[Epic] DestinationSignature kann über die Destination API bezogen werden

Warum

Die DestinationSignature wird benötigt, als Erkennungsmerkmal sowie Information für die Eintragung in die Landesredaktionssysteme. Wenn diese Information direkt mit gesendet wird, kann das Anbindungsprojekt diese direkt verwenden. (Anfrage von Hamburg)

Ziel

Bislang wurde die DestinationSignature vom SSP auf der Basis der Informationen aus dem ZSD erzeugt. Mit der Destination API können Zustellpunkte direkt im ZSD angelegt und geändert werden. Um eine DestinationSignature zu erhalten, muss diese manuell aus dem SSP bezogen werden.

Im ersten Schritt wird für ausgewählte Nutzer in der SSP-API die Möglichkeit geschaffen, die DestinationSignatures zu beziehen. Im zweiten Schritt erstellt der ZSD die DestinationSignatures und gibt sie über die ZSD-API aus. Da dies aufgrund der Signaturprüfung der Adressierungsinformationen einen breaking change darstellt, erfolgt der zweite Schritt erst nach einer angemessenen Vorbereitungszeit.

Strategische Ziele

• Produktentwicklung und technische Innovation: Sachbearbeiter generisch unterstützen
• Kunden gewinnen und langfristig binden
• Strategische Partnerschaften und Allianzen aufbauen und pflegen

Links, Hinweise, Bemerkungen

Der Routingdienst erzeugt bereits die JWKS-URL auf der Basis des Issuers. Die resultierende URL wird gegen eine Liste erlaubter Issuer (destinationSignature.keystoreUrls) geprüft. Es müssen pro Umgebung jeweils das SSP und der ZSD in diese Liste aufgenommen werden.

Anzupassende Doku:

• https://docs.fitko.de/fit-connect/docs/sending/get-destination/#checkDestinationSignature

Umsetzung

Die Erzeugung und Signierung von DestinationSignatures wird in den Zustelldienst verlegt. Die bereits existierenden DestinationSignatures, die vom SSP erzeugt wurden müssen ihre Gültigkeit behalten.

Die Prüfung der DestinationSignatures muss in Zukunft wie folgt ablaufen:

1. Prüfe den Issuer, dass seine Domain mit .fit-connect.fitko.net endet (.fit-connect.fitko.dev beim Testsystem)
2. Hole das JWKS vom Issuer (Issuer + /.well-known/jwks.json), z.B. https://test.fit-connect.fitko.dev/.well-known/jwks.json
3. Prüfe den Schlüssel gegen das JWKS.

Stories

Stufe 1

1. Das SSP stellt für ausgewählte Nutzer mit dringendem Bedarf in der (deprecated) SSP-API einen Endpunkt zur Verfügung, unter dem die DestinationSignatures bezogen werden können. team::SSP #2426
2. Die Dokumentation (Signaturprüfung der Adressierungsinformationen) wurde angepasst, um das neue Vorgehen bei der Prüfung von DestinationSignatures abzubilden team::Doku #2427
3. Die Anbindungsprojekte wurden informiert, zu prüfen, ob sie die DestinationSignatures prüfen und die Prüfung ggf. anzupassen team::AM
   • Siehe Entwurf unten: #2379 (comment 179142)
4. Der RTD wurde angepasst, um die neue Prüfung von DestinationSignatures umzusetzen team::RTD #2429
   • Anpassung der Config destinationSignature.keystoreUrls, sodass auch ZSD-Zertifikate akzeptiert werden.
5. Die SDKs wurden angepasst, um die neue Prüfung von DestinationSignatures umzusetzen, sodass auch ZSD-Zertifikate akzeptiert werden. team::SDK #2428

Stufe 2

6. ZSD generiert die DestinationSignature bei Änderungen an einer Destination team::ZSD #2458
7. Der ZSD implementiert den Endpunkt für den Bezug von DestinationSignatures team::ZSD #2458
8. Das SSP nutzt den Endpunkt für den Bezug von DestinationSignatures team::SSP #2459
9. ...

Akzeptanzkriterien

1. Es gibt eine angemessene Vorbereitungszeit für die betroffenen Anbindungsprojekte
2. Es gibt eine schnelle Übergangslösung für einzelne Anbindungsprojekte mit dringendem Bedarf.
3. Der Abruf von DestinationSignatures ist über die Destination API verfügbar.
4. Die DestinationSignatures können weiterhin über das SSP bezogen werden.
5. Es treten keine Fehler bei der Validierung gültiger DestinationSignatures auf.
6. ...
7. Definition of Done wurde überprüft.

Mögliche Folgeaktivitäten

Offene Fragen

• Wie prüfen die Clients, ob das Token von einem berechtigten Dienst ausgestellt wurde?
  • Pragmatisch: Prüfe den Issuer, dass seine Domain mit .fit-connect.fitko.net endet (.fit-connect.fitko.dev beim Testsystem)
  • Alternativ: Wir stellen eine (signierte) Liste von berechtigten Issuern zur Verfügung.