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.
Analyzing Identity 
