SAP-C02 Amazon AWS Certified Solutions Architect Professional – New Domain 5 – Continuous Improvement for Existing Solutions part 7
- Establishing trust between IdP and SP
Hey everyone and welcome back. Now in the earlier lecture we look we had a high level overview into how this single signon would really work with the help of Samuel. Now before this process actually starts, if you see in the earliest slide, in the previous slide there was a trust relationship which was is 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 site 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 Samlhanmeta 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 session name. 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 slash 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 or 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 XML 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 got 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 common name kplabs in email address highness t how do you see it here? Perfect.
So now if you see we have our 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 into the address management console. Okay, I’ll give the username, you have the password, let me just and ask me for the ODP. In order to get the ODP, I’ll just copy the ODP let it go 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 do, we’ll upload this specific metadata XML which is a sample based document. So I’ll go to downloads and upload the metadata exam 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 arc is it would be SAML 2. 0 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 Ern is of the jumploud 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. So this 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.
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 Kplapse 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 Kplabs. 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 Jump club. 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 dead. 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 dump cloud. 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. 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 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.
- Choosing a right IdP
Hey everyone and welcome to the KP Labs again. Now, in today we’ll look into how we can select a right identity provider for our environment. Now, we have already seen that for a SSO to happen, we need two things we need the IDP and we need a service provider. Service Provider we are already logged in as AWS, so this is something that we cannot change. However, when we talk about IDP, there are a lot of IDPs that we can choose from. Although it looks one in a practice. There are two applications which are generally used as far as Windows is concerned. The first application would be the ad or active directory. So this is where the username and passwords will be stored.
That is one thing. And the second thing would be the IDP or an identity provider and that would be ADFS, which is Active Directory Federation service. So you have to install both Ad and ADFS for the complete identity provider to happen. So that is one way. Now, second ways online there are various providers which will help you achieve this. Like Okta is one of the very famous one. However, we have been using JumpCloud. So if you will see, JumpCloud is offering Directory as a service, so it has an Active Directory and LDAP. So JumpCloud also has Active Directory where the users and password will be stored and it also consists of the identity provider. Now, the reason why we selected JumpCloud for our demo is because of the pricing section.
So if you will see there are multiple plans over here. The first plan which is free forever is free up to ten users. And the best part is you don’t really have to pay. Like for Octa there is a trial for one month and after one month you will have to pay. In Jump Club you don’t really have to pay till the time you are within this specific limit. So we can use this for our personal testing for any amount of time that we need. So this is the reason why I selected Jump Club. Now, in order to go with Jump Club, what you have to do, you have to put in the email address. Now, one caveat here is that you cannot put the Gmail address. You have to put some personal email address.
Like for me, I had put instructors in, okay? So something similar to this, it will not accept generic email address like Gmail or Yahoo. And this is the reason why I always encourage every one of you that you should have some kind of a domain through which you can generate a private email address. Because for many of the corporate applications, they will only accept the company email address and they will not accept the Gmail based address. Okay? This is one important thing to remember. So if you do not have, I would really encourage you go ahead and create the domain name. This cost around two to $3 if you go through a coupon. So quite inexpensive and I will really encourage you to get your own domain so that you can sign up for JumpCloud.
Now, once you sign up for JumpCloud, what you have to do is you have to log in. So there are two types of logins which are available. You see one is the admin login and second is the user login. So admin login is where we can configure the applications like AWS or other applications through which the users will be able to do a single sign on. So in our case I have two users, one is instructors at the rate Kblabs in and second is test at the rate Kblabs in. So instructors is the admin login and test is the user login. So if I show you the interface, this is the administrator login over here. So if you go to the applications, this is where you can configure your own application. So if I just click on the plus sign you see there are list of applications, around 138 applications that we can configure as a part of single sign on.
So quite a lot of them. So depending on what applications that your organization is using, you can go ahead and add them in this specific list. So this is one aspect. The second aspect is that if you want to implement the SSO you have to go ahead and create a user. Creating user is quite simple, you just have to give the username the first name, last name, username and the email and just click on save user. So this is a very simple way of doing this. So this is the basic about JumpCloud. So as we already discussed, Jump club provides both the identity store as well as the identity provider. So both of them are part of the single JumpCloud based console. So this is it about this lecture, go ahead and sign up for JumpCloud. Something that I would really encourage so that you can do the practical session related to the federation. Thanks for watching.