Analyzing Identity

Bob Blakley certainly hit a nerve with his keynote presentation at Catalyst this year. He had been working on the concepts for his “Pull” identity architecture for some time and it was well received by the audience, sparking a lot of discussion and debate. Since the conference, we’ve witnessed a terrific continuation of the debate through the excellent posts by Nishant Kaushik and Ben Goodman. Nishant has argued in favor of “Pull” here and here, while Ben has taken an opposing view here and here.

This type of discussion often takes place when we speak to enterprises about adopting externalized authorization managers instead of relying on historical approaches – you don’t always (or rarely) open up legacy applications unless there is a specific business reason to do so. However, as Nishant points out, enterprises realize the value and opportunity of moving forward with a “Pull” based approach. Existing models, while workable in many situations, may not be flexible enough for modern business organizations that need to operate in a more dynamic fashion while maintaining security and regulatory compliance.

A final point to make is this: for every application that adopts the “Pull” model, you have one less application that requires provisioning or data synchronization. I refer to this type of application as stateless, from an identity perspective. In this case, users don’t authenticate to the application, they authenticate via a service that may be hosted by the enterprise or an external entity – no extra accounts or credentials needed. For access control, the application calls to an externalized authorization manager (EAM) – here policies define what the user can do within the application. If additional attributes are needed, they can be loaded from existing authoritative sources by the EAM – no extra data synchronization or user provisioning is needed. Now this model will not work for every application or every scenario, but it is a model that is implementable today and many in the industry are enthusiastically adopting it. For applications that still require a monolithic approach, then I agree with Ben that your IdM  tools must indeed be very intelligent.

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!