cms v2 umsetzungsstand milestone 1 pakete 1 5 2026 03 24 - smart-village-solutions/sva-studio GitHub Wiki

Bericht zum Umsetzungsstand

CMS-Upgrade Milestone 1, Pakete 1 bis 5

Stand: 31.03.2026

Ziel und Abgrenzung

Dieser Bericht bewertet den Umsetzungsstand der Punkte 1 bis 5 aus dem Dokument concepts/konzeption-cms-v2/Auftrag-Milestone-1.md.

Die Bewertung basiert auf dem aktuellen Repository-Stand vom 31.03.2026, vorhandenen Tests, Architektur- und Betriebsdokumenten sowie vorhandenen Nachweis- und Staging-Dokumenten.

1. Architektur & Basis-IAM-Inkrement

Anforderungsbeschreibung laut Auftrag

  • Architektur-Design: Erstellung des detaillierten technischen Architektur-Designs für den gesamten Identitäts- und Zugriffsmanagement-Service (IAM-Service), die Permission Engine und das notwendige logische Datenbank-Schema (Postgres/Supabase) gemäß dem Zielbild des Konzepts.
  • Keycloak-Basis-Setup: Einrichtung des dedizierten Keycloak-Realms für die vereinbarte Test-/Entwicklungsumgebung.
  • Client & Token Setup: Konfiguration der spezifischen Clients für das CMS sowie Aufbau des initialen Token-Setups (OIDC-Claims), um die Authentifizierung zu ermöglichen.

Abnahmekriterien laut Auftrag

  • Die Architekturdokumentation (inkl. Logik des DB-Schemas, Schnittstellenkonzept) liegt in finaler, freigegebener Form vor.
  • Der dedizierte Keycloak-Realm und die zugehörigen Clients sind in der vereinbarten Testumgebung funktionsfähig eingerichtet.
  • Ein erfolgreicher Authentifizierungs-Flow (Login) eines Keycloak-Test-Users über einen der konfigurierten Clients ist nachweisbar.
  • Das ausgestellte OIDC-Token enthält die korrekten Claims gemäß dem initialen Token-Setup.

Bewertung

Weitgehend umgesetzt, aber die Abnahmekriterien zur realen Zielumgebung sind im Repository nicht vollständig nachgewiesen.

Umgesetzte Elemente

  • OIDC-Login mit Keycloak ist als technischer Standardpfad dokumentiert und im Auth-Paket beschrieben.
  • Redis-basierte Session-Verwaltung ist dokumentiert und Bestandteil der Architektur.
  • Die Architektur beschreibt die Aufgabenteilung Keycloak für technische Identität, Postgres für fachliche IAM-Daten und Redis als Cache.
  • Für den Keycloak-Service-Account und Rollen-Sync liegen Betriebs- und Setup-Dokumente vor.

Einschränkungen

  • Ein echter Acceptance-Lauf gegen die vereinbarte Testumgebung mit gültigen Runtime-Secrets war laut Bericht noch nicht möglich.
  • Damit ist die funktionsfähige Einrichtung von dediziertem Realm, Clients und realem Login-Flow nicht allein durch Repo-Artefakte final abgenommen.

Fundstellen

2. Accounts & Organisationen

Anforderungsbeschreibung laut Auftrag

  • Datenmodelle Implementierung: Implementierung des im Architekturkonzept entworfenen Postgres-Datenbank-Schemas (im IAM-Schema) für die Kernentitäten iam.accounts und iam.organizations.
  • Organisations-Hierarchie & Mandantenfähigkeit: Implementierung der Logik zur Abbildung der hierarchischen Organisationsstrukturen (z. B. Stadt → Stadtteil) sowie die Sicherstellung der Mandantenfähigkeit auf Datenebene.
  • Minimaler IAM-Service (Core-Sync): Implementierung der Synchronisations-Logik, die die Keycloak-User-ID (sub) nach dem Login oder bei Neuregistrierung mit dem entsprechenden iam.accounts-Datensatz verknüpft und synchronisiert.
  • Basis-CRUD-Operationen: Implementierung der Backend-Endpunkte (API-Schnittstellen) für die Erstellung, das Lesen, die Aktualisierung und das Löschen (CRUD) von Accounts und Organisationen, die vom CMS-UI genutzt werden.
  • Admin-UI Integration: Erweiterung der Admin-UI Basics um funktionale Komponenten zur Anzeige, Bearbeitung und Verwaltung der Accounts und Organisationsstrukturen inklusive Onboarding-Status.

Abnahmekriterien laut Auftrag

  • Die Datenbanktabellen iam.accounts und iam.organizations sind im Postgres-Schema der Testumgebung angelegt und entsprechen dem freigegebenen Design.
  • Die Synchronisations-Logik funktioniert fehlerfrei: Nach einem Login über Keycloak existiert ein korrekter Datensatz in iam.accounts mit korrekter Verknüpfung zur Keycloak-ID.
  • Die hierarchische Abbildung ist funktional: Die Anlage einer neuen Organisation kann erfolgreich einer übergeordneten Organisation zugewiesen werden.
  • Die CRUD-Operationen für Accounts und Organisationen sind über die Backend-API durch einen Test-Administrator erfolgreich durchführbar.
  • Die Admin-UI bildet die Benutzerliste und die Organisationsstruktur korrekt ab und ermöglicht die Zuweisung eines Accounts zu einer Organisation.

Bewertung

Weitgehend umgesetzt.

Umgesetzte Elemente

  • Backend-Handler für Benutzerverwaltung sind vorhanden, einschließlich Listen-, Detail-, Erstellen-, Aktualisieren-, Deaktivieren- und Sync-Funktionen.
  • Keycloak-User-Sync nach iam.accounts ist implementiert.
  • Organisationsverwaltung mit CRUD, Hierarchie, Mitgliedschaften und aktivem Organisationskontext ist implementiert.
  • Die Admin-UI stellt Seiten für Benutzer und Organisationen bereit.
  • Das Datenmodell und die Verträge für Accounts, Rollen, Gruppen und Organisationen sind typisiert.

Beobachtungen

  • Für den Abgleich "nach Login oder Neuregistrierung existiert korrekter Datensatz in iam.accounts" gibt es starke Implementierungshinweise über Import-/Sync- und Actor-Resolution-Pfade.
  • Ein vollständig dokumentierter End-to-End-Abnahmebeleg in einer realen Zielumgebung ist auch hier nicht zentral abgelegt, die Implementierung selbst ist aber deutlich vorhanden.

Fundstellen

3. Rollenmodell, Gruppen & Vererbungen

Anforderungsbeschreibung laut Auftrag

  • Rollen-Implementierung: Implementierung der verschiedenen System-Personas (z. B. System-Administrator, Redakteur) als feste Rollen sowie die Architektur zur Anlage mandantenspezifischer Custom-Rollen in der Tabelle iam.roles.
  • Gruppen-Modell: Implementierung des Backend-Modells (iam.groups) und der zugehörigen Logik zur Bündelung von Permissions und zur Zuweisung zu Accounts.
  • Feingranulare Permissions: Implementierung der Datenbank-Modelle zur Speicherung der feingranularen Berechtigungen gemäß der Struktur (subject, action, resource_type, resource_id?, scope).
  • Hierarchische Vererbung (RBAC/ABAC): Implementierung der komplexen Vererbungslogik, die Rollenberechtigungen über die Organisations-Hierarchie und über geografische Attribute korrekt auflöst.
  • Verwaltungs-UI: Erweiterung der CMS-UI um die notwendigen Oberflächen zur Anlage, Bearbeitung und Zuweisung von System- und Custom-Rollen, Gruppen sowie zur Verknüpfung von Accounts mit Rollen und Gruppen.

Abnahmekriterien laut Auftrag

  • Die Datenbankmodelle für Rollen, Gruppen und Berechtigungen (iam.roles, iam.groups, iam.role_permissions) sind angelegt und mit den notwendigen CRUD-Funktionen hinterlegt.
  • Die System-Personas sind angelegt und mit einem initialen Set an Berechtigungen versehen.
  • Die Rollen-Vererbung ist funktional: Ein Test-User mit einer Rolle auf Stadtebene erhält automatisch die korrekten effektiven Berechtigungen für alle zugeordneten Stadtteile.
  • Die Geo-Vererbung ist funktional: Die Zuweisung einer geographicPermission zu einer Region resultiert in der korrekten Auflösung der Berechtigung für alle untergeordneten geografischen Entitäten.
  • Die Admin-UI ermöglicht die korrekte Zuweisung von Rollen und Gruppen zu einem Account und spiegelt die effektiven vererbten Rollen korrekt wider.

Bewertung

Weitgehend umgesetzt. Die Verwaltungs-UI ist gegenüber dem Stand vom 24.03.2026 deutlich weiter ausgebaut, die vollständige fachliche Abnahme bleibt aber evidenzseitig noch offen.

Umgesetzte Elemente

  • Rollenverwaltung ist serverseitig vorhanden, einschließlich Create/Update/Delete, Reconcile und Keycloak-Sync.
  • Gruppenverwaltung mit Gruppenrollen und Gruppenmitgliedschaften ist implementiert.
  • Rollen- und Gruppenbeziehungen fließen in die Berechtigungsauflösung ein.
  • Organisationsvererbung und Geo-Vererbung sind in der Autorisierungslogik und den zugehörigen Tests abgebildet.
  • Direkte Nutzerberechtigungen (allow/deny) sind zusätzlich als feingranularer Override-Pfad implementiert und in Datenmodell, Validierung, Detailabfrage und Permission-Auflösung integriert.
  • Die Admin-UI enthält inzwischen eine Rollen-Detailseite mit Tabs für Metadaten, Permission-Zuordnung, Benutzerzuweisungen und Sync-Status.
  • Die Benutzerverwaltung enthält inzwischen einen Read-Only-Bereich für effektive Berechtigungen mit Herkunftstransparenz für direkte Zuweisungen, direkte Rollen und Gruppenrollen einschließlich wirksamer und nicht wirksamer Quellen.
  • Für Gruppen, Rollen und Vererbungslogik liegen Unit- und Server-Tests vor.

Einschränkungen

  • Die UI deckt die Pflege von Rollen-Metadaten und Rollen-Permissions inzwischen ab; die technische Transparenz effektiver Berechtigungen ist additiv im Benutzer-Detailvertrag und in der Admin-UI umgesetzt. Offen bleibt der formale fachliche Abnahme-Nachweis in Zielumgebung.
  • Für die Angebots- und technische Abnahme der Pakete 3 bis 5 liegt inzwischen ein separates Artefakt mit normativen Pflichtnachweisen vor, der ausgefüllte Nachweis selbst ist daraus noch nicht ableitbar.

Fundstellen

4. Permission Engine & High-Performance AuthZ

Anforderungsbeschreibung laut Auftrag

  • Permission Engine API: Entwicklung des zentralen IAM-Service-Endpunkts, der als einzige Quelle für Berechtigungsentscheidungen im CMS dient, einschließlich Algorithmus zur Berechtigungsberechnung.
  • High-Performance Cache: Aufbau und Konfiguration eines Redis-basierten Caches zur Speicherung von vorberechneten Permission Snapshots.
  • Caching-Logik: Implementierung der Logik für Cache-Hits (In-Memory-Checks) und Cache-Misses (Datenbankabfrage, Berechnung und Speichern in Redis).
  • Basiskommunikation: Implementierung eines Mechanismus zur Cache-Invalidierung bei Änderungen der Kernentitäten durch Events.
  • Performance-Tuning: Analyse und Optimierung des Berechnungsalgorithmus zur Einhaltung der kritischen Latenzanforderung kleiner 100 ms für den Endpunkt.

Abnahmekriterien laut Auftrag

  • Der zentrale Autorisierungs-Endpunkt ist in der Entwicklungs-/Testumgebung erreichbar und liefert korrekte Entscheidungen.
  • Die Redis-Integration ist nachweisbar funktionsfähig: Berechtigungs-Snapshots werden nach dem ersten Aufruf im Redis gespeichert und beim zweiten Aufruf von dort geladen.
  • Latenztest Performanz: Die Berechtigungsprüfung im Cache-Hit-Szenario überschreitet die zugesicherte Latenz von 100 ms als P95 bei den vereinbarten Lastbedingungen nicht.
  • Die Basis-Cache-Invalidierung funktioniert: Eine Änderung der Rolle eines Test-Users führt nachweislich zur Löschung des zugehörigen Permission-Snapshots in Redis.

Bewertung

Weitgehend umgesetzt, mit zusätzlicher Evidenz für Invalidation- und Snapshot-Pfade. Die End-to-End-Abnahme unter Zielumgebungsbedingungen ist weiterhin nur teilweise belegt.

Umgesetzte Elemente

  • Ein zentraler Authorize-Pfad ist vorhanden.
  • Effektive Permissions werden aus Rollen, Gruppen, Delegationen und Organisationskontext zusammengesetzt.
  • Redis-basierte Permission-Snapshots sind implementiert.
  • Ein lokaler In-Memory-L1-Cache und ein Redis-Shared-Read-Path sind vorgesehen und implementiert.
  • Cache-Invalidierung und Snapshot-Handling sind als eigene Bausteine vorhanden.
  • Direkte Nutzerberechtigungen invalidieren Permission-Snapshots inzwischen explizit über den Trigger user_permission_changed.
  • Architektur-, Qualitäts- und Benchmark-Dokumente für Performance und Cache-Verhalten liegen vor.
  • Zusätzlich ist nun eine ausführbare Harness für Cache-Hit, Cache-Miss, Recompute und user-scoped Invalidation im Repository vorhanden.

Einschränkungen

  • Der evaluator-nahe Benchmark liegt vor und erfüllt den Zielwert deutlich.
  • Für die Arbeitspaket-Abnahme gefordert ist aber insbesondere ein belastbarer Endpunkt-/Umgebungsnachweis, einschließlich Cache-Hit, Cache-Miss, Redis-Nutzung und Lastbedingungen. Dieser Nachweis ist im Repository weiterhin nur teilweise als operative Evidenz vorhanden.
  • Das neue Artefakt für Pakete 3 bis 5 konkretisiert zwar die erwarteten Performance- und Invalidation-Nachweise, ersetzt aber noch keinen ausgeführten Messbericht.

Fundstellen

5. Rechtstexte & Akzeptanzsystem

Anforderungsbeschreibung laut Auftrag

  • Datenmodell Rechtstexte: Implementierung der Tabellen in der Datenbank zur Speicherung von Rechtstexten (AGB, Datenschutzerklärung) inklusive Versionsverwaltung.
  • Akzeptanz-Workflow: Implementierung einer Logik, die beim Login-Prozess prüft, ob der angemeldete Benutzer die neueste Version der notwendigen Rechtstexte akzeptiert hat.
  • Erzwingung der Akzeptanz: Bereitstellung eines Redirects beziehungsweise einer IAM-Hook-Funktion, die den Benutzer zur Akzeptanz zwingt, bevor der Zugang zum System gewährt wird.
  • Nachweis & Export: Implementierung einer Funktion im Admin-UI, die einen revisionssicheren Nachweis liefert, wann und welche Version eines Rechtstextes von einem Benutzer akzeptiert wurde.

Abnahmekriterien laut Auftrag

  • Das Datenmodell ermöglicht die Anlage und Versionsverwaltung von mindestens zwei unterschiedlichen Rechtstexten.
  • Die Erzwingungslogik ist funktional: Ein Test-User, der eine neue Version eines Rechtstextes noch nicht akzeptiert hat, wird beim Login zur Akzeptanz gezwungen.
  • Nach der Akzeptanz wird der Akzeptanz-Vorgang mit Datum und Versionsnummer unveränderbar protokolliert.
  • Die Nachweisfunktion im Admin-UI liefert für einen beliebigen Benutzer einen Export der akzeptierten Rechtstexte, der die Einhaltung der Nachweispflichten belegt.

Bewertung

Weitgehend umgesetzt, mit stärkerer Repo-Evidenz für Enforcement, Sanitizing und Exportrechte. Der fachliche End-to-End-Nachweis bleibt jedoch offen.

Umgesetzte Elemente

  • Datenmodell und CRUD-Pfade für versionierte Rechtstexte sind vorhanden.
  • Eine Admin-Oberfläche für Liste, Suche, Filter, Erstellen und Bearbeiten von Rechtstexten ist vorhanden.
  • Eine serverseitige Erzwingung offener Rechtstext-Akzeptanzen ist implementiert.
  • Ein Exportpfad für Zustimmungs-/Consent-Nachweise ist vorhanden.
  • Im Frontend existieren API-Helfer für ausstehende Rechtstexte und deren Akzeptanz.
  • Der Akzeptanzdialog im Frontend ist mit eigenen Tests abgedeckt, einschließlich Sanitizing des gerenderten HTML-Inhalts.
  • Der Exportpfad ist auf eine explizite Berechtigung legal-consents:export abgesichert und dafür getestet.
  • Der Deep-Link-/Return-Target-Flow ist technisch gehärtet: Rücksprungziele werden serverseitig und clientseitig auf interne Pfade begrenzt, in der Session zwischengespeichert und nach Akzeptanz deterministisch wiederaufgenommen.

Einschränkungen

  • Die Staging-Testprotokolle markieren die Rechtstext- und Login-Szenarien noch als offen.
  • Im Repository ist kein abgeschlossener fachlicher End-to-End-Nachweis in der Zielumgebung dokumentiert; technisch ist der Rücksprung auf den validierten Ursprungspfad inzwischen implementiert und getestet.

Fundstellen

Technische Verifikation

Zum Stand vom 31.03.2026 wurden die relevanten Nx-Testtargets erneut geprüft:

  • pnpm nx run core:test:unit
  • pnpm nx run core:build
  • pnpm nx run auth:test:unit
  • pnpm nx run auth:test:types
  • pnpm nx run sva-studio-react:test:unit
  • pnpm nx run sva-studio-react:typecheck

Ergebnis: grün. Soweit Nx den Cache genutzt hat, wurden keine neuen Laufzeitnachweise gegen eine externe Zielumgebung erzeugt.

Fazit

Für die Punkte 1 bis 5 ist im Repository zum 31.03.2026 ein substanzieller Umsetzungsstand vorhanden. Besonders stark ausgeprägt sind Auth-Grundlagen, Accounts/Organisationen, zentrale Autorisierungslogik, Rollen-/Gruppen-Backend, direkte Nutzerberechtigungen sowie Rechtstext-Backend und zugehörige Admin-Oberflächen.

Nicht vollständig belegt oder nur teilweise umgesetzt sind vor allem:

  • die formale Umgebungsabnahme für Punkt 1
  • die formale fachliche Abnahme der vererbten Rollen-/Permission-Transparenz und der geforderten Nachweisartefakte in Punkt 3
  • belastbare End-to-End-Abnahmen unter Zielumgebungsbedingungen für Punkt 4
  • der vollständig dokumentierte fachliche E2E-Nachweis für Login-/Akzeptanzszenarien in Punkt 5
⚠️ **GitHub.com Fallback** ⚠️