AWS allows you to access and manage AWS resources even if you don't have a user account within IAM through the use of identity federation. Put simply, identity federation allows users from identity providers, IDPs, which are external to AWS to access AWS resources securely without having to supply AWS user credentials from a valid IAM user account. An example of an identity provider can be your own corporate Microsoft Active directory. 

Federated access would then allow the users within it to access AWS. Other forms of identity providers can be any OpenID Connect Web Provider. Common examples of these are Facebook, Google, and Amazon. So, what does this mean? Well, this means that if you need users to access AWS resources that already have identities that fit into these categories, then you could allow access to your environment using these existing accounts, instead of setting up each of them with a new identity within AWS IAM, effectively allowing for a single sign-on solution. 

As the vast majority of organizations today are using Microsoft Active Directory, this is an effective way of granting access to your AWS resources without going through the additional burden of creating IAM user accounts. As a part of the configuration process to implement federated authentication, a trust relationship between the identity provider and your AWS account must be established. AWS supports two types of identity providers, web identity federation and SAML 2.0 based federation. 

Web identity federation allows authentication between AWS resources and any public OpenID Connect Provider, such as Facebook, Google, or Amazon. When it's set up and configured and access is requested by a user to an AWS resource, then the identity provider will exchange an authentication token for temporary authentication credentials. And these credentials are associated to an IAM Role with pre-configured permissions allowing authorized access to the resource as defined by that role. SAML 2.0 based federations can allow your existing Active Directory users to authenticate to your AWS resources, allowing for a single sign-on approach. 

SAML stands for Security Assertion Markup Language, and allows for the exchange of security data, including authentication authorization tokens to take place between an identity provider and a service provider. In this case, the identity provider is Microsoft Active Directory service and the service provider is AWS. 

To learn more about AWS Federation and SSO, please see your exiting course here. Also, if you're looking to provide a means of authentication to your mobile web applications, then please see our existing course which covers Amazon Cognito here. It explores Amazon Cognito and how it can be used to manage authentication and authorization to your applications. And starts with a general overview of Amazon Cognito and when to use it. It then moves on to user pools and identity pools, and how Cognito can be integrated with your mobile and web apps to sync your application's user data across various platforms.