**3.3 ABACsh conceptual requirement**

Based on the analysis and investigations addressed an analytical study published by this chapter author in [40], the critical requirements in designing an ABAC model are listed below.


**41**

*An Intelligent Access Control Model*

knowledge base(KB)

**Figure 2.**

inference system

**Table 1.**

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

*A generic knowledge-based agent function [34].*

The enhanced attribute-based access control **ABACsh** fulfills requirement Req.1 by employing one main configuration point that is ABAC agent. This agent takes as an input, the access request parameters which consist of the subject, the object, and the operation (s, o, opr). Then it returns the access decision that indicates if the subject is

Background sentences Predefined sets of entities, attributes and

To represent action(s) The action is access-decision

policy rules

operation

access-request

New sentences are added each time an access-request is triggered which consist of a combination of attributes with the request

Reasoning based on the attributes set and the policy rule-sets to conclude with an appropriate action (allow or deny) the

configuration points, the policy configuration here is reduced to one, as the proliferation of policy configuration points can introduce difficulties in policy expression and comprehension [5]. For Req.2, in the Policy Decision Point (PDP), the decisionmaking process considers the subject attributes in addition to other attributes, instead of depending solely on the subject identity information. In Req.3, grouping is studied

However, grouping and listing will impede the flexible nature of ABAC [30, 42]. Therefore, permissions grouping and listing are avoided in this **ABACsh**. The decision calculation is based on four sets of attributes: subject-attributes, object-attributes, environment-attributes, and system-context attributes, all of which are taken into consideration in the proposed design to meet requirement Req.4. System context attributes have a special sensor to obtain an up to date system state to meet requirement Req.5. The privilege decision is calculated based on the attributes relation defined in the policy-rules. Therefore; the privilege value is returned after the access-decision is triggered, which meets the requirement Req.6. There are two core functions of **ABACsh**. The first function takes place at the initial system stage, where the attribute pairs (name:value) are created for the defined access control system entities

α

, which has four

allowed to operate on the object or it is denied. Compared to ABAC

**Components Agent architecture ABAC requirements**

Infer (i.e arrive to a conclusion via reasoning) hidden properties of the world to add new sentence to KB

Infer based on the predefined sentences and the new ones to conclude with appropriate actions

*Mapping knowledge-based agent with ABAC requirements.*

by HGABAC [41] to facilitate the addition of a hierarchy feature to ABAC.

#### **Figure 2.**

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

Modal logic is a candidate that supports a logical approach in artificial intelligence systems [39]. The main component of a knowledge-agent is a Knowledge-Base (KB) that consists of a set of sentences expressed using formal logic, in addition to two generic functions that involve logical inference. The first function is known as TELL, and adds new sentences (facts) to the KB to provide it with the required information. The second function is known as ASK, and queries the known information from the KB to determine the next step. The process between TELL and ASK will end as soon as the desired action is selected. The interaction between these two generic functions is similar to the updating and querying in databases, as illustrated in **Figure 2**. When an agent program is called upon, it performs two main actions. Firstly, it will TELL the KB what it perceives. Secondly, it ASKs the KB what action should be taken. Therefore, agent-based architecture is suitable to represent an ABAC model. The logical agent, furthermore, will be appropriate for the proposed modal logic scheme. **Table 1** demonstrates how knowledge-based agent architecture can represent an ABAC system. The logical agent can be designed to represent an access-request state through a process of inference to derive a new representation of the access-request state that can be used to deduce required actions. The proposed access-control logic agent will be

founded on knowledge-based agents, as this type of agent is logic-based [34].

by this chapter author in [40], the critical requirements in designing an ABAC

tion points as they affect the system's computational complexity.

not the main elements in access-decision processing.

be flexible and able to cope with large enterprises.

attributes reflect the fixed system characteristics.

defined upon access-request.

rules-creation.

• Req.1 ABAC model definition requires to identify the configuration points. Each point should be formalized via the proper languages. The configuration point indicates the necessary configurations to be accomplished via the ABAC model processing for computing the access decision. These points are known as functional points. It is more convenient to minimize the number of configura-

• Req.2 ABAC is identity-free. Therefore, identifications such as subject-id are

• Req.3 Avoid the creation of lists or groups in the design, as ABAC is intended to

• Req.4 Context-attributes reflect the current system state, whereas environment

• Req.5 ABAC is a multi-factor decision. Therefore, it enables fine-grained access

• Req.6 There are no predefined privileges for subjects as the privileges are computed after an access request is triggered. Policy rules set in ABAC are specified based on attributes. As a result, the permissible operations will be

• Req.7 The two basic functionalities in ABAC are attribute-assignment and

• Req.8 Security principles such as Separation of Duty (SoD) must be enforced.

Based on the analysis and investigations addressed an analytical study published

**3.3 ABACsh conceptual requirement**

model are listed below.

**40**

*A generic knowledge-based agent function [34].*


#### **Table 1.**

*Mapping knowledge-based agent with ABAC requirements.*

The enhanced attribute-based access control **ABACsh** fulfills requirement Req.1 by employing one main configuration point that is ABAC agent. This agent takes as an input, the access request parameters which consist of the subject, the object, and the operation (s, o, opr). Then it returns the access decision that indicates if the subject is allowed to operate on the object or it is denied. Compared to ABACα , which has four configuration points, the policy configuration here is reduced to one, as the proliferation of policy configuration points can introduce difficulties in policy expression and comprehension [5]. For Req.2, in the Policy Decision Point (PDP), the decisionmaking process considers the subject attributes in addition to other attributes, instead of depending solely on the subject identity information. In Req.3, grouping is studied by HGABAC [41] to facilitate the addition of a hierarchy feature to ABAC.

However, grouping and listing will impede the flexible nature of ABAC [30, 42]. Therefore, permissions grouping and listing are avoided in this **ABACsh**. The decision calculation is based on four sets of attributes: subject-attributes, object-attributes, environment-attributes, and system-context attributes, all of which are taken into consideration in the proposed design to meet requirement Req.4. System context attributes have a special sensor to obtain an up to date system state to meet requirement Req.5. The privilege decision is calculated based on the attributes relation defined in the policy-rules. Therefore; the privilege value is returned after the access-decision is triggered, which meets the requirement Req.6. There are two core functions of **ABACsh**. The first function takes place at the initial system stage, where the attribute pairs (name:value) are created for the defined access control system entities

#### **Figure 3.**

*The proposed intelligent framework for ABACsh.*

(subject, object, environment, and context). The second function is rules creation, which represents the SoD-rules and Policy-rules in the form of capability which indicates the access-rights. These two functions meet the ABAC requirement Req.7. An initial SoD is introduced in this design in the type of a DSoD. The elimination of policy-rule conflicts can be achieved by an object-operation oriented constraint. A formal presentation of the proposed SoD enforcement sentences is defined and will be flexible to manage the set of constraints and meet the system requirements Req.8 since the administrator can modify the set of SoD sentences. The proposed SoD will be enforced after the access-request is triggered where an action is forbidden based on a collection of attributes.
