> ## Documentation Index > Fetch the complete documentation index at: https://docs.blindsight.io/llms.txt > Use this file to discover all available pages before exploring further. # Identity binding > Connect your IdP via SCIM and OIDC so every employee is provisioned automatically and every device binds to a real directory user. The endpoint agent is installed by IT as SYSTEM / root. It cannot know which employee is using the machine on its own. Identity is bound **after** enrollment, using your IdP's directory and SSO flows. This page covers the two complementary mechanisms: * **SCIM** to provision users into the Blindsight workspace from your IdP. * **OIDC** + the device‑code flow to bind each device to a specific directory user. Both live under **Runtime Security → Directory & SSO** in the dashboard. ## SCIM provisioning SCIM (System for Cross‑domain Identity Management) is how your IdP keeps the Blindsight workspace's user list in sync with your directory. When you hire someone, they appear in Blindsight automatically. When you off‑board them, they're disabled. ### Set it up **1. Add a SCIM provider in Blindsight** Open **Runtime Security → Directory & SSO → SCIM** and click **Issue token**. Blindsight returns: * A bearer token (shown once). Copy it. * A base URL: `https:///scim/v2`. **2. Wire it in your IdP** In Entra, Okta, Google, or your IdP of choice, add a custom SCIM application. Paste the base URL and bearer token. Map standard SCIM attributes (`userName`, `emails[primary]`, `name.givenName`, `name.familyName`, `active`). **3. Assign users and groups** Assign the directory groups whose members should be provisioned into Blindsight. Your IdP pushes them immediately. **4. Verify in Blindsight** Under **Settings → Users**, look for the SCIM source badge on each row. Users land with `provisioning_source=scim` and are auto‑activated. ### Behavior | Event in IdP | Effect in Blindsight | | - | - | | User created and assigned | User auto‑created in the workspace with the mapped role. | | User updated (name, email, group) | Blindsight row updated within \~1 minute. | | User deactivated | Soft‑disabled in Blindsight. Sessions revoked, API keys disabled. | | User reactivated | Re‑enabled in Blindsight with the same row and history. | ### Group‑to‑role mapping Under **Directory & SSO → Group mappings**, map IdP groups to Blindsight roles. Common pattern: | IdP group | Blindsight role | Reason | | - | - | - | | `eng-leads` | `Admin` | Manage Apps and endpoint policies. | | `compliance-team` | `Reviewer` | Triage findings, no destructive actions. | | `all-employees` | `Viewer` | Read‑only access to dashboards. | | `engineering` | `Member` | Standard contributor inside Data Security. | A user with multiple matching groups gets the **highest** role. ## OIDC single sign‑on OIDC is how employees sign into the Blindsight dashboard and how the endpoint agent binds a device to a directory user. ### Configure your provider **1. Register Blindsight as an OIDC client** In your IdP, create a new app and copy the `client_id` and `client_secret`. Set the redirect URI to: ``` https:///api/auth/sso//callback ``` Where `` is generated when you add the provider in Blindsight. **2. Add the provider in Blindsight** **Runtime Security → Directory & SSO → OIDC providers → Add**. Provide: * `client_id` * `client_secret` * `discovery_url` (e.g. for Entra: `https://login.microsoftonline.com//v2.0/.well-known/openid-configuration`) **3. Test the flow** Click **Test sign-in** on the provider card. Blindsight opens the IdP, you authenticate, and it redirects back with a confirmation page. ### Supported providers OIDC covers **Entra**, **Okta**, **Google Workspace**, and **Ping**. Any standards‑compliant OIDC IdP that publishes a discovery document works. SAML is schema‑ready in the backend but not enabled in this build. ## Device‑code identity binding Once the agent is installed on a laptop, it needs to know **which directory user** is sitting at the machine. The agent runs the OIDC device‑code flow (RFC 8628): 1. The agent posts to `/agent/identity/start`. 2. Blindsight returns a short verification code and opens the IdP sign‑in page in the user's default browser. 3. The employee signs in with their normal corporate credentials. 4. The agent polls `/agent/identity/status` until the IdP confirms the binding. 5. The device row in **Endpoint → Devices** flips from `pending` to `bound`, with the directory user attached. The flow is one‑click for the employee. They sign in once on first boot; the binding persists for the lifetime of the device. ### Re‑binding A device can be re‑bound to a different directory user: * **Automatically** when SCIM marks the previous user inactive. * **Manually** by an admin from **Endpoint → Devices** → device row → **Force re‑bind**. Re‑binding triggers a new device‑code flow on the agent. ### Confirming an owner without SSO A workspace with no identity provider can still give a device a proved owner. An admin chooses **Confirm owner** on the device, in **Endpoint → Devices**, and names a person in the workspace. The device flips to `bound`, and the platform records which admin vouched, so a confirmed binding is never mistaken for one the identity provider proved. The person must be active. Like an SSO binding, a later re-enrollment that proves nothing returns it to `pending`. Until an owner is confirmed, a workspace with no identity provider has no identity to bind, and a pause request is refused with `identity_binding_unavailable`. See [Only a proved identity may pause](https://docs.blindsight.io/endpoint/devices.md#only-a-proved-identity-may-pause). Only a `bound` owner counts for pausing protection and for what the desktop app shows the person. See [Endpoint permissions](https://docs.blindsight.io/endpoint/permissions.md#what-people-see-in-the-desktop-app). ### Devices pushed by an MDM start as pending The Windows agent installs as SYSTEM, so at enrollment it reports the machine account (`HOST$`) as the device's operating system user. It never learns who signs in. A fleet pushed through Intune, GPO or SCCM therefore starts with every device `pending`, and `auto` matching cannot apply to it. The devices are protected and intercepted while they wait. To attribute a device's traffic to a person, bind it through the SSO device-code flow above, or confirm its owner. A confirmed owner is lost if the device is cleanly re-enrolled, so confirm it again after a reinstall. ## Auto identity for non‑user devices For devices that don't have a human user (lab machines, build servers), the agent sets `Identity = auto` when: * The OS username matches a directory user email's local part, and * SCIM has already provisioned that user. Mark these devices in **Endpoint → Devices** as `service` so they're filtered out of the regular user fleet view. ## Common workflows > **On‑board a new employee** > > 1. HR adds them to the directory. > 2. SCIM provisions them into Blindsight (\~1 min). > 3. IT ships a managed laptop. On first boot, the agent enrolls > and prompts for SSO identity binding. > 4. Employee signs in with corporate credentials. Device is > `bound` to their directory user. > **Off‑board an employee** > > 1. HR deactivates them in the directory. > 2. SCIM disables them in Blindsight. > 3. Their device is auto‑revoked. The agent stops processing > traffic and flags the machine for reclaim. > **Spin up a CI build host** > > 1. IT pushes the agent with the regular MDM policy. > 2. Set `Identity` to `service` and rename the device row to > `ci-runner-04`. > 3. Traffic from the runner is attributed to `service:ci-runner-04` > so you can filter it out of user‑centric reports. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.