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

# SCIM IdP Setup Guides

> Configure Okta, Azure Entra ID, OneLogin, and AWS-sourced SCIM provisioning for Genesis.

These guides assume you have already:

1. Generated a Genesis SCIM bearer token through the
   [SCIM Admin API](/docs/Setup/SCIM-Admin-API).
2. Configured a [group-to-role mapping](/docs/Setup/SCIM-Admin-API#configure-the-group-to-role-mapping)
   in Genesis for the groups you intend to push from the IdP.

For the conceptual overview, see the
[SCIM Inbound Provisioning](/docs/Setup/SCIM-Inbound-Provisioning) page.

## Common values for any IdP

| Setting | Value |
| - | - |
| SCIM base URL | `https://<genesis-host>/scim/v2` |
| Auth type | Bearer token |
| `userName` field | Primary email address |
| Groups to push | Only the groups present in the Genesis mapping |
| Deprovisioning | Send `active=false` (do not delete) |
| Group membership | Send full membership snapshots, or PATCH add/remove members |

<Warning>
  Push only groups that are mapped in Genesis. Pushing unmapped groups results
  in `4xx` SCIM errors and noisy IdP retries.
</Warning>

## Okta

For a screenshot-backed walkthrough, see the
[Okta SCIM Setup Guide](/docs/Setup/SCIM-Okta-Setup-Guide).

<Steps>
  <Step title="Create or open the Genesis app in Okta">
    In the Okta admin console, create a new SCIM 2.0 application for Genesis,
    or open the existing one.
  </Step>

  <Step title="Enable SCIM provisioning">
    Open **Provisioning** and turn on SCIM provisioning.
  </Step>

  <Step title="Configure the SCIM connection">
    * **SCIM connector base URL:** `https://<genesis-host>/scim/v2`
    * **Unique identifier field for users:** `userName`
    * **Authentication mode:** HTTP Header
    * **HTTP Header → Authorization:** `Bearer <Genesis SCIM token>`
  </Step>

  <Step title="Test API credentials">
    Use Okta's **Test API Credentials** action. Genesis returns service-provider
    metadata on success.
  </Step>

  <Step title="Enable provisioning operations">
    Turn on:

    * Create users
    * Update user attributes
    * Deactivate users
    * Push groups
  </Step>

  <Step title="Push only mapped groups">
    Push only the groups present in the Genesis group-to-role mapping. Other
    groups will return SCIM errors.
  </Step>

  <Step title="Validate end-to-end">
    Run one user create, one group membership change, and one user deactivate
    against a pilot user. See the [Pilot Runbook](/docs/Setup/SCIM-Pilot-Runbook).
  </Step>
</Steps>

### Recommended Okta attribute mappings

| Genesis / SCIM attribute | Okta source |
| - | - |
| `userName` | Primary email |
| `emails[primary].value` | Primary email |
| `displayName` | Display name |
| `name.givenName` | First name |
| `name.familyName` | Last name |
| `title` | Title |
| `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.employeeNumber` | Employee number |
| `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.division` | Division |
| `urn:ietf:params:scim:schemas:extension:enterprise:2.0:User.department` | Department |
| `active` | Account state |

When configuring optional Okta profile mappings, prefer the standard Enterprise
User extension fields above for `employeeNumber`, `division`, and
`department`. Genesis also accepts the top-level compatibility fields with the
same names on create and replace requests.

## Azure Entra ID

<Steps>
  <Step title="Create the Enterprise Application">
    In the Entra ID admin center, create an Enterprise Application for Genesis.
  </Step>

  <Step title="Open Provisioning and choose Automatic">
    Set the **Provisioning Mode** to **Automatic**.
  </Step>

  <Step title="Configure the Admin Credentials">
    * **Tenant URL:** `https://<genesis-host>/scim/v2`
    * **Secret Token:** the Genesis SCIM bearer token
  </Step>

  <Step title="Test connection">
    Use the **Test Connection** button. Entra calls Genesis and confirms the
    token and base URL.
  </Step>

  <Step title="Scope provisioning">
    Set **Scope** to **Sync only assigned users and groups**, then assign only
    the users and groups that should be provisioned to Genesis. Assign only
    groups that exist in the Genesis group-to-role mapping.
  </Step>

  <Step title="Start provisioning">
    Save and start provisioning. Watch the Entra provisioning logs for the
    initial sync run.
  </Step>
</Steps>

### Recommended Entra ID attribute mappings

| Genesis / SCIM attribute | Entra source |
| - | - |
| `userName` | `mail` (preferred) or `userPrincipalName` |
| `emails[primary].value` | `mail` |
| `displayName` | `displayName` |
| `active` | Account-enabled state (`Switch([IsSoftDeleted], , "False", "True", "True", "False")`) |

<Note>
  Entra ID may send opaque object IDs as `externalId` for groups. If your
  Entra setup sends GUIDs rather than display names, add the GUID as the key
  in the Genesis [group-to-role mapping](/docs/Setup/SCIM-Admin-API#mapping-key-choice).
</Note>

## OneLogin

<Steps>
  <Step title="Add a SCIM provisioning app">
    In OneLogin, add a custom SCIM provisioning app for Genesis (SCIM
    Provisioner with SAML or SCIM-only as appropriate).
  </Step>

  <Step title="Configure the SCIM connection">
    * **SCIM Base URL:** `https://<genesis-host>/scim/v2`
    * **SCIM Bearer Token:** the Genesis SCIM bearer token
  </Step>

  <Step title="Enable provisioning operations">
    Enable: create user, update user, delete or deactivate user, and group
    sync.
  </Step>

  <Step title="Map OneLogin groups or roles">
    Map OneLogin groups or roles to SCIM group display names whose names are
    keys in the Genesis group-to-role mapping.
  </Step>

  <Step title="Validate end-to-end">
    Provision one pilot user and one group membership change before broader
    rollout.
  </Step>
</Steps>

## AWS-sourced provisioning

AWS IAM Identity Center is **primarily a SCIM target** rather than a generic
SCIM client. It receives users and groups **into** Identity Center from an
external IdP. It does not natively push SCIM into arbitrary custom
applications such as Genesis.

For customers who want to drive Genesis from AWS Identity Store, the
supported pattern is an AWS-hosted provisioner that bridges Identity Store and
Genesis SCIM:

```text theme={null}
AWS Identity Store ──> AWS-hosted provisioner ──HTTPS──> https://<genesis-host>/scim/v2
                       (reads via AWS APIs)              (sends SCIM payloads)
```

<Steps>
  <Step title="Maintain the source of truth in AWS">
    Manage users and groups in AWS Identity Store as you would for any other
    Identity Center workload.
  </Step>

  <Step title="Run the provisioner inside your AWS environment">
    Deploy a provisioner workload (for example, in EKS) with AWS credentials
    that allow reading Identity Store users, groups, and group memberships.
  </Step>

  <Step title="Push to Genesis SCIM">
    The provisioner reads the current Identity Store state and pushes SCIM
    Users and Groups to `https://<genesis-host>/scim/v2` using the Genesis
    SCIM bearer token.
  </Step>

  <Step title="Map AWS group identifiers in Genesis">
    AWS group IDs typically arrive as SCIM `externalId` values. Configure the
    Genesis [group-to-role mapping](/docs/Setup/SCIM-Admin-API#mapping-key-choice)
    keyed by the group display name and / or the AWS group ID.
  </Step>
</Steps>

For production customer rollouts that need direct outbound SCIM, prefer an
IdP that natively pushes outbound SCIM to custom applications, such as Okta,
Azure Entra ID, or OneLogin.

## Per-IdP validation checklist

Run all of the following against a pilot user before enabling the IdP for
production traffic:

* Invalid bearer token returns a SCIM-shaped `401`/`403`.
* The IdP **Test Connection** action succeeds.
* A user create from the IdP appears as a Genesis user with `Managed by SCIM`.
* A user attribute update from the IdP changes the displayed values in
  Genesis.
* A user deactivation in the IdP sets `active=false` on the Genesis user.
* Adding the user to a mapped group in the IdP grants the corresponding
  Genesis role.
* Removing the user from the mapped group in the IdP removes only that role
  and leaves the user active.
* Audit rows are written in `SCIM_AUDIT_LOG` for each operation.

The full end-to-end runbook is in the
[SCIM Pilot Runbook](/docs/Setup/SCIM-Pilot-Runbook).