SAP-C02 Amazon AWS Certified Solutions Architect Professional – New Domain 5 – Continuous Improvement for Existing Solutions part 6

16. 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, Samuel 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 users will have to be stored in the SaaS providers database.

Now, what really is happening is there is a reputation that is taking place and there are a 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 deletion 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 a 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 SAML.

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 etc. Which is providing a service. So with the help of Samuel, 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 SAML 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 a 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 the 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 Endap as a service based approach. So let’s do the practical so that we can understand on how that would work. 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 into 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 SAML 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 in to Atlanta, 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 in to 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 details related to the packet capture on what exactly this token means in the next lecture.

So just to device the flow, I’ll just maximize this screen the flow gets initiated when the user opens the IDP URL and enters a username and password IDP will validate the 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 signin page and the service provider will validate those assertions on valuation. Once the token is proper, the SAS provider will redirect user to the management consultant. So this is the basic about SAML. Again, we will be speaking in more detail related to it in the upcoming lecture.

17. Capturing SAML assertion packets with Tracer

Hey everyone and welcome back. Now in the early lecture we saw that we logged into JumpCloud, we clicked on the AWS icon and we were automatically logged into the AWS management console. Now the question is how? We also discussed the entire flow related to how a single sign on which SAML would really work. However, we did not really look into the packet trace on how that would really look like. So in today’s lecture we’ll go in more depth and the points that we had discussed in the earlier lecture, we will be looking into the packet trace related to each of these points that we had discussed. Now, in my different browser I have my jumploud login. If you see on the applications, I have three applications connected over here.

So in our case for our demo purposes, we’ll be using AWS. Now, we already know once I click in I will be automatically logged into the AWS account. So, going back again to the flow page, because these points are very important to remember. So when we look into the second point, once IDP validates the credentials and associated permission, then the user receives a sample assertion from the IDP as part of a response. So once the user is able to log in with a correct username and password, and if the permission associated with the user are correct, then IDP will give a SAML assertion or you can say as a token. Now, user will use this token and it will send a post request to the service provider. In our case, since we are clicking on AWS, it would be AWS service provider will validate this SAML assertion.

And if it is valid, then the service provider will redirect users to the management console. So, let’s look into the flow. Now, there is a very nice tool called the SAML tracer. So this is something that I would really recommend you to go ahead and insert. So let me do one thing, let me open up this link. So this is just the hyperlink. So I just right click and click on copy link location and you see the location is ssosaml two AWS. So I just clear the SAML tracer and let me just enter. Now, what really happened is the browser has received the token, browser has sent a token to the AWS, AWS validated the token and I am logged in. So let’s look the same thing with the help of Stamina tracer. So if you remember, I had clicked on this specific URL. So this is the URL for which I had pressed Enter.

Now the second request, here is the post request. We already discussed this in the slide where once IDP will validate it, it will send the user the SAML assertion as a part of response and user will do a post of that sample assertion to the SAS sign in page. So what that means is as soon as the browser receives that sample, token, it will use that token and it will send it to the SAS sign in page. In our case it would be the AWS sign in page. So this is the post request. So what really has happened is this is the browser. You see the user agent is Mozilla. So what Mozilla is doing is Mozilla is logging in to sign in AWS Amazon. com. You see the SAML. So this is the URL to which the browser is going to and browser has a sample response over here. So you see over here it is a sampled response. So this is based on XML.

So what a browser is doing is browser is taking the sample response which it received from the IDP and it is sending that Sam’l response to the SaaS application, which is AWS in our case. Okay. So if you will see over here it is sending it to the Aws. com. Now AWS will validate whether the salmon token is correct or not. If it is correct, then AWS has sent a 30 two response, which basically means redirect. And within the response it has a doubles has given the location. So you see this is the location. And what this basically means is a debris is saying to the browser that this is the location, just go to this location and automatically you will be logged into the AWS management console. So now what a browser will do, browser will take the specific location. Remember, just look into the HCG.

So browser will take this location and the next request it will send a Get request to the specific location. So you see, HCG is ending now, browser is taking this location and it will send a Get request and this is where the AWS console will be logged in. So let me do one thing, I’ll copy this specific link and I’ll paste it in the new tab and let’s see on what really happened. So as soon as I pasted the link, you see I got logged into the AWS. So this is the basic on how it really works. I hope you understood the flow and I hope you understood the last slide that we were discussing about. Remember, this is very important for you to understand both in terms of exam as well in terms of how a sample would really work for. So this is yet another lecture for sale and federation. We will be continuing the series and will understand in more depth in the next lecture. So I hope this has been informative for you and I look forward to seeing you in the next lecture.