Call me sentimental … but when I started to think about writing this post, I immediately flashed on that great Lennon and McCartney song, “With a Little Help from My Friends.” Read on and you’ll see why.

Response to the unveiling of “Geneva” at the PDC last week has been outstanding! If you thought all those blogs about the Identity Metasystem were just talk … this is Microsoft putting its money where its mouth is. Improvements over ADFS and CardSpace v1 are huge. The Microsoft Federated Identity server, framework and client teams have worked long and hard. Every one of them deserves a curtain call with a standing ovation. It was particularly heartwarming to see Pamela’s acknowledgement of the Federated Identity team’s labors and accomplishments.

“Geneva” comprises a rich claims-based access feature set that will deliver on much of the promise of the Identity Metasystem vision. I just want to focus on the SAML 2.0 protocol support in this article. In the hope of being able to submit “Geneva” Server to the Liberty Alliance interoperability testing program, Liberty Interoperable, we have targeted the IdP Lite and SP Lite Operational Modes from the SAML 2.0 Conformance Requirements specification, plus the GSA Profile which is referenced by many governments around the world. That is still a lot of functionality and we had to determine what customers really needed so we could prioritize our development process accordingly. Microsoft did not do this alone. We had a Lot of Help from Our Friends.

We have been working with customers and other vendors for over a year to determine what features of the SAML 2.0 protocol are most commonly deployed. They unanimously agreed that the Web SSO Profile is what matters most. Based on actual customer deployments – augmented by extensive consultation with experts from the Shibboleth community, and precious insights from other vendors, including IBM, Ping Identity, SAP and Sun Microsystems – the SAML 2.0 feature prioritization for “Geneva” Server looks like this (in descending order).

- Web SSO AuthnRequest : HTTP redirect
- Web SSO Response : HTTP POST
- Identity Provider Discovery : Cookie
- Web SSO Response : HTTP Artifact
- Artifact Resolution : SOAP
- Single Logout (IdP-initiated) : HTTP redirect
- Single Logout (SP-initiated) : HTTP redirect
- Enhanced Client/Proxy SSO : PAOS

Patrick Harding, from Ping Identity, provided a most eloquent confirmation of the “Geneva” plan.

Ping Identity has partnered with Microsoft on numerous federated identity initiatives over the last few years – from the early work on WS-Federation to the more recent Information Cards interoperability events. It was extremely gratifying to have Microsoft recognize Ping Identity’s market leading success with SAML 2.0 when they reached out to us to ensure that Microsoft’s SAML 2.0 Web SSO profile implementation in its upcoming products will successfully interoperate with PingFederate.

Microsoft’s support for SAML 2.0 is a watershed moment in the identity management industry as it now allows deployers to focus on the business value of Internet SSO rather than concerning themselves and their business partners with protocol choice. Microsoft’s decision to focus on the IdP Lite, SP Lite and eGov interoperability profiles for SAML 2.0 also matches Ping Identity’s expectations as to what is the minimum bar necessary for deployers to successfully leverage SAML 2.0. I am looking forward to continuing to work with Microsoft to solve the next set of issues that will allow us to further simplify the effort involved in establishing federated identity connections.

Congratulations to all at Microsoft who were involved in enabling SAML 2.0 in Geneva.

We are working our way down the SAML 2.0 feature list above As anyone who has ever developed software knows, code isn’t finished until you test it. And that meant testing “Geneva” Server to prove its interoperability with other implementations. Again, we got a Lot of Help from Our Friends. We owe a huge debt of gratitude to the Shibboleth community (Scott Cantor from The Ohio State University, and Jim Fox from the University of Washington, in particular), IBM (Tony Nadalin, Shane Weeden, Neil Readshaw) and Ping Identity (Patrick Harding, Tom Doyle, Pasha Beneson).

We would not have finished the “Geneva” beta in time for the PDC without this incredible outpouring of help from the community. On behalf of Microsoft I extend our heartfelt gratitude. I guess this shows that the Identity Metasystem is bringing people together, as well as technologies.

At the Professional Developers Conference this week Microsoft is announcing the beta release of “Geneva”, the codename for its new claims based access platform.  This platform helps developers and IT professionals simplify user access to applications and other systems with an open claims-based model.  “Geneva” helps developers to externalize user authentication and identity processing from application code by using claims that are obtained with pre-built security logic that is integrated with .NET tools.  “Geneva” helps IT professionals to efficiently deploy and manage new applications by reducing user account management, promoting a consistent security model, and facilitating seamless collaboration across departmental, organizational and vendor boundaries.  User access benefits include shortened provisioning lead times, reduced accounts, passwords and logins, and enhanced privacy support.  “Geneva” implements the Identity Metasystem vision for open and interoperable identity, and includes built-in support for standard federated identity protocols.

A fundamental goal of “Geneva” is to extend the reach of its predecessor, Active Directory Federation Services, and provide a common identity programming model for developers of both web applications and web services.  To maximize interoperability with clients and servers from other vendors, it supports the WS-Trust, WS-Federation and SAML 2.0 protocols.  To maximize administrative efficiency “Geneva” automates federation trust configuration and management using the new harmonized federation metadata format (based on SAML 2.0 metadata) that was recently adopted by the WSFED TC.

WS-Trust is provided to support Information Card based Identity Selectors from third parties, as well as Windows CardSpace.  WS-Federation is required to maintain interoperability with existing federations being operated by government agencies, military organizations and business enterprises around the world.  “Geneva” support for SAML 2.0 was added in direct response to customer requests for increased cross-platform interoperability.  The benefits that are expected to accrue to customers, and the industry at large, are best summarized by Scott Cantor who is one of the key contributors to the SAML 2.0 standard and a Senior Systems Developer at the Ohio State University.

As a Shibboleth and OpenSAML project developer, and a deployer of the Shibboleth software at The Ohio State University, I’m excited and gratified that Microsoft is implementing the SAML 2.0 Web SSO profile in its upcoming products. Throughout the life of the Shibboleth project, and my work on the SAML 2.0 standard, our goal has been to leverage open standards to foster broad interoperability in federated identity within the higher education community and between it and its many commercial and non-commercial partners. Microsoft is clearly one of those critical partners, and as a key technology supplier, its support for the SAML standard reflects an understanding of our community’s needs and goals, and will expand the scope and impact of our efforts.

Our users will benefit by obtaining access to the broadest potential set of federated applications and services, and our worldwide community will benefit from the opportunity to deploy Microsoft’s identity solutions with the knowledge that they will interoperate with Shibboleth. Microsoft’s willingness to listen to our requirements and suggestions demonstrates a commitment to real-world compatibility. I look forward to continuing the dialog with Microsoft as we drive further interoperability in the use of federation metadata to scale and simplify both SAML 2.0 and WS-Federation deployments.

 

The fundamental purpose of federated identity is to enable subjects to use identities managed in one realm to gain authorized access to resources managed in other realms.  Requests to access resources are authenticated and authorized by the exchange of security tokens and the claims they contain.  Before seamless federated access can be granted, Identity Providers and Service Providers must configure their servers to agree on the types of tokens and claims that will be exchanged, and the keys that will be used to sign and encrypt them.  This configuration data is generically referred to as “federation metadata”; early implementations required this metadata to be manually entered on both sides of the relationship, which can be extremely error prone due to the lengthy URIs involved. 

A huge improvement in administrative efficiency can be gained by automating this configuration.  The key to automation is enabling IPs and SPs to publish their federation metadata in a standard format which can be exchanged between potential partners.  The Shibboleth community has demonstrated the effectiveness of this approach.  The SAML 2.0 standard includes the Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 specification [Samlv2Meta] that is devoted to standardization of a federation metadata format.

Federation metadata has also been a critical component of the WS-Federation specification that was submitted to OASIS.  A key goal has been to develop a single specification that can support both passive web application and active web service requestors.  In the interests of promoting engineering efficiencies for developers, and interoperability enhancements for deployers, the WSFED TC decided to make a substantive change to its federation metadata document structure during the first Public Review cycle.  WS-Federation has been revised to take a normative dependency on the SAML 2.0 federation metadata document structure.  The original format has been deprecated, although it is supported for backwards compatibility with early implementations.  The preferred format must be rooted in either the <md:EntityDescriptor> element or <md:EntitiesDescriptor> element from [Samlv2Meta].  The WS-Federation specification defines extensions for web services constructs (such as Endpoint References) that are required for WS-* protocols.

This work could not have been accomplished without the help of numerous SAML experts.  In particular I would personally like to thank Scott Cantor, Bob Morgan and Steven Carmody from the Shibboleth community, and Eve Maler and Pat Patterson from Sun Microsystems.  I believe this joint effort will significantly improve interoperability and reduce cost of ownership for enterprise class customers who typically deploy products from multiple vendors.  The harmonization dialogue between the WS-* and SAML communities has begun.  We can expect more to come.

Establishing a production federation between different organizations can be challenging.  A successful federated connection depends on numerous configuration and policy details being setup correctly at both ends.  If an application request fails, it can be difficult to track the failure back to an underlying configuration error, especially since an administrator at either partner only has access to half of the end-to-end system data.

Like most products Active Directory Federation Services provides trace logs to help solve these kinds of problems.  However, as any seasoned sysadmin knows, a high-level application request can spawn a multitude of underlying protocol messages.  Finding a single setup error by combing through the associated debug logs is tedious at best, and impossible if you do not know what to look for.  

The ADFS Test Team has filled the gap with tooling to verify that the underlying federation infrastructure is setup correctly.  They developed a new ADFS Diagnostics Tool that is available for free download on the web.  Administrators at each end of an ADFS-based federation can run the tool, share the output files, and quickly pinpoint configuration problems at their security token services (STS).  If ADFS is only used by the Relying Party partner in the federation, the tool can still be used to diagnose configuration problems between the STS and the application server.  One of Microsoft’s premier support engineers has posted the tool and provided a space for customers to ask questions and provide feedback.  He has high praise for how easy it is to perform low-level diagnostics of the complete distributed system.

The tool is very simple to use and provides a graphical UI. In order to perform distributed diagnosis, i.e. diagnose failures based on the configuration of multiple machines in the scenario, it’s necessary to copy the out file generated by the tool each time it’s run and use it as an input/output file when running the tool on the next machine.

For example, to debug a scenario with an FS at the account role (FS-A), an FS at the resource role (FS-R) and a Web Server (WS), first run the tool on the FS-A selecting a new file, say adfsdiag.out. After the tool is run, this file will now contain configuration information relative to the FS-A. Copy the file to the FS-R machine and run the tool there, this time selecting the existing adfsdiag.out file. The tool will detect it already contains information relative to other roles and will execute extra configuration checks, for example, a claim flow check that verifies the outgoing claims sent by the FS-A match the incoming claims expected by the FS-R. After this second run, adfsdiag.out will contain information relative to both the FS-A and FS-R. Finally, copy the out file to the WS machine and run the tool again following the same steps.

A number of large scale, production ADFS deployments came on line towards the end of last year.  Many more are in the pipeline.  This free tool has already proven to be priceless.  Try it and see for yourself.

This session was delivered by Ian Bailey (Director of Application Architecture, Office of the CIO, Provence of British Columbia, Canada) at Digital ID World in San Francisco.  A compelling session in its own right, it was also the coming out party for the BC Identity Management Architecture Project.

The provincial government leadership has taken a bold step to provide better outcomes for BC citizens through the use of online services and advanced identity management technology, such as Information Cards.  They organized a working group of government agencies and vendors to define an architecture that will enable critical, online access to services provided by the government and the broader public sector, while protecting the privacy of BC citizens.  The website spells out the scope and vision of the project.

The Office of the Chief Information Officer (OCIO) for the Province of British Columbia, with the advice and counsel of an executive committee of Broader Public Sector (BPS) Chief Information Officer’s (or equivalent), and key industry leaders have collaborated to develop an architecture that would enable an identity management service for the government and the BC BPS.

The goal of this project is to develop an identity management architecture to enable interoperation across a diverse range of public sector organizations and their service providers using multiple vendors’ technology solutions.

I have had the privilege to participate in this project. It has been an exhilirating experience to work with peers from so many BC government agencies and leading vendors in the identity management space. In addition to Ian, I especially want to congratulate Dave Nikolejsin (CIO) and Peter Watkins (Executive Director, Office of the CIO) for their vision and energy. And I want to thank Dick Hardt (CEO, Sxip Identity) for leading us in the development of a Claims Based Identity Management Architecture that I personally believe will become a model for governments and the broader public sector everywhere. This quote from the introduction of the Architecture Document should explain my enthusiasm.

Over the past three decades, the British Columbia Provincial Government and Broader Public Sector (BPS) organizations have invested heavily in the automation of business processes. Much of this investment has taken place only to meet a single organization’s unique local needs. It was usually done with limited consideration towards building interoperable cross-organizational information architecture.

To achieve the broader goals of the Province and improve service delivery, a mechanism must be created to securely share information between organizations and systems. An important piece of this mechanism is the development of common cross-organizational standards for interoperable identity management.

This is a complex issue to resolve when one considers the spectrum of public and private sector stakeholders involved: policy, management and administrative issues; privacy and security requirements for the management of access to information; and the various technologies in place. Compounding this architectural challenge is the fact that the Information Technology industry does not have an inclusive “off the shelf” solution. This project will require the British Columbia public sector to work with industry to build upon existing international standards in the development of a business and technology architecture to meet the secure information sharing needs of the BPS.

There is so much more I would like to share with you about this project. It is a profound endorsement of the industry wide convergence on Information Card technology and the underlying WS-* protocols and web services architecture. However, I have to catch another plane. So let me leave you with the knowledge that the BC government has also announced that they are taking the next step and moving the Identity Management Architecture Project from concept to reality. In his session, Ian described a pilot project that is expected to get underway this year.

Last week representatives from nineteen OASIS member organizations participated in the inaugural meeting of the WSFED TC which was formed to advance the WS-Federation specification through the international standards process.  Exploring the value of extending the WS-Trust Security Token Service model to provide simple Attribute Services emerged as one of the key interests of the members.  

A little background is helpful before plunging into this discussion.  WS-Federation 1.1 covers a variety of complex topics, some of which are challenging to understand from just the normative language in the specification.  Therefore, the co-authors contributed three other documents that were developed to explain the functionality addressed by this specification and the motivation for submitting it to OASIS for standardization.

1. Understanding WS-Federation whitepaper
2. Understanding WS-Federation slide deck
3. WS-Federation Overview slide deck

On the first day of the TC meeting Marc Goodner presented the “Understanding WS Federation” slide deck.  This session walked members through key features of WS-Federation using examples from the whitepaper, an Enterprise “request for proposal” scenario and a Healthcare “emergency room treatment” scenario.   On the second day, Anthony Nadalin and Don Schmidt presented the “WS-Federation Overview” slide deck.  This session explored how WS-Federation extends WS-Trust and reviewed almost all of the normative components of the WS-Federation 1.1 specification.

Both presentations elicited lively discussion and debate amongst the members.  The most recurring topics were:

• the need for standardized claim types and namespaces
• the relationship of WS-Federation to Attribute Services
• best practices for pseudonyms (logically a special type of attribute)

There is a clear pattern here.  The success of Federated Identity is dependent upon the ability to share a rich and commonly understood set of claims between an Identity Provider (IP) and a Relying Party (RP).

WS-Federation includes a common claims dialect that defines a syntax for IPs to serialize, and for RPs to de-serialize, arbitrary claim types.  It may need to be enhanced by the TC to accommodate more complex claim values than just strings, but the specification allows for this sort of extension.  Defining common namespaces and semantics for claim types could be accomplished by segmenting the work among communities of interest, such as, automobile manufacturing, defense contracting, higher education and healthcare.

In this post I want to elaborate on claims transformation as a mechanism for delivering basic Attribute Services to federation participants.  By claims transformation I mean the process by which a Security Token Service can exchange the claims from an input token for a corresponding, but different, set of claims in an output token.  We tend to focus on using security tokens to authenticate users and to protect the integrity and confidentiality of application messages.  However security tokens can carry claims, and claims are attributes.  The ability to translate or transform claims through a chain of Security Token Services is an immensely powerful construct.  My friend Kim Cameron certainly agrees.

The idea of claims transformation is the most important technical advance in distributed computing for at least a decade.

It is a straightforward extension of the STS model to provide attributes to relying parties. As described in the “WS-Federation Overview” slide deck starting with slide 29, attributes can be obtained by either  “inline” or “explicit” claims transformation.  Inline claims transformation is inherent to the basic federation model wherein both an IP and an RP deploy an STS to broker the trust relationship and simplify key management for the RP target application services.  In this scenario the application can publish its ”claim requirements” policy in terms of Application Claim Types that are only understood by the RP/STS and the target service.  The RP/STS can, in turn, publish its policy in terms of Federation Claim Types that are understood by all IP/STSs and RP/STSs in the federation.  A requestor will obtain its first security token from its IP/STS.  This will be exchanged for a token from the RP/STS.  This token exchange can automatically include inline claims transformation from Federation Claim Types to Application Claim Types.  Thus the target service can receive claims in exactly the form it requires.

In some instances the target service may need additional attributes beyond what is supplied in the requestor’s security token.  In this case, the target service may be able to use explicit claims transformation to exchange the original token from the requestor for a different token that contains the additional attributes.  For example, a supply chain application may need the discount rate of a purchaser.  Since this is information that must be calculated by the relying party based on past sales activity, it could be obtained by requesting a token that contains the discount claim for the customer identified in the  purchaser’s security token.  A WS-Trust RST/RSTR exchange would suffice for this kind of simple attribute request.

There may also be cases where the application needs an additional claim that must be obtained directly from the IP.  The Understanding Federation whitepaper contains an example in the healthcare scenario; emergency release of a patient’s medical records requires claims which assert that the requestor is a licensed physician and is currently on duty in a licensed emergency treatment center.  WS-Federation includes a SOAP fault that allows a relying party to express that additional tokens and/or claims are required to process the request.  Based on the exchange of Federation Metadata the systems can determine if the request could be automatically retried to provide the additional claims without user intervention.

The committee members agreed that the new SOAP fault – for identifying policy or metadata that is specific to a particular application request — is a powerful and useful mechanism.  It is particularly useful for obtaining claims from an additional IP that are required for application “exception cases” that cannot be conveniently expressed in static WS-SecurityPolicy documents.  In these situations, the SOAP fault mechanism is an example of inline claims transformation combined with a mechanism for failed operations to be automatically restarted with a high confidence of success. 

However, the committee recognized that completely retrying every request is too heavyweight of a mechanism for obtaining additional attributes from the requestor’s original IP.  In this case, the target service can retrieve Federation Metadata from the IP that issued the requestor’s token.  This metadata can include an AttributeServiceEndpoint statement.  If the interface to this service is implemented as an STS, the missing attribute could be obtained through explicit claims transformation using a WS-Trust OnBehalfOf RST/RSTR message exchange.

This discussion led to the observation that the STS model and claims transformation could be used to obtain claims from an attribute service, regardless of whether it was deployed by the RP, by the IP or by some well-known, third-party federation service provider.  It appears that existing WSDL and WS-SecurityPolicy techniques, augmented with Federation Metadata documents, are sufficient to locate such federated attribute services.

In all these scenarios there is a consistent set of benefits that accrue to application developers and IT staff. 

1. Claims can be delivered with the values and namespace that the application understands.  
2. If additional claims are required, they can be obtained without writing special code (LDAP searches, SQL queries, etc.) that is unique to the repository containing the data.
3. IT organizations can deploy federated authentication and attribute services that provide a common interface to end users and applications. 
4. Since an STS can provide a “Get claims” interface to most commonly used data stores, the risk can be eliminated of applications bringing down mission-critical repositories by making excessive, or ill-formed attribute lookup requests.  

Based on these considerations the WSFED TC members who participated in the inaugural meeting agreed that WS-Federation 1.1 extensions to WS-Trust can provide a simple, yet powerful federated Attribute Service through reuse of the STS model and claims transformation.  A richer Attribute Service functionality can be envisioned and more work in this space can be expected.  However, by reusing the STS model and the power of claims transformation we can solve numerous existing customer problems with minimal impact on infrastrucutre complexity.  This should should help contain the deployment and maintenance costs of Attribute Services.

The inaugural face-to-face meeting of the OASIS WSFED TC will be held on June 6-7.  As one of the authors of WS-Federation 1.1 I am delighted to have the opportunity for my work to be publicly reviewed and improved.  It is my personal opinion that specifications are harder to get right than code.  I don’t know about you, but I do not have a toolbox filled with compilers, debuggers and test-harnesses for developing good specifications. 

That said, I have high confidence that WS-Federation 1.1 is a valuable specification, one that warrants the investment of my peers’ time and energy to participate in the public review and standardization process.  Why do I believe this?  Because we have had the advantage of “Standing on the shoulders of giants.”  Much of our work has benefited from the technical accomplishments and customer engagements of colleagues in the Liberty Alliance Project and the OASIS Security Services (SAML) TC.  

Like my good friend Kim Cameron I want to extend my appreciation and thanks to everyone in the Liberty and SAML communities for their years of hard work and outstanding contributions.  And as he states so well, I want to affirm that the authors of WS-Federation 1.1 believe we have produced an evolutionary spec, not just an alternative one.

Liberty has contributed deeply to understanding a whole series of use cases and requirements, and the protocols, formats and concepts proposed by the SAML working groups have been an important step forward for all of us involved with identity. Nothing about WS-Federation invalidates this work.

On the other hand, technology doesn’t stand still. Think back to the days when SAML was first posited as an alternative to LDAP authentication. Those of us involved in LDAP from the very beginning didn’t for one minute take LDAP as the end of all thinking about attributes and identity. Ask LDAP guru Mark Wahl, or Bob “RL” Morgan or Keith Hazelton - people deeply involved in Kerberos and LDAP but just as willing to embrace new technologies like SAML as meeting new use cases.

Just as SAML broke new ground, WS-Federation is intended to address a number of things that people working in Web Services want better defined to facilitate interoperation using WS-Security and WS-Trust.

These protocols hadn’t even been invented when SAML evolved. The idea of claims transformation is the most important technical advance in distributed computing for at least a decade. It is so powerful that it wasn’t even fully understood until we began to build things with it. So how can anyone expect SAML to deal in an optimal way with the issues that ultimately emerged? This doesn’t detract from SAML’s successes. That’s not how software engineering works.

Many key contributors to theFederated Identity space have already joined the OASIS WSFED TC and will be participating in the meeting next week.  A few friends and key colleagues are noticeably missing.  WS-Federation would not be ready without the incredible contributions you have made to our industry, and the lessons we have all learned through your participation in other specification projects.  

I sincerely ask that you come and help do it again.

thx — des

Yesterday a White Paper, Understanding WS-Federation, was jointly published by IBM and Microsoft.  The primary goal of this paper is to promote an appreciation for the functional scope of the revised publication of WS-Federation.  As I have stated in previous posts, the scope of this specification extends far beyond the features delivered in first generation WS-Federation products, such as, Active Directory Federation Services v1.

The paper includes two use cases, an Enterprise “request for proposal” scenario and a Healthcare “emergency room treatment” scenario, that highlight key new features of WS-Federation 1.1.   Textual descriptions of the scenarios are annotated with sample XML message flows.

Another goal of this paper is to encourage participation in the OASIS WSFED TC.  Hopefully WS-Federation supporters and critics, alike, will find functionality that they care about, and be wiling to join in the open standards process for WS-Federation 1.1.

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.