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.