The case of the missing ‘Dialect’ (Part 1)

This is the first post of a series where I describe some issues regarding the definition and usage of claim requirements on the Windows Communication Foundation (WCF) platform.


The constraints and requirements of a WCF service can be expressed by a policy, defined according to the WS-Policy spec framework. Typically, this policy is automatically generated from the endpoint’s binding information and embedded into the service’s WSDL.

A policy is composed by assertions, that define specific constraints and requirements. The WS-SecurityPolicy spec defines a set of security specific assertions. One of those is the <IssuedToken> assertion, that is used by services to require security tokens issued by token issuers. The “parameters” of this assertion include:

  • An endpoint reference to the token issuer, optionally including the issuer’s address and metadata location
  • A set of elements that should be present in the request made by the client to the issuer. These elements, defined by the WS-Trust specs, define aspects such as:
    • The requested token and key types.
    • The required claims – claims that should be present in the issued token.

The required claims are defined by the <Claims> element, present inside the <IssuedToken> assertion and on the request sent by the client to the token issuer. This <Claims> element supports different ways of expressing the claims requirements. For that purpose, it contains a Dialect attribute (an URI) indicating the specific language used inside the <Claims> element.

The WS-Federation spec (version 1.1) defines a specific dialect for expressing authorization claims, depicted in the following XML

1: <wst:Claims

2:        Dialect=””>

3:    <auth:ClaimType Uri=“xs:anyURI” Optional=“xs:boolean”>

4:       (<auth:Value>…</auth:Value> | xs:any) ?

5:    </auth:ClaimType> *

6: </wst:Claims>

The Information Card Profile also defines a claim dialect where a required claim is represented by a <ClaimType> element:

1: <wst:Claims Dialect=””>

2:    <ic:ClaimType Uri=”http://…/ws/2005/05/identity/claims/givenname”/>

3:    <ic:ClaimType Uri=”http://…/ws/2005/05/identity/claims/surname”

4:       Optional=”true” />

5: </wst:Claims>

WCF directly supports this last dialect via the Security.Message.ClaimTypeRequirements property of both WFederationHttpBinding and WS2007FederationHttpBinding. This property represents a collection of ClaimTypeRequirement, where the claim types required by the service can be added.

In principle, it is also possible to use another dialect with WCF. In WS-SecurityPolicy, the <Claims> element is contained inside the <RequestSecurityTokenTemplate> element, which can be populated via the Security.Message.TokenRequestParameters property of any federation binding. This property represents the collection of XmlElement that are childs of the <RequestSecurityTokenTemplate>.

4 thoughts on “The case of the missing ‘Dialect’ (Part 1)

  1. Pingback: The case of the missing ‘Dialect’ (part 2) « Pedro Félix’s shared memory

  2. Pingback: The case of the missing ‘Dialect’ (part 3) « Pedro Félix’s shared memory

  3. Pingback: The case of the missing ‘Dialect’ (Part 4) « Pedro Félix’s shared memory

  4. Pingback: The case of the missing ‘Dialect’ (part 5) « Pedro Félix’s shared memory

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s