Dan Gradl [
http://community.jboss.org/people/dgradl] created the discussion
"XACML Performance"
To view the discussion, visit:
http://community.jboss.org/message/638433#638433
--------------------------------------------------------------
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
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.
--------------------------------------------------------------
Reply to this message by going to Community
[
http://community.jboss.org/message/638433#638433]
Start a new discussion in PicketBox Development at Community
[
http://community.jboss.org/choose-container!input.jspa?contentType=1&...]