“Push vs Pull” in Identity Management

My friend Ben Goodman over at Novell recently wrote a blog post arguing against the “future of identity is pull” movement that seems to be sweeping the nation (well, at least the hallways at the recent Catalyst conference). I’ll give him credit for having the conviction to go against the grain here, since the idea of pull really resonated with the attendees at the conference (In my presentation, I quipped that “We are entering the ‘Age of Pull‘, where services are king, and Bob Blakley is our prophet”). Now, I can’t make the case for pull any better than folks like Bob already have. But the foundation for Ben’s argument seems to be in his taking a pragmatist’s view of the world, which is the right view to take. I just happen to end up drawing different conclusions from that same view.

As I detailed in my Catalyst talk, identity management has always been a very reactionary technological domain, influenced by the environment (architectural, regulatory) that it exists within. And the “pull” model is coming into its own because of two key factors driving next-gen application architectures – Identity Externalization and Federation/Cloud. Push architectures are built on the almost contradictory principles of guesswork and predictability – You have to guess ahead of time what it is that needs to be pushed to the target, and you have to rely on all flows and scenarios using identity data to be predictable within the use cases you have envisioned. Because of this, push forces us to overshare identity data on the off chance that something might be needed. But technology, and more importantly business, has advanced (on the back of standards) to the point where dynamism and flexibility are not only possible but expected and relied on. And concerns for privacy and regulatory compliance are forcing enterprises to re-evaluate how free they are in sharing identity data. In such an environment, the principles behind push are hopelessly outdated.

Service-Oriented Security is not externalization just for the sake of it. It brings great benefits in terms of agility (reuse over duplication), consistency (same policies applied across environments) and collaboration (across application, domain and enterprise boundaries). And if you look at how identity management has become more process oriented (an argument Ben uses for the push model), you realize that a lot of that process exists because we need to push identity data into the targets. The move to pull is not just about technology and integration architectures, it is also about streamlining and optimizing business controls that had to be put in place because of the way we leverage identity data in applications. Saying this though, looking to use a Zapier alternative (in relation to data integration) for your business can help make a difference when it comes to creating connections through apps and help manage tasks a lot better.

Push is never going to disappear – the complexity of our enterprise environments all but assures that. But as I tried to demonstrate in my provisioning session, the idea is to transition to where you make the choice of model most appropriate to the business needs of the application. Push from the HR system to an Identity Store will likely still exist, and further push to complex ERP Solutions may also continue. But the majority of applications will get streamlined to leverage external services, including authentication, authorization and identity services, with minimal need for local storage of identity data or authorization metadata.

It is important to note (as we discuss issues like performance) that pull doesn’t only mean centralized, externalized identity stores, though ideally that is the goal. Push vs Pull is also about which party is initiating data transfer. A large cloud provider like Salesforce (which you can learn more about), really doesn’t want its enterprise customers to push all their identity data to them all the time. At the same time, it is likely not going to want to pull data across the internet from its customers identity stores every time it needs it. But it can (and will) decide when and how to pull data from those identity stores into its local run-time store (cache, if you will). This is still a “pull” model, though not necessarily externalized identity. It is, however, a necessary facet of our increasingly distributed IT infrastructure, and one at the heart of the Just-In-Time Pull-based Provisioning I described in my talk.

Through all this, keep in mind that standardizing identity pull is a far easier task than standardizing identity push (where there were way too many targets to influence, and SPML failed to make headway). And that will go a long way in driving adoption, especially as identity services makes its way into the platforms that applications are being built on. Given that Oracle has a stake in all parts of the equation – the identity products, the middleware platform and the applications built on top of them – we have unique insight into this aspect of the future of identity that makes me far more confident in making this assertion.

The way I see it, the pull model is the logical next step needed to power the upcoming enterprise application environment where mashups and loose connections are going to be more common and hard-coded integrations are going to be hard to justify.