Analyzing Identity

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: http://bit.ly/aXnTlb

This entry was posted on April 30, 2010 at 9:36 am and is filed under Performance, XACML. You can subscribe via RSS 2.0 feed to this post's comments. You can comment below, or link to this permanent URL from your own site.