Skip to content

Users, roles and sign-in

Edition: Community and Enterprise Offering: Self-managed

sealfix has no user database of its own. People sign in with your directory, and their roles come from the directory groups you bind.

flowchart LR
    P["Person"] -->|"password"| L["LDAP or Active Directory"]
    P -->|"single sign-on"| O["OIDC provider<br/>Keycloak, Entra ID, AD FS"]
    L --> G["Groups"]
    O --> G
    G -->|"role bindings"| R["Roles, everywhere<br/>or per project or target"]
    classDef box fill:#E9EEF6,stroke:#23407A,color:#13202D
    class P,L,O,G,R box

Connect LDAP or Active Directory

Prerequisites:

  • A read-only service account. Put its DN and password in api.env; sealfix.yaml only names the variables.
  • The directory reachable over ldaps://, or ldap:// with StartTLS.
sealfix.yaml
ldap:
  url: ldaps://dc.example.local:636
  base_dn: DC=example,DC=local
  bind_dn_env: SEALFIX_LDAP_BIND_DN
  bind_password_env: SEALFIX_LDAP_BIND_PASSWORD
  user_filter: (sAMAccountName={username})
  username_attr: sAMAccountName
  display_name_attr: displayName
  group_attr: memberOf

sealfix validates the directory's certificate and host name. To sign in, it binds as the service account, finds exactly one entry and binds as that entry with the user's password.

Plain ldap:// without StartTLS

allow_plaintext: true sends passwords unencrypted. It is meant for a lab. sealfix keeps running, and "System health" shows a warning for as long as it is set.

Group membership is read at sign-in, and read again at the moment of every approval, rejection and execution. Someone removed from the DBA group cannot approve in a session they already have.

Single sign-on with OIDC

With an oidc: section, the sign-in page offers your provider next to the password form. sealfix is a confidential client using the authorization code flow with PKCE.

Prerequisites:

  • A confidential client at your provider with the redirect URI https://<sealfix>/oidc/callback, authorization code flow only.
  • The client secret in api.env.
  • A username claim only the provider's administrators can change: upn on Entra ID, preferred_username with username editing off on Keycloak.

When LDAP and OIDC are both configured, the roles always come from the directory: a person links their provider account to their sealfix user once, and the provider's group claims are ignored.

Give roles

A role binding gives a user or a directory group one role, at one of three scopes: everywhere, a project, or one target.

sealfix bindings add --group "CN=dba-cards,OU=Groups,DC=example,DC=local" \
  --role dba_reviewer --project cards --reason "CHG-1234" --actor <admin>
sealfix bindings add --user pat --role requester --target cards-pg \
  --expires 2026-12-31T18:00Z --reason "contractor until year end" --actor <admin>

The same is available under "Admin" > "Access". A binding can expire. Every change is in the audit log.

Protect sign-in

Setting What it does
auth.mfa: privileged Sensitive actions, such as approving, need a passkey used within the step-up window
auth.step_up_minutes The step-up window, 1 to 480 minutes (default 15)
auth.passkey_sign_in Offer "Sign in with a passkey"
auth.throttle Lock an account after repeated failures (default 10 in 15 minutes), and an address after more
auth.break_glass_networks Networks from which the bootstrap administrator may sign in
auth.notice A notice shown on the sign-in page, such as an acceptable-use banner
auth.instance A banner naming this instance, styled for production or not

Troubleshooting

A user signs in but sees nothing

None of their groups is bound to a role. Check their groups with "Look up a user" in the setup wizard, then add a binding.

An approval answers 503

The directory could not be reached at the moment of the decision. Nothing changed. Try again when the directory answers.

OIDC sign-in is refused as not linked

With LDAP configured too, a provider account must first be linked to the person's sealfix user. The person links it under "Sign-in provider", signed in the usual way.