O SCIM, Where Art Thou?

This is a rant.

Connectors, more specifically provisioning connectors, have always been the bane of my career, and I’m sure I’m not alone in feeling this way. It really is what drives a lot of us in the identity management game to drink. I know it’s what gives Frank V nightmares. Because each connector is a mini-product in itself – they have to be R&D’d individually, development doesn’t scale, they’re not sexy, they’re not a competitive differentiator that helps you sell, they’re resource hogs that have to maintained and upgraded. And that’s just from the vendor side. Building a bigger and better connector framework becomes our white whale, because connectors are always a moving target.

The cloud, or more appropriately SaaS, was supposed to solve the connector problem. SaaS applications (well, real SaaS applications) don’t get customized, unlike on-prem applications, so you can truly build a connector once and then deploy it to many customers. And with a standard like SCIM, we finally have a SaaS-friendly, practical way to remove the problem across 90% of provisioning targets. Yes, there’d still be some complex apps that SCIM, with its narrow and focused approach, wouldn’t support. But that is a far more manageable and practical problem that can not only be solved, but is probably preferable. IDaaS solutions like ours would ride the SCIM wave to the promised land, we were told.

But SCIM has yet to arrive. Not at the spec level, where a lot of good work has been done already. But on the adoption side. Much like the old SPML days, we’re still waiting for SaaS apps to play nice. And waiting. And waiting.

Meanwhile, building connectors for SaaS apps is turning out to have a whole different set of challenges compared to the old connector games we used to play. Sure, I can build a Google Apps connector once and then use it for multiple customers. That part is true and works. But there are some real interesting wrinkles that SaaS apps throw into the mix. Like the fact that with some of the big (and therefore most common) vendors, you actually have to shell out (a lot of) money in order to get access to the application and its APIs to build the connector. And that’s not counting the SaaS vendors that almost force other vendors to pay through the nose and jump through hoops to become part of a development partner program. While there are legit reasons for doing things this way, and when done properly it can be an asset for all involved, far too often we find poorly designed programs that are money siphons and anti-competitive in nature. That’s not the way the new API economy is supposed to work.

Speaking of APIs, we’ve all heard about how everyone is focused on providing good APIs to their products. But that refers to those APIs that expose the business capabilities of that SaaS app. The proprietary user management (provisioning) APIs are 2nd class citizens in this world, if they even exist. Not well maintained or documented. We actually dealt with a case where a major SaaS vendor made changes to their user management APIs that weren’t previewed or documented, unlike the rest of their business APIs. It took us 2 days of round-the-clock debugging of our live connector to figure out exactly what had changed. It wasn’t like the error messages were helping. Thank goodness we had a solid connector framework we had invested in building.

In the old days of connectors, there was a magic bullet that could get us around a lot of this cr@p. We could go directly to the underlying data store and do SQL or LDAP integration with the application user store. It wasn’t until the rise of NoSQL that was created to help with these matters, that we saw a rise in popularity in SQL again. This appeard to be the one true way to help communicate with databases. You can visit here for more information – (https://blog.timescale.com/blog/why-sql-beating-nosql-what-this-means-for-future-of-data-time-series-database-348b777b847a/). With that being said, in the SaaS world, we lost that workaround (for good reason). So we’re stuck dealing with poorly designed or non-existent provisioning APIs. That’s why I laugh when someone brings up how other IDaaS vendors claim to support more than a thousand applications. That number is related to SSO, with a large percentage of that being form-filling (which is an absolutely legit method of dealing with SSO) as opposed to a standard like SAML. Heck, I’d say doing an HTTP Post on a form with a “username/email” field and a “password” field is a de facto standard too. So provisioning is a very small percentage of that 1000+ (even after bookkeeping tricks that count the same connector multiple times for the different modules of an app, like GMail, Calendar and Google+ being different “connectors”). And a lot of the ones that do exist are not very usable, because after they’re used, you (the enterprise admin) still has to log into the SaaS applications admin console to “finish” the job of creating a proper user with the correct access rights.

Those that feel that these reasons are why only the big vendors will succeed at this don’t understand the reality that big companies deal with. Having been there, I can tell you that everything about connectors is DeStRes-ing, and the R.K.R on connectors is abysmal. So attention to detail and focus on connectors is much worse for the big IAM vendors than the small ones. And no amount of crowdsourcing connect development can solve the fundamental challenges that underlie the integration problem.

In recent years there’s been a spate of folks in the IdM industry rushing to proclaim a standard dead. For a change, I’d like to see a standard live. C’mon SCIM. Live, dammit, live!!!

[Update 01/06/2014: You can read the discussion this blog post sparked on Twitter here. It’s a long one, so keep some time aside]