Skip to main content

SSO & SCIM

DriftWise supports SAML-based Single Sign-On and SCIM user provisioning via Casdoor as the identity broker. SSO is available on Team and Enterprise plans; SCIM requires Enterprise. For endpoint shapes see the sso tag of the API reference.

Setting up SAML SSO

1. Get your IdP metadata

From your identity provider (Okta, Azure AD, Google Workspace, etc.), obtain:

  • IdP Metadata URL — the SAML metadata endpoint
  • IdP Entity ID — the issuer identifier

2. Configure in DriftWise

The fastest path is the SSO section of the Settings tab in the dashboard. The underlying PUT /orgs/:id/sso-config endpoint proxies the write to Casdoor and requires OIDC authentication with owner or admin role — API keys are rejected outright. Swapping the SAML IdP metadata URL intercepts every subsequent login, so the mutation must be attributable to a specific human in the audit log.

The audit entry includes the new idp_entity_id (safe public identifier) but deliberately excludes the metadata URL, which can contain credentials or signed query strings.

3. Configure your IdP

Point your identity provider's SAML app to DriftWise's service provider. DriftWise uses Casdoor as the SAML service provider, so the ACS URL and SP entity ID are Casdoor-hosted values specific to your org. Both are shown in the Settings > SSO panel after you save an IdP configuration; contact support if you need them before first setup.

IdP fieldValue
ACS URLCasdoor-hosted SP endpoint (shown in Settings > SSO)
Entity IDCasdoor-hosted SP entity ID (shown in Settings > SSO)
Name ID formatEmail (Casdoor default)

Viewing current config

The read endpoint returns enabled: false (not 404) when no provider is configured yet, so callers always get a well-formed response. The scim_endpoint field appears only when your plan includes SCIM; the dashboard hides SCIM setup UI automatically when the field is absent.

SCIM provisioning

SCIM automates user lifecycle management in your DriftWise identity tenant — when users are created or deactivated in your IdP, those changes flow through to DriftWise's identity broker (Casdoor) without manual intervention.

SCIM is served by Casdoor; the endpoint URL is returned in the SSO config response as scim_endpoint. Configure that URL — plus a bearer token generated in your Casdoor org settings — in your IdP's SCIM provisioning settings.

What SCIM covers today:

  • User provisioning — users created via SCIM appear in your DriftWise identity tenant and can sign in via SSO. Assigning the user to a DriftWise org (and choosing their role) is still done in the DriftWise admin UI.
  • User deactivation — users deactivated via SCIM lose the ability to sign in. Existing org_memberships rows are not auto-removed; revoke them explicitly in the admin UI if required by your offboarding policy.
  • Audit trail — every SCIM user and group event (provision, update, deprovision) is recorded in admin_audit_log so auditors have a chained record of IdP-driven identity changes.

Group-to-role mapping is not yet implemented; group events are audited but do not mutate DriftWise org membership roles.

info

SCIM is available on the Enterprise plan only. Team-plan SSO config responses omit the scim_endpoint field entirely, and the dashboard hides SCIM setup UI automatically.

Federation info

Platform admins can retrieve OIDC federation details for configuring cloud provider trust. The endpoint is at GET /api/v2/federation-info — outside /admin/ but gated by the same platform-admin middleware, and OIDC-only (API keys return 403).

The response carries issuer_url, subject, audience, and service_account_email. Use these values when setting up OIDC Federation trust policies in AWS, GCP, or Azure.

The endpoint returns 503 when the server was booted without federation config — nothing to hand out.

Plan requirements

FeatureTeamEnterprise
SAML SSOYesYes
SCIM provisioning-Yes

Requests to SSO endpoints on the Free plan return 402 Payment Required with the canonical PaymentRequiredResponse body.

Endpoint reference

SSO config endpoints are under the sso tag of the API reference. Federation info is documented under the admin tag since it's platform-admin-gated.