Amazon AWS Certified Security Specialty – Domain 4 – Identity & Access Management part 9

23. Understanding Federation – Part 02

Hi everyone and welcome back to the second lecture of federation. So let’s go ahead and understand federation in more detail. So talking about a definition of federation, federation basically allows external identities to have a secure access in your AWS account without having to create any im users. So this, this is a very simple definition. Now when we speak about delegation, in the previous lecture we had the users which were present in the IAM and from IAM they used to do a zoom role to the second account. Now federation is little bit different where the users are not present even in the IAM, so they are present in the external entities. Something like an identity server like Ad or IPA that we discussed or even it can be a web identity provider which can be Facebook, Google, Amazon cognito or even open ID based compatible provider.

 So generally in many websites if you must have seen they have an option like sign in with Facebook, sign in with Google or sign in with say Twitter or LinkedIn. So that is basically a web identity provider federation. So you don’t really have to sign up that all you have to do is you sign in with your Gmail account and you will be logged into the website. So that is something like a federation in a very simple terms. Now let me actually show you that example because there is a very nice website I would say, which is security tube. So if I open security tube again a great thanks to Vivek Ram Chandran, he has done amazing work in field of open source based video education. So if you look into the security tube there is an option call as login with Google.

So once I log in with Google it actually asks me for the username and password. So once I log in with the username and password I will be logged into the website. So this is a very simple way of federation as far as the web identity provider is concerned. So this is what web identity provider and again the first option is adore IPA. So let’s understand on how federation works. So you have an active directory over here or you can consider as IP and there are a lot of users which are present over here. And on the second side you have Amazon web services. Now what you want is you want the user within your active directory to log in to your AWS. So what you need, you need is some kind of a middleman. So this middleman is called as the identity broker.

So identity broker is an intermediate service which connects multiple providers which can be in our case this is the identity provider active directory and this is the service provider AWS. So the identity broker will allow the user from the identity provider to log into the service provider. So this is what identity broker really means. So let’s understand the steps behind how exactly it will work. So you have an active directory, you have the users and you have the service provider which is AWS. So the very first thing the user will sign in to the identity broker page. So there will be some kind of a login form where the user will put the username and password. Now the identity broker will verify if the username and password is correct from the active directory. So the validation of the authentication will be done with the active directory.

So once the active directory says okay, the username and passwords are correct, then the identity broker will call the Sts service in the AWS. Now, Sts service will respond back with the authentication response which will contain the access key, secret key, the token and the duration. So those four things will be important for the user to connect. Now once the SPS will send the AR, which is the authentication response to the identity broker over here, identity broker will forward that response to the user and user will be able to sign in with those credentials to the AWS. So again, once the authentication response is received by the identity broker, user don’t have to put the username and password again, they will automatically be able to log in in the AWS account.

So again, this is a very simple step, let’s revise it again because this is extremely important in terms of exam. So first user enters the username and password to the identity broker. Identity broker will validate it from the active directory of elda. Once it is validated and authenticated, the identity broker will call the Sts service in the Amazon. Sts service will respond back with the authentication response and with that authentication response the user will be able to directly log into the AWS account. Now again, one important thing to remember over here is that there is a direct trust between the identity broker and AWS. So that trust relationship is already there between identity broker and AWS. So these are the steps that you need to remember.

So user logs in with the username and password. Credentials are given to the identity broker. Identity broker validates it against the Ad or LDAP. If credentials are valid, broker will contact the Sts token service from Amazon and Sts will share the four things which are access key, secret key, token and duration. And now user will be able to do various things with the help of these four authentication response that is received. So there are three important notation to remember. First is identities which are users. So the users can be part of LDAP or user can be part of Facebook or even Gmail or any open connect based provider. Second is identity broker which is the middleware or the middle person that takes the user from point A which can be LDAP and connect them to point B which can be AWS.

So that is the identity broker. And the third is identity stored. Identity Store is the place where users are stored. It can be Ad, it can be IP, it can be Facebook or any other providers. Now again learning on how to implement the identity. Broker or LTAP is out of the syllabus. However, if you really want to see on how this works, I will attach a video which will precisely explain on how this exactly process works in terms of practical session. So this is the basic about federation again I will really encourage you to remember all of these steps you should have all of these steps on back of your mind and in the notes section I will give you a reference to the video which will show you the practical demonstration on how this.

24. Understanding SAML for SSO

Hey everyone and welcome back. Now, continuing a journey with federation that we were discussing in the past few lectures. Today we will be speaking primarily about Samuel. Now, before we go ahead with the lecture, I just wanted to let you know that I am going through some dentist treatment and this is the reason why there are certain words which I might not be able to to pronounce very clearly. So just consider it for a few lectures. There were actually many of you who wanted to implement single sign on in your organization and this is the reason why I decided not to wait for two, three weeks for the treatment to get completed and actually go ahead and record videos. So let’s go ahead and understand what a SAML is.

So Sam’l stands for Security Assertion Markup Language. And it is based on XML. So it is a secure XML based communication mechanism for communicating identities across organizations. So by identities I mean users and passwords is something that you can consider. Now, SAML eliminates the need to maintain multiple authentication credentials such as passwords in multiple locations. And this is the scenario that we see in many of the organization where you have 56 application, a different, different application, and for each application you have separate username and password, which is a really big pain for the users to remember. And in order to effectively solve this problem, SAML was introduced. So let’s look into how it really works.

So what we have is we have an organization over here and within the organization there are certain users. Now, the username and password are stored in some kind of a directory like ad or LDAP based directory service. Now, the organization is using certain provider. Let’s assume this is a SaaS provider. Let’s assume this is AWS. Now, generally in a classic way, what really happens is whenever we create an AWS account, we create Im users. So what a user has to remember is that he has to first remember the password related to his laptop. That is the first thing. Second thing, he has to remember the password related to the SaaS provider, which is AWS. So first time the user’s passwords are stored in the active directory which is maintained by the organization.

Along with that, the same credentials, or maybe slightly different credentials for the same user will have to be stored in the SaaS provider database. Now, what really is happening is there is a reputation that is taking place and there are lot of issues in this kind of approach. So let’s go ahead and understand certain challenges with this kind of approach. The first is administrator does not have direct visibility with the underlying database of the SaaS provider. So since this database is managed by the SaaS provider in AWS, you remember we create an Im user, but the im user itself is stored in a database. So although AWS gives good visibility, there are a lot of other providers which does not give that good visibility. So this becomes a challenge for the administrator.

That is one point. The second point is if there are multiple SaaS provider it is difficult to keep track of which user has access to which SaaS application. And this is one of the very challenging things I still remember, because this is a real scenario where in one of my companies that I used to work with, when a user is leaving the organization, HR gives him some kind of a pamphlet, and he has to make sure that he gets the sign of the requested owner of the service. So we had around seven applications like Ad. You have IPA, you have kids, Confluence, HR, apps, servers, VPN, et cetera. And each of this application had different owners. So what user or what a developer had to do, he had to go to each owner and he had to get a sign of each owner saying that the user is cleared for leaving.

And this used to take a lot of time. It would be great if there was one single button which administrator would press and his users would be removed from all of these applications. And this is effectively called as a single sign on where there is only one page through which the user signs in and there is only one page where the user decision happens. So let’s understand the different views. When you talk about administrative use, similar to the challenge that we were speaking about, the classical way, the administrative view is that administrator has to log into different SaaS provider to manage and control permission of individual users. And in case the user forgets his username or password or reset of MFA is needed, then the administrator has to log into that SAS provider, he has to reset and it is a big pain.

So administrator is having a big pain. Let’s see about user. So in case of user, user has to remember username and password across all the application. So this is also a big pain for user and while leaving the organization, if you have to get a sign of the owner of the application, that is also big pain. So administrator is having a big pain, user is having a big pain and the third is SaaS provider. So in case of SaaS provider, the SaaS provider has to maintain the user and password database of the customer, which is a very very big liability. So in this case, you see this is a SaaS provider and he has to maintain the database where the user identity and passwords are stored. And if this gets leaked, then it is a big liability for a SaaS provider.

So administrator is not happy, user is not happy, SaaS provider is not happy. So let’s look into a solution where all of them can be happy is with the introduction of Samuel. So what really happens here is you have an organization where the users and passwords are stored. And this is called as the identity provider. So this is a provider which will give the identities, which means username and password. And second is the service provider. So service provider can be a SaaS application like AWS or Gmail or Salesforce etcd. Which is providing a service. So with the help of SAML, what really happens is there is a trust which gets established between an identity provider and a service provider. And effectively the users which are stored within this identity do not have to be replicated on the service provider side.

So let’s look into how that would really work. So we have an identity provider which is IDP and you have a service provider and this is a user. So what really user have to do is so user have to log in or to the identity provider. So this is some kind of a login page with the help of a username and password. The IDP, after authenticating that the username and passwords are correct, it will send a response back to the user with some kind of a token. Now what user wants to do, user wants to log into the service broader, let’s assume user wants to log into AWS. So in the Sam’l way, the user will not directly log in here. The user will log into the IDP with the username and password they authenticated. The IDP will send a token. Now the user will use this token as a post and send it to the service provider.

Now what the service provider will do, service provider will evaluate the token and if the token is proper, then the service provider will redirect to the management console. So this is a very simple approach. Let’s look into the practical session so this becomes much more clear. So when you talk about logging to AWS, there are two ways you can directly log into the service provider. By that I mean you can directly log into the SP or AWS, or you can follow the IDP approach. So in this lecture we will be following the IDP approach. So for our case we will be using JumpCloud. So JumpCloud is a great website which has LDAP as a service based approach.

So let’s do the practical so that we can understand on how that would work. Okay, so I think let me try from Google Chrome. Okay, so chrome works fast. Let me login okay, so this is the user login page. Let me log in with my test credentials. So this is something very similar to what we are speaking about. The user will log in to the identity provider. So this is the IDP and the user will log in over here. Perfect. So now what you’re seeing here is there are three applications which are connected. One is The Atlantic. Second is AWS and third is Google Suite. So now what I’ll do is I’ll click on AWS and let’s see on what happens. So I’ll click here, you see Sam’l is in the URL and what really happened was I got logged into the AWS management console.

So again, let’s revise, we authenticated against the IDP, IDP sent us the response to the token, we sent that token to the service provider in our case AWS and AWS gave us the management console. So this is the basic about how this would work. Now again, if I want to log into Atlantion, then again I’ll go to my JumpCloud and I’ll click on the Atlantian app and I’ll log in. If I want to log into Gmail, I’ll go to JumpCloud, I click on the Gmail app and I’ll be able to log in. So what is really happening here is that we are having just one credentials of the IDP and from that we are able to log into multiple providers or multiple service providers. So this is something called as a single sign on. So now you might ask where is SAML? So SAML is basically the token which you see over here.

The contents of the token is defined by SAML. So that is based on XML and we will be looking in detail related to the packet capture on what exactly this token means in the next lecture. So just to devise the flow just maximize this creek. The flow gets initiated when the user opens the IDP URL and enters the username and password IDP will validate your credentials and associated permission. And if correct, then the user will receive a SAML assertion which is basically a token as a part of response. Now, what a user will do, user will send a post of that SAML assertion to the SAS sign in page and the service provider will validate validate those assertion on validation. Once the token is proper, the SaaS provider will redirect user to the management.