Security

Identity and SSO

How SSO, MFA, person context, assignment, and session decisions stay separate in CerberusD.

Page type: SecurityIdentity and SSOStatus: CurrentCurrent product behaviorLast reviewed: 2026-07-02

Sign-in to the CerberusD panel uses SSO through the managed identity provider. The managed sign-in policy requires a second factor; password and second-factor verification stay with the identity provider.

This page covers only how sign-in identity enters the product. Resource assignment and session authorization belong to Identity, scope, and assignment.

What the person sees

  1. The person starts CerberusD sign-in.
  2. The identity provider verifies the account and completes the second factor.
  3. The successful return is matched to the person and workspace context in CerberusD.
  4. The panel opens the product areas visible to that context.
  5. A resource-session request triggers a separate assignment and session decision.

The SSO session is not used as a universal key for every resource. Panel identity and resource-session authorization remain separate decisions.

Identity-provider responsibility

The identity provider owns:

  • password verification,
  • second-factor enrollment and verification,
  • sign-in policy,
  • account activity state,
  • identity-provider session lifecycle.

CerberusD maps the verified person context to workspace membership and product responsibilities. Changes to user or group lifecycle require the identity source and CerberusD mapping to stay current.

When access changes

A role or resource-assignment change affects the next resource decision. Closing an already active work surface also requires an active-session action. Revocation and evidence treats these as separate operations.

Reviewable identity context

The identity record shows the person, workspace context, sign-in time, and identity result carried into the access decision. Target-resource passwords and second-factor secrets stay outside these records.