Connect your identity provider
Identity integration is set up with us: your identity team does the IdP-side configuration with their admin console, our team does the Data Workers side, and the federation is verified with a pilot group before rollout. This page is what your IAM owner needs to scope the work.
What’s supported, per IdP
Section titled “What’s supported, per IdP”We validate against real IdP sandboxes and say plainly where coverage stands:
| IdP | SSO (SAML 2.0) | SCIM 2.0 provisioning | Validation status |
|---|---|---|---|
| Okta | ✓ | ✓ | Validated |
| Microsoft Entra ID (Azure AD) | ✓ | ✓ | Validated |
| Google Workspace | ✓ | Workspace provisioning (their beta) | SSO validated; SCIM beta |
| PingFederate / PingOne | ✓ (SAML; OIDC supported) | ✓ via PingOne / provisioner | Validated (SAML) |
| OneLogin | ✓ | ✓ | In pilot — CI coverage in progress |
| JumpCloud | ✓ | ✓ | In pilot |
| ADFS | ✓ | ✗ (no SCIM — group claims only) | Best-effort |
“Validated” reflects our internal test coverage against that IdP’s sandbox — ask and we’ll show your identity team the evidence. Another IdP? Anything SAML 2.0-compliant can federate; we’ll tell you honestly what coverage it has.
What your identity team provides
Section titled “What your identity team provides”- IdP admin access (e.g. Okta Super Admin, Entra Application Administrator).
- The groups that should map to Data Workers roles (see mapping below).
- A pilot group of 3–5 users for federation verification before broad assignment.
We provide the service-provider details for your tenant — entity ID, ACS URL, and SCIM endpoint + token — during provisioning.
Group-to-role mapping
Section titled “Group-to-role mapping”Your IdP groups drive Data Workers authorization, which is how per-role policy works
even in clients whose team config can’t express it (see
Cursor for Teams): for example, a dw-engineers group
mapped to a role with write-tool access, and dw-analysts mapped to read-only. Mapping
is configured group-name → role during setup and enforced server-side on every call.
Lifecycle and offboarding
Section titled “Lifecycle and offboarding”With SCIM enabled, deactivating a user in your IdP deprovisions them in Data Workers — that’s the path to fast, automatic offboarding. Two honest caveats:
- ADFS has no SCIM: lifecycle rides on SAML group claims, so strict offboarding needs the account disabled in AD (which ends the SSO session) plus session revocation on our side — we’ll configure that with you if ADFS is your IdP.
- SSO/SCIM govern the Data Workers tenant (hosted endpoint, console identity, audit attribution). Engineers’ coding-agent identities are governed by those products’ own admin planes — Claude Code and Cursor for Teams have their own docs here.
Verification
Section titled “Verification”Done means: the pilot group signs in through your IdP, a SCIM-deactivated test user loses access, group-role mapping is demonstrated with one write-allowed and one read-only user, and the results are recorded in your onboarding report.