Identity

Lattix does not store user passwords or provide its own identity service. Every authentication is federated to your identity provider. This page covers what the platform needs from the identity provider, how to map its claims to Lattix roles, and what session-related controls are configurable.

Supported identity providers

The platform accepts any standards-compliant OpenID Connect (OIDC) or SAML 2.0 identity provider. In practice customers typically deploy with:

• Microsoft Entra ID (Azure AD)
• Okta
• Google Workspace
• Ping Identity
• Keycloak (for self-hosted identity)
• WorkOS (for SSO-as-a-service scenarios, especially multi-tenant B2B)

Any other identity provider that correctly implements OIDC or SAML also works.

What the platform requires from the identity provider

At a minimum, the identity provider must deliver:

• A stable principal identifier — a value that uniquely identifies the principal within the tenant and does not change if the principal's display name or email changes.
• An authenticated email address — used for invites and evidence-pack attribution.
• Group or role claims — the mechanism for mapping principals to Lattix administrative and data-access roles.
• Appropriate authentication strength — for tenants with sensitive workloads, MFA and session-strength signals should be present in the token.

For policies that reference contextual attributes (device posture, location, clearance level), the identity provider is also expected to deliver these as claims. The platform cannot evaluate what it cannot see.

Attribute mapping

An administrator defines a mapping from identity-provider claims to Lattix attributes. A typical mapping:

• Claim groups containing security-admins → Lattix role Security Administrator
• Claim clearance with value 3 or higher → Lattix attribute clearance-level >= 3
• Claim geography → Lattix attribute location
• Claim device-posture → Lattix attribute device-trust

Mappings are tenant-scoped. Two tenants in the same deployment can map differently — one treating groups: security-admins as a full administrator, another treating the same claim as a scoped reviewer.

The mapping is configured in the Mesh Dashboard's identity page. Changes are versioned and take effect on the next identity-provider-issued token.

Role assignment

Role assignments are made via attribute mapping rather than per-user selection inside Lattix. This has two important consequences:

• No parallel user database. Adding or removing a principal's Lattix access is done in the identity provider, not in Lattix. There is no separate user list to keep in sync.
• Revocation is effective immediately on the next session. When the identity provider removes a group membership, the corresponding Lattix role is lost the next time the principal's token is evaluated.

This pattern is deliberate — it eliminates a common source of security drift where an employee is removed from the directory but retains Lattix access because nobody updated a local user list.

Multi-IdP scenarios

A tenant can register multiple identity providers. This is the intended pattern for:

• Coalition or partner scenarios — your organization has its own IdP, the partner has theirs, both authenticate into the same tenant with scoped access.
• Contractor or vendor access — long-term contractors authenticated through a secondary IdP distinct from employee directory.
• Separation of duties — different IdPs for different administrative roles where compliance requires it.

Each IdP has its own attribute mapping. A principal authenticated through IdP A can have different attributes than a principal with the same name authenticated through IdP B.

Session controls

Configurable session-related settings:

• Session lifetime. How long a signed-in session remains valid before reauthentication. Shorter is more secure; longer is more convenient.
• Idle timeout. How long a session can remain inactive before being closed.
• Step-up authentication for sensitive operations. Operations like publishing a policy change, rotating a KEK, or exporting an evidence pack can be gated on a fresh MFA challenge even within an otherwise-valid session.
• Device binding. For tenants that want device posture to factor into access decisions, a session can be bound to a device identity provided by the identity provider.

These controls set the tenant's default; specific policies can tighten further.

What the platform does not store

Several things intentionally never touch the platform:

• Passwords — authentication is always federated.
• Tokens long-term — identity-provider tokens are used for the duration of a session and then discarded.
• Raw biometric data — the platform reads identity-provider signals about authentication strength but does not handle biometrics itself.
• Recovery credentials — account recovery is the identity provider's responsibility.

If your organization requires that no credential related to Lattix access exist outside your identity infrastructure, that requirement is met by the platform's design.