Auflösen der destinationIds im ZSD über das SSP-Backend
User Story
Alle Endpunkte, die derzeit auf subscribe-destination:<id> oder manage-destination:<id> prüfen, werden dahingehend angepasst, dass sie auf die Scopes https://schema.fitko.de/fit-connect/oauth/scopes/subscribe-destinations oder https://schema.fitko.de/fit-connect/oauth/scopes/manage-destinations prüfen. Die destinationIds werden aus dem neu angelegten Endpunkt des SSP-Backends GET /internal/destination-permissions bezogen. Dabei wird der vom Onlinedienst oder Fachverfahren erhaltene JWT an das SSP weitergegeben. ACHTUNG: In der Produktivumgebung ist hierfür ein Proxy nötig, da das SSP-Backend in einem anderen Data-Center läuft.
Why
Der Zustelldienst muss bspw. bei einem Aufruf von GET /v1/submissions wissen, welche Submissions welcher Destinations zurückgegeben werden sollen. Dies steht nun aber nicht mehr im Oauth-Scope, denn dieser lautet nur noch allgemein https://schema.fitko.de/fit-connect/oauth/scopes/subscribe-destinations. Deshalb muss der ZSD das SSP-Backend anfragen, welche destinationIds zum Client gehören.
Acceptance criteria
-
Alle Endpunkte, die derzeit über die oben genannten Scopes autorisiert werdem, wurden identifiziert. -
Die Autorisierung dieser Endpunkte erfolgt nun nach dem neuen Konzept. -
Mit einem Client-JWT kann man nur auf eigene Ressourcen zugreifen. Das Zugriffskonzept wird in keiner Weise aufgeweicht.
Implementation plan (to be completed by the developer)
-
... -
... -
... -
Definition of Done was checked.