Pat Patterson went and did it: He implemented the Service Provider (relying party) side of SAML V2.0’s browser/POST single sign-on profile…entirely in PHP. A number of people have been concerned that SAML is somehow just too hard to implement, particularly with that nasty XML Signature bit, but I think this shows the concern wasn’t warranted. He was apparently inspired by the ease with which Kim Cameron implemented InfoCard in PHP; of course, that has a significant SAML token-handling component, so there are a lot of similarities in what you have to do underneath.
At the same time, Jeff Hodges and Scott Cantor have continued to improve their SimpleSign and Lightweight SSO specs for doing SSO using SAML in an entirely XML-Signature-free way. The best way to keep up with this work is to track JeffH’s IdentityMeme.org blog. (He’s also got a recent post surveying the landscape of IETF I-D references to SAML, and other handy stuff.)
The next thing I’d love to see (I should get off my duff and do it, or at least browbeat Peter Davis into it — he’s the main guy behind the specs for SSO using both i-names and SAML) is a very simple spec showing how to use Yadis as the metadata and discovery component for SAML. With this, you could not only use Yadis for identities that have non-URL, non-XRI identifiers (such as the millions upon millions of “legacy” identities out there), but avoid some privacy issues as well.
The security considerations section of Peter’s spec profiling SAML for XRIs contains the seeds of everything you need to know to pull this off:
The use of XRI’s for authentication service discovery introduces a new potential correlation handle of the principal. Authentication service providers should carefully consider the risks associated with this shared identifier.
One suggested remedy is allow the principal to only supply the XRI of the authentication service provider (eg: @IdentityProvider), and not their personal i-name.
(I tried figuring out if the OpenID V2.0 work includes this approach as a possibility for URL-based identifiers, and it appears to go part of the way, though the underlying purpose seems to be different. Revision 10’s Appendix C.1 says “Supports IdP-driven identifier selection. This new variation of the protocol flow is initiated by entering an Identifier for an IdP instead of an Identifier for an End User, and allows the IdP to assist the End User in selecting an Identifier.” But I’m having trouble finding where in the normative spec this is defined.)
All in all, I think Pat’s lightbulb metaphor is apt — lightweight identity, shining a light on the identity issue, having the lightbulb suddenly go on, I get it, I get it. Now, with the “gotta wear shades” song in my head, I just have to avoid the next step down into earworm hell: “I wear my sunglasses at night”. Oh no! Too late! Even worse, the lyrics actually lend themselves to security and privacy themes…
Good IdP’s also offer a solution from “the other side” – instead of finding an RP and trying to log in to it – the IdP maintains a list of “bookmarks” for you, so when you want to log in to an RP – you click on it’s bookmark from inside your IdP – in other words – the RP only ever sees whatever identity you want it to – which might be an RP-specific one, or even an anonymous one: the main benefit being that you still need only 1 “main” identity, and no bots or google queries get a chance to link all your other identities back to you.
Hello Chris– Good point. This was basically the first key use case that SAML V1.x tackled, what eventually got called IdP-initiated SSO. This is the simplest possible flow, of course — no request for action, just authentication/authorization assurances pushed out at the right time.
We quickly found out, of course, just how appealing it is to be able to start at the service provider directly — so you can (e.g.) bookmark your favorite services directly and not have to start at a “portal” every time. So SAML V2.0 added the rest of the picture to make it more interoperable, since everyone was finding ways of doing it anyway (we had an interop test event at the RSA 2004 conference where this was the main complicating factor).
Partly because the SP-initiated version of the use case demands the same sorts of user choice that you’ve pointed out, and for a bunch of other reasons (protocol length/trickiness, UI design considerations…), it’s at least least twice as complicated as the other way. But it looks like it can’t be left out. :-)
Just when I had been able to expunge (embarassingly Canadian) Corey Hart from my memory, you bring him back in.