Ping Identity > Blogs > PingTalk 

PingTalk Blog

Why SCIM over SPML? Why not?

  • By ,
  •  | 

Dave Kearns, our good friend from Network World, recently shared his concerns on the new SCIM (Simple Cloud Identity Management) specification and contrasted it with the "legacy" SPML specification. While Dave is obviously entitled to his opinion, I felt it was important that I respond to some of his comments in the article.

As background, Ping Identity has never actually been opposed to the SPML specification. We implemented an internal "Federated Provisioning" SPML module back in 2007 that was used to provision to SaaS applications. Unfortunately, after doing some market analysis across our customers and SaaS vendors there was not enough interest to leverage SPML (or any standard) to solve what we now call the "cloud provisioning" problem. Everyone seemed happy to continue using batch oriented, secure FTP jobs.

Fast-forward to 2011 and a different world. Multiple SaaS and Cloud vendors have implemented proprietary SOAP and REST APIs to allow their customers to programmatically manage user accounts. All of these APIs are similar in that they support simple CRUD operations and a proprietary user schema of some form. This includes Salesforce.com, Google and Cisco and WebEx.

Over the past two years, we have consistently heard from our customers that proprietary APIs make no sense. They ask, "why haven’t the cloud vendors implemented a standard?" Our consistent response has been “does it matter to you whether the standard is SPML or a new lightweight, REST specification?” Our customers say that REST is fine. The fact that it’s a standard and implemented by all the cloud vendors is actually what’s most important.

I will leave it up to Google, Salesforce, WebEx and others to respond to why they implement proprietary APIs rather than leverage an available standard in SPML. My quick analysis would be to say that SPML looks, feels and acts like a boat anchor.

So to respond to some of Dave’s comments:

  • The argument is made that SPML is not best suited for cloud-based applications.

This is partially true. While we could certainly make SPML work over the Internet, it’s an XML-based protocol that is perceived by cloud vendors as too complicated and heavy. Adoption of REST and JSON in the Cloud is exploding.

  • There's nothing uniquely different about provisioning cloud applications as opposed to data-center applications -- except that the "data center" is at the end of a URL rather than a network path.

Again this is partially true. For years, enterprise provisioning vendors have not had to push enterprise application vendors to adopt SPML because they have always had a backdoor - so-called database cheats. The ability to create user accounts directly in the database via JDBC or other means has meant the ‘need’ to adopt SPML was not there. You can’t do database cheats in the cloud. You need a standard API.

  • A provisioning system needs to be able to work with all applications and services no matter where they're located.

True, and it would be even simpler if all those applications implemented a standard provisioning API.

  • And as to that "providing a common user schema" thing -- we've had that for many, many years (beginning with x.500) -- no need to reinvent that wheel.

Yes, with no adoption. Ironic that Dave mentioned X.500. X.500 included the Directory Access Protocol or DAP. DAP was succeeded by an alternate but simpler protocol called Lightweight DAP or LDAP. The same thing happened with mail protocols when X.400 was succeeded by Simple MTP or SMTP. I see a trend here.

  • To my mind this is no different than many other supposed "standardization" movements -- a poorly disguised attempt by one or a handful of vendors to dictate protocols to the world.

This one's the kicker. Ping has been all about standards since our inception. If there is any vendor who could stand up and state that they have no agenda related to open standards its Ping. SCIM is being developed under the Open Web Foundation (OWF) framework. This allows an equal voice to each participant. The fact that Google, Salesforce.com, VMware, Cisco, etc. are all participating says it is more than a ‘handful’ of vendors. Without SCIM, Pings customers, many of which are customers of all the previous three SaaS providers I mentioned, will need to support multiple proprietary protocols that are near 85% logically the same. We will also happily push to move this to a more traditional standards organization once we see some adoption.

  • It's time to scrap the SCIM and pump up the SPML.

Well that just makes no sense. We are now in a position where we have actual application vendors willing to adopt a standard user-provisioning specification. That's not a bad thing at all.

Add your comment