From dc937867ba5b87b5a6da7a2c9a773ead5bd49cb2 Mon Sep 17 00:00:00 2001 From: Albrecht Degering Date: Thu, 9 Jul 2026 15:05:51 +0200 Subject: [PATCH] Sync wiki from project files --- Codex-Project-Index.md | 1 + Repo-docs-IDENTITY-ACCOUNT-FUNCTION-MODEL.md | 64 ++++++++++++++++++++ 2 files changed, 65 insertions(+) create mode 100644 Repo-docs-IDENTITY-ACCOUNT-FUNCTION-MODEL.md diff --git a/Codex-Project-Index.md b/Codex-Project-Index.md index d09210a..d49ec52 100644 --- a/Codex-Project-Index.md +++ b/Codex-Project-Index.md @@ -6,4 +6,5 @@ This page is generated from repository and product-directory project files. - [Repo-README](Repo-README) - `/mnt/DATA/git/govoplan-access/README.md` - [Repo-docs-ACCESS-MODULE-BOUNDARY](Repo-docs-ACCESS-MODULE-BOUNDARY) - `/mnt/DATA/git/govoplan-access/docs/ACCESS_MODULE_BOUNDARY.md` +- [Repo-docs-IDENTITY-ACCOUNT-FUNCTION-MODEL](Repo-docs-IDENTITY-ACCOUNT-FUNCTION-MODEL) - `/mnt/DATA/git/govoplan-access/docs/IDENTITY_ACCOUNT_FUNCTION_MODEL.md` - [Repo-docs-OPENDESK-IDENTITY-BOUNDARY](Repo-docs-OPENDESK-IDENTITY-BOUNDARY) - `/mnt/DATA/git/govoplan-access/docs/OPENDESK_IDENTITY_BOUNDARY.md` diff --git a/Repo-docs-IDENTITY-ACCOUNT-FUNCTION-MODEL.md b/Repo-docs-IDENTITY-ACCOUNT-FUNCTION-MODEL.md new file mode 100644 index 0000000..1d58c1b --- /dev/null +++ b/Repo-docs-IDENTITY-ACCOUNT-FUNCTION-MODEL.md @@ -0,0 +1,64 @@ + + +> 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.