Identity Federation Demos


Course Introduction
Course Conclusion
Start course

Please note: this course has now been replaced with Using AWS Identity Federation to Simplify Access at Scale, which can be found here.


AWS Identity Federation is the concept of using external authorization sources to permit access to AWS Console and AWS Resources. Identity Federation comes in multiple levels that enable the use of existing directories or SAML to ensure users are accredited and authenticated to access AWS.

Intended audience

  • AWS Administrators
  • Security Engineers
  • Security Architects


  • You should review the Identity and Access Management Course
  • Have an understanding of Enterprise Identity technology such as Active Directory, LDAP; and some Open Identity Providers such as Google, Facebook, Twitter, or Amazon.

Learning Objectives

  • Understand what is Identity Federation as it relates to AWS Console Access.
  • Demonstrate the ability to set up and use Cross-Account Roles
  • Demonstrate the ability to use Simple AD for IAM authorization with Cross Account Roles
  • Understand the concepts of SAML Determine how SAML could be used for AWS Console Authorization

This Course Includes

  • 45 minutes of high-definition video
  • Live demonstration on key course concepts

What You'll Learn

  • Course Intro: What to expect from this course
  • What is Identity Federation?: This lesson defines the purpose and uses of Identity Federation
  • Types of Identity Federation: In this lesson, we’ll discuss the different ways it is used within AWS
  • Identity Federation Demos: In this lesson, we’ll walk through how to setup both Cross Account Roles using IAM User ids and using Simple AD for Authentication with Cross Account Roles
  • Course Conclusion: A wrap-up and review of the course

In this section, I will show you how to set up both Cross Account Roles using IAM user IDs, and using Simple AD for authentication with Cross Account Roles. Now let's get into a few details for setting up Cross Account Roles. You will need two accounts, a Trusted Account, and a Trusting Account. IAM users in the Trusted Account, and IAM Policy that is attached to a Role in the Trusting Account.

For this demo, the AWS Account called CloudAcademy2, is the Trusted Account. This where you will login and are authenticated. The Trusting Account is my CCForce account where I run servers and resources for development and testing. I want to point out this early on that your Cross Account setup is saved in the browser, and in the browser cookies, I believe. I haven't been able to find any evidence to the sort, I just know if you remove your cookies that relate to AWS, you will lose your Cross Account settings.

Remember this as you switch between browsers in different computers that your Cross Account Role will not come with you.

Now let's get into the actual demo. For this demo, I'm already signed into both accounts. The Trusting Account CCForce on the left, and the Trusted Account, CloudAcademy2 on the right. For step one, we need to use the Trusting Account CCForce. First thing I need to do is navigate to the IAM service, and I need to create a Policy. Click here on Policies, click Create a Policy. You could use an existing AWS Managed Policy, you could Generate a Policy, or you can just simply create your own. For this demo, I'm just gonna say Create Our Own. We need to give the Policy a name, CA_Crossaccount_Demo. A description is always a good idea, so this is EC2, Describe access to us-east-1. Then we need to Create a Policy. Like I said, you can create any Policy you want. You can cut and paste a Policy in that you already have. You can use a Managed Policy with some modifications. I've got a Policy ready to go. It's in the transcript notes, so I'm just gonna cut and paste it here real quick.


  "Version": "2012-10-17",

  "Statement": [


      "Effect": "Allow",

      "Action": "ec2:Describe*",

      "Resource": "*"



      "Effect": "Allow",

      "Action": "elasticloadblancing:Describe*",

      "Resource": "*"



      "Effect": "Allow",

      "Action": [





      "Resource": "*"



      "Effect": "Allow",

      "Action": "autoscaling:Describe*",

      "Resource": "*"



      "Effect": "Deny",

      "Action": "*",

      "Resource": "*",

      "Condition": {

        "StringEquals": {

          "ec2:Region": "us-east-2"







This is just a simple EC2 described instance. Policy allows you to describe EC2 instances, load balancers, some cloud launch metrics, some auto scaling. Interestingly, I added this Deny statement. We'll get into that in a minute. Basically now you can Create a Policy. This creates a Policy, now you need to Create a Role. Click Create Roles over here, click Create New Role. Make sure you click Role for Cross Account access, and then click Select.

Next step is to enter the Trusted Account number. I just happen to know my number, so I'm just gonna cut and paste that in there. Jump to the next step. Now I want to attach a Policy. We just made our own Policy for this, so I'm gonna filter the list by saying, Customer Managed, and click this CA_Crossaccount_Demo Role Policy that we just created. Click the next step. We need to give it a Role Name. Again, CA_Crossaccount_Demo, and give it a description, Cloud Academy Cross Account Role, and click Create Role.

Now after this Role is created, you want to look at the summary, just to take a peek at it, so click This Role, click The Role, and now you've got some useful information here. This link right here is what the users are going to use to access this Cross Account Role. Now the next step, as you remember, is to do the work in the Trusted Account. Let's go over here to the Trusted Account, now we're already logged in. We're gonna just copy this link, go over here to the Trusted Account, easier just to open a new tab, hit Control + V, paste that in there, and look at that. We've got a Switch Role command. It gives us our account name, which is what we've alias in IAM, the Role, and we can Display Name this anything we want. CCForce is fine.

I usually change the colors. You can change it from the red, to the orange, something that means something to you, and click Switch Role. Now you see up here, we've got a little variance up here. That tells us we're in this other account Role. Now if we go to IAM, we're gonna get an error. We can't see anything.

Back to the home screen, type in EC2, press Enter. We can see if there's any instances in the Northern Virginia region. There's nothing there, so if we go back over here to the Trusting Account. Go to Services, go to EC2, we should see the same thing. Now let me do a real quick Launch Instance. It doesn't really matter. We're not gonna connect to it anyways, just gonna go quick here and launch an instance. All these default parameters are fine. It doesn't really matter, just Review and Launch, and Launch.

We don't even need a key pair 'cause we're not even gonna login to it. The point is to show you that we're gonna see a change. Here we go, we got an instance launching. We go back here to View Instances, see it's in a pending state. Come back over here to the Cross Account, Trusted Account, refresh the screen, we see the same exact thing. Now we've got both accounts. We can see both, and we can just be logged into our one account and see the other account. Now, let's go back over to the Trusting Account. Let's Switch Regions for example. We'll go to Ohio here, us-east-2. Launch another instance.

Again, just a simple test instance. We're not even gonna connect to it, do a Quick Review and Launch, Launch. Again, we don't need a key pair, we're not gonna login to it. We're gonna View Instances, we're just gonna look at it. We're gonna Launch and Instance now, in the Ohio region, us-east-2b.

We come over here to our Trusted Account, and I switch to the Ohio Region, I get this old warning, 'cause it's the first time going to it. An error fetching instance data. You are not authorized to perform this operation. Remember from our IAM Policy, we denied access to us-east-2 region. Now you can see that you can't see any of the data in us-east-2, and if you want to trust somebody to come in and look at your account, you can limit them to a particular region if you want, if that's how you're configured, if that's helpful. Always trying to keep the least privileged model in tact. All right, that's pretty much it for Cross Account Roles.

Now you can go off an create some Cross Account Roles of your own, and manage your multiple AWS Accounts from a single account. In this second demonstration, I'm going to expand upon the first by using using Simple AD to authenticate the user with the Console Access first, then using a Cross Account Role, view the EC2 instance status in the CCForce Trusting Account.

First I set up Simple AD in the CloudAcademy2 Trusted Account. I included a cloud formation template link in the slide that will set up a designated VPC with two public subnets, and two private subnets. The cloud formation template link is in the transcripts. This template can be accessed to create a VPC, and setup Simple AD if you want to try this on your own account. This is only part of it, and actually the easy part. In this demo, I am not going to create any users other than the administrator user that is created when the Simple AD is created.

I'm going to set up a few more items in Simple AD directory to enable Console Federation. Let's jump into the demo. Now for this demo, I'm starting in the CloudAcademy2 Trusted Account. From the Directory Services, I'm selecting the Simple AD directory that was built for this demo, so let's type in Directory Services, and you'll see here this is the directory that I created just for this demo. We're gonna click on this directory, and we'll see a nice summary page of what was created. The first thing I need to do is set up an Access URL.

For this demo, I'm gonna call it cafeddemo2, and I'm gonna Create the Access URL, and press continue there. Now we need to create access for the AWS Management Console. If you look down here in AWS apps & services, you'll see the AWS Management Console. We're going to Enable Access. Sometimes this occurs. An unexpected error has occurred, please try again.

We'll just refresh the screen, and see if it worked. Actually it did enable. Just wanna let you see that. It's happened a number of times. It can be a timeout between clicking the link, and Amazon activating it. Don't fret it too much, just click refresh on your browser, and you'll be good to go. Now if we click the link, and we click Continue, it'll take us over here to IAM Roles. We don't have any Roles created yet, so we need to create a Role.

Let's click here to Create a Role, which will launch the IAM Role screen. We'll Create a New Role. We wanna pick this one here AWS Directory Services. We're gonna click Select. For this demo, we're just gonna grab the Administrator Access and use that as a Managed Role. You could use any of these Managed Roles, or if you had a predefined Role and Policy already created, you could use that. Click Next. We need to give this Role a name, so we're gonna call it FederationLogin and we're gonna click Create Role. Now we have a Role created. Let's go back to the Directory tab, and refresh the screen again, one more time. Directory tab, and we'll refresh this, and we'll see we have a Federation Role. If we click that, it takes us to the next screen, and this Assigned Users and Groups, we need to add a user or group. Let's click Add. This is actually a link to our Simple AD. As you can see here, cloudacademylocaldomain.

We'll just type an a for Administrator, and it'll bring it right up. We'll click on that, and not it's linked in, and we'll click Add, and now our Administrator user is linked to having Federated login access. Let's go back here to Directories, the Simple AD link, and if we click this link here,, we're gonna get a login screen. Key in Administrator, we'll type in the password, and now we're logged on with the Federated login account. You can look up here, you can see it changed, but watch this. If we go back to IAM Role, we need to reload it, 'cause we're now logged in with the Federated Account. If you go over here to Directory Services, same thing, and we're now logged in as the Federated IAM user. This is only part of our objective here in this demo. We want to Cross Account Role with this Federated account as well, and we need to do that from CCForce Trusting Account. Let's switch over to the CCForce Trusting Account. From this account, we need to go get the Role that we used in IAM to set up the Cross Account Role and add it to the Federated user login screen. The easiest way to do that again is IAM, Roles, go to our Role that we created, copy this link, Control + C.

I'm gonna switch back over to our other account here. We're already logged in. Let's hit a new tab, paste in that link. It's gonna bring this back up, CCForcedevtest, Cross Account Demo, CCForce. Let's make it blue this time. Switch Role. Taking a minute to load, you see the CCForce up here, just like before. We got to EC2 Service. We're in Ohio. We're not authorized to see this region, switch over to Virginia, us-east-1, running Instance, click on that, so that we can see the Instance. Now remember we set up this Role, and we shouldn't be able to stop or terminate this Instance. Try to stop it, we get an error. Remember we only gave ourselves Describe.

Okay, that pretty much completes this demo for using Simple AD to Federate yourself to the AWS Console, and then you can still switch accounts, and do Cross Account Roles, even though you logged in with a Federated user. Now, a Cross Account Role security tip. As you may have noticed, anyone in the Trusted Account could use the link to gain access to the Trusting Account. This could make the Trusting Account admins a bit nervous. The to control who can access the Trusting Account, is to edit the trust relationship that is set in the Trusting Account.

You do this by updating the Principal element within the ARN of the user or users you want to allow access. Let's do this in the Trusting Account. Okay, from the CCForce Trusting Account, we need to navigate over to IAM. We need to select the Role that we used in the demo so that we can modify the Trust Relationship. Just click on the Role, click on Trust Relationship, Edit Trust Relationship. All we need to do is change this from arn:aws:iam:account number root to user/Tom, and then update the Trust Policy. This just gave it the ARN for just my ID in the other account. Let's switch over to the Trusted Account, and create the Cross Account Role again.

Now just click here on the user name, click Switch Role, click Switch Role again, type in the Console Alias, ccforcedevtest CA_Crossaccount_Demo, ccforce, and click Switch Role, and now we've gotten access to the Cross Account Role based on just this user ID Tom. Now you're saying this is the same as the last Role. How do we verify that this is exactly the way we want. We switch back over to the Trusted Account, there's a Trusting Account. We edit this relationship, and we put something different in here. Let's change the user from Tom to Bob and update the Trust Policy.

Now we need to switch back over to the Trusted Account, and let's check to see if we can get through on the switched Role. We still have it CCForce here, and when we click on it. Now you see we have an error, that tells us that only Bob can get in now, not Tom. We're having difficulty getting in. To confirm this, let's switch back over to the Trusting Account, Edit This Relationship, change Bob back to Tom. Update the Policy, switch back over to the Trusted Account, click Switch Role, and we have restored access again. As you can see, you can get security a little bit tighter on Cross Account Roles just to make sure that only the certain people that you want to allow to use Cross Account Roles can, and you can use a single Federated IAM user account to login all your users. That concludes the demo. Hope this was helpful, and you've gotten something useful out of this course.



About the Author

Tom an active AWS Consultant creating and deploying AWS solutions for over five years. He has worked on numerous projects that involve everything from small lean startups on a tight budget to massive commercial Enterprises that have large-scale budgets with large-scale requirements that must be met even no matter the cost. Tom has worked for several of our United States government agencies taking the agencies to the cloud by migrating solutions from on-premise data centers to the AWS cloud in a secure solution while reducing their overall cost to operate and maintain the solution.

Personally Tom spends his available time riding his bicycle, sampling a good wine or two, enjoying a good meal and watching Formula One races.