Rückkanal: Case um Sender-Subject erweitern [ZSD 1.15.3]

Warum?

Relevante Links und Bemerkungen

Die Client-ID des Senders ist im Access Token als Subject Claim (sub) enthalten.

• Zugriffsprüfung hängt aktuell daran, dass man die caseId nicht kennt.
• Client-ID = sub Claim
• Bei erster create submission in case übernehmen
• Bei allen Sender-Zugriffen prüfen
• Klären: Soll das Event Log public bleiben oder auch abgesichert werden? -> public

Akzeptanzkriterien

1. Der Case wurde in der Datenbank um das Subject-Claim (sub) des Senders erweitert.
2. Wird ein neuer Case angelegt (POST /v1/submissions), so wird der sub Claim aus dem Access Token übernommen.
3. Bei folgenden Endpunkten wird geprüft, dass ein Sender nur zugreifen darf, wenn sein sub Claim mit dem Subject im Case übereinstimmt. Der Zugriff von Subscribern wird weiterhin über die Destination geprüft.

• ✅ POST /v1/submissions (sofern eine caseId angegeben wurde)
• ✅ PUT /v1/submissions/{submissionId}
• ✅ PUT /v1/submissions/{submissionId}/attachments/{attachmentId}
• ✅ GET /v1/replies
• ✅ GET /v1/replies/{replyId}
• ✅ PUT /v1/replies/{replyId}/accept
• ✅ PUT /v1/replies/{replyId}/reject
• ✅ GET /v1/replies/{replyId}/attachments/{attachmentId}
• ✅ GET /v1/cases/{caseId}/events

4. Der Endpunkt GET /v1/cases/{caseId}/events ist für Sender ohne Prüfung des sub Claims zugreifbar, wenn der Case schon vor der Implementierung der BiDiKo angelegt wurde (d.h. im Case ist kein sub hinterlegt.

5. Folgende Endpunkte sind für Sender ohne Prüfung des sub Claims zugreifbar:

• GET /v1/destinations/{destinationId}

Hinweis: Sofern neue Endpunkte noch nicht implementiert sind, muss die Absicherung bei der Implementierung (z.B. #509 (closed)) gemacht werden.

5. Fehlercodes in API-Spec und Doku auf Vollständigkeit prüfen/korrigieren. verschoben nach #1291 (closed) und #1227 (closed)

Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen)

• ...
• ...
• ...
• Definition of Done wurde geprüft