Whilst at the Burton Group’s Catalyst 2009 conference, I ran into Prateek Mishra from Oracle who told me somewhere between the lines of our conversation that a new XACML API that has just been posted to the OASIS XACML TC. It was a “soft launch” that was announced at the Kantara meetings on Monday at Burton Catalyst (which very unfortunately, I missed). When Prateek mentioned it to me, it stopped me dead in my tracks, because I find it really significant news – a very important step towards flexible access control policy based on XACML. Before I get in the details, let me step back a bit and explain what this is, why I find this so significant and why it got me so excited.
XACML, the eXtensible Access Control Modeling Language is an XML-based standard for authorization and access control. It is based on the Attribute Based Access Control (ABAC) model that is hailed as the next generation of access control models. According to many, ABAC will ultimately replace RBAC (Role Based Access Control). Instead of only using a role as the determining factor whether to grant access or not, many attributes can be used. Of course roles can be used in ABAC as well – since ABAC can use multiple attributes to make access control decisions, the “Role” can be one of those attributes – so ABAC can emulate RBAC perfectly while adding many additional advantages. This means that it is possible to add context to the access control decisions and adds for a finer granularity, tighter controls and more flexibility for the business.
Here’s an example: I might be authorised to make bank transfers from an application. In RBAC, this would usually mean that I would have a role enabled for my account, for example “Make_Transfers”. Simple, right? Well, perhaps not so. As the need for control gets tighter, I may be authorised only to make transfers up to a value of 2000 EUR without any approval. Anything else above that requires the approval of at least two of the financial supervisors. So how would you do this with RBAC? Not really so easy. And with ABAC? Piece of cake. With RBAC, the bank transfer application would have to have some hardwired piece of logic implementing the “max 2000 EUR without approval”. With ABAC, the policy could just express that if I have the role “Make_Transfers” and “transfer_amount <= 2000” the operation is approved. ALso approved is an operation if I have the role “Make_Transfers” and “transfer_amount <= 2000” and “valid_approvals >= 2”. Everything else is denied.
So let me get back to the XACML API. There has been adoption by XACML, and I could even see it for myself here at Burton Catalyst 2009 just by meeting the sheer number of vendors that are actively supporting it and using it it for policy enforcement and access control. What has really been missing however was a ready-to-use API that would allow developers to make an access control request in their application and get a decision. Now we finally have an API that allows developers to do just that. I’ve spent over an hour yesterday hunched over my brand-new netbook with Prateek and Pat Patterson, poring over the API and can only say: thumbs up!
So what can this API be used for? Is it easy enough for developers to jump on and enable their applications for externalised access control? Well, not really. XACML is a very powerful and expressive policy modeling language, and also defines a request/response protocol. This creates a certain level of complexity. Whilst of course it is possible for application developers to use this API in their applications, I think that higher-level authorisation APIs are still needed that make it “dead easy” for developers to externalise access control. For matters of comparison, I was very impressed at how easy it is to .NET developers to harness the Geneva Framework (which is now called WIF or Windows Identity Foundation). Microsoft has made it truly “dead easy” for developers to make their applications ready for externalised authentication and claims – with just a few lines of “plumbing code”. Externalising authorisation must be made just as simple. The XACML API is a great start to provide a foundation that can be used to connect simpler APIs and existing access control frameworks to XACML.
Kudos for Cisco and Oracle for having contributed this. Great work, guys!