This is the final chapter focusing on access security. So far, we have discussed access control from within your own AWS account, and even from a cross-account perspective. But what if you have hundreds or even thousands of users who need to access your resources? Configuring and setting up IAM users for so many people is not feasible, or even possible (due to user limitations within IAM). So what options do you have to simplify user management for your employees within a large organization? Also, how can you grant access to tens of thousands or even millions of users who are all competing for that high score on your latest viral mobile gaming app to store their accomplishments in one of your AWS databases? This chapter will help you answer all these questions.

The following topics will be covered in this chapter:

• What is AWS federated access?
• Using SAML federation
• Using social federation

Technical requirements

To follow the exercises within this chapter, you must have access to an AWS account and have permissions to configure federation options within the IAM service. For more information on granting access to services, please refer to the topics discussed in Chapter 4, Working with Access Policies. 

What is AWS federated access?

Federated access within AWS allows access to your AWS resources without having the need to create an associated IAM user account. Instead, credentials are federated by an identity provider (IdP), for example, your corporate accounts, such as your Microsoft Active Directory accounts (enterprise federation), or even by a social IdP, for example, using the credentials from your Google, Facebook, or even Amazon account (social identity federation).

Federation allows you to manage your account centrally and reduces the administration required in creating multiple accounts to access your AWS resources.  

There are a number of different options that organizations use to implement federation. We will be looking at two of the most common ones:

• SAML federation
• Social federation

We will then look at how Amazon Cognito uses federation to manage access to web and mobile applications with ease.

We'll start by explaining how you can allow users to authenticate and access your AWS resources using their corporate identities, such as their MS-AD account.

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:

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

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

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

6. 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:

7. 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.   

8. 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

6. This new URL is sent back to the user.
7. 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.

Using social federation

Social federation allows you to build your applications to request temporary credentials. Much like in the previous discussion relating to enterprise federation where we used SAML, these temporary credentials with social federation map to an AWS IAM role that has the relevant permission to access your DynamoDB database.

Instead of using your internal ADFS servers to authenticate users, the users of your app can use widely known social IdPs, for example, Facebook, Amazon, and Google. In fact, as long as the IdP is OpenID Connect (OIDC) compatible, then you can use them for authentication. Using these social IdPs, the user can get an authentication token, which in turn is exchanged for temporary credentials, and these credentials are associated with your specific IAM role with the required permissions.

When creating applications that require social IdPs for authentication, you need to write specific code to interact with the IdP to allow you to call the AssumeRoleWithWebIdentity API, which allows you to replace the token with temporary credentials. However, if you want to remove the need to have to write this specific code for the IdP, then there is another method, and it's actually recommended by AWS. This preferred and best practice method is to use Amazon Cognito.

Amazon Cognito

Amazon Cognito was built purely for the simplification of enabling secure authentication and access control for new and existing users accessing your web or mobile applications. It not only ingrates well with enterprise federation but also social federation. One of the biggest features of Amazon Cognito is that it has the capability to scale to millions of new users, which is great when working with mobile applications, which will be the focus of this discussion.

There are two main components of Amazon Cognito that you should be aware of, these being user pools and identity pools, and they perform different actions that we will see in the following topics.

User pools

User pools are essentially scalable user directories that allow new and existing users to log in to your mobile application using the user pool or they can alternatively federate their access via a social or enterprise IdP. Either way, a profile within the user pool is created for each and every user. These profiles contain no permissions for access to your AWS infrastructure; they allow them to log in to your mobile app as a user and use it.

Once a user is authenticated via the user pool, either from the user pool itself or via a third-party IdP, Amazon Cognito will generate tokens that manage the access to your mobile app.

It is also possible to enable additional features using user pools, such as the ability to enable multi-factor authentication (MFA), providing additional security to your user base. You can also create user pool groups and assign different permissions to different groups. This provides greater access control and prevents all users from having the same access, which might cause a security risk.

Identity pools

Identity pools are different from user pools. Identity pools actually provide you with the ability to assign permissions to users to access your AWS resources used within the mobile app by using temporary credentials. This access can be granted to both federated users and anonymous guest users. Identity pools support federated access for users that have been authenticated by user pools, OpenID Connect IdPs, SAML IdPs, social IdPs, and developer-authenticated identities. These permissions are assigned through IAM roles and can be mapped to different users to provide different permissions sets.

Once a user has authenticated either via a user pool or a social IdP, the token received and managed by Amazon Cognito can then be exchanged for temporary credentials using the identity pools. These credentials can then be used to access the AWS services required when using your mobile app.

Gaining access using user and identity pools

These two types of pool, both user and identity, can be used together or separately, depending on the functional requirements of your mobile app. The following diagram shows gaining access to AWS resources via the user pool for token generation:

This diagram is explained in the following steps:

1. Tokens are received from a third-party IdP, such as Facebook. The user pool then manages these tokens and authenticates the user to the app.  
2. The tokens are then exchanged for temporary credentials, based upon an associated IAM role with set permissions through the identity pool.
3. When these permissions have been assumed, the user of the mobile app is then authenticated and authorized to access the appropriate AWS services.

The diagram that follows shows users gaining access to AWS resources via the identity pool without the user pool:

This diagram is explained in the following steps:

1. A user authenticates with a third-party IdP, such as Facebook. The social IdP generates tokens, which are sent back to the mobile app.  
2. The tokens are then sent to the Amazon Cognito identity pool to be exchanged for temporary credentials, based upon an associated IAM role.
3. When these permissions have been assumed, the user of the mobile app is then authenticated and authorized to access the appropriate AWS services.

If you are building applications to run on a mobile client, then using Amazon Cognito is a great way to implement access management with simplicity and ease using social federation. 

Summary

This chapter highlighted some of the alternative methods for providing access to your AWS resources for identities that sit outside of the IAM service. Introducing federated access allows you to quickly and easily scale your user base, who might require access to your AWS Management Console, or simply require the ability to run APIs to perform actions against your resources.

Enterprise federation allows you to use your existing corporate identities, such as your Active Directory using SAML 2.0. Social federation allows you to scale to millions of users with the introduction of Amazon Cognito managing this elasticity and control of your token and authentication mechanism.

In the next chapter, we'll be looking at how to secure your EC2 instances through the use of Amazon Inspector, key pairs, and EC2 Systems Manager. We'll also look at how to isolate your instance should it become compromised.

Questions

As we conclude this chapter, here is a list of questions for you to test your knowledge regarding its material. You will find the answers in the Assessments section of the Appendix:

1. True or false: Federated access within AWS allows access to your AWS resources without needing to create any permissions.
2. Which AWS service uses federation to manage access to web and mobile applications with ease?

3. What are the two common types of federated access with AWS?
4. What is IdP short for in relation to federated access?
5. True or false: Identity pools actually provide you with the ability to assign permissions to users to access AWS resources used within a mobile app by using temporary credentials.

Further reading

• Amazon Cognito Documentation: https://docs.aws.amazon.com/cognito/index.html#lang/en_us
• AWS identity federation: https://aws.amazon.com/identity/federation/