Access to externally authenticated users (identity federation)
Your users might already have identities outside of AWS, such as in your corporate directory. If those users need to work with AWS resources (or work with applications that access those resources), then those users also need AWS security credentials. You can use an IAM role to specify permissions for users whose identity is federated from your organization or a third-party identity provider (IdP).
Note
As a security best practice, we recommend you manage user access in IAM Identity Center with identity federation instead of creating IAM users. For information about specific situations where an IAM user is required, see When to create an IAM user (instead of a role).
Federating users of a mobile or web-based app with Amazon Cognito
If you create a mobile or web-based app that accesses AWS resources, the app needs
security credentials in order to make programmatic requests to AWS. For most mobile
application scenarios, we recommend that you use Amazon Cognito
Federating users with public identity service providers or OpenID Connect
Whenever possible, use Amazon Cognito for mobile and web-based application scenarios. Amazon Cognito does most of the behind-the-scenes work with public identity provider services for you. It works with the same third-party services and also supports anonymous sign-ins. However, for more advanced scenarios, you can work directly with a third-party service like Login with Amazon, Facebook, Google, or any IdP that is compatible with OpenID Connect (OIDC). For more information about using OIDC federation using one of these services, see OIDC federation.
Federating users with SAML 2.0
If your organization already uses an identity provider software package that supports SAML 2.0 (Security Assertion Markup Language 2.0), you can create trust between your organization as an identity provider (IdP) and AWS as the service provider. You can then use SAML to provide your users with federated single-sign on (SSO) to the AWS Management Console or federated access to call AWS API operations. For example, if your company uses Microsoft Active Directory and Active Directory Federation Services, then you can federate using SAML 2.0. For more information about federating users with SAML 2.0, see SAML 2.0 federation.
Federating users by creating a custom identity broker application
If your identity store is not compatible with SAML 2.0, then you can build a custom identity broker application to perform a similar function. The broker application authenticates users, requests temporary credentials for users from AWS, and then provides them to the user to access AWS resources.
For example, Example Corp. has many employees who need to run internal applications that access the company's AWS resources. The employees already have identities in the company identity and authentication system, and Example Corp. doesn't want to create a separate IAM user for each company employee.
Bob is a developer at Example Corp. To enable Example Corp. internal applications to access the company's AWS resources, Bob develops a custom identity broker application. The application verifies that employees are signed into the existing Example Corp. identity and authentication system, which might use LDAP, Active Directory, or another system. The identity broker application then obtains temporary security credentials for the employees. This scenario is similar to the previous one (a mobile app that uses a custom authentication system), except that the applications that need access to AWS resources all run within the corporate network, and the company has an existing authentication system.
To get temporary security credentials, the identity broker application calls either
AssumeRole or GetFederationToken to obtain temporary security
credentials, depending on how Bob wants to manage the policies for users and when the
temporary credentials should expire. (For more information about the differences between these
API operations, see Temporary security credentials in IAM
and Permissions for temporary security
credentials.) The call returns temporary security
credentials consisting of an AWS access key ID, a secret access key, and a session token.
The identity broker application makes these temporary security credentials available to the
internal company application. The app can then use the temporary credentials to make calls to
AWS directly. The app caches the credentials until they expire, and then requests a new set
of temporary credentials. The following figure illustrates this scenario.
This scenario has the following attributes:
-
The identity broker application has permissions to access IAM's token service (STS) API to create temporary security credentials.
-
The identity broker application is able to verify that employees are authenticated within the existing authentication system.
-
Users are able to get a temporary URL that gives them access to the AWS Management Console (which is referred to as single sign-on).
For information about creating temporary security credentials, see Compare AWS STS credentials. For more information about federated users getting access to the AWS Management Console, see Enabling SAML 2.0 federated users to access the AWS Management Console.
