The case of the missing ‘Dialect’ (part 2)

This is the second post of a series where I describe some issues regarding the definition and usage of claim requirements on the Windows Communication Foundation (WCF) platform. On the first post, I introduced the concept of claim requirements, and how to express them in WS-Policy and WCF. In this post I begin to introduce a usage scenario.

BizTalk Identity Services

(disclaimer: the information below refers to Community Technological Preview, so things will probably change in the future)

Among several other things, BizTalk Services provides a publicly-accessible STS for each registered user. This STS can play two different roles: Identity Provider or Resource side STS (R-STS). In the later role, this STS act as a Policy Decision Point (PDP), responsible for evaluating the service’s access control policy,

  1. First, it receives a token request from the service’s client with:
    • A description of the required authorization claims
    • The claims of the requestor
    • The address of the target service
  2. Then, it evaluates the service’s policy using the above input information.
  3. Finally, if the authorization claims are granted by the authorization policy, it issues a token with them to the requestor.

This R-STS can be used by:

  • Services with endpoints “hosted” by BizTalk Connectivity Services. In addition to the connectivity functionality, BizTalk Connectivity Services also plays the role of a Policy Enforcement Point, verifying if the messages received by the “hosted” endpoint contain security tokens with the required authorization claims.
  • Independent (“stand alone”) services, that is, services not hosted by BizTalk Services. In this case, the policy enforcement must be done by the service.

The policy of a BizTalk Services STS is defined by a set of rules. Each rule defines a mapping between one or more input claims (claims of the token requestor) and an output claim (claim present in the issued token). When playing the role of an R-STS, these output claims belong to the authorization dialect defined by WS-Federation (see last post).

The metadata of the STS is available at the following addresses:

where <username> should be replaced by the user’s name (remember that there is an STS for each registered user).

Observing the contents of this metadata (just register with BizTalk Services and point a browser to the above address) is a rather educative experience, that will be the subject of the next post in this series.

3 thoughts on “The case of the missing ‘Dialect’ (part 2)

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

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

  3. 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:

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s