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.

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.