This is part of a series of blogs. See the preceding blog entries:
Let’s start with ADFS.
First of all, why using ADFS on this project? In short but mystical terms: to extend the corporate identity to the cloud. In layman terms, to allow Windows Azure to authenticate a corporate user without passing through the corporate firewall. To illustrate this, let’s look at the architecture without ADFS:
Basically, the user, sitting behind the corporate firewall, contacts the application deployed in the cloud. But since there is no relationship between our Corporate Active Directory and Windows Azure, the application is unable to authenticate the user.
Enters Active Directory Federation Services 2.0. ADFS is a service in front of your Active Directory. It uses AD to authenticate you and packages a SAML token for the application (called a relying party in the context of claims based security) to use. The relationship between ADFS and the application is a trust relationship: there are no network connections between the application and ADFS. Basically, your application is configured to accept SAML tokens from your ADFS.
The typical flow for authentication is the following:
- User connect to the web application
- The web application checks for an authentication cookie, doesn’t find one. It forwards the user to an ADFS login page.
- The user automatically authenticates (being on its corporate network).
- ADFS posts the SAML token back to the application
- The application creates a cookie
- The user has access to the application
Actually, ADFS version 2.0 enables much more than that. It moves away from Active Directory role based access control (RBAC) to claims based. I encourage you to read the excellent Guide to Claims-Based Identity and Access Control book available on Microsoft downloads to learn more about the exciting world of Claims based security.
You can download ADFS version 2.0 here. Straightforward to install. You need to reboot after the install and then configure the service on your machine, using the ADFS add-on on your Administrative tools.
Here I’ll show you how I configured it on my virtual machine. I was doing a demo-type of installation, so I didn’t worry about scalability or robustness. My installation was equivalent to installing SharePoint entirely on one server using SQL Express.
On the first screen, I chose to create a new Federation Service (since there was none yet).
On the second screen, I chose the stand-alone federation server installation.
On the next screen, I have to pick a certificate I just created in order to continue. To learn how to create a self-signed certificate, read this.
On the next screen, nothing needs to be done. It’s the last step before the actual configuration is implemented.
The next screen shows the progress of the configuration going on.
With this ADFS is installed on your machine. On the next blog entry, I’ll configure ADFS to work with my application (relying party).
Great posts Vincent (read through some of your other posts on the blog as well; including the over 10K customers on Azure – internally we actually see a lot more than that but we will probably publish the actual numbers at some point)! And thank you for taking a look at the Windows Azure platform:)
For the next part, and you probably know this already, try using Windows Identity Foundation (http://msdn.microsoft.com/en-us/security/aa570351.aspx) to integrate claims-based identities into an application.
A scenario I think is interesting when leveraging claims-based identities is when facilitating B2B integrations, and via the Windows Azure AppFabric which can serve as the intermediary between organizations and enabling them to use their own identities to communicate with each other’s services. More food for thought!
Best, -David Chou (Microsoft)
Hi David,
Thanks for the feedback. I’m looking forward to see more accurate figures on Azure user-base.
I plan to use WIF in its simplest form, to acquire the current user of a web request. I know there’s a WIF-http module that does just that and sets the current user to a WIF-IPrincipal derivative, I’ll just have to dig back the article I read showing that. My current task is to plug an application with ADFS. I’m planning to use the claim-based guide (http://www.microsoft.com/downloads/details.aspx?familyid=4C09FFE4-43DD-4FCC-BE35-C897C9BC4386&displaylang=en). If you have more straightforward litterature, I all ears 😉
We are interested into B2B integration in the long run. Being a financial institution, we integrate with many market data providers. On the other hand, the finance industry, especially in the market data, tends to be a bit conservative in its technology, so SAML might not be available for a while there.
An area where I can foresee difficulties when porting applications to Azure is with authentication on the DB. For better or worse, our Enterprise Standard is to use Kerboros and delegation all the way to the DB store (hence securing each user’s acces, as oppose to trusting a service account for DB access). That scenario isn’t currently supported. Do you know if SQL Azure will support claim-base authentication in the near-future? Otherwise, would you recommend an approach closing-in delegation in the cloud?
Cheers,
Vincent-Philippe Lauzon
Pingback: Departmental Application Migration to Azure – Part 3 – ADFS with on-premise web app « Vincent-Philippe Lauzon's blog
Pingback: Departmental Application Migration to Azure – Part 4 – ADFS with Azure web app « Vincent-Philippe Lauzon's blog
Pingback: Departmental Application Migration to Azure « Vincent-Philippe Lauzon's blog