WS-Federation 1.1 and SAML 2.0 have different goals
What does WS-Federation provide that is not already addressed by SAML 2.0?
As I explained in a previous post,
WS-Federation extends WS-Trust to provide a flexible federated identity architecture with clean separation between trust mechanisms, security token formats, and the protocol for obtaining tokens. This architecture enables a reusable token service model and protocol to address the identity requirements of both web applications and web services in a variety of trust relationships.
WS-Federation was specifically designed to enable federations based on the WS-Trust token service model and protocol. The fundamental vision of WS-Federation is to complete the delivery of a suite of integrated, composable protocols (commonly referred to as the WS-* stack) to address the identity and security requirements of both web applications and web services. These were not design goals of SAML 2.0.
The original version of WS-Federation anticipated two distinct client profiles, Active and Passive Requestor Profiles. Customer experience has demonstrated that the Active Profile is not required; SOAP clients can use the WS-Trust and WS-Security protocols directly. By far the majority of the WS-Federation specification defines extensions to WS-Trust that are intended to be used directly by SOAP clients and web services.
One section of the WS-Federation specification defines encoding rules that enable many WS-Trust protocol features and WS-Federation extensions to be used by browser clients and web applications via standard HTTP 1.1 mechanisms. This section does duplicate functionality defined in the SAML 2.0 specifications.
This overlap arises from the WS-Federation goal to provide a common protocol for performing Federated Identity operations for both web services and browser-based applications. A common protocol provides economies with regard to development, testing, deployment and maintenance for vendors and customers alike. Failure to integrate browser and web service scenarios will multiply these up front costs, and may introduce even more painful and costly migration issues for customers in the future. The authors believe that the goals of WS-Federation 1.1 distinguish it from SAML 2.0 and provide benefits to the industry that are not available from any existing standard.
Robert Sherwood said,
May 4, 2007 @ 9:23 am
This is a critical, but very poorly understood point. I’m glad to see you weighing in on these topics.
Don Schmidt said,
May 9, 2007 @ 5:48 am
Robert, thanks for your support. I have been speaking at the 1st European Identity Conference in Munich, Germany this week. Your comment was echoed in several Q&A sessions. The audience appreicate a factual explanation of the differences between these specifications and the rationale for taking WS-Federation into the standards process. They lamented the scarcity of public documentation on this topic and asked for me to provide additional detail. Stay tuned.