My blog has moved and can now be found at

No action is needed on your part if you are already subscribed to this blog via e-mail or its syndication feed.

Sunday, February 21, 2010
« Standards Based Provisioning and SPML | Main | NIST SP 800-73-3 and PIV-I »

To be conformant to SPML v2 means that the SPML interface (Provisioning Service Provider / PSP) MUST:

  • Support the set of Core operations
    • a discovery operation {listTargets} on the provider
    • basic operations {add, lookup, modify, delete} that apply to objects on a target
  • Supports basic operations for every schema entity that a target supports
  • Supports modal mechanisms for asynchronous operations

SPMLThere are additional “Standard” operations described in the OASIS SPML v2 Specification [Zip]. The clear thing to keep in mind is that each operations adds a data management burden onto the provider, so the choice of whether or not to implement them should be considered very carefully.

From the perspective of deployment topologies, the PSP could be deployed separately from the Target or could very well be integrated tightly with the Target e.g. an SPML compliant web service interface on a target system.

One of the frustrating items for me when enquiring about SPML support in products has been the lack of clarity and visibility around exactly what has been implemented. All too often, vendors seem to have cherry picked a chosen set of operations (whether from the Core or from the Standard list) and used that to claim SPML support. I would be very curious to see if anyone can claim full SPML v2 compliance.

A particular use case for SPML that I am currently working on has to deal with the “batch” movement of attributes from multiple systems to a central repository. The typical flow is as follows:

  • Per organizational policy & relationship to user, attributes are assigned in their home organization and/or business unit (Org A / Org B / …)
  • Org A must move those users and/or their attributes to a central repository (Repository X) on a regular basis
  • Repository X acts as the authoritative source of attributes of users from multiple organizations / business units and can provide those attributes to authenticated and authorized entities in a real-time request/response and in a synch-take-offline-use modes.

Some points to keep in mind are:

  • Org A / B / … may have, and all too often do, have their own existing identity and provisioning systems as well as associated governance processes in place.
  • The organizations and the repository may or may not be under the same sphere of control and as such cannot mandate the use of the same piece of provisioning software and associated connectors on both ends of the divide.
  • The systems where the organizations store the attributes of their users may not necessarily be directory based systems.
  • The Repository may or may not be directory based system.
  • Identity / Trust / Security are, as you may imagine, rather important in these types of transactions.

SPML_Profile To meet these needs, we are currently profiling SPML to support the Core SPML Operations as well as the optional “BATCH” capability.  The “ASYNC” capability is something that we are more than likely going to support as well as it provides a mechanism for the provider to advertise support for asynchronous operations rather than have a request for an asynch operation fail on a requester with an error “status=’failed’” and “error=’unsupportedExecutionMode’”.

Keep in mind that the end result will satisfy more than just the one use case that I noted above. In fact, it satisfies many other use cases that we have that deal with both LACS and PACS scenarios. In addition, the profile will also bring in the pieces that are noted as out of scope in the SPML standard i.e. the Profiling of the Security protocols that are used to assure the integrity, confidentiality and trust of these exchanges. Fortunately, we can leverage some of previous work we have done in this space for that aspect. Tags: ,,

Technorati Tags: ,,

2/21/2010 4:44 PM Eastern Standard Time  |  Comments [2]  |  Disclaimer  |  Permalink   
Monday, February 22, 2010 1:05:12 PM (Eastern Standard Time, UTC-05:00)
It was my recent understanding that SPML v2 is DOA. 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. See for more details.
Jon Salwen
Monday, February 22, 2010 7:19:16 PM (Eastern Standard Time, UTC-05:00)
@Jon I am aware of that Burton Blog posting. My blog postings, and my comments on that Burton Blog entry, are my responses to that fact that I do see the need for SPML (or something that is SPML-ish and standardized) in the community.

>SPML is not currently viable [...] is too complex and places too much of a performance burden on the connector

The entire point of SPML is to get away from the connector architecture that is proprietary in nature. Agree that there is an immense amount of complexity (to the point of being unusable) in some of the operations that are possible with SPML; "Search" and "Updates" come to mind. But as Mark noted in his Burton blog entry, a potential way forward is to Profile the standard so that there is a simpler subset of operations that are usable.

But ultimately my response is that if SPML cannot be salvaged, let's put a stake thru its heart and move on. But the alternative of staying with the proprietary connector architecture of provisioning products is not something that is viable for Enterprises. We need to either make SPML work or work on an alternative that is open, standards-based, interoperable and has vendor support behind it.
Anil John
Comments are closed.