Identity & Access Control

Enterprise customers manage their people in a directory such as Microsoft Entra ID, Okta, or Google Workspace, and they expect that directory to control access to every product they buy. People sign in through it, are created and removed by it, and receive roles based on the groups they belong to. Governance closes the loop: access is reviewed periodically, and evidence of those reviews is kept for frameworks such as SOC 2 and ISO 27001.

Architecture

flowchart LR
  subgraph customer [Customer]
    directory[(Corporate directory)]
    idp[Identity provider]
  end

  subgraph iac [Identity & Access Control]
    direction TB
    sso[SSO: OIDC and SAML]
    scim[SCIM 2.0 endpoint]
    mapping[Group-to-role mappings]
    dir[(Users, memberships, groups)]
    reviews[Access reviews]
  end

  idp -->|sign-in assertions| sso
  directory -->|create, update, deactivate users and groups| scim
  sso -->|just-in-time provisioning| dir
  scim --> dir
  mapping --> dir
  dir --> reviews
  dir -->|membership events| app[Application]

Two channels feed the directory:

• SSO authenticates users and can create them on first sign-in (just-in-time provisioning), with group claims in the assertion.
• SCIM pushes changes as they happen in the customer's directory, including deactivations, so access is removed even if the person never signs in again.

Group-to-Role Mapping

Customer admins configure mappings themselves. Roles granted by the directory are marked as such and cannot be edited in the product; roles granted manually remain separate, so a sync never silently removes them.

Deprovisioning

sequenceDiagram
  autonumber
  participant D as Customer directory
  participant S as SCIM endpoint
  participant I as Identity subsystem
  participant A as Application
  D->>S: PATCH /Users/u_91 active=false
  S->>I: Deactivate membership in the organization
  I->>I: Revoke sessions, refresh tokens, and API keys
  I->>A: membership.deactivated event
  A->>A: Reassign or freeze owned resources per policy

Deprovisioned users keep their history and authored content; only their access ends.

Access Reviews

Access accumulates. People change teams, contractors finish, integrations are abandoned, and their access remains. Access reviews periodically ask an accountable person to confirm or revoke each grant.

flowchart LR
  schedule[Scheduled or triggered campaign] --> snapshot[Snapshot of grants in scope]
  snapshot --> assign[Assign reviewers: managers, resource owners]
  assign --> decide{Reviewer decision}
  decide -->|keep| certify[Certified, with justification]
  decide -->|revoke| revoke[Access removed automatically]
  decide -->|no response| escalate[Escalate, then apply default]
  certify --> evidence[(Evidence report)]
  revoke --> evidence
  escalate --> evidence

• Context for each decision. Show when access was granted, by whom, how it was granted (directory, manual, share), and when it was last used.
• Unused access first. Grants with no activity in the review period are flagged, so reviewers spend their attention where it matters.
• Revocation is real. A revoke decision removes the grant through the same path as any other change, revoking sessions and keys, and emitting events.
• Directory-managed access. Grants that come from directory groups are reviewed in the directory; the product shows them for completeness but does not revoke them locally.

Across Ownership Scopes

Watch For

• Matching identities. Link directory users to existing accounts by the directory's stable identifier, not by email, which can change or be reused.
• Large groups. Group membership updates can carry thousands of users; process them incrementally and idempotently.
• Directory quirks. Each provider implements SCIM and SAML slightly differently. Test against a real tenant of every directory in scope.
• Rubber-stamping. Very large review campaigns with no prioritization produce "approve all". Keep campaigns small and focused.
• Evidence. Auditors want the snapshot, each decision, who made it, and when. Export it in a form that needs no reconstruction.