Category Archives: SPML

SPML SIG at Catalyst

Bob Blakley announces here that the Burton Group identity blog has transitioned to individual Gartner blogs. He also announces an SPML SIG at the next two Catalysts.

It’s good to see attention being given to SPML again. But will this translate into real movement to adopt SPML (either 2.0 or a to be developed 3.0)? Perhaps, but we may have to take a step backwards in order to move forwards. If work starts on SPML 3.0 then that will effectively kill adoption of 2.0. But if 2.0 isn’t being adopted anyway, why not go ahead and do a 3.0?

Interesting times.

Advertisements

SPML 3.0 in 3D!!!

OK I kid about the 3D, but I am starting to hear from various identity folks that it’s time to start thinking about SPML 3.0. The latest is John Fontana’s post on that here.

While I don’t think that there are any technical reasons SPML 2.0 can’t be used for interoperable provisioning, the market has clearly not embraced it yet. There are some SPML enabled products out there, but not nearly enough to reach the critical mass that is needed.

So would an SPML 3.0 effort succeed where SPML 2.0 has so far not succeeded? I honestly can’t say, but I feel it’s worth giving it a go. The industry really needs this. My employers products need it.

Open source C# SPMl v2 implementation

Softerra has released an open source C# implementation of SPML V2 (DSML profile). I haven’t had time to play around with it yet, but it looks interesting.

Now what would be really great would be some developers to take this and create some implementations that do useful stuff. For instance write a service provider for provisioning and reconciling AD accounts. Or perhaps integrate it with Microsoft FIM.

Pulling LDAP

Mark Diodati sums up the recent SPML threads here. But one questions that needs to be answered, if not SPML then what? One alternative that has been put forward by Mark Diodati, Mark Wilcox, and others is the LDAP (or DSML) pull model of provisioning.

This model is to expose your user accounts via LDAP using a Virtual Directory (VD) instance exposed to your service provider. The service provider would periodically make calls to the VD to look for account CRUD operations.

There are several compelling advantages to this model;

  • LDAP is already a standard protocol
  • There are defacto standard schemas (the most common of which is the standard AD account)
  • This is really just an extension of a model that has already been embraced in the enterprise (look at how many apps can be AD enabled)

Could that be it? Is the solution to service provider provisioning really this simple? No, at least not without SAML. While this model shows promise there is a problem; passwords. If your enterprise is not ready to use SAML to authenticate to your service provider, then you are left with two choices; both unpleasant.

First you could just punt on passwords and force your users to manage their passwords on their own. This is no worse than the situation without any provisioning, but certainly not where you could be if you used a provisioning solution to push the passwords out to the service provider as needed.

The second is to expose your password hashes via your VD. If your service provider supports the same salting and hashing algorithms, then the passwords could be synchronized by copying the hash across. In fact the recent version of the Google apps dir sync utility claims to be able to do just that.

But think about this for a moment. If you do that then the service provider knows the clear text password to log into your network for every one of your users that actually uses the service. After all, the user has to provide the clear text password to the service provider’s login page to generate the hash value to compare to the hash you sent them. If that’s the same as the hash value in AD, then the service provider knows your AD password by definition.

Do you trust Google with the clear text AD passwords? I’m not picking on Google; there simply aren’t any service providers I would trust with that information.

Another alternative I have heard is that the service provider’s login page would make an LDAP bind call back to the VD with the supplied password to do the authentication. Again, that gives the service provider a clear text version of your AD password.

Are you sure you really want to do that?

But if your enterprise and your service provider can implement SAML, then the LDAP pull model looks a lot more compelling. I would be curious to hear from anyone that has implemented this or is thinking of implementing it. And if anyone is using the password hash sync approach, I would be interested in hearing about as well.

Whither SPML or wither SPML?

Whither SPML or wither SPML? This is the question Mark Diodati asks in his post SPML on Life Support. Ingrid Melve and Nishant Kaushik have follow ups here and here.

The problem with SPML still the same more than 10 years after the effort was started. Right now the choice is between home grown provisioning or bringing in a provisioning vendor. In the latter case the provisioning vendors are forced to absorb the pain of integrating to all the disparate provisioning targets (a pain I know all too well). Since the provisioning vendors make it all work, the customers don’t force the enterprise system vendors to add SPML interfaces.

Note that Nishant has this to say about Oracle:

Is SPML on life support? Not quite, judging from all the RFP requests that still ask for it to be supported. But it desperately needs some energy to be put behind it. And it needs to adapt to these new architectures, new use cases and the ecology of standards that is far out-pacing it. I believe Oracle (led by folks like Prateek Mishra) will be looking to take some leadership in the evolution of the standard. Let’s see if we can turn things around.

Great, I would love to see that happen. But Oracle has been involved in SPML from the beginning, but do you know what they haven’t done? Added an SPML service to to support the provisioning of Oracle DB accounts. Neither has IBM, Sun, or Microsoft with respect to their own DB products, even though they have all had involvement in the SPML standard over the years. It’s the same when you look at directories, email systems, etc.

We can talk about the standards or “pull models” all we want, but it takes two to Tango. Until the enterprise systems support a common interface of some kind, provisioning will still be as problematic as it was 10 years ago.

SPML, SAML, OAUTH, and Impedance Mismatch

Nishant Kaushik posits an interesting question; can OAUTH fill the provisioning role in Just-in-time federated provisioning. Mark Wilcox follows up here and here.

I agree with Mark’s commenter who suggests that a SAML attribute service fills the role just as well. Mark suggests that a SAML attribute query is too difficult to implement in some development environments. But I am not sure that I buy the argument that there are environments where doing the SAML SSO is doable but doing the attribute query isn’t.

Regardless all this got me thinking about impedance matching. When we wear our standards hat, all things are possible. But we need to step back at times and put on our developer hat and think about how are designs are going to be implements. While we could mix SAML and OAUTH to support JIT federated provisioning, implementation now requires tools, libraries, and implementers that can implement both SAML and OAUTH as well as handle the rough edges where the don’t mesh well. That’s an impedance mismatch in my opinion.

Good summary of Sun’s open IdM projects

Luca Mayer has this summary of Sun’s open source IdM projects. I have some experience with OpenSPML (obviously), and I have fiddled with OpenDS. There is some great stuff there.

I hope this all survives the acquisition.