This is a cache of https://docs.openshift.com/acs/3.66/operating/manage-user-access/configure-okta-identity-cloud.html. It is a snapshot of the page at 2024-11-29T17:20:50.886+0000.
Configuring Okta Identity Cloud as a SAML 2.0 identity provider - Managing user access | Operating | Red Hat Advanced Cluster Security for Kubernetes 3.66
    OpenShift docs are moving and will soon only be available at docs.redhat.com, the home of all Red Hat product documentation. Explore the new docs experience today.
  1. Documentation
    2. history
×

Configuring Okta Identity Cloud as a SAML 2.0 identity provider

You can use Okta as a single sign-on (SSO) provider for Red Hat Advanced Cluster Security for Kubernetes (RHACS).

Creating an Okta app

Before you can use Okta as a SAML 2.0 identity provider for Red Hat Advanced Cluster Security for Kubernetes, you must create an Okta app.

Okta’s Developer Console does not support the creation of custom SAML 2.0 applications. If you are using the Developer Console, you must first switch to the Admin Console (Classic UI). To switch, click Developer Console in the top left of the page and select Classic UI.
Prerequisites

  • You must have an account with administrative privileges for the Okta portal.

Procedure

  1. On the Okta portal, select Applications from the menu bar.

  2. Click Add Application and then select Create New App.

  3. In the Create a New Application Integration dialog box, leave Web as the platform and select SAML 2.0 as the protocol that you want to sign in users.

  4. Click Create.

  5. On the General Settings page, enter a name for the app in the App name field.

  6. Click Next.

  7. On the SAML Settings page, set values for the following fields:

    1. Single sign on URL

      • Specify it as https://<RHACS_portal_hostname>/sso/providers/saml/acs.

      • Leave the Use this for Recipient URL and Destination URL option checked.

      • If your RHACS portal is accessible at different URLs, you can add them here by checking the Allow this app to request other SSO URLs option and add the alternative URLs using the specified format.

    2. Audience URI (SP Entity ID)

      • Set the value to RHACS or another value of your choice.

      • Remember the value you choose; you will need this value when you configure Red Hat Advanced Cluster Security for Kubernetes.

    3. Attribute Statements

      • You must add at least one attribute statement.

      • Red Hat recommends using the email attribute:

        • Name: email

        • Format: Unspecified

        • Value: user.email

  8. Verify that you have configured at least one Attribute Statement before continuing.

  9. Click Next.

  10. On the Feedback page, select an option that applies to you.

  11. Select an appropriate App type.

  12. Click Finish.

After the configuration is complete, you are redirected to the Sign On settings page for the new app. A yellow box contains links to the information that you need to configure Red Hat Advanced Cluster Security for Kubernetes.

After you have created the app, assign Okta users to this application. Go to the Assignments tab, and assign the set of individual users or groups that can access Red Hat Advanced Cluster Security for Kubernetes. For example, assign the group Everyone to allow all users in the organization to access Red Hat Advanced Cluster Security for Kubernetes.

Configuring a SAML 2.0 identity provider in Red Hat Advanced Cluster Security for Kubernetes

Use the instructions in this section to integrate a SAML 2.0 identity provider with Red Hat Advanced Cluster Security for Kubernetes.

Prerequisites

  • You must have permissions to configure identity providers in Red Hat Advanced Cluster Security for Kubernetes.

  • You must have an Okta app configured for Red Hat Advanced Cluster Security for Kubernetes.

Procedure

  1. On the RHACS portal, navigate to Platform Configuration → Access Control.

  2. Open the Add an Auth Provider menu and select SAML 2.0.

  3. Fill out the details for:

    • Integration Name: A name to identify this authentication provider, for example, Okta or Google. The integration name is shown on the login page to help users select the right sign-in option.

    • ServiceProvider Issuer: The value you are using as the Audience URI or SP Entity ID in Okta, or a similar value in other providers.

    • IdP Metadata URL: Use the URL of Identity Provider metadata available from your identity provider console. If you do not want to use the IdP Metadata URL, you can instead copy the required static fields from the View Setup Instructions link in the Okta console, or a similar location for other providers.

  4. Choose a Minimum access role for users accessing Red Hat Advanced Cluster Security for Kubernetes by using the selected identity provider.

    Set the Minimum access role to Admin while you complete setup. Later, you can return to the Access Control page to set up more tailored access rules based on user metadata from your identity provider.

  5. Click Save.

If your SAML identity provider’s authentication response:

  • Includes a NotValidAfter assertion, the user session remains valid until the time specified in the NotValidAfter field has elapsed. After its expiry, users must re-authenticate.

  • Does not include a NotValidAfter assertion, the user session remains valid for 30 days, after which, the users must re-authenticate.
Verification

  1. On the RHACS portal, navigate to Platform Configuration → Access Control.

  2. Select the Auth Provider Rules tab.

  3. Under the Auth Providers section, select the authentication provider that you want to verify the configuration for.

  4. Select Test Login from the Auth Provider section header. The Test Login page opens in a new browser tab.

  5. Sign in with your credentials.

    • On success, Red Hat Advanced Cluster Security for Kubernetes shows the User ID and User Attributes the identity provider sent for the credentials you have used to log in.

    • On failure, Red Hat Advanced Cluster Security for Kubernetes shows a message describing why the identity provider’s response could not be processed.

  6. Close the Test Login browser tab.

    Even if the response indicates successful authentication, you might need to create additional access rules based on the user metadata from your identity provider.