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]
Even if the SaaS provider supports SCIM, how do they protect it? As you pointed out, many of these SaaS providers are basing their security on underlying user accounts, so you need to share a person’s credentials with the connector using the SCIM API. These authentication schemes will fail if the person upgrades to something better than username password authn. The problem is not many organizations use IDM products, so SaaS vendors don’t get a lot of requests to support it.
Mike, SCIM is just an API, so it should be protected like any other API. Which ideally means OAuth.
And you’re right that SaaS vendors aren’t getting a lot of requests to support it. Therein lies part of the frustration. The reason SCIM was promising is that it wasn’t just the IDM vendors that were participating in it. SFDC, Google and Cisco were banner names that were going to lead the way in showing other SaaS vendors the benefit of adopting SCIM.
I disagree that not many organizations use IDM products. For the companies that care about provisioning to cloud apps, they’re in wait mode, because they don’t want to have to build and maintain the connectors. So they are (extremely reluctantly) rolling out AD-to-SaaS integrations in the interim (which is a poor man’s IDM in this scenario). And the ones that have had that for a while and rolling those back because of all the inherent issues. They’re hungry for an alternative, and we (Identropy SCUID) are hoping we can deliver one to them.
Very few organizations are using SAML and OpenID Connect either… therein lies the opportunity for companies like Gluu and Identropy. Our industry has done a bad job at convincing the average organization that centralized identity is a worth the expense of the undertaking. Even organizations that have a central identity infrastructure, don’t use it for many apps — not just SaaS apps. Phil Hunt from Microsoft had a comment on our Twitter exchange that is worth repeating … “SCIM has a way to go before it is interoperable and complete despite what some claims. ” I think you need to dig into that comment to perhaps get the answer to why SCIM is not being adopted..,. maybe there is more to it than my pithy dismissal of IDM in general.
Nishant – this is good stuff, I am also very surprised that there is little market demand for SCIM. Unfortunately, SCIM 1.0 was over-sold by marketing/PR types as some sort of resty-not-spml magic potion, whereas it was really just a starting point for work.
Now a lot of effort has gone into the draft SCIM 2.0 spec at IETF – and by the way – most of it comes from the boring old tech vendors 🙂 The next step is for large customers to demand the use of SCIM with cloud services.
Paul Moore at Centrify surveys different vendors and asks a similar question –
Prateek Mishra (using one of my 33333 consumer ids)