Skip to main content
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://<cloud>/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

​
Group‑to‑role mapping

Under Directory & SSO → Group mappings, map IdP groups to Blindsight roles. Common pattern: 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:
Where <provider-uuid> 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/<tenant>/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. Only a bound owner counts for pausing protection and for what the desktop app shows the person. See Endpoint permissions.

​
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

  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.
  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.
  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.