Using SAML federation

Before we go any further, let's just explain in a sentence what SAML actually is. Security Assertion Markup Language (SAML) is a standard that allows you to securely exchange authentication data between different domains by using security tokens between an identity provider (IdP) and a SAML consumer. In this case, the IdP will be Microsoft Active Directory (MS-AD) and the SAML consumer will be AWS, specifically IAM roles.

In this section, we will see how you can use SAML to enable single sign-on (SSO) to gain federated access to your AWS Management Console. 

Gaining federated access to the AWS Management Console

For this example, let's say we are using MS-AD. We may have tens or even hundreds of users who may need access to our AWS resources via the Management Console, but instead of creating AWS user accounts for each and every user, we can set up IAM federation using IAM roles and SAML. MS-AD is a SAML 2.0 compliant IdP, and using IAM roles you can allow the IdP to grant MS-AD identities access and permissions to access the AWS Management Console to perform tasks and actions.

To begin with, you need to configure your enterprise network as a SAML provider to AWS.  As a part of this configuration, you will need to do the following:

1. Configure MS-AD to work with a SAML IdP, for example, Windows Active Directory Services.
2. You must then create a metadata.xml document via your IdP, which is a key document in the configuration. This metadata.xml document also includes authentication keys.
3. Using your organization's portal, you must ensure that any requests to access the AWS Management Console are routed to the correct AWS SAML endpoint, allowing that user to authenticate via SAML assertions.  

Once you have created your metdata.xml document, you need to create a SAML provider via the IAM service. To do this, you can follow these steps:

1. Open the IAM dashboard from within the IAM Management Console and select Identity providers:

1. Select the Create Provider button in blue, as shown in the preceding screenshot.
2. Select SAML as the provider type:

1. Enter a provider name and select your metadata.xml document:

1. Select Next and verify your provider information, and if it’s correct, select Create:

1. Once your SAML provider has been created within IAM, you then need to create a role from within IAM that your federated users will assume to gain permissions within your AWS environment. When creating your role, select the SAML 2.0 federation option:

1. Once you have selected your SAML provider, which was created in the previous section, continue to add permissions to the role. The permissions policy of the role will dictate the permissions that federated users will gain when authenticated and follows the same configuration as any other role. The trust policy of the role creates a trust relationship between the IdP and IAM organizations. In this trust, the IdP we just created in IAM is used as a principal for the federation.

The following shows an example of what the trust policy might look like, where I have the AWS account ID as 123456789012 and the IAM IdP as My_SAML_Provider:

{
   "Version": "2012-10-17",
   "Statement": {
     "Effect": "Allow",
     "Action": "sts:AssumeRoleWithSAML",
     "Principal": {"Federated": "arn:aws:iam::123456789012:saml-provider/My_SAML_Provider"},
     "Condition": {"StringEquals": {"SAML:aud": "https://signin.aws.amazon.com/saml"}}
   }
 }

Within this trust policy, you can also include additional conditions that relate to SAML attributes that must match the user for them to assume the role.   

1. The final part of the configuration requires you to notify your organization's SAML IdP about AWS, which is now a service provider. This is completed by installing the following saml-metadata.xml file, which can be found at https://signin.aws.amazon.com/static/saml-metadata.xml.

Once the configuration is complete, users from your organization's Active Directory can be federated through to the AWS Management Console using the permissions set out in the role, as follows:

As illustrated in the preceding diagram, this federated access can be granted in seven steps:

1. Using a portal, which is a part of an organization's IdP, the user within the enterprise uses their organization's portal to direct them to the AWS Management Console. This portal manages the exchange of information between AWS and Active Directory Federation Services (ADFS).
2. When the portal receives the request, verification of the user is performed via the Lightweight Directory Access Protocol (LDAP) identity store.
3. If the user is verified, then the portal creates a SAML authentication response. This response can also include assertions that identify the user.
4. These assertions are then received by the client and are sent to the AWS Management Console sign-in URL.
5. At this point, the security token service (STS) is contacted to gain temporary credentials and to create a console sign-in URL using the credentials generated by the STS. The STS allows you to request temporary credentials for IAM users or for authenticated federated users. For more information on STS, please see the documentation at: https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html

1. This new URL is sent back to the user.
2. The user is then redirected to this new URL, gaining access to the Management Console using the role associated with the user's attributes.   

Now we have discussed SAML federation using your own organization as an IdP to help simplify access management for hundreds or even thousands of corporate users. 

We now know how federation works and the key benefit of using federation. However, sometimes you may need to federate users to your AWS resources, without ever knowing who those people are. An example of this would be if you had a mobile app where users who download the app may need to store high scores, or details in the app that are stored on a DynamoDB database within your AWS environment. How do you manage the access to these resources by users who you have no record of or control over? You could store credentials within the app that would authenticate access, however, this is a bad practice and should be avoided at all costs. Instead, you should use social federation.