Amazon AWS Certified SysOps Administrator Associate – Identity Part 2

4. Identity Federation with SAML & Cognito

Okay, so let’s talk about identity federation. You may have heard identity federation many, many times in AWS, and to be honest, for me it was quite a cryptic topic, it’s really hard to understand. So I’m doing my best here to explain to you how entity federation works, what the SAML incognito, how it is integrated with all these things.

So let’s take it step by step and hopefully you’ll have a clearer view of it after this lecture. So federation means that we let users that are outside of AWS to assume temporary roles to access our AWS resources. What does that mean? That means that our users don’t need to have a user in AWS to access AWS. How does this dark magic works? Well, basically the users will assume an identity provided access role. So that’s a lot of information. Ready? Let’s go through a diagram to understand better how this works.

So we are a user and we’re in our company, or we are a mobile app user, whatever it is, we’re a user and we don’t have an account in AWS. But what we do have is access to third party servers for login. It could be our companies, it could be whatever. And this third party is trusted by AWS. So we have defined preempt beforehand a trust between the third party and AWS. What happens is that our users will connect to this third party and through some complicated process that we’ll see in a second, the third party will give back credentials that will be temporary to our AWS, to our user, to us.

Then as a user, what can we do with these credentials when we can directly access AWS through the console or the API? So this is how federation works, identity federation, that’s because the identity is stored somewhere else, it’s stored on a third party. If you understand this, you’ve basically understood identity federation. Now, identity federation, what is this third party authentication that we’re talking about? It could be LDAP, it could be Microsoft Active Directory, which is also assimilated to being Sam’l. Sam’s a standard. But Active Directory is an implementation of it. It could be single sign on, it could be OpenID, it could be cognito.

So all these things can be third party authentication. And so using federation, the thing you have to remember is that we don’t need to create individual IAM users. The user management is done outside of AWS. So for the exam, they may ask you about some very specific form of identity federation, namely SAML custom broker and cognito. So we’re going to see these three in details right now. The first one is SAML federation, and that’s for enterprises. Basically, if you’re a large enterprise, you most likely have a Microsoft Active Directory or you have something SAML 2. 0 compliance, where you already manage your users through this and you basically want to integrate this with AWS.

What this gives you is that now all your users ultimately have access to the alias console or the CLI through the temporary credentials. So you don’t need to create a new IAM users for each of your employees, which is quite nice. So how does it look like? This is a diagram. Now, this may be a very complicated diagram, it comes straight from the aidos documentation, but it is very clear. So let’s walk through it one step at a time to understand what happens. We are the client app and we are within our organization. So a large organization. What we’ll do is that we’ll go to the identity provider IDP, which is Sam’l compliance. So it could be Microsoft Active Directory and it will authenticate the user based on the user database. Then when we are authenticated to this IDP, the IDP will send back a SAML assertion. It’s basically a token, a sample assertion is basically a token.

Now we get some SAML assertion and what we’ll do is that automatically we’ll call assume role with SAML to Sts, which is a special API on Sts. And Sts recognizes this SAML assertion and we’ll give us back we’ll trade this SAML assertion for temporary security credentials. So now we’ve basically logged in, got a sample assertion, traded that SAML assertion from SDS to security credentials. And now with the security credentials we can for example access AWS just normally. For example an S three bucket that’s if you want to have a CLI based access, if you wanted to have a console based access, there is also a nice diagram by AWS. The idea is the exact same from our browser. We’ll access the portal of an identity provider. So it’s like a web based thing. We’ll get authenticated same thing.

Then the IDP will return a SAML assertion and now we can use that SAML assertion directly to sign in into the AWS SSO endpoints, which behind the scenes talks to SDS. And then once it’s all validated, once your SAML is traded for SDS, then we’ll validate the whole thing and you get redirected to the AWS management console right here. So the idea is the same, right? If you look again, we trade our identity internally for some AWS credentials and basically there is just a bunch of back and forth that happens. So if you understood this, then you understood SAML Federation. It’s actually not that complicated.

Now, if you don’t have assemble 2. 0 way of identifying your users, then you need to use custom identity broker. So that’s only if you don’t have assemble 2. 0 and that’s a bit more complicated. Basically you have to program what’s called an identity broker and it’s an application and you have to program it. And this identity broker must be used to determine the appropriate Im policy you apply. So what’s the change where here it is again. We have our users browser application, we’ll access our identity broker and the identity broker is something that we have to program.

Okay, this whole thing in the green dot green circle is something that we have to program and the identity broker will validate our identity with maybe a corporate identity store authenticated. And then if it’s happy, it has superpowers, it has super user superpowers. And you can ask from SDS any security credentials for any policy. So it’s up to the identity broker to really tailor a policy just for the user that was connected. So it’s a bit more work to do. And that’s why it’s called custom Identity Broker application. So we have to create this. It goes to Sts, makes a request for security credentials, the security credentials come back, they’re given to our users and then they can either access AWS with the APIs or get redirected to the AOS Management console and we can access AWS. So it is the exact same principles as SAML, but it’s not SAML. And therefore we have to do a lot more manual work. We have to do a lot more work to implement that identity broker.

So if you see custom identity broker, that means enterprises but not SAML 20. Whereas before if you see SAML 20, that means identity Federation directly integrated with AWS. And finally, this was for our corporate users. So anytime you are basically sitting at a desk at your corporation but what if you have an app and an app? Your users need to basically put files into an S three bucket. How do we do this? Do we create a user per app? No, that doesn’t sound scalable. Right? So the goal is to provide AWS resources access directly to our users of our app. How do we do this? Well, we log in through a Federated identity provider or we can remain anonymous. Then we get AWS credentials back from what’s called a Federated Identity pool and that comes straight from Cognito.

And then these credentials will come with predefined IAM policy that basically allow users to do what they need to do. Don’t worry, there’s a graph. So an example is anytime you want to provide temporary access to write to your S three buckets, maybe using a Facebook plugin, you should use AWS, Cognito and Federated Identity Polls. Note there is something in the documentation called Web Identity Federation. You may have heard of it before and it is an alternative to Cognito. But now in the documentation AWS recommends against it and it says you should just use Cognito because it does the exact same thing. So for this reason I’m not teaching Web Identity Federation because it’s not at the exam anymore. Cognito is going to be the way to have public applications access AWS resources now concurrently. How does that work? We have our app and our app is directly connected to our identity provider. It could be congrato user pool, Google, Facebook, Twitter, Sample, open ID, whatever you want, right?

But it’s an app on the wild, it’s public. So our app logs in to our identity provider and gets a token back from it. Then the app will talk to the Federated identity provider Incognito. And will basically trade in that token that will be verified by the identity provider. And then the identity provider will get credentials from Sts. And then same pattern as before, the identity, the Federated identity on Kunito will send us back temporary aus credentials. And now, using these credentials, we can directly talk to our s three buckets and make some calls and see if we’re authorized to do what we need to do. So that’s the idea here. The difference is that now we connect to public identity providers such as Cognito, user Pool, Google and Facebook.

But the idea is exactly the same. We trade in a token we retrieve from a third party to a service on AWS to get back some temporary AWS credentials. So if you understood this, you understood Federation. Take your time, review the graphs, look at the documentation, review this lecture. I promise it will make sense after a little bit, just write it down on a piece of paper. It’s quite hard sometimes to understand how these things are orchestrated. It takes a lot of time for me to get to understand this, but once you understand it, it makes total sense. And any question of the exam that talks about Federation, you will not be afraid of it. You will be embracing it and happy that you know the answer right away. So I hope you enjoyed this lecture. I will see you in the next.

5. [SAA] STS & Cross Account Access

Now let’s talk about a service that is in the backbone of all the other AWS services. This is SGS. And SGS stands for security Token Service. SGS, as the name indicates, allows you to grant limited and temporary access to AWS resources and they will issue a token and that token will be temporary valid up to 1 hour. So if you want to reuse that token, you must be refreshing and so the credentials must be reverified before you have a new token that allows you to access your database resources. So there’s a bunch of API and Sts, but one of the most important is going to be Assume role. So you can use the assume role within your own account for enhanced security. For example, you have your users assume a role that allows them to delete EC two instances. So the reason we do this is that we want to have an extra layer of security such as they don’t accidentally delete easy two instances, they just have to assume a role first to do that. Or you can use Assume role for cross account access and in that case we assume a role in a target account which is not our account.

And because we have assumed a role there, we can perform actions on the resources of that account. There’s also Assume role with SAML and we’ll have a detail at it when we look at identity federation but this will be helpful to return credentials when our users are federated through SAML. There is Assume role with Web Identity which is to return credentials for users that are going to be logged in through an identity provider such as Facebook login, Google Login or any OIDC compatible login. And it’s going to return those credentials but it recommends against using this.

And we’ll see this again in the hands on in the in the next lectures. And we have to use cognitiveo instead, that is the most recommended way. And finally there’s Get Session Token which is for multifactor authentication for a user or editors for count row user. So anytime your users have MFA, they have to use Get session token to get a token allowing them access to the console or to the CLI and stuff like this. So as we can see, Sts is really at the center of providing our users our applications tokens that allow them to talk to our AWS resources.

So let’s look at the most common use case for Sts, which is how to assume a role. So first we define an im role. It could be within your account or cross account and we’ll just have a look at it in this account. Then you define which principles can access this im role. So which users, which other roles can access this im role. And then you use the Sts service to retrieve connect roles and impersonate the im role. And this is using the assume role API as which I discussed. And then the creation credentials will be valid for between 15 minutes to 1 hour based on how you configure your assume role API. So we have a user and it wants to assume a role within the same or another account.

So it’s going to say, okay, I want to assume that role. So I’m going to use the assume role API. Okay? And invoke Sts. Sts is going to check with IAM. If we have the permissions to do so, then it will return us temporary credentials. And these credentials can be used to access that role in our account. So we can see the whole process. We first ask stuff from Sts which checks with Im returns us. Security credentials. And then we are able to assume that role and endorse it. This is very, very similar when you have cross account access.

So this is a low quality diagram from the website of AWS, but I think it’s clear enough. So we have a production account on the left hand side and a development account on the right hand side. As you can see, the first thing to do is that the admin will create a role in the production accounts. Then the admin in the development account will create a developer’s group with the permission to access this update app role. Then the user will request access to the role. Sts will return the role credentials. So now we have credentials to use that role in this account. And then the user using these new credentials can access, for example, an s three bucket in the other accounts. So this is the process for cross account access. And this is done using Sts.

So you never share credentials across accounts. You never ever do that. Like create a new user and then send the credentials. No. You create a role and you make sure that your user assume that role and sts will return to you. Role credentials are temporary. So even if you somehow lose them, then it’s not as bad as leaking entire credentials of an account. Okay? So remember, anytime in the exam, you see cross account access, you see assuming roles. SDS. Okay. Well, that’s it for Sts. I will see you in the next lecture for some more identity Federation.