Analysis of an Access Control System for RESTful Services

Abstract

RestACL is an access control system for RESTful Services and describes a policy specification language as well as an architecture that shows how access control can be integrated with RESTful Services. The language is based on the ideas of the attribute based access control model allowing rich variations of security policies with a great diversity of access rules. Its structure utilizes the concepts of REST enabling a quick identification of security policies that have to be evaluated in order to find an access decision. This work analyzes the requirements on such a language and gives a brief introduction over the RestACL concepts. Evidence is provided that the language enables the implementation of an appropriate and efficient access control system that fulfills the requirements.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Attribute Based Access Control (ABAC) is a very generic model that allows expressing rich variations of security policies [11]. Therefore, it is a suitable candidate to become the access control model in environments that ship with great diversity of access rules. ABAC controls access to objects using arbitrary properties of entities. For example, a subject might have a property IP address and a document a property privacy level. A rule could restrict access in a manner that the conditions the documents privacy level is secret AND the subjects IP address is in the range of 10.0.0.1 to 10.0.0.255 AND the access method is read must be fulfilled.

Representational State Transfer (REST [5]) defines constraints on distributed systems enabling high-performing and scalable Web Services. This work analyzes and evaluates the RestACL language. A brief introduction into the language is given. An architecture describes how a RestACL system can be integrated in RESTful environments and how it can enforce access decisions. We explain which design characteristics of RestACL enable high-performing and scalable access control. Evaluation is done using two methods: formal performance analysis and experimental testing.

The remainder of this work is organized as follows: a brief introduction to the RestACL syntax and semantics is given in Sect. 2. We analyse the language, the architecture and a reference implementation in Sect. 3. In Sect. 4 we show the efficiency of our approach using experimental testing. Finally, we refer to related work in Sect. 5.

2 RestACL

The REST Access Control Language (RestACL) enables protection for resources depending on various attributes. This section shows the requirements to such a language and an architecture that describes how an RestACL system can be integrated in RESTful environments.

2.1 Basic Architecture

Fig. 1.

Access control architecture [8]

Figure 1 shows the components in an RestACL access control architecture. A RESTful Client application sends resource requests to a Server. The Server must serve the request including the execution of application and access control logic. Therefore, he formulates access requests and passes them to an Access Control System which computes the access decision depending on attributes given in the access request, attributes collected from an Attribute Provider, the Domain and a set of polices. The Domain and the Policy Repository store data objects that determine the security policy. While the Domain is used to map between resources and policies, the actual policies are located in a Policy Repository. Because a RESTful Service is responsible for the security policy of its resources, the Server can modify the mapping between resources and policies (the Domain) as well as the policies themself to change the security policy. This enables the adaption of frequent changes to the security policy in an automated fashion. A brief overview over the components is introduced in [8].

2.2 Syntax

In this section we will give an overview over the syntax of RestACL. Note that only a brief introduction is given that explains the main ideas of RestACL. A complete description that includes more details like the application of URI query strings and URI templates can be found in [8].

Domains. Resource orientation and addressability are core concepts of REST. A RestACL Domain takes advantage of these concepts and structures the security policy in a resource graph. This enables a key-driven ABAC mechanism with the resource address being the key. The benefit of utilizing resource orientation compared with XACML (discussed in the Sect. 3) is that language interpreters can quickly identify the subset of policies that needs to be evaluated for a single access request. In addition, this approach allows an easy integration with well established modeling tools like Swagger¹. These tools usually also employ a resource graph. Furthermore, it facilitates the definition and increases the lucidity of resource oriented access policies (if written or read by human users).

Listing 1 shows an example of a Domain. The Domain is used to do the mapping between resources and policies and administers nested resources represented by their path. The given example expresses the following: access to the user list resource using the GET or PUT method is determined by the policy P1. DELETE access to the user resource with id 1 is determined in policy P2.

This key-driven mechanism allows to utilize well performing data structures. Hash tables are an ideal candidate for such an algorithm because they have offer short search times and perform extremely well in practice [3]. We will show in Sect. 3 that the utilization of a key-driven approach also removes dependencies that interfere scalability.

Policies. RestACL is build on top of the ABAC model because it should support a great diversity of access policies. Therefore, the Policies that are referred from the Domain declare Conditions based on attributes. For example, a Condition might demand a subject attribute clearance or a resource attribute privacy level. Therefore, a Condition has a Function that compares Arguments. Arguments either refer to attributes in a request or they are fixed values. Attributes are demanded from an access request using a Category and a Designator. Categories are used because different entities in an access request might specify the same properties.

3 Comparison with XACML

We compare our approach with the eXtensible Access Control Markup Language (XACML [1]) because XACML is the de facto standard for ABAC. XACML security policies are organized in a tree structure of Policy Sets, Policies and Rules. Each of them has a so called target that expresses attribute conditions. XACML evaluates a Policy Set, Policy or Rule, if the provided attribute values satisfy the target conditions. From a simplified point of view XACML can be seen as a decision tree build by targets [12]. This tree is evaluated in a top-down fashion to find applicable Rules. The access decision is computed in a bottom-up fashion. Therefore, each Policy Set and each Policy uses a so called Combining Algorithm to determine the resulting decision. For example, if one Rule permits access while another Rule prohibits access and both Rules are applicable, the superordinate Policy or Policy Set uses a Combing Algorithm like PermitOverrides or DenyOverrides to determine the resulting decision.

Fig. 2.

A XACML security policy protecting a web resource

Figure 2 shows a structural example of a XACML security policy. The target of the Policy Set checks an attribute of a resource: the URI. If the URI is equal to the specified value, the Policy Set is applicable and the subordinated Policy is evaluated. The target of the Policy addresses an action attribute: the access method of the resource request. If the access method is equal to GET, the Policy is applicable and the subordinated Rule is evaluated. The target of the Rule addresses an attribute of a subject: the name of the subject. Note that target conditions are quite flexible using a variety of comparison and logical operators. The conditions in XACML do not have to be REST oriented as in the example.

3.1 Analysis of XACML

In larger applications many resources of the same type may occur. For example, an application might serve multiple users identified by the paths /users/$1$, /users/$2$, ..., /users/$n$. All user resources might have different access conditions. Handling all these conditions within one superordinate Policy Set or Policy would be inefficient because a XACML engine would have to sequentially compare all paths during the request evaluation. That would lead to an average target comparison number of $O(n)$ with $n$ being the total number of users. Efficiency can be increased using a transformation into a balanced binary tree of Policy Sets as indicated in Fig. 3. By using the described tree, the identification of the requested resource can be done within $O(log_{2}(n))$.

Fig. 3.

A binary tree of Policy Sets

In some previous work we have shown that the transformation into a binary tree of Policy Sets is the most efficient way to implement access control for RESTful Services with XACML [7]. The performance optimization is capable to reduce processing times for access requests dramatically, but additional Policy Sets must be added that cause an increased memory consumption. Instead of $n + 1$ Policies or Policy Sets (the superordinate Policy Set plus a Policy or Policy Set for each resource) the binary tree has

$$\begin{aligned} n + \frac{n}{2} + \frac{n}{4} + \frac{n}{8} + \cdots + 1 = \sum _{i=0}^{\log _{2}(n)} \frac{n}{2^{i}} \end{aligned}$$

(1)

Policies and Policy Sets. From (2) we can derive that the number of Policies and Policy Sets approximately doubles for a large number of resources.

$$\begin{aligned} \lim _{n\rightarrow \infty }{\sum _{i=0}^{\log _{2}(n)} \frac{n}{2^{i}}} = 2n \end{aligned}$$

(2)

That means, the optimization to reduce the average processing time from $O(n)$ to $O(log_{2}(n))$ ships with a doubling of memory consumption.

Now imagine an online photo community with an addressing scheme like /users/$\{user\_id$}/albums/$\{album\_id$}/photos/$\{photo\_id$} and 10 users. Each user has 10 albums containing 10 photos resulting in a total of $1110$ resources ($10$ users, $100$ albums, $1000$ photos). Because processing resources sequentially takes too much time, we transform the security policy to quickly identify the requested resources as indicated in Fig. 3. From (2) we know that the amount of Policy Sets doubles which means we have $2220$ Policy Sets just to identify the requested resource. A security policy for a resource should address at least one access method plus several other conditions that are compared against the attributes of an access request. If we expect an average of two declared access methods handled in Policies and five Rules that determine the access decision, than we have $2220$ Policy Sets, $2220 * 2 = 4440$ Policies and $4440 * 5 = 22220$ Rules. That means, the resulting number of targets is $2220 + 4440 + 22220 = 28880$. Our tests showed that a security policy protecting such an application has a file size of about 22 MB. If this security policy is instantiated using the XACML engine Balana², the total memory consumption is about 130 MB. We denote the number of methods that are stated for a resource as $m(r)$ and the average number of rules that have to be applied to a resource request as $p(r)$. With these functions the optimized processing time $t_{1}$ for an access request to a resource r is:

$$\begin{aligned} t_{1}(r, n) = c_{1} * log_2(n) * m(r) * p(r), c_{1} = const. \end{aligned}$$

(3)

Besides the increased memory consumption, the performance optimization has two more drawbacks. If new resources and therefore new Policies or Policy Sets are added, the binary tree must be balanced. Balancing comes along with high additional costs [3] which should be avoided for frequently occurring events. In addition administration efforts increase dramatically if the security policy is managed or debugged manually because of an intransparent set of policies. An automatic transformation by the XACML system to an efficient resource oriented form is not reasonable, due to the wide scope of conceivable target conditions.

3.2 Analysis of RestACL

The RestACL system can use a hash table to identify resources due to its resource oriented design resulting in search times of $O(1)$. In consequence, the most significant part of processing time is related to the evaluation of attributes. If we assume again that two access methods and five rules/policies per access method are declared, the complete evaluation of an access request is reduced to an evaluation of at most ten elements. This is a huge reduction compared to the potential 28880 elements for the same security policy written in XACML. The processing time $t_{2}$ for an access request can be computed as:

$$\begin{aligned} t_{2}(r) = c_{2} * m(r) * p(r), c_{2} = const. \end{aligned}$$

(4)

Comparing (3) and (4) shows a dependency on $n$ in (3) that is not present in (4). This makes RestACL a much better scaling solution than XACML.

RestACL has two characteristics that reduce also the memory consumption substantially. Firstly, generic ABAC solutions have to reformulate domain specific data using policy sets, defined already elsewhere as REST service definition. RestACL reuses domain specific data.

Secondly, the differentiation between the mapping of resources to policies and the policies themselves makes policies much more reusable, modular and readable, because they are referred instead of explicitly written. Only the reference occurs multiple times. A functionally equal policy that protects the resources as described in the previous section therefore has a file size of only about 1 MB and instantiated with the reference implementation a size of about 10 MB.

4 Experimental Results

The major drawback of XACML is that processing times for access requests depend on how the security policy is written [12]. We compare the RestACL reference implementation with an performance optimized version of XACML as described in the previous section.

Table 1. Processing time and memory consumption for optimized XACML and RestACL

Table 1 lists the average processing time for an access request and the memory consumption. As one can see, the processing times for both approaches remains at a constant level. For the XACML implementation the reason is that there is an initialization overhead that is great against the optimized processing time of the access request. For RestACL the reason is the application of hashing to identify policies that have to be evaluated. The price for an increased XACML performance can be found in the memory consumption column. The RestACL implementation can support 100 times more resources with a memory consumption in the same dimension when compared with XACML.

5 Related Work

Several approaches try to optimize XACML performance [10, 12]. The approaches have in common that they optimize an generic ABAC solution without utilizing the constraints that are given in dedicated environments. Policy implementation and management can be very challenging [4] and can be simplified with a well structured policy. The drawback of this approach is that the already high memory consumption of XACML is increased again.

The need for an efficient access control system for Web Services is proven by research activity in this area. But the majority of approaches targets specific use cases and can not offer the support for a great diversity of access rules because they rely on different models other than the attribute based model. A role based approach to protect RESTful Services is described in [2]. Access matrices are used to create a mapping between subjects and resources in [9]. We created a first version of the RestACL language that targets ABAC for REST in [6]. In this approach we utilized resource orientation to reduce processing times of access requests to a logarithmic order and to make the approach more intuitive for REST experts. We proposed a second version of the language as a draft including details of the implementation but without a detailed analysis in [8].