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 cloud side is solid; 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 the IAM cleanup pass, with one named exception (a personal-account principal, 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 the user account store is the source of truth for identity. Email + password is the only login path.
  • Account lifecycle is managed by an org admin via the user-create endpoint / the user-update endpoint / soft-delete via the active-account flag. 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

implemented — verified 2026-05-06. Cloud-side Workspace IdP (@dtectvision.ai) with enforced MFA + IAP-SSH; application-side identity model with role-based authorization and org-scoping. Known gaps below (no app-side SSO/SCIM yet) are roadmap items.

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.
  • a personal-account principal still a personal-account principal on the cloud side until re-bound to a Workspace identity.

Roadmap

  • Re-bind a personal-account principal 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.