Quite excited to return from vacation today and find an email in my inbox from Martin Gee of ICSynergy (a Sun-partner system integrator specializing in identity management) pointing me to his blog entry on adding CardSpace authentication to OpenSSO. Martin does a great job of explaining his use case, linking a personal card to an existing account in OpenSSO, screenshots and all.
This is fantastic stuff – a great foundation for OpenSSO/CardSpace integration. I’m certainly looking forward to seeing the code made available. And, of course, it will work just as well with Access Manager, OpenSSO’s almost-twin.
Well – Familia Patterson is off to London today for brother-in-law‘s wedding. Kim Cameron responded to my recent entry on minimal disclosure in CardSpace/InfoCard – unfortunately I won’t get a chance to follow up on that for a couple of weeks.
Oh – and Scott Kveton just added me to Planet OpenID. Thanks, Scott!
[I would have left this as a comment on Kim’s blog, but I don’t have an InfoCard handy and I can’t figure out how to register there for a good old username and password…]
Kim Cameron replies to a question from Eric Schultz with a description of how InfoCard (or is it CardSpace?) handles minimal disclosure, allowing the relying party to request only the information it needs. In Kim’s example, the relying party requests four claims regarding the user via an OBJECT tag:
Then, according to Kim,
If, next time, the relying party doesn’t want to receive these claims, it just doesn’t ask for them. If it has stored them, it should be able to retrieve them when necessary by using ”privatepersonalidentifier” as a handle. This identifier is just a random pairwise number meaningless to any other site, and so there is no identity risk in using it.
But, but, but… how does the relying party know not to ask for givenname, surname and emailaddress the second (and subsequent) time round? It doesn’t know that it’s already collected those claims for that user, since it doesn’t know who the user is yet…
If only there were some specification [PDF] (perhaps part of some sort of framework) that, given a token from an authentication, allowed you to get the data you needed, subject, of course, to the user’s permission [another PDF].
I just pulled the trigger on the first draft OpenSSO WS-Federation Software Requirements Specification (SRS) – see it on the dev-AT-opensso.dev.java.net mailing list here. This is the first requirements document to be completed under the new OpenSSO development process. I have to admit, it feels pretty strange having this out there in the open!
As I mention in the email, comments are welcome, so, please, sign up to the OpenSSO project and submit your feedback via the dev mailing list.
Dave ‘Wavy’ Holroyd of Good Technology reports on his production deployment of OpenSSO in the UK today on firstname.lastname@example.org. With his kind permission. I’ll just quote Dave here, lightly edited to turn his footnotes into hyperlinks:
Ok, so, in mid 2006 we rebuilt the Audi UK site to integrate with the Audi Global Content Management solution, and upgrade the previous, pre-J2EE technology platform. One of several features from the old site not included in the first delivery was the ability to log in to access special content and tools.
Having moved from a single-application model to a raft of independent webapps, that login functionality now requires a single sign-on solution. Also, given historical needs for integration with third-party systems and components, we wanted something based on well-thought-out Web Services, and a potential upgrade path to implement Federation.
Just before Christmas 2006, we deployed an OpenSSO system adapted with custom Authentication and Data Store plugins. These make use of the site’s existing relational database containing the profiles of around a quarter of a million registered users.
We integrated login and registration functions directly into our application rather than using the generic OpenSSO user interface. This enables access to functions like ‘ordering a postal brochure‘ by both authenticated and unauthenticated users, with the option for unauthenticated users to register toward the end of the process.
This is a great example of the kind of deployment that OpenSSO makes possible – Dave leveraged his visibility into the source code to create a solution customized to his needs, flagging some bugs in the process. Good, good, good, good, good… Good Technology!
I finally got round to completing Superpatterns’ migration from categories (exactly one category per post) to tags (zero or more tags per post). You can see the tag cloud at the top of the page (if you’re reading this through syndication you’ll have to visit my actual web page to see this). The size of each tag name in the tag cloud relates to the number of blog entries with that tag. If you still want to navigate by categories, they are listed in the dropdown near the top of the column on the right.
Thanks to Rich Sharples for the category chooser tip and to Dave Levy for the tag cloud idea.