#EIC2010: The Anywhere Architecture is Any-Depth too

In a recent keynote (Six Sigma For the Secure Cloud – Equip the Enterprise for Success) at the European Identity Conference, Gerry Gebel introduced the concept of the Anywhere Archictecture:

Data, applications and users can be anywhere… Does your architecture allow it? “Anywhere Architecture” is required.

The whole world is your market place and you need the flexibility that you could deploy [services] anywhere.

The Anywhere Architecture is about deploying services and connecting to users and data wherever they might be and enabling these interactions securely. Of course, in such a distributed environment, security needs to be rethought from the ground up. This goes through federated identity, trust establishment, externalized security, and flexible authorization to name but a few items. (More on Gerry’s blog)

“Anywhere Architecture” goes hand-in-hand with what I would call the any-depth architecture. Not only do you want to secure applications, data, and users wherever they might be, but you also want to achieve security at the right level, or depth, in order to exploit the relevant context in your security decision making.

In particular, when it comes to access control and authorization, it is important to be able to understand the context of the authorization decision making. Are we dealing with a service? A document? If so, does the access control apply to the entire document? Part of the document?

Any-depth architecture has two aspects. Firstly from a technical perspective, the any-depth architecture requires different connectors depending on the depth and technology of the integration. Are we integrating authorization (or more generally security) at a web service level? An ESB level? A legacy database level? Or even lower? Each level will require a specific integration point which in the XACML architecture is known as Policy Enforcement Point (PEP).

Any-depth architecture also has a business perspective and this is where context comes into play. Often customers will ask whether our Authorization service can take into account information of a document they wish to protect. The answer usually is that we can provided we integrate at the right level. Take for instance a Document Management System – a cloud-based one like Google Docs. If one wants to make decisions based on document information, then the integration with Google Docs must happen at the level of the API where the information is readily available. If on the other hand, one wants to make decisions based on the transport protocol (UDP vs. TCP for instance) then integration may need to take place at a lower level.

With Axiomatics’s Policy Server (APS), it becomes easy to integrate authorization at any of these levels. From a technical perspective, because the authorization engine is externalized and because it implements the XACML request/response protocol, the engine can be called by a PEP which has been specially crafted for a particular depth. From a business perspective, because the APS implements XACML and because XACML is attribute-based, one can take any information tidbit and map it to a XACML attribute. Both the PEP and the PDP can do this in a standard way through the Policy Information Point (PIP) interface.

And to summarize, here’s a little picture I wrote in SVG (an XML standard!) and XACML:

Integrate the Authorization Solution at the depth that is most relevant to your architecture.
Integrate the Authorization Solution at the depth that is most relevant to your architecture.