Configure ADFS Integration with AWS Management Console

Uncategorized

With the proliferation of public cloud, there comes with it questions around how do you manage authentication and identity to these third party systems. AWS is one of the most popular ones, so today we will walk through how to integrate AWS with ADFS. This article will assume you already have a working ADFS server and AWS account setup. We will walk through configuring it so that two sets of users can login, each with a separate role, or set of permissions.

Active Directory Setup

In your AD, lets configure two different AD groups:

AWS-FULLADMINS

AWS-DNSADMINS

Image

 

ADFS Metadata

Now, we need to download the metadata file from your ADFS server, this is located at https://[YOURADFSSERVER]/federationmetadata/2007-06/federationmetadata.xml

We will need to upload this file into AWS later on.

AWS Configuration

Next, let’s login to our AWS management console and navigate to the Identity and Access Management console. Now, lets go to Identity Providers on the left hand side and select Create Provider

Image

 

Set the provider type to SAML, a name to identity your provider, and then upload your FederationMetadata.xml file you download from your ADFS server previously.

Image

 

 

Select Next -> Create. Now, select the provider you just created, as you will need to copy the provider ARN of the object, as we will need it for our SAML rules later on:

Image

 

In our example, lets say that our provider ARN is:

arn:aws:iam::123456789012:saml-provider/Port25Guy

Now, we need to configure the roles that our users will get when they log in. We are going to tie our Active Directory groups created earlier to these roles later in the SAML config. Still in the IAM, navigate to Roles -> Create Role

Select SAML 2.0 Federation, from the dropdown select the identity provider you created earlier, and select Allow programmatic and AWS Management Console access:

Image

 

Select next, and now we are going to select our roles. This first one will be matched to our AWS-FULLADMINS group so we will select AdministratorAccessImage

 

Now, lets name the role:

Image

Let’s repeat the process but this time creating the role for AWS-DNSADMINS, this time we will find the AmazonRoute53FullAccess role:

Image

Now, for each of the roles you created, select them, and copy the ARN similar to how we did it for the identity provider previously:

Image

 

Mine map out like this:

AWS-FULLADMINS -> arn:aws:iam::123456789012:role/AWS-FULLADMINS

AWS-DNSADMINS -> arn:aws:iam::123456789012:role/AWS-DNSADMINS

At this point we are done with the AWS config, we are ready to create our relying party trust in ADFS and configure the necessary claim rules.

ADFS Configuration

In ADFS navigate to Relying Party Trust -> Add Relying Party Trust -> Claims AwareImage

 

Select Import data about… and use the URL https://signin.aws.amazon.com/static/saml-metadata.xml

Image

 

Set the display name to anything you want:

Image

 

Set your Access Control Policy accordingly:

Image

Select Next -> Finish

If you didn’t have selected to Edit Claim Issuance policy, highlight the Amazon Web Services trust, and select Edit Claim Issuance Policy

Image

Click Add Rule -> Transform an Incoming Claim

Image

 

Claim Rule Name -> Name ID

Incoming claim type -> Windows account name

Outgoing claim type -> Name ID

Outgoing name ID format -> Persistent Identifier

Image

Next, create another rule -> Send LDAP Attributes as Claims

Image

 

Claim rule name -> Session Name

Attribute Store -> Active Directory

LDAP Attribute -> User-Principal-Name

Outgoing Claim Type -> https://aws.amazon.com/SAML/Attributes/RoleSessionName

Image

 

Note the outgoing claim type IS case sensitive.

Now we need to create our rules to map our groups in AD to AWS roles. Here I will deviate from the AWS instructions and do things a little bit differently. I find this easier than the AWS instructions which require the groups and roles names to match and relies on REGEX to link the two inside the SAML language. The downside is that it can require more rules in the Claim Issuance Policy, and requires more steps to setup.

First, we are going to create a temp rule that we will use to build the initial language we need for our rule.

Select Add Rule -> Send Group Membership as a Claim

Image

 

Name the rule whatever you need, we will delete this after. The only important piece here is to select the users group. For outgoing claim type and value, it does not matter:

Image

 

Now, select Finish -> Highlight the rule you just created and click Edit -> View Rule LanguageImage

Copy the language here to notepad:

Image

 

You want to replace this line:

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role", Value = "admin", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, ValueType = c.ValueType);

with the following:

=> issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = "arn:aws:iam::123456789012:saml-provider/Port25Guy,arn:aws:iam::123456789012:role/AWS-FULLADMINS");

You should replace this section:

Value = “arn:aws:iam::123456789012:saml-provider/Port25Guy,arn:aws:iam::123456789012:role/AWS-FULLADMINS”

with the ARN of your Identity Provider and the ARN of your role that you copied from AWS previously.

Now, your complete rule should look like the following:

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-1693000147-1615933772-1549220743-5440", Issuer == "AD AUTHORITY"]
=> issue(Type = "https://aws.amazon.com/SAML/Attributes/Role", Value = "arn:aws:iam::123456789012:saml-provider/Port25Guy,arn:aws:iam::123456789012:role/AWS-FULLADMINS");

Essentially the top half of the rule is seeing if your a member of the AD group via SID, and then if you are, sending a claim to AWS that has the identity provider ARN and role ARN in the claim.

Repeat this process for your second AD group and AWS role, generating the custom rule language. Save the language as we will need it right now.

Delete your temp rule, it is no longer needed.

Select Create Rule -> Send Claims Using a Custom Rule

Image

 

Name the Claim Rule for the appropriate role, then paste in the custom language you created from above:

Image

Repeat the above step for the AWS-DNSADMINS role and AD group:

Image

 

Your Issuance Transform Rules should look similar to the above:

Image

 

Testing Access

First, you need to make sure that you have the IDP Initiated Logon page available on ADFS, you can do that with the following powershell command:

Set-AdfsProperties -EnableIdPInitiatedSignonPage $true

Now, go to the following URL:

https://[YOURADFSSERVER]/adfs/ls/IdpInitiatedSignOn.aspx

Select Sign In:

Image

 

Then select Amazon Web Services

Image

 

You should get redirected to the AWS console page:

Image

 

It will list that it is a Federated Login, as well as the identity provider/username as your session name. You are all set!

 

Logging in without IDP Portal Page:

ADFS has an annoying configuration in that the IDP login page lists anonymously the resources available through that server:

Image

 

For this reason, many organizations disable this page, in fact Windows Server 2016 disables it by default. However, AWS doesn’t seem to allow any type of SP initiated logon. So are you out of luck? Nope, we just need to use a special URL to do so.

In ADFS, navigate to the AWS relying party trust, go to Properties->Identifiers

Note the relying party identifiers, which in our case is urn:amazon:webservices.

Now use the below URL, obviously entering in your ADFS FQDN:

https://[YOURADFSSERVER]/adfs/ls/IdpInitiatedSignOn.aspx?loginToRp=urn:amazon:webservices

Notice after the loginToRP= we enter in the identifier we copied from above. After your ADFS server authenticates you, you’ll be automatically logged into the AWS console, while having the IDP portal page disabled!

Leave a Reply

Your email address will not be published. Required fields are marked *