Wednesday, 3 June 2015

Enabling federation between Active Directory and AWS IAM (Identity Access Management)

AWS allows us to integrate our existing AD intrastructure within it's Identity Access Management service with the use of SAML - allowing us to utilize features such as SSO (Single Sign-on) enabling users to manage our different AWS services.

So what exactly is SAML?

SAML (Security Assertion Markup Language) is an XML based format that provides auhentication and authorization between two parties - in this case the claims provider (AD) and the relying part (AWS.)

The following demonstrates the process flow of an AD user logging into AWS:

From Amazon:

1. User browses to AWS sign-in URL and is then re-directed to our ADFS instance
2. User authenticates their self with ADFS
3. User then recieves a SAML assertion from the ADFS server
4. User then posts the SAML assertaion for the AWS SAML endpoint (
5. Finally user is redirect to AWS sign-in page and is redirected to the AWS console

For this tutorial we will setup a domain called example.internal and join an ADFS server to the domain. Once we have a DC / domain setup we will proceed by setting up ADFS as follows:

Add Roles and Services >> Active Directory Federation Services >> 'Configure the federation service on this server' >> 'Create the first federation server...' >> Setup Certificates, Service Accounts etc.

The next step will involve creating a SAML provides in your AWS account:

AWS Console >> IAM >> Identity Providers >> Create Provider >> SAML >> Enter a name and upload the metadata file that can be downloaded from your ADFS server as follows:


(NOT the hostname of the ADFS server!)

** Be aware:  ADFS 2.0 no longer has a dependence on IIS - AD FS is now built directly on top of HTTP.SYS and does not require the installation of Internet Information Services (IIS). This caught me out! **

We should then proceed by creating a SAML Role as follows:

AWS Console >> IAM >> Roles >> 'Create new role' >> 'Role for Identity Provider Access' >> 'Grant Web Single Sign-On (WebSSO) access to SAML providers' >> Select the SAML provider we created earlier >> Select the relevent policies e.g. "AmazonEC2FullAccess'.

We will proceed by adding AWS as a Trusted Relying Party within ADFS:

ADFS Console >> Right-hand click ADFS 2.0 >> 'Add Relying Party Trust...' >> 'Import data about the relying party published online...' which should be: >> Display Name should be "" >> Choose whether you want any multi-factor options >> "Permit all ysers to access this relying trust" >> Finish Wizard.

Once the relying trust has been created we should now right-hand click on the newly created relying trust and select "Edit claim rules..." >> Issuance Transform Rules >> Add Rule >> "Transform an incoming claim" >> and enter the following in line with the form:

Claim rule name: NameId
Incoming claim type: Windows Account Name
Outgoing claim type: Name ID
Outgoing name ID format: Persistent Identifier
Pass through all claim values: Checked

We then add another rule >> 'Send LDAP Attributes as Claims' >> enter the following:

Claim rule name: RoleSessionName
Attribute store: Active Directory
LDAP Attribute: E-Mail-Addresses
** Ensure you have an email address attached to your AD user object! **
Outgoing Claim Type:

We proceed by adding another rule >> 'Add rule' >> 'Send Claims Using a Custom Rule' and enter as follows:

Claim Rule Name: Get AD Groups
Custom Rule: c:[Type == "", Issuer == "AD AUTHORITY"] => add(store = "Active Directory", types = ("http://temp/variable"), query = ";tokenGroups;{0}", param = c.Value);

and finally one more >> 'Add rule' >> 'Send Claims Using a Custom Rule' and enter as follows:

Claim Rule Name: Roles
Custom Rule: c:[Type == "http://temp/variable", Value =~ "(?i)^AWS-"] => issue(Type = "", Value = RegExReplace(c.Value, "AWS-", "arn:aws:iam::123456789012:saml-provider/ADFS,arn:aws:iam::123456789012:role/ADFS-"));

Finally we can test our configuraion by going to the following url:



Post a Comment