# SCIM provisioning > SCIM 2.0 provisioning of LightHouse users and groups from the organisation's directory, including deprovisioning. LightHouse™ accepts SCIM 2.0 provisioning (RFC 7643 and RFC 7644) from Microsoft Entra ID, Okta or any directory that sends standard SCIM. The directory creates, updates, deactivates and deletes users and groups in the tenant. ## Scope Provisioning records who is in the directory, who is active and which groups each person belongs to. It operates with [single sign-on](/enterprise/single-sign-on/) and the sign-in rules on the **Access** page: | Subject | Behaviour | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Roles** | A role comes from a sign-in rule. A **Directory group** rule gives a role to the active members of a provisioned group. Domain, group and named-person rules continue to apply | | **Deprovisioning** | Takes precedence over every rule. A person the directory has deactivated or deleted is refused from their next request, including where a domain or group rule matches them. Their delegated tokens (CLI and MCP clients) are revoked immediately | | **API keys** | Unaffected. Keys belong to the tenant’s machines and are listed in the [access review](/security/verify/#with-your-tenants-credentials) | | **Matching** | A provisioned user is matched to a person by email address: the primary email, or the `userName` where it is an email address. It must be the address the person signs in with | ## Endpoint and token **Access → Provisioning** requires `client_admin`, signed in as a person. | | | | ------------------ | --------------------------------------------------------- | | **SCIM base URL** | `https://.atlanticagenticlabs.com/api/scim/v2` | | **Authentication** | A bearer token: `Authorization: Bearer ` | Choose **Create token**. The token is shown once; enter it in the directory at that point. LightHouse stores only its SHA-256 hash, and the token is accepted only at the tenant’s own host. | Action | Effect | | ------------------------- | --------------------------------------------------------------------------------------------------------- | | **Create token** | Issues the tenant’s one live token | | **Replace token** | Issues a new token and revokes the previous one immediately. Enter the new token in the directory at once | | **Turn off provisioning** | Revokes the token. People already deactivated remain refused | The page shows whether provisioning is on, when the token was issued and last used, counts of active and deactivated users and of groups, and the recent provisioning events. ## Directory configuration **Microsoft Entra ID** 1. In the Microsoft Entra admin centre, open **Enterprise applications** and choose **New application → Create your own application**, as a non-gallery application. An existing enterprise application for LightHouse sign-in can be used instead. 2. Open **Provisioning**, and set **Provisioning Mode** to **Automatic**. 3. Under **Admin Credentials**, set **Tenant URL** to the SCIM base URL and **Secret Token** to the token from LightHouse. Choose **Test Connection**, then **Save**. 4. Under **Mappings**, check that `userName` is mapped to the attribute that holds the address people sign in with (usually `userPrincipalName` or `mail`), and that `emails[type eq "work"].value` is mapped to `mail`. Keep the `active` mapping; it deactivates the user when the account is disabled. 5. Under **Users and groups**, assign the users and groups to provision. 6. Set **Provisioning Status** to **On** and save. Result: Entra ID provisions on its own schedule. **Provision on demand** provisions one user immediately, for a check; the user appears in the counts on **Access → Provisioning**. **Okta** 1. In the Okta admin console, open the app integration used for LightHouse sign-in. On its **General** tab, under **App Settings**, enable **SCIM provisioning** and save. 2. On the **Provisioning** tab, under **Integration**, set **SCIM connector base URL** to the SCIM base URL and **Unique identifier field for users** to `userName`. 3. Under **Supported provisioning actions**, select **Push New Users**, **Push Profile Updates** and **Push Groups**. 4. Set **Authentication Mode** to **HTTP Header**, and paste the token from LightHouse as the bearer token. Choose **Test Connector Configuration**, then **Save**. 5. Under **Provisioning → To App**, enable **Create Users**, **Update User Attributes** and **Deactivate Users**. 6. On the **Assignments** tab, assign the people and groups to provision. On the **Push Groups** tab, push the groups that sign-in rules will name. Result: the users and groups appear in the counts and recent events on **Access → Provisioning**. ## Directory group sign-in rules On the **Access** page, add a rule of the kind **Directory group (SCIM)**, enter the group’s display name exactly as the directory sends it, and choose the role. The rule admits the group’s active members. Membership is read on every request. A person removed from the group loses the role from their next request, and a delegated token issued under that rule stops working. ## Deprovisioning When the directory deactivates a user (`active: false`) or deletes one, LightHouse refuses that person from their next request and revokes their delegated tokens. A deleted user is retained as a deletion record, which prevents a domain rule from admitting the person again. The record is replaced only if the directory provisions the same `userName` again. ## Supported operations | Resource | Operations | | --------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | | `ServiceProviderConfig`, `ResourceTypes`, `Schemas` | `GET` | | `Users` | `GET` (with `filter`, `startIndex` and `count`), `POST`; on one user `GET`, `PUT`, `PATCH`, `DELETE` | | `Groups` | `GET` (with `filter`), `POST`; on one group `GET`, `PUT`, `PATCH`, `DELETE` | Filters: for users, `userName eq`, `externalId eq` and `emails.value eq`; for groups, `displayName eq` and `externalId eq`. `PATCH` accepts the operation shapes that Entra ID and Okta send. Users and groups are held per tenant under row-level security; an identifier from another tenant returns not found. ## Portal API | Route | Role | Action | | --------------------------- | ------------------------ | ----------------------------------------------------------------- | | `GET /api/v1/scim` | `client_admin` | Returns the base URL, the token’s state, counts and recent events | | `POST /api/v1/scim/token` | `client_admin`, a person | Issues a token, shown once; the previous one stops working | | `DELETE /api/v1/scim/token` | `client_admin`, a person | Turns provisioning off | ## Audit Token changes are recorded in the tenant’s audit log with the person who made them (`scim_token_issued`, `scim_token_revoked`). The directory’s changes are recorded with the actor `scim`: `scim_user_created`, `scim_user_deactivated`, `scim_user_reactivated`, `scim_user_deleted`, `scim_group_created`, `scim_group_changed` and `scim_group_deleted`. Source: https://docs.atlanticagenticlabs.com/enterprise/provisioning/