This blog entry is a snapshot of the paper “Optimizing Access Control Performance For the Cloud” published in the The 4th International Conference on Cloud Computing and Services Science, CLOSER 2014.
Cloud computing is synonym for high performance computing. It offers a very scalable infrastructure for the deployment of an arbitrarily high number of systems and services and to manage them without impacts on their performance. As for traditional systems, also such a wide distributed infrastructure needs to fulfil basic security requirements, like to restrict access to its resources, thus requiring authorization and access control mechanisms. Cloud providers still rely on traditional authorization and access control systems, however in some critical cases such solutions can lead to performance issues. The more complex is the access control structure (many authorization levels, many users and resources to protect); the slower is the enforcement of access control policies. In this article we present a performance study on these traditional access control mechanisms like XACML, which computes the overhead generated by the authorizations checking process in extreme usage conditions. Therefore, we propose a new approach to make access control systems more scalable and suitable for cloud computing high performance requirements. This approach is based on a high speed caching access control tree that accelerates the decision making process without impacting on the consistency of the rules. Finally, by comparing the performance test results obtained by our solution to a traditional XACML access control system, we demonstrate that the ACT in-memory approach is more suitable for Cloud infrastructures by offering a scalable and high speed AC solution.
Deploying XACML on a Cloud Platform
XACML is a declarative AC policy language implemented in XML and a processing model describing how to evaluate authorization requests according to the rules defines in policies. It allows for the definition of AC but also usage control rules through obligations. This language is very expressive and can be used to define a lot of different kind of policies. The choice of this language was due to the completeness of its expressivity for access control rules. We can define many AC models (like RBAC, ABAC, UBAC , etc.) with this language. It has a good flexibility for defining rule conditions. Due to the diversity of AC models used in different cloud platforms, we opted for XACML as a suitable standard to express AC rules.
This language is hierarchically structured and each policy contains a set of Rules composed by these elements:
– Subjects: who can access the resource?
– Resources: what are the targeted resources?
– Action: what is the action that must be executed on the resource?
– Environment: what are the environmental conditions that must be fulfilled by the requester before getting access to the resource?
The decision whether an access is granted or not is taken at the rule level. Each rule defines an Effect, which can be Deny or Permit.
We propose the XACML engine architecture depicted in Figure 1 as an integration architecture to the Cloud infrastructure.
- Cloud User interface: UI layers provided by the cloud as a service or as a platform feature. This cloud layer offers an IDM function to manage the user identity and authentication features. A user can create accounts, can chose to authenticate via traditional login password or Certificate based SSO systems. Through this UI the user can access to the different services and resources offered by the cloud. The identity (or role) of the user and her access request are collected at this level in order to be exploited by the PEP (Policy Enforcement Point) of the XACML engine
- XACML Engine: it is deployed in the cloud a service or as platform functionality (in this paper we chose to deploy it as a service). It offers the traditional functionality defined by the XACML specifications: PAP (Policy Administration Point) to manage the policy repository, PDP (Policy Decision Point) that evaluates the user request, and the authorizations contained in the policies, PIP (Policy Information Point) that provides external information about the user profile, and the Context Handler that coordinates all the previous components.
- Cloud resources: we connected the resource manager of the XACML engine to the different resources provided by the cloud infrastructure (database, services, VMs, etc.) in order to associate a user request with the requested resources . These resources are only accessible if the PDP evaluates positively the user request.
This deployement architecture is then deployed on the SAP HANA Cloud platform to perform the tests.
Using Acess Control Trees to Optimize the Policy Enforcement Process
The main issue with XACML is the complexity due to its high expressivity. This implies complex and long policy evaluations. In order to optimize these processes, we decided to implement a solution based on AC trees (ACT). The ACT is a concept based on aggregation. The use of pre-processing to aggregate privacy policies into the ACT will allow performance efficient AC check on mass of data. We can represent the aggregate AC information into a tree. The tree data structure has two key advantages for us: firstly, it provides a simple view of the AC structure; secondly, it facilitates the application of hashing techniques on a tree for efficient data search functions. This hashing technique will allow us to use an emerging database class (NoSQL) in order to improve further the already good performance of an ACT implementation in a relational database.
In this model, only accessible data objects are available. If the access to an object is denied, it will not appear. Following this model, our ACT contains only permitted data objects. If the data object cannot be accessed it will simply not appear. For this reason we call this tree the “Permit Tree” (PT). The AC tree or PT can be represented as follows:
The PT (the same procedure can be applied for the Deny rules thus obtaining a Deny Tree), represented in the prevuious figure, is structured in three main levels: The first level contains the list of authorized subjects (or users, or roles, etc.) declared in the XACML policy repository. The ANY subject ID is used for objects that are accessible to all users with no restrictions. The second level represents the different actions or operations that can be executed on the data. If the list of actions is undefined, there is also an element Any (Action). The third level represents the different types for data objects. Subsequently, the fourth layer contains a list of accessible data object IDs. The layer order (in the example subject, action and resource) can change according to system requirements. For example the first level can be the ID of the object. In that case the selection is made on the object to be accessed, for which one gets the list of authorized users.
In our performance testing we copared three cases: One traditional XACML engine running on SAP HANA Cloud (in-memory), one ACT based XACML engine running on an SQL DB (Derby) load in memory, and a last one also ACT based XACML engine but running on relational hash tables in a NOSQL DB (Also load in memory). In the test scenario we take the workst case where we have a different AC rule per protected resource (called PII or Personal Identifiable Information).
Below the results:
At 2000 data object, the Derby version is 2428x faster than traditional XACMLone, and the NOSQL version is even 16998x faster. The difference is important since the XACMLbased solution has to explore a complex structure of XML and objects representing the policy rules in order to match the applicable policy with the context of the request. This is more expensive in terms of processing time than a DB SQL query execution or a Hash function call.