AWS : single Sign-on (SSO) with Okta

bogotobogo.com site search:

Introduction

In this page, we will integrate AWS Single Sign-On with Okta (developer account).

Here is the summary of solution:

Users authenticate against Okta.
Users log on to AWS SSO upon successful authentication with Okta.

Users now can assume roles to perform tasks within their AWS environment using Security Assertion Markup Language (SAML), which is managed by AWS SSO.

  {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Federated": "arn:aws:iam::****:saml-provider/AWSSSO_bb421e8d48559f88_DO_NOT_DELETE"
            },
            "Action": [
                "sts:AssumeRoleWithSAML",
                "sts:TagSession"
            ],
            "Condition": {
                "StringEquals": {
                    "SAML:aud": "https://signin.aws.amazon.com/saml"
                }
            }
        }
    ]
}

This post is closely following this blog (Single Sign-On between Okta Universal Directory and AWS).

Okta setup with developer account

Create a developer account with Okta:

To add AWS SSO application to Okta, navigate to the Okta administration console and login with Okta administrator credentials, then I navigate to the Applications tab. Then, click the Add Integration button and add AWS SSO application.

AWS SSO setup

Select the AWS SSO application and download the SAML Meta Data file generated by Okta by clicking the Identity Provider metadata. Keep this file (IDP-metadata.xml), we need it later to configure the AWS side of the single sign-on:

Now that we have the metadata file, open the AWS Management Console in a new tab while keeping the Okta tab open as the procedure is not finished there yet. Navigate to AWS Single Sign-On and click Enable AWS SSO.

In Settings navigation panel, set the Identity source by clicking the Change link:

Select External identity provider from the list of options. Then, select the XML file we downloaded from Okta.

Click Change identity source to complete the AWS Single Sign-On side of the process.

Here, we need to take note of the two values AWS SSO ACS URL and AWS SSO Issuer URL because we must enter these in the Okta console.

AWS-SSO-Change-identity-provider-metadata-from-download-file.png

Now that we have configured Okta for single sign-on for users to connect using AWS Single Sign-On, we want to enable automatic provisioning of user accounts. As new accounts are added to Okta, and assigned to the AWS SSO application, a corresponding AWS Single Sign-On user is created automatically. So, an administrator does not need to do any work to configure a corresponding account in AWS to map to the Okta user.

On the AWS Single Sign-On Console, navigate to Settings and then click the Enable identity synchronization link.

Then, as shown below, we'll have a dialog containing the values for the SCIM endpoint and an OAuth bearer access token (hidden by default). We need both of these values to use in our Okta application settings.

Back to Okta console - Enable API Integration

Back to the tab open on the Okta console, and click on Provisioning tab under the AWS SSO Application. Click Configure API Integration and select Enable API integration. Then put the values Base URL (AWS Single Sign-On Console SCIM endpoint) and API Token (AWS Single Sign-On Console Access token). Make sure to remove the trailing / at the end of the URL. The URL ends with scim/v2

Click Test API Credentials to verify everything works as expected and click Save.

Then, click To App to enable users creation, update, and deactivate as shown below:

Synchronizing Okta with AWS SSO (groups and users)

Now that the provisioning enabled, we need to assign the users and groups that we want to synchronize from Okta to AWS Single Sign-On.

AWS SSO supports automatic provisioning (synchronization) of user and group information from Okta into AWS SSO using the System for Cross-domain Identity Management (SCIM) v2.0 protocol.
To configure this connection in Okta, you use your SCIM endpoint for AWS SSO and a bearer token that is created automatically by AWS SSO. When you configure SCIM synchronization, you create a mapping of your user attributes in Okta to the named attributes in AWS SSO. This causes the expected attributes to match between AWS SSO and your IdP. - okta

Note: SSO is a way to authenticate, and SCIM is a way to provision. SCIM is to automate the exchange of user identity data between cloud apps. For example, SCIM synchronization is done by Okta's pushing users & groups.

Click the Assignments tab and add Okta users and groups. Click Assign, and select the Okta users and groups we want to have access to AWS

The users are now synchronized to AWS Single Sign-On, and the users can see the AWS Single Sign-On application appear in the Okta portal (logged in with my personal gmail user):

To verify the assigned users are synchronized, switch back to the AWS Single Sign-On console and select the Users tab. As we can see in the picture below, the users assigned in Okta console are present:

Set up permissions in AWS Single Sign-On

Note that at this time, the users have only access to sign in. To manage permissions in terms of what they can access once signed into AWS, we should set up permissions in AWS Single Sign-On.

Back to AWS SSO Console, click AWS Accounts on the left tab bar and select the account from my AWS Organizations that we're giving access to.

Click Assign users to assign SSO users or groups to a set of IAM permissions. For this example, I assign just one user, the one with gmail address.

Click Select permission sets and Create permission set to create a set of IAM policies to describe the set of permissions we're granting to the Okta users. For this case, we're granting a read-only permission on all AWS services:

Testing SSO

Let's test the SSO.

Using the AWS Single Sign-On user portal (the URL is on the AWS Single Sign-On settings page):

Click Management Console:

Using Okta portal (https://dev-8020297.okta.com/):

Click AWS SSO:

This time, we may want to click "Command line ...."

Note

Unfortunately, it appears that we cannot combine AWS SSO with JIT (JUST-IN-TIME) with OKTA. So, JIT (temporary elevated access) and AWS SSO (persistent access) should be used in parallel.

Pls check out

Using the broker alongside your existing access solution.

Refs: