Tag Archives: SPML

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.

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.

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:

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.

Nishant Kaushik has a great (and funny) slide deck on federated provisioning on his blog. He discusses some distinctions between two flavors of federated provisioning, the Just-in-time (JIT) and what he terms advanced provisioning (often referred to as bulk provisioning).

I would like to clarify a couple of points in his presentation, however. He talks about a possible SAML profile of SPML for JIT provisioning. There was already an effort (which I lead) to define a SAML profile of SPML in Project Liberty (most of the work has already been done if anyone wants to revive it). But this was not for JIT provisioning as there is really no need for SPML when doing JIT provisioning. JIT provisioning can be done by SAML alone (or OpenID+other stuff). Rather the SAML profile of SPML was intended for advanced (bulk) provisioning. While the DSML profile could be used for advanced provisioning the Liberty TEG felt that using the SAML attributes assertions as the provisioning data structure was a better fit for advance provisioning accounts that would later be used in a SAML sign-on.

Me, I see it six one way, half dozen the other.

Another point the Nishant brought up is the need for the equivalent of the SAML attribute query in SPML. That already exists in the form of the SPML Search query which supports getting a single user record and asking for a subset of attributes.

When discussion whether JIT or advanced provisioning is appropriate, the points that are usually brought up are auditing, de-provisioning, and billing. But Nishant overlooks the most important point:

Do the identities have any meaning outside of authentication?

If the answer for your service is yes, than JIT provisioning is likely not an option.This is not a case of “tightly coupled” versus “loosely coupled”. Rather it is a matter of business requirements.

Take my current employer CareMedic (now part of Ingenix). We have a suite of medical revenue cycle management web apps that we host as SaaS. We need to know the identities of our customer users for the purposes of workflow before the user actually logs into the system.

Of course there are plenty of apps where the business requirements make JIT provisioning ideal. But it still comes down to the business requirements, not the technical architecture or standards.