Dan Gradl [http://community.jboss.org/people/dgradl
] created the discussion
"Get something started with XACML - Requirements Discussion"
To view the discussion, visit: http://community.jboss.org/message/637330#637330
I have recently begun participating in this project and I noticed that the discussion on
XACML has been fairly quiet, so I thought I would kick off some discussions to see what
the interest level is, see what requirements people have considered, see who is using it,
and maybe create some interest in it from others who don't know what it is or have
looked at it and found it lacking something.
I'm going to use this post as a teaser for topics I'm going to write about and to
provide a summary of links to them. However, I would also like people to respond on this
thread, if there is something I don't mention, or to provide other general thoughts on
the subject of XACML.
In a past role I architected and implemented a fine-grained access control system on a
large scale using XACML. This was built on the SunXACML library which is now at the core
of JBossXACML (since the Sun community died off). The library left a lot to be desired
for such an implementation, and it was our desire actually to purchase a vendor product
because of those gaps. However, due to various reasons this purchase was delayed and we
fell back on this library and filling gaps ourself to provide at least a portion of the
capabilities required. I am going to share some of the learning from this experience on
various aspects of a complete access control solution based on XACML. I believe that for
JBoss XACML to get more adoption and interest and to provide an alternative to the
commercial products it needs to address some of these concerns. Don't take this as a
critcism of what's here nor me just complaining (I intend to help build new features,
if there is some interest).
Here's some of the key considerations in its implementation that I intend to write
about and start discussions on:
1. Performance - Access control is a cross cutting concern, it is pervasive throughout an
application (or an enterprise). If you are controlling access to services it's going
to be checked on every service invocation, if you are controlling access to data it will
be called whenever its accessed. As such it needs to have a low overhead and be able to
scale well. One thread is started about caching, but there is more to consider.
2. Enforcement - In the XACML logical architecture, JBossXACML pretty much provides just
the PDP, some context handling, and hooks to PIPs. Enforcement will vary greatly
depending on what resources you are protecting, but is there anything generic it could
3. Administration - Policy writing is difficult, complex, and has a great impact on item
#1. There is no open source Policy Administration Point (PAP) that I am aware of, but
this is essential for ease of use and adotion. This may also include the need to test a
policy that was created.
4. Auditing/Reporting - Access to resources is a major security concern so of course
auditors and it security professionals and others need to know who has access to what
5. Deployment - Is the entire XACML stack (PEP, PDP, PIP, PAP) on one box alongside the
application using it or is support for more distributed deployment topologies required?
6. Resource management - keeping an inventory of things you are protecting, seems simple,
sounds like administration, but there are some gotcha's I'd like to share.
7. Best practices - this'll be a catchall for some random things
Reply to this message by going to Community
Start a new discussion in PicketBox Development at Community