User Management & Identity Governance

Identity governance in Colrows comes down to one thing: every person and agent runs under an identity whose access is enforced deterministically, at compile time. Bring your enterprise identity provider for sign-in; inside Colrows, users belong to groups and carry authorization attributes, and the data access and masking policies bound to them shape every query before a single row is read.

Why identity is upstream of governance

In most stacks, identity and data access live in separate silos: a user exists in your IdP, their tool identity exists somewhere else, and a role change only takes effect at the next manual sync. Colrows closes that gap by making identity the thing that governs. A user authenticates, and the data access and masking policies that match the user, their groups, and their attributes are compiled into every query - so authorization happens before a single row is read, not after.

Identity model

• User - a principal who signs in through your IdP or with native credentials. Belongs to zero or more user groups and selects a persona. Each user carries a role: Developer, Curator, or Admin.
• User group - a collection of users you manage in Colrows. Data access and data masking policies bind to individual users and to groups.
• Authorization attributes - typed values on a user, such as a region or a clearance level, set by an administrator or synchronized from your identity provider at sign-in. Attribute conditions in data access policies compare them with attributes on tables and columns.
• Persona - a named identity that carries scope and policy context. An administrator defines the organization's personas, and each user selects one; queries, agents, and monitors run under it, which is what keeps scheduled and automated work reproducible.
• Session - an authenticated context that carries the resolved persona, audit identifiers, and a request-scoped trace.

Authentication options

Native email & password

Sign in with an email and password managed in Colrows. Passwords can be reset, and an administrator can deactivate a user to revoke access immediately. Native accounts suit evaluation and break-glass administrators; bring your identity provider for everyday production access.

SAML 2.0 single sign-on

Colrows acts as the SAML Service Provider. Configure your IdP's entity ID, sign-on URL, and signing certificate in organization settings (all three are required to accept an assertion); Colrows publishes its SP metadata and validates the assertion at its ACS endpoint. Just-in-time provisioning is supported - a user signing in for the first time is created automatically. A configurable group claim carries the user's IdP groups into the session.

OIDC

Colrows also authenticates users against an OIDC identity provider, reading a configurable group claim so group membership travels with the sign-in. Works with mainstream providers such as Okta, Microsoft Entra ID (Azure AD), Google Workspace, Auth0, and Keycloak.

LDAP

Colrows can authenticate users against an LDAP directory. The realm is configured in organization settings with the directory URI and bind details; users then sign in with their directory credentials through the standard login flow. Use LDAP where identities already live in a corporate directory rather than a SAML or OIDC provider.

Attributes from your identity provider

LDAP, SAML, and OIDC sign-ins can also set a user's authorization attributes. In Administration → Settings → Authorization, a provider mapping links a source (LDAP, SAML, or OIDC), an issuer, and a claim to a subject attribute. The issuer must match exactly: the configured LDAP URI, the SAML IdP entity ID, or the validated token issuer for Google and Microsoft. Only claims from the verified provider response can set values. Provider values expire after the attribute's maximum age (at most 24 hours), and token refresh does not renew them, so users sign in again to get current values. A missing or invalid claim removes the previous value on the next sign-in. See Attribute-based access.

Managing users, groups & personas

Administrators manage users and user groups from Administration → Users and Administration → User Groups, and on the platform API. Groups and attributes are how identity connects to governance: policies bind to users and groups, attribute conditions test user attributes, and every request compiles under the requester's identity.

To see how policies become row- and column-level control, read Data Access Control and Data Masking Policies. For the full architectural picture, see SaaS Architecture.

Session & audit

• Every session is bound to the resolved persona; a persona change takes effect on the next session. Sessions can be refreshed with POST /api/user/token/refresh.
• Session lifetime is a configurable deployment timeout (default 2 hours).
• Every API call is recorded server-side - request URL, HTTP method, response code, organization, user, and timestamp. See Audit & Traces for what is captured and how to retrieve it.