SSO / Identity Architecture

For your security & risk team. How BareMetalRT authenticates enterprise users, maps them to least-privilege roles, provisions/deprovisions them, and how it all runs on-prem or air-gapped. Off by default

1. Supported identity providers

One standards-based RP/SP covers every compliant IdP — no per-vendor SDK.

Protocol	IdPs	Status
OIDC (primary)	Okta, Microsoft Entra ID, Auth0, PingOne, Keycloak, ADFS, Google Workspace	Authorization Code + PKCE
SAML 2.0	Okta, Entra ID, PingFederate, ADFS, Keycloak, OneLogin	SP-initiated, signed assertions
SCIM 2.0	Any IdP with a SCIM connector	Users + Groups, auto-deprovision

2. OIDC flow (primary)

Authorization Code + PKCE (S256). No implicit flow; no tokens in URLs.
Admin supplies issuer + client_id + client_secret; endpoints are auto-discovered from /.well-known/openid-configuration.
Each login carries a fresh state (CSRF) and nonce (replay), held in a short-lived HttpOnly transaction cookie and verified on callback.

ID-token validation (every login)

Signature verified against the IdP's JWKS (RS256/384/512). alg=none and HMAC algorithms are explicitly rejected — no algorithm-confusion bypass.
iss equals the configured issuer; aud contains our client_id; exp/iat enforced (60 s leeway); nonce matches the value we issued.

3. SAML 2.0 (second binding)

SP-initiated SSO; SP metadata + ACS URL exchanged with the IdP.
Assertion signature validated (XML-DSig, exclusive C14N, RSA-SHA256 only) against the configured IdP certificate before any content is trusted; unsigned assertions are rejected.
Conditions (NotBefore / NotOnOrAfter) and AudienceRestriction (must equal our SP entity ID) enforced. XML is parsed with entity resolution and network access disabled (XXE-safe).
Out of scope (documented): encrypted assertions. IdPs send signed, unencrypted assertions.

4. Role-based access control (least privilege)

Group/role claims from the IdP token map to three app roles via admin-configured rules (highest match wins; unmatched users get the default role):

Role	Can
admin	Everything: audit log, connector connect/disconnect, admin & SSO settings
user	Normal product use (default)
viewer	Read-only: no connector-connect, no admin settings

The role is stored on the user, carried in the session, and enforced server-side (require_role()) on the audit view, connector-connect, and admin/SSO settings.

5. SCIM 2.0 provisioning & deprovisioning

Endpoints: /scim/v2/Users and /scim/v2/Groups (create / read / update / deactivate), plus /ServiceProviderConfig for IdP discovery.
Authenticated with a bearer token minted on the admin page and stored hashed (SHA-256).
Deprovision is real-time: an IdP active:false (PATCH/PUT) or DELETE both flag the user inactive and revoke all their sessions, so access is cut even if a cookie is still live. The auth middleware also fails closed for inactive users.

6. Session handling

SSO logins mint the same revocable session as every other login path — one JWT + one row in the sessions table + one HttpOnly, Secure, SameSite=Lax cookie. No parallel identity store.
Sessions are revocable per-user (logout, SCIM deprovision, admin action). The session table fails closed: a token with no live session row is rejected on signature alone.
Secrets (client secret, SCIM tokens) are stored server-side only and never returned to the browser in full (redacted to a “set” sentinel).

7. On-prem & air-gap topology

SSO works wherever the orchestrator runs — including fully on your own network. The orchestrator is the OIDC Relying Party / SAML Service Provider; it talks to your IdP, not ours.

Deployment	RP/SP host	IdP
Hosted	BareMetalRT orchestrator (your tenant)	Your cloud IdP (Okta/Entra/Auth0/Ping)
On-prem	Orchestrator on your servers	On-prem Keycloak / ADFS
Air-gapped	Orchestrator inside the enclave	Keycloak/ADFS inside the enclave; OIDC discovery + JWKS and SAML cert all resolve internally — no outbound internet

GPU inference always stays on hardware you own; identity is the only added integration, and it points at infrastructure you control.

8. Data & privacy

We store only what's needed to authorize: email, name, IdP subject id, group names, role, active flag.
No IdP access/refresh tokens are persisted; the ID token / assertion is validated and discarded.
Enabling SSO never disables the local/anonymous demo or email/password paths unless you choose to.