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:

• http://identity.biztalk.net/sts/<username>/sts.wsdl, accessible via a straight HTTP GET.
• http://identity.biztalk.net/sts/<username>/mex, accessible via the WS-MetadataExchange protocol.

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.