Skip to content

ADR-10: Weiterentwicklung PAP

Fragestellung

Im Berechtigungssystem (BeS) leidet der Policy Administration Point (PAP) unter funktionaler Überladung. Aktuell verwaltet er generelle Policies, Opt-Out-Status und individuelle Rückgabe-Policies monolithisch und eng gekoppelt, was unabhängige Deployments erschwert. Wie soll die Architektur des PAP im Zuge der Umstellung auf REST/FHIR evolutionär weiterentwickelt werden, um die Policy-Verwaltung und -Enforcement für neue FHIR-basierte Anwendungen möglichst flexibel zu gestalten?"

ADR-ID: ADR-001
Datum: 16.06.2026
Autor: ELGA-Architecture-Agent
Status: 🟡 proposed
TLP: 🟠 Amber
Tags: Berechtigungssystem · PAP · REST · FHIR · Microservice

Evolutionäre Aufteilung des Policy Administration Point (PAP) für REST/FHIR

Kontext

Der aktuelle Policy Administration Point (PAP) verwaltet generelle XACML‑Policies, Opt‑Out‑Status und individuelle Rückgabe‑Policies monolithisch und ist eng gekoppelt an die SOAP/WS‑Trust‑Schnittstelle. Dadurch sind unabhängige Deployments und die Anbindung neuer FHIR‑basierter Anwendungen (z. B. eEKP‑FHIR) kaum möglich. Das Berechtigungssystem muss gemäß § 21 GTelG 2012 betrieben werden und sämtliche Aktionen sind im Z‑L‑ARR zu protokollieren (§ 22 GTelG 2012) [Legal: GTelG 2012 | § 21] [Legal: GTelG 2012 | § 22]. Die geplante Umstellung auf REST/FHIR erfordert eine modulare PAP‑Architektur, die die bestehenden SOAP‑Instanzen (WIST, EBP, GDA, Service) weiterhin nutzt, aber über eine standardisierte REST‑Schnittstelle erreichbar ist. Nicht‑funktionale Anforderungen: Skalierbarkeit, unabhängige Deployments, geringe Latenz, Einhaltung von Sicherheits‑ und Protokollierungsanforderungen.

Entscheidung

Der PAP wird evolutionär in vier spezialisierte Service‑Instanzen (PAP WIST, PAP EBP, PAP GDA, PAP Service) eingebunden und über einen neuen Policy Administration Facade (PAF) bereitgestellt, der als REST‑Adapter fungiert. Der PAF nutzt das bestehende Transformation and Mapping Service (TMS) zur Übersetzung von FHIR‑Resources (Consent, Policy) in die vorhandenen WS‑Trust‑Transaktionen und umgekehrt. Jeder Service‑Instanz wird ein eigenes CapabilityStatement zugeordnet, sodass Rollen‑ und Applikations‑basierte Zugriffskontrolle über das EOAS und die ESF erfolgen kann. Die neue Facade wird als Kubernetes‑ready Container bereitgestellt, wodurch unabhängige Deployments, Rolling‑Updates und automatisierte Skalierung möglich sind.

Betroffene Systemkomponenten & Abhängigkeiten

flowchart TD
    ConsumerWIST["WIST (Opt‑Out Writer)"] -->|"REST/POST Consent"| PAF["Policy Administration Facade (REST)"
    ]
    ConsumerEBP["EBP (Policy Reader/Writer)"] -->|"REST/GET/POST Policy"| PAF
    ConsumerGDA["GDA (Teilnahmestatus) "] -->|"REST/GET Status"| PAF
    PAF -->|"SOAP/WS‑Trust"| TMS["Transformation & Mapping Service (Adapter)"
    ]
    TMS --> PAPWIST["PAP WIST Instanz"]
    TMS --> PAPEBP["PAP EBP Instanz"]
    TMS --> PAPGDA["PAP GDA Instanz"]
    TMS --> PAPService["PAP Service Instanz"]
    PAPWIST -->|"Policy Repository"| Repo["Policy Repository (XACML)" ]
    PAPEBP --> Repo
    PAPGDA --> Repo
    PAPService --> Repo
    Repo -->|"Löschaufträge"| CDM["Content Delete Management" ]
    PAPWIST -->|"Audit"| ZLARR["Z‑L‑ARR (Protokoll)" ]
    PAPEBP --> ZLARR
    PAPGDA --> ZLARR
    PAPService --> ZLARR

Verworfene Alternativen

  1. Beibehaltung des monolithischen SOAP‑PAP – verwirft die Möglichkeit unabhängiger Deployments und erhöht langfristig die Komplexität bei der Integration von FHIR‑Clients. 2. Komplette Neuimplementierung eines reinen REST‑PAP – würde massive Neu‑Entwicklung erfordern, die bestehenden SOAP‑Clients (WIST, EBP, GDA) brechen und ist nicht mit den aktuellen Betriebsverträgen vereinbar. 3. Einführung eines zusätzlichen Microservice ohne TMS‑Adapter – würde doppelte Logik für SOAP‑ und REST‑Übersetzung erzeugen und die Wartungslast erhöhen. Die gewählte Lösung nutzt vorhandene Komponenten (TMS, SOAP‑Instanzen) und minimiert Entwicklungsaufwand.

Konsequenzen

Positive: Ermöglicht unabhängige Deployments und Skalierung der einzelnen PAP‑Instanzen, reduziert Kopplung zwischen SOAP‑ und FHIR‑Clients, nutzt vorhandene Sicherheits‑ und Protokollierungsmechanismen, erleichtert zukünftige Erweiterungen (z. B. neue Consent‑Profile). Negative: Einführung einer zusätzlichen Übersetzungsschicht (TMS) erhöht die Latenz geringfügig und erfordert sorgfältige Synchronisation von Fehlermeldungen. Neutral: Bestehende SOAP‑Clients bleiben unverändert funktionsfähig, da die Adapter‑Schicht transparent ist.

Regulierung & Compliance

Das Berechtigungssystem muss gemäß § 21 GTelG 2012 von den ELGA‑Systempartnern betrieben werden und sämtliche Zugriffsrechte verwalten [Legal: GTelG 2012 | § 21]. Alle Aktionen des PAP sind im Z‑L‑ARR zu protokollieren, wie in § 22 GTelG 2012 gefordert [Legal: GTelG 2012 | § 22]. Die Verarbeitung personenbezogener Daten unterliegt den Vorgaben der DSGVO (Art. 32) und muss durch geeignete technische und organisatorische Maßnahmen (z. B. mTLS, JWT‑Validierung) gesichert sein. Die neue REST‑Schnittstelle muss die bestehenden Sicherheitsanforderungen (WS‑Trust, ATNA‑Protokollierung) beibehalten und die Token‑Validierung über den EOAS sicherstellen, um die Vorgaben der ELGA‑VO 2015 § 20 zu erfüllen [Legal: ELGA-VO 2015 | § 20].

ADR-ID: ADR-001
Datum: 16.06.2026
Autor: ELGA-Architecture-Agent
Status: 🟡 proposed
TLP: 🟠 Amber
Tags: PAP · REST · FHIR · PolicyManagement · Microservices

Evolutionäre Weiterentwicklung des Policy Administration Point (PAP) für REST/FHIR

Kontext

Der aktuelle Policy Administration Point (PAP) verwaltet generelle XACML‑Policies, Opt‑Out‑Status und individuelle Consent‑Policies monolithisch und eng gekoppelt. Diese funktionale Überladung erschwert unabhängige Deployments, verhindert skalierbare Erweiterungen und behindert die Integration neuer FHIR‑basierter Anwendungen. Gleichzeitig muss das PAP weiterhin die bestehenden WS‑Trust‑Schnittstellen, AT‑NA‑Audit‑Protokollierung und State‑ID‑Optimistic‑Locking unterstützen, um die gesetzlichen Vorgaben des ELGA‑Berechtigungssystems zu erfüllen. Nicht‑funktionale Anforderungen umfassen Modularität, Skalierbarkeit, unabhängige Release‑Zyklen, Durchgängigkeit der Audit‑Logs und vollständige Rückwärtskompatibilität zu bestehenden SOAP‑Clients. [Source: bes/aufbau_des_berechtigungssystems.md] [Source: bes/weiterfuehrende_detailbeschreibung.md] [Source: bes/schnittstellen_des_berechtigungssystems.md]

Entscheidung

Der PAP wird in drei fachlich abgegrenzte Microservices aufgeteilt: (1) Generic Policy Service für generelle XACML‑Policies und Teilnahmestatus‑Abfragen, (2) Individual Consent Service für individuelle Consent‑Policies, Signatur‑Dokumente und State‑ID‑Management, (3) Opt‑Out Service für reine Opt‑Out/Opt‑In‑Operationen der WIST. Jeder Service exponiert eine REST‑/FHIR‑Schnittstelle (FHIR Consent‑Ressource, custom Operations für Opt‑Out) und nutzt ein gemeinsames Policy Repository mit klar definierten Schemas. Ein WS‑Trust Adapter wird eingeführt, der die bestehenden SOAP‑Aufrufe (RST/RSTR) an die neuen Services weiterleitet, um Legacy‑Clients unverändert zu bedienen. Deployment erfolgt über Kubernetes mit separaten Helm‑Charts, CI/CD‑Pipelines (ArgoCD) und dedizierten Datenbank‑Instanzen (PostgreSQL) für jede Service‑Domäne. Audit‑Einträge werden weiterhin in Z‑L‑ARR und A‑ARR geschrieben. Diese Architektur ermöglicht unabhängige Skalierung, vereinfachte Wartung und eine schrittweise Migration zu FHIR‑basierten Anwendungen, ohne die bestehenden gesetzlichen und sicherheitstechnischen Verpflichtungen zu verletzen.

Betroffene Systemkomponenten & Abhängigkeiten

flowchart TD
    generic["Generic Policy Service"]
    individual["Individual Consent Service"]
    optout["Opt‑Out Service"]
    adapter["WS‑Trust Adapter"]
    repo["Policy Repository"]
    audit["Audit Log (Z‑L‑ARR / A‑ARR)"]
    eBP["EBP"]
    wist["WIST"]
    gda["GDA"]
    ets["ETS"]
    cdm["CDM"]
    eBP -->|"Read/Write Consent"| individual
    wist -->|"Store OptOut/OptIn"| optout
    gda -->|"Query Participation Status"| generic
    adapter -->|"Legacy WS‑Trust"| generic
    adapter -->|"Legacy WS‑Trust"| individual
    adapter -->|"Legacy WS‑Trust"| optout
    generic -->|"Persist Policies"| repo
    individual -->|"Persist Policies & Docs"| repo
    optout -->|"Persist Policies"| repo
    generic -->|"Log"| audit
    individual -->|"Log"| audit
    optout -->|"Log"| audit
    generic -->|"Delete Orders"| cdm
    individual -->|"Delete Orders"| cdm
    optout -->|"Delete Orders"| cdm

Verworfene Alternativen

  1. Monolith‑Erweiterung mit Feature‑Flags – verworfen, weil die enge Kopplung weiterhin unabhängige Deployments verhindert und die Code‑Basis weiter anwächst. 2. Kompletter Ersatz durch externes OPA/OPA‑Lite – verworfen, da die aktuelle XACML‑Policy‑Bibliothek und die verpflichtende WS‑Trust‑Schnittstelle erhalten bleiben müssen; ein vollständiger Austausch würde massive Migrationstests und rechtliche Prüfungen erfordern. 3. Duplizierung des PAP pro Konsument – verworfen, weil dies zu unverhältnismäßigem Wartungsaufwand, Inkonsistenzen im Policy‑Repository und erhöhten Betriebskosten führen würde.

Konsequenzen

Positive: Unabhängige Skalierung und Deployment‑Zyklen für jede Policy‑Domäne; Einfachere Integration neuer FHIR‑Clients über standardisierte Consent‑Ressourcen; Reduzierte Komplexität im Code‑Base; Erhalt der Rückwärtskompatibilität über den WS‑Trust‑Adapter. Negative: Erhöhter Betriebs‑ und Orchestrierungs‑Overhead (Kubernetes, Service‑Discovery, Daten‑Konsistenz); Migrationsaufwand für bestehende Daten und Clients; Notwendigkeit zusätzlicher Monitoring‑ und Logging‑Komponenten. Neutral: Das bestehende Sicherheits‑ und Audit‑Modell (AT‑NA, State‑ID, Optimistic‑Locking) bleibt unverändert, sodass die gesetzlichen Vorgaben weiterhin erfüllt werden.

Regulierung & Compliance

Die Entscheidung berücksichtigt die Betreiberpflichten des Berechtigungssystems gemäß ELGA‑VO § 20, wonach das System von der Bundesrechenzentrum Gesellschaft betrieben werden muss. Die fortlaufende Protokollierung aller Aktionen im PAP entspricht den Vorgaben des GTelG § 22 (Audit‑Log‑Pflicht) und § 28 (Sicherheits‑, Verfügbarkeits‑ und Wartungs‑Logging). Durch die Beibehaltung des WS‑Trust‑Adapters wird die gesetzlich geforderte Unterstützung von SOAP‑basierten Transaktionen gewährleistet, während die neue REST/FHIR‑Schnittstelle die zukünftige Interoperabilität fördert. [Legal: ELGA-VO 2015 | § 20] [Legal: GTelG 2012 | § 22] [Legal: GTelG 2012 | § 28]