The identity provider in BizTalk Services is a way for applications to delegate identity and access control to a hosted service. In other words, an application can use BizTalk Services to answer the all-important question "Who are you and what are you allowed to do?". If you haven't checked it out, I strongly recommend it (

The identity provider can be used without the connectivity service. The calculator sample in the SDK is an example (as of R10, it installs by default in the C:\Program Files\Microsoft BizTalk Services SDK\Samples\AccessControl directory). This entry examines the calculator sample that uses a certificate, and this blog post is not a substitute for reading the readme...

As indicated in the readme, running this sample requires you to login to, go to "Manage Access Control", "Rules", and setup a few claims mappings. After you login, click on the following (right hand side):


The Rules link takes you to a page that lets you map input claims to output claims. In the case of the Calculator sample, you are going to map BizTalk.NET usernames to Resource+Operation claims. These Resource+Operation claims are demanded by the calculator service (running on your machine). WCF shields you from quite a bit of the protocol level goo here. The following is an example of what it looks like in the web UI:


There's lots of interesting things going on here. For now, let me just focus on the Output Claim Value field. It's the concatenation of (in this case) the service URL, "#", the service contract name, ".", and the action of the operation:

<Value> ::= <Service Url> "#" <Service Contract Name> "." <Operation Action>

This may sound very scientific, but the reality is that it's simply a matter of a choice made by the ServiceAuthorizationManager derived type that's included in the Calculator sample (available at C:\Program Files\Microsoft BizTalk Services SDK\Samples\AccessControl\CalculatorServiceWithCertificate\FederatedAccessManager). You can change it to be whatever you want (of <Read> or <Write> could have been substituted for contract name + operation action).

After you setup the input and output claim mapping for the calculator service, you have a system like the following:


Step 1: Present identity claims to BizTalk.NET

Step 2: Receive the claims that are mapped to that identity

Step 3: Send those claims to the Calculator Service

Step 4: If the claim (URL+ContractName+Action) is present, the ServiceAuthorizationManager allows the WCF infrastructure to invoke the calculator implementation.

In effect, the calculator service delegates identity and access control to BizTalk Services.

I think that's way cool.