The Value of SPML Gateways

Blogger: Mark Diodati

A grateful “thank you” goes out to James McGovern, who steered me to Project Keychain and Jerry Waldorf’s associated blog. Project Keychain is an SPML gateway which leverages Sun’s open source enterprise service bus (fittingly called OpenESB). You can find Project Keychain’s list of supported target platforms (including LDAP, RACF, and salesforce.com) here.

Recently, I was asked if there is any value to using an SPML gateway. I believe there is. A picture is worth a thousand words (a cliché to be sure, but a good one), so here are a few thousand words. This picture describes the provisioning world, pre-SPML. I think we’d all agree that the world would be a better place if provisioning systems did not require connectors or the use of a proprietary API to manage users.

Currently, there are a few target platforms that natively support SPML for provisioning. Cloakware’s Password Manager (a privileged account management product), Imprivata’s OneSign and Citrix’ Password Manager solutions, and SAP NetWeaver come to mind. The list of target platforms which support SPML is slowly growing. With SPML support built into the target platform, organizations can readily integrate the platform into the provisioning environment because they can use the existing, standards-based framework (SPML). Also, a standards-based approach means that component upgrades (either the provisioning system or the target platform) are less likely to “break” the provisioning process. This picture describes the goal of SPML – provisioning users without connectors or proprietary APIs.


So, what are the benefits of the SPML gateway (as personified by Project Keychain)? One benefit is the ability to insulate the complexity of the target platform’s proprietary API from the provisioning system. This insulation means that the creation of a custom provisioning connector is not required, and any changes to the target platform’s API will not break the provisioning process (though it does place the burden on the SPML gateway). Another benefit is a smooth transition once the target platform natively supports SPML in future releases, because the provisioning system can speak directly to the target platform without the gateway. This picture describes a mixed environment with a provisioning system using SPML to manage users.

SPML may fix the plumbing issues with provisioning, but the user attribute schema issue remains. The provisioning system (that is, the SPML requesting authority) and target application (in the simplest architecture, this would be the combined SPML provisioning service point and provisioning service target) must use an agreed-upon set of attributes. The provisioning system must then map the SPML attribute schema to its internal schema. The provisioning system must do this for every target application, as it is likely that each target application will require a separate attribute schema. For what it is worth, SPML v2 made the division of service and attribute schema much easier. Burton Group’s SPML document discusses this issue. You can find the document at http://www.burtongroup.com/Client/Research/Document.aspx?cid=848 (client subscription required).

Comments

[Bob Bobel]

Mark,

Great comments on SPML and the impact it is having. As part of the projects I'm responsible for at Quest Software I have had the good fortune to be allowed to create a free SPML provider for Microsoft's Active Directory. The provider can be used to provision Active Directory by itself or in conjunction with Quest's provisoning solution ActiveRoles Server. Anyone interested in the free provider can download it from the Quest web site at http://www.questsoftware.de/activeroles-server/spml.aspx.

Thanks,

Bob

[James]

I would love if Burton Group also provided coverage of http://docs.safehaus.org/display/VELO/Home. Likewise, this begs the question of the separation of provisioning from user interface from workflow.

More importantly, I think it would rock if Burton provided coverage regarding multitenancy aspects of provisioning going forward...

[Ron Daley]

Hello Mark,

The SPMLv2Gateway works only with Sun Identity Manager and Sun ESB running on Glassfish application server. It does'nt work with Novell as I tried them both. Novell SPML implementation had quite a lot of conflicting schema issues when I parsed with JAX-WS.

Ron
Accenture

[Mark Diodati]

Hi Ron,

Thanks for passing along the results of your tests. Do you feel that other provisioning systems would work with Sun ESB?

Thanks,

Mark Diodati

[Mark Diodati]

Hi Bob,

Thanks for passing along the information about Quest's SPML gateway to AD!

Mark

[Colin Robbins]

At Nexor we have also been looking at the concept of SPML gateways, but in a slightly different context. In our specific market, there is a need to be able to provision users over low bandwidth links. We have documented our approach in http://www.nexor.com/index.php?option=com_content&task=view&id=544&Itemid=251

[Jerry Waldorf]

Mark, thanks for the nice note!

The keychain project supports a number of different targets (all at different levels of maturity):

Active Directory, Adempiere, Alfresco, Google Apps, Igloo, JDBC, LDAP, LongJump, RACF, Salesforce.com, SugarCRM, Workday, ZenDesk, and Zoho.

The intention of the project is to create SPMLv2 Gateways that interoperate with any provisioning system that speaks SPMLv2.

I would be interested in finding out what issues were found between Novell and the SPMLv2 Gateways. We intentionally tried to follow the SPMLv2 spec in a way that would allow it to interoperate with any provisioning system.

[Gary Zheng]

We at Cloud Identity also find the Gateway concept very valuable as well. We are hosting such Gateways to SaaS providers like Google Apps, Salesforce.com, ZenDesk, ...

More information can be found at http://www.cloud-identity.com.