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