Identity & Access — overview

Claresia delegates identity to your IdP. We never store your users’ passwords. Login goes through WorkOS, which abstracts over Okta / Azure AD / Google Workspace / generic SAML / OIDC. SCIM 2.0 handles user lifecycle.

What ships on day 1

Feature	Status
SAML 2.0 SSO (Okta, Azure AD, Google, generic)	GA
OIDC SSO (Okta, Azure AD, Google, Keycloak, generic)	GA
SCIM 2.0 user lifecycle	GA
Group-based RBAC (group → archetype mapping)	GA
Immediate de-provision on IdP user removal	GA
MFA enforcement (delegated to IdP conditional access)	GA
Domain allowlisting	GA
Audit log per user / per action / exportable	GA
Just-in-time (JIT) user creation on first login	GA

How identity composes with deployment mode

Mode	Identity location	Notes
A	Claresia Cloud (WorkOS)	Standard
B	Claresia Cloud (WorkOS) + IP allowlisting	Optional VPN/tunnel for SAML traffic
C	Claresia Cloud + WorkOS Connect inside customer cloud	Customer-side WorkOS instance federates to your IdP; auth tokens never leave customer boundary

The auth flow (Mode A/B)

sequenceDiagram
    autonumber
    participant U as User browser
    participant CC as Command Center
    participant WO as WorkOS
    participant IdP as Customer IdP
    participant API as Claresia API

    U->>CC: GET app.claresia.com/dainese
    CC->>WO: redirect to WorkOS hosted SSO
    WO->>IdP: SAML AuthnRequest (or OIDC redirect)
    IdP->>U: present login page
    U->>IdP: enter credentials + MFA
    IdP-->>WO: SAML Response (or OIDC code)
    WO-->>CC: callback with WorkOS user profile
    CC->>API: mint JWT (5 min lifetime, refresh in HttpOnly cookie)
    CC->>U: redirect to /dainese/dashboard
    Note over U,API: Subsequent API calls carry the JWT in Authorization header

RBAC model

Three layers:

IdP groups — the source of truth. Claresia syncs them via SCIM.
Archetype mapping — cc-061 maps each user to one of 14 archetypes via their job title (or you can override per-user in Step 8 of the Onboarding Portal).
Skill entitlements — per archetype. Auto-generated from the Cowork pack for that archetype, then toggled manually in Step 9.

You can additionally assign:

Role within Claresia: tenant_admin, auditor, csm_external, member.
Custom group skill grants — additive to the archetype default.

Group → role conventions

We recommend you create the following IdP groups (or repurpose existing ones):

Group	Claresia role	Notes
`claresia-admins`	`tenant_admin`	Full Command Center access
`claresia-auditors`	`auditor`	Read-only, includes audit log + Hub records
`claresia-users`	`member`	Default. Skill access via archetype

Members not in any of these groups get member role with no skill entitlements until you grant via archetype.

Per-IdP setup guides

Audit log

Every privileged action emits a governance_event Hub record. Includes:

Actor (user_id, email, source IP)
Action (login, skill_entitlement_change, tenant_config_change, cmek_key_rotation, role_assignment, connector_credential_update, …)
Target (resource_id, resource_type)
Outcome (success / failure + error code)
Timestamp (microsecond precision, monotonic)
SHA-256 provenance hash

7-year retention default. Exportable via the Hub API or downloadable from Command Center as JSON or CSV.

What we do not support

Password-based auth (delegated to your IdP only)
Magic-link login (use SSO)
Local user accounts (no DB-stored passwords)
LDAP direct (use SAML or OIDC adapter to LDAP)