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 (http://biztalk.net).

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 http://biztalk.net, go to "Manage Access Control", "Rules", and setup a few claims mappings. After you login, click on the following (right hand side):

image

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:

image

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:

system

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.