Iron Foundry and other PaaS frameworks are built to deliver a set of services to developers for building applications. While we think Iron Foundry has a great set of web, data and messaging services available, it by no means includes everything that a developer can use to craft a cool web app. Ideally, a developer can mix and match services from multiple PaaS providers in order to get everything that’s needed to solve a particular problem. For instance, what if an Iron Foundry developer wants to build a .NET application that lets users log in with credentials from a trusted provider? In this blog post, I’ll show you how to do user authentication/authorization in an Iron Foundry ASP.NET app by using the Windows Azure Access Control Service (ACS).
What is Windows Azure ACS?
Windows Azure ACS is essential a claims transformation engine that connects to trusted web identity providers (e.g. Facebook, Google, Windows Live, Yahoo) and custom identity providers (e.g. through Active Directory Federation Services), and authenticates the user before passing along a set of claims to your web application. It provides developers a way to outsource the identity management part of their application. ACS itself doesn’t store credentials or act as an identity provider, but rather, it acts as a middleman that can take a series of input claims (e.g. “Google username”, “Windows logon ID”) and transform them into a single claim (“user ID”) used by your app. It’s a cool way to get your application out of the business of handling unique identity providers or storing credentials.
Let’s walk through the steps to building a simple, secure web app that we can deploy to Iron Foundry.
Step 1 – Create new ASP.NET MVC 4 (internet) application
To get started, I built a new ASP.NET MVC application in Visual Studio 2012.
Once the project was created from the MVC4 template, I simply built it and ran it. You can see the default website and notice that I can register for an account. At this point, what this does is store my credentials in the default membership provider (which is a local database). I don’t want that as my long term solution. I want to let users log in with their web identity provider of choice.
2. Configure Access Control Service to Recognize Our Iron Foundry Application
Virtually every Windows Azure service has migrated from the clunky Silverlight portal to the new, clean HTML portal. Unfortunately, Windows Azure ACS still lives in the old portal. Once I regretfully logged into it, I saw the options to add/configure identity providers, set up the relying party applications (like the one I created), and define the claims transformation rules.
If I wanted to add ADFS as a valid identity provider, I could do that here. Instead, since I used existing web identity providers, I could jump right to the “relying party applications” section. On the first part of this form, I set the friendly name of the application, and the URL that will receive the claims. Initially (until I deployed to Iron Foundry) this was a local address on my machine.
Further down this form, I was asked which (configured) identity providers I wished to use, whether or not to create a new set of claims transformation rules, and what certificate to use for signing the tokens.
After saving my relying party entry, I jumped to the “Rule Groups” section of this portal to configure the transformation rules. I chose the option to “generate rules” for all the available identity providers, and was left with a series of “passthrough” rules that take whatever claim value was issued by the identity provider and ships it, as is, to my application.
An individual one of these rules, such as the “Google name” one, has an input claim type and value, and an output claim type and value. While the one below has the same type and passthrough value, you can imagine how you might have three different providers with different input claim types/values all map to a single, internally-defined claim type and/or value.
3. Configure ASP.NET App to use ACS for Identity Management
With my ACS configuration complete (for now), I returned to Visual Studio 2012 to make it “ACS aware.” Now there is a great new tool for Visual Studio 2012 and the latest Windows Identification Foundation bits (which you can see by grabbing the Identity and Access Tools), but since Iron Foundry doesn’t yet support .NET 4.5, I wasn’t able to use the wizard tooling. The latest WIF only applies to .NET 4.5, so I jumped back to using WIF 3.5. To easily grab this version, simply add the NuGet package for Windows Identification Foundation to a project.
With all the proper assemblies in place, I then manually updated my web.config file to reflect my use of WIF and ACS. You can find my complete web.config file below. To learn more about the significance of each section, I’d recommend the blog post Windows Identity Foundation (WIF) Configuration Sections in ASP.NET Web.Config.
That’s about it. Clearly if I wanted to customize the handling of these claims (e.g. show the value of a claim besides “name” on the home page), there’s additional work I’d want to do in my code. When I ran this application, I was quickly prompted for credentials and the ACS site served up a page for me to select which identity provider to use.
When I chose the Google provider, I was redirected to the Google accounts page and asked to log in.
Once I logged into my account, I was returned to my custom web app which recognized that I was now authenticated!
To prove that this is an account that wasn’t managed by my application itself, I clicked on my name to “manage” my user. I was presented a message indicating that there’s no local password for this user, as the identity provider was NOT my local membership provider.
4. Update and Deploy the App to Iron Foundry Environment
The final task was to update the ASP.NET application and ACS configurations before deploying the application to Iron Foundry. First, I returned to the Windows Azure ACS portal to change the “realm” of the relying party entry that I created for my custom application. I planned on deploying this application to the free IronFoundry.me environment, so I entered the expected destination of the application.
After saving this change, I returned to my Visual Studio project and entered that same IronFoundry.me URL into the web.config file where the “localhost” value had been before. After publishing the website to the file system and executing a Cloud Foundry vmc push command from my Command console, my app was quickly deployed.
Did it work? I browsed my newly published app on Iron Foundry, and just as with the local site, I was prompted for which identity provider to use. After selecting Google and plugging in my credentials, I saw my logged in user on the website.
Cool! This is a fun case of being able to use the public/private Iron Foundry PaaS but still take advantage of other useful services offered by other PaaS solutions.
Pingback: Links to Recent Articles Written Elsewhere « Richard Seroter's Architecture Musings