Skip to content
Snippets Groups Projects
Select Git revision
0 results
Blame Permalink
2021-08-11-sprint-report-cw-32.md 8.03 KiB 
title: Sprintwechsel KW32
tags: [sprint-report, roadmap-update]

Im Folgenden wollen wir euch ein kurzes Update bzgl. unseres Sprints geben. Hierbei wollen wir auf die Stories eingehen, die wir bearbeitet haben, sowie den Stand der noch offenen Stories durchgeben.

Falls relevant soll auch ein entsprechendes Update der Roadmap kommuniziert werden.

Dieses Format soll nun bei jedem Sprintwechsel veröffentlicht werden.

Stories

Umgesetzt

Finalisierung des Autorisierungskonzepts

Im Rahmen dieser Story wurden die begonnenen Arbeiten an der Umstellung der OAuth Autorisierung umgesetzt. Die FIT-Connect-Infrastruktur wurde gegen die neuen Tokens und Scopes getestet und die Dokumentation und API-Spec aktualisiert. Die Neuerungen der OAuth-Autorisierung lassen sich wie folgt zusammenfassen:

  • Die Zugriffsberechtigung für Zustellpunkte basiert nun auf Scopes (manage:destination:<uuid> bzw. subscribe:destination:<uuid>) und nicht mehr auf der Identität des konkreten API-Client, der den Zustellpunkt initial erstellt hat. Dies erlaubt es, API-Clients flexibel auszutauschen, ohne hierfür den Zustellpunkt neu anzulegen oder auch mehreren API-Clients einen Zugriff auf einen Zustellpunkt zu ermöglichen.
  • Neue Zustellpunkte können nur noch über das Self-Service-Portal angelegt werden. Die Verwaltung von Zustellpunkten ist weiterhin über die API möglich.
  • Sendende Systeme können Access Tokens mit eingeschränkten Scopes abrufen, die nur für den Versand von Einreichungen an Zustellpunkte mit bestimmten Leistungen und Regionen gültig sind, um hiermit den Berechtigungsumfang eines Tokens einzuschränken. Wird von dieser Option kein Gebrauch gemacht, ist der Scope des Access Token für alle Regionen und Leistungen in Deutschland gültig.
    • Um diese spezifischen Berechtigungseinstellungen bei Access Tokens von sendenden Systemen zu ermöglichen, müssen in den Zustellpunkten nun die Leistungs-IDs (bspw. Angabe eines Leika Schlüssel) und die Region-IDs (aktuell ARS), die in diesem Zustellpunkt abgebildet werden, verpflichtend hinterlegt werden. Bei Leistungen, die nicht über den ARS abgebildet werden können oder keinen Ortsbezug haben, wird in dem Zustellpunkt als Regionsangabe lediglich DE angeben.

Die Nutzung von OAuth ist folgenden Artikeln beschrieben:

Wie Scopes bei der Registrierung und Verwaltung von API-Clients hinterlegt werden, wird in der Dokumentation zum Self-Service-Portal beschrieben, sobald dieses umgesetzt ist.

Endpunkt zur Abfrage der öffentlichen Informationen einer Destination

Bisher gab es keine Möglichkeit, dass ein sendendes System die öffentlichen Informationen eines Zustellpunktes abfragen konnte. Ein solcher Abruf ist bis zur Umsetzung der Routing-API notwendig, damit sendende Systeme die hinterlegten Informationen eines Zustellpunktes ermitteln können, da diese Informationen für eine fachlich und technisch korrekte Übermittlung zwingend erforderlich sind.

Daher wurde ein neuer Endpunkt umgesetzt, um die öffentlichen Informationen einer Destination abzurufen. Empfangende Systeme können für ihre eigenen Zustellpunkte zusätzlich auch die internen Informationen abrufen (technische Ansprechpersonen, Callback-Adresse).

Event Log der Submission

Zur Prüfbarkeit der Datenübermittlung erhält die Submission einen Event Log, der Security Event Tokens (SET) gemäß RFC 8417 enthält, die einzelne Ereignisse in der Datenübermittlung signiert dokumentieren. Ein Teil der Events werden vom Zustelldienst erzeugt, andere Events (bspw. im Kontext Akzeptanz oder Ablehnung der Submission) werden durch das empfangende System erzeugt. Der Event Log bzw. die SETs der einzelnen Events ersetzen das bisherige Statusmodell. Im Vergleich zum bisherigen Statusobjekt zeichnet sich ein SET durch eine Absicherung mittels Signatur, einen Zeitstempel und eine eindeutige Identifikation von Events aus. Aktuell werden SETs noch ohne einen Payload umgesetzt, der Events detaillierter beschreibt. Entsprechende Event-Payloads werden in zukünftigen Weiterentwicklung spezifiziert und umgesetzt.

Die Dokumentation kann hier eingesehen werden:

Schlüsselverwaltung des Zustelldienstes