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,
- 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
- Then, it evaluates the service’s policy using the above input information.
- 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.
Pingback: The case of the missing ‘Dialect’ (part 3) « Pedro Félix’s shared memory
Pingback: The case of the missing ‘Dialect’ (Part 4) « Pedro Félix’s shared memory
Pingback: The case of the missing ‘Dialect’ (part 5) « Pedro Félix’s shared memory