AWS single sign-on using ADFS

Datetime:2016-08-23 03:40:33          Topic:          Share

One of our clients wanted to integrate their internal systems with AWS like Active Directory and use single sign-on feature for their internal users. Another case is an application needs to access their resources on AWS. Here in this post, I will explain how to integrate Active directory with AWS and give users access according to their domain groups. Here are the steps we have to follow:To set up my domain, I used Amazon EC2 because that made it easy to access the domain from anywhere. My EC2 instance used Windows Server 2012 R2 running Internet Information Server (IIS), AD, and ADFS.

How integration between AD FS and AWS Works

The flow is initiated when a user (let’s call him Sam ) browses to the ADFS sample site ( https://Fully.Qualified.Domain.Name.Here/adfs/ls/IdpInitiatedSignOn.aspx ) inside his domain. When you install ADFS, you get a new virtual directory named adfs for your default website, which includes this page

The sign-on page authenticates Sam against AD. Depending on the browser Sam is using, he might be prompted for his AD username and password. Sam’s browser receives a SAML assertion in the form of an authentication response from ADFS. Sam’s browser posts the SAML assertion to the AWS sign-in endpoint for SAML ( https://signin.aws.amazon.com/saml ). Behind the scenes, sign-in uses the AssumeRoleWithSAML API to request temporary security credentials and then constructs a sign-in URL for the AWS Management Console. Sam’s browser receives the sign-in URL and is redirected to the console. From Sam’s perspective, the process happens transparently. He starts at an internal website and ends up at the AWS Management Console, without ever having to supply any AWS credentials.

Now that we understand how it works, let’s take a look at setting it all up.BTW this post is fairly long. The next couple of sections covers installing and configuring ADFS. If you already have ADFS in your environment, you may want to skip ahead to the Configuring AWS section.

Configuring Active Directory

If you want to follow along with my description, you’re going to need a Windows domain.

For demonstration purposes, I used a single user ( aws_admin ) who is a member of two AD groups ( aws_admins and aws_users ) and a service account (LOGESH.PUC) used by ADFS. Note that the names of the AD groups both start with aws . This is significant because aws_admin's permission to sign in to AWS will be based on a match of group names that start with aws ,` as I'll explain later.

Note If you follow along with the instructions, make sure you use exactly the same names we do for users, AD groups, and IAM roles, including uppercase and lowercase letters.

  • We will create two domain groups, aws_admins and aws_users
  • We will create one user named aws_admin and add it to the aws_admins and aws_users group
  • Create another user named LOGESH.PUC. This account will be used as the ADFS service account later on.
  • We will create an identity provider in AWS and upload our SAML metadata.
  • We will create two roles for each group, aws_admin_role and aws_user_role .
  • We will configure AWS as a Trusted Relying Party in ADFS and add some claim rules.

Finally, we will test it.

Ok let’s start step by step:

Install active directory and ADFS on windows 2012 server:

1- Created my test domain on a Windows 2012 R2 instance and my domain is comsys.local . I will create two groups named as aws_admins and aws_users .

2- I will create one user for each group and add them to the corresponding groups.

Installing and configuring ADFS:

Prerequisites:

  • IIS with Self-Signed Certificate

Here I am not going to cover IIS installation in this post since there are many documents already available online, you can simply Google it and install in few minutes. Here I will cover how to generate the self-signed certificate for ADFS.

Generating self-signed certificate

Open IIS management console and select the server in the left hand side (SVR01 – in my case)

Open “Server Certificates” option

Click on “Create Self-Signed Certificate” option under “Action”

Specified the name as “self” and certificate store as “Personal”

Right click on the certificate and click on export. Provide the location and provide your own password

Installing ADFS

Open Server Manager and click on “Add roles and feature”

Simply click “Next” at the “Before You Begin” screen

At the Installation type snap-in, select “Role-based or feature-based installation”

Simply click on “Next” in the “Server Selection” page as the default server selected as my local server where I want to install ADFS

Select the “Active Directory Federation Service” in Server Roles page

Click on “Install” at the Confirmation page

Now the installation is succeeded and we now need to configure the ADFS, click on “Close”

Now you can see the Notification flag. Click on “Configure the Federation service on this server” and now you will get the following Welcome screen

Select “Create the first federation server in a federation server farm” and click “Next”

Make sure your service account is selected (In my case it is logesh.puc)

Import your self-signed certificate generated in the previous step using IIS

Enter the Display name of your choice that is what your user will see at sign in

Select your service account (in my case: logesh.puc) and Enter the password of it.

On the Specify Configuration Database interface, click Create a database on this server using Windows Internal Database, and then click Next…

On the Review Options interface, click next…

On the Prerequisite Checks interface, verify that all prerequisite passed and then click Configure…

On the Results interface, click Close…

During my testing, I went through this wizard on several different Windows servers and didn’t always have 100% success. In some cases I encountered the following error message:

It turns out this is a known issue that can be fixed by running the following at the command line (Make sure you run the command window as an administrator):

setspn -a host/localhost logesh.puc

Note, that is the name of the service account I used.If the command is successful, you see output like this:

DFS is now configured and ready to use. We can check our SAML metadata document by hitting bellow URL.

" https://localhost/FederationMetadata/2007-06/FederationMetadata.xml "

Configuring AWS

Now it is time to create our identity provider in AWS.

Step1:

In IAM console, Click “Identity provider” and then click “Create Provider”.

For “Provider Type” choose”SAML”and type “Provider Name” as “demo”.

For Metadata Document, Click Choose File, specify the SAML metadata document that we have downloaded in above step

Click “Next step” and verify the information you have provided, and click Create.

We have now successfully created our provider. Next, we have to create an IAM role using this provider in the trust policy.

Step 2:

In this step, I will create two different roles with different policies. aws_admin_role and aws_user_role .

When configuring role, I select “Role for Identity Provider Access” and “Grant Web Single Sign-on access to SAML Provider”.

I choose my “demo” SAML provider.

In “Verify role trust” settings I don’t change the policy since it allows to assume role with SAML.

And I set permissions as “administration access” since this role is for my aws_admins domain group.

I review my role and create it.

I do the same configuration for aws_users group but when setting permissions, I select “read only access”.

Step 3:

Last step in configuring AWS as a Trusted Relying Party in ADFS and adding some claim rules. In ADFS console by right clicking on “relying party trust” we start the wizard.

In “select data source” screen we can use federation metadata URL or download and upload the metadata file. I use the URL https://signin.aws.amazon.com/static/saml-metadata.xml

I named it as AWS_SAML_Demo .

We will ignore the MFA settings for now

Choose your authorization rules. For my scenario, I chose permit all users to access this relying party. When you’re done, click next.

Finally, I review it and add AWS as a trusted relying party.

Now I will configure our claim rules. Again right click on AWS_SAML_Demo and edit claim rules. We will setup the AWS requested attributes NameId, RoleSessionName, and Role.

Click on “Add Rule”

First I will add a “Transform an incoming claim “ rule.

I named it as “NameId” and used other settings as shown in the picture

Next, I added another rule and select “Send LDAP Attributes as Claims”.

I named it as “RoleSessionName” and used other settings as shown in the below snap. In outgoing claim type, I used https://aws.amazon.com/SAML/Attributes/RoleSessionName .

Now I will use a custom rule and get AD groups and put them in a variable. Then I will match them with our aws_admins and aws_users groups and assign the roles to them.

c:[Type " http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname ", Issuer "AD AUTHORITY"] => add(store = "Active Directory", types = (" http://temp/variable "), query = ";tokenGroups;{0}", param = c.Value);

I will again select custom rule and add the following rules.

c:[Type == " http://temp/variable ", Value =~ "(?i)^AWS-"] => issue(Type = " https://aws.amazon.com/SAML/Attributes/Role ", Value = RegExReplace(c.Value, "AWS-", "arn:aws:iam::135056789012:saml-provider/Demo,arn:aws:iam::135056789012:role/ aws_admin_role "));

This rule uses a custom script to get all the groups from the temporary claim () and then uses the name of the group to create the principal/role pair, which has this format:ARN of SAML provider, ARN of role to assume

For example: it comes out this way: arn:aws:iam:123456789012:saml-provider/Demo,arn:aws:iam:123456789012:role/ aws_admin_role

In the exampl I used an account number of 123456789012. Make sure you change this to your own AWS account.

Here I want to explain these rules. In previous rule, we get the AD groups and put them in a variable. Then in these rules, we match the aws_admins group and redirect the user to our saml-provider “demo” and use the role aws_admin_role . It is same with the aws_users group. We can also use a regex here. If you want to learn more about the ADFS claim rule language refer to this link. And also for ADFS regex refer to this link

We finished our configuration and it is time to test it.

I go to adfs created sign-in page https://54.72.253.85/adfs/ls/IdpInitiatedSignOn.aspx .

I select sign in to my AWS_SAML_demo site and I use my credentials as aws_admin user

Since aws_admin user is in aws_admins group , it is assigned with aws_admin_role .

And for the aws_user credentials I successfully redirected to AWS console with read_only permissions.

I tried to reboot my domain controller but failed since my permission is read_only.

Now you can add/remove users to the specific domain groups and redirect them to AWS console with their granted permissions.

Explore & Enjoy!