Mapping knowledge-based agent with ABAC requirements.
Cybersecurity is a critical issue as the world is moving towered IR4 era (Industrial Revaluation 4.0) where technology is involved, and access to the internet is an imperative need. The traditional computing systems are not able to meet the huge computing demand and growing data (Big-Data). Therefore; new technologies have been evolved such as cloud computing. This chapter is exploring the need for a dynamic access control approach to enhance the Cybersecurity. The scope in this chapter is focusing on IaaS (Infrastructure as a Service) layer of cloud computing. The research approach aims to enhance the basic ABAC (Attribute-Based Access Control) model by adding a context-aware feature and SoD principle. The enhanced model called ABACsh. This proposed enhancement is implemented through a framework based on AI (Artificial Intelligent) to meet the requirements of dynamic systems. The framework is tested in the OpenStack testbed. The results show better performance in the term of computation speed.
- formal logic
- cloud computing
Industrial revolution 4 (IR 4.0) utilizes technology in different aspects. As per the world economic forum, three principle technology drivers in the industrial production: connectivity, intelligence and flexible automation where big data is one of the value drivers and IoT is one of the scale-ups enablers . To summarize one scenario of the embedded technology in the industry is the implementation of IoT systems. Internet of Things (IoT) starts with a collection of sensors used to collect information from the surrounded environment. For example, a temperature sensor used to collect the atmosphere temperature during the day by taking three reads for six months for the purpose of studying climate change. The collected data will be sent to central storage such as cloud computing technology to get the advantage of accessing the data anywhere and anytime. There is a need for a network connective that allows distributed components to be connected. Mostly the collected data is a type of big-date as they might collect temperature reading from a different site in the globe and for a long time might be years. That big-data requires some analysis where the traditional analytical system might not manage to absorb its huge records, therefore; there is a need to utilize the features of artificial intelligence filed in data-science. This example shows how several technologies are used in order to be used in analyzing the big-data collected from different sites.
As there are distributed systems and the internet connection is used, cybersecurity becomes a critical aspect, especially when there are some economic benefits. There are many security principles which might be tackled in order to enhance the cybersecurity of the systems, however, access control is one of the major aspects as there will be a need to restrict the access to the system as there is a distributed environment when it comes to IoT deployment. One of the optimal access control models to be used in this case is attribute-based access control model (ABAC) [1, 2].
This chapter introduces intelligent attribute-based access control model tested in the cloud computing environment. Section 2 discusses the introduced enhancements to the basic ABAC model. Section 3 illustrates how inelegant is introduced in the proposed ABAC. Finally, an empirical experiment is demonstrated in Section 4 where OpenStack (cloud environment) is used to discuss the efficiency of the proposed approach.
2. The proposed enhancement in ABAC model
2.1 Context-aware analytical study
Context-aware system has verity of definitions based on the study scope. In access control field, context-aware allowing a dynamic permission to access an object based on some attributes related to the user context . The context can be extracted from the system environment by using 5W1H (who, where, what, why, when and how) . The context attributes are a finite set which reflect the system and differs from the attributes related to the subject and the object as per the researcher in . However, other authors consider the rule enforcement through Attribute-Based Access Control (ABAC) is based on the attributes of both the subject and the object . Therefore; this section is investigating context-aware concept in access control.
An ubiquitous application with RBAC extension has been investigated by Kim’s  where state checking matrix is used to build a context-aware agent. Two cases are defined to deploy context-awareness. The first one is through giving privilege up-on the user context, such as location and time. The second one is changing resource permissions up-on the system information, such as network bandwidth and memory usage. Another work proposed by Kim in this filed, called CIAAC (Context Information-based Application Access Control) . CIAAC designed to separate processing logic and business from context awareness and access control policy. CIAAC add flexibility to business application which support dynamic access control policy. This feature allows to satisfy the demand of external security environment. However, the potential drawbacks of CIAAC have not yet been evaluated. Another technique was proposed by Li in his thesis  to meet the scope of mobile cloud environment based on Attribute-Based Encryption (ABE). Li defines context-aware terminology to cover the user context-information in addition to the environment such as location and time.
As per the literature, encryption techniques such as ABE introduce several limitations which effect the overall system efficiency such as the overhead caused by bilinear pairing due to its heavy computation . In addition to that ABE cannot attain fine-grained control . Another related work done by AL Kukhun  considering pervasive systems where XACML language is used to build a model to extend RBAC that can facilitate context-aware features. However, RBAC extinctions approaches do not satisfy usability, situation awareness, and improving access opportunities. It can be observed that location and time are used as context-aware parameters in most related work on context-aware access control models. Liu and Wang  present the Fine-grained Context-aware Access (FCAC) model for Health Care and Life Sciences (HCLS) using specific communication technology based on linked data. FCAC is based on two main components: an ontology base, and access policy with XACML.
It is observed from the state of art that context attributes are linked to the system environment rather than subject-attributes or object-attributes. Venkatasubramanian et al.  investigate context-aware to distinguish between the traditional authorization models and their proposed criticality-aware as they take into consideration the context of the whole system. Their criticality-aware (CAAC) is based on RBAC concepts. Choi  used access-aware in cloud computing. Choi recommends an ontology-based Access Control Model (onto-ACM). Compared to C-RBAC (Context-aware RBAC), onto-ACM can grant the role inheritance by administrator and user, whereas C-RBAC grants the role by administrator only.
2.2 The proposed context-aware deployment in ABACsh
As per the related work investigated in Section 2.1, we can conclude that to deploy an efficient context-ware feature, the attributes should be related to the system environment. Context-aware will add a flexibility to dynamic systems where the users and privileges keep changing such as the case in IaaS. ABAC is the basic access control type which can support the context-awareness. Therefore, we are not recommending RBAX extensions.
The proposed ABACsh model is adding context-aware through two phases. The first phase defines the context-attribute set. Each context-attribute consists of an attribute name and an attribute value. The context attributes-names set is predefined by the system administrator based on system critical information and characteristics. Context-attributes differ from the environment attributes in that the latter values are predefined by the administrator, whereas context-attribute values are updated based on the system states, where an embedded sensor captures the context information. For example, for the context-aware attribute named memory, its value will be updated based on the system memory measurements. The context attribute can reflect CPU clock, desk space, network zone, or data and time. In the second phase, context-awareness will be defined as one of the configuration points in the proposed ABACsh system to enforce the use of context in the access-control decision.
2.3 Critical analysis of SoD in ABAC
In an environment that allows policy combination, a user is authorized to act in more than one role or trigger more than one operation simultaneously. Policy combination might lead to policy conflict, as some actions violate the overall policy if they are committed at the same time. Therefore, constraints should be configured to manage this possibility.
The Separation of Duty (SoD) principle is used in such scenarios to prevent misuse of the system by limiting the user to the least privilege necessary to perform their required tasks. The least privilege principle limits the access of the subject during an operation on a specific task to be within the minimum resources, lowest privileges, and specified period of time. Several security enhancements can be gained from SoD, such as fraud prevention and error minimization [14, 15, 16].
There are two main types of SoD: static, and dynamic. Static-SoD (SSoD) will list the conflicting roles which cannot be executed by the same user at the same time, whereas dynamic-SoD (DSoD) enforces the control at the time of access-request. In an RBAC model, roles and role relations are defined in advance during the policy engineering process. For SSoD in RBAC, SSoD relations place constraints on the user-to-rule assignment function, where one user can be assigned a specific set of roles and be excluded from another set of roles. Otherwise, two or more users are required to be involved in accomplishing sensitive tasks, since it is less likely that multiple parties will issue a fraud attack. In the DSoD relation, the capabilities for one user are restricted to being activated during a specific user session, i.e. the same user cannot perform two roles simultaneously [17, 18].
Although in RBAC, SSoD and DSoD relations offer some advancement in control over identity-based systems, security issues remain. The most accommodating form of SoD is History based (HSoD). Although, enforcing it in a static based access control management environment such as RBAC is di_cult, if not impossible [19, 20]. One role of a HSoD is that it prevents an object from being accessed by the same subject a certain number of times . Therefore, we assume that the ABAC model concept has the characteristics of supporting certain types of SoD. The following section will investigate efforts in the literature to involve the SoD principle in ABAC.
A significant amount of research has been conducted regarding the principle of Separation of Duty (SoD) in RBAC; however, SoD deployment in ABAC remains a problem . One of the earliest related works in specifying constraints in ABAC is illustrated through ABAC configuration-points . Nevertheless, their proposed constraint settings are event-specific during attribute assignment and/or modification of the object and subject. This method is similar to the RBAC constraints-setting concept, where the allowed roles are activated for a specific user session after the roles are assigned to the users.
The author of ABCL proposed an event-independent constraint language based on conflicting relations of attribute values such as mutual exclusion and precondition . ABCL language specifies restrictions either on a single set of attribute values or on a set of values of different attributes within the same entity. The usefulness of ABCL language has been validated through case studies. However, it lacks a framework or a formal model that illustrates its implementation. Dynamic Separation of Duties (DSoD) is more appropriate to cloud computing, and it also meets the dynamic nature of ABAC. Nguyen  has carried out interesting research on DSoD and proposed DSoD deployment through Provenance based Access Control (PBAC). His work is basically proposing a means to capture and utilize the information needed in the SoD enforcement, as previous work in the area assumes that the information is ready without demonstrating how to prepare it. Some of the previous work related to dynamic-based SoD is ObjDSoD, which is based on the object, and where the enforcement is constructed on a set consisting of conflicting-roles and a conicting-action on these roles. Therefore, the subject will not be allowed to perform an action on an object if that action is in the set of action role conflict. Another approach is OpsDSoD based on operations. This is a task-aware that involves an action-role conflict set, thus it differs from ObjDSoD by limiting the user to perform the needed actions for a particle task even though they have more privileges. A third approach is HDSoD, which combines ObjDSoD and OpsDSoD. Further, HDSoD is object-aware and a task aware. HDSoD is order-aware, where order-dependency conflict is triggered if the order is essential for a sequence of sub-tasks. Nguyen in  extended HDSoD by adding dependence-path-aware and past attribute-aware in their DSoD which is used in Provenance-based Access Control (PBAC).
Event pattern and response relations called obligations are introduced by Ferraiolo, Atluri, and Gavrila in their policy machine research , which can enforce some forms of HSoD in their access control framework. Obligations have a set of conditions that are specified by the event pattern under which the state of the policy is obligated to change; only if this set matches the surrounding context, the operation on an object can be executed. There are two recognized standards can be applied to the ABAC concept: Extensible Access Control Markup Language (XACML), and Next Generation Access Control (NGAC) . XACML does not show any support for DSoD constraint, while NGAC does show some support to DSoD through a Prohibitions (Denies)-relation, which includes a set of denying relations that specify privilege exceptions where a user that is allowed to run capability (x) will be prohibited from running capability (y).
2.4 SoD design and deployment in access control system
It is most likely that the formulation of SoD requirements are prepared by the administrator based on the business rules. An example of such a rule is, person may not approve his or her own purchase order . SoD deployment can be involved with different layers of an access control system. It can be designed within administrative-level policies and procedures, or it can be used within logical or technical mechanism access-control restriction points .
Based on recommendations regarding SoD implementation to traverse its limitation in RBAC , several techniques have been explored, such as grouping concept, membership control, activation control, history control, and labels. However, in ABAC, the grouping concept will not be appropriate as grouping restricts an attributes flexible nature. Membership control cannot be adopted by ABAC as it is not role-centric. Though, the activation control concept has been adopted into SoD specifications in ABAC by Jin  and Bijon . Ferraiolo et al.  describe a relation between entities that can be used in History based SoD deployment. Whereas Biswas et al.  point out that label concept can be used to enforce SoD in their proposed label-based access control in an ABAC. There are several obstacles in designing and implementing SoD, as it is an application-oriented policy where the business rules indicate the critical tasks which require SoD enforcement. Another challenge is that different applications may require various types of SoD. Lastly, most SoD types are informally defined, which creates ambiguity regarding the subjects or specifications .
2.5 The proposed SoD deployment in IaaS by ABACsh
Based on the above investigation [22, 23, 24, 29], SoD can be defined as an enforcement constraint configured to avoid conflict between policies. This conflict can be due to multi-access requests from different subjects to the same resource simultaneously, or the same subject requesting access to multiple resources at the same time. From this definition, it can be observed that SoD may be viewed as object-operation-oriented, which can be aligned with ABAC’s relation between appropriate to enhance SoD by implementing a form of HSoD which will be suitable to be enforced in a dynamic access control policy environment such as ABAC. With RBAC, the centric entity involved in the SoD principle design is the role set. In contrast, ABAC cannot consider a role in the form of an attribute as it can lead to a chaos . Therefore, the focus of this paper regarding formally defining SoD within ABAC will be on attributes and attribute-relations, with no aim to define an application-oriented SoD. Thus, we aim to identify a logical based design for SoD within the ABAC policy model. The proposed work is based on formal logic; exception cases are not encouraged in a formal logic as exceptions make regulations non-monotonic and introduce conflict between proven conclusions .
Therefore, the proposed SoD is operation-object orientated that defines a rules-set reflecting the forbidden operations on the set of objects under a specific situation of a collection of entities attributes. Entities include the object, the subject, the environment, and the system context. Moreover, formal logic facilitates SoD rule creation, even by non-expert security administrators. Since the proposed system is attribute-based, it is not necessary to update different locations if a new action restriction is added, deleted, or modified. Object-attributes and operations. We can discern from the above that it is more appropriate to enhance SoD by implementing a form of HSoD which will be suitable to be enforced in a dynamic access control policy environment such as ABAC. With RBAC, the centric entity involved in the SoD principle design is the role set. In contrast, ABAC cannot consider a role in the form of an attribute as it can lead to a chaos . Therefore, the focus of this paper regarding formally defining SoD within ABAC will be on attributes and attribute-relations, with no aim to define an application-oriented SoD. Thus, we aim to identify a logical based design for SoD within the ABAC policy model. The proposed work is based on formal logic; exception cases are not encouraged in a formal logic as exceptions make regulations non-monotonic and introduce conflict between proven conclusions . Therefore, the proposed SoD is operation-object orientated that defines a rules-set rejecting the forbidden operations on the set of objects under a specific situation of a collection of entities attributes. Entities include the object, the subject, the environment, and the system context. Moreover, formal logic facilitates SoD rule creation, even by non-expert security administrators. Since the proposed system is attribute-based, it is not necessary to update different locations if a new action restriction is added, deleted, or modified.
3. An intelligent framework for ABACsh
The framework is designed based on knowledge-agent and it employs rule-based expert system method. This intelligent system is not based on machine learning which will have a percentage of correct answers. This system is based on the available rules; therefore, it is not a type of uncertain approach. The system must guarantee an access decision.
The purpose of this ABACsh framework is to prove that AI architecture can contribute in supporting a dynamic access control. In regard to guaranteeing behavior, the followed mechanism in this chapter is based on knowledge available. If there is a shortage in knowledge, the access decision will be denied. There are other AI categories related to uncertain knowledge such as probabilistic reasoning, However, uncertain reasoning is out of this research scope.
3.1 AI scope for the proposed framework
According to [32, 33, 34], artificial intelligence systems are designed to think and act. They can be categorized into four types based on the intention of the system: Thinking Humanly, Acting Humanly, Thinking Rationally and Acting Rationally. The category of Thinking Rationally leads to an evolved need for the logic field in artificial intelligence. Involving logic in an intelligent system faces two substantial obstacles. The first one is the difficulty of presenting informal-knowledge using a formal logical notation though the certainty level is less than 100%. The second is that solving problems theoretically is different from solving them practically when the machine capacity is taken into consideration.
The category of Acting Rationally initiates the development of a computer agent. Prior to computer science, the term agent was used in different fields. Therefore, there are various definitions of agent. However, it can be defined as an entity that acts within an environment by sensing its surroundings to update its knowledge and acts upon that to meet specific goals . The agent function represents an abstract mathematical description, whereas the agent program represents an agent implementation within a physical system.
Problem-solving through an intelligent agent involves four stages. Firstly, the agent formulates its goal. Secondly, it formulates the problem based on five steps: initial state, possible actions, transition model that describes what each action does, goal test and path cost. Thirdly, it searches for a solution by looking for a sequence of actions that leads to the goal. Fourthly, in the execution stage, the solution found is implemented. However, the problem-solving agent is inflexible as each possible state should be hard-coded. Therefore, the complexity of the search stage grows exponentially in relation to the number of states in addition to its inability to infer unobserved information. Therefore, there is a need for logic to reason about the possible states instead of hard-coded all predicted states.
Knowledge-based reasoning is a step in overcoming problem-solving agent limitations. The logic provides a natural language for describing and reasoning about the system. The knowledge-based system is given facts about the external world, and it is asked queries about that world. The rule-based expert system is a popular method that is used to build knowledge-based systems. The rules are used to represent knowledge in the format of IF-THEN. The Inference engine is the reasoning component whereby the system concludes by linking the rules given in the knowledge base with facts supplied from the database. The explanation facilities allow the user to interact with the expert system to get justifications regarding the results produced by the inference engine. Therefore; the AI scope for the proposed intelligent-framework for ABACsh is illustrated in Figure 1. Modal logic is found to be the most appropriate logic to be used in AI as discussed by .
3.2 Logical-based agent architecture
Intelligence security is a fertile approach, as most existing security paradigms suffer from reactive and fragmented approaches . In a frequently changing infrastructure, deploying an agent-based mechanism will be an advantage . Modal logic is a candidate that supports a logical approach in artificial intelligence systems . The main component of a knowledge-agent is a Knowledge-Base (KB) that consists of a set of sentences expressed using formal logic, in addition to two generic functions that involve logical inference. The first function is known as TELL, and adds new sentences (facts) to the KB to provide it with the required information. The second function is known as ASK, and queries the known information from the KB to determine the next step. The process between TELL and ASK will end as soon as the desired action is selected. The interaction between these two generic functions is similar to the updating and querying in databases, as illustrated in Figure 2. When an agent program is called upon, it performs two main actions. Firstly, it will TELL the KB what it perceives. Secondly, it ASKs the KB what action should be taken.
Therefore, agent-based architecture is suitable to represent an ABAC model. The logical agent, furthermore, will be appropriate for the proposed modal logic scheme. Table 1 demonstrates how knowledge-based agent architecture can represent an ABAC system. The logical agent can be designed to represent an access-request state through a process of inference to derive a new representation of the access-request state that can be used to deduce required actions. The proposed access-control logic agent will be founded on knowledge-based agents, as this type of agent is logic-based .
|Components||Agent architecture||ABAC requirements|
|knowledge base(KB)||Background sentences||Predefined sets of entities, attributes and policy rules|
|To represent action(s)||The action is access-decision|
|inference system||Infer (i.e arrive to a conclusion via reasoning) hidden properties of the world to add new sentence to KB||New sentences are added each time an access-request is triggered which consist of a combination of attributes with the request operation|
|Infer based on the predefined sentences and the new ones to conclude with appropriate actions||Reasoning based on the attributes set and the policy rule-sets to conclude with an appropriate action (allow or deny) the access-request|
3.3 ABACsh conceptual requirement
Based on the analysis and investigations addressed an analytical study published by this chapter author in , the critical requirements in designing an ABAC model are listed below.
Req.1 ABAC model definition requires to identify the configuration points. Each point should be formalized via the proper languages. The configuration point indicates the necessary configurations to be accomplished via the ABAC model processing for computing the access decision. These points are known as functional points. It is more convenient to minimize the number of configuration points as they affect the system’s computational complexity.
Req.2 ABAC is identity-free. Therefore, identifications such as subject-id are not the main elements in access-decision processing.
Req.3 Avoid the creation of lists or groups in the design, as ABAC is intended to be flexible and able to cope with large enterprises.
Req.4 Context-attributes reflect the current system state, whereas environment attributes reflect the fixed system characteristics.
Req.5 ABAC is a multi-factor decision. Therefore, it enables fine-grained access
Req.6 There are no predefined privileges for subjects as the privileges are computed after an access request is triggered. Policy rules set in ABAC are specified based on attributes. As a result, the permissible operations will be defined upon access-request.
Req.7 The two basic functionalities in ABAC are attribute-assignment and rules-creation.
Req.8 Security principles such as Separation of Duty (SoD) must be enforced.
The enhanced attribute-based access control ABACsh fulfills requirement Req.1 by employing one main configuration point that is ABAC agent. This agent takes as an input, the access request parameters which consist of the subject, the object, and the operation (s, o, opr). Then it returns the access decision that indicates if the subject is allowed to operate on the object or it is denied. Compared to ABAC , which has four configuration points, the policy configuration here is reduced to one, as the proliferation of policy configuration points can introduce difficulties in policy expression and comprehension . For Req.2, in the Policy Decision Point (PDP), the decision-making process considers the subject attributes in addition to other attributes, instead of depending solely on the subject identity information. In Req.3, grouping is studied by HGABAC  to facilitate the addition of a hierarchy feature to ABAC.
However, grouping and listing will impede the flexible nature of ABAC [30, 42]. Therefore, permissions grouping and listing are avoided in this ABACsh. The decision calculation is based on four sets of attributes: subject-attributes, object-attributes, environment-attributes, and system-context attributes, all of which are taken into consideration in the proposed design to meet requirement Req.4. System context attributes have a special sensor to obtain an up to date system state to meet requirement Req.5. The privilege decision is calculated based on the attributes relation defined in the policy-rules. Therefore; the privilege value is returned after the access-decision is triggered, which meets the requirement Req.6. There are two core functions of ABACsh. The first function takes place at the initial system stage, where the attribute pairs (name:value) are created for the defined access control system entities (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 collection of attributes.
3.4 The proposed framework
The proposed intelligent framework for ABACsh has been published by this chapter author in . 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 collection.
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.
A prototype implementation of an extended nova access control model with an intelligent ABAC.
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)
The introduced PDP follows ABACsh by
Utilizing the attributes in access decision-making process.
Involving forward-chaining algorithm that works as logical reasoning for access decision processing.
Three experiments are studied to compare and contrast the extended ABACsh with the default nova-OpenStack access control model.
The Quality of Service (QoS) measurement is discussed based on response time as a performance metric.
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 . 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 . 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 . 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 . The keystone  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
In policy.json, the access policy consists of two main parts “<target>”: “<rule>” . 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.
|Known as||Forward reasoning (Data driven)||Backward reasoning (Goal driven)|
|Reasoning start with||A Set of facts to reach a goal (or hypothesis)||A hypothesis (goal) to reach the facts behind it|
|When applicable||If the goal is unknown||If the set of goals are known|
Many researchers avoid the Logic Theory Machine, which is based on forward-reasoning 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 . 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.
5.4 ABAC implementation in OpenStack
5.4.1 Enforcement architecture
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 rules.
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 architecture is divided into three components as follows:
ABACsh PIP: this is used to collect attributes information from the access 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 . 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 store policy rules in OpenStack
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 facilitate its implementation in OpenStack.
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 reasoning indicates if the access is permitted or denied.
5.4.2 Prototype implementation
The first stage of ABACsh deployment in Openstack is to be implemented on nova component. ABACsh PDP part will be implemented as a prototype.
Scope and Assumption.
IaaS access control tenant scope can be a single tenant , multi-tenant [54, 55, 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 feature.
OpenStack aids in deploying IaaS cloud. Figure 8 shows the deployed testbed in this chapter. It is installed in three machines using Ubuntu 16.04 LTS as an operating system and OpenStack Ocata the latest release (Feb2017). One machine is configured as a controller which provides OpenStack main server in addition to networking services (neutron), keystone, nova and glance. The Two other machines are configured as compute nodes where virtual machines are hosted. The machines specification is Intel Core i5–4460 CPU Processor 3.20GHz _ 4, 15.5 GiB memory, 235 GB Disk and 2 NICs cards. The testbed networking consists of two LANs: management network and data network. The management network traffics the Openstack service communication where data network connects the communication of the virtual machine. This IaaS is a private cloud where OpenStack services and the VMs are accessed by the LAN users.
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. 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
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’ ‘through curl command.
The extracted nova metrics from the OpenStack system via a command openstack quota show are considered as the object attributes. The attributes information is stored in JSON _le format
The nova environment attributes are extracted via the OpenStack command openstack hypervisor stats show. The attributes information is stored in JSON _le format
The context attributes are not implemented in this prototype but it is visible to be included via Telemetry OpenStack service
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.
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 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 . 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.
|Performance metrics element||Description||The applicable Access Control Component|
|Response time||The time required to process access request should meet the organization requirement||PEP, PDP, PIP, PRP|
|Policy distribution||If there exist a mechanism that can be used for access control policy distribution||PAP, PIP, PRP|
|Integrated with authentication function||If the subject and object can be associated with some identifications through an authentication function.||PIP|
|Key: Policy Decision Point (PDP), Policy Administration Point (PAP), Policy Enforcement Point (PEP), Policy Information Point (PIP), Policy Retrieval Point (PRP)|
5.4.4 Experiment content
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 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 engine.
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.5 Experimental results and discussion
Each experiment was run five times, and then the average value was recorded. Five scenarios were observed by increasing the number of requests from five to twenty-five as illustrated in Table 4. The request indicates an access control request from a user (subject) to access nova-resources (object).
|No. of Requests||Response time||Exp1||Exp2||Exp3|
Based on usability engineering [67, 68] The response time value can be within three categories: over 0.1 seconds will give the user a feeling that the system is reacting instantaneously, over 1.0 seconds will give the user a feeling of a delay but will stay uninterrupted, over 10 seconds the user will lose his/her attention and will search for something to work on till the computer responds.
Three time values has been recorded as illustrated in Table 4: real-time, user-time and sys-time. In this study, real-time and sys-time have a direct reflect on the performance analysis whereas user-time is reflecting the processing outside the kernel. The real-time shows the access control execution time in additions to the other OpenStack cloud processes that introduce some delay by blocking the process or introducing a waiting time. Therefore, this measurement will indicate the effect of our extended ABACsh nova to the overall OpenStack system.
The graph in Figure 10 compares the real-time for the three set of experiments. The increase is 0.05 seconds when the extended ABACsh nova employ forward reasoning in access decision processing as shown in Table 5 while the increase is 0.145 seconds when ABACsh uses twenty-four attributes in access decision processing. Therefore, there is an increase of 0.56% when attributes are added to the policy engine and 0.19% when the forward-chaining algorithm is added. Consequently, the increase in response time is negligible in Ref. to the usability engineering when the nova default access control is extended with part of the proposed ABAC enhancement.
|Experiment 2 - Experiment 1||Experiment 3 - Experiment 1|
On the other hand, sys-time gives the process execution only within the kernel regardless of the other tasks. Therefore, the time for the 25 requests dropped from 43.02 seconds within real-time to 2.09 seconds within sys-time during Exp1 which involve default nova access control. The sys-time comparison for the three experiments is illustrated in Figure 11. The results show a slightly better performance of 5.5% for extending the default nova access control when forward-reasoning has been utilized whereas an increase of 4% over the default nova when 24-attributes are used in the policy-engine as illustrated in Table 6.
|Experiment 2 - Experiment 1||Experiment 3 - Experiment 1|
From these results, the ABACsh shows an acceptable performance compared to the default OpenStack access control within nova service. This section demonstrates the enhanced attribute-based access control ABACsh performance improvement when attributes and forward reasoning algorithm are employed. It has been noticed that the performance improvement is liner in Figure 10 when only attributes are involved in access decision. Whereas in Figure 11 when forward reasoning is involved, an improvement in performance has been noticed. This indicates an opportunity of enhancing the IaaS-cloud security when logical reasoning and AI mechanism are involved in access control system.
5.4.6 Experiments limitations
The main aim of the experiments in this chapter is to study the performance improvement when attribute-based access control model is introduced into IaaS cloud. The experiment scale is limited to a private cloud in a LAN set-up. Therefore, the network performance metrics has not been studied such as the latency and throughput. The implementation in this chapter does not involve the PIP component of the access control, therefore only a simple forward reasoning algorithm has been deployed without knowledge update component. The used database for knowledge is written manually whereas the system should use an automated information collection method if PIP is implemented. One subject is involved in each experiment, therefore multi-access has not been investigated in this chapter. Multi-tenant study is a critical future work.
This Chapter is focusing on the problem of deploying access control in a dynamic environment. Access control is one of the information security principles where the system user access is controlled through an access policy. In the cybersecurity world where systems and devices are distributed in different locations, there is a need to have an access control model that is able to cope with a dynamic environment where new users with different privileges are joining and leaving the system.
This chapter is proposing to deploy an enhanced version of attribute-based access-control named ABACsh. This model is deploying knowledge base category of AI. A proof of concept is implemented in the cloud computing environment to measure the performance and the visibility of such a deployment.