Music / Security/identity · 23 Oct 2006

The future’s so bright I gotta wear shades

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 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…