Another entry from the 'While-I-was-on-vacation' department... Video from my JavaPolis ID-WSF 2.0 session was posted at Parleys.com. This is the third and final session I did at JavaPolis last year, the previous two covering OpenSSO and SAML 2.0.
There's also a short report from the JavaPolis 2007 Speaker and JUG Dinner - you can catch a couple of glimpses of me enjoying the JavaPolis hospitality, though Harold and Alexis get speaking parts...
It's Friday afternoon, time for some fun! We've put together a neat little game where you can protect your enterprise from the like of disgruntled former employees, Sarbox gremlins and the deadly auditors with the help of Sun's identity management products: Identity Hero! Here's a screenshot:
Kaliya wonders "if OpenID has been used for activism yet?", then, in a footnote:
Sorry - I am really trying to get openID to work on this hoster (well my tech person Lucy is) there is still something not working. So if you want to comment either link to this blog post and say it on your own site or send me e-mail kaliya (at) mac (dot) com. If any of you OpenID tech folks want to see if you can help her solve the problem let me know I will put you in touch.
There's really nothing I can add...
As I just reported over at The Aquarium, Eve and Marina recently published Federated Identity Through the Eyes of the Deployer - what it is, why you might want it and what questions to ask as you architect a federated identity system.
As I mentioned on The Aquarium, Eve was a key player in defining XML, SAML and more. What you might not know is that Eve is also a talented musician, shining even when accompanied by those less gifted in the art, such as here, at IIW2006b:
Across the wires this morning comes news from Kim and Stefan that Microsoft has acquired Credentica's U-Prove technology and the services of Stefan and his Credentica colleagues. I'm curious as to why the news isn't simply 'Microsoft acquires Credentica', but business is sometimes like that, I guess.
Anyway, congratulations to Stefan and co! I've been following their technology for a few years now (I even worked my way through Stefan's book - well, most of it - some of the formal proofs were a little beyond my mathematical abilities) and have met Stefan and Greg a couple of times - super guys, cool technology - it will be great to see it get wider exposure.
I wrote an entry on Tuesday about CardSpace as a Password Manager. Kim responded with a request: "I’d like to hear Pat’s ideas about the user experience of bootstrapping the passwords into the Identity Provider.".
Well, I see this happening at the relying party (RP) - if you already had an account there you would go to some 'change password' page containing the information card 'script' to invoke the identity selector and proceed as I detailed in the earlier post. When the identity provider (IP/STS) receives this initial request, it will see that it has no password for that RP/user, create (and record) a new one and send it to the RP, which will write it into the user's entry exactly as if the user had just typed it in.
If you didn't have an account, the relying party would do the information card thing as part of the signup, as an alternative to just prompting you for a password. In both cases, the relying party could display the password on screen (probably requiring a mouse click to 'unmask' it) so the user could independently make a note if she really wanted to.
In all three cases, signup, login and change password, it's the same code from the RP point of view - just a way of getting a password from the user. And, in both cases, the password could be nice and strong, since the user doesn't really need to remember it. One other detail is that the RP would need to communicate its password policy (e.g. 5-12 characters, alphanumeric plus !, @, #, $, %) to the IP/STS; sp:RequestSecurityTokenTemplate looks like it could carry that in its optional wsp:Policy element.
Going further, Gerry posted this morning on how the identity provider could even provide a series of strong, one time use, passwords, providing additional security, albeit with some incremental complexity at the RP.
I don't get it.
In this scheme, all three of IdP, identity selector, and RP need to speak the information card protocols. If they do that, then why not just use the regular information card stuff?
Is there something missing in the information card protocols whereby these password tokens would add value? If so, what is it?
This looks to me like it's just adding more code and complexity without adding any value.
That's a good question - where is the benefit here, and to whom? Well, the benefit for the RP over the regular information card model is that the RP does not have to correlate Information Card Private Personal Identifiers (PPID's) with user accounts. At the cost of adding some minimal code to the login process (parsing username/password from a posted information card token, rather than from the usual form fields), the RP enables CardSpace login. The RP doesn't need to add a PPID column to its user table and doesn't need a strategy for linking incoming PPIDs with existing accounts. If the RP is running some off-the-shelf web application, with no access to its underlying user management model, this could be very useful, indeed.
For the user, this allows them to use strong passwords with a huge potential population of web sites, all based on a single authentication to their identity provider, this authentication via an identity selector such as Windows CardSpace, rather than a web page in a browser.
For the identity provider, this is a value-added service that it could either charge for, or (more likely) provide free-of-charge as a competitive differentiator.
You might have noticed the exchange between Ben and Kim over the past day or two... Ben made a point that CardSpace makes OpenID redundant - why not just send a password to the RP? Kim jumped all over him - somewhat misinterpreting what Ben later describes as one of my most diabolical hungover bits of prose ever. Ben goes on to clarify that maybe CardSpace can have a role in helping the user manage passwords; Kim says "Hmm... Food for thought" (okay, I'm paraphrasing); Ben admits he didn't explain himself too clearly to begin with; and, glory be, they're violently agreeing. Phew! I thought we were going to be seeing handbags at dawn...
Reading all this lit a spark in my mind of how this could work. The crux is to consider the username/password token, usually sent as one of a set of possible input tokens to an identity provider security token service (IP/STS), as an output token.
Here's how it would work... Borrowing a diagram from Microsoft's Guide to Interoperating with the Information Card Profile V1.0:
First of all, the IP/STS would specify ic:RequireAppliesTo in the managed card. This tells the identity selector to include a wsp:AppliesTo element in the wst:RequestSecurityToken (RST). The IP/STS is going to need this later...
Now, the user visits the relying party (RP) in step 1, requesting some resource. In step 2, the 'service requestor' (application client with identity selector) requests security policy from the RP. The RP would indicate, in step 3, that it wanted a username/password token by specifying a token type of http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0 in the policy.
Now the identity selector presents some set of information cards (hopefully just one) to the user (step 5) and the user selects one (step 6). Steps 7 and 8 would see the RP requesting security policy from the IP/STS, and the IP/STS supplying it, exactly as in the standard information card interaction. Here the IP/STS could require any form of input token, but username/password is most likely.
Between steps 8 and 9, the identity selector prompts the user for credentials (bad Microsoft, missing that out of the diagram!) and in step 8, the identity selector packages up the user's credentials in a WS-Trust RST and send them to the IP/STS.
Now, here's the interesting bit. The IP/STS authenticates the user, exactly as in the standard CardSpace case, but now it looks at the wsp:AppliesTo element, and looks up the user's username/password pair for that RP (this is an implementation detail - there could be a mapping of RP identifiers to username/password pairs per user, all encrypted on disk, of course). The IP/STS packages them as a wsse:UsernameToken, which is then encrypted with the RP's public key and returned to the identity selector (step 10). The display token could just show ******** for the value of the password claim. Now we have a nice, securely packaged credential that the identity selector can send to the RP in step 11.
Here's the other nice bit... All the RP has to do is to decrypt the incoming token and it has the user's username and password, exactly as if they had arrived by a conventional form post. No further customization required at the RP - no changes to directory or database schemas, no extra steps of associating an information card with your account. Passwords on steroids.
OK - one more post in this jetlag-fuelled blogging frenzy...
Here are the slides from my JavaPolis 2007 sessions:
It's time to do a little housekeeping over at Planet Identity. First, the easy stuff... The feeds for Dmitry Shechtman (feed) and Trusted Network Technologies (feed) have been returning 404 since I-don't-know-when, so I've deleted them from the subscription list. If you know the current whereabouts of Dmitry's or TNT's blogs, then please leave a comment, or email me (if you're reading this in your RSS reader, then just click through to Planet Identity or Superpatterns - my email address is in the sidebar on both.)
Now, the hard stuff. Shelley Powers (feed) and Doc Searls (feed) both write entertaining, lucid, insightful prose, but most of it is not about identity. I've resisted removing folks from the subscription list for some time, but I had some really good feedback at the recent IIW on the usefulness of Planet Identity and how it would benefit from more focus. So, if you want to carry on reading Shelley and Doc, do what I just did - subscribe to them directly - those feed URLs again - Shelley, Doc.
Much as I enjoy playing (more or less) benevolent dictator (mwa-ha-ha-ha-ha!!!), Planet Identity is there for you, the readers. If you have an opinion, either way, on any of these changes, then please leave me a comment. If you'd rather express your opinion to me privately, then, again, my email address is on the sidebar at both Planet Identity and Superpatterns.
With that, I'll bid you a good day and leave you to the ever-widening river of news...
I've been back from Tokyo for a couple of weeks now and just realized that I haven't posted slides from my presentation on OpenSSO, so here they are [PDF]. Many thanks to the Liberty Alliance Japan SIG for organizing this day - about 220 attendees heard the latest Liberty Alliance news, many of them stopping by my booth afterwards to see OpenSSO in action. Special shouts to Takashi and Tatsuo for making me so welcome in Tokyo, as always. Via Tatsuo, here are some pics from our excursion on the last night there - I'm the balding caucasian guy in the blue t-shirt
Moving on... the preso at TriLUG last night - 'Digital Identity from LDAP to SAML and Beyond' - went well - about 60 or so very technical attendees. When I asked how many people in the audience did NOT understand sequence diagrams, only a couple of hands went up, and I breathed a sigh of relief as I explained the basics.
A BIG thankyou to Andy Oliver and the rest of TriLUG for the invitation to speak - it's a pleasure to talk to a well-informed, interested audience who are there by choice, not because it's their job . As promised, here are the slides [PDF]. There should be some video at some point too; I'll update this blog entry when it appears.