Organization SSO

The SSO page (Control > SSO in the organization sidebar) is the single place an MSSP configures single sign-on - both for its own admins signing in to the organization console, and for each managed tenant's users, without ever switching into the tenant. Both use the same provider editor and support OIDC and SAML 2.0.

This page is about organization-scope administration. A tenant's own administrators manage their SSO from the tenant dashboard instead - see tenant-level SSO.

Screenshot

[SCREENSHOT PLACEHOLDER: The SSO page showing the "Require SSO for org admins" card, the "Organization sign-in providers" card with one enabled OIDC provider, and the "Managed tenants" card with collapsed tenant rows.]

How it works

The page has two sections that differ in who gets authenticated:

Section	Who signs in	Where the IdP redirects	Role handling
Organization sign-in providers	Your org admins, into this console	This console's own domain	None - admins are matched by verified email and are never auto-created
Managed tenants	A managed tenant's users, into that tenant's dashboard	That tenant's own login domain	Optional role mapping and auto-create on first login

All changes on this page are restricted to the organization owner role, and every create, update, or delete first asks you to confirm your identity (your password, or a re-verification through your own SSO session). Secrets - the OIDC Client Secret and the SAML SP Private Key (PEM) - are write-only: they are never displayed again after saving, and leaving them blank while editing keeps the stored value.

Require SSO for org admins

The Require SSO for org admins card enforces SSO-only sign-in for the organization console: when enabled, password sign-in for org admins is refused. Two guard rails prevent lockout:

• You can only enable it once at least one organization sign-in provider is enabled.
• While it is enabled, you cannot delete the last enabled provider (the delete button is disabled with the hint "Disable Require SSO before deleting the last enabled provider").

Using the page

The provider editor

Selecting Add provider (or the edit pencil) in either section opens the same editor:

• Protocol - choose OIDC or SAML.
• Provider Template (OIDC, when creating) - quick-fill buttons for Keycloak, Entra ID, Okta, Google, Auth0, or Custom. Templates pre-fill sensible defaults; your connection fields are never overwritten.
• Name - a label such as Okta or Entra ID SAML.

For OIDC:

• Issuer URL, Client ID, Client Secret (write-only).
• Test OIDC Discovery - checks the issuer's discovery document before you save.
• Under Advanced settings: Email claim, Name claim, Scopes, and Redirect URL ("Must match the redirect URI registered with the IdP").

For SAML:

• IdP Entity ID / Issuer, plus an IdP source: IdP Metadata URL or IdP Certificate (PEM).
• SP Entity ID, Email attribute, Name attribute, optional SP Certificate (PEM) and SP Private Key (PEM) (write-only), and an Allow IdP-initiated SSO checkbox.

Common toggles: Enabled and Primary provider.

Field summary by protocol:

	OIDC	SAML
Identity source	Issuer URL	IdP Entity ID / Issuer + IdP Metadata URL or IdP Certificate (PEM)
Credentials	Client ID, Client Secret (write-only)	SP Certificate (PEM), SP Private Key (PEM) (write-only)
User attributes	Email claim, Name claim	Email attribute, Name attribute
Roles (managed tenants only)	Role claim path	Roles attribute
Connection test	Test OIDC Discovery	Validated on save

Reading the provider list

Each configured provider appears as a row showing its name, a protocol badge (OIDC or SAML), a Primary badge where set, an Enabled/Disabled indicator, the issuer URL, and the client ID. Secrets are never shown. Use the pencil to edit and the trash icon to delete - both prompt for re-authentication.

Organization sign-in providers

These providers authenticate your org admins to this console. There is no role mapping here: an incoming identity must match an existing org admin by verified email, and accounts are never created automatically - so provision the admin in Admins & Access first.

Register these endpoints with your IdP, on this console's domain:

• OIDC redirect (callback) URI: https://<this-panel>/api/v1/org/auth/sso/callback
• SAML ACS / reply URL: https://<this-panel>/api/v1/org/auth/saml/callback
• SAML SP metadata: https://<this-panel>/api/v1/org/auth/saml/metadata

Managed tenants

Expand a tenant row (Manage SSO) to see and edit that tenant's providers. The editor gains the role-mapping controls:

• Role claim path (OIDC) / Roles attribute (SAML) - where in the token/assertion the user's roles live.
• Default role - assigned when no IdP role matches (e.g. viewer).
• Auto-create users on first login - create tenant users automatically on their first successful SSO sign-in.

One thing is deliberately different here: the IdP must redirect back to the tenant's own login domain, not this org console. Register with the tenant's IdP:

• OIDC callback: https://<tenant-domain>/api/v1/auth/sso/callback
• SAML ACS: https://<tenant-domain>/api/v1/auth/saml/callback
• SAML SP metadata: https://<tenant-domain>/api/v1/auth/saml/metadata

The Redirect URL field is intentionally left blank when creating a tenant provider so you enter the tenant's callback rather than the org console's.

Screenshot

[SCREENSHOT PLACEHOLDER: The provider editor open for a managed tenant, showing the Provider Template buttons, OIDC fields, and the role-mapping controls (Role claim path, Default role, Auto-create users on first login).]

Worked example: Entra ID for org admins, Okta for a tenant

An MSSP wants its analysts to sign in to the org console with Microsoft Entra ID, and its customer Fabrikam to use Okta.

Org sign-in with Entra ID:

1. Under Organization sign-in providers, select Add provider, pick the Entra ID template, and enter your tenant's Issuer URL, Client ID, and Client Secret from the Entra app registration. Register the console callback URL shown on the page as the app's redirect URI.
2. Select Test OIDC Discovery to confirm the issuer resolves, then Create provider and confirm your identity when prompted.
3. Sign out and back in via SSO to prove it works, then on Require SSO for org admins select Require SSO. Password sign-in for org admins is now refused.

Fabrikam with Okta:

1. Under Managed tenants, expand Fabrikam and select Add provider with the Okta template.
2. Enter the Okta issuer, client ID, and secret; in Okta, register https://<fabrikam-domain>/api/v1/auth/sso/callback as the redirect URI, and set the same value in Redirect URL under Advanced settings.
3. Under Advanced settings, leave Role claim path as groups, set Default role to viewer, and keep Auto-create users on first login ticked so Fabrikam staff are onboarded on first sign-in.
4. Select Create provider and confirm your identity.

Fabrikam users now sign in on their own tenant domain through Okta; your admins never had to switch into the tenant to set it up.

Video

[VIDEO PLACEHOLDER: End-to-end setup of an organization sign-in provider - add provider from a template, test discovery, save with the re-authentication prompt, then enable "Require SSO".]

Troubleshooting and FAQ

My admin can't sign in through org SSO. Org sign-in never auto-creates accounts. The admin must already exist in the organization with the same verified email the IdP asserts.

The Save/Add buttons are missing. Only an organization owner can edit SSO; other org roles see the page read-only.

I edited a SAML provider and the IdP metadata field looks empty. Stored metadata and secrets are not echoed back into the form. Leaving those fields blank on edit keeps the stored values; only fill them to replace them.

Test OIDC Discovery fails. The Issuer URL must be the exact issuer your IdP publishes (the address that serves its OIDC discovery document). Copy it from the IdP's application configuration rather than typing it - a trailing path or wrong host makes discovery fail.

Tenant users land with the wrong role. Check the Role claim path (OIDC) or Roles attribute (SAML) against what your IdP actually puts in the token or assertion. When no asserted role matches, the Default role is applied - so users unexpectedly showing up as viewer usually means the roles are not where the configuration is looking.

Can I require SSO before adding a provider? No - the Require SSO button stays disabled until at least one organization provider is enabled, so you cannot lock yourself out.

Can I configure more than one provider? Yes - both sections support multiple providers, each with its own Enabled toggle, so you can stage a new IdP alongside the old one and cut over by flipping which is enabled.

Which roles can Default role assign? The selector offers super_admin, admin, analyst, executive, and viewer. Pick the least-privileged role that makes sense as a landing default; IdP role mapping can elevate specific users.

Does configuring tenant SSO here differ from doing it inside the tenant? It is the same configuration, managed centrally. Tenant admins can still see and manage it from their own dashboard - see tenant-level SSO.

All SSO changes are recorded in the organization Audit Log.