*5.4.3 Performance evaluation*

The aim of this performance evaluation is to detect if **ABACsh** deployment in Openstack introduces any significant overhead. The efficiency of deploying an access control model depends on several factors. The quality of service (QoS) measures

**49**

engine.

*An Intelligent Access Control Model*

*The prototype implementation data flow.*

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

can be calculated by performance properties and computation complexity [61, 62]. In this section, the performance metrics are evaluated. The performance metrics consist of four elements: response time, policy repository and retrieval, policy distribution, and Integrated with authentication function [62]. **Table 3** explains theses performance metrics elements and on which access control components they can be applied. Since the implemented prototype is the **ABACsh** PDP, the followed experiments will measure response time. With regard to policy repository and retrieval, the implemented **ABACsh** use JSON file to store access control policy which does not add any extra hardware or software cost to OpenStack IaaS cloud as this form of policy storage is used by OpenStack. The remaining two performance metrics elements are

In this section, the performance evaluation of the implemented **ABACsh** prototype in OpenStack is presented. Specifically, **ABACsh** policy engine which represents PDP of access control model is discussed. The experiments fall into three parts where the response time is calculated. Response time indicates the time consumed by the system in order to process the access request decision call. The response time has been used to measure the performance in several OpenStack implementations such as in [63, 64]. In these experiments, OpenStack cloud was installed in physical servers running Ubuntu 16.04 LTS release. Three types of execution time can be measured [65, 66]. The first one is real time that reflects the wall clock where the time is calculated from the start till the end of the call including the waiting time and time used by other processes. The second one is user-time that reflects the actual CPU-time spent outside the kernel during the process call in user-mode without considering other processes. The third one is sys-time that reflects the actual

not calculated in this stage as PIP is not implemented.

CPU-time spent within the kernel during the process execution.

Three experimental settings have been implemented as explained below.

• Experiment 1 (Exp1): The response time for the default access control model to process access request to nova resources. The default use RBAC and Oslo policy

• Experiment 2 (Exp2): The response time for extending the default nova policy engine with **ABACsh** that utilizes 24 attributes in access control processing

• Experiment 3 (Exp3): The response time for extending the default nova policy engine with **ABACsh** that use forward-chaining for access control reasoning.

*5.4.4 Experiment content*

**Figure 9.**

**Figure 9.**

enforcement based on attributes.

*OpenStack testbed in physical machines.*

**Figure 8.**

'through curl command.

JSON \_le format

*5.4.3 Performance evaluation*

information is stored in JSON \_le format

be included via Telemetry OpenStack service

Based on access rules defined by the administrator, the access request will be allowed or denied. **Figure 9** shows the **ABACsh** PDP extension to nova authorization. A policy engine is designed and implemented to add an access control

In access control terminology, the Openstack users are the subject, the nova resources are the objects, the policy.json is PEP and **ABACsh** policy engine is the

• The subject attributes can be extracted from keystone token where the available information is user name, user id, user passward, role id, role name. The Token information can be retrieved from "content-type:application/json'

• The extracted nova metrics from the OpenStack system via a command openstack quota show are considered as the object attributes. The attributes

• The nova environment attributes are extracted via the OpenStack command openstack hypervisor stats show. The attributes information is stored in

• The context attributes are not implemented in this prototype but it is visible to

**ABACsh** policy engine server is implemented using several programming technologies. The web server is developed using Python programming language with web.py since OpenStack services is using python. RESETful API utilities are used to allow the communication between **ABACsh** and OpenStack APIs. The forward reasoning function is programmed using java since this programming language can be smoothly integrated into web programming. To allow the technical interaction between python and java, jpype is used [59, 60]. Data is

stored in JSON file formats such as policy data and attributes data.

The aim of this performance evaluation is to detect if **ABACsh** deployment in Openstack introduces any significant overhead. The efficiency of deploying an access control model depends on several factors. The quality of service (QoS) measures

PDP. The attributes are extracted from the following channels

**48**

*The prototype implementation data flow.*

can be calculated by performance properties and computation complexity [61, 62]. In this section, the performance metrics are evaluated. The performance metrics consist of four elements: response time, policy repository and retrieval, policy distribution, and Integrated with authentication function [62]. **Table 3** explains theses performance metrics elements and on which access control components they can be applied. Since the implemented prototype is the **ABACsh** PDP, the followed experiments will measure response time. With regard to policy repository and retrieval, the implemented **ABACsh** use JSON file to store access control policy which does not add any extra hardware or software cost to OpenStack IaaS cloud as this form of policy storage is used by OpenStack. The remaining two performance metrics elements are not calculated in this stage as PIP is not implemented.
