Prerequisites

• Your AWS Organization

The Lesson

I have some good news and some bad news. The good news is we get to learn more about IAM today. The bad news is we get to learn more about IAM today!

If you’ve been in security for a while, you probably spent a lot of time learning about networking and operating systems. That’s what IAM is to cloud: the single most important foundational security control. I know I’ve said why before, but I can’t repeat it enough…

I’ll get into the governance bit later, but in public cloud we administer everything over the Internet using standard APIs and web interfaces. That’s why identity is the new perimeter of cloud: full admin access is only a username, password, or token away.

Up to this point we’ve done all our work using IAM constructs within AWS. In the real world that isn’t manageable or scalable. If you have hundreds or thousands of employees (or more) and a large rogue’s gallery of cloud services, it simply isn’t possible to have multiple identity stores. We dumped that idea a long time ago, and even in datacenters moved to federation.

Federation 101

We have previously talked about authentication (AuthN, proving who you are) and authorization (AuthZ, permission to do something). In federation we split these across different systems/platforms:

• Identity Provider (IdP): This is where you log in. The identity provider is the home of the user pool or directory where you set up user accounts, groups, etc. We sometimes call this the authoritative source because it’s the ultimate decider of who you are and your groups & roles.

• Relying Party: This is where you do things. The relying party… relies… on the IdP for authentication, so it can focus on authorization.

Federation is the primary way we get Single Sign On (SSO), where users only need one set of credentials to access multiple things. The administrators on both sides set up a trust relationship between the IdP and the relying party. It uses a lot of fancy cryptography. You only need to log in once, and then you can access all those other services. If you log into a portal at work and then click into different cloud services, that’s federation. If you log into Active Directory and then connect to a file share to snag a document, that’s also federation.

In the cloud it’s all based on standards. The most common are SAML (Security Assertion Markup Language), OIDC (Open ID Connect), and OAuth 2.0. Each is a bit different and has a different purpose (OIDC actually relies on OAuth 2.0), and it will be a long time before we have to get into the details. You know how to read Wikipedia if you really can’t wait.

The Process

I’m going to get a little generic, instead of focusing on a specific standard, so we can keep things simple for now. And, honestly, this is nearly all you need to know unless you start writing your own federation code.

• Users are created in the Identity Provider and assigned attributes such as group, role, and email address.

• Administrators create a trust relationship between the identity provider and the relying party. This is usually an exchange of metadata to define the relationship and cryptographic signing certificate(s), and includes the URLs for communications. Those certificates are the magic sauce so it’s a major security bummer if you let an attacker get them.

  • The entire system assumes that only the two sides have access to the private signing certificates. This is the foundation of the whole trust relationship. Messages will be digitally signed to prove they came from the IdP. If an attacker gets the certificate, they can pretend to be the IdP, and bad things happen. Just ask Microsoft.

• This next part is a bit different depending on the specific standard, but this is enough to explain the concepts. A user logs into the IdP. When they go to log into a relying party, they provide the address of the IdP or some other identifier so the relying party knows who the heck they are (this is usually hidden from the user). The IdP then makes an assertion: a digitally signed statement that the user is who they say they are, including whatever attributes they send over (like a group or whether they used MFA).

• The user is issued a digital token which represents the session. That token has a Time To Live (TTL) before expiration. The user only needs to present the token to the relying party, which then decides what the user is allowed to do.

• When the token expires, the user needs to log in again, or ask for a refreshed token with a new TTL.

Here’s a simplified diagram to highlight the main points:

Lesson Key Points

• Federation is a form of Single Sign On which enables you to log into one Identity Provider and access actions and resources in a Relying Party.

• Federation is the name of the game in cloud, since we need to create an identity relationship between two organizations — otherwise everyone would have more accounts than grains of sand in the universe.

• Federation uses cryptography to create trust relationships. Messages are signed using digital certificates.

• A user is issued a digital token, which is how they access the relying party. Attackers love these.

The Lab

Today we will enable federation using the AWS Identity Center, create an Administrators group, create our own user, and set up MFA. In our next lab we’ll assign permissions and accounts.

AWS supports a range of federation. When we switched roles using AssumeRole, that used a form of federation, but it was all inside AWS and — as you saw — not really scalable. We aren’t about to create hundreds of IAM users for our org. I’ve seen it done — it doesn’t end well. Or start well. And the middle isn’t that great either.

AWS natively supports SAML and OIDC in accounts, and you can manually create connections in the IAM dashboard under Identity Services. We won’t use that because it’s intended for one account. Instead AWS has a service called AWS Identity Center, previously AWS SSO.

Identity Center can be the IdP for accessing your AWS accounts. In that case we set it up with a built-in user pool. But you can also federate into Identity Center from your own IdP. That’s how we can map a big corporate directory into AWS and translate it into access into individual accounts, with different permissions.

There are a lot of big concepts in federation and Identity Center, but this post is already too long, so let’s just jump in and I’ll just explain more as we go.

Video Walkthrough

Step-by-Step

First, go to https://console.aws.amazon.com and sign in. Then go to IAM Identity Center. I guess this is different than Mystical Creatures Identity Center, so they had to add the “IAM” part.

Then Enable. Being bald and sitting in a chair, I wish these buttons all said Engage, but I’m out of luck.

One important security note you will see on the next screen: unless you block it with an SCP, an administrator can create an instance of Identity Center in their own account, scoped to only that account. You generally don’t want this, so we will block it with an SCP later.

The next thing to do is to bookmark the link which allows us to log in. As you register users they will get this via email, but it helps to copy and paste it as a manual bookmark.

We’ll start by creating an Administrators group:

Call it Administrators and leave a good description:

Next we want to set up MFA. By default Identity Center will send users an email code when they log in from a new device, but I recommend being stronger (fitness is important). I also recommend requiring real MFA for every login. Follow these steps:

We want to require MFA on every sign-in, and require the user to set up their own MFA app or device (e.g., a Yubikey, who should sponsor — that would be a cool lab!). I don’t like the email option.

Now create a user for yourself. Take a minute on the page and notice that you can set a lot of details, just like in any enterprise directory. We are only concerned with the basics. Notice that I used yet another +address email. You don’t really need to, but I like to keep all my identities separate. In a corporate environment you would likely be hooking into another directory, and thus be using their main email.

Then click Next.

Add yourself to the Administrators group:

Then Add user:

The user (you) will then get an email that looks like this:

Click the link to set up your password, another MFA, and log in. Once you do you’ll see you don’t have access to anything because… our time is up and we’ll set that up next week!

Lab Key Points

• IAM Identity Center is the SSO portal (heck, it used to be called that) in AWS.

• It can serve as an identity provider, or as a bridge from your enterprise IdP into AWS.

  • It can even be your IdP for other cloud services outside AWS.

• We configured Identity Center for the entire Organization. But an administrator in an account could also configure it for their account; we will add an SCP to block that later.

• The default MFA setting is to send the user an email when they first use a device. Instead we required real MFA for every login.

-Rich