Skip to content

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 sid and iss, and iss must 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-logout events claim and sub or sid, and must not carry nonce. 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 be https://. 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.