AWS：Amazon Cognito 与 STS 和 SAML

Question

In the official AWS documentation about Cognito, in the outline of a use case is stated that:

1.In the first step your app user signs in through a user pool and receives user pool tokens after a successful authentication.

2.Next, your app exchanges the user pool tokens for AWS credentials through an identity pool.

3.Finally, your app user can then use those AWS credentials to access other AWS services such as Amazon S3 or DynamoDB.

Isn't the goal of assigning "AWS Credentials" via tokens achieved via STS ?

What exactly are the differences in scope in terms of granting access to non AWS users to AWS services (say S3 or EC2) among Cognito and STS?

The same source of documentation also states that Cognito is also good for identity federation between AWS and a third party Identity provider (such as social - eg Facebook - or an AD corporate one).

Isn't this also achieved via SAML federation (ie having AWS and the IdP establishing a SAML-based trust relationship first?)

Answer 1

Cognito User Pools, and Identity Pools, are higher-level abstractions than SAML and STS. Let's start with defining what SAML and STS are:

SAML makes single sign-on (SSO) technology possible by providing a way to authenticate a user once and then communicate that authentication to multiple applications.

STS is a web service that enables you to request temporary, limited-privilege credentials for AWS Identity and Access Management (IAM) users or for users that you authenticate

Basically, SAML is a method of transmitting authentication tokens generated by one application to another, and STS is a method of getting authorization tokens (ie AWS credentials) from AWS.

Now, on the other hand, we have Cognito User and Identity Pools:

User Pools provide authentication, like SAML, but they also provide a database of users. SAML does not do this, so if you want to keep user data around, add to it, change it, etc. you need to do it yourself. All SAML lets you do is offload authentication of those users to another party. You have to write all the code to make the authentication happen, though.

User pools can themselves use a SAML authentication provider, or do their own built-in authentication. But in either case, you still end up with a user entity that lives in Cognito and has data associated with it.

Identity Pools provide authorization, ie the decision of what to allow a (usually authenticated, but not always) user to do. They do use STS in the background, to get tokens enabling specific actions, but an Identity Pool chooses based on user characteristics whether and what credentials to grant. An identity pool relies on an authentication provider to determine who a user is; this provider can be a user pool, or a SAML provider, too. An identity pool will automatically check given authentication tokens that they're valid according to the provider, and that they allow the user to get certain authorization tokens.

In summary , Cognito User Pools and Cognito Identity Pools encapsulate the functionality which you would normally need to write yourself to go from a SAML provider to a user database to a mapping of users to permissions to being able to retrieve AWS credentials for those permissions. Instead of making auth calls to a SAML provider (or implementing your own auth), implementing a user database, and then making AWS credentials for a user's privileges, they allow you to configure a user pool to use a given provider (or Cognito's own auth), point an identity pool at the user pool, and tell the identity pool what permissions members of the user pool should have. All the rest is done in the background, for you.