SCIM provisioning

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 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
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://<tenant id>.atlanticagenticlabs.com/api/scim/v2
Authentication	A bearer token: Authorization: Bearer <token>

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.