With this post, the long tail of commentary from the European Identity Conference continues. I came up with the term Anywhere Application Architecture while preparing my EIC keynote as it captures a number of principles that architects must consider when deploying applications. Today, applications and the supporting infrastructure must be able to run anywhere – and be mobile enough to transit between on premises data centers, private clouds, and public clouds. Below is a graphic that represents this approach, from an authorization perspective.
Here’s how it works: A typical authorization service is depicted in the lower part of the graphic; it is comprised of a policy enforcement point (PAP) policy decision point (PDP) and policy enforcement points (PEP). In addition, authorization policies represent the business and security rules to be enforced and necessary attributes are retrieved through a policy information point (PIP) interface.
The traditional deployment of an authorization infrastructure is to install it on premises alongside applications in your enterprise’s data center. A PEP would be typically integrated with your application (App A in this case). If your enterprise utilizes a private cloud hosting a web services application, then XML gateways can serve as a super PEP to secure access to web services (in this case Service A).
If you are running workloads in the public cloud, the same authorization infrastructure can be extended. In our example, the XML gateway can protect publicly hosted web services (Service B) or you can choose to implement a PEP in the cloud (Service C). Finally, you may also choose to run part or all of your authorization infrastructure in the cloud – depending on the usage scenarios or requirements of your applications and users.
To reiterate, security architects and application planners must prepare for workloads that can run in the data center, in private clouds or in public cloud scenarios – and they must be able to accommodate moving workloads between these environments. Therefore, your IdM infrastructure must have the same flexibility characteristics. In this example, we’ve shown you how an XACML-based authorization system fits the bill. By the way, this approach integrates extremely well with a federated model as the authentication approach. Then you can also accommodate users that are located anywhere!
Analyzing Identity 