Blogger: Mark Diodati
Jackson Shaw and James McGovern have been blogging recently about one of my favorite topics: Service Provisioning Markup Language (SPML). I’d like to contribute to the discussion. You can find Jackson’s blog entry from December 20 here, and James McGovern’s blog entry from January 5 here.
One thing that organizations using SPML should do is to secure the service from an authentication, authorization, and encryption perspective. In most instances, because the number of SPML requestors and providers (this is terminology specific to SPML) are small, most organizations are opting to manually configure the requesting authority and the provisioning service provider with static passwords or certificate lists to establish trust between the provisioning services components. These authentication techniques don’t provide authorization services in any meaningful sense. A large SPML implementation requires authorization services to determine the rights of the requesting authority to manage the specific user on the respective provisioning service target. In our opinion, the multi-tenancy (call it cloud-based if you like) use case is an example of a large SPML implementation – one must build the requisite authorization and authentication services to support the provisioning service.
SPML’s lack of authentication and authorization capabilities highlights the broader issues we see with the emergence of identity services. An authorization service requires authentication services in order to have any utility whatsoever. The authorization and authentication services may be consolidated (one big authorization and authentication service) or discrete (two separate services). One example of a discrete authorization service is a XACML authorization service that leverages the user’s SiteMinder SMSESSION ticket for authentication.
As for federation and federated provisioning, the lack of provisioning capabilities remains an operational impediment. Several years ago, a Liberty Alliance Technical Expert Group began working on a way to “harmonize” SPML and SAML. While the services would remain separate “pipes”, the TEG was working on a way to harmonize the user attribute schema across the two services.
James’ blog entry discusses the inter-enterprise standardization of roles. From talking to my colleague Kevin Kampman, there's been little if any traction to date. It really highlights the fact that a role is a representation of responsibilities coupled to a relationship, and getting common agreement on this is problematic.
If you are interested in more detail, we published a research document on SPML. The document discusses the v2 specification in depth, as well as the differences between the v2 specification and the v1 specification. It also discusses the barriers to the ubiquitous use of SPML. You can find the document at http://www.burtongroup.com/Client/Research/Document.aspx?cid=848 (client subscription required).
Check out http://blogs.sun.com/jerrywaldorf/entry/spmlv2_gateway_solution_for_salesforce
Posted by: James | January 13, 2009 at 10:48 AM