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

## **Figure 6.**

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

ture is divided into three components as follows:

store policy rules in OpenStack

*5.4.2 Prototype implementation*

• **Scope and Assumption.**

facilitate its implementation in OpenStack.

reasoning indicates if the access is permitted or denied.

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 architec-

1.**ABACsh** PIP: this is used to collect attributes information from the access

2.**ABACsh** PAP: The knowledge database for **ABACsh** model consists of access rules from SoD rules and Policy rules. The access rules are created by the system administrator. Those rules will be stored in JSON file format to

3.**ABACsh** PDP: this is the logical component which reasons about access control in **ABACsh**. **ABACsh** PDP will get an access-request sentence from **ABACsh** PEP that consist of the attributes information with the access request. **ABACsh** PDP will load the access rules from **ABACsh** PAP. **ABACsh** PDP accomplishes logical reasoning through forward-chaining algorithm. The result of the logical

The first stage of **ABACsh** deployment in Openstack is to be implemented on

IaaS access control tenant scope can be a single tenant [5], multi-tenant [54–56] and collaborating parties a cross-clouds [57, 58]. The implementation scope of access control in this chapter is within single tenant whereas its hypothesis is applicable to multi-tenant and cross-clouds as the big concept behind **ABACsh** is user-id free and attributes-based. The proposed **ABACsh** is not replacing OpenStack RBAC in this stage. Instead, it allows fine-grained access control and opens prospective avenues to replace RBAC in the near

nova component. **ABACsh** PDP part will be implemented as a prototype.

control entities, the environment, and the system context. PIP can be achieved in Openstack through configuring the Telemetry component. The Telemetry service is designed to support a billing system by gathering the required information. Therefore, its structure will be beneficial in providing PIP with required attribute information. Telemetry consists of five building blocks: Compute Agent, Central Agent, Collector, Data Store and API Server in order to perform five essential functions [53]. **Figure 7** summarizes the Telemeter process to collect data for further analysis. Telemeter can be configured to collect the attributes and save them in JSON file as this file format is used to

**46**

feature.

*Proposed ABACsh for Openstack nova.*
