Prüfung des Leistungsschlüssels im Zustelldienst (Part 1)

Warum?

Momentan erlaubt der Zustelldienst, Anträge zu beliebigen Verwaltungsleistungen an beliebige Zustellpunkte (Destinations) zu schicken, auch wenn der jeweilige Zustellpunkt dieser Verwaltungsleistung gar nicht unterstützt.

Um Fehlzustellungen bereits möglichst früh zu erkennen und zu unterbinden, soll der Zustelldienst prüfen, ob die über den Endpunkt POST /v1/submissions übergebene Leistungsschlüssel der Verwaltungsleistung (serviceType -> identifier) in der Liste der Services der adressierten Destination (GET /v1/destinations/{destinationId} -> services[] -> identifier) vorhanden ist.

In diesem Issue (Part 1) sollen Fehler zunächst nur geloggt werden, um die Auswirkungen dieser Änderung zu bewerten. Später sollen ungültige Einreichungen in #924 (closed) abgelehnt werden.

Relevante Links und Bemerkungen

Akzeptanzkriterien

1. Wenn die über den Endpunkt POST /v1/submissions übergebene Leistungsschlüssel nicht in der Liste der Services der adressierten Destination vorhanden ist, wird ein entsprechender Log-Eintrag erzeugt, nach dem über einen eindeutigen Error-Code (z.B. submission-service-identifier-mismatch o.ä.) einfach gefiltert werden kann.
2. Der Log-Eintrag enthält die Submission-ID, die OAuth-client_id des Senders, die Destination-ID des adressierten Zustellpunktes und den in der Submission gewünschten (aber nicht passenden) Leistungsschlüssel.
3. In der Dokumentation wird beschrieben, dass der übergebene Leistungsschlüssel in der Liste der Services der adressierten Destination vorhanden sein muss.

Durchführungsplan

• Überlegen, ob die Lösung mittels eigener Felder im Logging Output oder als suchbare Nachricht geschrieben werden sollte. Muss nicht unbedingt so ein Key (wie oben submission-leika-key-mismatch) sein sondern kann auch anderes aber immernoch eindeutig identifizierbares sein ("greppable")
• Im Spring Service hinter dem POST Endpunkt prüfen, ob der Leistungsschlüssel der Verwaltungsleistung in der Liste ist
• Wenn nicht, loggen. Wenn schon, nichts tun.
• Hier einen Absatz oder so schreiben: https://docs.fitko.de/fit-connect/docs/getting-started/submission/structure / Ist durch https://docs.fitko.de/fit-connect/docs/sending/start-submission/#eine-neue-einreichung-anlegen dokumentiert
• Optional: Vorarbeiten für das Ticket #924 (closed), dass man Prüfung und Aktion trennt.
• Optional: Vorarbeiten für das Ticket #924 (closed), dass das "scharfschalten" über eine Umgebungsvariable möglich gemacht wird.
• STAGE und PROD Logs erfasst und evaluiert.
• Betroffene vor der Aktivschaltung (Part 2) informiert (@Team Operations, @Laura_Elges).
• Eventuell notwendige Lösungsansätze für Betroffene wurden ausgearbeitet.
• Betroffene haben entsprechende Maßnahmen umgesetzt und bestätigt, dass die Prüfung aktiv geschaltet werden kann. (@Team Operations). https://git.fitko.de/fit-connect/planning/-/issues/2566