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:
Installed ADFS 2.0 on a domain joined server
Created a relying party
Created claims mappings to data in Active Directory
Created a simple Claims-Aware application
So what do we need to do next? There really isn’t much we need to do:
Build Azure App
Federate it using FedUtil.exe
Building an Azure application isn’t trivial, but we don’t need to know much to Federate
How do we federate it? Follow these
steps providing the Azure details for the application URI and the Federation Metadata
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
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.