**2.2 The proposed context-aware deployment in ABACsh**

As per the related work investigated in Section 2.1, we can conclude that to deploy an efficient context-ware feature, the attributes should be related to the system environment. Context-aware will add a flexibility to dynamic systems where the users and privileges keep changing such as the case in IaaS. ABAC is the basic access control type which can support the context-awareness. Therefore, we are not recommending RBAX extensions.

The proposed **ABACsh** model is adding context-aware through two phases. The first phase defines the context-attribute set. Each context-attribute consists of an attribute name and an attribute value. The context attributes-names set is predefined by the system administrator based on system critical information and characteristics. Context-attributes differ from the environment attributes in that the latter values are predefined by the administrator, whereas context-attribute values are updated based on the system states, where an embedded sensor captures the context information. For example, for the context-aware attribute named memory, its value will be updated based on the system memory measurements. The context attribute can reflect CPU clock, desk space, network zone, or data and time. In the second phase, context-awareness will be defined as one of the configuration points in the proposed **ABACsh** system to enforce the use of context in the access-control decision.

## **2.3 Critical analysis of SoD in ABAC**

In an environment that allows policy combination, a user is authorized to act in more than one role or trigger more than one operation simultaneously. Policy combination might lead to policy conflict, as some actions violate the overall policy if they are committed at the same time. Therefore, constraints should be configured to manage this possibility.

The Separation of Duty (SoD) principle is used in such scenarios to prevent misuse of the system by limiting the user to the least privilege necessary to perform their required tasks. The least privilege principle limits the access of the subject during an operation on a specific task to be within the minimum resources, lowest privileges, and specified period of time. Several security enhancements can be gained from SoD, such as fraud prevention and error minimization [14–16].

There are two main types of SoD: static, and dynamic. Static-SoD (SSoD) will list the conflicting roles which cannot be executed by the same user at the same time, whereas dynamic-SoD (DSoD) enforces the control at the time of

access-request. In an RBAC model, roles and role relations are defined in advance during the policy engineering process. For SSoD in RBAC, SSoD relations place constraints on the user-to-rule assignment function, where one user can be assigned a specific set of roles and be excluded from another set of roles. Otherwise, two or more users are required to be involved in accomplishing sensitive tasks, since it is less likely that multiple parties will issue a fraud attack. In the DSoD relation, the capabilities for one user are restricted to being activated during a specific user session, i.e. the same user cannot perform two roles simultaneously [17, 18].

Although in RBAC, SSoD and DSoD relations offer some advancement in control over identity-based systems, security issues remain. The most accommodating form of SoD is History based (HSoD). Although, enforcing it in a static based access control management environment such as RBAC is di\_cult, if not impossible [19, 20]. One role of a HSoD is that it prevents an object from being accessed by the same subject a certain number of times [21]. Therefore, we assume that the ABAC model concept has the characteristics of supporting certain types of SoD. The following section will investigate efforts in the literature to involve the SoD principle in ABAC.

A significant amount of research has been conducted regarding the principle of Separation of Duty (SoD) in RBAC; however, SoD deployment in ABAC remains a problem [22]. One of the earliest related works in specifying constraints in ABAC is illustrated through ABAC configuration-points [5]. Nevertheless, their proposed constraint settings are event-specific during attribute assignment and/or modification of the object and subject. This method is similar to the RBAC constraintssetting concept, where the allowed roles are activated for a specific user session after the roles are assigned to the users.

The author of ABCL proposed an event-independent constraint language based on conflicting relations of attribute values such as mutual exclusion and precondition [23]. ABCL language specifies restrictions either on a single set of attribute values or on a set of values of different attributes within the same entity. The usefulness of ABCL language has been validated through case studies. However, it lacks a framework or a formal model that illustrates its implementation. Dynamic Separation of Duties (DSoD) is more appropriate to cloud computing, and it also meets the dynamic nature of ABAC. Nguyen [24] has carried out interesting research on DSoD and proposed DSoD deployment through Provenance based Access Control (PBAC). His work is basically proposing a means to capture and utilize the information needed in the SoD enforcement, as previous work in the area assumes that the information is ready without demonstrating how to prepare it. Some of the previous work related to dynamic-based SoD is ObjDSoD, which is based on the object, and where the enforcement is constructed on a set consisting of conflicting-roles and a conicting-action on these roles. Therefore, the subject will not be allowed to perform an action on an object if that action is in the set of action role conflict. Another approach is OpsDSoD based on operations. This is a task-aware that involves an action-role conflict set, thus it differs from ObjDSoD by limiting the user to perform the needed actions for a particle task even though they have more privileges. A third approach is HDSoD, which combines ObjDSoD and OpsDSoD. Further, HDSoD is object-aware and a task aware. HDSoD is orderaware, where order-dependency conflict is triggered if the order is essential for a sequence of sub-tasks. Nguyen in [24] extended HDSoD by adding dependencepath-aware and past attribute-aware in their DSoD which is used in Provenancebased Access Control (PBAC).

Event pattern and response relations called obligations are introduced by Ferraiolo, Atluri, and Gavrila in their policy machine research [19], which can enforce some forms of HSoD in their access control framework. Obligations have

**37**

proven conclusions [31].

*An Intelligent Access Control Model*

*DOI: http://dx.doi.org/10.5772/intechopen.95459*

a set of conditions that are specified by the event pattern under which the state of the policy is obligated to change; only if this set matches the surrounding context, the operation on an object can be executed. There are two recognized standards can be applied to the ABAC concept: Extensible Access Control Markup Language (XACML), and Next Generation Access Control (NGAC) [25]. XACML does not show any support for DSoD constraint, while NGAC does show some support to DSoD through a Prohibitions (Denies)-relation, which includes a set of denying relations that specify privilege exceptions where a user that is allowed to run

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

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

capability (x) will be prohibited from running capability (y).

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

mechanism access-control restriction points [15].

**2.5 The proposed SoD deployment in IaaS by ABACsh**

Based on the above investigation [22–24, 29], SoD can be defined as an enforcement constraint configured to avoid conflict between policies. This conflict can be due to multi-access requests from different subjects to the same resource simultaneously, or the same subject requesting access to multiple resources at the same time. From this definition, it can be observed that SoD may be viewed as object-operation-oriented, which can be aligned with ABAC's relation between appropriate to enhance SoD by implementing a form of HSoD which will be suitable to be enforced in a dynamic access control policy environment such as ABAC. With RBAC, the centric entity involved in the SoD principle design is the role set. In contrast, ABAC cannot consider a role in the form of an attribute as it can lead to a chaos [30]. Therefore, the focus of this paper regarding formally defining SoD within ABAC will be on attributes and attribute-relations, with no aim to define an application-oriented SoD. Thus, we aim to identify a logical based design for SoD within the ABAC policy model. The proposed work is based on formal logic; exception cases are not encouraged in a formal logic as exceptions make regulations non-monotonic and introduce conflict between

subjects or specifications [28].

#### *An Intelligent Access Control Model DOI: http://dx.doi.org/10.5772/intechopen.95459*

*Quality Control - Intelligent Manufacturing, Robust Design and Charts*

access-request. In an RBAC model, roles and role relations are defined in advance during the policy engineering process. For SSoD in RBAC, SSoD relations place constraints on the user-to-rule assignment function, where one user can be assigned a specific set of roles and be excluded from another set of roles. Otherwise, two or more users are required to be involved in accomplishing sensitive tasks, since it is less likely that multiple parties will issue a fraud attack. In the DSoD relation, the capabilities for one user are restricted to being activated during a specific user ses-

sion, i.e. the same user cannot perform two roles simultaneously [17, 18].

Although in RBAC, SSoD and DSoD relations offer some advancement in control over identity-based systems, security issues remain. The most accommodating form of SoD is History based (HSoD). Although, enforcing it in a static based access control management environment such as RBAC is di\_cult, if not impossible [19, 20]. One role of a HSoD is that it prevents an object from being accessed by the same subject a certain number of times [21]. Therefore, we assume that the ABAC model concept has the characteristics of supporting certain types of SoD. The following section will investigate efforts in the literature to involve the SoD principle

A significant amount of research has been conducted regarding the principle of Separation of Duty (SoD) in RBAC; however, SoD deployment in ABAC remains a problem [22]. One of the earliest related works in specifying constraints in ABAC is illustrated through ABAC configuration-points [5]. Nevertheless, their proposed constraint settings are event-specific during attribute assignment and/or modification of the object and subject. This method is similar to the RBAC constraintssetting concept, where the allowed roles are activated for a specific user session

The author of ABCL proposed an event-independent constraint language based on conflicting relations of attribute values such as mutual exclusion and precondition [23]. ABCL language specifies restrictions either on a single set of attribute values or on a set of values of different attributes within the same entity. The usefulness of ABCL language has been validated through case studies. However, it lacks a framework or a formal model that illustrates its implementation. Dynamic Separation of Duties (DSoD) is more appropriate to cloud computing, and it also meets the dynamic nature of ABAC. Nguyen [24] has carried out interesting research on DSoD and proposed DSoD deployment through Provenance based Access Control (PBAC). His work is basically proposing a means to capture and utilize the information needed in the SoD enforcement, as previous work in the area assumes that the information is ready without demonstrating how to prepare it. Some of the previous work related to dynamic-based SoD is ObjDSoD, which is based on the object, and where the enforcement is constructed on a set consisting of conflicting-roles and a conicting-action on these roles. Therefore, the subject will not be allowed to perform an action on an object if that action is in the set of action role conflict. Another approach is OpsDSoD based on operations. This is a task-aware that involves an action-role conflict set, thus it differs from ObjDSoD by limiting the user to perform the needed actions for a particle task even though they have more privileges. A third approach is HDSoD, which combines ObjDSoD and OpsDSoD. Further, HDSoD is object-aware and a task aware. HDSoD is orderaware, where order-dependency conflict is triggered if the order is essential for a sequence of sub-tasks. Nguyen in [24] extended HDSoD by adding dependencepath-aware and past attribute-aware in their DSoD which is used in Provenance-

Event pattern and response relations called obligations are introduced by Ferraiolo, Atluri, and Gavrila in their policy machine research [19], which can enforce some forms of HSoD in their access control framework. Obligations have

**36**

based Access Control (PBAC).

in ABAC.

after the roles are assigned to the users.

a set of conditions that are specified by the event pattern under which the state of the policy is obligated to change; only if this set matches the surrounding context, the operation on an object can be executed. There are two recognized standards can be applied to the ABAC concept: Extensible Access Control Markup Language (XACML), and Next Generation Access Control (NGAC) [25]. XACML does not show any support for DSoD constraint, while NGAC does show some support to DSoD through a Prohibitions (Denies)-relation, which includes a set of denying relations that specify privilege exceptions where a user that is allowed to run capability (x) will be prohibited from running capability (y).
