Prüfung von Events im Zustelldienst

Zur Prüfbarkeit der Datenübermittlung erhält ein Case einen Event Log, das Security Event Token (SET) gemäß RFC 8417 und dem Dokument Event Log speichert. Manche der Events werden vom Zustelldienst erzeugt, manche werden extern über die API zugeliefert.

Anmerkung: Dieses Issue ist teilweise schon umgesetzt. Ziel dieses Issue ist die Prüfung der Akzeptanzkriterien.

Akzeptanzkriterien

• Die SET werden persistent gespeichert
  • ✔ EventService.writeEventLogEntry
• Der Zustelldienst erzeugt bei allen definierten Events ein SET und speichert sie
  • https://schema.fitko.de/fit-connect/events/create-submission
    • ✔ SubmissionService.createSubmission: eventService.createAndWriteEvent(submission, CREATE_SUBMISSION);
  • https://schema.fitko.de/fit-connect/events/submit-submission
    • ✔ SubmissionService.addSubmissionDataAndSubmit: eventService.createAndWriteEvent(submission, event, payload);
  • https://schema.fitko.de/fit-connect/events/notify-submission
    • ✔ CallbackService.asyncCallbackForNewSubmissionsAndLogEvent: eventService.createAndWriteEvent(submission, NOTIFY_SUBMISSION, NotifyType.NOTIFY_TYPE_CALLBACK.asMap());
    • ✔ SubmissionService.getSubmittedSubmissionsForDestinations: eventService.writeNotifyEventIfRequired(submission);
  • Neu: https://schema.fitko.de/fit-connect/events/deliver-submission
    • ➡ Das Event gibt es noch nicht -> #292
  • https://schema.fitko.de/fit-connect/events/forward-submission (wird durch den Subscriber erstellt)
  • https://schema.fitko.de/fit-connect/events/reject-submission (wird durch den Subscriber erstellt)
  • https://schema.fitko.de/fit-connect/events/accept-submission (wird durch den Subscriber erstellt)
  • https://schema.fitko.de/fit-connect/events/delete-submission
    • ➡ Es wird derzeit noch nicht gelöscht -> #91 (closed)
• Der Zustelldienst nimmt über die API die definierten Events an und speichert sie. Aktuell ist das die Übermittlung von SETs durch den Subscriber für die Events forward, accept und reject
  • ✔ CasesAPI.processCaseEvent
• Es werden nur SET angenommen, deren Schema und Signatur erfolgreich geprüft wurden
  • Der Zustelldienst prüft Signaturen auf Gültigkeit
    • ✔ SecurityEventTokenValidator.validateSignature
  • jti ist eindeutig
    • ✔ SecurityEventTokenValidator.validateJtiClaim: eventLogRepository.findByTokenId(setParseResult.getJti()).isPresent()
• Zusätzliche Prüfungen für Subscriber
  • Im SET Header sind die drei Angaben typ, algund kidenthalten und keine weiteren Angaben.
    • ✔ SecurityEventTokenValidator.validateHeader
    • typ hat den Wert secevent+jwt
    • alg hat den Wert PS512
    • kid entspricht einem vorliegenden Schlüssel
  • Der von kidreferenzierte Schlüssel …
    • … hat den Eintrag "alg":"PS512"
      • ✔ SecurityEventTokenValidator.validateSignKey: rsaKey.getAlgorithm().equals(JWSAlgorithm.PS512)
    • … hat den Eintrag key_ops":["verify"] (das Array darf weitere Werte enthalten)
      • ✔ SecurityEventTokenValidator.validateSignKey: rsaKey.getKeyOperations().size() == 1 && rsaKey.getKeyOperations().contains(KeyOperation.VERIFY)
    • … hat eine gültige Zertifikatkette aus der V-PKI (Abschaltbar in der Testumgebung) (Wird auch in #119 (closed) gebraucht. Dort sind auch die entsprechenden Vorgaben in den Akzeptanzkriterien definiert)
      • ➡ -> #119 (closed)
  • Die SET Signatur konnte mit dem Schlüssel verifiziert werden
    • SecurityEventTokenValidator.validateSignature: signedJWT.verify(jwsVerifier)
  • SET Payload:
    • Entscheidung vom 17.1.22: Wenn $schema gesetzt ist, dann wird auch das Schema des Events durch den Zustelldienst geprüft.
    • Der SET Payload ist valide gemäß dem angegebenen ($schema) JSON Schema
      • SecurityEventTokenValidator.validateSetPayloadSchema
    • Die in iss enthaltene Destination-ID ist die der Destination, an die die Submission gesendet wurde.
      • ✔ SecurityEventTokenValidator.validateIssClaim
    • iat: Ist ein UNIX-Timestamp der in der Vergangenheit liegen, aber nach dem letzten status-verändernden Event der Submission.
      • ✔ SecurityEventTokenValidator.validateIatClaim
    • Die in sub enthaltene Submission-ID gehört zu dem Case, der in der URL angegeben ist
      • ✔ SecurityEventTokenValidator.validateSubClaimAndFetchSubmission
    • Die in txn enthaltene Case-ID gehört zu einem Vorgang, auf den der Subscriber Zugriff hat
      • CasesAPI.processCaseEvent: @PreAuthorize("@auth.canSubscribeToDestinationOfCase(authentication, #caseId)")
    • und entspricht der Case-ID in der URL.
      • ✔ SecurityEventTokenValidator.validateTxnClaim: transactionId.equalsIgnoreCase(caseId.toString())
    • Enthaltenes Event existiert und darf vom Subscriber angelegt werden
      • ✔ EventService.parseAndValidateSecurityEventToken: if (set.getEvent().getIssuer() == FitConnectEventIssuer.ZUSTELLDIENST) {

Legende:

• ✔ Prüfung ist bereits vorhanden oder wurde ergänzt
• 🚧 Offene Aufgabe
• ➡ Aufgabe in/Abhängig von einer anderen Story

Durchführungsplan

• Branch: https://git.fitko.de/fit-connect/zustelldienst/-/commits/297-validate-events