Discussions

News: Liberty Alliance: IBM finally joins, and maybe Microsoft is next

  1. IBM has become the latest company to join the Liberty Alliance, a global consortium aimed at developing standards for managing user identities. IBM joins and Intel as a backer of the effort, which Sun leads.

    Microsoft has also downgraded their Passport efforts, and there were rumors that they could join the game.

    What are your thoughts on the Liberty Alliance. Have you had any experiences with it?

    Read more: Liberty Alliance holdout IBM ends resistance
  2. If this ever becomes a reality, it will be one of the most important effects of the recent M$/Sun deal (they might in fact back eachother on this one)

    My only fear is that the WS-* specs will drive this, not actual user requirements. Not everyone buys into the contemporary SOA/WS craze.
  3. My only fear is that the WS-* specs will drive this, not actual user requirements. Not everyone buys into the contemporary SOA/WS craze.

    SOA is the strongest impetus for single sign on. Single sign on is fundamental to Oasis's WS-Security. WS-Security sponsors include Sun, Microsoft, BEA, and IBM.

    Contrast this with the feeble appreciation of single sign on in JCP's servlet and portlet literature. I suspect that most or all third party frameworks based on JSR-72 (Java GSS API) are comitted to migrating to WS-Security. I used WS-Security long before Oasis adopted it, and it's mature. Like it or not, WS-* has been the driver of single sign on. That's since only SOA has resource aggregation as a guiding principle. In contrast Monster.com, a tradional CGI-driven site, dumped MS's Passport. Traditional web sites have little demand for the sophistication of platform-neutral single sign on.
  4. Traditional web sites have little demand for the sophistication of platform-neutral single sign on.

    Why on earth restrict such a standard to web sites? Most enterprise applications are yet to be web based and they probably never will be.
  5. Exactly why, Han, are you disappointed by the current trend of WS-* driving single sign on standardization?
  6. Platform neutrality is not the issue. Cross-domain single-sign on is. By the very nature of cookies, one is not able to log one web-site of a federation and then access the other. An example of this is someone being able to log onto their university website say www.univ.com and be able to go to someother site www.someother.com and not be asked for authentication again. That is what Liberty and moreso Shibboleth are trying to do. Shibboleth is already gaining acceptance in educational institutions and is being used by them to provide access to web-based resources like Napster and more importantly to educational material from third party sources.
  7. By the very nature of cookies, one is not able to log one web-site of a federation and then access the other.

    Actually, this is not the issue as well. There are techniques allowing cross-domain cookie collection. For example, the Identity Provider Introduction profile specified in Liberty may use a "common domain cookie" to let the service provider figure out the identity providers the principle has been authenticated with recently. However, such cookie was never intended to provide a security context the service provider could rely upon. Regardless of the identity federation specification (WS-Federation, Liberty or SAML), the cross-domain single sign-on always involves a message exchange between the service provider and the identity provider that results in the authentication assertion issued by the latter. Upon receiving such an assertion, the service provider may create a local cookie that carries the local security context.

    The real issue in the cross-domain single sign-on is to use a standardized set of profiles to enable secure communication of identities between asserting and relying parties. IMHO, OASIS SAML 2.0 appears to be the most comprehensive set of specifications to this day that addresses this issue.
  8. IMHO, OASIS SAML 2.0 appears to be the most comprehensive set of specifications to this day that addresses this issue.

    How's Oasis SAML better than Oasis WS-Security?
  9. How's Oasis SAML better than Oasis WS-Security?

    Well, you can't compare these two specifications. SAML provides a set of profiles to support identity federation and single sign-on, while WS-Security defines lower-level SOAP message security like message signing and encryption. In the case when providers use SOAP bindings for SAML message exchange, they would use some elements defined in WS-Security specs.

    Perhaps the more appropriate comparison would be between SAML and WS-Federation profiles, but it is a different story.