Single Sign-On Between the Cloud and On-Premise using ADFS 2

One of the issues I hear about hosting services in the cloud has to do with managing Identity.  Since the service isn’t local, it’s harder to tie it into services like Active Directory.  What do I mean by this?

I’m kind of particular how certain things work.  I hate having more than one set of credentials across applications.  Theoretically since we can’t join our Azure Servers to our domain, there’s a good chance we will need separate credentials between our internal domain and Cloud Services.  However, it’s possible to make our Cloud Applications use our Active Directory credentials via a Claims Service.

With Federation Services it’s surprisingly easy to do.  Yesterday we talked about installing Active Directory Federation Services and federating an application.  Today we will talk about what it takes to get things talking between Azure and ADFS.

As a recap, yesterday we:

1. Installed prerequisites
2. Installed ADFS 2.0 on a domain joined server
3. Created a relying party
4. Created claims mappings to data in Active Directory
5. Created a simple Claims-Aware application

So what do we need to do next?  There really isn’t much we need to do:

1. Build Azure App
2. Federate it using FedUtil.exe

Building an Azure application isn’t trivial, but we don’t need to know much to Federate it. 

How do we federate it?  Follow these steps providing the Azure details for the application URI and the Federation Metadata from ADFS. 

One of the gotcha’s with deploying to Azure though is that the Microsoft.IdentityModel assembly is not part of the GAC, and it’s not in Azure builds.  Therefore we need to copy the assembly to the bin folder for deployment.  We do that by going to the Microsoft.IdentityModel reference properties and setting Copy Local to true:

That isn’t the only gotcha.  We need to keep in mind how data is transferred between Cloud and intranet.  In most cases, nothing goes on behind the scenes; it passes across the client’s browser through POST calls.  If the client’s browser is on the local intranet, when it hits the cloud app it will redirect to an intranet location.  This works because the client has access to both the cloud app and can access ADFS.  This isn’t necessarily the case with people who work offsite, or are partners with the company.

We need to have the ADFS Server accessible to the public.  This is kind of an ugly situation.  Leaving the politics out of this, we are sticking a domain joined system out in the public that’s sole responsibility is authentication and identity mapping.

One way to mitigate certain risks is to use an ADFS Proxy Service.  This service will sit on a non-domain joined system sitting on an edge network that creates a connection to the ADFS Server sitting inside the corporate network.  External applications would use the Proxy service.

Installing the Proxy service is relatively simple, but a topic for another post.