Federating AWS Authentication to Okta with SAML

ACM.160 A high level walkthrough of integrating Okta with AWS

Part of my series on Automating Cybersecurity Metrics, IAM, and AWS Organizations. The Code.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

In the last post we considered how we might implement governance for creation of new AWS accounts in an organization.

In this post, I’m going to look at the AWS-Okta integration at a high level based on the documentation. We’re not going to implement anything just yet as we first want to consider our options.

When you integrate AWS and Okta you’re going to be using an identity system integration protocol called SAML (Security Assertion Markup Language). I’m not going to re-hash what you can read about SAML from many other sources. You can read what Okta has to say about SAML here.

One interesting note on this page is the part about implementing a “backdoor.” In cybersecurity, backdoors are often a bad thing. However, I mentioned in an earlier post that the problem with using an IdP to access your cloud account might the case where the IdP is malfunctioning or the victim of a DDoS attack. Or perhaps the IdP is compromised and you want to lock out all access from the IdP.

When considering how to implement Okta, perhaps we don’t want to create our IdP in the root account. We don’t want anyone logging into our root AWS management account anyway. Perhaps we should architect our accounts such that the IdP and all the users log into some other account that manages authentication.

Hold that thought. Let’s look at the steps to set up Okta as an IdP for AWS using AWS IAM. Remember, we are not using AWS IAM Identity Center with SCIM for this test and I explained why in other posts.

Let’s take a look at the steps to set up Okta with AWS.

Step 1: configure Okta as an identity provider in AWS. These steps are pretty straightforward.

As I mentioned before you can configure this by clicking on Identity providers on the IAM dashboard and then click Add provider.

When you get to the next step you need to provide a file to facilitate the integration. To get that file you set up AWS as an application in Okta and generate the file, which you plug in here.

Once you complete that step you’ll have an ARN for your IdP which you will use in a subsequent step.

Can we automate this step?

On the AWS side you can use CloudFormation to create an IdP:

On the Okta side, Okta has an API. I’m not sure if I could make some API calls but that’s not exactly what I had in mind. In addition, Okta offers some Terraform providers. Right away as I read the documentation, I am concerned as I see the use of hard coded AWS access keys.

This concerns me but we aren’t using Terraform here anyway so I’m going to skip that for now. I also, having read ahead, am concerned about the use of AWS keys with Okta, but let’s keep going. As for Terraform, it’s interesting because you can use it to somewhat standardize your deployment process. But you cannot simply create one script and deploy it anywhere. You still have to understand cloud-specific constructs for each cloud environment.

For now, until I find a more straight-forward approach for automation, I will probably manually set up the Okta side for the initial configuration steps. I’ll explore automation for Okta separately at a later point.

Step 2: Create Roles that users authenticated via Okta can assume

Next, we’ll need to create some roles that allow users created in Okta and authenticated by Okta can assume. These roles will require a specific configuration to grant Okta permission to use the roles.

Essentially, we are going to modify the trust policy where the Principal is the IdP.

{
  "Version": "2012-10-17",
  "Statement": [
   {
      "Effect": "Allow"
      "Principal": {
        "Federated": "<COPY & PASTE SAML ARN VALUE HERE>"
      },
      "Action": "sts:AssumeRoleWithSAML",
      "Condition": {
        "StringEquals": {
          "SAML:aud": "https://signin.aws.amazon.com/saml"
        }
       }
    }
  ]
}

Once again, we are talking about trust policies that allow principals to assume roles. We’ve talked about trust policies over and over again throughout these series because they are so important for security in your AWS accounts.

Do you see a problem with the trust policy above? The principal is not very specific. It simply says allow this IdP to assume the role. It’s not specific to a particular identity. There’s no MFA requirement. We’ll look at that in more detail later but let’s get through the simple version of these steps to “make it work” which, as per usual, is not the same as “make it secure.”

Another thing we might want to consider when setting up these roles is multiple regional endpoints for failover:

If there is an outage in a particular region we may be able to login via another region. How much good that will do us depends on the nature of the regional outage and where our resources are located, but it may help.

We can automate the creation of these roles the same way we automated creation of roles in prior posts and code in this series.

Step 3: Generate an AWS API Access Key

Here’s where I’m slightly concerned. The next step involves creating API keys (access key id and secret key. However, security best practice is to create an AWS role for a third-party vendor, not to grant them long-lived credentials. I wonder why Okta takes this approach.

The permissions granted to this key are as follows:

{
    "Version": "2012-10-17",
    "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iam:ListRoles",
        "iam:ListAccountAliases"
        ],
       "Resource": "*"
     }
    ]
}

Now, although this policy only grants read-only access, It could be that someone with access to role names might attempt to find a way to initiate a confused deputy attack. What else might an attacker be able to do with a role name?

Step 4: Configure AWS APP in Okta

The last step is a bit trickier. In this step we configure the Okta side of the integration. Many more steps exist and I think I will need to actually implement this to fully determine if any additional risks exist.

Enable API integration

One thing I do notice in these steps is that there is a checkbox to enable API Integration, and it is at this point where you enter your AWS keys:

I wonder what happens if you do not enable API integration? Alternatively, can you enter the keys, enable integration to obtain the roles, then uncheck the box and disable the keys on the AWS side? That would alleviate some issues with AWS credentials in the Okta system.

Environments and ACS URL

For the advanced configuration, we need to figure out what is required for these settings:

What is an ACS Url? This definition is pretty straightforward:

An Assertion Consumer Service (or ACS) is SAML terminology for the location at a ServiceProvider that accepts <samlp:Response> messages (or SAML artifacts) for the purpose of establishing a session based on an assertion.

Source:

It’s not clear from these steps what is meant by environment. Perhaps it is obvious once you see the screens. However, by Googling around I found these settings for either general AWS or Gov Cloud and the related ACS URLs in case the environment is not listed. I presume other environment like the China region and other government cloud environments have different ACS URLs and audiences. The documentation says to contact AWS if your environment is not listed when configuring Okta.

Application ACS URL: https://signin.aws.amazon.com/saml Application SAML audience: urn:amazon:webservices

Gov Cloud Application ACS URL: https://signin.amazonaws-us-gov.com/saml Application SAML audience: urn:amazon:webservices:govcloud

This documentation for Google Workspaces references the above information and might come in handy when attempting to understand the flow. It’s also interesting if you are considering using Google as the IdP instead of Okta.

Join all roles

I’ll just be honest. This part is confusing me:

Join all roles: Select this check box to make AWS SAML use all roles. If a user is directly assigned Role1 and Role2 (user-to-app assignment), and the user belongs to group GroupAWS with RoleA and RoleB assigned (group-to-app assignment), then Join all roles OFF: Role1 and Role2 are available upon login to AWS Join all roles ON: Role1, Role2, RoleA, and RoleB are available upon login to AWS.

It has something to do with roles assigned:

• Directly to a user (Role > User)
• To a group that a user is in (Role > Group > User)

I guess if you check it the user sees all the roles for both of the above and if you uncheck they see some of the roles. Will have to test it out.

Group mapping and multiple AWS instances

This option refers to the scenario where you have multiple AWS instances. This appears to mean the case where you have multiple AWS accounts and you have IdPs configured in different accounts. This is a pretty long and involved process as explained here:

As it turns out, after going through all of the above in my initial analysis to come up with my Okta SAML integration architecture…that documentation is out of date. It doesn’t match the actual screens I found when I tried to implement this in Okta. The concepts are pretty much the same but the order and method of getting the metadata you need is different.

Once you get into Okta it points you to completely different documentation which is long and wordy and this verbiage about groups is no less confusing. We’ll revisit this topic when we get to that point of the instructions.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab