Skip to content
ABRQ DATADocs Abrq DIP · latest
Product page Request a trial
On this page

Authentication Providers

Overview#

Settings → Authentication holds two provider registries, both admin-only:

  • Single sign-on — OIDC providers (Okta, Azure AD, Google Workspace, Keycloak, and other OpenID Connect identity providers).
  • LDAP / Active Directory — direct-bind providers for on-prem directories.

Local username/password login always remains available alongside any providers you add. How the resulting sessions, tokens, and refresh flow work is covered in Authentication.

For both kinds, the provider's configuration — including the OIDC client secret or the LDAP bind password — is stored as one encrypted blob in the platform's secrets store, sealed with the master key. Secrets are write-only: the API and UI never return them; editing a provider without re-entering the secret keeps the stored one.

SSO (OIDC) providers#

Creating a provider#

  1. In the Single sign-on card, select New provider.
  2. Fill in:
    • URL slug — unique, lowercase (a-z0-9_-), fixed after creation. It appears in the login URL and the callback path.
    • Display name — the label users see on the login page.
    • Issuer — the OIDC discovery base URL of your identity provider.
    • Client ID and Client secret — from the application you registered at the identity provider.
    • Scopes — space-separated; defaults to openid email profile.
    • Default role for new users — viewer, editor, or admin; applied when a user is provisioned on first login (default viewer).
    • Allowed email domains — comma-separated; blank allows any domain.
  3. Select Create.

Callback URL#

When registering the application at your identity provider, set the redirect (callback) URL to:

https://<YOUR_DIP_HOST>/sso-callback/<PROVIDER_SLUG>

The browser is redirected there after the identity provider authenticates the user, and the page completes the login against the DIP API.

Group-to-role mapping#

Beyond the default role, the provider config accepts a groups_claim (which ID-token claim carries the user's groups; default groups) and an ordered group_role_mappings list of {group, role} pairs — the first exact match wins, and a user matching no mapping gets the default role. These two fields are set through the API (POST / PATCH /api/v1/sso-providers); the create dialog covers the common fields listed above.

Enabling, editing, deleting#

  • The Status switch enables or disables a provider; only enabled providers appear on the login page.
  • Edit changes the display name, and pushes a new config only when you re-enter the client secret (it is never shown back).
  • Delete removes the provider. Sessions already issued remain valid until they expire.

LDAP / Active Directory providers#

Creating a provider#

  1. In the LDAP / Active Directory card, select New provider.

  2. Fill in:

    • URL slug and Display name — as for SSO.

    • Server URI — for example ldaps://dc1.corp.example:636 or ldap://dc1.corp.example.

    • Bind DN and Bind password — a service account used for the user search and the connection test. The password is write-only.

    • User search base — the base DN under which login names are searched, for example OU=Users,DC=corp,DC=example.

    • User filter — an LDAP filter template where {username} is substituted (safely escaped) with the submitted login name. The default is Active Directory native: (&(objectClass=person)(sAMAccountName={username})); OpenLDAP deployments typically use uid instead.

    • LDAPS and/or StartTLS — transport security options.

    • Group mappings — one mapping per line, <GROUP_DN> = <ROLE>:

      CN=DIP-Admins,OU=Groups,DC=corp,DC=example = admin
CN=DIP-Analysts,OU=Groups,DC=corp,DC=example = viewer

  3. Use Test connection to probe the server with the entered config — nothing is persisted by the test, and the bind password is never echoed back.

  4. Select Create.

The API additionally accepts ordered failover_uris — alternate server URIs tried in turn when the primary fails to connect.

Role mapping is deny-by-default#

LDAP group mapping has no default role. Mappings are evaluated in declared order against the group DNs on the user's directory entry; the first exact match assigns the role. A user whose bind succeeds but who matches no mapping is refused login — a loud, audited refusal (the LdapNoGroupMapping failure) rather than a silent fallback.

Warning. An LDAP provider with an empty group-mapping list means no user can log in through it. Map at least one group before enabling the provider, and keep group DNs exact — matching is not substring-based.

Enabling, editing, deleting#

Same model as SSO: a Status switch, an Edit dialog that only pushes config when the bind password is re-entered, and Delete. A persisted provider can also be re-tested at any time from its row.

Audit trail#

Provider creation, updates, deletion, SSO logins, and denied LDAP logins are all audited. See Audit.