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

#### **Figure 4.**

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

Policy engine in OpenStack is a type of authorization engine that return back a decision based on some policy rules that indicating if a specific operation is allowed or denied [14, 45, 48]. The default policy engine is maintained via Oslo policy, and the access request is issued via API communication. Oslo policy is completely separated from RBAC model [49]. The developer can view Oslo policy rules that are related to nova via the command "oslopolicy-policygenerator {namespace nova". The list of rules verifies if the user credentials are matching to grant access to the requested resources. The user credentials are stored in the format of a token. The token holds information related to the token itself in addition to the user, the project, the domain, the role, the service and the endpoint. The policy rules are stored in JSON (JavaScript Object Notation)

In policy.json, the access policy consists of two main parts "<target>": "<rule>" [47] . The target is known as an action that indicates the API call for an operation such as "start an instance". The rules can be one of the following: allow all, deny all, a special check, a comparison of two values, Boolean expressions based on simpler rules. The special check gives the developers an opportunity to extend the OpenStack policy engine. The special check can indicate, a role that is extracted from token information, or a complex rule by defining an alias, or a target URL that

Each service in Openstack has its own access control configuration points which involve PEP, PIP, PDP and PAP. The information ow between nova access-control configuration points is demonstrated in **Figure 4**. In the original Openstack architecture, Nova PEP will send a token that contains the information of the access request to Nova PIP to retrieve the object information. Then Nova PEP sends the information of the subject, object and request to Nova PDP in order for Nova PDP request an access control policy from Nova PAP. Nova PDP evaluate the access request based on the policy and return the access decision to

In the search stage of the problem-solving agent, there is a need to use a proper searching algorithm that meets the problem scenario and the input information. The search algorithms that are used in rule-based systems are backward chaining, forward-chaining and a mixture of both of them [34, 51]. **Table 2** compares between the reasoning algorithms which are referred to as chaining in some

Many researchers avoid the Logic Theory Machine, which is based on forwardreasoning due to the computation complexity. However, this complexity is due to the classical mathematical logic and it is not due to the forward-reasoning concept [52]. Classical mathematical logic such as propositional logic and First-order logic. Therefore, the computational complexity of forward-chaining when it is used in nonclassical logic such as deontic logic will be decidable, and it will have an acceptable computation complexity. A simple algorithm for forward-chaining is illustrated in **Figure 5**. Forward reasoning search iteration is based on facts and rules to

delegates the check to an external policy engine.

**5.2 Nova authorisation data-flow**

**5.3 Forward-chaining algorithm**

**5.1 Policy engine**

file format.

Nova PEP.

literature.

find a conclusion.

**44**

*Nova authorization data- flow [50].*


#### **Table 2.**

*Comparing forward-chaining with backward-chaining.*

**Figure 5.**

*Forward chaining algorithm.*

#### **5.4 ABAC implementation in OpenStack**

#### *5.4.1 Enforcement architecture*

The core characteristics of **ABACsh** are to work as an intelligent agent that sense the attributes (the environment, the system context, the subject and the object) in order to search for an access decision using forward chaining (forward-reasoning). The set of attributes represent facts whereas the set of policy rules represent the rules.

The proposed **ABACsh** enforcement architecture employs the Telemetry service of OpenStack. The telemetry service in Openstack provides the facility to sense the IaaS cloud for environment attributes and the context attributes. The Telemetry service facilitates polling information from the computing service since the proposed access control agent **ABACsh** will use the collected information for the attributes assignment process. As an example, the nova service access control process will be used to illustrate **ABACsh** extension. Section 4.3 introduces the default data ow of nova service access control while **Figure 6** illustrates nova service access control with **ABACsh** extension. The proposed **ABACsh** enforcement architecture focuses on three configuration points: PIP (Policy Information Point), PAP (Policy Admission Point) and PDP (Policy Decision Point). **ABACsh** enforcement architecture is divided into three components as follows:

