How to Use Azure Active Directory with AWS SSO - AWS Online Tech Talks

hello thank you for joining us today I am Yuri the company solutions architect with a double yes and I have Lee ward with me today Lee or could you please introduce yourself yes thank you everyone for joining I'm Lee or Pollock a solution architects specializing in security and identity Thank You lore what we'll be talking about today today we will talk about the ways you can integrate your workforce identities with AWS while you are mentioning workforce identities what do you mean so companies typically have two types of identities to deal with the first one is employees and contractors who make up their workforce these workforce members need access to their AWS accounts and they may also need to gain access to diverse number of business applications companies use a workforce identity system such as octa or Azure ad for this purpose and today we will focus on this use case where we want to provide federated access to AWS accounts and business applications the other type of identities companies typically have is users of customer-facing applications such as users of a retail storefront AWS has solutions in this space such as Amazon kognito but we will keep this out of scope for this session today okay now what we understand the use case let's brief talk about AWS SSO sure URI enter vs. is so makes it easy to centrally manage access to multiple AWS accounts and business applications as well as provide users with a single sign-on access to all their assigned AWS accounts and applications from one place and now you can integrate and authenticate your existing identities from external identity providers or IDPs such as Azure Active Directory through the support of Federation with security assertion markup language or sam'l 2.0 standard you can also provision as your ID users and groups into AWS SSO automatically with the open standard of system for cross domain identity management or the latter makes it easier for you to grant access based on existing users and groups seamlessly integrating with multiple AWS accounts and provide your users the convenience of the signing experience they know with single click access to assign various accounts and applications sounds great so the question we addressing today is about AWS multi-count access and governments and about simplifying it for users and administrators using existing are your ADM deputies yes but before that let's take a step back and provide an overview of the mechanisms in place to control access to AWS accounts that would be great let's talk about I am with my pleasure so I am or Identity and Access Management is a very special AWS service 100% of AWS customers are using I am if you do anything on AWS even if you access from the web console you call an API endpoint and you're getting authenticated and authorized to call this this endpoint with I am the I in I am stands for identity the human or application calling the AWS endpoint we also call this the principal and the a.m. start a stands for access management a powerful flexible permission language for controlling access ok although we will focus on human workforce identity for most of this webinar we will touch briefly on how I am helps with human and machine identity either way several identity of authentication modules with I am first you can create individual I am users assign them to groups and attach permission policies well this is the simplest way to grant access there are some challenges right yes indeed there are two key challenges I'm users exist in a single account and you don't want all these unsynchronized separate identities second users will potentially be using long term credentials stored in their user or application environments and to avoid a security risk it will require additional measures to ensure users rotate their credentials periodically so what you imply while this is meant for workforce identity it's something used as a simple way to grant application access this is why we recommend that whenever possible applications calling AWS endpoints should use I'm roles and attach them to AWS services such as ec2 lambda and so on these I'm rows provide a temporary set of credentials which AWS manages for the application you can define how long these credentials are good for an AWS will rotate them before you before they expire customer applications can access these credentials most commonly by using the alias SDKs or CLI tools ok coming back to human identities you can also create I am roles that can be assumed by users this I am model is called I am Federation in this situation a company administers the workforce identities in an identity provider that supports the security assertion markup language standard also called sam'l or the Open ID Connect standard also called a YDC they use one of the standards to connect the de identities into an AWS account right correct and every time they log in they're getting what's called an IM session from that session they can assume a role the session operates within the access policies attached to that assumed role so what is the policy okay a policy is one of a key concepts of I am and it's been used to provide authorization we can say that there are two essential parts that take place with policies the first one is the I am administrator defines what actions are allowed or denied for resources in the policy the second one is on AWS to evaluate policies on each and every request to access these AWS resources when you define your access policies you attach them to a principle a principle is a user group or role in the policy then specifies which action the principle can perform on your AWS resources and under which conditions another type of policy that you need to understand is the trust policy of roles because roles are first assumed and only then can be used to access resources which are allowed in the access policies that we attach to them the trust policy is where you authorize who can ask who can assume that role let's see how policy is composed I am policies operate in what we call the park model principle who is doing the action this can be a user role or AWS service such as lambda or ec2 instance for example action what the principle is allowed or denied to do research on what resource the action can operate and condition when to allow and when to deny an action based on conditions and context when using identities from an nd8 identity provider through a WSI M Federation we first have to configure sam'l or or IDC Federation and then we need to create roles that trust the Federation provider in AWS accounts and I attached some access policies to the role we will see how that's done momentarily importantly when you use iron Federation AWS trusts whatever your external identity provider claims about your identities that is after the user signs into the identity provider the identity provider sends I am some assertions about the user I am looks at the assertions for information about which roles the user can assume the identity provider specifies which roles can be used by providing one or more Amazon resource names also called Arn for each role these irons are unique identifiers for these roles if a user has access to multiple roles the identity provider passes an Arn for each role when this happens I am prompts the user to choose the role they want to assume so the IDP needs to be aware of the roles in AWS accounts in order for identity administrators to be able to associate them with users and groups right correct that means that administrators have to implement some kind of role query against I am and configure that into their IDPs let's look at user experience for this scenario user can start from accessing AWS console and then will be redirected to the IDP this is called service provider or sp-initiated login because AWS console plays this service provider role here or user can start from the identity provider portal provide credentials there and then choose an application he's like - single sign-on in our case it's the AWS console application this is called IDP initiated single sign-on scenario in both cases the IDP provides an exception that contains information about user identity and rules this user can sign in with the service provider so let's see this in the demo for example what should the administrator to do to integrate an existing user ID directory with a brand new a SS account yeah what would be great let's do that we're starting from Azure Active Directory I already have some users and groups created here the next thing to do is to create an enterprise application I already have two accounts that I've set up in advance and now I need to create the third one I'm going to select new application and I'm going to search the gallery for the AWS application let's give it a meaningful name the user will see this name on the users portal when he's going to single sign-on today copyright correct and this is why we have to give a name that the user can identify next let's select setup single sign-on and sam'l I don't want to save settings yet and I'm going to edit basic sam'l configuration and modify the identifier the reason is that we already have two accounts set up and we need to give each and every one of them a different identifier so because this is the third account that I'm adding I'm just going to add hashtag 3 and save this configuration ok the next thing I need to do is to download the Federation metadata XML file and that is you we will upload this metadata for later to AWS I am when mobile configure is some identity provider yes in fact we're going to do this just now so I'm in my AWS account that I want to add to the Federation with I am and I'm going to the I am as a console and to identity providers I'm going to create a new provider and choose this provider type as sam'l I will give it a meaningful name like as your ID and upload the metadata file that I just downloaded and just finish the configuration created next I will create two roles and these roles will be used to assign users from Azure ID later on so I'm going to create a network administrator role and as support user role and one important thing to remember is that you have to select the type of the trusted entity to be your some of Federation provider I'm going to select sam'l 2.0 Federation and use a provider as as ready I'm going to allow both programmatic access and alias management console access and here I'm going to assign some policy to my rule I'm going to use the job function manage policy type and we are choosing AWS manage policies for this demo also customers may always create their own policies and customize permissions with the full power of AWS am correct I'm using the AWS job function policies because it's the easiest way to start it gives you sign defaults and you can customize them later I'm gonna skip that creation and give the role a name like support user role and create it next I'll create another role with the same configuration so sam'l 2.0 Federation same provider same settings just with a different name and policy here I'm going to use the network admin policy and create the next thing we need to do is to create a user that will give - as ready so it can pull the roles and then assign them to our users and this will be the read-only user correct yes we'll start by creating the policy let's see how we do this to minimize the access that this user will have so I'm going to select the service as I am and the action to be just list roles this will be the only action that will be permitted for this user let's review it and give it a name like list roles and create the policy now let's create the user and assign the policy I'm going to choose access type as programmatic access I'm going to attach the policy that I've just created [Music] now let's see how we set up provisioning in the azure ad side so I'm heading back to adder and selecting provisioning menu item and I'm going to change the mode of provisioning from manual to automatic next I will have to put in my user credentials in this dialog so I'm heading back to AWS I'll copy the access key ID and put it in the client secret box then I'm going to use my secret access key from AWS and put it in the secret token box in Azure and there is a little bit different terminology here between AWS I already yes this is something to remember next I'm going to test my connection and then I can click Save now once that set up we can go ahead and enable provisioning I'll click on and save the configuration again now my provisioning has started and I'll refresh to see if it finished already so I can see that I got two roles synchronized from AWS and my initial sync was completed now one thing to remember is that the initial sync is the is taking place almost immediately but follow-up sync will be done on intervals of 40 minutes so every change you make in AWS will only be synced here once every 40 minutes so while the roles may appear in here it may take a little while until they'll show and be available for assignment in the users and group menu let's all head over there and they add a new group assignment I'm going to take the groups that are already created let's take support users and assign the support user roles that we just synced from AWS I'm clicking assign and I'm going to repeat this also for the network admin group and we can assign more than one a table years of all to the users in groups in a row ready yes of course let's do that so we can see how it looks like later on I'm going to the group selection again I'm going to pick up the support users group and I'm going to assign this group with the network admin role as well I'm going to click assign okay so when this assignment completed let's look at the users experience let's open a new browser session and see how user signs in okay so I'm going to show you the IDP initiated flow and I'm going to go to my apps edit Microsoft comm signing in with one of my users and we're going to type in the password I don't want to stay sign in and we can see the already portal with the applications in AWS accounts assigned to the user right and as you can see this user already has assignments for AWS project a dev and project a prod from previous assignments and now they also have the new project be production account let's click it so because we assigned two roles for this user group now we get prompt by AWS role selection menu to choose which role we want to sign in with I'm going to select the support user role and click sign in as you can see we are signing to this account with the support user role with the identity from our IDP which is Jay Jenkins we go through a number of steps here and administrator has to do this for each namely new account and to keep managing changes for the account axis in both places AWS and already this probably can be automated correct yes customers may automate provisioning of new accounts but managing this configuration and changes may not be the easiest task here so what happens when our organization footprint is growing in new accounts in created for new business applications and workloads in large companies with more than 50 accounts they typically create automation to federate their identity provider to each account obtain enroll information assign roles to users in their identity provider and configure their identity provider to pass the role Arn - I am but this can be a challenge for companies with fewer accounts and less sophistication got it let's see how these smaller companies can address the multiple account scenarios for companies with fewer resources to build authorization automation you don't want to manually configure access control for each and every account instead we'd like to have a tool that allows us to manage large number of accounts efficiently and to be able to use the same identities to provision the axis from one single place yes a nativist single sign-on enables us to centrally manage access to AWS accounts and business applications as well you connect your existing corporate identities and simplify the process of enabling these identities to use your resources such as a diverse accounts also to business applications like Salesforce box and more so what do we need to know about using an AWS SSO hold that thought and let's talk a bit about AWS accounts and how we can manage them AWS accounts are isolated tenets in AWS they are shared nothing zero trust environments can customers organize they account for management purposes yes customers like to put them in some structure that makes sense - from a business or operational perspective to manage them efficiently to help with this a double is created AWS organizations with organizations you can group accounts for example by devtest broad environments or by applications or business units organizations also enable you to organize these accounts groups into a hierarchy of organizational units called use typically these are as a standard structure of grouped accounts for example you might set up organizational units to contain a development test and production account and then create a know you for each of your projects organizations also enables you to apply some policies that govern organizational units by using the hierarchy this makes it easy to assure compliance using the right guide res guide guardrails for these accounts for example you can specify that organizational units are not allowed to use specific services or products to help you standardize and reduce unwanted expenses a SS organizations enables you to do all this together with centrally creating accounts and forcing audit monitoring centrally managing cost and so on great so these can help us govern in our cows that federated users can access right that's right but it also provides a new and easier way to manage access across all your all your workforce identities while eliminating a lot of the complexity associated with iron Federation all right so on that note let's get back to AWS SSO to start with AWS SSO we need to decide what is the identity stored we will be using a SS SS own has its own identity store and you can provision users and their credentials there if you don't already already have a directory it also supports integration with AWS managed Active Directory or Microsoft ad on-premises the third option is to integrate it with an external identity provider such as our 3d which we'll focus on today the malicious is so integrates with AWS organizations and this allows us to manage all organizations accounts access from this single place incorporating all accounts in our organization and automate Federation and role configuration deployments seamlessly when we create a new account in the organization structure or we add an existing account to it it appears in AWS SSO management console and we can assign users to access it let's get some more details how the provision users access to AWS accounts sure AWS SSO has the concept of permission sets permission sets are templates for ion policies and they define access assigned to identities accessing to AWS resources and services in other words a SS SS ole automates the target account setup using these templates and its integration with AWS organizations which is very convenient indeed one last thing that I want to mention before we get into the demos is the ability to configure business applications in the user portal in addition to accessing AWS accounts you can configure cloud applications that support sam'l you can select from a large list of pre integrated applications or use the configuration wizard to configure your own custom sam'l application great let's see how we enable AWS SSO and prepare the basic setup file we're now logged into the console of our organization's master account let's go to the a single sign-on console and enable it with a single sign-on here and this is assuming that AWS organizations already enabled right if organizations is not enabled we'll get a prompt to enable it okay that was quite easy to enable a diversity so now let's look at the configuration for identity sources by default we have the a SS this is so internal provide selected we can change it to Active Directory and select a local manage Active Directory or AD connector but note that the directories that show up here are directories that are configured on the same region that we enabled eighth of a single sign-on on so make sure you enable it in the right region another option which we're going to show you later on today is configuring the external identity provided a simple process of exchanging metadata files let's set up some basic settings in our accounts in preparation for the next demo first let's create some permission sets and remember permission sets are actually in access policy templates that AWS SSO is going to provision in date correspond in AWS accounts right so we're going to use the same job function policy as we did before so we're going to select the support user and create a permission set from it and another one for the network administrator just like before later on when we're going to assign users we're going to select the accounts that show up here that are synchronized from our organizations and assign them to specific permission sets can you also have a look how to configure a business application with AWS SSO yes definitely let's go ahead and configure a new application I can either select an application that are pre-configured in the application catalog or create my own custom sam'l 2.0 application I'm going to configure Dropbox so I'm going to just select it from the list and to add the application and then I'm going to select the configuration instructions that will tell me how to configure my Dropbox setup this is very convenient because it goes step by step to configure the Dropbox application and it also populates the right field so I can just copy and paste them to Dropbox let's go to draw box I'm already logged on as an administrator on the settings pane for the single sign-on configuration I to copy from the guide identity provider sign-in URL and paste it in here next I'm going to copy the identity provider sign out URL and also paste it in the right location in Dropbox next I want to download my AWS single sign-on certificate and again pasting that or selecting that actually as my certificate for the Federation in relationship another thing I should do is to copy the CSS so sign-in URL so that my configuration will also support a service provider initiated login flow I'm going to copy that and go down into my application start URL and paste it back at Dropbox I'm going to enable single sign-on select optional and save the settings I'm also going to save the settings in analysis oh and my application is configured when I will configure my users and groups I can then later assign them in here now that we have seen the basic setup let's get to the final part of our talk today integrating with external identity provider as you remember in the very first demo we showed how to integrate as ready with I am and separately with each AWS account which in a multi account environment requires a lot of work or to create your own automation now let's see how we could simplify this process by using AWS SSO let's start from the administrator perspective in contrast to federating with I am directly federating is a one-time setup process with a SS SSO first we'll configure samo as before a simple exchange of the meta data files in place of pulling a list of roles to the IDP AWS SSO supports the open standard system for cross domain identity management or the scheme 2.0 protocol to propagate users groups and their metadata from Azure ad to AWS just to clarify here with scheme and sam'l users credentials stay in the identity providers directory right yes correct now once we have the users and groups in a diversity so identity store we can go on to assigns access to users to a diverse accounts and use permission sets as policy templates for the roles that will be automatically created in the corresponding accounts and it also creates an identity provider trusting a diversity so in in that account and configures the roles trust policy to trust a diversity so we can also go and assign other applications business applications to users so from a user experience perspective users sign in to the AWS portal and get redirected to the azure ad IDP for their authentication then when a user selects in AWS account and roll for a business or a business application ADA basis is so acts as a federation broker and connects the user to the selected resource good let's look how it actually works now sure thing we're going through the demo so now let's configure Federation between aw ssso and azure indeed first let's change the identity source or external identity provider meta data from a SS SS so and I'm going to move over to Azure Active Directory going to enterprise applications just like before and creating a new application or a devices so we're going to select the non gallantry application give it a descriptive name this name is not really critical because most of the time you won't see it because we're going to use the SB initiated flow provider mysticism so I'm going in to set up single sign-on and sam'l and the first thing I'm going to do is to upload the meta data file that I just got from a CC so let's edit and save next we need to download the Federation Cemil for majority and give it to a double single sign-on to create or to complete the metadata exchange we're going to back to a diversity so I'm taking the azure ad Federation metadata file and I'm going to finish the setup before I can complete the setup I need to acknowledge that I'm making a change that might affect my users because the existing users in my system are used to sign in with the aid of ssso credentials so I have to make sure that I'm aware of the changes that I'm going to make here that's confirmed so if I was using the internal it means as a sole identity store that those users will not be able to log in anymore right so when we make this change the metadata or the user context is retained when I changed from the internal data store to external identity provider but the authentication method is now based on Sam oh so this is what you're actually confirming here so paedo is SSO it's going to take care of everything in the background and now I can return to continue the setup so the next part of our configuration is to configure the automated provisioning using the scheme open standard this is going to work differently than what we had in the previous demo in this case as ER we use the scheme standard to connect to an endpoint provisioned by AWS and we'll write all the identities the users and groups and their metadata to the aid of ssso metadata store let's enable it so now I have the skin endpoint provision for me and also I have an access token let's see how we configure these in Azure so the next step in here is to go to the provisioning menu item and again just like before change the provisioning mode from manual to automatic let's move back to a SS SSO and copy the scheme endpoint we need to paste it in the tenant URL box and again we need to remember terminology differences here right I'll copy the access token and paste it in the secret token box and then test the connection now you can choose to all to add a notification email in case the provisioning synchronization process fails if you want to get notified but this time I want a configure this I'm just going to say ok next I want to configure mappings because the default set of mappings in the non-career application do not match what a device SSO expects so I'm going to select synchronize Azure Active Directory users to custom up SSO and this name here custom app SSO may differ in your setup depending on how you set your directory to do is first to remove some of the you know configured attributes and as you can see here we've got three phone numbers we only need one and I'm going to remove the mobile number and also the fax email telephone number another change we want to make here is to change the external ID mapping and change from male nickname to object ID because male nickname doesn't create a unique or that is not necessarily a unique attribute so we're changing it to object ID and confirming another change you might want to do is to change the way that male attribute maps to the email that a SS SSO will get and if your users are in a provisioned with office 365 accounts then you don't really have to do this change but because in my account I don't have any email setup for my users I want to still relay the email attribute for each and every one of my users and I'm going to use the user principal name source attribute for that again in your environment you might not want to do this change so AWS SSO needs a unique I think if R for the user and an email address to make provision and working to scheme right right right it's mostly important if you have business applications that you want to use because these business applications are looking for the email field in order to map the users understood but unique ID we need anyway yes okay I'm going to save this okay now before I'm going to enable the provisioning I also need to assign some users and groups to my enterprise application so I'm going to users and groups and I'll click add user and be either a user or a group and I'm going to select a couple of groups here project a would it be just select them at this time we don't need to assign any roles here because users metadata will be pushed to AWS SSO and then we will be assigning permissions sets on the AWS so side instead correct so I have assigned my groups here and now the next step and the final step in AWS since are in edger would be to enable provisioning from now on whenever I want to make any any new assignments I can just go to a divan sucesso and make the assignments there so I'm clicking provisioning status to on so before that I want to talk to you about the scope here so by default as your ad only synchronizes users and groups that are assigned to this enterprise application you can change this behavior and select sync all users and groups and then even users that are not users and groups that are not assigned here will also get synchronized I'm going to leave it at default and click Save great so this is going to take a moment I'll refresh okay as we can see we've got our groups and users synced to AWS again just like with iron Federation this provisioning happens immediately on the initial sync but then every 40 minutes it gets synced again the Delta is getting synced again to AWS in this case you can also manually set the synchronization state and restart it if you click this checkbox and save it but now I don't need to do this so I'm going back to AWS and let's see if our users and groups are already synchronized great as you can see we have our users and our groups if I click one of the users I can see that apart from the username that was synced from pager we see attributes like the first name the last name and others and we can see that this metadata been provisioned by skin corrector II we can also check other attributes that are in the directory like the user department let's assign some of our groups to AWS accounts so I will now choose a couple of a diverse accounts let's say project a prod and project a dev and assign the support user group to have access to these accounts next we're going to choose the permission set so I want to have a permission set for a support user and began permission sets will be used by AWS SSO to create roles and policies on the corresponding AWS accounts so now AWS SSO goes to those AWS accounts and creates an identity provider for itself there and also creates roles with policies according to the permissions temples that's right now that we have access setup to our accounts let's also assign some business applications so I'm going into my Dropbox application that we configured earlier and I'm going to assign the same group for support users to get access to draw box also so when all this is ready and all assignment is complete can be jumped to degree users experience yes definitely we have to copy the user portal URL and hand it to our users we can also customize this URL so that it will have a familiar name that user recognizes I'm going to use the default let's move in to a new browser and paste this URL we will now be taken to authenticate with our Azure ID identity provider let's use jeido and that were authenticated we're getting to the end of ssso portal and we can see the accounts and business applications that you just assigned to the users groups correct so if I'm going to project a dev for example I can see that I have the permission set for support users provisioned for me I'm going to click the management console and single sign-on into this account let's quickly see the I am configuration on this account what did AWS is so provisioned for us there yes of course let's go into the i''m console and see that identity provider first so as you see I have a new identity provider here that was automatically created by the others SSO I also have the role configured for me based on the template of the permission set and we can see the support to use a role here right can you also have a look how user logs into the business application via AWS SSO yes of course so I'm going to click the drop box business application and I'm going to be redirected now to my Dropbox account I'm going to confirm that I want to single sign-on for Jade and now I'm logged on as Jane Doe to the Dropbox business application and this could be any application either one of the applications in the list or any custom summon application amazing and Jane Doe carries identity that actually the source for this identity is already metadata being provisioned in India so and then we single sign-on using this identity to the business application this is great for human accessing AWS resources via the console let's have a look at a new AWS CLI feature for AWS SSO yes with the new AWS CLI version 2 you can get temporary credentials for accessing your a device accounts and resources from the command line let's try it so for this final demo we're going to show you how to use AWS CLI version 2 to integrate with a double a single sign-on so I'm going to type in AWS 2 for CLI version to configure SSO and the first thing it's going to ask me is to paste the SSO start URL if you remember we use this URL to access the SSO portal previously so I'm going to paste it here and make sure you paste the entire URL including the slash start at the end otherwise this won't work the next thing I have to specify is the region where a device SSO is enabled I'm going to select yours East one the next thing that is going to happen after I'm going to press Enter is that a to vs. is so we'll open a browser window and take me to the IDP to sign in let's do that I'm going to sign in with my user Jane Doe and I'm going to be directed back with my sam'l assertion to single sign-on and to authorize the ED over CLI session I'm going to click that and now back in my AWS CLI I can see that I have the role selection menu where I can pick the role and account combination it will allow me to create a CLI profile for that specific area I need to specify the default region for this profile basically the same as you would have set up for a regular credential configuration setup I'm gonna use a usest one here as well and IDO a CLI will create a new profile for me with the prefix of the role name and the suffix of the account number and I can use this profile to specify which permission set I want to use when I will log in to Ed of ssso now so the next thing I want to do is to use AWS a SLA version 2 with this edibles profile so let's see a call the STS endpoint and get our identity and I'm going to copy that profile name and paste it over here as you can see I'm logged in or assumed with the role that ADA basis is so created for me and the identity comes from the ADP this is great also you use the browser to provide your credentials for as your ID and to authorize the accession what happens if you are in the environment where a browser is not available when you log in AWS CLI generates a one-time token which you can manually enter with a browser in a different environment and register that session also great feature so I can type it for example in my laptop into authorize my session that way so let's recap at the beginning we filled how to integrate an external identity provider such as authority with AWS a.m. for each every AWS account as far as you could see it may become quite difficult to manage access control to these accounts and it requires to ride automation when your big organization grows interval is sso natively integrates with AWS organizations and helps address in this challenge it allows the provision and manage access to your accounts and business applications from one single place for both AWS console and AWS CLI while a double ssso supports its local identity store and integrates with Microsoft Active Directory either a double is managed or on Prem it now also integrates with and external identity provider such as already we have demonstrated how this enables you to keep managing existing users identities and provide access to AWS accounts and business applications within minimal configurations on AWS side that is done at one single place all these using industry standard protocols like sam'l and skin to learn more about what we discussed today please check these links it's been a great session Thank You Lior we have some time left so let's take some questions