SCIM 2.0 provisioning for your wiki

Provisioning without tickets

The standard enterprise onboarding story is: someone joins, IT opens a ticket, an admin creates accounts in five separate systems, the ticket closes three days later. Offboarding is worse — the ticket to revoke access sits in a queue while the former employee's session token keeps working.

SCIM replaces that queue with an API. Your identity provider — Okta, Azure AD / Entra ID, OneLogin, JumpCloud — speaks SCIM 2.0 natively. Tell it where the endpoint lives and give it a bearer token, and it will create accounts when someone joins, update them when roles change, and deactivate them the moment they leave.

What SCIM 2.0 covers in Wikantik

Users (/scim/v2/Users)

The full CRUD set plus soft-delete:

• Create (POST) — provision a new account. If externalId is provided it is stored as the sso.subject link, making the account SSO-only (no password is revealed). If active: false is in the create body, the account is immediately deactivated.
• Retrieve (GET /scim/v2/Users/{uid}) and list/filter (GET /scim/v2/Users) — filter by userName or externalId.
• Replace (PUT) — full replacement of mutable attributes. userName is not replaced by PUT.
• Partial update (PATCH) — update active, displayName, name.formatted, emails[0].value, or externalId. Active/inactive changes route through UserLifecycleService.
• Soft-delete (DELETE) — calls UserLifecycleService.deactivate(). The database row is preserved; the account is locked. Audit history survives intact.

Groups (/scim/v2/Groups)

Groups route through GroupManager and the groups + group_members tables:

• Create, retrieve, list, replace membership, membership PATCH (Add/Remove), and hard delete.
• Members are resolved by uid — an unresolvable uid returns HTTP 400 invalidValue.
• Nested groups are not supported.

Discovery endpoints

Three RFC 7643 §8 endpoints advertise Wikantik's SCIM capabilities so IdPs can self-configure:

• GET /scim/v2/ServiceProviderConfig — capabilities: patch true, bulk false, filter true (maxResults 1000), changePassword false.
• GET /scim/v2/Schemas — User and Group schema descriptors.
• GET /scim/v2/ResourceTypes — User and Group resource types.

Onboarding and offboarding lifecycle

The typical pattern pairs SCIM with SSO: the IdP uses SCIM to create accounts and maintain group membership, while SSO handles the actual login flow. SCIM-provisioned accounts authenticate via SSO by default — a random password is generated at creation time and never revealed, so there is no credential to phish.

When an employee leaves, the IdP sends a SCIM DELETE or a PATCH active=false. Both routes call UserLifecycleService.deactivate(), which sets a lock expiry and prevents any further login. The account row is retained, so audit history, page ownership records, and any attribution metadata remain intact.

All SCIM user and group operations are recorded in the tamper-evident audit log under category ADMIN with event types such as scim.user.create, scim.user.update, and scim.group.update. (Deactivations route through the shared lifecycle path and are recorded as user.deactivate, as described above.) Your security team can see exactly when each account was provisioned or deprovisioned.

Security boundaries

SCIM Groups never grant the Admin role

This is an explicit security boundary, not an accident. SCIM groups route exclusively through GroupManager and the groups/group_members tables. The roles table — which holds the Admin role assignment — is never touched by any SCIM operation. A SCIM group named "Admin" creates a wiki group only; it does not grant the Admin role to any member. Admin role assignment is a privileged operation done through the admin UI or directly in the database.

Lock enforcement at every login path

Deactivation only works if every login path checks it. Wikantik's database login module, the SSO login module, and the remember-me token filter all call isLocked() and refuse access for locked accounts. An attacker who obtained a valid remember-me cookie before offboarding cannot use it after the SCIM deactivation lands.

Bearer token authentication

Every request to /scim/v2/* must carry Authorization: Bearer <token>. The filter uses constant-time comparison to prevent timing attacks. Set the token in wikantik-custom.properties:

wikantik.scim.token = <a-long-random-secret>

If the token is absent, ScimAccessFilter logs a warning at startup and denies all SCIM requests with HTTP 401.

Frequently asked questions

Which IdPs work with Wikantik's SCIM endpoint?

Any IdP that supports SCIM 2.0 (RFC 7643/7644) with bearer-token authentication. Okta, Azure AD / Entra ID, OneLogin, and JumpCloud all support this standard. Point the IdP at /scim/v2/* with the configured bearer token and it will provision users and groups automatically.

Does offboarding via SCIM actually lock access immediately?

Yes. A SCIM DELETE or PATCH active=false routes through UserLifecycleService.deactivate(), which locks the account. Every login module — including the database authenticator and the remember-me token filter — checks isLocked() and refuses access for locked accounts. The account row is preserved for audit history and can be reactivated if needed.

Can a SCIM group escalate a user to the Admin role?

No. SCIM groups route exclusively through GroupManager and the groups/group_members tables. The roles table is never touched by SCIM. A SCIM group named "Admin" creates a wiki group only — it does not grant the Admin role to any of its members. Admin role assignment is a privileged operation done through the admin UI or database only.