Amazon AWS Certified SysOps Administrator Associate – Identity Part 3

6. [DVA] Cognito User Pools Overview

So the first service we will see into Cognito is called Cognito User Pools or cup. And this is a way to create a serverless database for your web and mobile application users. So what is a serverless database? That means that your users can use, for example, a simple login, their username or their email and a password connection, a combination to connect into your application. They can also obviously reset their passwords. We can, thanks to Kunito user pools, do an email and phone number verification. We can enable multifactor authentication for our users and we are able to tell our users they can log in with Google, Facebook or even SAML. So this is called Federated identities.

So this is pretty much the thing you see when you go into any other website they ask you to register. Users either create a username and password or log in Google, Facebook or some other way. There is a feature that you can block users if their credentials are compromised elsewhere. So AWS scans the web for compromised credentials and will let your user knows into Cooking Tear user pools. And then finally, and then finally when your users log in with the cooking Tear user pool, what they get back from the API is a GWT. So a JSON web token.

So in a diagram, what does our cognitive user pool look like? Well, they’re a database of users. So Kapp will have its own internal database of user that we can see. And then our mobile applications and our web application can log in against our cognitive user pool. And whenever they’re logged in, the cup will return to our used to our mobile applications and our web applications, adjacent web token JWT. As I said, we can also provide login with Amazon or Google or Facebook facility into our cognitive user pools. So we can do federation through third party identity providers and offer a social login through a social identity provider. So. Login with Google.

Login with Facebook. We can also integrate more specific identity providers with SAML or even Open ID Connect. If your identity provider supports OpenID Connect. So that’s for how cup works at a high level, then let’s talk about the integrations within AWS for cup. So cup integrates with the API gateway and the application load balancer natively. So for the API gateway, we’ve seen how that works already. Our users will authenticate with our cooking to user pool and retrieve the JSON web token from it. Then they will pass the web token, the JSON web token to the API gateway which will evaluate the cooking token and make sure that it is valid and then allowing us to access our back end.

And this is how we provide authentication onto our API gateway. But very simply, we can also use an application balancer. So using application balancers listeners and rules, we are able to authenticate our users against Kineto user pools. And then once done, we can forward our users to the back end in our target group, which could be easy to instances, lambda functions or ECS containers. So that’s it for a high level of communal user pools. Now, let’s do a hands on the next lecture to practice and see how they work in details.

7. [DVA] Cognito Identity Pools Overview

So now let’s talk about 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 the cognitiveo 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 asteroid bucket. And so to access these things, they need temporary AWS credentials. So we cannot create normal im users for these users because there are too many of them, it doesn’t scale and we don’t trust them.

So instead we are 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, login with Amazon, Facebook, Google and Apple. Or even allow the users that are already logged in with the Amazon cooking to user pool or even allow Open ID 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 their identity before they trade it for AWS credentials, we can allow unauthoriqued 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 the API call using an SDK or through the API gateway. So these credentials, these credentials that the users get, they have an im 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 grain control. And we’ll 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 SR bucket and a DynamoDB table. But we want to make sure the users first get credentials of AWS.

But we don’t want to create an im 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 logins. So for social identity providers or sample or open ID connect. So they will log in 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, cooking to 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 im policy. So this is very simple and a big difference from what cognito user pools are. But you see, there’s 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 entry bucket or DynamoDB 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’re going to log in and get a token. And why would you do this? Well, maybe because we want all our users to be centralized in the cognitive 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 nonetheless, all users are going to show up in my cognito user pool.

Then our web and mobile application users can exchange the JSON 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 pool decide which role to apply to which user? Well, we can define a default im role for both authenticated users and guest users.

So that means the guest users will have one im role and the other will have another one’s im 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 im 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 is free. For example, these im credentials, as we said in the previous slide, are obtained by Cooking to Identity pools through Sts. And the roles must have a trust policy of Cooking to Identity pool 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 and so we want to create an im 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 im policy. Then, for the authenticated users, we can define a policy variable on Amazon sree. So our users are connected, but we want to make sure that they only have access to a prefix in your s three bucket that represents what the user identity is. And so, as such, you can use a policy variable like here in green. And this is allowing a user to only access within the bucket.

We’ve defined anything that starts with the prefix of its user ID. So, effectively, we gave the user access only to what it can access thanks to its user ID, and we can define the same on DynamoDB. So here is a sample policy in which we allow the user to do anything it wants on DynamoDB. For 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 im policy. Now, these are advanced, but I just want 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.

8. [DVA] Cognito User Pools vs Cognito Identity Pools

So a common question will be what is the difference between a cognito user pool and an identity pool? And I think they’re very different. But let me emphasize this. So with Kogma user pools, we have a database of users for our web and mobile applications and we can federate the logins through public social providers OIGC and SAML. We can customize the UI used for authentication, including the logo, and it has triggered triggers with lambda during the authentication flow.

If we want to integrate, for example, with a custom analytics solution, cognito identity pools allow us to obtain a device credentials for our users and the users can log in again through public social OIDC SAML and also the cognitive user pools. The users can also be guest users, so unauthenticated users, and they will be mapped to im roles and policies in which we can leverage policy variables to make them tailored for our users.

So, in summary, if you use cooking to user pools and cooking to identity pools, the first one is to manage the user and password and the second one is to give access to AWS services. So this is what we were represented in the graph in the first place. So our Web and mobile applications wants to access our SV bucket and our DynamoDB table.

They will log in and get the token from coming to your pools, which can be having its own database of users and be integrated with logins for social providers SAML and Open ID Connect. Then we will exchange the tokens for a voice, credentials and cooking to identity pools which will validate the login, then talk to Sts to get these credentials and pass them back to our web and mobile applications. And then finally, now that we have these roles and these tokens, we can directly access AWS resources. So hopefully that’s very clear and I will see you in the next lecture.

9. [SAA] AWS Single Sign On (SSO) – Overview

Let’s talk about AWS. Single signon or SSO. It is to centrally manage single signon to access multiple accounts and thirdparty business applications. So you’re going to go to a portal, and once you’re logged in to that single signon portal, you can log in to any of your AWS accounts dropbox Officers Slack without reentering your login. That’s why it’s called single signon. So you log in once and you have access to all the things that Single Signon is configured to access. So the really cool thing is that it is integrated with AWS organizations. So if you have tons of accounts within your organization, you just set up AWS single sign on and you will have access to login to all the accounts within that organization. So one login for all the accounts, it supports SAML 20 markups.

So he has integration with SAML and deep integration with on premise Active Directory. It’s centralized permission management so you can manage all the permissions of users within single sign on, and you get centralized auditing with cloud trail for the logins. So it’s awesome. So anytime you see a use case talking about doing a sign on to Multiple Events accounts or to business applications that require SAML 20, think single sign on. Okay, so here’s another graph.

So in the center we have single sign on, so SSO and we set up a connection to maybe our on Premise Active Directory. So we’ll have an Active Directory on premise, but we could also use managed services by AWS. So we can use Microsoft Managed ad by AWS to also manage our users from there. So we set up that trust and then single Sign on notes how to get the users from there. Then the users can connect to Single Sign on. And from Single sign on we can integrate it with different Ous and accounts within our organization. So once we’re logged into single sign on, we can access any organization accounts in here, but also we can access Business Cloud application to have deep integration with SSO such as Office 365, Dropbox and Slack.

Or we can even configure our own custom 2. 0 compliance application. And with these SAML applications we can enable it to work with SSO. So the idea is like we log in one with SSO, it checks our login with our on premise ad or our managed ad, and then we have access to AWS Business Cloud applications and custom SAML application. So it’s really cool, but I want you to notice exactly the difference between using SSO and using the Assume role with SAML API that I told you from before. So if you use Assume role with SAML, we have to set up our third party IDP login portal that will check our identity with the identity store that will return to us as SAML 20 assertion.

And then we have to send that SAML assertion to Sts to use the right Assumer with SAML, and we get back security credentials and we are connected to AWS, but so if you had multiple accounts on AWS, we need to set up this process for each and every single account. On top of it, we have to manage this login portal. And that’s not a thing that may be available in your company just yet, but with SSO, a browser interface will log in through the login portal of SSO.

So we don’t have to set up that login portal ourselves. This is the SSO service, and SSO is already integrated with your identity store. So we don’t have to run anything here. They just talk to each other, they generate credentials for you, and you get credentials back right away. So it’s one less piece of integration to do. But the really cool thing is that this SSO portal can give us credentials for one A list accounts, but also many others. So as soon as you want to scale with the number of multiple accounts you want to connect to, then SSO becomes an obvious choice. So let’s say for this lecture, and then let’s go quickly into the hands on to see how that works. But hopefully you get a better idea of what SSO is and how it’s used in your company.

10. [SAA] AWS Single Sign On (SSO) – Hands On

So this is going to be a short hands on because we can’t really set up SSO. We don’t have multiple accounts and so on, but let’s just go in the UI and see what it looks like. So let’s go to AWS single sign on and see the options we have for setting it up so it is loading and we can enable AWS SSO. These steps is a process that takes about 30 seconds, and once it’s enabled, we have three steps to do. The first is to choose our Identity Source, which is where we are going to administer our user and groups, and it’s going to be our Active Directory.

The second one is configure SSO to access all your AWS accounts that would be within your organization and then use SSO to access your cloud application or anything that is going to be SAML 20 compatible. And then the cool thing is I’m getting this user portal right here, which is given by SSO, and this is the portal I would have to log into, obviously once it’s being set up to log into there. So there will be my SSO portal. And once I’m logged in through the year, it would check my identity with the Identity Source, and then I would get SSO access to all the accounts and the cloud applications. So, very handy. Now to choose the Identity Source, we can have SSO itself as an Identity Source or Active Directory or an External Identity Provider, each with its own setup.

So we’ll choose SSO right now because it’s easier. Next, I can click on manage SSO access to our organizations and we have access to a bunch of accounts within my organization and I can say, okay, these will be the accounts I won’t want to access to. And finally, SSO access to our cloud applications. And we can add applications and there’s an either of a catalog of applications that already work with AWS SSO, or I can add a custom sample 20 application, in which case I would need to specify a bunch of properties to properly configure it. But overall, very, very handy.

It’s a free service of AWS and it saves you a lot of time and trouble. So if you manage your users through AWS SSO, you could add them through here as well as groups. But as I said before, SSO is a really good confetti debt when you want to integrate your source with another identity source. And for example, that would be Active Directory or an external IDP. All right, that’s it for this hands on. I just wanted to show you the different options. I hope you like this and I will see you in the next lecture.