Credits

First of all, credits to those who helped me in the process of understanding of Federated Identity on .Net. Follow them up on twitter, they are cool people

And thanks to the AltNet Hispano community for those awesome sessions!

Gracias!

Before to begin

This how-to is designed for .Net developers. Since this is a how-to, for more background information you should visit and read the resources listed below. Would be useful for you if you get along with concepts like Federated Identity and Claim-based architecture.

Requirements to begin this how-to

• An active Windows Azure account. There is a free trial for 3 months! This may work
• Windows Identity Foundation libs installed. This is the WIF runtime, you’ll need it for deployment.
• Windows Identity Foundation SDK. This are tools for your Visual Studio 2010, you need it just for development.

The gang

Now a brief presentation to the participants on this post.

Federated identity

FI is the capability of trusting and delegating the authentication of an application into another a third party application. Oh, wait, but how is that secure? Well, is more secure and reliable than you can imaging.

The thing is, today companies are growing and sometimes integrating with each other; services are getting along and more often we fall into the requirements of integrate services.

In .Net is quite easy implement an application that authenticate against several Identity provider. The name of the architecture to achieve this is called: Claim-based architecture.

And the answer in .Net to get this done is Windows Identity Foundation (WIF).

Claims

Claims are security information contained in security tokens issued by an identity provider. This information represents the identity of the client, i.e. Email, User Name, Name, Roles, etc.

The basic scenario for a claim base architecture is

Note that is the simplest scenario, ACS is not part of it, yet. The application knows where to get the authentication for this user, and there is just one identity provider, could be Gmail, Facebook, Active Directory (in this case the issuer may be an ADFS), etc.

 

Windows Identity Foundation

Microsoft create this layer of abstraction in order to facilitate the process of authentication through existents identity providers: Active Directory, Google, Facebook, Windows Live ID, etc. In .Net sense, WIF are just .Net assemblies that we need to reference in our .Net projects.

Access Control System

Access Control System (ACS) is part of Windows Azure Active Directory. Is the nexus between our apps and all the identity providers (Google, Windows Live ID, etc.).

-Should I’ve an active Windows Azure account to use it? -Yes.

-In order to achieve Federated identity on .Net; Should I always need ACS ? –No. We are using it here to let him care about all identity providers we trust, in a way we are centralizing this matter. Then all applications on a company, may trust in just one Federation Provider: and this is our dear ACS. You always can build an application with WIF to authenticate the application against any supported identity provider (IDP).

Resources about Federated Identity on .Net

For more concepts I recommend these readings:

• http://claimsid.codeplex.com/ here you will find an amazing ebook that explains in details this topic. Ebook format: Msdn version or PDF.
• Papper: Claims-Based Identity for Windows. PDF.

Sample architecture

This is an overview of the information flow; how the resource request and authentication happens.

Creating an Asp.Net Web Application

This will be the application what decides to have the authentication process delegated into another party.

In Visual Studio, let’s create just an Empty Web Application. An empty application just focus in the ACS integration, but if you like, you can create and Asp.Net Web Application or an MVC one, is up to you.

After that, add to the project a new Web Form page called ‘Default.aspx’. And the project should looks like this

 

Configuring Access Control System namespace

Now, let’s see best part of this post, configuring the ACS, which a straightforward process. And for this you should have an active Windows Azure account.

In the Windows Azure panel select Service Bus, Access Control & Caching –> Access Control –> New

Create a unique namespace where our service is going to be running. Select the Country/Region that fits to you, then select the active Subscription of your Windows Azure account.

Wait for you namespace to be in ‘Active’ status. Then select it, and click on the button Access Control Service

Everything related to the Access Control Service for our namespace is here

Click on the left menu: Identity Providers. This is the part we configure the Identity Providers. By Default we have already configured Windows Live ID.

To add i.e. Google to the list, and also login with our Google accounts. Click on Add. Then click on Next.

In this screen let everything by default, and click on Save.

Done, now our Federation provider support Google and Windows Live ID for login. The next step is configure the Relying Party applications (this may be our web application).

Click on the left menu Relying party applications, and then click on Add.

Give it a Name, a friendly one. Then add the Realm and Return URL to http://localhost:52000/. Our sample web app is running under a development environment, that’s why the urls are set to localhost with the particular port. This may change in staging or production environments.

Then click Save.

Now on the left menu, click on Rule groups and also click in the Rule group created by default, in our case is called Default Rule Group for Hello all of you.

You will see that, so far none rules were created, and a message like this should shown. Click on Generate.

Click on Generate.

And the result will be four claim rules we’ll receive from our identity providers.

 

Integrating the Federation Provider with Relaying Party

It’s time to integrate both ends, the ACS and our application.

Click in Application Integration and copy the url of the Federation Metadata file.

If Windows Identity Foundation SDK was installed correctly, by right-clicking the .Net project and selecting “Add STS reference…” we start a wizard to configure the integration. If you haven’t yet, this is the moment.

As we are running the Web Application in our development machine, then the url is http://localhost:52000/

A warning will be displayed, because we are not using our application with HTTPS, but is Ok for this sample application. Just click on Yes (Si).

Using the url of Federation Metadata file, we paste it here:

After the integration, the tool will modify the project.

The web.config has suffer some changes. But we still need to add this line into system.web:  <httpRuntime requestValidationMode="2.0"/>

 

To have an interesting interaction, let’s see if the claim are coming from the identity providers. To achieve this add as a reference the assembly Microsoft.IdentityModel.

In the Load page event, in the Default.aspx code behind, write this code to iterate through the claims received from the issuer

using System;
using System.Web.UI;
using Microsoft.IdentityModel.Claims;
using System.Linq;
namespace HelloAllOfYouQu
{
	public partial class Default : Page
	{
		protected void Page_Load(object sender, EventArgs e)
		{
			var claims = User.Identity as ClaimsIdentity;
			
			claims
				.Claims
				.ToList()
				.ForEach(c => Response.Write("<br>Type: " + c.ClaimType + " ; Value: " + c.Value));
		}
	}
}

 

Source code

In case you need it, here you’ve the final application sample:

https://github.com/darioquintana/src/tree/master/Azure/HelloAllOfYouQu

Running the application

It’s time to try our sample. In Visual Studio, press F5 to run the web application. Since we are not logged in, the ACS let us choose between Windos Live ID or Google.

I’ve select the Google account, so the ACS has redirected to the Google login page.

After the login, I’ve to grant permission to helloallofyouqu.accesscontrol.windows.net to access to my Google information.

And this is it! Now we are authenticated, and we can see in the default page the claims that we got from Google.

Conclusion

We created a web application delegating the authentication process to Windows Live ID or Google. We used Access Control Service from Azure, to manage the identity providers allowed by the application.

 

Hope this helps!

@darioquintana