Authorization Performance Myth Busting

It’s a common misconception that XACML authorization systems perform poorly by default because they are XML-based. While it is true that XML systems can be slow, XACML product vendors have many techniques at their disposal to address performance concerns. Keep in mind, however, that every application and every deployment has its own performance considerations and will require individual analysis. Therefore, this post lists the main bottleneck points for performance and discusses some alternatives for each.

Policy Retrieval: When resources are accessed, the authorization system must find the right policy to evaluate. If the PDP is going to the database or file system to retrieve policies during runtime, you can degrade response time considerably. An alternate approach is to load all policies into memory at PDP startup. XACML policies are not excessively large, so memory usage is not an issue.

Policy Matching: Policy modeling and structure directly impact how quickly a PDP can find the right policy to evaluate. Application access patterns must be studied to determine the most efficient policy structure for rapid matching and evaluation.

Attribute Retrieval: Attributes are the lifeblood of an XACML system and their inefficient retrieval can contribute to poor application performance. Attributes can be incorporated into the authorization process from many entry points: 1) the PEP can gather attributes from the user session or service request, 2) the PEP can retrieve additional attributes from enterprise systems and repositories before making the access request, 3) the PDP can retrieve yet more attributes from similar sources before evaluating a rule, 4) you can have all of the above in a given scenario.

If multiple attributes are sourced from the same repository, they can be retrieved with one call, instead of making a call for each attribute. Caching can also be useful to retain in storage attributes that are frequently used by the PDP. Attribute retrieval can also be triggered during policy matching, allowing the PIP interface to “look ahead” for attributes once the PDP knows which policy will be matched. Finally, if an attribute repository is known to be costly to fetch, it should only be utilized in policies that are infrequently called.

Decision Caching: In certain cases, the PEP can cache access decisions so that the PDP does not have to be invoked for each access request. This technique is useful where similar requests would result in the same outcome due to the structure of policies or due to the nature of the request.

Multiple Requests: It is quite common that multiple decisions must be processed for a particular request, such as when a user is requesting access to a list of resources. Such requests will be more efficient if they are processed as a “multiple request” instead of a series of individual requests because there is less transport overhead and the PDP can optimize the request knowing it is for the same subject (user).

This reminds me that I recently heard a comment at an industry event where a vendor stated, “If you are rendering a web page with 50 authorizations in it, it is not possible if you do a SOAP call for each authorization.” Well, of course that is a correct statement but not exactly helpful to prospective customers that are considering deploying XACML authorization. This is precisely a case where multiple requests should be utilized and where more suitable enforcement points should be considered to avoid the SOAP overhead.

PDP – PEP Interaction: It is possible to implement a closely coupled PDP-PEP in order to reduce transport overhead. In addition, authorization systems should be able to support several types of transport mechanisms, such as web service, RMI, in process, or others. In extremely performance-sensitive cases, the PDP and PEP should be able to communicate via in-process calls for ultimate response times.

PDP Features: In general, the PDP is stateless, making it very easy to create several concurrent instances. These instances may run on separate threads (and thus leverage multi-core architectures) and/or on separate hosts to increase the capacity of the authorization system.

What have you done to address performance concerns??

Photo credit:

Explore posts in the same categories: Performance, XACML

4 Comments on “Authorization Performance Myth Busting”

  1. […] The modularity and flexibility of the architecture will impact greatly performance as Gerry Gebel explains in one of his myth-busting posts on XACML. […]

  2. […] XACML Performance In a previous post discussing XACML performance myth-busting, I described several areas in an XACML authorization […]

  3. Chi Says:

    One problem I need to solve is user searching/browsing in a repository. For example, if the repository has 100k+ assets (or even millions), and we employ a faceted search engine like Apache Solr, how can we get around this performance problem? Note that Solr faceted search requires looking through all the assets in the repository via its indexes? Even without Solr, if you just want to offer paged search results, you will still need to iterate through the assets. Is the answer simply: no it cannot be done?

    • ggebel Says:

      Chi – you are right that querying whether a user has access to large numbers of assets is a bit challenging for XACML-based systems. However we have an interesting way of addressing this and you can contact me at gerry-at-axiomatics-dot-com to learn about it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: