• **Data flow**.

Nova policy engine is embedded within its configuration files, therefore it is considered as one of OpenStack's limitations. However, the default policies can be overwritten if policy.json is enabled. Policy.json can be configured to call an external policy engine through URL. The token hold information that can be passed from OpenStack keystone to **ABACsh** policy engine via RESET GET-call. Nova PEP receives an access decision from **ABACsh** policy engine via RESET POST-call. **ABACsh** policy engine use a forward-chaining algorithm to produce an access control decision. The access control reasoning takes facts which are subject and object attributes, in addition to the system and context attributes.

**Figure 8.** *OpenStack testbed in physical machines.*

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 enforcement based on attributes.

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 PDP. The attributes are extracted from the following channels


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