1
Repo docs IDENTITY ACCOUNT FUNCTION MODEL
Albrecht Degering edited this page 2026-07-09 15:05:51 +02:00

Mirrored from /mnt/DATA/git/govoplan-access/docs/IDENTITY_ACCOUNT_FUNCTION_MODEL.md. Origin: repository. Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.


Identity, Account, Function, Role, And Right Model

GovOPlaN access should distinguish identity facts from organizational responsibility and authorization decisions.

Directory services, identity providers, and IDM systems may authenticate people and provide membership facts. GovOPlaN access owns the platform projection used for sessions, tenant membership, groups, functions, roles, delegation, and permission decisions.

Semantic Layers

  • Identity: the real person, service, or external subject.
  • Account: the login or technical account used to authenticate.
  • Tenant membership: the person's participation in a tenant.
  • Organization unit: the administrative unit where responsibility applies.
  • Function: a responsibility held in an organization unit, such as case clerk, intake desk, treasurer, or committee secretary.
  • Role: a permission bundle or workflow authority attached to a function, group, or explicit assignment.
  • Right: the concrete scope or action permission evaluated at runtime.

The UI and API should avoid collapsing these layers into one generic group concept. Directory groups can feed mappings, but they should not silently become business authority without a governed mapping rule.

Boundary

Access owns:

  • account and tenant membership projection
  • groups, roles, function assignments, and delegation facts
  • permission decisions and explain responses
  • identity and membership change events
  • SCIM/OIDC/SAML/LDAP mapping effects when implemented

Access does not own:

  • mailboxes, calendars, files, cases, tasks, or postboxes
  • module-specific ACL records beyond stable principal/group/role references
  • external provider internals except where they mutate access-owned state

Required Explainability

Access decisions should be explainable in concrete terms:

  • actor identity/account
  • tenant membership
  • organization unit
  • function assignment or group membership
  • role source
  • permission/right checked
  • delegation or system-actor context
  • policy or lock that changed the result

This shape is required for postbox role access, workflow actions, service directory personalization, delegated administration, and audit review.