Windows Domain to Amazon EC2 Single Sign-On Access Solutions

Posted by Abel Avram on Jan 21, 2010

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

Architecture ,

Security ,

.NET ,

Cloud Computing ,

Operations

Tags

Active Directory Federation Services ,

Windows Identity Foundation ,

Windows ,

Single Sign-On ,

EC2 ,

Active Directory

David Chappell, the Principal of Chappell & Associates, US, has written a whitepaper proposing several solutions for Single Sign-on (SSO) access to applications deployed on Amazon EC2 from a Windows domain. InfoQ explored these solutions to understand what the benefits and tradeoffs each one presented.

Entitled Providing Single Sign-On To Amazon EC2 Applications From An On-Premises Windows Domain (PDF), Chappell’s whitepaper addresses several possible cases to provide SSO access to an application deployed to Amazon EC2 from a Windows domain:

• Accessing an Amazon Machine Instance (AMI) belonging to the same entity controlling the Windows domain
  • Using VPN to access an AMI in Amazon Virtual Private Cloud (VPC)
  • Using Active Directory Federation Services (ADFS) to access an AMI in the public EC2 cloud
• Accessing an application belonging to a third party

Windows Domain - Amazon VPC

When a company wants to deploy its own application on Amazon EC2 and using VPN is a viable solution, then Chappell suggests deploying the application on Amazon VPC. The AMI in the VPC will behave similarly like having it on-premises, and there are three possible solutions to integrate it with Active Directory Domain Services (ADDS) in order to provide SSO:

• Make the Amazon EC2 instances inside the VPC part of an existing on-premises Windows domain and site. This option doesn’t require running a domain controller in the VPC.
• Make the Amazon EC2 instances inside the VPC a new site in an existing on-premises Windows domain. This option requires running ADDS in Amazon EC2.
• Make the Amazon EC2 instances inside the VPC a new domain in an existing on-premises Windows forest. This option also requires running ADDS in Amazon EC2.

In all these cases, authentication and authorization works similarly to on-premises access to an application. The user contacts the ADDS server to be authenticated and to receive a Kerberos ticket that is forwarded to the application in the cloud which grants access based on credentials contained by the ticket.

Windows Domain with ADFS – Amazon Public Cloud

When VPN is not desirable, a company can set up a configuration to have SSO access to its own AMI from a Windows Domain using ADFS. Chappell offers two solutions based on ADFS 1.1 or ADFS 2.0. They are mostly similar with a few differences.

ADFS 1.1

In this case, an ADFS 1.1 server needs to run on-premises, inside the Windows Domain. The AMI will need to contain an ADFS 1.1 Web Agent. When an user wants to connect to the cloud application through his browser, his request is received by the Web Agent which redirects it via the browser to the ADFS 1.1 server which authenticates the user and generates a token which the browser hands back to the Web Agent which grants access to the application based on the claims contained in it. The entire authentication and authorization operation is done behind the curtains, the user not being involved.

The approach works even if the AMI does not run Windows. All it needs to have is a Web Agent implementing the WS-Federation protocol. The whitepaper mentions Quest and Centrify as providers of WS-Federation agents for Linux.

This approach has a few drawbacks. One is that it works only for browsers. Another is that “ADFS 1.1 also lacks some of what’s required to be a solid foundation for claims-based identity, a more general approach promoted by Microsoft, IBM, and others”.

AD FS 2.0

The drawbacks mentioned for ADFS 1.1 are solved with ADFS 2.0. The ADFS server is a 2.0 server, and the Web Agent is replaced by a Windows Identity Foundation (WIF) agent. The SSO access works similarly to using 1.1.

Windows Domain with ADFS – Third Party AMI in Amazon Public Cloud

The cases presented above work well when the AMI in the cloud belongs to the same entity as the Windows Domain. Things are different when the AMI belongs to a third party which does not operate under the same conditions. The AMI will belong to a Windows domain different from the user’s, a domain with its own ADFS server. In this case there are also two possible solutions based on what version of ADFS is used: 1.1 or 2.0.

ADFS 1.1

When the browser tries to connect to the cloud application, the request is redirected to the cloud Windows domain ADFS server which generates a SAML token and redirects through the browser to the ADFS server belonging to its own domain. The server generates another token which is presented back to the remote ADFS server which in turn emits a token to be used by the browser to access the application.

ADFS 2.0

This case is similar to using an ADFS 1.1 server, but the web agent is replaced with WIF and the 1.1 server is replaced with the newer version 2.0.

SSO is an important feature to have when the number of on-premises and Internet accounts created by users grow to large numbers, making the task of administering them increasingly difficult. This will likely result in more requests to software vendors for SSO support/solutions since these make the users’ lives simpler and reduce administration costs.

• Older >