Whilst doing an access control service demo I was asked whether you could wire in your own existing authentication mechanisms as customers did not want to have to redo their authentication/registration mechanisms to use Live ID, Google, Yahoo! etc. The answer to this was yes but I had never done it so this was a good time to investigate how.
I started off with the Windows Azure Platform Training Kit(VS2010) and worked through the “Introduction to the AppFabric Access Control Service V2” lab to setup a web site that allows login via Live ID, Google and Yahoo!. Once this was running I needed to create my own provider and wire it into the lab solution that I just created. There is an additional lab ""Federated Authentication in a Windows Azure Web Role Application" which gives the basics of creating your own identity provider. Unfortunately this does not link to ACS so I needed to work out how to wire the provider in. The following instructions are how I created the site and wired it in:
Taking the ACS lab solution as the basis, create an ASP.Net website that will carry out the login process. For this I added a “ASP.NET Security Token Service Web Site”. Right click on your solution and select new website. Make sure that the URL you enter for the site includes https at the start. (e.g. https://localhost/MyIDProvider).
When the project is created, you need to change some of the code in the template as it does not handle the return address correctly when redirecting from your identity provider after logging in.
The template for an STS web site needs the following code changing in App_Code\CustomSecurityTokenService.cs
Go to GetScope and change the line
scope.ReplyToAddress = scope.AppliesToAddress;
to
scope.ReplyToAddress = String.IsNullOrEmpty(request.ReplyTo) ? scope.AppliesToAddress : request.ReplyTo;
This takes the replyto address from the query string and uses this to redirect back to ACS once the login process has been completed. There are 2 other changes required to the basic STS template in order for it to work correctly.
Open web.config and search for IssuerName in the application settings section and change it to be the url of your STS website (e.g. https://localhost/MyIDProvider)
Also change the SigningCertificateName to point to a certificate that exists in your local machine certificate store. This website will now provide a simple mechanism for logging in. Without any changes you can enter any username and it will authenticate. At this point you will need to wire in your own authentication mechanism, but for testing purposes the default site will allow you to set it up correctly and test it out.
We now need to wire this into ACS. I am using the labs version of the access control service at https://portal.appfabriclabs.com/.
Navigate to your Access Control Service at appfabriclabs.
Click “Identity Providers”, “Add Identity Provider” and add a new “Microsoft Active Directory Federation Service 2.0” provider. The two bits that are important are “WS-Federation metatdata” and the relying party application. Browse to the FederationMetadata.xml file of your STS project you have just created. (e.g. C:\inetpub\wwwroot\MyIDProvider\FederationMetadata\2007-06\FederationMetadata.xml). Also ensure that the ACS website created as part of the labs is checked and press Save.
The final piece of configuration that is required is to add in the rules for your provider. still in the Access Control Service portal, click “Rule Groups”, select the rule group that you setup for your ACS lab and select “Generate Rules”. Ensure that your new identity provider is in the list and that it has been checked and press the “Generate” button. Two new rules should have been added for your provider (Pass through for name and role). You are now ready to test this.
To make it easier to see what is happening I added the following to the Default.aspx of my ACS lab
In default.aspx add the following:
<asp:LoginView ID="LoginView1" runat="server">
<AnonymousTemplate>
<asp:Panel Visible="true" CssClass="secretContent" runat="server" ID="unauthorisedContent">
You are unauthorised to view this page
</asp:Panel>
</AnonymousTemplate>
<LoggedInTemplate>
You are logged in
</LoggedInTemplate>
<RoleGroups>
<asp:RoleGroup Roles="Administrator">
<ContentTemplate>
<asp:Panel ID="SecretContent" runat="server" CssClass="secretContent"
Visible="true">
Secret Content (Only administrators can access this section)
</asp:Panel>
</ContentTemplate>
</asp:RoleGroup>
</RoleGroups>
</asp:LoginView>
This will display the login status so you can see whether the login works or not.
Also add the following style to the site.css file in the ACS lab site:
.secretContent
{
border-style: solid;
background-color: Red;
padding: 5px;
color: White;
}
Run the ACS lab application and check to see if your provider appears in the list of providers and also that when you click on the button it redirects to you page. Login and you should be redirected to the Default.aspx page of the ACS lab site with the text “you are logged in”.
You may want to change the claims that are allowed for specific users. This is done in App_Data\CustomSecurityTokenService.cs in your identity provider web site.
Modify GetOutputClaimsIdentity to change depending upon who is logged in.
Change the code that adds a Manager Role to the following code to allow a user called Steve to be an administrator and everyone else as a user.
if (principal.Identity.Name.Equals("Steve") == true)
{
outputIdentity.Claims.Add(new Claim(ClaimTypes.Role, "Administrator"));
}
else
{
outputIdentity.Claims.Add(new Claim(ClaimTypes.Role, "User"));
}
Run your ACS website again and login with “Steve” and you should now see the secret content that only administrator should see. Login as anyone else and you will not see the secret content.
All that you need to do now is to wire in your own authentication mechanism and deal with the claims for each user.