Using Simple Web Token (SWT) with WIF

SAML 1.1/SAML 2.0 is the default token format when using ACS as the authentication service for your website. In this model, your website talks to ACS using WS-Federation protocol and what it normally gets back is a Saml token. This scenarios is fairly straight-forward as WIF natively supports WS-Federation protocol & SAML1.1/SAML 2.0 token formats.

There are cases where you might want to return a Simple Web Tokens (SWT) after a successful authentication. For example, you might want to use this same SWT (available as a bootstrap token) to call other downstream REST/OData services as depicted in the following diagram.

ACS fully supports returning an SWT token after a successfully WS-Fed authentication but WIF currently doesn’t support SWT tokens. You would have to write a custom Security Token Handler for WIF to process SWT tokens coming back to your website. I have created some extensions which enables this and other OAuth WRAP related scenarios. Feel free to download the code from my SkyDrive.

Silverlight Claim-Based-Security

This would hopefully be a multi-part series showing some tricks to enable claims-based-security in Silverlight 4.0. Silverlight 5.0 would have a much better story around claim-based-security as mentioned here.

In this first post, I’ll give you a high level overview of the solution. The main idea is to use the ‘WCF Routing Service’ in the DMZ to route both token issuance requests & business requests to the actual backend services.

1. Routing Service looks for a token issuing request and forwards it to the STS where the actual authentication is performed. After the successful authentication, STS issues a SAML token which goes back to Silverlight client via the routing service. Routing Service also terminates the SSL and backend is called using straight HTTP. This model offers strong security on the internet while keeping the internal deployment simpler & efficient. This model also resembles with the standard SSL offloading setup where a hardware load-balancer is used to terminate the SSL.

1: Token Issuance Path

2. Once the Silverlight client got a SAML token, it can attach it to all subsequent message sent to business service(s). Routing Services forwards al the business messages (messages which doesn’t match the token issuance filter) to the actual backend services again doing the protocol transitioning from HTTPS to HTTP. Please note, here you can use the rich filtering mechanism provided by the Routing services to decide which messages should to which services. I used a very simple MatchAll filter which forwards all the non-token-issuance messages to the business service.

2: Web Service Call Containing a SAML Token

To implement the 1st part of solution I have used the WSTrustClient class & the associated bindings from the identity training kit.

var vm = this.DataContext as MainPageViewModel;

var stsBinding = new WSTrustBindingUsernameMixed();

var stsCreds = new UsernameCredentials(vm.UserId, vm.Password);
var client = new WSTrustClient(
    stsBinding,
    new EndpointAddress(vm.SelectedEndpoint),
    stsCreds);

var rst = new RequestSecurityToken(WSTrust13Constants.KeyTypes.Bearer);
rst.AppliesTo = new EndpointAddress(vm.AppliesTo);

client.IssueCompleted += new System.EventHandler<IssueCompletedEventArgs>(client_IssueCompleted);
client.IssueAsync(rst);

For the 2nd part I have implemented a message inspector along with an extension method which makes it super easy to attach the SAML with outgoing messages.

var vm = this.DataContext as MainPageViewModel;
var client = new ServiceReference1.Service1Client();

client.AttachToken(vm.SecurityToken.RawToken);

client.GetDataCompleted += new EventHandler<ServiceReference1.GetDataCompletedEventArgs>(client_GetDataCompleted);
client.GetDataAsync(32);

Securing WF 4 Workflow Services

If you interested in an in-depth understanding of workflow services along with various security options. Then check out my latest MSDN magazine article.

http://msdn.microsoft.com/en-gb/magazine/gg598919.aspx

Associated Source code

Exposing Workflow Service over Azure Service Bus

In this post I’ll walk you through the steps of exposing a ‘Windows Server AppFabric’ hosted workflow service over the Azure service bus.  IIS/AppFabric hosted services are message activated so they cannot be visible on the servicebus until they are activated. So in this post, I’ll use the AutoStart feature of AppFabric to make my service available over service bus.

Create a workflow service project using Visual Studio

VS would generate a .xamlx based service and a default web.config file

The generated web.config uses the new WCF 4.0 default configuration option so no <service> tag was generated. If you run the service now, default endpoints would automatically be generated based on the base address of the service provided by the IIS.

Service bus endpoints requires an address in the service bus namespace so I can’t use IIS provided base address which means I can’t use the default endpoints feature. So the first set of changes would to be revert back to the old-style explicit endpoint definition.

    <services>

      <service name="Service1">

        <endpoint address="http://eval01.servicebus.windows.net/wfappfabric/" binding="ws2007HttpRelayBinding" contract="IService"/>

        <endpoint address="http://eval01.servicebus.windows.net/wfappfabric/mex" binding="ws2007HttpRelayBinding" kind="mexEndpoint"/>

      </service>

    </services>

The service name & contract name (‘Service1’ & ‘IService’) can be found from the properties of the workflow and the receive activity respectively.  Because I’m using an absolute address for my endpoint, WCF tells me to disable the multipleSiteBindings by removing the following element.

    <serviceHostingEnvironment multipleSiteBindingsEnabled="true" />

Next I’ll change the default ws2007HttpRelayBinding to disable security.

    <bindings>

      <ws2007HttpRelayBinding>

        <binding>

          <security mode="None" relayClientAuthenticationType="None" />

        </binding>

      </ws2007HttpRelayBinding>

    </bindings>

Configure the ACS security for the ServiceBus and specify the discovery mode to public so that I can see my service in the registry. All of this is done using a default a endpoint behavior.

      <endpointBehaviors>

        <behavior>

          <serviceRegistrySettings discoveryMode="Public" />

          <transportClientEndpointBehavior credentialType="SharedSecret">

            <clientCredentials>

              <sharedSecret issuerName="owner" issuerSecret="SECRET=" />

            </clientCredentials>

          </transportClientEndpointBehavior>

        </behavior>

      </endpointBehaviors>

Using the project properties, I’ll configure the service to run under IIS/AppFabric

I can now see my endpoints in the AppFabric management console but I can’t see my service in the Service Bus registry because it’s not activated yet.

So I need to configure Auto-Start feature on this service which I can easily do using the AppFabric management console.

After configuring AutoStart I can straight a way see my service in the registry

When I browse to my service I see the standard help page which the metadata URL

Download: Web.config