Look at the way we set up access permissions today on, say, a windows file. We go into a form and state the exact users and files that will have permission for the file. If we want to set the same permissions on a different file, we have to go through the whole process again, manually.
At home, I have an XP PC, a Vista laptop, a Mac laptop and a network storage drive. My XP PC has 3,000,000 files on it, each file must have its permissions set correctly; my other computers are similar. I have many other applications that control access to my information, not to mention web sites. I have a Capgemini laptop, of course (actually, I’ve just remembered, I have two). Then I have my desktops at client sites; that’s without even starting to think about the clients’ infrastructure.
I have no idea whether my security setup meets the Data Protection Act, or whether it’s sufficient to meet the threats that are out there. In the unlikely event that, by some random chance, I’ve got everything right, if the threat changes, or the interpretation of the Data Protection Act changes, then I’m back to the beginning again.
This should give you some idea of the scale of the security problem we all face. The response we are forced to take, that is, setting access permissions, is rather less powerful than assembly programming. There must be a better way. Ideally, I would want the following:
- The capacity to specify an access policy that applies to many different objects simultaneously.
- The capacity to specify an access policy in a single place in a single style, which is then interpreted consistently by many different applications and locations.
- The capacity to offload security policy setting into the cloud – security as a service.
The good news is, this is now a possibility. The new XACML v2 standard from OASIS describes how a security policy decision point can be separated from the policy enforcement points; along with protocols for them to talk to each other, and a language for specifying rich security policies.
The bad news is, support for XACML v2 in real-world applications is still pretty patchy.
I hope I have now explained why security access permissions, as currently implemented, cannot hope to solve the security problem, and justified the provocative title of this blog entry. XACML-style rich policies are, I believe, a crucial component for building a collaboration-oriented architecture and meeting the de-perimeterisation challenge.