SSO and SCIM

AACsearch supports federated sign-in (SSO) and automated user lifecycle management (SCIM 2.0). Both are part of the Enterprise tier.

SSO (SAML / OIDC)

SAML and OIDC are turned on per organization. Contact sales@aacsearch.com with:

• The IdP you are using (Okta, Azure AD / Entra ID, OneLogin, Google Workspace, Ping, JumpCloud, Auth0, custom).
• Whether you want SAML 2.0 or OIDC.
• Whether you want to enforce SSO (block password sign-in) for your organization.
• The domain(s) that should resolve to your organization on the sign-in page.

We will return the metadata URL (SAML) or client configuration (OIDC) needed by your IdP. Round-trip is typically one business day.

Just-in-time provisioning

When a user signs in via your IdP for the first time, AACsearch creates the User row automatically and adds them to the organization as a member. To assign a higher role (admin, owner), either:

1. Promote them once in the dashboard (one-time), or
2. Configure SCIM group → role mapping (recurring).

JIT does not assign admin roles automatically. This is intentional — privilege escalation should not be a side effect of signing in.

SCIM 2.0

SCIM lets your IdP push user creates, updates, and deactivations into AACsearch. We implement the SCIM 2.0 core schema (RFC 7643) and protocol (RFC 7644) for Users and Groups.

Enabling SCIM

1. Organization → SCIM provisioning in the dashboard.
2. Click Generate token. Copy the bearer token (scim_…) once and save it in your IdP — only the hash is stored in our database.
3. Copy the SCIM base URL: https://app.aacsearch.com/scim/v2.
4. In your IdP, create a SCIM integration with that base URL and the bearer token.
5. (Optional) Add provisioning rules — see below.

Supported endpoints

Bearer token auth only (Authorization: Bearer scim_…). Filtering and pagination follow the SCIM protocol.

Token rotation

Tokens have no built-in expiry. Rotate them at least every 12 months:

1. SCIM provisioning → Regenerate token. The new token is returned once.
2. Update your IdP with the new token.
3. The old token is invalidated immediately.

Token regeneration is audited in the scim_audit_log — see Audit logs.

SCIM group → role mapping

By default, SCIM-provisioned users land as members. To map IdP groups to higher roles:

1. SCIM provisioning → Provisioning rules → Add rule.
2. Group name — exact match against the displayName of the SCIM Group as your IdP sends it (e.g. AACsearch Admins).
3. Target role — owner, admin, or member.
4. Deprovisioning action — what happens when a user is removed from the group:
   • suspend — disable the user but keep the row (recoverable).
   • remove — remove from the organization (one-way).
   • notify — alert an admin, do nothing automatic.
5. Enabled — set to true to activate.

Rules are evaluated in order. The highest matching role wins, so a user in both Admins and Engineering gets admin.

Audit

Every SCIM action is recorded in a dedicated scim_audit_log table separately from the main audit log. Recorded actions include config_created, token_regenerated, sync_started, user_provisioned, user_deprovisioned, group_provisioned, and their failure variants. See Audit logs.

Common mistakes

• No break-glass account. Always keep one account with password + 2FA outside SSO. If your IdP outage coincides with an AACsearch incident, you still need to sign in.
• Mapping a "default" group to admin. Group → role mapping should follow real responsibility. A Everyone → admin rule defeats the point.
• Skipping deprovisioning. Without a suspend or remove action, an offboarded employee still has dashboard access. Test deprovisioning by removing yourself from the IdP group.
• Rotating the SCIM token without updating the IdP. Sync stops silently; the audit log will show sync_failed. Schedule the IdP update in the same change window as the rotation.

See also

• API keys — separate auth path for programmatic access
• Audit logs — scim_audit_log rows live here
• Enterprise overview — the tier that includes SAML/OIDC and SCIM