Authdog
Enterprise guide

User Provisioning & SCIM

SCIM provisioning lets a customer's identity provider drive user and group lifecycle in Authdog. Authdog exposes a SCIM 2.0 service for Users and Groups, authenticates requests with an environment-scoped bearer token, and can map provisioned groups to RBAC roles. This guide uses console configuration and observable sync results rather than undocumented management APIs.

Prerequisites

  • An Authdog Enterprise plan with a selected project and environment.
  • Administrator access to Provisioning → SCIM in the Authdog console.
  • Administrator access to a SCIM-capable IdP.
  • A test user and test group in the IdP.
  • RBAC roles already defined when group-to-role mapping is required.
  • A documented offboarding test approved for non-production use.

SCIM configuration is environment-specific. Start in development or staging and use test identities that cannot reach production data.

Implementation

1. Generate the provisioning token

Open the target environment's SCIM provisioning page. Copy the displayed SCIM Base URL; Authdog documents the service path as /v1/scim/v2. The environment is resolved from the bearer token, so tenant and environment identifiers are not placed in the service URL.

Select Generate token, give it a recognizable name such as the customer and IdP name, and create it. Copy the full adscim_ token immediately. The console displays the full secret only once; afterward it retains identifying metadata such as name, prefix, creation date, last-used date, and status.

Store the token only in the IdP's protected SCIM configuration or an approved secret-handling workflow. Authdog stores a SHA-256 hash and clear prefix rather than the full token.

2. Configure the IdP

In the IdP's provisioning application:

  1. Set the tenant or base URL to the SCIM Base URL shown by Authdog.
  2. Set authentication to bearer token.
  3. Paste the generated adscim_ token.
  4. Enable only required User and Group operations.
  5. Use the IdP's connection or credential test, if available.

Authdog's service supports Users and Groups, including create, update, deactivate, delete, and group-membership changes. Avoid inventing vendor-specific attribute mappings. Begin with core identity fields supported by both systems, run a test sync, and inspect the resulting Authdog profile before adding more attributes.

3. Test users and groups

Assign one test user and one test group to the IdP provisioning application. Trigger the IdP's initial or on-demand sync.

In Authdog, verify that:

  • The user appears in the intended environment.
  • User identity fields match the upstream record.
  • The group appears with the expected display name and external ID.
  • Group membership contains the test user.
  • The token's Last used value updates after an authenticated request.

If the IdP supports incremental push, update the test user's name and group membership and confirm both changes arrive.

4. Map groups to roles

Under Group → Role Mapping, create a rule that matches either:

  • Group name, compared case-insensitively; or
  • External ID, compared exactly.

Choose the Authdog role to grant, then add the rule. Rules apply during SCIM group sync. If the group already exists, select Re-apply to existing groups and review the reported group and new-assignment counts.

Mappings are additive. They add matched group-role assignments but do not remove existing assignments, including manually added ones. Review all role sources when validating least privilege.

For broader design guidance, see Authorization and access control.

5. Test deprovisioning

Deactivate the test user upstream and trigger sync. Confirm that the Authdog user becomes suspended or deleted according to the operation sent by the IdP. For suspension, the user record remains available for operational history, but new sign-ins are blocked and sessions stop validating on the next validation check.

Also remove the user from the test group and verify that group-derived access changes as expected. Do not consider onboarding complete until both provisioning and deprovisioning have been demonstrated.

6. Operate tokens

Use separate, clearly named tokens where operational ownership requires it. Monitor Last used to distinguish an idle integration from one that is authenticating requests.

The console supports rotation and revocation. Rotation replaces the token secret immediately and shows the new full value once; the old secret stops working without a grace period. Coordinate the Authdog action and IdP update tightly. Revocation permanently marks the token inactive.

Security considerations

  • Treat SCIM tokens as privileged secrets that can modify users and groups in one environment.
  • Never place tokens in browser code, tickets, chat transcripts, screenshots, or logs.
  • Copy each secret once into the intended IdP, then clear temporary clipboard or notes according to local policy.
  • Use non-production identities for initial sync and destructive lifecycle tests.
  • Rotate only with an immediate IdP update plan; old credentials stop working at rotation.
  • Revoke unused or exposed tokens and verify rejected sync attempts.
  • Review direct role assignments because additive group mapping will not remove them.
  • Keep audit exports containing personal data under controlled access and your own retention policy.

Validation checklist

  • IdP uses the Base URL shown for the intended Authdog environment.
  • Bearer token begins with adscim_ and is stored only in the IdP.
  • Test user is created with expected identity fields.
  • Test group and membership are visible in Authdog.
  • Token Last used updates after sync.
  • User update propagates from IdP.
  • Group mapping grants the intended role.
  • Existing groups were re-applied after new mapping rules.
  • Upstream deactivation blocks user access.
  • Token rotation and emergency revocation procedures are documented.

Troubleshooting

IdP reports unauthorized: confirm bearer formatting, token prefix, active status, environment, and whether the token was rotated, revoked, or expired.

Sync succeeds but no user appears: verify the IdP assignment and inspect its provisioning logs. Then confirm Authdog environment and token Last used timestamp.

Group exists but role is missing: compare mapping type and value. Group names ignore case; external IDs require an exact match. Re-apply rules for pre-existing groups.

User keeps permissions after group removal: inspect direct and organization role assignments. Group mappings are additive, so another role source may still grant access.

All provisioning stops after rotation: replace the IdP credential with the newly revealed token. The previous secret becomes invalid immediately.

Next steps