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
Jonathan Sander of Quest has this to say about the coming identity apocalypse. Interesting stuff.
This got me thinking to a fascinating aspect of identity management in the ASP (and SaaS) space, and that it the delegated nature of identity. For example my current employer CareMedic (now part of Ingenix) offers hosted services where authorization decisions are made based on the identity of the user. Since these are medical revenue cycle applications, the authorization decisions are covered by various regulations such as HIPPA.
But here is the interesting part. We don’t really need verify that the identity we know is actually a specific person. We trust our customers (the health care service providers) to validate that the identities they provide us are properly vetted and they determine the roles that those identities fulfill.
And this is the fundamental trust issue pertaining to the identity providers that Jonathan Sander discusses. The entity with the financial stake must validate the real person behind the identity.
Beware of greeks bearing gifts, or schools issuing laptops. Of course this situation could be addressed by a simple application of electrical tape.
You have to wonder exactly what the school was thinking would happen. How do you not get sued when you do something so monumentally dumb?
Nico Popp suggests that incidents such as the recent Google hack may lead to governments and large corporations adopting a form of Mutually Assured Destruction cyber defense.
On one hand there is a lot of sense in this, especially for governments. However I suspect retaliation would be more of a economic (or worst case military) nature.
At some level that’s exactly what is going on with the Google case. Google obviously believes that the Chinese government is behind the attack and Google has retaliated by threatening to stop censoring content in China, even at the risk of getting thrown out of the country. Of course now they seem to be backing down and both sides are now looking for a face saving compromise.
But one problem with the MAD theory of cyber-warfare is that you most often don’t have any idea who to retaliate against. At least not with sufficient degree of certainty.
So for now, MAD looks pretty unlikely in the cyber-warfare game.
Of course by now everyone in the social networking space is aware of the Google Buzz privacy issues and the corrective steps Google has taken. Not to beat up on Google, but this was a totally avoidable mishap. All Google needed to do was keep in mind one simple rule that inevitable invites disaster when ignored:
Always ask first!
If you look at at many of the recent public relations debacles such as the Buzz roll out and the recent Kindle 1984 flap, companies got in trouble for taking actions that they assumed the customer would be OK with. The when it turned out that they were in large numbers, not OK with it, they had to scramble to make amends.
And as I always say, “when you assume you make an ass out of U and, well U”.
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.
Would you expose your genitals to a complete stranger just to get on an airplane? That is no longer a hypothetical question as plans move forward to install scanners in major airports. And this article should disabuse of any notions that the privacy and dignity violations won’t get abused. They already have.
Images of your total body in graphic details will be taken. Those images will be viewed by at least one total stranger. Those images can also be stored, printed, and distributed despite any reassurances you will be given.
Really, how many indignities is too many? When is enough enough? How about random cavity searches? If we don’t push back now that is surely next.
Hit them where it hurts; boycott any airports that put these things in, starting with Heathrow.
I get a steady stream of indignant sputtering about this post on the metric system and what it means for authentication. One common point that readers make is that Celsius is better than Fahrenheit because it is based on natural law, defined as 100 degrees between the freezing and boiling point of water.
Only it isn’t, and hasn’t been for some time (at least not since 1954). While the freezing point and boiling point of water was precise enough in the 1700′s, it is no where near precise enough to act as a standard. The reason is that no two samples of water will melt and freeze at the same temperature due to variations in water purity, air pressure, and humidity.
By international convention, the Celsius scale is defined by a range between absolute zero and the thermodynamic triple point of Vienna Standard Mean Ocean Water (VSMOW). This point, by the way, is 0.01 C. And VSMOW is not ocean water (despite it’s name), but rather is a carefully crafted lab concoction comprised of specially defined proportions of oxygen and hydrogen isotopes.
So while we are taught Celsius is defined by the freezing and boiling points of water, it is actually defined by absolute zero (which doesn’t exist in the natural world), and the triple point of a form of water that only exists in the lab.
Explain to me again, why this is less arbitrary that Fahrenheit?
And why is it still taught incorrectly in schools (at least in the US)?