Skip to content

[Epic] Aufheben Limit Destinations

Why

Aktuell ist die Anzahl der Destinations, welche von einem Client / Owner verwaltet werden können aufgrund der Beschränkungen im Header des Token übergebenen OAuth Scopes limitiert. Dies gilt sowohl für die Self-Service API als auch für das Self-Service Portal.

FIT-Connect soll weiterhin kontinuierlich wachsen und besonders für Großanbindende ist die Aufhebung dieser Limitierung von besonderer Bedeutung - hier haben wir bisher aus den Nutzungsprojekten den Wunsch erhalten bis zu 5000 Destinationen unterstützen zu können, siehe auch #1230 (comment 123147).

Goal

Ein Owner soll zukünftig in der Lage sein, über einen API-Client bis zu 5000 Destinations verwalten zu können.

Links, Notes, Remarks

(Click to expand): Flowcharts
sequenceDiagram
    autonumber
    participant CL as API-Client
    participant ZSD as Submission API
    participant SSP as Self-Service API

    CL ->>+ ZSD: Get all Submissions for pickup
    note right of CL: HTTP GET /v1/submissions<br>Auth: …/subscribe:destination

    ZSD ->>+ SSP: Get Destination IDs for API-Client<br>(client_id)
    note right of ZSD: HTTP GET /internal/destination-permissions<br>Auth: <use_api_client_token>

    SSP -->>- ZSD: List of Destination IDs
    note over SSP, ZSD: ["<uuid1>", "<uuid2>", …, "<uuid5000>"]

    ZSD -->>- CL: List of Submissions for pickup<br>(from API-Clients' Destinations)
(Click to expand): Migration der Scopes in der Tokenausstellung und in der Prüfung der Scopes im Zustelldienst
  1. (Aktuell) Client -> /token -> Token mit manage:destination:<id> -> Token-Validator -> Zustelldienst
  2. Client -> /token -> Token mit manage:destination:<id> https://schema.fitko.de/fit-connect/oauth/scopes/submission-api/manage:destination -> Token-Validator -> Zustelldienst (verwerfen der zusätzlichen langen Berechtigung)
  3. Client -> /token -> Token mit manage:destination:<id> https://schema.fitko.de/fit-connect/oauth/scopes/submission-api/manage:destination -> Token-Validator -> Zustelldienst (lesen der zusätzlichen langen Berechtigung und Abrufen des /token/introspect Endpunkts für diesen) -> OAuth-Server Antwort mit https://schema.fitko.de/fit-connect/oauth/scopes/submission-api/manage:destination:<id>. Muss zur Liste der Berechtigungen hinzugefügt werden.
  4. Prüfung im Zustelldienst anpassen: Nur noch lange Scopes prüfen: https://schema.fitko.de/fit-connect/oauth/scopes/submission-api/manage:destination:<id>. Hier müssen alle Scopes in Tests / Test Tokens angepasst werden.
  5. Einführung eines Test Doubles (z.B. ein Mock) um im Test keine signierten Tokens verwenden zu müssen.
  6. Entfernen der Token-Validator Middleware, da Zustelldienst die Signatur der Tokens über den /token/introspect prüft.
  7. (Ziel) Client -> /token -> Token mit https://schema.fitko.de/fit-connect/oauth/scopes/submission-api/manage:destination -> Zustelldienst -> /token/introspect -> https://schema.fitko.de/fit-connect/oauth/scopes/submission-api/manage:destination:<id>
(Click to expand): Sonstige Anmerkungen

Stories

Board

Acceptance criteria

  1. 5.000 Destinations pro Owner sind zu nutzen Update 23.4 - keine Einschränkungen auf der Owner Ebene
  2. 5.000 Destinations pro Client sind zu nutzen
    • falls Performanceprobleme bei irgendwelchen Endpunkten erwartet werden, reduzieren wir diesen Wert (z.B. Polling der Submissions fragt alle destinationen des Clients ab)
  3. Per Config sind initial 1000 Destinations pro Owner und 1000 5000 Destinations pro Client auf allen Umgebung einzurichten (das soll bei Bedarf über die Config bis auf 5000/5000 nach einer weiteren Prüfung angehoben werden können) (Update 23.04)
  4. Durch die Umstellung wird die Performance des Gesamtsystems nicht beeinträchtigt
  5. Durch die Umstellung wird die Sicherheit des Gesamtsystems nicht beeinträchtigt
  6. Umstellung auf die neuen Scopes ist in der Submission API implementiert
  7. Umstellung auf die neuen Scopes ist in der Self-Service API implementiert
  8. SSP funktioniert auch mit der größeren Anzahl möglicher Destinations unverändert
  9. Implementierung ist nicht mit einem breaking change verbunden
  10. Definition of Done was checked.

Follow-Ups

  • Nach Abschluss dieser Entwicklung wird die Übernahme der SSP durch das Team Zustelldienst umgesetzt #1278 (closed)
  • Limits des Owners (oder des Berechtigten) sind nach Abschluss der Teamfunktionalität zu überprüfen #330 (closed)
Edited by Wojciech Gdaniec