Skip to content

Erweiterung / Konsolidierung Self-Service API

Warum?

Relevante Links und Bemerkungen

Zu klären

  • Umgang mit OAuth-Scopes -> SSP tauscht OAuth-Scopes aus, wenn Request geproxiet werden (siehe POST /v1/destinations-Endpunkt)
  • Umgang mit alten Daten (z.B. Zustellpunkt, der im ZSD gelöscht wurde, aber im SSP noch existiert)

Akzeptanzkriterien

  1. Die Destination Management APISelf-Service API-Spezifiakation ist um alle Zustellpunktverwaltungs-Endpunkte der Submission API erweitert
  2. Die Endpunkte im tag Zustellpunktverwaltung in der Submission API-Spezifikation als depecated markiert. In der Description ist ein Hinweis zu den neuen Endpunkten in der Destination Management APISelf-Service API-Spezifiakation enthalten. werden in die Kategorie Internal verschoben.
  3. Die SSP-Implementierung ist um neue Endpunkte der Destination Management APISelf-Service API erweitert ("Proxy")
  4. Bei Delete-Requests werden auch die Daten im SSP gelöscht.
  5. Es existiert ein neuer SSP-Endpunkt POST <ssp>/v1/destinations zum Anlegen einer neuen Destination
    • Request: { "name": "Test-Zustellpunkt für Fachverfahren XY", ... }
    • Response: { "destinationId": "620e9e5f-36d6-480a-acbe-25e92072c413" }
    • OAuth-Absicherung: https://schema.fitko.de/fit-connect/oauth/scopes/self-service-api/create:destination
  6. Der Request wird mit neuem OAuth-Token (Scope: "create:destination", aud: "submission-api-...") ohne die Attribute "name" und "submissionHost" an den Zustelldienst weiterleitet, um dort den Zustellpunkt anzulegen.
  7. API-Clients haben nach wie vor keinen Zugriff auf den POST /v1/destinations-Endpunkt des Zustelldienstes.
  8. Äquivalent zum Anlegen einer Destination über das UI, speichert das SSP beim Anlegen einer Destination über die Self-Service API die neu generierte Destination-ID, das Attribut "name" "submissionHost" und die Zuordnung zum User (Owner) als "Destination-Referenz" in der bisher schon existierenden Datenbank-Tabelle. Auf Basis der Client-ID aus dem Access Token (sub-Claim) ordnet das SSP hierbei die neue Destination dem User (Owner) zu, der den Client mit dieser Client-ID besitzt.
    1. Es gibt hierzu einen Test, der die korrekte Zuordnung einer Destination zum User, dessen API-Client die Destination via Self-Service-API angelegt hat, prüft.
  9. Das SSP legt für diese neue Destination im OAuth-Server für den aktuellen API-Client die Scopes manage:destination:..., subscribe:destination:... und https://schema.fitko.de/fit-connect/oauth/scopes/self-service-api/manage:destination:<id> mit passender aud an. Die Zuordnung ist auch in der UI (in der Client-Verwaltung) sichtbar.
    1. Hierzu gibt es einen Test, der prüft, ob alle drei Scopes angelegt werden.
  10. Neu: Das SSP prüft beim Bearbeiten (PUT/PATCH) einer Destination, beim Hochladen neuer JWKs (POST /v1/destinations/{destinationId}/keys) und beim Löschen einer Destination (DELETE) über die Self-Service API, ob der anfragende Client den passenden https://schema.fitko.de/fit-connect/oauth/scopes/self-service-api/manage:destination:<id>-Scope besitzt (insb. wichtig für name-Attribut).
  11. NEU: Die Self-Service-API enthält das replyChannels-Attribut im Services-Objekt.
  12. Neu: Die Fehlermeldungen des Zustelldienst werden auch über die Self-Service-API ausgegeben.
  13. Prüfen beim PO-Review: Nebenwirkungen beim Erstellen der OAuth-Scopes mit #385 (closed)

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

Edited by Marco Holz