OIDC / SSO overview¶
Federated sign-in is configured per identity provider on the Identity Providers page in your dashboard, alongside local accounts - not instead of them. This page covers the concepts that apply to any provider; for a concrete walkthrough see Microsoft Entra ID setup.
CertIntel's own two-factor sign-in applies only to local password accounts. Users who sign in through an identity provider are exempt, even when the workspace requires two-factor sign-in: the provider is responsible for their second factor, so enforce MFA in its conditional access or sign-in policy.
Provider types¶
A provider's shape is fixed permanently at creation:
- Tenant-wide - no fixed organization. Its mapped roles may grant an
all-organizations role, tenant administration, or a specific organization's role.
Users enter via the provider's Login link (
/login?sso=<slug>, shown on the Identity Providers page) or via the shared login page's email-domain discovery. - Organization - bound to exactly one organization. Every user who signs in through it lands in that organization and only that one, regardless of what their token asserts. Never named on the shared login page.
When you create a provider with an organization selected in the dashboard's top bar, the form pre-selects that organization and defaults the type to organization; choose tenant_wide to create a tenant-wide provider instead (the organization picker is then disabled, because a tenant-wide provider must not name an organization).
The core invariant
Which tenant / organization a federated user belongs to is decided by which provider connection authenticated them, never by a claim inside their own token. A compromised identity provider can assert anything about a user; it can never talk its way outside the connection it came through.
Role mapping is default-deny¶
Each provider has a role claim (default roles) and a table of role
mappings, each pairing one value your provider asserts to one CertIntel role. A
login whose claim values match none of the mappings is refused, and nothing
is provisioned unless the provider has a Fallback role. The fallback role
(Edit configuration & role mappings, default Deny sign-in) is granted
only when the token carries no mapped claim value: across all organizations
for a tenant-wide provider, or in that organization for an organization
provider. It can never grant tenant or platform administration. Role
assignment is fully resynced on every login: removing someone from a mapped group in your IdP removes the
corresponding CertIntel role at their next sign-in.
The CertIntel.* claim convention¶
Beyond the explicit mapping table, these claim values are recognised automatically. Keep each claim value in your identity provider consistent with its use in CertIntel.
| Claim value | Grants |
|---|---|
CertIntel.TenantWide.Administrator |
Administrator across all orgs + tenant administration |
CertIntel.TenantWide.<Role> |
that built-in role across all organizations |
CertIntel.AllOrgs.<Role> |
that built-in role across all organizations, without tenant administration |
CertIntel.Org.<org-id-or-slug>.<Role> |
that built-in role in the named existing organization only |
<Role> is a built-in role's name with the spaces removed: Administrator,
Operator, Observer, Viewer, Auditor, AlertManager, CertificateIssuer,
DNSDelegationManager. A custom role has no automatic claim spelling; map a
claim value to it with an explicit mapping row on the Identity Providers page,
which lists custom roles alongside the built-in ones.
The Identity Providers page pre-fills the default mapping rows for the tenant tiers when you create a provider.
Disabling a federated user doesn't depend on your IdP¶
The disabled flag on a user account is deliberately never resynced from the
provider. It is the one lever an administrator has to immediately cut off a
federated account from the Users page without directory-admin access to that
organization's identity provider.
Disabling an identity provider also invalidates sessions created through that provider. Its existing sessions cannot continue after the provider is disabled; users need an enabled sign-in method. Local administrator access remains a separate way to manage the configuration.
Single logout¶
Signing out ends the local session, then - for a federated session - redirects the
browser through the provider's own end-session endpoint (RP-initiated logout). This
is a hard requirement: a provider whose discovery document has no
end_session_endpoint is refused at configuration time, not silently degraded.
The Redirect URI, Back-channel logout, Front-channel logout,
Login link and End-session values are shown on the Identity Providers
page once you create a provider; use whichever logout form your provider
supports.
Provider-initiated logout is honoured only when it can be tied to the right provider:
- Front-channel requests must carry both
sidandiss, andissmust equal the provider's configured Issuer byte for byte. Otherwise the page still says You have been signed out. but the CertIntel session is left untouched. - Back-channel logout tokens must be signed with RS256, PS256 or ES256, carry
iat,jti, the back-channel-logouteventsclaim andsuborsid, and must not carrynonce. Issuer and audience must match the provider.
Sign-in starts, callbacks and back-channel logout requests are rate-limited per
address and per provider; an excess returns 429 with Too many OIDC sign-in
starts. Try again later. (or the callback/logout equivalent) and a Retry-After
header.
What you'll need, for any provider¶
- Discovery URL (
https://.../.well-known/openid-configuration), which must behttps://. CertIntel reads the issuer from the document and shows it on the provider card; there is no separate Issuer field. The discovery host must resolve to a public address (private, loopback and carrier-grade NAT ranges are refused with URL host is not allowed), and the document must be plain, uncompressed JSON under 1 MiB with every required field present. - Client ID and Client secret - the secret is encrypted at rest (not hashed; it is replayed to the provider at every sign-in).
- Role claim and role mappings.