Nishant Kaushik has a great (and funny) slide deck on federated provisioning on his blog. He discusses some distinctions between two flavors of federated provisioning, the Just-in-time (JIT) and what he terms advanced provisioning (often referred to as bulk provisioning).
I would like to clarify a couple of points in his presentation, however. He talks about a possible SAML profile of SPML for JIT provisioning. There was already an effort (which I lead) to define a SAML profile of SPML in Project Liberty (most of the work has already been done if anyone wants to revive it). But this was not for JIT provisioning as there is really no need for SPML when doing JIT provisioning. JIT provisioning can be done by SAML alone (or OpenID+other stuff). Rather the SAML profile of SPML was intended for advanced (bulk) provisioning. While the DSML profile could be used for advanced provisioning the Liberty TEG felt that using the SAML attributes assertions as the provisioning data structure was a better fit for advance provisioning accounts that would later be used in a SAML sign-on.
Me, I see it six one way, half dozen the other.
Another point the Nishant brought up is the need for the equivalent of the SAML attribute query in SPML. That already exists in the form of the SPML Search query which supports getting a single user record and asking for a subset of attributes.
When discussion whether JIT or advanced provisioning is appropriate, the points that are usually brought up are auditing, de-provisioning, and billing. But Nishant overlooks the most important point:
Do the identities have any meaning outside of authentication?
If the answer for your service is yes, than JIT provisioning is likely not an option.This is not a case of “tightly coupled” versus “loosely coupled”. Rather it is a matter of business requirements.
Take my current employer CareMedic (now part of Ingenix). We have a suite of medical revenue cycle management web apps that we host as SaaS. We need to know the identities of our customer users for the purposes of workflow before the user actually logs into the system.
Of course there are plenty of apps where the business requirements make JIT provisioning ideal. But it still comes down to the business requirements, not the technical architecture or standards.
Posted in Cloud computing, Identity, Identity Management, OpenID, Provisioning, SaaS, SAML, SPML, Standards
Tagged Federated Provisioning, Identity, Identity Management, SAML, SPML, Standards
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?
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.
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.
Posted in AD, Identity Management, Open Source, Provisioning, SPML
Tagged AD, DSML, FIM, Identity Management, Open Source, Provisioning, SPML
Microsoft has finally released FIM (formerly ILM and MIIS). While it’s good to see this finally out the door, Microsoft has made a decision that I believe will severely hinder adoption. The system requirements include:
- Windows Server 2008 64-bit or Windows Server 2008 R2 Standard, Enterprise or Datacenter Editions
- SQL Server 2008 64-bit Standard or Enterprise Editions SP 1 or later
Unfortunately far too many enterprises are still unwilling to move to Windows 2008, much less 64 bit Windows 2008. So many of the enterprises will have to budget moving to 64 bit Windows and SQL Server 2008 as part of their evaluation of whether to start an IdM project.
And for the life of me I can’t see any technical reason for this limitation.
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.
Posted in AD, Authentication, Google, Identity, Password Management, Provisioning, SAML, SPML, Standards, Virtual Directory
Tagged Authentication, Google, Provisioning, SAML, SPML, Virtual Directory
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.