Single Sign-On
DAAM supports enterprise identity management through OIDC and SAML 2.0. You can configure multiple identity providers per organization with JIT provisioning, group sync, and SCIM 2.0 user/group lifecycle management.
Overview
The identity provider framework lets you delegate authentication to your existing IdP (Okta, Azure AD/Entra ID, Google Workspace, OneLogin, or any standards-compliant provider). Key capabilities:
- Multiple providers per org — configure separate providers for employees (OIDC) and contractors (SAML) simultaneously.
- JIT provisioning — user accounts are created automatically on first SSO login. No pre-registration required.
- Group sync — IdP group memberships map to DAAM groups, driving policy assignments automatically.
- SCIM 2.0 — push user and group lifecycle changes from your IdP in real time, without waiting for login.
- Session termination — back-channel logout (OIDC) and SLO (SAML) revoke DAAM sessions when users are signed out of the IdP.
Your existing SSO credentials work - no separate DAAM passwords to manage. IdP tokens are never shared with agents.
When Force SSO is enabled on the organization, local password authentication is disabled. The login page hides the password form and shows only SSO options. At least one identity provider must be configured before Force SSO can be enabled.
Provider Configuration
All identity providers share these settings, regardless of protocol:
| Setting | Default | Description |
|---|---|---|
slug | — | URL-safe identifier (lowercase alphanumeric + hyphens, 3-50 chars, unique per org) |
display_name | — | Human-readable name shown on the login selection page and in the admin console |
enabled | true | Soft-enable or disable the provider without deleting configuration |
auto_provision | true | Create user accounts automatically on first SSO login (JIT provisioning) |
allowed_domains | All | Restrict authentication to specific email domains |
default_role | member | Role assigned to JIT-provisioned users (member or admin) |
sync_group_membership | false | Sync IdP group claims to DAAM groups on each login |
remove_unmatched_groups | false | Remove user from IdP-managed groups not present in the current login's claims |
Setting default_role to admin with auto-provisioning enabled grants admin access to every user who authenticates for the first time. This requires explicit confirmation during setup to prevent accidental mass-provisioning of admin accounts.
OIDC Setup
OIDC (OpenID Connect) is the recommended protocol for most identity providers.
Adding an OIDC Provider
- In the console, navigate to Settings and click Identity Providers.
- Click Add Provider and select OIDC as the protocol.
- Enter a slug (e.g.
corp-okta) and a display name (e.g. "Corporate Okta"). - Enter the Issuer URL from your IdP (e.g.
https://your-org.okta.com). DAAM uses OIDC Discovery to automatically fetch endpoints and signing keys. - Enter the Client ID and Client Secret from the application you created in your IdP.
- Optionally adjust scopes (default: openid, email, profile). Add the groups scope if you plan to use group sync.
- Click Save.
Configuring Your IdP
When creating the OIDC application in your IdP, configure the following:
| IdP Field | Value |
|---|---|
| Sign-in redirect URI | https://app.daam.dev/api/v1/auth/oidc/callback |
| Sign-out redirect URI | https://app.daam.dev/console/login |
| Application type | Web application |
| Grant types | Authorization Code |
Back-Channel Logout
If your IdP supports OIDC back-channel logout, configure it to send logout tokens to:
https://app.daam.dev/api/v1/auth/oidc/backchannel-logout
When a user signs out of the IdP, DAAM automatically revokes their admin sessions, CLI refresh tokens, and terminates active database connections.
SAML Setup
SAML 2.0 is supported for IdPs that do not offer OIDC or for organizations with existing SAML infrastructure. DAAM acts as a SAML Service Provider (SP).
Adding a SAML Provider
- In the console, navigate to Settings and click Identity Providers.
- Click Add Provider and select SAML as the protocol.
- Enter a slug (e.g.
contractor-azure) and a display name. - Upload your IdP's metadata XML, or manually enter the Entity ID, SSO URL, and certificate(s).
- Optionally enable IdP-initiated SSO to accept unsolicited SAML responses from your IdP.
- Optionally enable SP request signing and upload the SP certificate and private key.
- Click Save.
Required SAML Configuration
| Field | Required | Description |
|---|---|---|
| IdP Entity ID | Yes | The IdP's SAML entity identifier (from IdP metadata) |
| IdP SSO URL | Yes | Single Sign-On Service URL (HTTP-Redirect binding) |
| IdP Certificate(s) | Yes | PEM-encoded X.509 certificates for signature verification (multiple supported for rotation) |
| IdP SLO URL | No | Single Logout Service URL for IdP-initiated logout |
| NameID Format | No | Defaults to email address format |
| Allow IdP-initiated SSO | No | Accept unsolicited SAML responses (default: off) |
Configuring Your IdP
Download DAAM's SP metadata to configure your IdP. The metadata URL for each SAML provider is:
https://app.daam.dev/saml/your-provider-slug/metadata
This metadata contains the SP Entity ID, Assertion Consumer Service (ACS) URL, and signing certificate (if configured). Import this into your IdP to complete the SAML trust relationship.
| IdP Field | Value |
|---|---|
| ACS URL | https://app.daam.dev/saml/your-provider-slug/acs |
| SP Entity ID | https://app.daam.dev/saml/your-provider-slug/metadata |
| NameID Format | Email Address |
Certificate Rotation
DAAM supports multiple IdP certificates to allow seamless rotation. When validating a SAML response, DAAM tries each certificate until one validates the signature. Add the new certificate before removing the old one to avoid authentication failures during the transition.
Single Logout (SLO)
If your IdP supports Single Logout, configure the SLO URL to receive logout requests. When a user signs out of the IdP, DAAM automatically revokes their admin sessions, CLI refresh tokens, and terminates active database connections.
SCIM Provisioning
SCIM (System for Cross-domain Identity Management) 2.0 lets your IdP push user and group lifecycle changes to DAAM in real time. SCIM is complementary to SSO authentication:
| Concern | SSO (OIDC/SAML) | SCIM |
|---|---|---|
| Purpose | Authentication (who are you?) | Provisioning (who exists?) |
| Direction | User-initiated (login flow) | IdP-initiated (push) |
| User lifecycle | JIT on first login | Pre-provisioned before login |
| Group sync | On login via group claims | Real-time via IdP push |
| Deprovisioning | None (user remains until manual action) | Immediate on IdP removal |
Enabling SCIM
- In the console, navigate to Settings and click Identity Providers.
- Select the identity provider you want to enable SCIM for (OIDC or SAML).
- Toggle Enable SCIM in the provider settings.
- Click Generate Token to create a bearer token. Copy the token — it is shown only once.
- In your IdP's SCIM configuration, enter the endpoint URL and bearer token.
SCIM Endpoint
Configure your IdP's SCIM client with the following endpoint:
https://app.daam.dev/scim/v2/
Authentication uses the bearer token generated above. Multiple active tokens per provider are supported to allow rotation.
What SCIM Manages
- User provisioning — creates DAAM accounts when users are assigned in the IdP, before they log in.
- User deprovisioning — suspends DAAM accounts and revokes sessions when users are removed from the IdP.
- User updates — syncs email changes from the IdP to DAAM.
- Group provisioning — creates DAAM groups matching IdP groups.
- Group membership sync — adds and removes group members in real time as IdP assignments change.
SCIM is always paired with an identity provider — there is no standalone SCIM configuration. SCIM tokens, identities, and group mappings are all scoped to a specific provider. Deleting a provider cascades to all its SCIM data.
JIT Provisioning
Just-In-Time (JIT) provisioning creates user accounts automatically when someone authenticates via SSO for the first time. This is the default behavior when auto_provision is enabled.
How JIT Works
When a user logs in via SSO for the first time, their account is automatically created and linked. If a DAAM account with a matching verified email already exists, the IdP identity is linked to the existing account. Email verification is required to prevent unauthorized account linking.
Disabling JIT Provisioning
Set auto_provision to false to require that users already have DAAM accounts before they can authenticate via SSO. This is useful when you want SCIM to control user lifecycle and only allow pre-provisioned users to log in.
Group Sync
Group sync automatically maps IdP group memberships to DAAM groups on each login. This drives policy assignments without manual intervention — when a developer joins a team in the IdP, they automatically receive the correct database access.
Setting Up Group Sync
- Enable Sync group membership on the identity provider.
- Configure the group claim name (default: "groups"). For OIDC, this is the ID token claim. For SAML, this is the SAML attribute name.
- Create group mappings that link IdP group names to DAAM groups. Navigate to the provider's settings and add mappings (e.g. IdP group "Engineering" maps to DAAM group "Backend Team").
- Optionally enable Remove unmatched groups to remove users from IdP-managed groups they no longer belong to.
How Sync Works
On each SSO login:
- DAAM extracts group names from the IdP token or assertion.
- Group names are resolved against the configured mappings. Unknown group names are silently ignored.
- DAAM computes the difference between the user's current IdP-managed memberships and the mapped groups.
- New memberships are added and stale memberships are removed (if remove_unmatched_groups is enabled).
- If any groups changed, policies are recomputed and pushed to connected agents immediately.
Group memberships from SSO sync and manual assignments are tracked independently, so automated sync never overrides your manual admin decisions.
Session Management
DAAM supports federated session termination to ensure that signing out of the IdP also signs out of DAAM. This is critical for compliance — when IT disables an account in the IdP, that user should immediately lose database access.
How Session Termination Works
When a user is deactivated or signs out of your IdP, their DAAM sessions and active database connections are terminated. This includes console sessions, CLI sessions, and live agent connections.
DAAM supports OIDC back-channel logout and SAML SLO for automatic session termination when users sign out of your IdP.
Multiple Providers
Organizations can configure multiple identity providers simultaneously. This supports scenarios like employees using corporate OIDC while contractors authenticate via a separate SAML provider.
Provider Selection
When multiple providers are enabled, DAAM determines which one to use:
- Single provider — auto-redirect to that provider.
- Default provider set — auto-redirect to the default provider.
- No default — show a selection page listing all enabled providers with their display names and protocol badges.
The CLI can specify a provider slug directly to skip the selection page. If omitted, the CLI follows the same auto-detection logic.
Deleting a Provider
Deleting a provider removes all associated data including identity links, group mappings, SCIM tokens, and auth states. Users who were provisioned via the deleted provider retain their DAAM accounts but must authenticate via another provider or local password.