Amazon AWS Certified Security Specialty – Domain 4 – Identity & Access Management part 10
- 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 with 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 the 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 as 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 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 center 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 this 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 happens. 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.
- Establishing trust between IdP and SP
Hey everyone and welcome back. Now in the earlier lecture we looked, we had a high level overview into how this single signon would really work with the help of SAML. Now before this process actually starts, if you will see in the earlier slide, in the previous slide there was a trust relationship which was was established between an identity provider and a service provider. And this is very much mandatory. And if you don’t really have this, then this will not really work. So let’s go ahead and understand on how the trust relationship really works. So in a very high level overview, how we can establish a relationship is that from the identity provider we create a document, we create a sampled document and that document we upload it into the service provider. Similarly, on the service provider side there is a document which is generated, we take that document and we import it into the identity provider side and this is how the trust relationship works.
So as far as AWS is concerned, Amazon provides that document on this specific URL which is sign in AWS, Amazon. com, static Sam and metadata XML. So this is that XML document which needs to be imported on the identity provider side. Now, when we look into the contents of the document, this again is a SAML based document and it is based on XML. So one of the very important field is the certificate. So you will see it contains an x 50 nine certificate and this is the certificate contains this is super important. The certificate basically contains lot of information related to the organization, the email address and the most important is the public key of the provider of a service provider. This is one important thing. The next important thing is the attributes section.
So if you see there are a lot of attributes which are present among which the first two are particular interest to us. And if you look into this attribute value there is required is true in the second attribute also is required is equal to true. And if you look into the attribute name it is attribute slash role and the second starts with attributes role listening. So these are the two attributes which are mandatory in the IDP site because if we are importing this metadata XML in the identity provider, then in the IDP we also have to specify the value associated with both of these attributes. And this is the reason why when I go into the jump cloud so this is the administrator page. So if I open up the AWS, you see there are two constant attributes which are present.
One is the role session name and second is the attribute role and they correspond to the attribute role and the role session name. So this is very important to remember. If you do not have the attribute, chances are that things will not work very properly. Anyways. As far as the identity providers are concerned, like JumpCloud or Octa. Whenever you create the AWS application, the metadata XML is automatically imported. So you don’t really have to manually import it. So let’s look into how we can do that. So I’ll just delete the created one. So in order to create an application, just click on the plus sign. So there are a lot of applications through which we can establish SSO. We’ll select Amazon Web Services and I click on Configure.
So if you will see over here, it automatically gave us the two attributes which are mandatory in the XML file. So JumpCloud automatically imported this metadata XML from the AWS and it gave us the attributes as well. Now there are two important things which we have to remember in the metadata XML. If you will see there is a certificate file. So when we look into the slide as far as JumpCloud or Octave concern, they automatically import this specific metadata XML file. However, we also have to generate a metadata XML of the identity provider. And in order to do that, we need a certificate. And this is the reason why creating a certificate is the first and the foremost thing that we have to do before we can generate the metadata exam of the IDP.
So let’s go to our favorite Linux box and we’ll generate a certificate. So there are two commands which are important. First is we generate a private key and second is we generate a certificate from the private key. So quite simple, let me open up the terminal, I’ll maximize the screen, I’ll copy the first command which generates the private key. I’ll paste it here. So this is a private key, you see private key or generator. And second is a certificate. So we will be creating a certificate from this specific private key. So it will ask me for various information like country name, state, locality, I’ll say Mumbai organization name will be KP. Labs unit would be training commony Kplabs in email address highness t. How do you see it? Perfect.
So now if you see we have a private key generated and we have a certificate generated. So now let me just refresh the page. Okay, so let’s do one thing. Let’s create the application from here again, because this is a Linux box. So we’ll upload the certificate, we’ll put a cert PN and then we’ll upload the private key. Perfect. So now we have uploaded both of them, we’ll have to give a label. I’ll say Kplabs would be our label and I’ll click on Activate. So now what has really happened is that the application is created and now we have to import the metadata of my IDP to the AWS side.
So in order to do that, I’ll just quickly log, login to the address management console. Okay, I’ll give the username, user have the password, let me just and it will ask me for the ODP. In order to get the ODP, I’ll just copy the ODP 24 let it go 532180 perfect. So I’ll just copy it 532180 perfect. So I’m signed in. So now what we have to do is that we have to upload the metadata of my IDP to the SaaS application or to the service provider in our case, since it is AWS. In order to do that, I’ll go to IAM and here if you see there is a section called Identity Provider.So I’ll click here and we had already one which was created which we had done a demo for. I’ll click on new Create Provider. So in the provider type there are two of them, one is SAML and second is Open ID.
For our case we’ll use SAML. So provider name would be Jumpclouddemo. Now you see it is asking for the metadata document. So what I’ll do here, I’ll click on Export metadata and I’ll save this metadata XML file. So if you just open the metadata XML file, let me do one thing, I’ll copy this and I’ll paste it in an XML formatter. So there are a lot of formatters which are available which will format your XML files. Perfect. So it has formatted and one very important thing that you will see over here is the certificate. So this is the certificate which we need and this contains the public key associated with the private key that we had generated. So what we’ll do, we’ll upload this specific metadata XML which is a sample based document.
So I’ll go to downloads and upload the metadata examine perfect okay and I click on Create perfect. So we have Identity provider which got created. Let me just cancel this as well. Now, one important thing that I wanted to show you in the metadata XML is the URL of the IDP provider. So if you will see over here it contains the URL of the IDP provider. This is important because the service provider should also know the URL of the IDP provider because we are establishing a trust. Perfect. So now that we have created the identity provider, the next thing we have to do is we have to create a role. I’ll click on Create Role. Now there are various types of role which are there for our case it would be SAML 20 Federation. SAML provider will be the JumpCloud demo.
I’ll click on Next policy, let me give easy to read only the role name would be SSO demo and I’ll click on Create role perfect. So the role is created if I go to SSO demo. If you look into the trust relationship, you see the ARN is of the JumpCloud demo identity provider that we had created. Perfect. So now what we have to do is we have to take the role ARN and we have to paste it in the IDP site. So let’s do one thing since the graphic might not be that good, I’ll log into my windows box only and we can continue our section here. I think the graphic looks much more better. So I’ll just log into Management Console. Okay, so going back to the role that we had created, which was SSO Demo.
If you go here, let me refresh the page. The reason why we went to the Linux box was to generate the OpenSSL private keyn certificate. Okay? So now what we have to do is there are two attributes which are present over here and we have to fill in the details related to both of these attributes. So let’s do one thing. I’ll copy this and I’ll paste it over here. So there are a few important things here. One is the account number. So I have to get the account number. I’ll take the account number from here and I’ll paste it. And the second is the role name. In our case, the role name is SSO Demo. So I’ll paste it. SSO Demo. So this is the first aspect. The second aspect as well. We have to do the same thing. I’ll copy the account number.
Let me just, let me do it once more. And the next is JumpCloud. Let’s just verify this is Jumpcloudem. So I’ll just paste it over here. Perfect. So now I’ll copy this and I’ll paste it over here. The name I can say Kplabs for the time being. And I’ll click on save. Perfect. So hopefully everything is configured properly. So now what we have to do is we have to log in as a normal user and we’ll try and access this specific AWS application. So I’ll open up the ignitor window and I’ll click on jumpcloud. com. So this time we’ll log in as a normal user and we’ll see on how exactly that would work. So I’ll click on login. Perfect. So now we’ll click on Kblabs. Okay, so the authenticated user is not authorized for the service provider.
Okay? So the reason why this is happening is because there is one caveat in JumpCloud. What you have to do is if you look into the slide, we had this point that IDP will validate the credentials and associated permissions. So the reason why we are getting this error is because the credentials are proper, but the associated permissions are not assigned to the specific user. So in order to do that, what you have to do is you have to create a group. So I’ll create a group. Just name this group, the same name that you had given to your application. In our case, it was creepy labs. So this is the thing which is specific to JumpCloud. So this is one important thing to remember.
The user will be test application all the applications, okay? And I’ll click on save group. So this is one important step that you have to remember if you’re using JumpCloud. So now let me go back. And now if I click on KP Labs, hopefully it should work somehow. It is not working. Let’s just verify once more users test, I’ll just select Amazon. I think this is a bug with JumpCloud. Okay, let me try once more. And this time it should hopefully work. Perfect. So now, if you will see, we are logged into AWS perfectly. So this is the basic on how we can configure a trust between IDP and a service provider. So I hope this has been useful for you. Quite a long lecture, but this is something which is important to practice. Thanks for watching.