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.
Standards fascinate me. One of the most problematic standard in use almost universally today is the kilogram (kg). The problem is that no one really knows exactly how much mass a kilogram actually has. By extension that means that no one knows how heavy a pound is either since the US government defines it in relationship to the SI kg unit.
Originally the metric system was supposed to be defined in terms of “natural laws” that the common man could measure for himself. The kg was originally defined as a cubic decimeter of water under certain conditions. This is probably what you were taught in school, one of many metric misconceptions (see why everything you know about the metric system is wrong).
But that approach was jettisoned as impractical due to variations in water density, temperature, etc. In 1889 the standard became defined by a set of “physical prototypes” that were manufactured and distributed to major countries. So what was a standard based on “natural laws” became based on an arbitrary hunk of platinum and iridium.
Only that has not worked either (at least not to the number of significant digits desired). The problem is that the different physical prototypes are changing mass by a small but measurable amount. So today there is effectively no precise consistent definition of a kilogram, and thus by extension the pound.
The plan going forwards is to define the kg in terms of basic physical properties, similar to what has been done with the meter and the second. But for now, kg is only an estimate for given levels of precision.
Vittorio Bettocci from Microsoft has a great write up of OAuth 2.0 and how it relates to authentication protocols (but is not one itself). You can read it here.
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.
There is an idea that has been kicked around in IdM for years called Security Policy Provisioning. Basically the idea is that you have a system that takes centrally managed security policies and pushes them out to disparate system, the same way provisioning systems manage user accounts. We kicked around the idea of building a Security Policy Provisioning product back at OpenNetwork, but never did. In all honesty I had expected some IdM vendor to have added this feature to their provisioning engine by now, but as far as I know none ever went farther than user role management.
Well Axiomatics has apparently rolled it out in the guise of pushing their XACML policies to Windows Server 2012 to leverage the new authorization features. This is a very neat idea.
Of course after you push out the policies, Windows Server 2012 becomes the PDP as well as the PEP. You could develop a similar solution without using XACML at all.
OptimalIdM announced its new Office365 offering this morning. You can read the announcement here.
This has been an great project to work on. OptimalIdM can now enhance Office365 with a great set of new features and can do so for both the WS-Federation Passive and Active profiles. The Active Profile is used for Office365 Lync and Outlook support.
The new features we add to Office365 include easy multi-forest support, support for non-AD users, support for users with non-addressable UPNs, two-factor authentication, auditing, and a whole bunch of other features.
Posted in AD, Authentication, Cloud computing, Identity, Identity Management, Microsoft, Security, Standards, WS-Trust
Tagged Identity, Office365, WS-Federation
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.
There is a lot of push vs pull provisioning discussion going on recently. Both models have a place but there is hard and fast rule you should consider. If your solution requires your customers to stand up a web service (SOAP or REST) you are going to be running uphill against a head wind. Customers see public web services as support and security costs they just don’t want to pay.
For most customers it’s far easier to have a system running in a data center that makes that makes web service requests to a provider than it is to stand up a service. Google, for one recognizes this. The Google Apps Directory Sync is often incorrectly cited as a “Pull Provisioning” technology when it is exactly the opposite. The sync software runs on the customer side, reads from the local directory and pushes to the Google Apps Provisioning Web Service.
A proper provisioning standard, regardless if it’s SOAP or REST, should support both push and pull (note that SPML supports both). But I really don’t see the pull model getting much traction for cloud based provisioning. Perhaps it will for provisioning internal applications.
Posted in Cloud computing, Google, Identity, Identity Management, Provisioning, SOAP, SPML, Standards
Tagged Identity, Identity Management, Provisioning, REST, SOAP, SPML