Integration with external directories

The AWS IAM service is offered as a simple way to build authentication into our application. But, there are some limitations as to what IAM can provide.

The typical limitations of IAM are soft limits. For instance, the number of users we can create in IAM is limited to 5,000, the number of groups to 300, and so on, and if our application is built for the web, we would also expect web-scale user numbers to be supported. When we talk about web-scale, we are talking about hundreds of thousands, millions, and potentially billions of users. To support large sets of individually authenticated users, IAM can be integrated with web identities, Security Assertion Markup Language (SAML), and OpenID-compatible providers. There is built-in support for Amazon, Amazon Cognito, Google, and Facebook web identity providers, but any other compatible provider can be used as well. This can help us make use of the web identity provider's account management system to authenticate our users seamlessly and with very little effort. Upon authentication, the application can make use of the AssumeRoleWithWebIdentity call and allow the application to get permissions to access AWS web resources.

For example, you can build a mobile game that keeps track of scores in a DynamoDB database and game files in S3. To be able to access game files and record the score for each individual user, the application would assume the role, and then be able to enter a new high score straight into the DynamoDB table and access the S3 bucket to retrieve the game files. There is no need to store any credentials in the application, which is insecure:

Another example of why we would need to use an external directory is when we are using an existing corporate directory with possibly millions of objects that have very complicated relationships. Since the directory already exists and the users are already used to the current authentication system, we can simply federate our corporate directory with IAM. This allows us to use our corporate directory to provide a single sign-on system that also allows access to the AWS services. The federated system can delegate the authentication to the corporate directory and then use the AWS STS service to issue temporary credentials that can be then passed along with every request to the AWS environment, enabling the user to be granted access to AWS.

Here is an example flow of authentication with AWS federated access with Active Directory:

1. The user authenticates against the Active Directory Federated Service (ADFS).
2. Security Assertion Markup Language is used to issue an assertion back to the user's client.

1. The SAML assertion is sent to the Security Token Service (STS) to assume a role within IAM.
2. The STS responds to the user requesting federated access with temporary security credentials.
3. The user is granted federated access to the necessary AWS services as per the role permissions: