User Management & Identity Governance

User management in an autonomous AI stack is not about managing passwords. It is about enforcing identity-based governance across your semantic layer. Access to your data must be as deterministic as the SQL we generate. Colrows integrates with your enterprise IdP to map roles directly to semantic permissions at compile time.

The architecture gap: identity silos vs. integrated governance

The identity silo problem

Most SaaS tools store identities in isolated databases. A user exists in your IdP (Okta, Entra, Google Workspace). Their Colrows identity exists in a separate silo. When you need to revoke access or change a role, you update the IdP, but the SaaS tool does not reflect the change until the next manual sync (if at all). This creates security gaps. It makes it impossible to enforce consistent access policies across your stack.

The integrated advantage

Colrows integrates natively with your existing identity provider. We do not replicate your users. We resolve them. When you authenticate, we ask your IdP for your groups and attributes. We map those groups directly to personas in our semantic graph. Your role changes propagate in real time. Access is enforced at compile time, before a single row of data is read. The result is secure, automated access without manual overhead.

Identity model

• User - a unique principal authenticated by your IdP. Has zero or more group memberships and persona bindings.
• Group - a collection of users mirrored from your IdP (Okta, Entra ID, Google Workspace, JumpCloud, AD).
• Persona - a graph node with scope and policy bindings. A user's effective persona is resolved at request time from group membership and explicit assignment.
• Session - an authenticated context. Carries the persona, audit identifiers, and a request-scoped trace.

Authentication options

Native authentication

Email + password with mandatory MFA (TOTP or hardware key). Use it for early evaluation or for break-glass admin accounts. Not recommended as the primary auth method for production.

• Argon2id password hashing, configurable cost factors.
• Mandatory MFA after first sign-in. Backup codes generated on enrollment.
• Forced rotation on compromise - admins can invalidate all sessions for a user instantly.

OAuth / OIDC

Recommended for most deployments. Colrows is a standard OIDC relying party - bring an Identity Provider that supports the Authorization Code flow with PKCE.

idp:
  type: oidc
  issuer:           https://acme.okta.com
  client_id:        colrows-prod
  client_secret:    ${ENV}
  scopes:           [openid, profile, email, groups]
  group_claim:      groups
  username_claim:   email

Tested integrations: Okta, Microsoft Entra ID (Azure AD), Google Workspace, Auth0, Keycloak, Ping. Custom IdPs work as long as they're spec-compliant.

SAML 2.0

For enterprises with a SAML-only IdP (some on-prem ADFS deployments). Colrows acts as the Service Provider; upload the IdP metadata XML and provision claim mappings.

idp:
  type: saml
  metadata_url:     https://idp.acme.com/saml/metadata
  attribute_username: NameID
  attribute_groups:   memberOf
  signed_assertions:  required
  signed_responses:   required

Just-in-Time provisioning is supported - users created on first sign-in inherit personas based on group membership.

Group → persona mapping

The contract between identity and the semantic graph is the group-to-persona map.

persona_bindings:
  - group: "data-platform-engineers"
    persona: engineer
  - group: "regional-analysts-emea"
    persona: regional_analyst
    scope:
      region: EMEA       # ABAC predicate
  - group: "executive-readers"
    persona: viewer

Bindings are evaluated at session start. A user in multiple matching groups receives the union of allowed scopes and the most restrictive policy for any conflict.

SCIM provisioning

Colrows exposes a SCIM 2.0 endpoint for automated user and group lifecycle management. Most IdPs can drive create, update, delete, and group membership sync over SCIM. Combined with OIDC, this gives you a fully automated identity loop with zero manual overhead.

How we integrate

Identity integration happens in three stages. First, your users authenticate against your IdP (Okta, Entra, Keycloak, or any OIDC-compliant provider). Second, we resolve their group memberships and attributes. Third, we map those groups to personas in the semantic graph. The persona binds to data access policies enforced at compile time. See fine-grained data access control to understand how identity maps to row- and column-level security. For the full architectural picture, see SaaS Architecture.

Session & audit

• Sessions are bound to the resolved persona. Persona changes (role swap, scope change) take effect on next session.
• Idle and absolute timeouts are configurable per workspace. Defaults are 12h idle, 24h absolute.
• Every authenticated action writes an audit row keyed by user, persona, request ID, and trace ID. Searchable from the admin console. Exportable to your SIEM.