> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure Automated User Provisioning with Okta

> Configure CoreWeave Automated User Provisioning with Okta

Automated User Provisioning (AUP) lets you instantly sync users and groups from your identity provider (IdP) to the Cloud Console, using the SCIM (System for Cross-domain Identity Management) standard. You no longer need to send invites or wait for users to sign in.

This guide shows how to set up AUP with Okta as the IdP. When you finish, SAML SSO and one-way SCIM are configured, and you can assign Okta users and groups so they sync into CoreWeave IAM.

## Prerequisites

You need the following access:

* Admin access to the CoreWeave Cloud Console.
* Admin access to the Okta dashboard.

## Create SAML SSO integration

Users created through AUP must use SAML SSO for authentication, so you must [configure SAML SSO first](/security/authn-authz/saml-sso/configure-saml-sso).

1. Open the Cloud Console and the Okta dashboard in separate windows.

   * In the Cloud Console: Navigate to the [SAML SSO](https://console.coreweave.com/organization/iam/sso) page and click **Configure SAML**.
   * In Okta: Go to **Applications**, click **Create App Integration**, and select *SAML 2.0*.

   For the next few steps, the Cloud Console displays details for your integration that you need to copy into Okta.

2. Copy the *ACS URL* from the Cloud Console and paste it into Okta's *Single sign-on URL* field. Leave the checkbox checked (for *Use this for Recipient URL and Destination URL*).

3. Copy the *Entity ID* from the Cloud Console and paste it into Okta's *Audience URI (SP Entity ID)* field.

4. In Okta, within the **SAML Attributes > Sign-on** tab, add the following SAML SSO attributes in the **Attribute Statements** section:

   | Name         | Value            |
   | ------------ | ---------------- |
   | `first_name` | `user.firstName` |
   | `last_name`  | `user.lastName`  |
   | `email`      | `user.email`     |

   Click **Next**.

5. For **App Type**, select *This is an internal app we have created*, and click **Finish**.

6. The Okta dashboard displays a page with details for your integration. This time, you copy values from the Okta dashboard and paste them into the **Identity Provider** section in the Cloud Console. In the Okta dashboard, ensure the **Sign-on** tab is selected. Under **Sign-on methods**, under **Metadata details**, expand the *More details* carat to reveal more sign-on details.

   * Copy the *Sign-on URL*, and then paste the value into the **SSO URL** field in the Cloud Console.
   * Copy the *Issuer*, and then paste the value into the **Entity ID** field in the Cloud Console.
   * Copy the *Signing Certificate*, and then paste the value into the **Signing certificate** field in the Cloud Console.

7. In the Cloud Console, click **Next** and then click **Deploy SSO**.

## Configure one-way SCIM

Set up one-way SCIM provisioning so the Cloud Console can receive user and group information from Okta.

1. In the Cloud Console, on the [SCIM Configuration](https://console.coreweave.com/organization/iam/scim) page, toggle **Enable SCIM API** and **Enable Automated User Provisioning**.

2. In the Cloud Console, create a new **SCIM Token** with a name of your choice (for example, **Okta ID**).

3. In Okta:

   * On your integration's **General** tab, click **Edit** in the **App Settings** card.
   * Set **Provisioning** to **SCIM** radio button, and click **Save**.

4. Go to the **Provisioning** tab in Okta:

   * Click **Edit** in the **SCIM Connection** section.
   * Set **SCIM Connector base URL** to `https://api.coreweave.com/scim/[org-userid]`. Find your org ID in the ACS URL (from the Cloud Console) `https://console.coreweave.com/accounts/saml/[org-userid]/acs`.
   * Set **Unique identifier field for users** to `userName`.
   * For **Supported provisioning actions**: select *Push New Users*, *Push Profile Updates*, and *Push Groups*. Do not enable any import options.
   * Set **Authentication mode** to *HTTP Header*.
   * For **Authorization**, paste the bearer token from the Cloud Console.

   After setup, the **Settings** sidebar populates two new tabs: **To App** and **To Okta**. Because this is a one-way sync, **To Okta** shows *Import Not Available*.

5. In the **To App** tab:

   * Click **Edit** under **Provisioning to App**.
   * Enable: Create Users, Update User Attributes, and Deactivate Users.
   * Do not enable *Sync Password* because SAML SSO handles authentication.
   * Click **Save**.

## Assign users and groups

To complete the integration, assign users to a group in your IdP, and then assign the group to your application. Then test the integration by checking whether the users sync to the Cloud Console.

1. In the Cloud Console, navigate to the [Users](https://console.coreweave.com/organization/users) page to view a list of all users in your organization.

2. Assign users to a group in Okta:

   * Go to **Directory > Groups** and click the name of a group.
   * With the **People** tab selected, click **Assign people**.
   * Click the **+** icon to add individuals to the group, and make sure to include the *Org Admin*.

3. Assign the group to your application in Okta:

   * Go to **Applications > Applications** and click the name of your application.
   * On your application's **Assignments** tab, click the **Assign** dropdown, then click *Assign to Groups*.
   * Find the name of the group, then click *Assign*.
   * Click **Save and go back**, then click **Done**.
   * The name of that group appears in the assignments list for your application.

4. In the Cloud Console, refresh the page showing your **Users** list. The users in the group you just assigned in Okta appear immediately in the Cloud Console.

## Sync groups

### Nested groups

CoreWeave SCIM does not support nested groups. If you push a parent Okta group whose member list includes references to other groups, provisioning fails for those nested group members. To avoid sync errors, use one of the following approaches:

* Push only flat (leaf) groups. Do not push parent groups that contain sub-groups.
* Add a [group membership filter](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-about-group-push.htm) to exclude parent groups from being pushed.
* Use an Okta [group rule](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-create-group-rule.htm) to flatten nested memberships into a single flat group before pushing.

Okta uses *push groups* that are configured to push group memberships to applications like the Cloud Console, through a feature called [Group Push](https://help.okta.com/en-us/content/topics/users-groups-profiles/usgp-about-group-push.htm).

You can sync groups from Okta to the Cloud Console in two ways:

* **Recommended path**: Configure a regular Okta group for all the users you want to push to CoreWeave, along with all regular groups that you want to represent in the Cloud Console. Then configure push groups for any subgroups you want to manage within CoreWeave. Only those subgroups automatically sync with CoreWeave. Removing a user from a subgroup does not remove the user from the "all CoreWeave users" group.

* **Manual path**: Do not create an "all CoreWeave users" group. Configure push groups in a one-to-one mapping with every regular group. When you make changes, you must manually run **force sync** in Okta for each update.

## Map SSH keys for SUNK

If you use [SUNK User Provisioning (SUP)](/products/sunk/manage_sunk/manage_cluster_access/sunk_user_provisioning), you can sync SUNK attributes, including SSH public keys and POSIX user information, from Okta to CoreWeave. This requires creating custom attributes in your Okta user profile and mapping each one to CoreWeave's SCIM endpoint.

<Note>
  If you are not using SUNK, skip this section.
</Note>

### SUNK attribute reference

Create all of the following custom attributes in your Okta user profile and map each one to the corresponding CoreWeave SCIM attribute. The steps in this section use the SSH keys attribute as a worked example; repeat the same process for each row.

| Display name                  | Variable name                   | Data type | CoreWeave SCIM attribute     |
| ----------------------------- | ------------------------------- | --------- | ---------------------------- |
| SUNK SSH Keys                 | `sunk_ssh_keys`                 | Array     | `sunkSshKeys`                |
| SUNK POSIX Username           | `sunk_posix_username`           | String    | `sunkPosixUsername`          |
| SUNK Preferred Home Directory | `sunk_preferred_home_directory` | String    | `sunkPreferredHomeDirectory` |
| SUNK POSIX Group ID           | `sunk_posix_group_id`           | Number    | `sunkPosixGroupId`           |
| SUNK POSIX User ID            | `sunk_posix_user_id`            | Number    | `sunkPosixUserId`            |
| SUNK Login Shell              | `sunk_login_shell`              | String    | `sunkLoginShell`             |

### Add the SUNK attributes to the Okta user profile

1. In the Okta Admin Console, navigate to **Directory** > **Profile Editor**.

2. Click **Okta** in the Filters list, then click **Profile** for **Okta User (default)**.

3. Click **Add Attribute** and configure the fields for the SSH keys attribute:

   | Field         | Value                          |
   | ------------- | ------------------------------ |
   | Data type     | Array                          |
   | Display name  | SUNK SSH Keys                  |
   | Variable name | `sunk_ssh_keys`                |
   | Description   | SSH public keys for SUNK login |

4. Click **Save**.

5. Repeat the previous two steps for each remaining attribute in the [SUNK attribute reference table](#sunk-attribute-reference), using the **Display name**, **Variable name**, and **Data type** values from that table.

### Set the SSH key on a user profile

1. In the Okta Admin Console, navigate to **Directory** > **People**.

2. Select the target user and click the **Profile** tab.

3. Click **Edit** and enter the user's SSH public key in the **SUNK SSH Keys** field (for example, `ssh-ed25519 AAAAC3Nza...`).

4. Click **Save**.

### Add the attribute mapping

1. In the Okta Admin Console, navigate to **Applications** > **Applications** and select your CoreWeave application.

2. Click the **Provisioning** tab, then select **To App** in the settings list.

3. Scroll to the **Attribute Mappings** section and click **Edit**.

4. Find `sunk_ssh_keys` in the list of Okta user profile attributes. In the target attribute dropdown, select the CoreWeave SCIM attribute `sunkSshKeys`. Okta auto-discovers this attribute from CoreWeave's SCIM schema, and it appears under the `urn:coreweave:params:scim:schemas:extension:coreweave:2.0:CoreWeaveUser` namespace.

5. Repeat the previous step for each remaining attribute in the [SUNK attribute reference table](#sunk-attribute-reference), matching the Okta source attribute (**Variable name**) to the corresponding **CoreWeave SCIM attribute**.

6. Click **Save**.

### Verify the sync

1. In Okta, trigger a manual push for the target user (or wait for the next provisioning cycle).

2. In the Cloud Console, navigate to **Users**, click the three-dot menu next to the target user, and select **View Details**.

3. Under **Slurm Attributes**, confirm the **SSH Keys** field contains the public key you set in Okta.

If the key does not appear, check the Okta provisioning logs under **Reports** > **System Log** for errors. For more details about verifying SSH keys and configuring SUP, see [Provision users in SUNK](/products/sunk/manage_sunk/manage_cluster_access/sunk_user_provisioning).

## Adjust attribute mappings

### Remove the Department attribute

The **Department** attribute in Okta can prevent groups from syncing properly with CoreWeave IAM. Before syncing groups, remove this attribute from the attribute mappings:

1. Navigate to your CoreWeave application in the Okta dashboard.

2. Click the **Provisioning** tab.

3. Locate the **Attribute Mapping** section.

4. Remove the **Department** attribute, and save your changes.

This adjustment removes the **Department** attribute from the attribute mapping used for syncing with CoreWeave, but does not change the attribute inside Okta itself.

### Recommended group sync configuration

1. Configure a regular Okta group for all the users you want to push to CoreWeave.

2. Configure regular Okta groups for all the subgroups that you want to represent in the Cloud Console.

3. For legacy CoreWeave IAM deployments, ensure that your selected Okta groups and subgroups are not named any of the [default user groups](#legacy-default-user-groups), or for every push group with the same name as a default user group create a new user group with the appropriate default policies attached.

4. Use Group Push to [sync your Okta groups](https://help.okta.com/wf/en-us/content/topics/workflows/access-control/access-control-sync-group.htm) for all except the "all CoreWeave users" group.

### Legacy default user groups

Legacy CoreWeave IAM deployments automatically provisioned a set of default user groups with specific policies attached. The policies attached to these groups were necessary for operating CoreWeave services. These legacy default user groups included:

* `admin`
* `metrics`
* `read`
* `write`
* `billing_viewer`

When syncing groups with legacy CoreWeave IAM deployments with SCIM, you must resolve the naming conflict by either avoiding syncing push groups with these names, or for each push group with the same name as a default user group:

* Create a new user group in CoreWeave IAM with a new preferred name.
* Assign the policies attached to a default user group. For example, for an administration group use the policies attached to the `admin` group.
* Delete the default user group before configuring a push group with the same name.