XACML training workshop in Washington DC

On September 19-20 Axiomatics will be arranging an XACML workshop in Washington DC. I will be there and perhaps I will meet some of my readers.

In my opinion the most interesting aspect of this workshop is that Axiomatics' has managed to establish a fully featured ecosystem around their product. I started looking at the product back in 2009 and at that point it was a useful and very interesting PDP.

The use case I was looking at was online health records for usage in pre and post FDA approval registries and given that Axiomatics had been used in the national Swedish healthcare implementation they had the substantial edge in that the system actually was in production. The main issue with Axiomatics at that point was that getting access to the rest of the pieces that you would need for an actual production implementation would require usage of components that were built or heavily configured by companies that really didn't have any global delivery capability. If your needed the stuff delivered on the Nordic market then it worked fine but if you needed it in the US or Asia Pacific you basically  needed to use another products.

Over the last three years Axiomatics has managed to pick up some really smart people including Gerry Gebel from Burton group. Gerry and the rest of Axiomatics has worked really hard on establishing connections with other product companies whose products fits very well with the PDP as well as professional services organizations that can manage the implementation.

The result of this work can be seen in the speakers list for the XACML workshop. Sailpoint will be there to talk about how you use Sailpoint IdentityIQ to not only provision users to the central user and attribute repository, perhaps an LDAP server from Radiant Logic, but also manage the entire lifecycle of the user including access recertifications. You have Layer7 that talks about how to integrate Axiomatics into your corporate web service gateway or your enterprise SOA platform. Well done Axiomatics!

Externalized authorization and Xacml

Back in 2001-2003 I was working for a business system vendor and we were looking at how to integrate the technical infrastructure of the business system with the new platform technology that was starting to mature. We started out by creating a Corba based architecture that was later converted to J2EE. On the security side we integrated the authentication engine with LDAP/AD. We looked at having authorization objects externalized but determined that there probably wasn’t any market pressure for that feature at the time.

The years passed and the web access managers became the standard for coarse grained web authorization. Most access managers deal in URL access which is good if you just want to protect an application or a part of the application but if you want to say “users in group A can only update transactions that originated in the central European region and whose total value is less than $50 000” you really are in trouble.

XACML and attribute based access control does offer a promise to give you this ability. It is off course nothing revolutionary as you can implement exactly the same in your favorite programming language but there are situations where having the authorization logic embedded within the business logic may not be so good.

One example from pharmaceuticals world is that FDA is putting more and more pressure on companies to deliver data about not only how their drugs behave during trials but also how the drugs behave in the commercial patient population. As competition increases between different drug makers and makers of generic drugs it also becomes increasingly important to have a close relationship with your patients and doctors. The most common solution to this problem is to create a registry that basically is an online electronic health record system where patients and their doctors can record how the therapy is progressing.

One important factor here is of course data privacy. Health information is simply highly sensitive so you don’t want this information to grant inappropriate access. Defining what is appropriate and inappropriate is unfortunately slightly more complex. In most cases the patient and the treating doctor should have full access. In many cases other doctors in the same practice should also have access along with nurses and other health care professionals. In some cases patients are treated in multiple practices or may switch practices temporarily or permanently.

You could of course implement all of this functionality in code but if you ever need to prove that only the appropriate users have access to the patient’s information the auditors may not be happy with having to look through thousands of lines of code. Also if you run a global system you may run into requirements where you have to handle people from different jurisdictions differently as the German Bundesdatenschutz may require special rules for German citizens.

Xacml clearly offers a very attractive way to externalize and document the authorization logic in a format that is clearly understandable by auditors and other interested parties.

Xacml in itself does not solve the whole problem but it is an important puzzle piece. Next posting will talk more about the other pieces.