Update 2007-03-21: On March 19, 2007 OASIS acknowledged receipt of a draft TC charter proposal to create a Web Services Federation (WSFED) Technical Committee. The TC would accept as input the WS-Federation specification (Version 1.1) published by BEA Systems, BMC Software, CA, IBM, Layer 7 Technologies, Microsoft, Novell, and VeriSign. The revised WS-Federation specification Version 1.2 would extend basic federation capabilities enabled by WS-Security, WS-SecureConversation, WS-Trust, and WS-SecurityPolicy. Representatives from twenty-three companies provided statements of support for the charter proposal. See: "Proposed Charter: OASIS Web Services Federation (WSFED) Technical Committee."

Update 2004-03-05: The WS-MetadataExchange specification referenced in the WS-Federation document has now been published. The WS-MetadataExchange specification is said to be part of the Web services roadmap for WS-Federation. WS-MetadataExchange "describes how to exchange metadata such as WS-Policy information and WSDL between services and endpoints." See details in the news story "Web Services Metadata Exchange (WS-MetadataExchange) for Service Endpoints."

[July 08, 2003] BEA, IBM, Microsoft, RSA Security, and VeriSign have released a new Web Services Federation Language (WS-Federation) specification which defines mechanisms "used to enable identity, account, attribute, authentication, and authorization federation across different trust realms. The specification extends the WS-Trust model to allow attributes and pseudonyms to be integrated into the token issuance mechanism to provide federated identity mapping mechanisms. The models defined in WS-Security, WS-Trust, and WS-Policy provide the basis for federation; WS-Federation extends this foundation by describing how these models are combined to enable richer trust realm mechanisms across and within federations."

Supporting profiles include: (1) the Passive Requestor Profile, which "describes how the cross trust realm identity, authentication and authorization federation mechanisms defined in WS-Federation can be utilized used by passive requestors such as Web browsers to provide Identity Services (under the HTTP protocol)"; and (2) the Active Requestor Profile, which defines how federation mechanisms are used by active requestors such as SOAP-enabled applications.

Because participation in a federation "requires knowledge of metadata such as policies and potentially even WSDLs and schemas for the services within the federation, a variety of specified mechanisms may be used to acquire metadata, as outlined in the WS-Policy and WS-MetadataExchange specifications. WS-MetadataExchange is a set of Web service mechanisms to exchange policies, WSDL, schema and other metadata between two or more parties. WS-MetadataExchange is part of the Web services roadmap for both WS-ReliableMessaging and WS-Federation" and is planned for public release in Summer 2003.

Summary: "The Web Services Federation specification is another component of the Web Services Security model that defines mechanisms to allow different security realms to federate by allowing and brokering trust of identities, attributes, authentication between participating Web services. The mechanisms defined in this specification can be used by passive and active requestors. The Web service requestors are assumed to understand the new security mechanisms and be capable of interacting with Web service providers." (IBM)

Bibliographic Information

Web Services Federation Language (WS-Federation). By Siddharth Baja (VeriSign), Giovanni Della-Libera (Microsoft), Brendan Dixon (Microsoft), Mike Dusche (Microsoft), Maryann Hondo (IBM), Matt Hur, Microsoft), Chris Kaler (Editor, Microsoft), Hal Lockhart (BEA), Hiroshi Maruyama (IBM), Anthony Nadalin (Editor, IBM), Nataraj Nagaratnam (IBM), Andrew Nash (RSA Security), Hemma Prafullchandra (VeriSign), and John Shewchuk (Microsoft). Draft Version 1.0. July 8, 2003. 41 pages. Copyright (c) IBM, Microsoft, BEA Systems, RSA Security, and VeriSign.

WS-Federation: Passive Requestor Profile. By Siddharth Baja (VeriSign), Brendan Dixon (Microsoft), Mike Dusche (Microsoft), Maryann Hondo (IBM), Matt Hur (Microsoft), Chris Kaler (Editor, Microsoft), Hal Lockhart (BEA), Hiroshi Maruyama (IBM), Anthony Nadalin (Editor, IBM), Nataraj Nagaratnam (IBM), Andrew Nash (RSA Security), Hemma Prafullchandra (VeriSign), Yordan Rouskov (Microsoft), John Shewchuk (Microsoft), and Jeff Spelman (Microsoft). Draft Version 1.0. July 8, 2003. 32 pages.

WS-Federation: Active Requestor Profile. Siddharth Baja (VeriSign), Giovanni Della-Libera (Microsoft), Brendan Dixon (Microsoft), Maryann Hondo (IBM), Matt Hur (Microsoft), Chris Kaler (Editor, Microsoft), Hal Lockhart (BEA), Hiroshi Maruyama (IBM), Anthony Nadalin (Editor, IBM), Nataraj Nagaratnam (IBM), Andrew Nash (RSA Security), Hemma Prafullchandra (VeriSign), and John Shewchuk (Microsoft). Draft Version 1.0. July 8, 2003. 18 pages.

The IBM and Microsoft White Paper

IBM and Microsoft have published a joint white paper Federation of Identities in a Web Services World which defines the federated identity management problem and surveys the primary goals of federated identity services:

[The paper] "describes the issues around federated identity management and describes a comprehensive solution based on the Web services specifications outlined in the WS-Security roadmap and other related Web services specifications. The approach described in this whitepaper, which will be further defined in the WS-Federation specification, introduces an identity provider as a class of security token service. As such, it uses the mechanisms of WS-Trust and WS-Federation to create and broker trust within and across federations. Additionally, mechanisms are defined for single sign-in and sign-out, sharing of attributes based on authorization and privacy policies, and integrated processing of pseudonyms (aliases used at different sites/federations). Together, the specifications identified in this paper provide a comprehensive and integrated set of protocols for secure reliable transacted messages in and across federations by composing with other security and Web service specifications..."

Excerpts from Web Services Federation Language (WS-Federation)

"By using the XML, SOAP and WSDL extensibility models, the WS* specifications are designed to be composed with each other to provide a rich Web services environment. WS-Federation by itself does not provide a complete security solution for Web services. WS-Federation is a building block that is used in conjunction with other Web service and application-specific protocols to accommodate a wide variety of security models..."

Requirements: The following list identifies the key driving requirements for this specification:

• Enable appropriate sharing of identity, authentication, and authorization data using different or like mechanisms
• Brokering of trust and security token exchange
• Local identities are not required at target services
• Optional hiding of identity information and other attributes...

Model:

As described in WS-Trust, WS-PolicyAssertions can indicate that a Web Service requires a set of claims, codified in security tokens and related message elements, in order to process an incoming request. Upon evaluating the policy, if the requester does not have the necessary security token(s) to prove the required claims, it may use the mechanisms described in WS-Trust to use security tokens (or secrets) it has already to acquire additional security tokens.

This process of exchanging security tokens is typically bootstrapped by signing-on to obtain initial security tokens using either the mechanisms already defined in WSTrust or the mechanisms defined in this specification. WS-PolicyExchange mechanisms are used to enable to the requestor to discover applicable policy, WSDL and schema about the endpoint.

These initial security tokens may be accepted by various Web services or exchanged at security token services (STS) / Identity Providers (IP) for additional security tokens subject to established trust relationships and trust policies as described in WS-Trust.

This specification also describes Attribute/Pseudonym services that can be utilized to provide mechanisms for restricted sharing of principal information and principal identity mapping (when different identities are used at different resources). WSPolicyExchange mechanisms are used to enable to the requestor to discover the location of various Attribute/Pseudonym services.

From WS-Federation: Passive Requestor Profile

"The WS-Federation specification defines an integrated model for federating identity, authentication and authorization across different trust realms and protocols. This specification defines how the WS-Federation model is applied to passive requestors such as Web browsers that support the HTTP protocol.

For the passive mechanisms to work seamlessly and provide a single or reduced sign-on, there needs to be a service that will verify that the claimed requestor is really the requestor. Initial verification must occur in a secure fashion, for example, using SSL/TLS or HTTP/S.

Subsequent verifications of passive requestors may use custom mechanisms or cookies to optimize the flow. However, use of cookies may suffer from the certain security risks. It is strongly recommended that if cookies are used, that the discard attribute as defined in RFC 2965 be used.

Aside from the discard issue, artifacts and cookies still suffer from replay attacks. Passive requesters should consider using stronger methods of authentication such as digest authentication (RFC 2617) and the HTTP Security Extensions. Such mechanisms may be used to authenticate to the Web server, if it supports such mechanisms.

From WS-Federation: Active Requestor Profile

This specification defines how the cross trust realm identity, authentication and authorization federation mechanisms defined in WS-Federation are used by active requestors such as SOAP-enabled applications.