Zulfiqar's weblog

Architecture, security & random .Net

Silverlight Claim-Based-Security

Posted by zamd on February 8, 2011


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

image

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

image

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);

About these ads

11 Responses to “Silverlight Claim-Based-Security”

  1. […] This post was mentioned on Twitter by Thomas Martinsen, Richard Dudley and Cornerstone, Jeremy Likness. Jeremy Likness said: #Silverlight claim-based security: http://bit.ly/hdaFUV […]

  2. […] client.GetDataCompleted += new EventHandler<ServiceReference1.GetDataCompletedEventArgs>(client_GetDataCompleted);client.GetDataAsync(32); Original post by Zulfiqar Ahmed on 8/02/11 here: http://zamd.net/2011/02/08/silverlight-claim-based-security/ […]

  3. Hi,
    When trying to reproduce this example developing a prototype, I have found that the tricky part is the routing service configuration,
    Do you have the code of this example?

    thank you for the post

  4. This is a nice situation to show the capabilities of the routing service, but im afraid, the routing service is not able yet to execute this scenario with federation binding .

  5. […] part 1 I talked about a simple approach to combine WCF Routing service and claims-based security and I got […]

  6. […] part 1 I talked about a simple approach to combine WCF Routing service and claims-based security and I got […]

  7. James said

    Excellent example, proved very helpful to SL app I’m working on, finally got my actively federated SL passing tokens to WCF services.

    I have one question, in a situation where a client logsout from my app and then login again under a different account how would I remove the existing token from the service call and provide the new one?

    Many thanks
    James

    • zamd said

      Hi James, Glad you found it useful :)

      The token gets associated with your WCF proxy so you can just dispose the WCF proxy to get rid of token. When user signs-in again you should get a new token and attach to the proxy agian.
      I hope that helps.

      Zulfiqar

  8. business messages…

    […]Silverlight Claim-Based-Security « Zulfiqar's weblog[…]…

  9. MSK said

    Hi,
    I am getting the following exception when requesting my adfs
    An error occurred while trying to make a request to URI ‘https://corpsts.com/adfs/services/trust/13/usernamemixed’. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: