Identity and access model IDENTITET 023

Proposed Security Identity Identitet Rbac Oidc

Defines Identitet as the platform identity and authorization domain for human, service, tenant, and operator access.

Author
Lars Solem
Updated

Status

Proposed on 2026-03-14 by Lars Solem.

Context

Identitet is already listed as a core Dataverket service, but until now the architecture has only described it briefly.

For a multi-tenant platform, identity and access must cover more than user login. The platform needs an explicit model for:

  • human authentication
  • service-to-service authentication
  • authorization and RBAC
  • tenant and project scope
  • operator versus tenant access boundaries

Decision

Dataverket treats Identitet as the service responsible for identity and access policy inputs across the platform.

Its core responsibilities are:

  • human authentication through OIDC-based flows
  • service and workload identity inputs for platform components
  • token issuance or validation support for CLIs and APIs
  • RBAC and authorization context for tenant, project, and operator scopes
  • identity information consumed by Sentral, domain services, and operator tooling

Human identity

The normal human access path should use:

  • ZITADEL-backed OIDC for login
  • Teleport for operational access workflows where applicable
  • dvid login as the shared CLI auth entrypoint

Human identity should produce auditable actor context usable across API, task, and event systems.

The first-use experience should allow a tenant administrator to authenticate, discover available scope, and complete initial project onboarding through supported APIs and CLI flows rather than through undocumented manual token or role setup.

Service identity

The platform also needs service-to-service identity for:

  • internal APIs
  • NATS-connected components
  • automation workers
  • operator-facing infrastructure agents where applicable

The exact technical mechanism remains open, but the architecture requires strong service identity rather than shared static credentials everywhere.

Authorization model

Authorization must fit the tenant hierarchy and operator boundaries.

At minimum, the platform needs:

  • tenant-level administrative scope
  • project-level operational scope
  • environment-aware restrictions where relevant
  • operator-only roles for infrastructure and platform administration

Authentication alone is not enough. Identitet must feed consistent authorization context into the rest of the platform.

Relationship to Sentral

Identitet is not the public resource API.

Sentral remains the public control-plane facade, but it should consume identity and authorization context from Identitet rather than embedding its own separate auth model.

Relationship to secrets and break-glass

Identitet is distinct from:

Those systems integrate, but they do not replace the need for a normal identity and authorization service.

Consequences

  • Identitet becomes an explicit architectural domain instead of a thin placeholder
  • authentication, authorization, and RBAC are now recognized as platform-critical concerns
  • later security and API decisions can build on a clearer access model

Decision Outcome

Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.

More Information

  • RBAC model
  • service identity mechanism
  • token and session model
  • operator versus tenant access boundary rules

Audit

  • 2026-03-14: ADR proposed.