This is a post in a serious of discussions I am starting to get some discussion going on XACML. I led the implementation of XACML on a large scale using the original SunXACML libraries as the PDP and I am sharing some of my insights as a way to elicit some requirements on the further development of XACML. The original post and index to these discussions is http://community.jboss.org/thread/175091?tstart=0.
In this thread I want to share some thoughts and insights on the topic of performance in XACML and kick off some discussion on this topic. Primarily I'm addressing the PDP component here as it is the most complex runtime component in the XACML logical architecture.
1. Memory utilization
In our application, access control was applied at the field level. Users may be entitled to see data or not see data based on the roles. Whether this much fine-grained control is a good idea or not may be a topic for another discussion. I'm sure that there are applications that will make a similiarly high level of XACML requests. What we observed was that SunXACML created a lot of temporary instances of objects. In other words they were created for the purpose of processing the request and then discarded. The result of this was not running out of memory, but it did cause garbage collection to be run frequently which impacted overall performance. The version we used was a bit older than the one now in JBoss, but I do still see some similar object creation that may be unnecessary for processing. Secondly we made the problem worse by wrappering SunXACML. Our motivation for this was to provide an abstraction layer so that it could be swapped for another PDP in the future. But it actually didn't help that (we piloted using a commercial PDP) every request required creation of a "MyXACMLRequest" and converting it to SunXACMLs. In PicketBox, JBossXACML has a similar function and I'm afraid it may be worse since this is done by a set of JAXB conversions, rather than just a "manual" object mapping. I don't know until some profiling is done, but this is one area of tuning I suggest. But again, I thought the same thing was a good idea, so I'm not critizing the JBossXACML team for it, but we definitely saw this eventually being a bottleneck and removed the abstraction.
2. Execution speed
All of the algorithms in the PDP engine need to be as fast as possible. SunXACML has been around awhile, it was written as one of the first reference implementations of XACML (as far as I know) and I think that a fresh look at it with some XACML learning under the belt would yield better results. However, even if you just stick with the module as is, there were certain aspects such as conditions and functions that could be done more quickly.
3. Policy writing
One of the biggest impacts to performance had to do with how policies are written. The XACML policy model allows you to achieve the same effect multiple different ways, some ways are processed more quickly than others by the SunXACML engine. The targetting also does not do any sort of indexing or caching, so it essentially has to go through all of the policies until it finds a match and depending on the combining algoritm it may stop when it gets to the policy or not. If for example you use a policy permission set (from the RBAC profile) with a set of policy reference ids, and the target matches the last reference in that list it goes through all to reach that (more frequently used resources at the top of the list helped). Another dev team with less experience writing policies wrote a set of terribly inefficient ones that became a huge bottleneck. Anyway, there are a couple opportunities here... one is that you can improve how policies are processed with like a more efficient target matching algorithm or target match caching (already a JIRA task), the other thing is that having a PAP that creates policies for you in the most efficient manner saves a developer having to work out the best way to write the policies each time.
4. Deployment topology
This one is pretty obvious, but the topology of the XACML implementation can influence its performance. You could have a PEP access a remote PDP which has PIPs that access data from other sources (LDAP, RDBMS, etc).
5. Caching
Caching can help in some scenarios see the other discussion forum on this topic.