Provisioning

Provisioning is how users and their access get created, updated, and removed on their own, from a customer's identity provider or HR system, instead of from a support ticket.

When someone joins or leaves that company, their access to your app should follow. That's what this is for.

The problem it solves

Without provisioning, every new hire signs up by hand, and every departure leaves an account behind. Provisioning closes that loop. The customer's directory is the source of truth: their identity provider or HRIS pushes changes to Authdog, and Authdog reflects them in your environment's user store and roles.

Authdog exposes two inbound channels. Both are token-authenticated REST endpoints, scoped to one environment.

SCIM 2.0: identity provider sync

SCIM (System for Cross-domain Identity Management) is the standard identity providers such as Okta, Entra ID, and JumpCloud already speak. Authdog exposes a SCIM 2.0 service:

• Endpoint: /v1/scim/v2
• Auth: a bearer token prefixed adscim_, issued per environment in the console
• Resources: Users and Groups: create, update, deactivate, delete; group membership changes

Configure the identity provider once, with the endpoint and the token. After that it pushes user and group changes on its own. Deactivating a user there suspends them in Authdog, which invalidates their sessions.

HRIS: HR-driven provisioning

Some customers treat the HR system as the source of truth, not the identity provider. The HRIS connector covers that case. It mirrors the SCIM slice:

• Endpoint: /v1/hris/v1
• Auth: a bearer token prefixed adhris_
• Resources: Employees (users, with employment attributes like job title, manager, department, employment type, cost center, start/end dates) and Departments (groups)

Employment status can drive access, not only whether someone is in a directory group.

Group-to-role mapping

Creating the user is only half of it. They also need the right access. Authdog maps directory groups (SCIM groups or HRIS departments) to roles for you:

IdP group "Engineering"      -> role "developer"
IdP group "Billing Admins"   -> role "billing-admin"
HRIS department "Support"    -> role "agent"

When group membership changes upstream, Authdog recomputes that user's roles additively. RBAC authorization stays in step with the customer's org chart. A mapping matches the group display name (case-insensitive) or the external id (exact).

Deprovisioning

This is the part that protects you. When someone is removed or deactivated upstream:

• their Authdog user is suspended or deleted,
• outstanding sessions stop validating on the next check,
• and group-derived roles fall away.

Access ends when employment ends. Nobody has to remember a cleanup ticket.

How it fits together

Customer directory Source systems

IdP HRIS

SCIM / HRIS push

Authdog environment Synchronizes identity and access

1 Create or update user 2 Sync group membership 3 Apply role mappings

Current user and roles

Your app Authorizes with current roles

Access reflects latest directory state

Provisioning tokens are scoped to one environment. For enterprise customers, provisioning pairs with their enterprise SSO connection: the same customers who bring their own login also bring their own directory. Platform account structure (organizations and tenants) stays above the environment. Provisioning only changes that environment's user store.

Related