Down with federated provisioning

Blogger: Ian Glazer

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:

• We've dealt with it so long that pain isn't as acute
• Provisioning vendors built an array of connectors, shifting the pain up a level, allowing companies to focus on the provisioning technology and not each and every application they want to provision

Provisioning vendors spent lots of time and money to build connectivity to traditional applications.  Lots.  And in doing so provided a bit of absolution for application vendors from their failing to provide a standards-based provisioning interface.  Having gone through all that pain and suffering, vendors are not eager to go through it again with SaaS applications, coding connectors to each one's different web service.  Customers aren't too keen on the idea either.

In providing SPML interfaces to their applications, SaaS vendors would do everyone a service.  Provisioning vendors could use their SPML connectors and not have to build to each SaaS application.  Customers wouldn't have to write custom code to different service interfaces.

You don't want that fired sales guy walking away with your customer list no more than you want him walking out the door with your pricing information.  To that end, there should be no reason why deprovsioning from an application like Salesforce.com is any harder than deprovisioning from LDAP.  Federated provisioning should not exist; there is only provisioning.

Comments

[Dr Joe in NH]

SPML is terrible spaghetti at best. Having worked for a SaaS org, we looked at it and decided it was overkill for something that could be done in a much more compact and simple fashion. (We rolled our own). Some SaaS providers certainly have more than a clue about provisioning (witness Google's provisioning APIs) but I agree that it's not widespread and usually an afterthought.

[byron arnao]

Given these shortcomings ... SPML not being optimal, roll your own approaches leading to non-standard interfaces there does seem to be a vacuum in terms of a standard and opportunity for a vendor/company/standard to evolve to act as the glue for this. Is it simply that the demand does not exist or does not exist YET?

[Chandra]

We do need a standard way of provisioning. If SPML is complex and has shortcomings, there needs to be a simplified version of it. S2PML (Simplified SPML)???

[KeithD]

Federated Provisioning? What's the point? Provisioning is performing the necessary administration in the service provider's environment to allow identity to use the service. For example creating a folder for files, a mailbox , defining access rights and assiging passwords.

Surely the goal of Federation is to avoid this administration. If you need something, then assemble it "on the fly" when the user first uses the service.

Using SAML pseudonyms that should all be possible, in theory at least. I'm quite prepared to accept that in practice it will be difficult to collect all the information you need "on the fly" - but I'd suggest that that is because the IP does not have it or cannot/will not release it.

We have two problems
- who are the Identity Providers we will trust as custodians of our information.
- how (when) does the SP deprovision a stale account.