Category Archives: Provisioning

Azure AD Supports SCIM

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.

Enter the Migrator

One common business case we get is to migrate from various directory servers to AD. This is usually an issue of per user license cost but lower maintenance is also a factor. Companies are realizing that since they are maintaining AD anyway, why pay for and maintain other multiple directory servers as well? For employee accounts it usually doesn’t make sense to have the same account in two places and need additional processes just to keep them in sync.

There are several ways you can migrate directories. You could use a one-time import/export, a Metadirectory, or a provisioning system, but these approaches have several key drawbacks. One issue is that in most cases you can’t migrate the user passwords. Another issue that the migration may require custom attributes to be added to AD (try getting your AD team to agree to that).

But the biggest issue is that these directories exist for a reason. There are client apps, sometimes tens or hundreds, which rely on the information in the old directories. Most home grown apps written for one directory won’t be able to switch over to AD without extensive rewriting. Even commercial apps that support AD may require significant and disruptive configuration changes.

Enter the Migrator (obscure Disney reference intended)

A virtual directory can be your Migrator. The solution is to standup a virtual directory that merges your AD with the old directory into a single view that emulates the old directory. Run both directories side by side while migrating the accounts. When a password change is made the virtual directory can update both AD and the old directory with the new value, so after running side-by-side long enough, most of the passwords will have been migrated. Eventually the old directory can be retired.

This approach has two main advantages:

  • no changes need to be made to the client applications
  • no schema changes need to be made to AD.

There is a good white paper that covers this in detail on the OptimalIdM web site (no registration required).

Thoughts on SCIM

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.

Open Source IdM platforms

Radovan Semančík has put together an interesting list of open source IdM platforms. There are not as many as I would have expected.

A tale of two standards

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.

It’s easier to push than be pulled

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.

SPML and DSML search filters not so hard

One issue that has been raised in regards to SPML is search filters. SPML allows searches that optionally specify a starting point (in terms of an SPML container), a subset of data to return, and a search filter. In the DSML Profile, the search filter is naturally a DSML filter.

DSML filters can be arbitrarily complex, just like the LDAP filters they model. For instances a DSML filter could be something like “get everyone with the last name of smith”, or in DSML:

<filter xmlns=’urn:oasis:names:tc:DSML:2:0:core’>

<substrings name=’Name’><final>Smith</final></substrings>

</filter>

Or it could be “get everyone with last name smith not located in Orlando”:

<filter xmlns=’urn:oasis:names:tc:DSML:2:0:core’>

<and>

<substrings name=’Name’><final>Smith</final></substrings>

<not>

<substrings name=’Office’>

<final>Orlando</final>

</substrings>

</not>

</and>

</filter>

Now if your back end data is stored in LDAP, then this is pretty easy to handle. Just convert to an LDAP filter and do any attribute name mappings required. If you backend data is SQL, it just slightly more difficult to translate the DSML filter into a SQL query clause.

But what if your back end data store doesn’t support a query mechanism? What if the data is in a flat file, or a NOSQL DB? What if the data is only accessible through an API that doesn’t allow for filtering?

There are several ways to solve that problem, but the easiest is to recursively walk the DSML filter and create a decision tree where each node determines if a given instance passes the part of the filter it knows.  The code for this is pretty simple in .NET and I posted an example here. Note that this example is just a partial implementation of the SPML search request for the purposes of demonstrating this concept. It is not a full featured implementation of SPML.

The basic idea is that an abstract data provider would return a dictionary of the attribute values for each entry in the data. The interface could look like (in C#):

public interface IUnfilteredDataProvider {

List <DSMLData> DoUnfilteredSearch();

}

In this example the sample data provider reads entries from a flat file. On each search request the filter is recursively read and turned into nodes in a decision tree. Each data entry is then passed to the decision tree and if it passes the filter it is appended to the returned results:

List<DSMLData> dataList = this._unfilteredProvider.DoUnfilteredSearch();

DataFilter df = GetDataFilter(searchRequest);

List<PSOType> returnPSOs = new List<PSOType>();

// return only those entries that pass the filter

foreach (DSMLData data in dataList) {

if (df.Pass(data)) {

returnPSOs.Add(data.GetPSO());

}

}

The GetDataFilter method walks the DSML filter and constructs a decision tree (feel free to download the sample and look at the code for more details). No special meaning given to any of the attributes returned by the provider. They are all just treated as DSML attributes. Of course you will note a potential scalability issue with large data sets, but there are several tricks that can be used to minimize that (thoughts for a later post).

Oh, and this approach works great for creating a DSML service as well and the general concept would be just as easy to implement in Java.

So what does all this mean? Supporting filtered searches in an SPML or DSML service is really not that hard, even if your data is stored in a data store that does not support filtering.