0 Replies Latest reply: Dec 3, 2011 3:54 PM by Dan Gradl RSS

XACML Administration

Dan Gradl Newbie

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.

 

This post is to discuss the Policy Administration Point (PAP) portion of the XACML model.  

 

In terms of what a PAP should do it's fairly straightforward, its a tool that helps you to author and manage your policies, rules, and policy sets.  If you are going to use RBAC, it probably also provides the mechanism to define the permissions associated to a role.    It may possibly deal with user to role assignment or user to permission assignment, but these may also be handled by other tools.

 

There are several reasons why a PAP is important (and lacking in picketbox):

1.  The XACML policy format provides a powerful tool to define complex policies and rules in the security space, but they can also be difficult to right.  First and foremost a PAP helps to author these policies without specialized skills.

2.  The same flexibility of XACML means that you can achieve the same effect several different ways.  For example, you can grant access to action=execute, resource=myService, by creating a policy that target's this action/resource with an empty rule=permit; you could also have an empty target (would match everything), and a rule that looks for these values.  There are advantages to doing things a certain way (targets should allow indexing and locating policies more quickly).  So a PAP enables policies to come out in a predicable way that then the decision point can take advantage of in optimized performance.

3.   As you scale up the number of things you protect with XACML policies... you will wind up with many many policies and just managing the sheer volume (organizing, finding them, etc.) can become unwieldy.

4.  It helps with auditing/reporting

5.  If your architecture calls for distributed PDPs it can aide in deplolyment

 

I have also observed a secondary piece of administration that is less obvious.   In some of the more complex rule situations, you may have a policy and then you may have a piece of related external data that may need to be managed.  For example the policy may be that a user can only access the system from their assigned terminal, the mapping of user to terminal (e.g. IP address), may be an external lookup, rather than authoring unique policies for each user.  So you may need a mechanism to manage the policy rule and also a way to adminster other related data.

 

You may also need to consider the usability of the tool for different types of people.  You may have dedicated adminstrators that author policies and manage more complex aspects, and you may have delegated adminstrators who need a simpler interface and manage a smaller subset of things.