[Epic] ZBP Adapter-NdB: um Zentrales Bürgerpostfach (ZBP) in FIT-Connect anzubinden

Warum

Die BundID ist eine zentrale Komponente der digitalen Verwaltungsleistungen und ermöglicht zum einen allen Bürgern eine einfache, schnelle sowie sichere Authentifizierung in den Onlinediensten. Zum anderen können und sollen über das Zentrale Bürgerpostfach der BundID (ZBP) Bescheide und Nachrichten an die Bürger zugestellt werden.

Um als Fachverfahren Nachrichten an das ZBP zu versenden, ist aus Sicherheitsgründen eine Verbindung zu dem NdB zwingend erforderlich. Fachverfahren haben jedoch nur sehr selten einen Anschluss an das Netz des Bundes. Angesichts der nicht vorhandenen Anbindung der Fachverfahren an das NdB, soll im engen Austausch mit der BundID der ZBP-Adapter zwischen dem Zustelldienst und dem Zentralen Bürgerpostfach implementiert werden, um Kommunen ohne Anschluss an das NdB einen sicheren Zugriff zu ermöglichen. Der ZBP-Adapter wird innerhalb des Verbindungsnetzes (NdB-VN) betrieben und hat die Aufgabe über einen Zustellpunkt von FIT-Connect ZBP Nachrichten und Statusupdates zu empfangen/ abzurufen und diese dann mit Hilfe der SDKs an ZBP zu übermitteln. Eine Nachricht an das ZBP soll in FIT-Connect an ein Case geknüpft werden, jedoch sollen Nachrichten auch ohne einen früheren Antrag über den Zustelldienst von den Nutzern versandt werden können. (TODO: Case als Klammer für BiDiKo - zu klären ob am Case die externe ID angegeben werden sollte um Cases zu bündeln)

Follow-Up:

• #1113 (closed)

Ziel

Der FIT-Connect ZBP-Adapter schafft eine sichere Schnittstelle zwischen den an FIT-Connect angebundenen Fachverfahren und dem Zentralen Bürgerpostfach. Der ZBP-Adapter hat eine Anbindung an das NdB (Netz des Bundes). Somit sollen Fachverfahren (auch ohne eine Anbindung an das NdB) Nachrichten (in der nächsten Ausbaustufe auch Statusupdates) an das ZBP versenden können.

Die für de Abbildung im ZSD notwendigen Voranalysen sollen in den Stories #2006 und #2007 (closed) erfolgen und die Erkenntnisse daraus in dieses EPIC eingearbeitet werden. Ergebnis dieser Stories ist, dass für die Übertragung bestehende Logik genutzt werden soll und für die Nachrichten und Statusupdates eine oder zwei spezielle destinationen angelegt werden (TODO: LEIKA und Schema bzw. kennzeichnug als Sonderdestination ist festzulegen - bis hin zum Routingdienst)

Nicht-Ziele:

• eigenes EPIC SDKs: Nachrichten in das ZBP Postfach ablegen
• eigenes EPIC SDKs: Statusupdates in das ZBP Postfach ablegen
• eigenes EPIC SDKs: Optimierung Authentifizierungsprozess und Übergabe an FV

Links, Hinweise, Bemerkungen

• Integrationsumgebung BundID: https://int.id.bund.de/de
• Doku BundID: https://ssp.id.bund.de/ip?id=downloads
• FIT-Connect Konzept ZBP Adapter: https://wiki.fit-connect.fitko.dev/de/Konzeption/ZBP-Adapter

Einordnung in die gesamte BundID Thematik:

Als Hilfe zur Abgrenzung: Das folgende Bild zeigt alle EPICs rund um die BundID entlang des E2E Antragsprozesses. In diesem Epic geht es um den STEP 2 aus dem Diagramm.

• STEP 1: #2016 (closed)
• STEP 2: #714
• STEP 3: #82
• STEP 4: #tbd

Stories

1. #2075 Initiales Aufsetzen (Repos etc.) [in Abstimmung mit TEAM INF]
2. #2069 Mock-Server für die Entwicklung [in Abstimmung mit TEAM SDK]
   • ab Test beim Deployment gegen die BundID Systeme Tests laufen lassen
3. #tbd Destination für ZBP Adapter anlegen [in enger Abstimmung mit TEAM SSP]
   • TODO: eigene LEIKA / Schema oder Anlage als Spezial-Destination
4. #tbd Erweiterung der SDKs, dass nicht nur direkt, sondern über den ZSD die ZBP-Nachrichten versendet werden [TEAM SDK]
5. #2064 ZBP Adapter holt Nachrichten ab
6. #2065 ZBP Adapter leitet die Nachricht an ZBP
7. #2066 ZBP Adapter versendet Empfangsbestätigung
8. #2189 (closed) Testdeployment [in Abstimmung mit TEAM INF]
9. #2087 Doku
10. #tbd Video

Akzeptanzkriterien

1. ZBP-Adapter ist als eigenes Artefakt im Verbindungsnetz (NdB-VN) deploybar und erfüllt die erforderlichen Kriterien.
2. Fachverfahren und Onlinedienste können über neuen Endpunkt im ZSD(mit SDKs) die Nachrichten(mit Anhängen) an das ZBP hinterlegen (mit & ohne Submission-im-Case-Bezug und inkl. der Signatur mit der Behörden-PKI).[TEAM ZSD & TEAM SDK] (TODO: ApplicationID der BundID als Klammer am Case)
   • mögliche Auswirkungen auf die OAuth Scopes zu festzulegen 
3. Nachrichten an das ZBP bekommen immer einen neuen Case, da neuer Sender und Empfänger
4. ZBP-Adapter ruft Nachrichten vom ZSD ab. (mit SDKs)
5. ZBP-Adapter entschlüsselt(mit SDKs) die Nachricht und sendet die Nachricht mit den SDKs an das ZBP.
6. Es wird vom ZBP-Adapter ein accept/reject Event erstellt und mit den SDKs an den ZSD weitergeleitet (in Abhängigkeit von der Antwort des ZBP).
   • Sonstige Events entsprechen dem Event der Submission und werden ebenfalls am Case im Event-Log hinterlegt.
7. Der öffentliche Schlüssel des ZBP-Adapters ist über einen Endpunkt des ZSD abrufbar (Verwaltungs-PKI).
8. ZBP-Adapter kann den öffentlichen Schlüssel über einen Endpunkt des ZSD hinterlegen.
9. Löschfristen der Nachrichten an das ZBP entsprechen den Löschfristen, welche an Submissions/ Replies geknüpft sind.
10. ZBP Adapter, der ZBP Branch und die SDKs sind als Release Candidate auf einer eigenen Testumgebung veröffentlicht
11. Webhooks und Callbacks sollten sich an den fachlichen Prozessen der Submission orientieren (fachlich aktuell kaum Bedarf ZBP-Adapter steht im NdB und kann eh nicht informiert werden, das ist bei künftigen Postfächern aber ggf. anders)
12. Verständliche Dokumentation zur Nutzung der neuen Funktionen wurde erstellt.
13. Ein Videotutorial zu den neuen Funktionen steht im SSP zur Verfügung.
14. ...
15. Definition of Done wurde überprüft.

Optimierungspotentiale im Zusammenhang mit der Integration

1. [ ] Es ist unideal, dass die Nachrichten-Signatur (genannt "sha512sum") vom Brückenkopf und nicht vom Autor erstellt werden muss. Wäre diese Signatur vom Autor, könnte man die Herkunft nachweisen und verhindern, dass die Nachricht auf dem Weg unerlaubt modifiziert wird. Eine Signatur vom Brückenkopf hat jedoch sehr viel weniger Nutzen.
2. [ ] Es ist unideal, dass ein "authorToken" in Form eines ablaufenden JWTs mit übergeben werden muss. Das derzeitige Setup sieht eine asynchrone Nachrichtenübermittlung mit mehreren Mittlern vor. Wenn der JWT jedoch in 30min abläuft, verliert man die Robustheit der Asynchronität: Schafft die Nachricht es nicht rechtzeitig durch die Systeme, ist auch kein Retry mehr möglich.
3. [ ] Kleinigkeit: Stimmt die tatsächliche Größe eines Attachments nicht mit der übermittelten "contentLength" überein, führt dies zu HTTP 500.

Mögliche Folgeaktivitäten

1. Aufstellung im ITZBund #2141 team::INF
   • Der ZBP-Adapter steht im Verbindungsnetz (NdB-VN) und ist damit vom restlichen Netz abgeschirmt (einzige Kommunikation über API zum ZSD und REST-API/ ZBP)
   • VPKI Schlüssel ist beantragt
2. Klärung ob und wie Behörden-PKI für FIT-Connect genutzt werden könnte / sollte

Offene Fragen