Single Sign-on with Windows ADFS to Amazon EC2 .NET Applications

items>Single Sign on with Windows ADFS to Amazon EC2 .NET Applications
This document provides step-by-step instructions for creating a test lab demonstrating identity federation between an on-premise Windows Server Active Directory domain and an ASP.NET web application hosted on Amazon's Elastic Compute Cloud (EC2) service, using Microsoft's Active Directory Federation Services (ADFS) technology.


Submitted By: SteveRiley@AWS
AWS Products Used: Amazon EC2
Language(s): C#, C++, VB.NET
Created On: April 12, 2010 6:30 PM GMT
Last Updated: September 26, 2013 12:28 AM GMT
A companion document describing the rationale for using ADFS and EC2 together is required pre-reading, and is available here.

Download the full step-by-step guide.

The document is organized in a series of scenarios, with each building on the ones before it. It is strongly recommended that the reader follow the document's instructions in the order they are presented. The scenarios covered are:

  1. Corporate application, accessed internally: Domain-joined Windows client (i.e. in the corporate office) accessing an Amazon EC2-hosted application operated by same company, using AD FS v1.1
  2. Corporate application, accessed from anywhere: External, not-domain-joined client (i.e. at the coffee shop) accessing the same EC2-hosted application, using AD FS v1.1 with an AD FS proxy. In addition to external (forms-based) authentication, the proxy also provides added security for the corporate federation server
  3. Service provider application: Domain-joined and external Windows clients accessing an EC2-hosted application operated by a service provider, using one AD FS v1.1 federation server for each organization (with the service provider's federation server hosted in EC2) and a federated trust between the parties
  4. Service provider application with added security: Same clients accessing same vendor-owned EC2-hosted application, but with an AD FS proxy deployed by the software vendor for security purposes.
  5. Corporate application, accessed internally (AD FS 2.0): Domain-joined Windows client accessing EC2-based application owned by same organization (same as Scenario 1), but using the currently-in-beta AD FS 2.0 as the federation server and the recently-released Windows Identity Foundation (WIF) .NET libraries on the web server.
Some notes regarding this lab:
  • To reduce the overall computing requirements for this lab, AD FS federation servers are deployed on the same machines as Active Directory Domain Services (AD DS) domain controllers and Active Directory Certificate Services (AD CS) certificate authorities. This configuration presents security risks. In a production environment, it is advisable to deploy federation servers, domain controllers and certificate authorities on separate machines.
  • This lab includes a fully-functional Public Key Infrastructure (PKI) deployment, using Active Directory Certificate Services. PKI is a critical foundational element to a production-ready federation deployment. Note that:
    • This lab uses a single-tier certificate hierarchy. Note that a two-tier certificate hierarchy with an offline certificate authority (CA) responsible for the organization root certificate would be more secure, but is outside the scope of this lab.
    • Also, this lab uses CA-issued certificates (chained to an internal root CA certificate) for SSL server authentication. This requires distribution of the root CA certificate to all clients that access those web servers, to avoid SSL-related errors. In a production deployment, it is preferable to use certificates that chain to a third-party root certificate (from Verisign, RSA, etc.) that is already present in Windows operating systems, since this alleviates the need to distribute root CA certificates.
  • This lab also includes a fully-functional Domain Name Services (DNS) deployment, using Microsoft DNS Server. DNS is also a critical foundational element to a production-ready federation deployment. Note that:
    • This lab uses fictional DNS domains, which Internet name servers resolve to the web site, breaking the lab functionality. Thus, the lab simulates resolution of external DNS names by using DNS forwarding from domain DNS instances to a hypothetical "Internet DNS" server that you run on one of the EC2-hosted web servers. While useful in the context of this lab, DNS forwarding is not a requirement of a functional federation deployment.
  • To varying degrees, every scenario covered in this lab requires inbound Internet connectivity to the corporate federation servers, which will reside inside your organization's firewall. Before proceeding, make sure you have access to an external/internet IP address, with open ports 80 and 443 for Scenario 1, and port 443 only for Scenarios 2 through 5.
  • This lab will require a total of three local computers. In this lab, Hyper-V virtualization technology in Windows Server 2008 was used to keep physical machine requirements down.
  • To simplify the recording of important values you must type during configuration, please use the Important Values Worksheet.
©2017, Amazon Web Services, Inc. or its affiliates. All rights reserved.