Hello, my name is Stuart Scott and today I want to speak to you about AWS Identity Federation.  I want to explain what it is, some of the AWS services that can be involved in federation and also highlight some scenarios where you might want to implement it.

If you have any feedback on this course, positive or negative, it would be greatly appreciated if you can contact support@cloudacademy.com.

So, firstly, what is Identity Federation? 

It’s basically a method 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 IdPs authentication.

You’ve probably all been to websites where it presents you with a log in page, where you can either log in using existing credentials native for that service, or you might have an option to authenticate using credentials from a 3rd party provider, such as Facebook, Google, Twitter or LinkedIn etc.  

On the screen here you can see the login page for medium.com you can use existing credentials from identity providers including Google, Facebook, Apple, Twitter and Gmail to create a new Medium account, or log back in to Medium if you’ve already created an account.  In this scenario, Medium would be the Service Provider.

So if you didn't have an account with Medium already, you could select one of these providers to create one.  So as an example if you already had a Google account and were signed in with it, and selected ‘Sign in with Google’ you’d be presented with the following screen

Now here Medium has detected that I didn't have a Medium account associated with my current Google Account, you can see it says “Sorry, we didn't recognize that account’, and so you are asked if you would like to create one.  By selecting Sign up with Google, Medium authenticates my access via my Google credentials, and so trusting the Google IdP, and this enables me to create a new Medium account based off of that authentication.  

So in this example, Google was used as the Identity Provider to authenticate you to Medium with a new account.  The next time I then need to log in to Medium, all I would have to do is select ‘Sign in with Google’ and as long as I were logged in to my Google account already, I would be logged straight into Medium with 1-click, and this directly correlates to the term ‘Single-Sign on’, or SSO.  SSO relates to the method of signing in to one system, which can then be used to authenticate you into another without having to resupply additional credentials. 

Now, the process behind this is fairly simple, when the identity provider has been selected, and the user is authenticated by that provider, an assertion is sent back to the service provider, in this case Medium.  And this assertion is a message that contains metadata and attributes about the user such as their username.  This assertion allows the service provider to authorize access to their services.

So identity federation provides a great way to easily set up access control systems with flexibility and ease for the users and service providers.  

So using this same principle AWS has a variety of services and methods that allows you to access your AWS services via federated access, meaning you don’t need to have a specific identity & access Management user configured in AWS if you already have a user directory that is managed elsewhere that could be used as an Identity Provider.  

Using many different identity standards, including OAuth 2.0, OIDC, which is OpenID Connect, and SAML 2.0, (Security Assertion Markup Language), AWS enables you to easily configure access for contractors and other 3rd parties, in addition to allowing scalable access to authenticate to your mobile and web applications.

Let’s take a quick look at the definitions of these standards according to Wikipedia:

“OAuth is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information on other websites but without giving them the passwords” - Wikipedia

“OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user.” - Wikipedia

“Security Assertion Markup Language 2.0 (SAML 2.0) is a standard for exchanging authentication and authorization identities between security domains. SAML 2.0 is an XML-based protocol that uses security tokens containing assertions to pass information about a principal (usually an end user) between a SAML authority, named an Identity Provider, and a SAML consumer, named a Service Provider.” - Wikipedia

Now we have more of an understanding of federation, I want to take a high level look at some of the services offered by AWS and how they fit into AWS Identity Federation, including

• AWS Single Sign-On, known as SSO
• AWS Identity & Access Management (IAM)
• And Amazon Cognito

Now, by the name alone we can safely assume that this has something to do with federated access.  

This service has primarily been designed for users to easily access multiple accounts within their AWS Organization enabling a single sign-on approach negating the need to provide credentials for each account.  For those unfamiliar with AWS Organizations, they provide a means of centrally managing and categorizing multiple AWS accounts that you own, bringing them together into a single organization, helping to maintain your AWS environment from a security, compliance, and account management perspective.

You can either use the AWS SSO own built in user directory which allows you to create unique users based on e-mail addresses, or alternatively connect AWS SSO to one of the supporting identity providers, such as your own corporate MS Active Directory if you are using one.  

Either way, AWS SSO enables you to create different groups while leveraging the power of IAM roles and permissions allowing you to control what access users or groups have in specific AWS Accounts within your organization.  

When Users have been configured, they can connect via their own portal which will list all AWS accounts they have access to, along with roles they have access to adopt, and if they would like to access the Management console or use temporary credentials for AWS CLI access.

AWS SSO can also be used to manage access to cloud-based apps using SAML 2.0 such as Office 365 and Salesforce.  

As I mentioned previously, Identity federation allows you to access and manage AWS resources even if you don't have a user account within IAM.  

Whereas AWS SSO allows you to create a single sign-on approach to multiple accounts in your AWS organization using the in-built user directory or MS-AD, AWS IAM allows you to configure federated access to your AWS accounts and resources using different identity providers for each AWS account.  Examples include both SAML 2.0 for enterprise federation using MS-AD, and OpenID Connect, classed as web identity federation, such as Google, PayPal and Amazon. As a result you could allow access to your environment using these Identity Providers instead of setting up users with a new identity within AWS IAM.

The benefits of this is twofold. It minimizes the amount of administration required within IAM and it allows for a single sign-on solution. 

As a part of the configuration process to implement federated authentication, a trust relationship between the identity provider and your AWS account is established. AWS supports two types of identity providers, OpenID Connect, also often referred to as web identity federation, and SAML 2.0.

Amazon Cognito has been built purely to enable the simplification of enabling secure authentication and access control for new and existing users accessing your web or mobile applications, rather than your AWS account.  It not only integrates well with SAML 2.0 but also web identity federation as well.  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.

Cognito also allows you to use a custom portal allowing you to add a personalized sign-in page with branding and your own logo.

There are 2 main components of Amazon Cognito, these being ‘User Pools’ and ‘Identity Pools’ and they perform different actions.

User Pools are essentially a scalable user directory that allows new users to sign up, or existing users to log in to your mobile application using their native credentials from the user pool, or they can alternatively federate their access via a web or enterprise IdP.  

Identity Pools are different to user pools in that they actually provide you with the ability of accessing AWS resources called upon by your web or mobile app by using temporary credentials and the Security token service.

So let me summarize the key difference between these 3 AWS options to implement federated access to AWS.

• AWS SSO allows you to create a Single sign-on approach to access multiple AWS accounts within an AWS Organization using a single identity provider for all.
• AWS IAM allows you to configure different OpenID or SAML identity providers for each of your AWS accounts.
• Amazon Cognito enables secure authentication to your web or mobile applications using both SAML 2.0 and web identity federation.

That brings me to the end of this introductory course covering AWS identity Federation. You should now have a greater understanding of what it is and some of the services that can be used to implement different kinds of federated Access.

If you have any feedback on this course, positive or negative, please send an e-mail to support@cloudacademy.com, your feedback is greatly appreciated. Thank you for your time and good luck with your continued learning of cloud computing. Thank you.