[VS-NfD] Map IdP groups and roles onto the permission model #217

New Issue

fable-5 · 2026-07-30T01:43:48+02:00

fable-5 commented

2026-07-30 01:43:48 +02:00

Plan reference: 20-massnahmenplan.md -> P1-1
ADR: ADR 0021
Effort: M (2–3 AT)
Depends on: #214

Context

Without claim mapping, every authority deployment administers permissions
twice — and the second copy drifts. Drifted permissions on classified
content is exactly the finding to avoid.

Current state

Permissions are grants evaluated centrally
(apps/api/src/permissions/, deny-wins, default-closed, ADR-documented
route-enumeration test). Grants are created through the API — the project
rule is that raw grant rows bypass the PondPermissionCache.
Nothing consumes IdP claims (no OIDC exists yet, #214).

Acceptance criteria

A declarative, admin-visible mapping turns claims into pond roles
and the site-admin flag; the mapping is instance configuration, not
code.
Mapped grants are applied through the same service path as manual
grants, so the permission cache stays correct (no raw row writes).
Removal of a claim revokes the corresponding grant on next login, and
live collab sessions are terminated by the existing revocation path
(pg_notify access listener) — asserted by test.
Manually created grants are distinguishable from mapped ones, and a
documented rule says which wins.
Every mapping-driven change is audited.
docs/architecture/permissions.md documents the mapping.

Out of scope

SCIM provisioning, and just-in-time user creation policy beyond what #214
defines.

**Plan reference:** `20-massnahmenplan.md` -> P1-1 **ADR:** ADR 0021 **Effort:** M (2–3 AT) **Depends on:** #214 ## Context Without claim mapping, every authority deployment administers permissions twice — and the second copy drifts. Drifted permissions on classified content is exactly the finding to avoid. ## Current state - Permissions are grants evaluated centrally (`apps/api/src/permissions/`, deny-wins, default-closed, ADR-documented route-enumeration test). Grants are created through the API — the project rule is that raw grant rows bypass the `PondPermissionCache`. - Nothing consumes IdP claims (no OIDC exists yet, #214). ## Acceptance criteria - [ ] A declarative, admin-visible mapping turns claims into pond roles and the site-admin flag; the mapping is instance configuration, not code. - [ ] Mapped grants are applied through the same service path as manual grants, so the permission cache stays correct (no raw row writes). - [ ] Removal of a claim revokes the corresponding grant on next login, and live collab sessions are terminated by the existing revocation path (`pg_notify` access listener) — asserted by test. - [ ] Manually created grants are distinguishable from mapped ones, and a documented rule says which wins. - [ ] Every mapping-driven change is audited. - [ ] `docs/architecture/permissions.md` documents the mapping. ## Out of scope SCIM provisioning, and just-in-time user creation policy beyond what #214 defines.

fable-5 added this to the M27 — VS-NfD: external authentication milestone 2026-07-30 01:43:48 +02:00

fable-5 added the

effort:M

area:auth

vs-nfd

labels 2026-07-30 01:43:48 +02:00

fable-5 referenced this issue from a commit

2026-07-31 13:09:31 +02:00

#217: map IdP groups and roles onto the permission model

fable-5 referenced this issue

2026-07-31 13:09:55 +02:00

#217: map IdP groups and roles onto the permission model #285

fable-5 commented

2026-07-31 13:47:16 +02:00

Implemented in PR #285 (commit 6aac785), merged fast-forward (run 604 green); CD 609 green, readyz test+int ok. Declarative idpMapping.rules (instance setting) map ID-token claims to pond roles and the site-admin flag on every OIDC login. Mapped grants go through the SAME GrantsService path as manual grants - permission cache invalidation and the collab access notify (pg_notify revocation path) asserted by test - never raw rows. Ownership via role_grants.origin and users.is_site_admin_managed: manual wins, always; claim removal revokes mapped state on next login; every change audited with origin idp_mapping; unknown slugs and the last-Pond-Admin protection log-and-skip (never a login lockout). Documented in permissions.md (own section), ADR 0021, data-model.md, hardening guide. 4 e2e tests drive real OIDC logins with group claims.

Implemented in PR #285 (commit 6aac785), merged fast-forward (run 604 green); CD 609 green, readyz test+int ok. Declarative idpMapping.rules (instance setting) map ID-token claims to pond roles and the site-admin flag on every OIDC login. Mapped grants go through the SAME GrantsService path as manual grants - permission cache invalidation and the collab access notify (pg_notify revocation path) asserted by test - never raw rows. Ownership via role_grants.origin and users.is_site_admin_managed: manual wins, always; claim removal revokes mapped state on next login; every change audited with origin idp_mapping; unknown slugs and the last-Pond-Admin protection log-and-skip (never a login lockout). Documented in permissions.md (own section), ADR 0021, data-model.md, hardening guide. 4 e2e tests drive real OIDC logins with group claims.

fable-5 closed this issue

2026-07-31 13:47:17 +02:00

Sign in to join this conversation.