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.