Recently Microsoft announced Azure AD support for SCIM 2.0. This is a big deal. But the announcement was lacking one key detail:
Does Office 365 support managing users and groups via SCIM 2.0?
It seems that since Office 365 is based on Azure AD provisioning to Azure AD should be the same as provisioning to Office 365. But Microsoft doesn’t say that in the announcement or anywhere else that I can find. So for now I will have to assume that while SCIM is supported for Azure AD, it is not supported for Office 365. I would love to hear otherwise.
Last week at TechEd Microsoft disclosed their new Graph API for Windows Azure Active Directory. Graph API is a RESTful web service for accessing the identity system behind Windows Azure and Office365.
This is an interesting development because it will enable Azure and Office365 customers to provision with systems other than FIM. While Graph API is not specifically an identity management API like SPML and SCIM, the capabilities are effectively the same in the context of the Azure environment.
There is a great presentation on this here, including a demo of the soon to be released OptimalIdM support.
It seems strange that there is so little attention being paid to this. It really an important step in cloud identity.
Now that SCIM 1.0 is final and SCIM 2.0 is starting I wanted to share my thoughts. First here is what I like about SCIM:
- SCIM defined a standard schema in 1.0. I wish SPML had done the same. Not doing so was one of the biggest mistakes we made.
- SCIM supports filtered and paged searches. That’s a must have in my book.
- SCIM supports multi-value attributes with the proper modification semantics. You be surprised how many Identity APIs I have seen that don’t get the modification semantics right.
- SCIM only did what it needed to do, nothing more.
So what don’t I like about SCIM? I don’t really care about the REST vs SOAP aspect. It’s not going to be widely used unless it’s wrapped in an API or toolset. So that’s a moot point. So I can’t really think of anything I don’t like.
But will SCIM be accepted where SPML was not? I don’t know, but I think there is a decent chance. I think announcing the IETF SCIM 2.0 effort so soon may be mistake as it may convince people to just ignore it until 2.0 comes out.
But ultimately the proof of standards is in adoption. For it to succeed it has to be both adopted by the cloud providers as a service and by IT as a client. Each of them wants the other to go first.
My biggest question is will the backers of SCIM implement it in their main product lines. Will SalesForce.com stand up a SCIM provisioning service? Will PingIdentity then add SCIM support to their SalesForce.com offering? We shall see.
Jackson Shaw has some great points to make about it here, but I didn’t really get the parrot reference. He points to this article about SCIM which also makes some great points.
One of the most puzzling complaints I have heard about SPML is the search filter. The complaint is that it requires the service to support search filters of arbitrary complexity. I have never considered it that hard and have posted sample code to demonstrate it.
Still, perception has a reality of its own and search filters are often given as a reason not to support SPML.
So now that SCIM has finalized the 1.0 version, the filter-phobes can breathe easy, right? Not so much it seems. Like SPML, SCIM has a search filter mechanism that supports filters of arbitrary complexity. Which is a good thing for without that capability a provisioning service would be severely limited.
But really this should not be a reason to avoid either SPML or SCIM. This class of problem comes up regularly and provisioning service developers should learn how to handle it (if don’t already). One could argure that it would even be considered a pattern.
Actually it is: the Specification Pattern.
The new RESTful provisioning standard, SCIM, is being discussed a lot recently in comparison to SPML. Dave Kearns has some interesting thoughts here.
While Dave makes some good points I think he is entirely missing the reason the SPML was never accepted. SPML never gained traction because enterprises and application vendors never adopted it. It didn’t matter whether the provisioning vendors supported it or not, and it won’t matter if provisioning vendors adopt SCIM or ignore it.
Enterprises and service providers drive adoption. The ISVs will meet their needs. If SPML or SCIM is demanded, it will be provided. That demand never materialized for SPML, partly because the provisioning vendors already had non-standard solutions for the problems SPML was intended to solve.
Will this demand materialize for SCIM? Time will tell the tale of these two standards.