Why is WS-Federation being republished and proposed for standardization now?

The original version of the WS-Federation specification was developed through open workshops and vendor interoperability testing, in keeping with the WS-* Specification Process. When WS-Federation 1.0, was published in July 2003 we anticipated two distinct types of federation clients, Active and Passive Requestors. At that time our focus was on Web Single Sign-on (Web SSO) for browser clients and web applications, so we drafted a profile for passive requestors.

Driven by customer demand for Web SSO solutions, numerous vendors built prototypes based on this fledgling profile. There was one defining event which convinced many of us that it was time to develop commercial products. This was the Multiprotocol Federation Interoperability Demonstration hosted by the Burton Group at their Catalyst Conference North America in July, 2005. Today many vendors are shipping (or have announced development of) Web SSO products based on WS-Federation 1.0.

During this time the concept of Federated Identity has garnered a great deal of interest from a wide variety of sources. The computer, security and identity industries have come to greatly improve their understanding of the ways in which identity information is most effectively federated. Customer experience has indicated that an Active Requestor Profile is not required; SOAP requestors can use the WS-Trust protocol directly. Since support for browser-only clients is such a small part of WS-Federation, a separate Passive Requestor Profile is no longer warranted. The draft passive profile has been incorporated to ensure backwards compatibility with released products. The republication of WS-Federation 1.1 incorporates this improved understanding and enables several enhanced scenarios.

At the previously mentioned Catalyst Conference, Microsoft and IBM announced plans to submit three WS-* specifications, WS-Trust, WS-SecureConversation and WS-SecurityPolicy, to OASIS. The ratification of these specifications as OASIS standards is almost complete.

WS-Federation is the capstone of the web services security stack. A fundamental goal is to provide a common protocol for performing Federated Identity operations for both web services and browser-based applications. A common protocol simplifies product development, testing, deployment and maintenance for vendors and customers alike.

The authors of WS-Federation believe that this specification is ready to complete the journey begun in the WSS and WS-SX Technical Committees. Please join us in the WSFED TC and help ratify WS-Federation 1.1 as an OASIS standard.

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.

How does WS-Federation relate to the WS-Trust specification that was recently ratified as an OASIS standard?

WS-Trust lays the foundation for federation by enabling SecurityToken Services (STS) to broker trust between resource and identity providers; it provides an application-independent protocol for requesting, issuing, renewing and validating security tokens.

WS-Federation breathes life into the federated relationships envisioned by WS-Trust. WS-Federation enables development and deployment of advanced federation services (e.g. Authentication, Authorization, Attribute and Pseudonym Services) as special purpose variations of the WS-Trust STS claim transformation model. Managing, discovering and accessing such services can be simplified when they are all based on a common processing model and speak the same protocol. Further, reusing an established processing model and protocol can simplify the threat model for implementers and should lead to more robust code.

Customers have indicated that manually configuring federation trusts – particularly exchanging signing keys and specifying service endpoints and access policies – is an onerous process when they have many partners. WS-Federation defines a Federation Metadata format to identify services, including the communication and security policies which must be satisfied for accessing them. This enables much of the configuration to be automated.

Another significant benefit of WS-Federation is improved security through “automated de-provisioning” of external user access. If a Relying Party issues local accounts for external users from its partners, it may not immediately learn when those users have changed responsibilities or been terminated. Such accounts could be misused to obtain unauthorized access. WS-Federation enables a Federated Identity relationship wherein a user can no longer access a partner’s resources as soon as he is unable to obtain a valid security token from his own organization.

The WS-Federation Language 1.1 specification was published for public review and comment in December 2006. On April 13, 2007, the Organization for the Advancement of Structured Information Standards (OASIS) called for participants to join the proposers of a Web Services Federation Technical Committee to drive standardization of the WS-Federation protocol. Today OASIS announced formation of the WSFED TC to undertake ratification of the WS-Federation 1.1 specification as an OASIS standard.

These actions have sparked a spirited debate in the blogosphere, paraphrased as:

How does WS-Federation relate to the WS-Trust specification that was recently ratified as an OASIS standard?

What does WS-Federation provide that is not already addressed by SAML 2.0?

Why is WS-Federation being republished and proposed for standardization now?

These are good questions. They demonstrate that the open standards process is alive and well in the Federated Identity space. The answers to all three questions have this in common.

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.

As one of the authors of WS-Federation I will do my best to provide more detailed explanations of our motivation in subsequent posts.

Federatied Identity is an approach to identity management that allows one organization to grant or deny access to its protected resources based on digital identities managed by another [trusted] organization. The key point is that the resource provider relies on an externally managed identity, rather than creating another locally managed identity for the subject requesting access.

Wikipedia defines it as follows.

Federated identity, or the ‘federation’ of identity, describes the technologies, standards and use-cases which serve to enable the portability of identity information across otherwise autonomous security domains. The ultimate goal of identity federation is to enable users of one domain to securely access data or systems of another domain seamlessly, and without the need for completely redundant user administration.

Federated Identity can reduce IT costs, improve user experience, and increase security in collaborative environments.

1. The IT department of the resource provider does not have to create accounts , invest in account life-cycle management, or pay Help Desk costs to reset passwords for external users that are not even members of the organization.

2. External users do not have to wait for the resource provider’s IT department to create accounts before they can begin working on the project. They can logon once for access to local and remote resources rather than having to remember a different ID and password for every collaborative project they work on.

3. Access control decisions are based on fresh knowledge of the authorization status of external users. If an external user is terminated there is no stale account at the resource provider that could be misused to gain unauthorized access.