‫So now let's talk a service that I wish wasn't named
‫like this, but is named like this.
‫It's the Cognito Identity Pools,
‫also called Federated Identities.
‫And I wish it wasn't named like this
‫because it's so not the same as a Cognito User Pool,
‫but it's under the same umbrella of Cognito,
‫which I don't like, but it's just my personal opinion.
‫Let's try to understand what Cognito Identity Pools are.
‫So, our users are outside of our AWS environment,
‫and there can be a web application users,
‫or mobile users, and they want access to stuff
‫within our AWS environments.
‫So for example, they want to have access
‫to DynamoDB table, or an S3 bucket.
‫And so to access these things,
‫they need temporary AWS credentials.
‫So we cannot create normal IAM users for these users
‫because there are too many of them,
‫it doesn't scale, and we don't trust them.
‫So instead, we're going to give these users access
‫to AWS through a Cognito Identity Pool.
‫So this identity pool can allow your users to log in
‫through a trusted third party.
‫And that could be a public provider,
‫for example, log in with Amazon, Facebook, Google and Apple,
‫or even allow the users that are already logged in
‫with the Amazon Cognito user pool,
‫or even allow OpenID Connect Providers and SAML Providers,
‫or finally, the Developer Authenticated Identities,
‫which is a custom login server.
‫So, on top of all these login providers,
‫to allow to give our users an identity
‫before they trade it for AWS credentials,
‫we can allow unauthenticated guest users access into AWS.
‫So it is possible for us to define a Guest Policy,
‫and give our guest users AWS credentials.
‫So, once the users have obtained these AWS credentials,
‫then they can access the AWS services directly,
‫with an API call using an SDK, or through the API gateway.
‫So these credentials, these credentials that the users get,
‫they have an IAM policy that is defined by what we do
‫in Cognito Identity Pools, and they can be customized
‫based on the value of the user ID, for fine grained control.
‫And we see this in this theory lecture.
‫So, I'll try to make it as simple as possible.
‫So we have a web and mobile applications,
‫and they want to access our private S3 Bucket,
‫and a DynamoDB Table.
‫But we want to make sure the users first get
‫credentials of AWS, but we don't wanna create
‫an IAM users for these applications.
‫So what do we do?
‫We're going to leverage Cognito Identity Pools,
‫but first, we want the users to get a login
‫and obtain a token out of this login.
‫So we will allow our users to connect,
‫for example, to a Cognito User Pool,
‫or to connect to Google login, Facebook login,
‫so for social identity providers,
‫or SAML, or OpenID Connect.
‫So they will login with any of those.
‫They will get a token, and they will go
‫and talk to the Cognito Identity Pool service
‫to exchange the token for temporary AWS credentials.
‫So first, the identity pool will verify
‫the login with whatever provider we have defined,
‫and then, once it's validated, the Cognito Identity Pool
‫will talk to the STS service to get temporary
‫credentials for our web and mobile application users.
‫Once this is done, the credentials are returned
‫to our applications, and they can use,
‫and directly access AWS, thanks to these credentials,
‫and the associated IAM policy.
‫So this is very simple, and a big difference
‫from what Cognito User Pools are,
‫but you see there is a lot of common,
‫especially around the identity provider.
‫So, the question is, how does it work, if I use
‫Cognito Identity Pools with Cognito User Pools?
‫So here's the answer.
‫We have the same diagram.
‫We want our users to connect to a Private S3 Bucket,
‫or DynamDB Table, but we want their identity
‫to be stored in Cognito User Pools.
‫Okay, so this is the same diagram as before,
‫but I'm just expanding into Cognito User Pools.
‫So they need to login and get a token.
‫And why would you do this?
‫Well, I do, because we want all our users
‫to be centralized in the Cognito User Pool database,
‫so it could be an internal database of users,
‫or we can also enable social identity providers,
‫SAML and OpenID Connect,
‫as Federated Identity Providers,
‫for our Cognito User Pools,
‫but none the less, all users are going to show up
‫in my Cognito User Pool.
‫Then, our web and mobile application users
‫can exchange the adjacent web token obtained
‫from Cognito User Pools, into the Cognito Identity Pool,
‫for credentials, so there will be verification
‫of these token, and then talking to the STS service
‫to get these credentials that will be returned
‫to our web and mobile applications.
‫And then, thanks to these credentials,
‫we will have direct access into AWS.
‫If you understood this, I'm so happy,
‫and you're good to go for the exam.
‫So, how does Cognito Identity Pools
‫decide which role to apply to which user?
‫Well, we can define a default IAM role
‫for both authenticated users, and guest users.
‫So that means the guest users will have one IAM role,
‫and the other will have another one's IAM role.
‫And we can define rules to choose which role
‫goes to which user, based on the user ID.
‫And then we can customize the IAM policy,
‫thanks to using policy variables,
‫and this will be allowing us to make sure
‫that the users will only get access to what they need
‫in DynamoDB or Amazon S3, for example.
‫These IAM credentials, as we said in the previous slide,
‫are obtained by Cognito Identity Pools through STS.
‫And the roles must have a trust policy
‫of Cognito Identity Pools for it to work.
‫So, I'll make it a bit more concrete,
‫here is an example.
‫So we want to give our guest users access to AWS,
‫so we want to create an IAM policy, for example,
‫that would allow any guest user to do a get object
‫on a bucket for my picture, the jpeg.
‫So this would give us, for the guest users,
‫access to AWS with a very simple,
‫and obviously restricted, IAM policy.
‫Then, for the authenticated users,
‫you can define a policy variable on Amazon S3,
‫so our users are connected,
‫but we want to make sure that they only have access
‫to a prefix in your S3 bucket,
‫that represents what the user's identity is.
‫So, as such, you can use a policy variable,
‫like here in green, and this is allowing
‫our user to only access within the bucket we've defined,
‫anything that starts with a prefix of its user ID.
‫So effectively, we gave the user access,
‫only to what it can access, thanks to his, its user ID.
‫And we can define the same on DynamoDB.
‫So here's a sample policy, on which we allow
‫the user to do anything it wants on DynamoDB,
‫from my table, as long as the leading key
‫for DynamoDB is corresponding to the user ID of the user.
‫So effectively, we've done row-based security,
‫thanks to this IAM policy.
‫Now these are advanced, but I just wanted
‫to give you a sneak peek into how they worked.
‫So that's it for this theory lecture.
‫In the next lecture, we're going to practice
‫Cognito Identity Pools.