Skip to content

Konzept SSP-API prüfen

User Story

  • Als Team Zustelldienst
  • möchte ich das Konzept für die SSP-API verstehen und analysiert haben
  • um die kommende Entwicklung möglichst effektiv umsetzen zu können.

Warum?

Wir wollen die verschiedenen Handlungstränge, Ideen und Requirements aus #1278 (Destination Verwaltung per API ermöglichen) möglichst gestrafft in eine umsetzbare und verständliche Ordnung bringen um zeitnah mit der Implementierung beginnen zu können.

Hinweise:

  • Der Token-Validator entfällt durch den Aufruf des /token/introspection Endpunktes der Connect2Id API.
  • Abrufen der Scopes aus /token/introspection muss abschaltbar sein, da wir im Test aktuell (noch?) unsignierte / Dummytokens verwenden weil man sich den (aufwändigen) Signierungsprozess / Mocking spart.

Acceptance criteria

  1. Team SSP stellt dem Team Zustelldienst das aktuelle Konzept vor.
  2. Yves versteht die Auswirkungen der Verlängerung der OAuth Scopes. Die Änderung welche aus #1278 für den Zustelldienst dafür notwendig sind, sind im Ticket #9999 erfasst.
  3. Analyse des Issues #1278 & der dort verlinkten Dokumente / Issues
  4. Abgrenzung zu anderen Issues im EPIC (https://git.fitko.de/fit-connect/planning/-/boards/44?label_name\[\]=Epic%3A%3ASelf-Service-API)
    • sofern Issues widersprüchlich zu dem Konzept in 1278 sind, sollten wir diese schließen
    • das AK muss im engen Austausch mit dem PO erfolgen
  5. Lösungsansätze zu den offenen Punkten wurden erarbeitet und die beste Alternative empfohlen
    • Hier können die Ansprechpartner vom SSP (vor allem Michael und Rene) für einen Austausch genutzt werden
  6. EPIC #1278 ist in Stories (ggf. kleinere Epics) aufgeteilt und kann vom Team Zustelldienst abgearbeitet werden
    • unter Umständen macht es sinn es als ein neues Issue anzulegen
    • ebenfalls in enger Abstimmung mit dem PO
  7. Alle Akzeptanzkriterien des EPICS und der Stories wurden aktualisiert/bestätigt und sind vollständig
    • ebenfalls in enger Abstimmung mit dem PO
  8. Künftiger Name der API ist festgelegt ( #1278 (comment 109795))

Vorschlag zu den Stories zur Umsetzung des Tickets

  1. Abschluss Keycloack #1192 (closed) (Team SSP) - erledigt
  2. Abhängigkeiten zur Teamfunktionalität auflösen (Team SSP) - unabhängig von unseren Aktivitäten
  3. Implementierung der Anpassung an Tokenanpassung, geänderter und Prüfung der Auhtorisierungsanfragen (Team ZSD) - S-2 / PI-7 / Q1
  4. Anpassung OAuth Scopes (Team ZSD) - #1230 (closed) - S-1 / PI-8 / Q2
    • Ziel: Aktuelle Beschränkungen bei der Menge der destinations eines clients (oder eines Users) sollten aufgehoben werden
    • Anpassung Token-Validator aus #1278 (comment 101878)
  5. Die Änderung des sub claims im Token (Zustelldienst) aus #1278 (comment 107638) Punkt 1 - S-1 / PI-8 / Q2
  6. Übernahme der ausgewählten Informationen aus dem SSP-DB in ZSD-DB - S-1 / PI-8 / Q2
    1. Zuordnung User zu Client/Destination
    2. Name der Destination(Freitext)
    3. Anpassung Exporte für die Nutzungsstatistiken
    4. Anpassung und Test aller SSP-API Endpunkte (Team SSP)
    • Änderung der Namen der Destinationen(Freitext)
    1. Konzept + Kommunikation + Umsetzung
  7. Migration auf allen Umgebungen
  8. Anlage neuer Clients über SSP-API (Team SSP? und Team Infrastruktur?)
  9. Anlage neuer Destinationen über SSP-API (funktioniert wohl bereits)
  10. Anpassung Doku & Videos
    • Aufteilung der API-Spec in Submission und Destination Management über (schon vorhandene) Labels / Tags in der Submission API.

offene Fragen

Allgemein

  • Wie erfolgt die die Trennung zw. Submission-API und SSP-API ?
    • Die Trennung besteht in der Funktionalität der APIs, diese ist schon vorhanden. Beide APIs sind aber im Zustelldienst verankert, weswegen eine technische Trennung dann nicht mehr vorhanden wäre, weil beide Endpunkte dann im Zustelldienst vorhanden sind. Daher würden die jetzt im Zustelldienst bestehenden Endpunkte der Self-Service-API dann für alle öffentlich geschaltet. Empfehlung: Internal aus Submission API in Self-Service-API schieben. (Internal = Zustellpunktverwaltung in Self-Service-API) image
  • Abgrenzung zu "Langfristig soll auch die Erstellung von API-Clients sowie der Scope von Clients für bestimmte Destinations für Drittsysteme möglich sein und soll durch die Architektur möglich sein, aber ist nicht Teil des Umfangs dieses Epics" ist nicht ganz klar
    • Korrekt, dies ist nicht Teil des Umfangs dieses Epics, da weitere Entscheidungen dafür noch notwendig wären. Langfristig sollte es dann eingeplant werden.
  • Auswirkungen / Stand der Analyse im Zusammenspiel mit Multiple Zustelldienste #1278 (comment 107636)
    • Da wir momentan noch kein Design für Multiple Zustelldienste haben, können wir hierzu noch keine valide Aussage treffen. Jedoch aus dem momentanen Stand hat es keine Auswirkungen auf eine Implementierung von multiplen Zustelldiensten.
  • Zusatzinformationen im SSP im Nachgang implementieren? (Name der Behörde und des Verfahrens an der Destination) #1278 (comment 102297)
    • Ja, im SSP als auch im Zustelldienst würde das Feld gebaut werden und eingefügt werden.

Limit destinations / OAuth Scopes #1230 (closed)

  • Wie ist der Stand von #1230 (closed) - Limit destinations
    • Ist noch in der Konzeptionierung. Es kann vor sowie nach diesem Epic durchgeführt werden.
  • ist #1230 (closed) eine Voraussetzung für dieses Epic, oder kann das im Nachgang synchronisiert werden
    • Nein, es ist keine Voraussetzung. Empfehlung ist danach, weil wir dann erst die Konzeption der Limits besprechen müssten. Es sollen die bestehenden Tokens, wie jetzt, genutzt werden. Jedoch sollen die Scopes ausgelagert werden, weswegen sich mit dem Limit-Ticket wahrscheinlich nur die Abholungsstrecke der Tokens verändern. Idee ist mit der Destination API die Datenbanken zusammenbringen und danach die Limits zu erhöhen.
  • wie ist es mit den hier offenen Punkten #1278 - ist das in 1230 bereits berücksichtigt?
    • Ja, die offenen Fragen sind im Epic berücksichtigt. Wir setzen Gruppen-IDs, der Refresh Token (für die API) würde nicht eingeführt werden (all drei Punkte unter Auswahl und Dokumentation des OAuth Flow werden nicht durchgeführt).

Keycloak #1192 (closed)

  • UserID - haben wir zw. Elster, Keycloack, Gitlab, oder sonstiges noch irgendwelche Abhängigkeiten?
    • Auf der Testumgebung wird Elster zu den bestehenden Logins dazukommen. Dabei muss berücksichtigt werden, dass wir nicht erkennen können, dass ein Nutzer sich mit zwei Accounts anmeldet, dieser würde als zwei unterschiedliche Nutzer geführt werden. Ab Stage ist dann nur noch Elster erlaubt.
  • Wie unterscheiden sich User-IDs von Gruppen-IDs (müssten wir im ZSD nicht eine Story vorab dafür einplanen, wenn es umgestellt wird?) In meinem Verständnis brauchen wir in Zukunft sowohl Gruppen als auch User, oder?
    • Nein, mit der bestehenden im SSP hinterlegten Mail wird auf die neue Elstermail gemappt, daher ist die Umstellung direkt möglich. Der Owner meldet sich mit der Gruppen-ID an und legt bspw. drei User in seinem Account an. Diese User erhalten eine User ID, welche einer Gruppen-ID in dem jeweiligen Scope zugeordnet sind. So sehen sie nicht die Ansicht des Owners, daher würde die Gruppen-ID beim Owner als Client-ID liegen.
  • Ist die Keycloack Umsetzung zwingende Voraussetzung für Story 2ff?
    • Nein, da die Destination API der Umzug der Datenbank ist.
  • AK2 - einem User oder einer Gruppe muss es in Zukunft zugeordnet werden? - ist es in 1192 berücksichtigt?
    • Bei Destinationerstellung ist immer sichergestellt, dass diese Destination einem User zugeordnet wurde ist beim Keycloak Epic berücksichtigt, da diese Info in der SSP-Datenbank ist und nicht verändert wird. Der Hintergrund ist, dass die Gruppe nur über den Scope der API ermittelt wird, somit ist die Zuordnung über das SSP erledigt.

Anlage neuer Clients

  • Prozess "Ablauf Anlage neuer Clients" sind die Schritte 2 bis 9 tatsächlich Teil des Prozesses oder eher vorgelagerte Schritte bei der Anlage? Sollten wir kurz genauer besprechen.
    • Wir verändern den Ablauf. image
  • Prozess "Ablauf Anlage neuer Clients": verstehe ich es richtig, dass für die Anlage des Clients im ZSD eigentlich es auch keinen Endpunkt gibt?
    • Wir benötigen einen Endpunkt im Zustelldienst, um die Info aus dem SSP in den Zustelldienst zu schreiben.
  • Sollen Clients auch über die SSP-API angelegt werden oder nur SSP?
    • Nur SSP, hier geht es nur um die Zustellpunkte. Die Clients werden in einem Folgeticket beschrieben.
  • Wurde der Prozess der Zuordnung Clients zu Destinations auch überarbeitet? Soweit ich mich erinnere können mehrere Clients auf eine Destination zugreifen.
    • Nein, der Prozess bleibt weiterhin bestehen.

Zur Abgrenzung der Epics, welche SSP und Zustelldienst betreffen aber voneinander thematisch getrennt zu betrachten sind. Eine vorgeschlagene Reihenfolge, da zwischen den Epics eine zeitliche Abhängigkeit besteht.

  • Datenbankumzug (Ist ein Unterthema des Destination API Epics/ die Endpunkte sollten eng mit dem SSP abgestimmt werden / sollte vor Elster fertig sein (Mitte Februar), ansonsten nach Elster (Ab Q2)
  • Destination API
  • Elster Login (Muss Q1)
  • Teamfunktionalität (Muss Q1)
  • 1000 Destinations pro JWT
  • Michael ist Delegierter für die Kommunikation
Edited by Wojciech Gdaniec