Almost every organization I have ever worked at, with, or for has discussed and dreamed about implementing a Single Sign On (SSO) solution for either some or all of their applications and/or websites. It is a very interesting and enticing prospect to be able to enable your users to enter one username and password in order to access multiple applications. I am not going to take the time to explain SSO any more than that but if you are not familiar with SSO or would like to learn more about it there is a plethora of blogs and articles on the internet that should help get you up to speed.

In this series of blog articles I am going to go over a way I have found to very quickly and easily implement a SSO solution - without writing a lick of code! But I won’t stop there; the solution I will suggest will also enable your organization to authenticate your users via one or more of the many well known identity providers out there such as Active Directory Federated Services, Google, Live, Facebook, and more – or you can roll your own if so inclined. Finally I will take this SSO solution and extend it to your Windows based applications as well.

In this first part I am going to introduce you to the underlying framework that will be doing most of the work. While I don’t expect you to understand everything about this framework, I do want to point out its existence and role in our solution. If you are developer or you are at an organization that is going to want to write their own identity provider then you are going to want to know about the framework.

At the center of our solution is Microsoft’s Windows Identity Foundation (WIF). Until recently it was an add on framework but starting with .NET Framework 4.5, WIF has been fully integrated into the .NET framework. At it’s core WIF is a framework for building identity-aware applications; it abstracts the WS-Trust and WS-Federation protocols and presents developers with APIs for building security token services and claims-aware applications. I won’t go into too much detail about the framework but I do want to point out the major parts of the framework because when I get to my solution for SSO you will need to have a basic understanding to appreciate what it does for you.

I do want to point out that WIF is based on a concept called the Claims-Based Identity Model which simply means that a user in your applications is presented as a set of claims. One claim could be the user’s name, others might be their email address or display name. The basic idea is your application will be given a set of data an external identity system is configured to provide about the user – along with cryptographic assurance the identity data you receive comes from a trusted source, of course. [1]

A basic WIF scenario usually consists of one or more Relying Party (RP) applications and a Security Token Service (STS). The Relying Party (RP) is basically an application that relies on claims issued by a STS. An RP is also often called a “claims aware application” or “claims-based application.” The Security Token Service (STS) is the service that builds, signs, and issues security tokens according to the WS-Trust and WS-Federation protocols. The STS will be the one responsible for collecting and validating user credentials and if successful, returning to the RP a claims-based token representing the user. [2,3] If you are confused don’t worry, the solution I propose should help make this abstract concept a little more concrete.

Microsoft’s Windows Identity Foundation is a great start but it doesn’t give us anything to immediately get up and running – let alone a SSO solution. It is as it’s name implies – a foundation, not a solution. Continue to part 2 of this blog series to be introduced to a solution I have discovered that makes implementing WIF and SSO a snap and all without writing a single line of code. I welcome your comments and feedback on this first part. Also you may contact me via the “Contact Us” page at http://www.yosttechnologies.com/contact.


References:
1. The Claims-Based Identity Model (http://msdn.microsoft.com/en-us/library/ee517291.aspx)
2. Relying Party (http://msdn.microsoft.com/en-us/library/ee748466.aspx)
3. Security Token Service (http://msdn.microsoft.com/en-us/library/ee748490.aspx)