Posted February 5th, 2009
Nishant has commented on my post about federated provisioning. He has provided two different examples of federated provisioning. One of these, the advanced provisioning example, involves a company who manages its employees’ access to a service provider service via provisioning. In this case, Nishant agrees with me that provisioning of this sort is no different than provisioning the UNIX box down the hall.
But it is Nishant’s second example, the just-in-time provisioning example, which is a bit tougher. In this case, the enterprise and its service provider have a federation in place. Using SAML-based authentication, a new user attempts to access the service provider’s service. The idea (hope?) is that the service provider recognizes the new user request, provisions the user, and authenticates the user in the same conversation. Nishant does add a degree of difficult in this scenario as he ties the federation service to a provisioning service. Grabbing attributes from the SAML token, creating a SPML message, and handing that to a provisioning service is possible, but as a commentator points out this sort of interop isn’t spec’ed out so the heavy lifting is left to the service provider. And even if the service provider doesn’t want to directly link its federation and provisioning services, it still needs to grab that assertion attributes and create the account in the backend system.
Continue reading "Will the “real” federated provisioning please stand up?"...
Posted January 7th, 2009 There’s been a bit of recent blogging activity about federated provisioning and SPML. Having worked on both federated provisioning and SPML in a past life, it warms my heart to see this discussion. Jackson, quoting the CIO of Education Testing Services, Daniel Wakeman, restates the observation that SaaS providers are providing when it comes to federated identity management. This “major shortcoming” leaves service subscribers to fend for themselves in managing user lifecycle events like on-boarding and off-boarding. Not acceptable.
That got me thinking – there really ought not to be a concept of federated provisioning. Provisioning an application in the data center must be the same as provisioning an application in the cloud. However, in the course of the conversation between James, Jackson, and Mark, it seemed SaaS applications and in-house applications were different from a provisioning perspective.
SaaS applications may be harder to provision and de-provision than non-SaaS application, but that doesn’t make them fundamentally different animals. The point was made that SaaS apps lack a standards-based provisioning interface, an SPML interface. The fact is the vast majority of applications, SaaS or not, lack a standards-based provisioning interface and this makes dealing with them very much the same.
Now there are two reasons that we don’t hear the same short of clamor about provisioning non-SaaS applications as we do with SaaS applications: Continue reading "Down with federated provisioning"...
- We’ve dealt with it so long that pain isn’t as acute
Posted July 1st, 2008 My first post as a Burton Group analyst is now up over at the Identity and Privacy Strategies blog.
(Helps if I actually link correctly… doh!)
Posted March 17th, 2008 James has provided me more to work with…
Identity consolidation says that I figure out how to get user stores out of my enterprise application and instead get these applications to bind at runtime to a directory service such as Active Directory.
Ah, so identity consolidation is centralized authorization. Got it.
I am making the assumption here that when James says user store he means authorization store. (Applications in this model still need some modicum of a user store if nothing else for auditing purposes.) I am assuming the implication here is that after authentication comes a round of authorization that the directory service provides. The application would consume this authorization data, at runtime, and act accordingly. Theoretically, an enterprise policy (XACML) store could theoretically reproduce the authorization models of every application in the enterprise today and that policy tools would interact with this store. Though I think this is a very viable model for customer applications (especially J2EE and .NET), I do not see it as an enterprise approach where complex applications like mainframe security and ERP roam free.
Identity management says that I should go create a strategy around provisioning of identity and leverage tools such as Sun’s IDM, Thor, etc where I still fundamentally allow enterprise applications to have their own user stores and takes me down the path of building lots of connectors… [snip] I am of the belief that identity management (provisioning) propagates and encourages an otherwise bad architecture. Continue reading "Considering identity consolidation"...
Posted March 16th, 2008 James recently picked up on my Identity leprosy or identity zombies post and writes:
Ian believes that identity needs brains but falls into the trap of thinking about identity solely from the perspective of provisioning and while avoiding runtime aspects. I wonder if he would blog on why enterprises should consider identity consolidation over identity management?
Before I respond I’d like to get some clarity. James, give me a more to work with and I’ll happily write more. Help me understand that which you are contrasting between “identity consolidation” and “identity management.” Help me understand how provisioning doesn’t have runtime implications.
|
|
what others say