Single sign-on and team access

In preview

Let people sign in with your identity provider over OIDC or SAML, keep the panel's own second factor and break-glass rules, and invite team members who can touch only what you share with them.

Built and lab-tested

  • OIDC with the authorisation code flow and PKCE. The token is fully validated: issuer, audience, expiry, not-before, nonce, signature, and the algorithm confusion tricks (none, HS256 with the public key) are refused. 14 attack tests ran against a lab identity provider.
  • SAML 2.0: a response is validated against the provider's pinned certificate, and the person and attributes are read only from the element that was verified. Redirect request and POST response, metadata import and download, certificate rollover and a Test sign-on. In the lab, 24 of 24 forged or altered responses were refused with no session cookie.
  • A person is found by provider and subject, never by email. A provider that asserts a local person's verified email takes nothing over, with just-in-time creation on or off.
  • Just-in-time creation only when you switch it on. Nobody becomes an administrator from a claim unless you switch that on, and a reseller's provider cannot grant it.
  • The panel's second factor still applies, step-up needs a fresh authentication of the same person, and "SSO required" never applies to administrators, who always keep a local way in.
  • Sign-in alerts for a new device, a failure burst, a new country and impossible travel, with a "this was not me" answer by email or from the device list. Country and travel alerts use an offline country database (DB-IP Lite, CC BY 4.0) that the server fetches through its outbound guard; lab-proven with a fixture.
  • Team: an account owner invites sub-users scoped to chosen resources, with an expiry. A Team member's lists are filtered in the query, and Team isolation held against every attempt in the QA walk.
  • Passkeys, authenticator codes and recovery codes for everyone who signs in with a password, and two-step sign-in required for administrators and resellers.

Not there yet

  • SAML encrypted assertions (refused with a message), signed requests, single logout and artifact binding.
  • The replay of a valid SAML response is covered by unit tests, not by the lab replay.
  • SCIM, and deprovisioning of linked people who were not created just in time. A person created just in time has no plan or limits until you assign one.
  • The alert emails were proven by tests, not in a browser.

Where you set it up

An administrator adds a provider on the Single sign-on page, with a Test sign-on before anyone depends on it. People link or unlink their own sign-in under Security.

Who may do what

Roles and grants are the same ones every other sign-in uses, so single sign-on adds a way in, not a way around the permissions. A provider run by a reseller cannot grant administrator rights.

Every action in this area is in the panel, one keystroke away in the command palette (Ctrl K), on the command line and in the API, and most changes can be previewed as a plan first. Built and tested in our lab; RespireCloud is not released yet.

Modules in this area