Skip to content

Identity Provider

Statement

ClaimGuard has two distinct identity surfaces with two distinct identity providers today:

  • For cloud / infrastructure access: Google Workspace (@dtectvision.ai) is the IdP for every privileged action against the GCP project. Workspace MFA is enforced; SSH to the VM is gated through Identity-Aware Proxy on top of the Workspace identity. See Privileged access.
  • For application access: there is no external IdP. Customer staff authenticate with email + password issued by their organization admin in the application; the application is the source of truth for user identity. See Authentication.

The control sits at partial because the cloud side is solid, but the application side is not yet integrated with any external IdP. Adding SSO (SAML / OIDC) is on the roadmap, gated on the first enterprise customer that requires it.

Implementation

Cloud-side identity (Google Workspace)

  • Owner pair: roee@dtectvision.ai, dor@dtectvision.ai. Both are Workspace identities subject to Workspace's mandatory-MFA policy.
  • Personal @gmail.com accounts are no longer in the project's owner set after plan step A1.4-step1, with one named exception (idonithid@gmail.com, an active developer; re-binding to a Workspace identity is a planned follow-up). See Privileged access for the cleanup record.
  • Authentication path: Google sign-in via Workspace; the gcloud CLI uses short-lived ID tokens refreshed against the Workspace identity.
  • MFA: enforced at the Workspace policy level. The cloud console and gcloud both require MFA via the Workspace identity. See MFA.

Application-side identity (in-app)

  • No external IdP. The application's users table is the source of truth for identity. Email + password is the only login path.
  • Account lifecycle is managed by an org admin via POST /api/users / PUT /api/users/:id / soft-delete via is_active = false. See Authentication.
  • API keys are an alternate authentication path for programmatic clients; they are application-issued and not federated.

What's not in place

  • No SAML SSO. No customer can today authenticate their staff into ClaimGuard via their corporate IdP (Okta, Azure AD, Google Workspace, OneLogin, etc.).
  • No OIDC SSO. Same.
  • No SCIM provisioning. Customer admins create users one-by-one via the application UI / API; there is no provisioner-to-IdP sync.
  • No Just-In-Time (JIT) user creation on first SAML sign-in.
  • No per-org IdP configuration model in the schema; adding SSO requires a feature design that includes per-org IdP metadata, certificate rotation, and assertion-mapping rules.

Status

partial — verified 2026-04-29.

What's in place:

  • A clean Workspace-IdP story for cloud / infrastructure access: named owners, mandatory MFA, IAP-gated SSH, no shared accounts.
  • An in-app identity model with role-based authorization and org-scoping. See Authorization.

Known gaps

  • No application-side SSO of any kind.
  • No SCIM provisioning.
  • idonithid@gmail.com still a personal-account principal on the cloud side until re-bound to a Workspace identity.

Roadmap

  • Re-bind idonithid@gmail.com to a Workspace identity. Small IAM change, scheduled.
  • SAML SSO for application logins, gated on the first enterprise customer that requires it. Requires a per-org IdP-metadata model.
  • OIDC as a fast-follow once SAML is in.
  • SCIM provisioning as a fast-follow once SAML is in.
  • Org-admin self-service of SSO configuration once the per-org IdP-metadata model is shipped.