Identity & SSO
Premora issues its own tokens — there is no separate IdP product to run. A built-in token issuer verifies the sign-in method, then mints RS256 JWT access/refresh tokens and publishes the JWKS the gateway verifies. The model mirrors what enterprise admins already expect from self-managed GitLab/Bitbucket/Jira.
The bootstrap sequence
- Install → local admin. First-run bootstrap creates a DB-backed admin that exists before any SSO, and is permanent break-glass — a broken IdP can’t lock everyone out.
- Admin configures SSO once, after bootstrap, in Admin → Authentication.
- Users sign in via the IdP. First login maps IdP groups → Premora scopes, and membership in the designated admin group maps to an admin token.
Supported methods
| Method | Notes |
|---|---|
| Local accounts | Username/password verified against the local store. The break-glass admin. |
| OIDC / Microsoft Entra | Standard OpenID Connect; Entra ID supported directly. |
| SAML 2.0 | Premora acts as the SAML Service Provider. |
| LDAP / Active Directory | Direct bind against your directory. |
Group → scope mapping
Map your IdP’s groups to Premora scopes, and designate which group grants admin access. On first login a user’s group membership is translated into Premora scopes; membership in the admin group yields an admin token.
Security properties
- Live-applied config. SSO configuration lives in central runtime config and applies to the issuer without a restart.
- Write-only secrets. IdP secrets are never returned on read.
- Cryptographic verification. Every SSO token is verified — no blind trust.
- Scope filtering. Minted scopes are filtered to the known catalog.
- Fails closed. SSO fails closed when misconfigured, so a bad config denies access rather than granting too much.
See Access control for how scopes govern what users and agents can do, and Runtime configuration for how admin settings apply live.