Tag Archives: Enterprise Architecture

Ping Identity’s Andre Durand makes some interesting observations about internal IdM vs Federation projects in the enterprise:

What’s interesting about our conversations is that invariably, they talk about one or more of their internal provisioning, IdM or WAM projects that is basically not meeting their expectations. What I find interesting about this is that federation deployments, by their very distributed nature, are taking an entirely different approach. Most if not all centralization projects are large, costly, complex and long. This makes them inherently more risky, and introduces higher and higher probabilities of failure at one or more levels.

He is absolutely right that centralization projects typically larger, more costly, and just plain harder than federation projects. Centralization is harder because it creates tight coupling between systems where as federation creates a loose coupling between systems. And tight coupling of systems made by different vendors (and often the same vendor) can be very hard and risky.

So Federation (loose coupling) is always the best way to go, right?

No. It’s often the best way to go but there are many times that tight coupling simply must be done. Often that means using a provisioning system and a means of synchronizing accounts (IBM TIM, Sun SIM, MS ILM, etc). Sometimes that means configuring your systems to centralize the identity (Quest Vintella,  Centrify, etc).

And here is where I will let you in on the dirty little secret of provisioning. It’s really all about deprovisioning. Typically enterprises don’t care if it takes weeks for you to get access to all of the resources you need to do your job. They care in the abstract (usually), but not enough to actually do anything about it. But the minute your employment is ended, your access to all your enterprise resources needs to be turned off.

And for that you need centralization of some sort.

Of course I have seen plenty of cases where systems are tightly coupled from an identity standpoint but loose coupled from and authentication standpoint. This is where the two systems share synchronized or centralized accounts, but are SSO enabled via federation. One common use case is using federation to bridge different vendors WAM solutions.