SSO and SCIM
Let your identity provider own authentication and lifecycle — and understand the one thing SSO does not cover.
SSO and SCIM apply to people. Agents authenticate with a key pair at the gateway and are not affected by either.
#SSO
bashcurl -s $CP/v1/admin/sso -H "Authorization: Bearer $KEY"
Configuring it requires sso:update, which is step-up gated — changing how
everyone authenticates is in the same category as revoking an identity.
SSO does not replace step-up
Your identity provider authenticates the session. Step-up requires a fresh re-authentication at the moment of an irreversible operation, which is a different guarantee.
A twelve-hour SSO session is a perfectly good credential for reading dashboards. It is not an appropriate credential for revoking a production agent. → Step-up
Role assignment is yours. SSO tells Veefore who someone is; Veefore decides what they may do. If your provider can send group claims, map them to roles — but review the mapping, because a group that grows is a role grant that grows with it.
#SCIM
bashcurl -s $CP/v1/admin/scim -H "Authorization: Bearer $KEY"
Reading it requires scim:read; configuring it requires scim:update.
SCIM provisions and deprovisions members automatically. The deprovisioning half is the one that matters.
Deprovisioning is the point
A member removed in your identity provider is removed in Veefore, without anyone remembering to do it.
Manual offboarding is reliable right up until the week somebody is busy. SCIM turns "we remove access when people leave" from a process into a property.
What SCIM does not do: revoke an API key that person created. Keys belong to the organization, not to the member who created them.
bashcurl -s $CP/v1/api-keys -H "Authorization: Bearer $KEY"
Review that list as part of offboarding. The name field is why specific names
matter — ci-policy-gate tells you what will break if you revoke it;
temp-key-2 does not.
#Network restrictions
bashcurl -s $CP/v1/admin/networks -H "Authorization: Bearer $KEY"
IP allow and deny rules, requiring network:read and network:update. Requests
from a disallowed network are refused with NETWORK_RESTRICTED.
Test an allow-list change from outside your network before relying on it
An allow-list that excludes your own egress address locks everyone out, including whoever would fix it.
Add the new range, verify from it, then remove the old one. In that order.
#Offboarding checklist
Even with SCIM, four things need a human:
- [ ] API keys they created. Not owned by the member; review and revoke.
- [ ] Delegations they issued.
GET /v1/delegations/graph— a grant that outlived its purpose. - [ ] Approver routing. If a rule names them specifically, approvals will route to nobody.
- [ ] Break-glass.
GET /v1/security/break-glass— remove the grant.
That third one is the quiet failure. A SINGLE-routed approval rule naming a
departed person produces approvals that expire with nobody to decide them, and
no error anywhere.
#Onboarding
- They authenticate through SSO, or are provisioned by SCIM.
- Grant a role, scoped to a workspace where they only need one.
- Do not grant
OWNER. - If they will approve, confirm they understand what an approval card is telling them — an approver without context approves everything.
#Quarterly review
bashcurl -s $CP/v1/members -H "Authorization: Bearer $KEY"
curl -s $CP/v1/api-keys -H "Authorization: Bearer $KEY"
curl -s $CP/v1/security/break-glass -H "Authorization: Bearer $KEY"
Three questions: who holds security:emergency_action, who holds
policy:activate, who holds audit:export. Those accumulate quietly.
Then: any member who no longer needs access? Any organization-wide grant that could be workspace-scoped? Any role that exists for a team that does not?
#MFA
veefore doctor reports MFA not being enforced as a finding, and it is a real
one — SSO without MFA at the provider means a password is the only thing between
an attacker and a session.
Enforce it at your identity provider, which is where it belongs.