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 provide here?
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
We have always used our xacml engine primarily in conjunction with providing services to containers in the JBoss Application Server and upstream projects. So we have never really gone beyond to look at enterprise features for our xacml stack. I would definitely support the addition of xacml goodies in a separate project so that the core xacml stack is what it is right now.
Currently the XACML project provides the core functionality and the PDP. The PEPs are essentially in the integrating projects such as JBoss Application Server etc (web, ejb containers). The XACML project is a lightweight project that does a few things very well.
If we want to add some of the enterprisey things, I would suggest we create a complementary project under the picketbox umbrella and add those goodies there. That way, people who are looking for a core xacml engine can use the xacml project and people with enterprisey standalone xacml capabilities - can get the core xacml project + enterprise project together.
So upstream, PicketBox XACML can be used to protect my web resources or my EJBs, right? But still the end user is the one who hooks it in and writes policies and configures it and all of that right? Unless the policies are prewritten and provided by those upstream projects, there is at least one pain point to using this project I would say. If all this was used for was to protect various container resources, wouldn't you still need to address some of the concerns I am referring to?
Performance is still important
Policy writing is still painful (wouldn't a PAP be useful?)
Might someone still want to be able to report and audit on the access granted to those resources?
Isn't there still a set of resources to manage? (EJBs, Servlets, etc)
I don't suppose XACML is a mandatory part of the JBoss AS, but it is there in case you need to provide fine grained access control to resources. Still these things would make it easier to leverage for that purpose.
Yea I can also see these capabilities also enabling a standalone XACML platform that could be used outside of JBoss, and a few things I mentioned may only make sense in that arena.
Before we spawn a project though, I guess we should see if anyone is interested in these things.
Having given this some time to sit out there, it seems that my thoughts haven't generated any discussion at all. I guess there isn't a ton of interest in the XACML piece of this.. or do you think it is being used more than it seems, Anil? I think it is understandable though.. a PDP alone just isn't too exciting, it's really one part of an overall access control solution and writing policy files isn't a whole lot of fun either. I feel like a more complete XACML solution, would have a great deal more use. I'm just not sure if there is even any interest level for this in PicketBox or even in the JBoss community... based on the lack of feedback so far I guess.
Dan, in reality XACML is still years behind the adoption curve. The industry is still getting to terms with authentication. I am hoping that there will be emphasis on access control in a couple of years.
There is adoption of xacml among university research and other security focused entities.
The need of the hour is domain based editors that can be used to craft the xacml policies. Rather than crafting xacml policies by hand, GUI should be employed depending on domains to craft the policies.
I obviously agree on the need for a GUI policy administration point. There's too much work involved to implement xacml based access control without it. I also think that people won't see value in XACML when all that is there is a decision engine. There are commercial XACML implementations out there... they don't neccessarily even promote the XACML name, but they are full solutions and they are obviously seeing use in various places such as in the finance industry. Like I may have mentioned to you before, I implemented XACML at a large bank and we looked at the products because there was no open source alternative, and building and maintaining something like that ourself didn't make sense. I'd definitely be interested to work towards creating a more complete open source XACML solution. It would seem, however, that given the low interest it would end up being me running solo on it. At least until it had enough features to be more interesting to others.
Hi, Dan, Anil,
Stumbled on to this topic late in the thread but it definitely sounds very interesting and useful. I am new to XACML and so it will be very helpful to have some links to how to configure a web/ejb container (as Anil mentions) to use XACML. A pointer to an example will be great.
what I see is that there are COTS solutions, that are conceptually not much further on the "adoption curve"... We need a good pap implementation that is tailorable to the domain experts, to their vocabulary. The role of the "policy modeller" is not very well described up to now. It is not an IT admin, it is more the Service Manager. So we build a kind of eclipse rcp app that consumes a dsl to generate XACML and distributes it on a set of preconfigured pdps...
May be requirements analysis helps us to understand, why the standard is still not widely used.
In the XACML impl I worked on it the thought had been that the policy modeller would be part of the info security team, even in a PAP this takes some specialized skill. However without a PAP it fell to developers to craft the XML policies. There was also a need to delegate control over some of the details to a variety of different people (business users, customer power users). They wouldn't write policies per say but have control over some of the "constraints" defined by the policies and the UI would be simplified greatly to where it needed little to no training/additional skill.
I like your thinking on the DSL.. that idea had been bouncing around in my head as well. Although, I was thinking it could directly drive the PDP... I see the value in XACML being the data and logical model and not so much in the fact that it uses XML. That is to say I don't see any particular value in generating XML other than the fact that the current PDP drives off of it. Many of the COTS drive off a database representation of the entities. Also, I think a DSL may be a good interim step in creating a usable PAP, but that ultimately it needs a UI on top of it for easiest learning curve.
the policy modeller as part of the info security team- interesting point. I thought the possible advantage of XACML -besides from interop- is the ability to change and adapt existing access rules while the system is running, i.e. is already developed. So if we restrict the ability to change the rules to specialized people, it tends to get adjusted one time or twice in the lifecycle of the software. It is not much different from hardcoding the rules in the software. If we really want to use the advantage, we need to enable the business guys to understand what happens.
But I haven't seen such a system working. So as you describe it - this organization has some procedure to work with "meta-rules" and then they give the order to change to the security team. The question is, how often occur changes ?
But even if you have specialized people- the policysets get big and complex and so the GUI should really be able to structure them according to different perspectives (like eclipse perspectives) There might be an application perspective, an organization perspective, a dictionary. It is a special kind of rule management system. There have been various attempts to write good editors, see http://www.tfgordon.de/publications. But it is worth a try.