**5. OpenStack access control model (OSAC)**

A key component in building a virtualization environment is its operation via the hypervisor. The hypervisor on its own cannot build IaaS. Therefore, a cloudstack such as OpenStack, Cloud-Stack or OpenNebul is required. According to the current industry, OpenStack is likely to become a dominant cloud-stack [43]. OpenStack is an open-source cloud computing platform that offers an IaaS layer of service. OpenStack IaaS infrastructure supports agent communication. For example, network nodes in the OpenStack activate a DHCP agent to deploy a DHCP service [44]. OpenStack was selected to be the experimental platform for this research as it has a supportive and active community of both academic researchers and commercial bodies.

OpenStack can deploy different access control models within its infrastructure [45]. For example, nova configuration files can be protected via several implementations such as centralized logging, policy file (policy.json) and MAC framework (Mandatory Access Control). The availability of access control models depends on the hypervisor vendor. The supported models are Mandatory Access Control (MAC), Discretionary Access Control (DAC), and Role-Based Access Control (RBAC).

The Openstack access control model (OSAC) that enables both operators and users to access resources for specific services is a type of RBAC [46]. The keystone [47] supports the notation of roles and groups. Each user should be associated with a group, and each group has a list of roles. For a user to be granted access to a service, Openstack service takes into consideration his/her role, though as the first authorization step, the OpenStack PEP (Policy Enforcement Point) takes into consideration the policy rules associated with the resources before it checks the user role. Therefore, the policy enforcement middleware enables fine-grained access. Each Openstack service defines the access control policies rules for its resources in a specific policy file called policy.json.

## **5.1 Policy engine**

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) file format.

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 delegates the check to an external policy engine.

#### **5.2 Nova authorisation data-flow**

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 Nova PEP.

#### **5.3 Forward-chaining algorithm**

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 literature.

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 find a conclusion.

**45**

rules.

**Figure 5.**

*An Intelligent Access Control Model*

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

**5.4 ABAC implementation in OpenStack**

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

**Forward-chaining Backward-chaining**

A hypothesis (goal) to reach the facts

behind it

Known as Forward reasoning (Data driven) Backward reasoning (Goal driven)

When applicable If the goal is unknown If the set of goals are known

A Set of facts to reach a goal (or

hypothesis)

*Comparing forward-chaining with backward-chaining.*

*5.4.1 Enforcement architecture*

*Forward chaining algorithm.*

Reasoning start

*Nova authorization data- flow [50].*

with

**Figure 4.**

**Table 2.**
