SCIM provisioning

Shield360 is a SCIM 2.0 service provider (RFC 7643 / 7644). Your identity provider creates members, keeps their details current, pushes groups, and deactivates people the moment they leave.

What deactivation does

When the provider deactivates a person (active: false) or deletes them, Shield360 — in one step, as removing a member by hand does:

• removes their membership of the organisation and their links to its databases;
• revokes the API keys they created for the organisation;
• ends their sessions, where the organisation speaks for them: it has verified their email domain, or it was their only organisation.

AI agents the person owned keep their access but no longer have an owner. They are flagged as Owner left in Agent authorization and raise an agent_authorization.owner_orphaned alert, so somebody reassigns them.

The SCIM record stays while deactivated, so the provider can read it and reactivate the person. The organisation’s owner and its break-glass account are never changed or removed through SCIM.

Groups and roles

Groups pushed over SCIM drive roles through the same group-to-role mapping as SAML sign-in (Settings → Security). The first mapped group a person is in decides their role. When they leave every mapped group, a role the mapping gave them goes back to the organisation’s default role; a role an administrator gave by hand is left alone.

Connect your provider

1. In Settings → Organisation → Security → SCIM 2.0 provisioning, choose Create SCIM token and copy it. It is shown once and only its hash is stored. Creating a new token revokes the old one, which is how you rotate it.
2. Give your provider:
   • Tenant / base URL: https://<your Shield360>/api/scim/v2
   • Token: the SCIM token, sent as Authorization: Bearer <token>.

Entra ID

1. Open the Shield360 enterprise application → Provisioning → Get started, Provisioning Mode: Automatic.
2. Tenant URL: the base URL. Secret Token: the SCIM token. Test Connection, then Save.
3. Mappings: keep userName ← userPrincipalName (or mail), active ← Switch([IsSoftDeleted], , "False", "True", "True", "False"), emails[type eq “work”].value ← mail. For groups, keep displayName.
4. Assign users and groups, and set Provisioning Status to On.

Okta

1. In the Shield360 app: General → App Settings → Edit, Provisioning: SCIM.
2. Provisioning → Integration: SCIM connector base URL: the base URL; Unique identifier field for users: userName; supported actions Push New Users, Push Profile Updates, Push Groups; Authentication Mode: HTTP Header, with the SCIM token.
3. Provisioning → To App: enable Create Users, Update User Attributes and Deactivate Users.
4. Push Groups: push the groups your mapping names.

Google Workspace

Google Workspace provisions over SCIM only to apps in its own catalogue, not to custom SAML apps. Use SAML with automatic joining on your verified domain, or provision from Entra ID or Okta.

Supported endpoints

Endpoint	Methods
/Users	GET (filter userName eq "…" or externalId eq "…", startIndex, count), POST
/Users/{id}	GET, PUT, PATCH, DELETE
/Groups	GET (filter displayName eq "…" or externalId eq "…", excludedAttributes=members), POST
/Groups/{id}	GET, PUT, PATCH, DELETE
/ServiceProviderConfig, /ResourceTypes, /Schemas	GET

Bulk, sorting, ETags and password changes are not supported. A new user’s email comes from the primary emails value, or from userName when that is an email address. SCIM never changes the email a person signs in with.

An existing Shield360 account that belongs to another organisation is linked only when this organisation has verified its email domain; otherwise the request is refused with 409 uniqueness.

Limits and auditing

• Requests are limited per token and per address (429 with Retry-After).
• Every write — accepted or refused — is in the audit log with the action (scim.user.create, scim.user.deactivate, scim.group.update, …), the token’s id and the outcome. The token itself is never recorded.
• While the organisation is closing, writes are refused with 403.