Since the first drafts of the SAML standard have been available, I’ve been delivering a talk called “SAML Basics” that introduced its major concepts and syntax. It has evolved as SAML has gone into new versions, as the identity management space and people’s understanding of it have grown, and as the work of the Liberty Alliance has expanded the scope of standards work in this area. For the XML 2005 conference in Atlanta, I took a tiny step back and put together a talk that covers the main SAML V2.0 (and Liberty Identity Federation Framework, or ID-FF) value propositions that are likely to be initially interesting to potential users. The talk is called “Federated Identity Management: An Overview of Standards and Concepts”. I have continued to modify my slides slightly, and will probably do more of this over time. I posted links to all this stuff here. (The entire set of XML 2005 proceedings should be available to the general public soon, I’m told.)
Russ’s UML diagrams seem sound as far as they go (I think — I’m no UML expert). I’ve been pressing for a little more use case information from the guys, which will go a long way towards determining the appropriateness of existing SAML patterns for what they want to do. Here are some brief thoughts I offered:
…from the glimpse I get from the new nuxle.us site and material provided by MD, it seems that nuxle.us would be, at the least, a SAML “identity provider” that takes care of authentication and authorization and shares such details with the other “service providers” in order to achieve single sign-on for users. If the service providers will also have distinct “accounts” for the same users rather than keying solely off nuxle.us authn/authz activity, you’d be looking at account linking across them.
In a scenario where nuxle.us and, say, ChannelXML want to safely exchange identity info about a user (such as online presence info or geographic location info) without bothering him/her in interactive fashion, that would be the world of Liberty ID-WSF (“identity web services framework”), where other stuff would come into play. For the simplest possible scenario of securing web services traffic without much of an identity exchange angle, you could be looking at plain WS-Security using SAML assertions as security tokens.
I pointed them to some potentially interesting open-source efforts: Sun’s OpenSSO, Internet2′s OpenSAML, and a French effort called Lasso. I guess we’ll see where this goes — it would be very interesting if SAML were to become a part of this new set of communities they’re putting together.No tags for this post.