Vittorio Bettocci from Microsoft has a great write up of OAuth 2.0 and how it relates to authentication protocols (but is not one itself). You can read it here.
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
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.
Posted in Authentication, Identity, Open Source, OpenID, Provisioning, SAML, SPML, Standards
Tagged Federated Provisioning, Federation, Identity, OAUTH, OpenID, Provisioning, SAML, SPML
This is interesting. Sears (and Kmart) web pages now support OpenID for consumer authentication (as a relying party). I just gave it a spin on the Sears web site and it worked quite nicely with my Yahoo OpenID. When reauthenticating it remembers that I used my Yahoo OpenID last time and gives me that as a choice.
This is a really good application of OpenID. It gives me quick and easy access to consumer information without having to fill register yet again.
The only downside was that it required me to pick a unique screen name. I would have preferred it to give me the option to use my Yahoo OpenID as my screen name.
Other than that, it’s nicely done.
No, not me (at least not me so far as I know). The Jeff in question is Jeff Atwood of the Coding Horror blog (one of my favorite dev blogs). Jeff relates how his OpenID account was hacked here and here. It’s fascinating reading, especially because the hacker was of the friendly sort who apparently just did it to point the vulnerability.
The hacker was able to obtain the unsalted hash of Jeff’s password on a different site. He then looked up that password using one of the reverse hash web sites available. He then guessed Jeff’s OpenID provider and tried the password there. Since Jeff had used the same password in both places, the hacker was able to log into OpenID and impersonate Jeff at Jeff’s StackOverflow web site, which depends on OpenID.
Here is an interesting question: is it dangerous to reveal your preferred choice of OpenID providers? I suspect there is nothing dangerous about, given peoples propensity to flock to one of the big players anyway. Even if there are a plethora of OPs, the bad guys will just script a solution that tries a list known OPs until a hit is made.
Posted in Authentication, Hacking, Identity, OpenID, Password Management, Programming, Security
Tagged Authentication, Hacking, OpenID, Password Hash, Security
One theme I have harped over the last year of so is that it means little for the big content providers to become OpenID providers if they don’t also become relying parties. You can’t build a highway with nothing but on ramps.
So far the vast majority of OpenID announcements by the big players have been to be yet another OP, or just signing up for the OpenID Foundation. It looks like the game is finally changing. Apparently Facebook is getting ready to become an OpenID Relying Party. From Inside Facebook:
Less than three months after joining the OpenID Foundation’s board as a sustaining corporate member (i.e. putting its weight and financial support behind OpenID), Facebook has just announced at the “technology tasting” event this afternoon at its Palo Alto headquarters that users will soon be able to log in to Facebook with their OpenID.
This could be huge for OpenID adoption, if it really happens.
There is an interesting new OpenID provider called MyID.is. The stated goal is to provide a verified OpenID:
MyID.is trying to answer a simple question, how can we provide our users a digital ID that have been certified with the same level of trust as if we met in real life with a valid ID delivered by a governement administration but without the need to actually meet in real life?
By certifying your ID you’ll be able to certify all of your online presence, such as your blogs, your Facebook, LinkedIn profiles…, your comments,… and any kind of online presence that is part of your Identity 2.0.
They validate who you are by billing you a small amount via credit card and then sending you a code via postal mail. You have to wait until to get the code to use the OpenID.
What I find most interesting about this service is that they are not trying (at least at this point) to solve the age verification issue. That’s a good idea in my opinion as I feel that the age verification issue is one of the most oversold issues in the identity space.
There is also a good ARS Technica article on MyID.is here.