Using Roles for Federated Access
Start course
4h 50m

This section of the AWS Certified Solutions Architect - Professional learning path introduces the key identity management, security, and encryption services within AWS relevant to the AWS Certified Solutions Architect - Professional exam. Core to security is AWS Identity & Access Management commonly referred to as IAM. This service manages identities and their permissions that can access your AWS resources, so understanding how this service works and what you can do with it will help you to maintain a secure AWS environment. IAM is an important service in ensuring your resources are secure.

Want more? Try a Lab Playground or do a Lab Challenge

Learning Objectives

  • Learn about identity and access management on AWS, including users, groups & roles, IAM policies, MFA, identity federation, and cross-account access
  • Learn the fundamentals of AWS Web Application Firewall (WAF), including what it is, when to use it, how it works, and why use it
  • Understand how to configure and monitor AWS WAF
  • Learn about AWS Firewall Manager and its components
  • Learn how to configure AWS Shield
  • Learn the fundamentals of AWS Cognito

In this lecture, I want to discuss how users who have been federated can access your resources using roles. When doing so you have two options. Firstly, Web Identity, this allows users federated by a specified external web identity or OpenID Connect provider, to assume this Role to perform actions in your account. And secondly, SAML 2.0 federation, this allows users that are federated with SAML 2.0, to assume this Role to perform actions in your account.

So let's first look at Web Identity and a scenario where you might need to create a Role. You've just created a new mobile application that requires access to Amazon S3 to store media such as photos and videos from users worldwide. As a part of the operations of your application, it will require permissions to S3, to upload and download this media from tens of thousands of users. Embedding long-term credentials into your application code to do this goes against all security best practices. And so instead, you should design your application to request temporary credentials from authenticated users through web identity federation. 

Before I go any further, let me explain what identity federation is. It's basically a method of authentication where two different providers can establish a level of trust, allowing users to authenticate from one, which authorizes them to access resources in the other. During the federation process, one party would act as an Identity Provider, known as an IdP, and the other would be the service provider, an SP. The identity provider authenticates the user and the service provider controls access to their service or resources based on the IdP's authentication.

You've probably all been to websites where it presents you with a login page, where you can either login using existing credentials, native that service, or you might have an option to authenticate using credentials from a third party provider, such as Facebook, Google, Twitter, or LinkedIn, et cetera. So going back to our example, our application run on AWS would be the service provider, and the Web Identity provider could be Google or Facebook, for example.

So when users authenticate to your app via web identity federation, they will receive an authentication token. This token is then exchanged for temporary security credentials in AWS, which can be mapped to your IAM Role, using the AssumeRoleWithWebIdentity API. This then allows the relevant access to Amazon S3 provided by the role, to carry out the operations needed by the application.

Generally, when working with mobile applications, the preferred and recommended method for managing access, would be via Amazon Cognito, to manage his federation process. For more information related to Amazon Cognito, please see our existing course here.

Let's now take a look at SAML 2.0 federation. Whereas web identity federation is generally used for large, wide scale of access from unknown users, SAML 2.0 is generally used to authenticate your employees using existing directory services that you might already be using. SAML, which stands for Security Assertion Markup Language, is a standard that's used to exchange authentication and authorization identities between different security domains, which uses security tokens containing assertions to pass information about a user between a SAML Identity Provider and a SAML consumer.

For example, you might already to be using Microsoft Active Directory to authenticate your employees to your internal network. And so you might not want to or need to create lots of users in IAM with their own set of credentials. Instead, it would be easier to allow them to federate their access through via SAML, integrating with your ADFS server. The benefits of this are twofold. It minimizes the amount of administration required within IAM and it allows for a single sign on solution.

As the vast majority of organizations today are using Microsoft Active Directory, using MSAD is an effective way of granting access to your AWS resources without going through the additional burden of creating potentially hundreds of IAM user accounts. Let's take a high-level look at how active directory authentication mechanism is established. This example will assume the user within an organization requires API access to S3, EC2, and RDS. This scenario will also include the use of an AWS service called Security Token Service, STS. The Security Token Service allows you to gain temporary security credentials for federated users via IAM, associated with IAM roles and policies. Let's look at this in more detail via a diagram.

A user within an internal organization initiates a request to authenticate against the Active Directory Federated Service, an ADFS server, via a web browser using a single sign on URL. If their authentication is successful by using their Active Directory credentials, SAML will then issue a successful authentication assertion back to the user's client, requesting federated access. The SAML assertion is then sent to the AWS Security Token Service, to assume a role within IAM using the AssumeRoleWithSAML API. STS then responds to the user requesting federated access with temporary security credentials, with an assumed role and associated permissions, allowing S3, EC2, and RDS access as per our example, the user then has federated access to the necessary AWS services as per the role's permissions.

This is a very simple overview of how federation is instigated from the user for API access to specific AWS services. Corporate identity federation is always authenticated internally first by Active Directory before AWS, when creating your role for users federating via SAML, you can specify if you want to provide programmatic access only, or programmatic and AWS management Console access, in addition to specific permissions to access other AWS resources.

About the Author
Learning Paths

Danny has over 20 years of IT experience as a software developer, cloud engineer, and technical trainer. After attending a conference on cloud computing in 2009, he knew he wanted to build his career around what was still a very new, emerging technology at the time — and share this transformational knowledge with others. He has spoken to IT professional audiences at local, regional, and national user groups and conferences. He has delivered in-person classroom and virtual training, interactive webinars, and authored video training courses covering many different technologies, including Amazon Web Services. He currently has six active AWS certifications, including certifications at the Professional and Specialty level.