Skip to content

Abfragen der Destinations eines API-Clients ermöglichen

User Story

Why

Das Konzept, alle UUIDs aller zugreifbaren Destinations in den Scope eines Tokens zu packen, skaliert nicht. Daher möchten wir aus dem ZSD heraus diese Information aus dem SSP abfragen. Das SSP hält die Information, welcher Client auf welche Destinations berechtigt ist.

Links, Notes, Remarks

Im SSP gibt es bereits einen GET /v1/destinations-Endpunkt. Dieser ist Teil der öffentlichen Self-Service-API und es werden Lookups zurück zum ZSD vorgenommen. Dieser Endpunkt ist für unseren Anwendungsfall also nicht geeignet. In Abgrenzung zur öffentlichen API schlagen wir daher den /internal/-Prefix für den neuen Endpunkt vor:

> http get https://ssp-api/internal/destination-permissions
> Authorization: Bearer <Client-JWT>
> Accept: application/json

< {"destinationIds": ["uuid1", "uuid2", "uuid3", "uuid4", "uuid5", …]}

Es ist nicht nötig, neue Oauth-Scopes einzuführen, oder diesen Endpunkt gesondert abzusichern, weil der ZSD schlichtweg den vom Client erhaltenen JWT weitersenden kann. Die Prüfung auf die neuen OAuth-Scopes (siehe unten) muss hier auch nicht erneut erfolgen, weil diese direkt im ZSD passiert.

Der Lookup soll folgendermaßen erfolgen:

  1. Ist das subject des Oauth-Tokens eine clientId im Sinne der SSP.clients-Tabelle, sollen die zugehörigen destinationIds aus der allowed_destinations-Tabelle zurückgegeben werden.
  2. Ist das subject des Oauth-Tokens der Form -internal-ssp-dest-<uuid> soll die extrahierte UUID zurückgegeben werden. Dieser Hack ist nötig, um den Spezialfall "ad-hoc-clients" zu unterstützen: Das SSP bietet Endpunkte zur Self-Service-API an und solche für die eigene Administrations-UI. Hier müssen gelegentlich authentifizierte Requests gegen den ZSD durchgeführt werden. Dazu legt das SSP derzeit pro Destination einen passenden OAuth-Client mit dem namen -internal-ssp-dest-<destinationId> an (per master token) und loggt sich für den Client ein, um mit dem (nun stark unterprivilegierten) Token den ZSD anzurufen. Dieser umständliche Mechanismus ist im Fall der Administrations-UI unumgänglich, weil hier noch gar kein Client im Sinne der clients-Tabelle vorliegt. Für die Self-Service-API wäre dieser Schritt eigentlich nicht nötig, weil das SSP den im Request erhaltenen Token einfach an den ZSD weitersenden könnte und dieser würde auf einen Client im Sinne der clients-Tabelle aufgelöst; wir haben uns aber entschieden, diese Logik des SSP im Rahmen dieses Features nicht auch noch zu ändern.

  • Im Epic gibt es eine Mermaid Grafik: #1230 (closed)

  • Kompression der Antworten (gzip) machen wir erstmal nicht an, da die Anzahl der Nutzer die so viele Destinations haben nicht sehr groß ist. Der Implementierungsoverhead

Acceptance criteria

  1. Das SSP hat einen neuen internen API Endpunkt der zu einem client-JWT die zugehörigen destinationIds liefert. Dieser Endpunkt kann sowohl Clients im Sinne der clients-Tabelle auflösen, als auch vom SSP erstellte ad-hoc-clients.
  2. Der Endpunkt liefert bis zu 5000 destinationIds ohne Pagination.
  3. Allen bekannten Fachverfahren-Clients (aktuell noch Subscriber im SSP genannt) werden die folgenden Scopes in einer Migration hinzugefügt (siehe OAuthScopeMigration.java im SSP-Backend, alternativ DB Change).
    • https://schema.fitko.de/fit-connect/oauth/scopes/subscribe-destinations
    • https://schema.fitko.de/fit-connect/oauth/scopes/manage-destinations
  4. Bei existierenden API-Clients müssen die Scopes (manage|subscribe):destination:<uuid> entfernt werden.

Implementation plan (to be completed by the developer)

Edited by Fabian Sudau