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.