Its a little gap in between my third and fourth part, anyways I am going to write 4th part of the series. First you can read my earlier parts from the link below.
As if you have read my earlier posts in the series, you can visualize that in my first post I discussed about the Idea about Claim based authentication, basics and various components of Claim based authentication.
In part 2, we discussed about Windows Identity Foundation (WIF) and also created a step by step simple example using WIF.
In part 3, we discussed the problem of the approach discussed in part 2 and discussed that these problems can be avoided if we use a Federated Provider. In this post we’ll implement the federated provider in a simple solution.
To continue reading this post, it’ll be better to go through at least part 3 post in the series.
Just to brief, In federated scenario, two Identity Providers comes into the picture : one is Identity Provider (where user puts its credentials) and another is Federated Provider which understands all the Identity Providers and accordingly creates a new token that is understood by the relying party. Relying party does not care about Identity Providers, rather it just trust the Federated Provider and can understand the token issued by it. It can be pictorially depicted as
As here in above image, we can see that every Identity Provider send different type of token. Access control service process these and create a new token and sends to Relying Party.
We can have our own custom Identity Provider and Federated provider as well. In Microsoft stack, Access Control Service is one of the most popular service which serves the purpose of a federated provider. It is Pay-As-You-Go service on Azure and provides all the basic infrastructure and requires less or no amount of coding. Access Control Service is now called Windows Azure Active Directory.
In today’s post, I’ll create a step by step example to implement the Federated provider using Windows Azure Active Directory. First let me discuss the various components while using federated provider . So there would be at least four components
- Client
- Identity Provider(s)
- Federated Provider
- Relying Party
As we have already discussed all the above components in my last post. we ‘ll create a step by step example of Federated Provider. Here Identity provider could be any third party Identity Provider or our own Identity Provider. Windows Azure Active Directory works as Federated Provider and a application hosted on my local machine will be relying party.
Let’s go step by step. First we need to create a namespace at azure Access control. For this first one need to be registered on http://windows.azure.com. If you have account here then you can continue else you’ll require to register here before proceed.
Here we’ll login azure portal (https://windows.azure.com/) and create a Active Directory Access Control namespace for our Federated Provider that will be used by our application (Relying Party). After login it redirects to home page and provides many options in left pane of the Home page as
Here to quickly create the Active Directory Access Control namespace click on the encircled new button in left bottom as in above screen shot. It opens up a window.
Select App Service ->Access Control -> Quick Create. It asks for namespace and region. The namespace should be globally unique, else it will not be accepted. After filling it click on Create
I have given here namespace CBAPart4 and selected region Southeast Asia. Here you can see encircled green tick mark which means the namespace available. After creating, it will be enlisted in your account with status active few minutes as:
On this page, click on Manage button at bottom middle of the page which takes us at different page in a new tab/window with left pane as
Now click on Identity Providers which allows to add Identity providers for this Federated Provider. It takes us at below screen
It has added by default added Windows Live Id as an Identity Provider. We can add other providers by click on Add link encircled in the above screen shot.
Here we have some already pre-configured Identity Providers like Google, Yahoo and custom Identity Providers like facebook, ADFS 2.0 (Active Directory Federation Services). Let’s add Google here
It asks the that display and any image for that if we want to show that at login link. I provided an image and Clicked on save. Similarly we can add Yahoo as an Identity provider. Now we have three Identity providers for our federation provider: Google, Yahoo and Windows Live Id.
Next we require to add the Relying Party. Means our application that will be authenticated via this Federated Provider. To add the Relying Party applications, click on Relying Party applications link, it takes us
Here I provided the name to my Application as MyRelyingPartyApp . There are two ways to add settings. Select the first one (Enter settings manually) as encircled in mode section. We need to provide two URLs. Here one is for which the token is issued (also called Realm) and another where the federation provider returns the access token. Leave the rest of the settings of section Relying Party Application Settings section and move to next section Authentication settings on the same page as
Here it lists all the Identity Providers that we added , we need to select all which we want to use. I selected all. Now we need to create the rules. So first require to create a Rule Group then rules under that rule group. We either can use any existing rule group (if exists which can serve the purpose) or can create a new one. I’ll be telling why do we require the rules in coming section.
Token is required to be signed to check the integrity at the target application. Here I have selected the default option for this demo. We can provide our own certificate that can be used for token signing.
Rule – Rules are very important here. Identity Providers sends token with claims to Federated Provider. As Federated provider trust Identity Provider so it knows the format and details about token and can read it. Federated provider first checks the integrity of token then read the required data and creates a new token with claims. Then Federated provider sends this token to Relying party. Here this rule is to convert the claim provided by Federated Provider to some other claim type that can be understood by Relying party. We can easily pass through the same just creating a rule with pass through.
Rules also are very helpful because we not want to sends all the claims to Relying party or want to combine some claims. These scenarios is handled by these rules.
To add the rules, click on the Rule Groups from left pane
It adds by default a rule group for added Relying party. We can create new one . We need to add the rules in the rule group assigned to Relying party. For that click on Default rule group on the above screen shot and it redirects us to
Here we can see the details of the rule group. It is for the Relying party that we added as second encircled . Now in this group there is no rule. Either we can add some rules or we can simply check on Generate button, which redirects us a page which list down all the Identity Providers for this Federated Provider namespace and again click on generate button which just add the default claim rules that just pass the claims returned by Federated Provider as is. A rule is created is for each claim which has input claim and output claim as
Else we can create rule by our self by clicking on the Add link as encircled in the previous screenshot as:
It has three section, first section If first option Identity provider, once we select it accordingly it populates all the claims provided. As I selected Google and enlist all the claims by provided by Google in dropdown as marked in second encircled area. We can add here another input claim as last encircled link. Now let’s move to next section that is Then
Here either we can pass through as it is or we can send it in some another type that is available in second encircled drop-down. It has a list of standard claims that we can choose off. Also we can put our own custom claim type in the text box. Every claim type is in URI format as per standard so custom type also should follow the standard. I have selected pass through. The last section is Rule Information . here we can put the details about the rules.
All the required steps has been completed on windows azure portal, Now need to get the metadata for the Federated provider. Click on the Application Integration link under the Development section in left pane.
As this provides many option but we require here WS federation metadata as encircled that will be used in relying party . Copy that encircled URI.
As discussed, I have created a ASP.NET web application project using default template and hosted at IIS. Now the next step to build a trust relationship with Relying party and Federated Provider. So as we have already seen in our part 2 post that how to build relationship between Identity Provider and relying party. We require here the federation metadata from the identity provider and add the STS (Securty Token Service) reference. I am adding those steps for the completeness of the post.
So let us add the STS reference as
It opens a popup as
First encircled area contains Relying party configuration settings and another is Application URI. Click on next
Here as we are using existing STS so selected the last one. We require to provide the metadata here so to get the metadata URL from Federated Provider. I have the provided the metadata URI that we copied from Application Integration section. Click on next
Here I have selected to Disable certificate chain validation as my certificate is not verified. For development purpose it can be disabled but at production, this option should not be selected. Click Next
Select No Encryption. Click Next.
Here we have two claims Name and Identity Provider. Click Next
Now click finish. And we have built a trust relationship between federated provider and our own Application (Relying Party).
Now it’s time to run the application. So let us run it
It takes us a page and asks us to choose the Identity Providers that we added as Identity Provider while configuring Federated Provider on Azure Portal. The images for Identity Providers, I provided while adding these on Azure Portal.
Now I clicked on Google and it took me at Google login page after providing my credentials and successful authentication, I got redirected my own application as an authenticated user. Similarly can get authenticated via Windows Live Id or Yahoo Id.
Reading Claims provided by Identity Providers
Reading the claims is very easily that are provided by these Identity Providers. I read the claims and displayed it via a Data Control. To read the claims, we can use the following code
IDictionary<string, string> claims = new Dictionary<string, string>();
IClaimsPrincipal icp = Thread.CurrentPrincipal as IClaimsPrincipal;
IClaimsIdentity claimsIdentity = (IClaimsIdentity)icp.Identity;
gdViewClaims.DataSource = claimsIdentity.Claims;
gdViewClaims.DataBind();
Now If I login through Google account then it shows the following claims
I have displayed three values here ClaimType, Value, and ValueType. Here Google returned four Claims which has it’s descriptions and my mail-id and name. Similarly if I login through another Identity Providers, they will show different claims. We can use these values in our relying party for different purposes.
I have written this part is little long (could not make it short). If you face any issue while working on any steps, Do let me know here I’ll be happy to answer.
Cheers,
Brij
