SPML Is On Life Support ….

Blogger: Mark Diodati

But it (or something like it) is desperately needed.

 

At Burton Group, we closely watch emerging identity standards. In particular, we pay close attention to the development and adoption of the Service Provisioning Markup Language. We have hosted two interoperability events at our Catalyst conference. We issued our first research document on SPML in early 2006—coincident with the release of the SPML v2 standard. The publishing of our second document is imminent, and it is based upon some “hands-on” work with the standard, as well as ongoing discussions with vendors, end-user organizations, and OASIS Provisioning Service Technical Committee members (past and present).

 

The primary goal of SPML is provisioning without the use of proprietary connectors. The reality is that SPML is not currently viable for building useful, standards-based provisioning services because it is too complex and places too much of a performance burden on the connector. For example, the SPML Search capability is required for most viable provisioning services, and its support is infeasible due to complexity and performance concerns. I’ll talk more about these issues (including the Search capability) in my next blog.

 

The SPML standard—like all emerging standards—requires more work. More work is required to harmonize SPML with SAML. An optional “inetorgperson-like” user schema is required to promote greater SPML adoption (the OASIS Provisioning Services Technical Committee tried to create a standard user schema when developing SPML v2, but the members could not agree on one). A simpler “real world” search capability is needed, with a limitation on the number of attributes and filter expressions. The latter two requirements should be combined into a future “SPML Simple” profile.

 

Unfortunately, there appears to be little industry support for SPML enhancements. A vicious cycle exists. Few people are using the standard, so there’s less momentum to enhance it. The IdM vendors’ participation in the OASIS Provisioning Services Technical Committee has been minimal at best since the 2006 approval of the SPML v2 standard. The last meeting of the Committee was in early 2008. None of the major provisioning vendors have developed an SPML v2-conformant product. Many of the vendors who have created commercial SPML connectors tell us that they must create specific SPML implementations for each of the major provisioning products. An SPML reference implementation does not exist, but would surely help.

 

What is the future of standards-based provisioning?

 

SPML may prevail if the industry simplifies the standard and supports it in commercial products. It may be too late to pull it out of the fire, though. Another alternative is a “pull” model—LDAP-based directory services supported by virtual directories. For example, both salesforce.com and Google provide a pull capability via LDAP. The applications query existing enterprise directories for authentication and identity information. Many organizations express concern about exposing a directory (especially Active Directory) to cloud-based applications. Burton group believes that virtual directories can mitigate these concerns. It is worth noting that neither vendor supports SPML. Both salesforce.com and Google expose a relatively simple (compared to SPML) SOAP interface for provisioning. Another path to standards-based provisioning may be SAML.

 

My colleague Bob Blakely will be speaking more about standards-based provisioning in the IdPS Telebriefing “The Future of Identity Management is Pull”.

Comments

[Anil John]

Really glad to see this discussion starting. From an end user perspective SPML is most definitely needed to implement an open and standards based provisioning interface. And there are many use cases that would benefit from it.

The concern with exposing LDAP/AD across organizational boundaries is real and may not be resolved at the technology level. Applying an existing cross-cutting security infrastructure to a SOAP binding (to SPML) is a proven and understood mechanism which is more acceptable to risk averse organizations.

I would also add two additional points:

1) More support for the XSD portion of SPML vs. DSML in vendor tooling. There are a LOT of authoritative sources of information that are simply NOT directories.

2) There needs to be the the analog of SAML metadata in the SPML world (Or a profile of SAML metadata that can be used with SPML) to bootstrap the discovery of capabilities. The "listTargets" operation is simply not enough.