**4. ABACsh implementation for IaaS cloud via OpenStack**

This section demonstrates the visibility of **ABACsh** in IaaS cloud by introducing an enforcement architecture based on OpenStack. That is followed by a prototype implementation and performance evaluation that illustrates the advantages of the proposed **ABACsh** extension over the existing access control model. This section discuss the following points

• Designing enforcement architecture for **ABACsh** that utilizes telemeter service deployment to be used in feeding Policy Information Point (PIP) with attributes values.

**43**

*An Intelligent Access Control Model*

intelligent ABAC.

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

external policy engine

• The introduced PDP follows **ABACsh** by

access decision processing.

time as a performance metric.

and commercial bodies.

Control (RBAC).

specific policy file called policy.json.

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

• A prototype implementation of an extended nova access control model with an

○ Extend the nova policy enforcement point (PEP) to communicate with an

○ The proposed external policy-engine works as policy decision point (PDP)

○ Involving forward-chaining algorithm that works as logical reasoning for

• Three experiments are studied to compare and contrast the extended **ABACsh**

• The Quality of Service (QoS) measurement is discussed based on response

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

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

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

○ Utilizing the attributes in access decision-making process.

with the default nova-OpenStack access control model.

(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

The proposed intelligent framework for **ABACsh** has been published by this chapter author in [40]. **Figure 3** shows the framework components. The proposed **ABACsh** model framework focuses on three functional points in Ref. to XACML framework: PDP, PIP and PAP. The Policy Enforcement Point (PEP) enforces the access decision. The PDP (Policy Decision Point) involves the core logical reasoning that takes place in an inference mechanism where the access decision is processed. The PAP (Policy Administration Point) involves rule creation by the system administrators. The PIP (Policy Information Point) involves information

This section demonstrates the visibility of **ABACsh** in IaaS cloud by introducing an enforcement architecture based on OpenStack. That is followed by a prototype implementation and performance evaluation that illustrates the advantages of the proposed **ABACsh** extension over the existing access control model. This section

service deployment to be used in feeding Policy Information Point (PIP) with

• Designing enforcement architecture for **ABACsh** that utilizes telemeter

**4. ABACsh implementation for IaaS cloud via OpenStack**

**42**

collection of attributes.

**Figure 3.**

collection.

**3.4 The proposed framework**

*The proposed intelligent framework for ABACsh.*

discuss the following points

attributes values.

	- Extend the nova policy enforcement point (PEP) to communicate with an external policy engine
	- The proposed external policy-engine works as policy decision point (PDP)
	- Utilizing the attributes in access decision-making process.
	- Involving forward-chaining algorithm that works as logical reasoning for access decision processing.
