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.