Steve Riley’s post on growing interest from Amazon customers on identity federation is consistent with what I hear from our own customers.

As part of our project, we actually tested the two scenarios he describes on EC2:

“I imagine most scenarios involve applications on Amazon EC2 instances obtaining tokens from an ADFS server located inside your corporate network. This makes sense when your users are in your own domains and the applications running on Amazon EC2 are yours.”

This would be exactly Scenario #1 in the guide, hosting a-Expense sample on EC2:



The guide covers a similar deployment on Windows Azure. 


“Another scenario involves a forest living entirely inside Amazon EC2. Imagine you’ve created the next killer SaaS app. As customers sign up, you’d like to let them use their own corpnet credentials rather than bother with creating dedicated logons (your customers will love you for this). You’d create an application domain in which you’d deploy your application, configured to trust tokens only from the application’s ADFS. Your customers would configure their ADFS servers to issue tokens not for your application but for your application domain ADFS, which in turn issues tokens to your application. Signing up new customers is now much easier.”

And this is exactly what we cover in the chapter “Federation with Multiple Partners” with Fabrikam Shipping sample:




Note: You could implement all these with ADFS v1 and Windows Server 2003. But now that Amazon support Win2008, you can deploy ADFS v2 so the story is even better.

In both cases, if the IP (the ADFS server in each company) is exposed to the internet, then users will also have easy access to EC2 hosted systems using the same corporate credentials.

The bottom line is that with ADFS & WIF it is very easy to enable a seamless login experience for your applications, regardless of where they are actually hosted. What’s the catch? Well, your app has to be “claims aware”. If you are application uses say, Windows integrated security, then you need to either:

1- Convert it so it understands claims.

2- Leave it on your premises.

3- Host it in an environment that supports the required network protocols. Typically, you need a VPN between the 2 datacenters (yours and the hoster’s).

#1 depends on your application architecture. The first scenario of the guide examines a simple “before and after”. For #3, you can use Amazon’s Virtual Private Cloud service, albeit at a much higher cost.

Update: fixed typos. Added link to David Chappell's whitepaper.