Federated provisioning is the topic, and the raging dispute about its pros and cons is today's subject. It started with the comment by Daniel Wakeman (CIO, Educational Testing Service), who said "It's a 'huge shortcoming' that SaaS [Software-as-a-Service] vendors do not embrace 'federated identity management' standards allowing centralized identification and validation of users via a single sign-on process…"
Quest's Jackson Shaw jumped on this remark: "Wakeman has hit the nail on the head. SaaS will only complicate security, audit and compliance if it doesn't effectively address identity management. As he points out, supporting federated identity management would go a long way to addressing those issues..."
Enterprise Architect (for The Hartford Financial Services) James McGovern, the Burton Group's Mark Diodati and Ian Glazer (also of the Burton Group) jumped in to comment. Ian's post drew fire from Oracle's Nishant Kaushik and the battle was on!
You see, Ian started life in identity management with Access360 – one of the original provisioning vendors (swallowed up by IBM in 2002). His point: "…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." That's a concept I can get behind.
Nishant's credentials are no less impressive, though: he came to Oracle when it acquired Thor Technologies where Kaushik had been Product Architect and Lead Technologist for Xellerate, Thor's provisioning product. He brings up a "just-in-time" provisioning situation in which a federation server (using SAML) and a provisioning server (using SPML) would need to interoperate and there simply are no standards for that today. Neither SPML or SAML, on their own, could handle the transaction.
But, as Ian bluntly puts it, "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."
So it appears to be a case of violent disagreement. Yet we're still not much closer to automated provisioning of clients, customers, vendors and partners, are we? And then there's de-provisioning – the removal of access for users. Glazer says "You don't want that fired sales guy walking away with your customer list any more than you want him walking out the door with your pricing information. To that end, there should be no reason why de-provisioning from an application like Salesforce.com is any harder than de-provisioning from LDAP." But, evidently, it is. Is there a way to solve that problem? Tune in next time…