Protocol Bridge Claims Provider

Table of Contents


Disclaimer 1

Getting Started. 1

Configuring an ASP.NET application to use the Multi Protocol STS.. 4

Configuration. 7

General Properties. 7

Claims Providers. 8

Scopes. 9

More info. 10

The story behind. 10

Known Issues. 11

Main contributors. 11



This code is provided as-is under the Ms-PL license. It has not been tested in production environments and it has not gone through threats and countermeasures analysis. Use it at your own risk.

Getting Started

The Multi Protocol Security Token Service is a WS-Federation aware token issuer that allows bridging with other authentication protocols like OpenID, OAuth or other custom protocols like LiveID.

Once installed, open a browser and go to one of the sample web applications https://localhost/SampleRP. This is the flow between the web application (ASP.NET MVC with WIF), the STS (ASP.NET MVC with WIF) and Yahoo identity provider (OpenID).

Configuring an ASP.NET application to use the Multi Protocol STS

The following step by step instructions show how to configure an ASP.NET application to trusts the Protocol Bridge Claims Provider.

1.    Open Visual Studio 2008 (or 2010)

2.    Create a new ASP.NET Web Site

3.    Right click on the project and press Add STS Reference…

4.    Leave the default values but add Default.aspx in the Application URI textbox.


5.    Select Use an existing STS and enter the url of the multi protocol STS (the installation will create an entry in the HOSTS file and virtual directory in IIS default website). The default url is Press Yes when the certificate warning shows up.


6.    Select No encryption and press Next. By default the Multi Protocol STS does not encrypt tokens.

7.    These are the claims offered by the STS. Press Next

8.    Press Finish.

9.    Replace the Default.aspx markup with this (this markup will extract the claims from the IClaimsIdentity of the principal and  show them)


<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" ValidateRequest="false" %>


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "">


<html xmlns="">

<head runat="server">




    <form id="form1" runat="server">


    <% foreach (var claim in ((Microsoft.IdentityModel.Claims.IClaimsIdentity)User.Identity).Claims)

       {  %>

       <strong><%=claim.ClaimType %></strong>:<%=claim.Value %><br />

    <% } %>





10.  Open the Multi Protocol STS Web.config and add the following scope to the list of scopes.





      useClaimsPolicyEngine="false" />



General Properties

The Multi Protocol STS has some general properties


<multiProtocolIssuer identifier="" responseEndpoint="">

  <signingCertificate findValue="CN=localhost" storeLocation="LocalMachine" storeName="My" x509FindType="FindBySubjectName"/>


Configuration Attribute/Element



The identifier of the STS (an arbitrary URI)


An endpoint that would accept the HTTP response (if any) from the different protocols


the X509 certificate used to sign the outgoing tokens


Claims Providers

In the Multi Protocol STS, a claims provider is an authoritative source of claims. These are configured in the Web.config as shown below. A claims provider talks a specific protocol (OpenID with Attribute Exchange, OpenID with SReg, OAuth 2.0, a custom protocol, etc.), so a claims provider is linked to a protocol handler, a class that implements the protocol. The Multi Protocol STS was tested against three well known claims provider: Yahoo, Facebook and LiveId.



        <add identifier="urn:Yahoo:AX" url="" protocolHandler="OpenIdAxHandler" profile="AX" />

        <add identifier="urn:LiveId" url="" protocolHandler="LiveIdHandler" allowCompleteProfileForm="true">


            <add key="wll_appid" value="000000004403607C"/>

            <add key="wll_secret" value="IbAu38iuwwRbst5vl1CuJRfHx3e7vcWl"/>

            <add key="wll_securityalgorithm" value="wsignin1.0"/>



        <add identifier="urn:Facebook" url="" protocolHandler="FacebookHandler" profile="OAuth2.0">


            <add key="api_url" value="" />

            <add key="application_id" value="122744481090516" />

            <add key="api_key" value="b61ec28402117d024abc235177c82e92" />

            <add key="secret" value="51fb4330162e14914832131f39f8a530" />





Configuration Attribute/Element



The identifier of the claim provider (an arbitrary URI). This identifier has to match with the whr parameter used in the website that hosts the STS. Clicking on one of the logos, will redirect to /authenticate?whr=identifier-of-the-claims-provider


The endpoint of the claim provider where the user will be redirected


The friendly name of the protocol handler class that will process the sign in request and response. The list of protocol handlers can be found in the Web.config in the <unity> section.


The profile implemented within the particular protocol. This attribute is just informative and does not change any runtime behavior


A set of key value pairs that will be sent to the protocol handler. Typically, this key value pairs will hold API keys, app identifiers, etc. needed to talk against the claim provider

Note:  if you will use this in a real application make sure to change the default parameters.



In the Multi Protocol STS, a scope is the application that is requesting a token. These are configured in the Web.config as shown below and represent a white-list of applications that can use the STS.


<scope uri="https://localhost/SampleRP" identifier="https://localhost/SampleRP" useClaimsPolicyEngine="true">


    <add type="" name="name" demandLevel="Request" />

    <add type="" name="email" demandLevel="Request" />

    <add type="" name="gender" demandLevel="Request" />


    <add type="" name="name" demandLevel="Request" />

    <add type="" name="email" demandLevel="Request" />

    <add type="" name="gender" demandLevel="Request" />


    <add type="" name="email" demandLevel="Request" />





    <add name="urn:Yahoo:AX" />

    <add name="urn:MyOpenID:Sreg" />

    <add name="urn:AOL:AX" />

    <add name="urn:LiveId" />

    <add name="urn:Facebook" />





Configuration Attribute/Element



Required. The identifier of the scope (an arbitrary URI). This identifier has to match with the wtrealm parameter sent by the web application.


Required. The endpoint of the scope where the token will be posted back if no wreply parameter was sent.


Optional (default false). If false, all the claims coming from the claim provider will be copied to the output token. If true, a rules engine will be used to transform the incoming claims to outgoing claims. This engine uses XML to author the rules. See the Claims Policy Engine for more details [TBD].


Optional. Some of the protocols (like OpenID) require to specify the claim types to demand from the claim providers. This section allows configuring what claims should be requested for a specific application. Depending on the implementation of the claims provider it will ask the user to give consent about the disclosure of those claims. Each claim has a demand level (NoRequest, Request, Require).


Optional. A set of claim providers allowed for a specific application. The intended usage of this is to show/hide the logos on the identity selector web page. It does not affect the runtime behavior.

More info

The story behind

This work is the result of a proof of concept we did with the Microsoft Federated Identity Interop group (lead by Mike Jones), Medtronic and PayPal. The business scenario brought by Medtronic is around an insulin pump trial registration. In order to register to this trial, users would login with PayPal, which represents a trusted authority for authentication and attributes like shipping address and age for Medtronic. However, authentication alone is not enough for the purpose of the trial. Medtronic wants to enrich the identity of the user with other attributes that belong to their realm. In essence, they are doing an identity mash up and using this “mashed” token to access other applications/services. An example of this kind of applications is a site we created called Contoso Opinions that allowed users with a Medtronic token (containing PayPal and Medtronic attributes) to comment about their experience with the device.

While there are many ways to solve a scenario like this, we chose to create an intermediary Security Token Service that understands the OpenID protocol (used by PayPal), WS-Federation protocol and SAML tokens (used by Medtronic apps). This intermediary STS would also allow SSO between the web applications, avoiding re-authentication with the original identity provider (PayPal). The idea of this protocol transition/bridge STS was originated in Vittorio Bertocci’s blog and then Matias Woloski posted an initial implementation on his blog.

We decided together with the Microsoft Federated Identity Interop team to make the implementation of this intermediary multi protocol STS available under open source.

Known Issues

·         Single sign on is not working properly with web applications hosted in localhost.

·         The allowedClaimProviders configuration does not alter the behavior of the STS

·         Exception handling can be enhanced with more detailed errors

·         No performance/stress test has been done

Main contributors

·         Juan Pablo Garcia (blog: twitter: @jpgd mail: juanpablo dot garcia at southworks dot net)

·         Matias Woloski (blog: twitter:@woloski mail: matias at southworks dot net)


2010-05-30 17:06:42