**2.4 SoD design and deployment in access control system**

It is most likely that the formulation of SoD requirements are prepared by the administrator based on the business rules. An example of such a rule is, person may not approve his or her own purchase order [26]. SoD deployment can be involved with different layers of an access control system. It can be designed within administrative-level policies and procedures, or it can be used within logical or technical mechanism access-control restriction points [15].

Based on recommendations regarding SoD implementation to traverse its limitation in RBAC [20], several techniques have been explored, such as grouping concept, membership control, activation control, history control, and labels. However, in ABAC, the grouping concept will not be appropriate as grouping restricts an attributes flexible nature. Membership control cannot be adopted by ABAC as it is not role-centric. Though, the activation control concept has been adopted into SoD specifications in ABAC by Jin [5] and Bijon [23]. Ferraiolo et al. [19] describe a relation between entities that can be used in History based SoD deployment. Whereas Biswas et al. [27] point out that label concept can be used to enforce SoD in their proposed label-based access control in an ABAC. There are several obstacles in designing and implementing SoD, as it is an application-oriented policy where the business rules indicate the critical tasks which require SoD enforcement. Another challenge is that different applications may require various types of SoD. Lastly, most SoD types are informally defined, which creates ambiguity regarding the subjects or specifications [28].
