Directory sync (SCIM)

Directory sync (SCIM 2.0) lets your identity provider push the user lifecycle to emisar: provision people from the directory, and when someone is offboarded there, their emisar access is revoked automatically — sessions ended, API keys revoked, no manual cleanup.

Enabling directory sync#

On a configured connection, enable directory sync to let your IdP push the user lifecycle to emisar over SCIM 2.0 — the standard Okta, Entra, and JumpCloud all speak as a provisioning client. The directory-sync panel lives on each connection's page, right under its settings. Only available on Enterprise.

emisar console · Directory sync (SCIM)

Expand

1. 1

   Click Enable directory sync on the connection.

   emisar shows you two things to wire into your provider's SCIM connector — both visible in the panel above:

   • — the SCIM base URL — /scim/v2 on your emisar host (copy button beside it), and
   • — a bearer token, shown once when you enable or rotate it. Like every emisar secret it's write-only after that — copy it then. Didn't catch it? Use Rotate token to mint a fresh one (the old one stops working).
2. 2

   Point your IdP's SCIM connector at that base URL and bearer.

   In your provider, set the SCIM endpoint to the base URL and paste the token as the API token — emisar accepts it in the Authorization header. Enable Create / Update / Deactivate. The connection's "Point your IdP at this connection" guide names the per-provider specifics — for Okta, SCIM lives in a separate app (the OIDC login app can't do SCIM); for JumpCloud it's a Custom SCIM config on the same app.

3. 3

   Match the SCIM externalId to the OIDC subject.

   Configure your IdP so the SCIM externalId is the same stable identifier as the connection's identifier claim (the OIDC sub). Then a member's SSO login and their synced directory record resolve to one emisar identity — no email-matching anywhere. Okta and JumpCloud default both to the directory user id, so this usually needs no change. If the two sides can't be configured to share an identifier, that connection can't be reconciled this way.

Once it's wired, here's what the sync does:

• — Provisioning creates the user and their membership at the connection's default role — so account access is in place before their first login. Runner access follows the connection's Default runner access setting, which starts at no runners: a provisioned member sees the fleet only once you grant it, per member or by group mapping.
• — Deprovisioning — when the IdP marks a user inactive or removes them — suspends the member: their sessions are killed and their API keys revoked immediately, so an offboard in your directory revokes emisar access automatically. It does not delete the user — the audit trail is preserved. Reactivation in the directory restores access.

Group → role mapping#

With directory sync on, map an IdP group (by its SCIM externalId) to an emisar role — viewer, operator, billing manager, or admin. A member in several mapped groups gets the highest role mapped to any of them. Owner is never assignable through sync — it stays a deliberate human assignment.

Security notes#

• — The SCIM bearer token is an admin-grade credential — it can provision and deprovision across the account. Treat it like a password, and rotate it from the connection's panel if it's ever exposed (your IdP loses access until you paste the new one).
• — Every directory-sync action lands in the audit log with its authentication method, so you can see that the directory, not a person, suspended an offboarded member.