Thursday, May 17, 2012

Secure your ASMX WebServices with SWT and Claims

I was recently involved into interesting project, that was using the plain old ASMX web services. We wanted to migrate it to the Windows Azure Access Control Service and make use of Claims.

The way we achieved that is to add additional Soap Header to the client requests that includes Simple Web Token (SWT). On the server side, we make a check for this specific header existence, then extract the token, perform some validation checks and inject a fresh new Claims Identity into the Service instance. One thing to look out for is that you have to think of a workaround, if your ASMX WebService is a Singleton object. My implementation works with non-singleton implementations. And I currently get my Simple Web Tokens from Windows Azure Access Control Service’s WRAP endpoint. I have configured a “Password” service identities and I play with the RuleGroups to add additional claims, based on identity used. It is pretty flexible!

The result is on … GitHub. I initially wanted to be on CodePlex, because I have other projects there and am more used to TFS style of working. But CodePlex’s TFS is down for quite some time, which was a good excuse to use GitHub. There is some explanations in the Readme.txt file, as well as comments in the code. So feel free to get the code, play around with it, ping me if it is not working for some reason, and so on!

The project makes extensive use of SWT Implementation, done by the Two10Degrees’ team. But I added a compiled assembly reference for convenience.

Wednesday, May 16, 2012

MEET Windows Azure on June the 7th

I’m following Windows Azure since its first public CTP at PDC’2008. It was amazing then, it is even more amazing now, and more exciting to come (I’m really, really excited!) …

Get ready to MEET Windows Azure live on June the 7th. Register to watch live (June the 7th 1PM PDT) here. Be informed by following the conversation @WindowsAzure, #MEETAzure, #WindowsAzure

And, if you want to be more social, register for the Social meet up on Twitter event, organized by fellow Azure MVP Magnus Martensson.

What I can tell you for sure, without breaking my NDA, is that you don’t want to miss that event!

See you there!

MEET Windows Azure Blog Relay:

Tuesday, May 1, 2012

Introduction to Claims

It is 21st century! We live in a digital world where we can do almost everything online. While you might think this is an amazing, let me ask you a question: How many online identities do you have? And here I don’t only mean your Google or FaceBook account. I mean every single username and password you had to ever create. I personally, have about 8 (eight!) that I actively use (including a digital signature), another 10 or even more that are used fairly rare and maybe over 20, which I had to create by some reason, and then abandon. For me, as a consumer this drives me crazy. Just couple a weeks ago, I rejected an invitation to the next business social networking site, from a person who I really trust, just because that new network did not offer me an option to use any of mine existing identities. They required from me to create another user name, another minimum 6 symbols password containing upper and lowercase characters and numbers. No thanks. I’m done with creating online identities!

As being a developer, I also know that the easiest way to go with a site, which offers some kind personalization, is to use my own authentication and authorization mechanism! But this thinking I have left behind me. I decided to step into the present (not even the future!) and pay attention to terms like Identity Provider, Claims, Trust, Relying party application, and similar. Fortunately for me, there is the Windows Azure Access Control Service (or just ACS) on the market, that really helps me build applications that respond to the needs of the customers. Combining the power of ACS with Windows Identity Foundation (or WIF) I can easily create applications that would offer the consumers, the option to use some of their existing online identities (such as Microsoft Live ID, Google, Yahoo, Facebook and others).

If you want to join me, let me first list out the terms which you will begin working with on a daily basis:

Take a closer look to the following sentence: “I claim that my name is Anton Staykov, and I can prove it by showing you my personal Identification card, issued by the Bulgarian Government”. It represents almost all the terms and objects you will work with, when working with ACS.

Claim – this is an assertion about an object issued by an Identity Provider. In the given sentence, the Claim is “Name” and it value is “Anton Staykov”

Identity Provider – an authority, which issues security tokes, that contain claims. Bulgarian or any Government is an Identity Provider, which issues Passports. And the passports are

Security Tokens – this is a digitally signed object, which contains claims. A Token may contain one or more claims.

And last, but not least, you, dear reader are the Relying Party to which I present my token that contains claims.

There is one more player on the scene, and it is the Federation Provider. This, in essence is an Identity provider. It stays as mediator between mine application and your Facebook identity. When I want to give you the chance of using your FaceBook account to identify in front of mine application, I don’t want to bother with implementation details, which might (or might not) be very different from the details I need to know when I give you the option to sign with your Live ID. In my application I have a piece of code, where I say – look, I only trust Tokens and Claims that come from that federation provider. And that very federation provider takes care of implementation details around FaceBook, Live ID, Google, OpenID, WS-Federation, etc. And not only it takes care of these details, but even more. If, one day I decide that I no longer trust Google as Identity Provider, I just uncheck a checkbox, do nothing in my code, and you will no longer be able to use your Google account to present yourself in front of mine application.

As some final words, I want to share with you details from some studies conducted amongst online users about their perceptions about online shopping experience.

· 3 out 4 online shoppers avoid creating new user accounts

· 76% of online shoppers admit to have given incomplete or wrong information when required to create new user account

· 24 % of online shoppers abandon the site, when it requires a registration

With this said, I hope I made you believe (at least a bit) that Claims is the way to identify online user. And if you happen to be a developer, I really hope I have lighted up a small fire, which will drive you to at least investigate a bit more about Claims and social sign-in.