diff --git a/README.adoc b/README.adoc index d5ae8c08..89c5df0a 100644 --- a/README.adoc +++ b/README.adoc @@ -25,6 +25,7 @@ image:https://shields.io/badge/Application Maintenance API-1.2.4-green?logo=swag == Aktuelles + * *25.08.2023* 👨‍💻 https://github.com/gematik/api-vzd/blob/gemILF_VZD_FHIR_Directory/1.0.1/docs/gemILF_VZD_FHIR_Directory.adoc[FHIR VZD Implementierungsleitfaden v1.0.1] * *28.07.2023* 👨‍💻 https://github.com/gematik/api-vzd/blob/gemILF_VZD_FHIR_Directory/1.0.0/docs/gemILF_VZD_FHIR_Directory.adoc[FHIR VZD Implementierungsleitfaden v1.0.0] * *12.05.2023* 👨‍💻 https://github.com/gematik/api-vzd/blob/gemILF_Pflege_VZD/1.5.5/docs/gemILF_Pflege_VZD.adoc[Implementierungsleitfaden v1.5.5] diff --git a/docs/FHIR_VZD_HOWTO_Authenticate.adoc b/docs/FHIR_VZD_HOWTO_Authenticate.adoc index 019835da..ad066ae0 100644 --- a/docs/FHIR_VZD_HOWTO_Authenticate.adoc +++ b/docs/FHIR_VZD_HOWTO_Authenticate.adoc @@ -18,7 +18,7 @@ image::gematik_logo.svg[gematik,float="right"] [width="100%",cols="50%,50%",options="header",] |=== -|Version: |1.0.1 +|Version: |1.0.2 |Referencing: |gemILF_FHIR_VZD |=== @@ -36,6 +36,8 @@ image::gematik_logo.svg[gematik,float="right"] |1.0.1 |25.08.23 |Chap. 2.4 |added chapter for owner auth |gematik +|1.0.2 |11.09.23 |Chap. 2.5 |added chapter "2.5. Authenticate using the gematik Authenticator" |gematik + |=== == Classification of the document @@ -330,3 +332,23 @@ CAUTION: The diagramm displays the most important interaction parts. For detaile

++++ ==== + +=== Authenticate using the gematik Authenticator +The link:https://fachportal.gematik.de/hersteller-anbieter/komponenten-dienste/authenticator[gematik Authenticator] is a windows application that can be used to simplify the interaction with a connector, the card terminals and the users smartcards(SMC-B/HBA). The authenticator app can be started using a deeplink call (authenticator://) and the authenticator app takes over control. The authenticator offers 2 possibilities to interact with the caller: + +* calling the redirect_uri using the registered application for http calls +* calling the redirect_uri directly using a HTTP get Request + +The first option would require that the redirect_uri provided by the VZD-FHIR directory has to return application specific content that fits the callers needs. As the caller can be any application, this flow is not an option. +For the second option the caller needs information on the actual status of the authenticator authorization process.To fullfill this need the VZD-FHIR directory will provide an endpoint that can be used by clients to query the actual authorization process status. +The following sequence diagramm shows the process in detail. + +.owner-authenticate with the gematik Authenticator +[%collapsible%open] +==== +++++ +

+ +

+++++ +==== diff --git a/docs/VZD_FHIR_Directory-Spec-Changes.adoc b/docs/VZD_FHIR_Directory-Spec-Changes.adoc index e7582646..0b8cced0 100644 --- a/docs/VZD_FHIR_Directory-Spec-Changes.adoc +++ b/docs/VZD_FHIR_Directory-Spec-Changes.adoc @@ -192,7 +192,138 @@ Siehe Kapitel 4.6.3 Zusammenführung mehrerer TelematikID´s zu einer Organisati |=== + +== Anbieten eines Polling Endpunktes +Wenn der Authenticator der gematik von Clients genutzt wird, um eine Authentifizierung auf Basis von Smartcards zu realisieren, dann ist es notwendig am Ende des Prozesses, die Kontrolle wieder an den Client zu übergeben und diesen mit den notwendigen Informationen für die weiteren Prozesschritte zu versorgen. Im folgenden werden die Anpassungen am Auth-Service des VZD-FHIR Directories beschrieben, die notwendig sind, um eine Anmeldung unter Verwendung des gematik Authenticators zu realsieren. + +Beim Anmeldevorgang verwendet der User eine Smartcard als Authentifizierungsmittel. Der Ablauf orientiert sich hierbei an den OIDC-Vorgaben zur link:https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html[Client initiated backchannel authentication]. Um die Kollisionen mit standard OAuth2 Grants zu vermeiden, definiert die gematik einen eigenen Grant urn:telematik:params:grant-type:decoupled als link:https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1-08#section-6.3[Extension]. + +Der Standard kann nicht zu 100% umgesetzt werden, da hierfür ebenfalls noch eine Anpassung des gematik Authenticators und des IDP der gematik notwendig sind.Als Übergangslösung wird der Client den Aufruf des Authenticators übernehmen und das VZD-FHIR Directory einen Endpunkt bereitstellen über den der Status des Authentifizierungsvorgangs abgefragt werden kann. +OIDC Konformität und Abweichungen werden im Anschluss an das Sequenzdiagramm im Rahmen der Erläutertung der einzelnen Schritte hervorgehoben. +.owner-authenticate with the gematik Authenticator +[%collapsible%open] +==== +++++ +

+ +

+++++ +==== + +*Notwendige Anpassungen/Neuerungen am VZD-FHIR Directory* +[options="header"] +|===== +| Funktionalität | Anfoderung +| Bereitstellung des initalen authenticate Endpunkt am Auth-Service a| Das VZD-FHIR Directory muss einen /owner-authenticate-decoupled Endpunkt anbieten der POST Request mit dem übergebene grant_type urn:telematik:params:grant-type:decoupled akzeptiert. + +.neuer owner Endpunkt +[%collapsible%closed] +==== +[source] +---- +POST /owner-authenticate-decoupled HTTP/1.1 +Host: https://fhir-directory-ref.vzd.ti-dienste.de/ +Content-Type: application/x-www-form-urlencoded + +grant_type=urn%3Atelematik%3Aparams%3Agrant-type%3Adecoupled +---- +==== +Erhält das VZD-FHIR Directory eine derartige Anfrage wird ein Autorisierungsauftrag mit den Werten: + +* auth_reg_id +* state +* owner-accesstoken(in diesem Moment noch unbefüllt) +* code_challenge + +erstellt und es werden folgende Daten an den Client im Response zurück geliefert: + +.owner Response +[%collapsible%closed] +==== +[source, json] +---- +HTTP/1.1 200 OK +Content-Type: application/json +Cache-Control: no-store + +{ + "auth_req_id": "bspuw6ea-scst-u5hn-p3nt-37khzwY4g", + "redirect_uri": "https://idp-ref.app.ti-dienste.de/...", + "poll_uri": "https://fhir-directory-ref.vzd.ti-dienste.de/...", + "expires_in": 600, + "interval": 3 +} +---- +==== +* expires_in: definiert die Zeit, die die auth_reg_id gültig ist und genutzt werden kann in Sekunden +* interval: definiert das Mindestwarteintervall zwischen 2 Pollinganfragen + +| Bereitstellung eines neuen polling Endpunktes am Auth-Service a| Das VZD-FHIR Directory muss einen Endpunkt anbieten, der von Clients genutzt werden kann, um den Status eines Autorisierungsauftrages abzufragen. +Dazu übergibt ein anfragender Client die folgenden Werte (wobei ist durch VZD festgelegter Endpoint, welcher im Schritt 06 dem Client über poll_uri mitgeteilt wird) + +.Token Request +[%collapsible%closed] +==== +[source, json] +---- +POST /oauth/v2/oauth-token HTTP/1.1 +Host: idsvr.example.com +Content-Type: application/x-www-form-urlencoded + +grant_type=urn%3Atelematik%3Aparams%3Agrant-type%3Adecoupled +auth_req_id=bspuw6ea-scst-u5hn-p3nt-37khzwY4g +---- +==== +Es wird geprüft, ob für die auth_req_id noch gültig ist und bereits ein owner-accesstoken vorliegt: +a) Es liegt ein passendes Token vor: +Dann antwortet der Auth-Service in seinem Response mit dem entsprechenden owner-accesstoken: + +.Token Response Success +[%collapsible%closed] +==== +[source, json] +---- +HTTP/1.1 200 OK + Content-Type: application/json + Cache-Control: no-store + + { + "access_token": "G5kXH2wHvUra0sHlDy1iTkDJgsgUO1bN" + "token_typ": "Bearer" + "expires_in": "86400" +} +---- +==== +b) liegt kein passendes Token vor dann antwortet der Server mit: + +.Token Response Error +[%collapsible%closed] +==== +[source, json] +---- +HTTP/1.1 400 Bad Request +Content-Type: application/json +Cache-Control: no-cache, no-store + +{ + "error": [ERROR_REASON] +} +---- +==== +Die ERROR_REASON kann die folgenden Werte annehmen: + +* authorization_pending - Der Authentifizierungsprozess ist noch nicht abgeschlossen +* slow_down - Wenn der Token Request noch nicht abgeschlossen ist und der Client hat den Request schneller als 3 Sekunden gestellt. +* access_denied - Der Authentifizierungsprozess konnte im Hintergrund nicht erfolgreich durchgeführt werden. +Das minimal erlaubte Polling-Interval wird auf 3 Sekunden festlgelegt. Das VZD speichert den Zeitstempel der letzten Polling-Anfrage, sodass bei der nächsten Anfrage mit dem gleichen auth_req_id der letzte Zeitstempel abgerufen werden kann (z.B. in der gleichen Datenbanktabelle). Der Zeitunterschied des aktuellen Zeitstempel und den letzten Zeitstempel muss im Minimum 3 Sekunden betragen. +| Bereitstellung einer neuen Redirect_uri | Aktuell liefert die vom VZD-FHIR Directory verwendete Redirect_uri (/signin-gematik-idp-dienst) bei Übergabe des Auth_code und des state einen owner-accesstoken zurück. Diese Rückgabe ist nicht notwendig, wenn der Authenticator die Redirect_uri direkt aufruft. +|===== + + + == Support und Unterstützungsleistungen Produktivbetrieb TI-Messenger + + *Es wird in gemSpec_VZD Kapitel 4.6.1.2.3 wie folgt ergänzt* + + Es wird in gemSpec_VZD Kapitel 5. wie folgt ergänzt @@ -207,3 +338,12 @@ Tabelle: Tab_VZD_Mapping_Eintragstyp_und_ProfessionOID |=== + +== Korrekturen +*Es wird in gemSpec_VZD_FHIR_Directory Kapitel "4.2.3 Erzeugung und Bereitstellung der Föderationsliste" wie folgt angepasst* + + + ++++ML-123677 - Maßnahmen gegen die Manipulation der Föderationsliste (VZD-FHIR-Directory, Sicherheitsgutachten)+++ + ++++Im Sicherheitsgutachten des VZD-FHIR-Directories sind geeignete Maßnahmen gegen die Manipulation der Föderationsliste beschrieben.<=+++ + + + + diff --git a/images/diagrams/SequenceDiagram.FHIR-Directory.LinkApproval.png b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkApproval.png new file mode 100644 index 00000000..1965c2e5 Binary files /dev/null and b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkApproval.png differ diff --git a/images/diagrams/SequenceDiagram.FHIR-Directory.LinkApproval.svg b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkApproval.svg new file mode 100644 index 00000000..8570bf67 --- /dev/null +++ b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkApproval.svg @@ -0,0 +1,132 @@ +FHIR-Directory NutzerNutzerFHIR-VZD-ClientFHIR-VZD-ClientFHIR-ProxyFHIR-ProxyFHIR-DirectoryFHIR-DirectoryFHIR-VZD-AdministrationFHIR-VZD-Administration[01]Öffne Administration GUI im ClientLese alle Verlinkungsanfragen, die auf Approval durch Nutzer warten[02]getPersonInstitutionLinks {}[03]prüfe owner-accesstokenalt[accesstoken is valid][04]Lesen der Verlinkungsdaten[05]HTTP 200 OK(Result Body json)[06]Filtern nach Verlinkungsanfragen, die auf Approval durch Nutzer warten[owner-accesstoken is invalid][07]HTTP 401[08]Anzeige Verlinkungsanfragen, die auf Approval durch Nutzer warten(kann auch nur ein Hinweis auf offene Anfragen im GUI sein)[09]Auswahl der zu Verlinkungsanfragen, die bestätigt werden sollen[10]Verlinkungsapprovalmit selektierten VerlinkungsanfragenVerlinkungsApproval[11]approvePersonInstitutionLink {id}[12]prüfe owner-accesstokenalt[accesstoken is valid& Verlinkungsanfrage wartet auf Approval durch den Nutzer (telematikID aus dem accesstoken)][13]Eintragen des Verlinkungsapprovals[14]Eintragung der Verlinkung in die FHIR Daten[15]HTTP 200 OK[16]HTTP 200 OK(Result Body json)[owner-accesstoken is invalidoder Verlinkungsanfrage wartet nicht auf Approval durch den authentisierten Nutzer][17]HTTP 401[18]Ergebnis Verlinkungsapproval \ No newline at end of file diff --git a/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRemoval.png b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRemoval.png new file mode 100644 index 00000000..b61a2834 Binary files /dev/null and b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRemoval.png differ diff --git a/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRemoval.svg b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRemoval.svg new file mode 100644 index 00000000..0b8c694f --- /dev/null +++ b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRemoval.svg @@ -0,0 +1,134 @@ +FHIR-Directory NutzerNutzerFHIR-VZD-ClientFHIR-VZD-ClientFHIR-ProxyFHIR-ProxyFHIR-DirectoryFHIR-DirectoryFHIR-VZD-AdministrationFHIR-VZD-Administration[01]Suche nach eigenen verlinkten RessourcenLese alle eigenen verlinkten Rassourcen[02]GET /owner?... (Suche alle eigenen HealthcareService oder PractitionerRolemit telematikID aus dem accesstokenoder clientID/holder aus dem accesstoken (Kartenherausgeber))[03]prüfe owner-accesstokenalt[accesstoken is valid][04]GET /?...[05]HTTP 200 OK(Result Body json)[06]HTTP 200 OK (Result Body json)[search-accesstoken is invalid][07]HTTP 401[08]Anzeige eigener, verlinkter Ressourcen[09]Auswahl der Verlinkungen, die gelöscht werden sollen[10]Lösche Verlinkungenmit selektierten RessourcenVerlinkungsRemoval[11]deletePersonInstitutionLink {id}[12]prüfe owner-accesstokenalt[accesstoken is valid& Verlinkung gehört zu eigener Ressource (telematikID/clientID/holder aus dem accesstoken)][13]Eintragen des Verlinkungsremovals[14]Löschen der Verlinkung in die FHIR Daten[15]HTTP 200 OK[16]HTTP 200 OK(Result Body json)[owner-accesstoken is invalidoder Verlinkung bezieht sich nicht auf eigene Ressourcen/Zuständigkeitsbereich][17]HTTP 401[18]Ergebnis Verlinkungsapproval \ No newline at end of file diff --git a/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRequest.png b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRequest.png new file mode 100644 index 00000000..2adbe213 Binary files /dev/null and b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRequest.png differ diff --git a/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRequest.svg b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRequest.svg new file mode 100644 index 00000000..ca04398c --- /dev/null +++ b/images/diagrams/SequenceDiagram.FHIR-Directory.LinkRequest.svg @@ -0,0 +1,190 @@ +FHIR-Directory NutzerNutzerFHIR-VZD-ClientFHIR-VZD-ClientFHIR-ProxyFHIR-ProxyFHIR-DirectoryFHIR-DirectoryFHIR-VZD-AdministrationFHIR-VZD-Administration[01]Start Verlinkungsanfragemit Suche nach der zu verlinkenden Partner-RessourcenSuche aller eigenen Ressourcen, die verlinkt werden können[02]GET /owner?... (Suche alle eigenen HealthcareService oder PractitionerRolemit telematikID aus dem accesstoken)[03]prüfe owner-accesstokenalt[accesstoken is valid][04]GET /?...[05]HTTP 200 OK(Result Body json)[06]HTTP 200 OK (Result Body json)[search-accesstoken is invalid][07]HTTP 401Suche aller Partner Ressourcen, die verlinkt werden können[08]GET /owner?... (Mit Nutzer Suchstring fürPartner HealthcareService oder PractitionerRole)[09]prüfe owner-accesstokenalt[accesstoken is valid][10]GET /?...[11]HTTP 200 OK(Result Body json)[12]HTTP 200 OK (Result Body json)[search-accesstoken is invalid][13]HTTP 401Lese alle vorhandenen Verlinkungsdaten[14]getPersonInstitutionLinks {}[15]prüfe owner-accesstokenalt[accesstoken is valid][16]Lesen der Verlinkungsdaten[17]HTTP 200 OK(Result Body json)[owner-accesstoken is invalid][18]HTTP 401[19]Anzeige aller eigenen und Partner Ressourcen(HealthcareService und PractitionerRole)sowie vorhandene Verlinkungsdaten[20]Auswahl der zu zu verlinkenden Ressourcen[21]Verlinkungsanfragemit ausgewählten Ressourcen{HealthcareService, PractitionerRole}VerlinkungsRequest[22]suggestPersonInstitutionLink {HealthcareService, PractitionerRole}[23]prüfe owner-accesstoken& Prüfe, dass eine der Ressourceneine eigene Ressource istalt[accesstoken is valid][24]Eintragen des Verlinkungsrequests[25]HTTP 200 OK(Result Body json)[owner-accesstoken is invalidoder keine eigene Ressource ausgewählt][26]HTTP 401[27]Ergebnis Verlinkungsanfrage \ No newline at end of file diff --git a/images/diagrams/SequenceDiagram.FHIR-Directory.owner_auth_authenticator.png b/images/diagrams/SequenceDiagram.FHIR-Directory.owner_auth_authenticator.png new file mode 100644 index 00000000..f90c7398 Binary files /dev/null and b/images/diagrams/SequenceDiagram.FHIR-Directory.owner_auth_authenticator.png differ diff --git a/images/diagrams/SequenceDiagram.FHIR-Directory.owner_auth_authenticator.svg b/images/diagrams/SequenceDiagram.FHIR-Directory.owner_auth_authenticator.svg new file mode 100644 index 00000000..1a676e5a --- /dev/null +++ b/images/diagrams/SequenceDiagram.FHIR-Directory.owner_auth_authenticator.svg @@ -0,0 +1,85 @@ +Entkoppelte FHIR-VZD AuthentisierungVZD-FHIR-DirectoryLeistungserbringerLeistungserbringerTI-M ClientTI-M Clientgematik Authenticatorgematik Authenticatorgematik IDP-Dienstgematik IDP-DienstAuth-ServiceAuth-Service[01]Anmeldung starten[02]Decoupled Authorization RequestPOST /owner-authenticate-decoupledHeader: Content-Type=application/x-www-form-urlencodedBody: grant_type=urn:telematik:params:grant-type:decoupled[03]Erzeuge PKCE_code_challenge, PKCE_code_verifier und state[04]Erzeuge auth_req_idSiehe Bildungsregel:https://openid.net/specs/openid-client-initiated-backchannel-authentication-core-1_0.html#rfc.section.7.3[05]code, state und auth_req_id werden als Autorisierungsauftragin einem persistent Store gespeichert[06]Decoupled Authorization Response 200 OK("auth_req_id": "...","poll_uri": "...",{redirect_uri}: "https://idp-ref.app.ti-dienste.de/auth?response_type=code&client_id=GEMgematFHI4HkPrd8SR&scope=fhir-vzd+openid&redirect_uri=https%3A%2F%2Ffhir-directory-ref.vzd.ti-dienste.de%2Fsignin-gematik-idp-dienst&state=HkX8By1qMekEg4a7B1aXyw&code_challenge=a0kY3HugNKgveqhBQjc1tmX4_m-OT7FMF175rDlOIOM&code_challenge_method=S256","expires_in": 600,"interval": 3)par[Authenticator Flow][07]Deeplink-Aufruf:authenticator://?challenge_path={redirect_uri}&callback=DIRECT&cardType=HBA[08]Der Authenticator interagiert mit dem IDPund über einen Konnektor mit den Smartcards.Am Ende des Prozesses erhält der Authenticatorden auth_code vom IDP.Siehe nächster Aufruf![09]302 Redirect auf die redirect_uri des VZD-FHIRmit dem auth_code und dem state[10]Der Authenticator ruft selbst mit einem HTTP Get,redirect_uri&code=XXX&state=YYY auf.)[11]Finde via state den Autorisierungsauftragund speichere auth_code in diesem Autorisierungsauftrag[12]200 OK, Empty Body[13]Anwendung wird beendet[14]Übergabe des auth_code und deskey_verifier an den Token EndpunktSiehe:https://github.com/gematik/api-ti-messenger/blob/main/docs/IDP/idp.adoc#3231-erzeugung-des-key_verifier-durch-die-relying-party[15]signierter id_token[16]Erzeuge owner-accesstoken auf Basis des id_tokensund speichere dieses am Autorisierungsauftrag[TI-M Client pollt][17]Access Token Request POST {poll_uri}aus Decopled Authorization ResponseBody: auth_req_id={auth_req_id}[18]Prüfe ob für die übergebene auth_req_idein Autorisierungsauftrag vorliegt undggf. bereits ein owner-accesstokenalt[Poll Pending][19]400 Bad Request (Pending){"error":"authorization_pending"}[Poll Success][20]200 OK (Success){"access_token": "..."}[Poll Error][21]400 Bad Request (Error){"error": "access_denied"..or.."error": "expired_token"..or.."error": "slow_down"}...fachlicher flow... \ No newline at end of file diff --git a/src/openapi/DirectoryAdministration.yaml b/src/openapi/DirectoryAdministration.yaml index 5b4da0ea..4bfe8e70 100644 --- a/src/openapi/DirectoryAdministration.yaml +++ b/src/openapi/DirectoryAdministration.yaml @@ -3,8 +3,19 @@ info: title: I_Directory_Administration description: REST Schnittstelle zur Pflege der Verzeichniseinträge. Über diese Schnittstelle können Verzeichniseinträge inklusive Zertifikaten erzeugt, aktualisiert und gelöscht werden. Die Administration von Fachdaten erfolgt über Schnittstelle I_Directory_Application_Maintenance und wird durch die Fachanwendungen durchgeführt. Lesender Zugriff auf die Fachdaten ist mit Operation getDirectoryEntries in vorliegender Schnittstelle möglich. - version: 1.11.0 + version: 1.12.1 + # Änderungen in Version 1.12.1 + # - Merge von Versionen 1.12.0 und 1.11.1 + # + # Änderungen in Version 1.12.0 + # - Schema baseDirectoryEntry um Attribut providedBy erweitert. + # Damit wird die Zusammenführung von mehreren LDAP Einträgen in einer FHIR Organisation möglich. + # + # Änderungen in Version 1.11.1 + # - Schema baseDirectoryEntry um Attribut providedBy erweitert. + # - Operation read_Directory_Entry: Suchparameter für komLeData und kimData vereinfacht + # # Änderungen in Version 1.11.0 # - Schema FAD1 um kimData erweitert. Damit wird in read_Directory_Entry zusätzlich zu komLeData # auch kimData im Response aufgenommen @@ -345,6 +356,8 @@ paths: - holder - professionOID - mail + - komLeData + - kimData - Suche nach Vorhandensein oder leerem Inhalt eines Attributs des VZD Datensatzes mit dem Kode \00 in den Parametern - givenName @@ -540,50 +553,34 @@ paths: Selektiert alle Datensätze, deren Attribut FAD1.mail den angegebenen String in einem Wert des arry's enthält. schema: type: string - - name: komLeData-mail - in: query - description: | - Erlaubt die Suche mit Hilfe des Attributs FAD1.komLeData.mail - - Selektiert alle Datensätze, deren Attribut FAD1.komLeData.mail den angegebenen String in einem Wert des arry's enthält. - Bitte beachten: Dieser Suchparameter wird auf eine LDAP Wildcard Suche mit führendem * abgebildet und verlangsamt die Operation signifikant. - schema: - type: string - - name: komLeData-version + - name: komLeData in: query description: | - Erlaubt die Suche mit Hilfe des Attributs FAD1.komLeData.version + Erlaubt die Suche mit Hilfe des Attributs FAD1.komLeData - Selektiert alle Datensätze, deren Attribut FAD1.komLeData.version den angegebenen String in einem Wert des arry's enthält. + Selektiert alle Datensätze, deren Attribut FAD1.komLeData den angegebenen String in einem Wert des array's enthält. + komLeData enthält die "version" und "mail" durch Komma getrennt in einem array. + Beispiel: 1.0,mc_smcb_za@dom1.komle.telematik-test + Für diesen Suchparameter kann ein Wildcard genutzt werden. schema: type: string - - name: kimData-mail + - name: kimData in: query description: | Erlaubt die Suche mit Hilfe des Attributs FAD1.kimData.mail Selektiert alle Datensätze, deren Attribut FAD1.kimData.mail den angegebenen String in einem Wert des arry's enthält. + + Selektiert alle Datensätze, deren Attribut FAD1.kimData den angegebenen String in einem Wert des array's enthält. + komLeData enthält die "mail", "version" und "appTags" durch Komma getrennt in einem array. + Die appTags werden durch das Pipe Zeichen getrennt. + Bitte beachten: Wenn das Pipe Zeichen im Suchstring genutzt wird muss die besondere + Bedeutung dieses Zeichens bei der LDAP Suche beachtet werden. + Beispiel: mz_smcb_za@dom2.kim.telematik-test,1.0,DALE-UV;Einsendung;V1.0|eEB;V1.0 + Für diesen Suchparameter kann ein Wildcard genutzt werden, z.B. + mz_smcb_za@dom2.kim.telematik-test* schema: - type: string - - name: kimData-version - in: query - description: | - Erlaubt die Suche mit Hilfe des Attributs FAD1.kimData.version - - Selektiert alle Datensätze, deren Attribut FAD1.kimData.version den angegebenen String in einem Wert des arry's enthält. - Bitte beachten: Dieser Suchparameter wird auf eine LDAP Wildcard Suche mit führendem * abgebildet und verlangsamt die Operation signifikant. - schema: - type: string - - name: kimData-appTags - in: query - description: | - Erlaubt die Suche mit Hilfe des Attributs FAD1.kimData.appTags - - Selektiert alle Datensätze, deren Attribut FAD1.kimData.appTags den angegebenen String in einem Wert des arry's enthält. - Bitte beachten: Dieser Suchparameter wird auf eine LDAP Wildcard Suche mit führendem * abgebildet und verlangsamt die Operation signifikant. - schema: - type: string - + type: string responses: 200: @@ -2081,6 +2078,28 @@ components: description: 'Wird beim Anlegen des Eintrags vom VZD aus dem Zertifikat übernommen (Feld registrationNumber der Extension Admission). Falls der Basiseintrag (baseDirectoryEntry) ohne Zertifikat angelegt wird, kann in Operation add_Directory_Entry die telematikID angegeben werden. Damit ist der Verzeichniseintrag bereits über die telematikID im baseDirectoryEntry auffindbar. Diese telematikID muss mit der telematikID aus dem Zertifikatseintrag (userCertificate) übereinstimmen. Simmten die telematikIDs nicht überein, wird die Operation mit Fehlercode 422 abgelehnt' + providedBy: + type: string + description: | + Erlaubt die Zusammenführung von mehreren LDAP Einträgen in einer FHIR Organisation. + In Attribut providedBy wird dazu die telematikID der übergeordneten Oragnisation eingetragen. + Wird in Attribut "providedBy" im LDAP VZD Eintrag eine TelematikID eingetragen, + wird für den LDAP Eintrag im FHIR VZD ein HealthcareService unter der - mit der TelematikID - + referenzierten Organisation generiert. + Randbedingungen: + - Es wird nur eine Hierarchieebene unterstützt (providedBy vom referenzierten Datensatz + MUSS leer sein) + - Es können nur Organisationseinträge zusammengeführt/verlinkt werden (personalEntry=false) + - Das Attribut "providedBy" darf nur eine TelematikID enthalten. + - Der Client - der dieses Attribut setzt - MUSS auch für den referenzierten + LDAP Datensatz als Holder eingetragen sein. + - Wenn Attribut providedBy gesetzt wurde, kann es nur zurückgesetzt + (Inhalt auf leer gesetzt) werden. Eine Änderung auf einen anderen Wert + wird nicht unterstützt. + - Vor Löschung eines LDAP VZD Eintrags müssen alle Verlinkungen über Attribut "providedBy" + von anderen Datensätzen auf den zu löschenden Datensatz entfernt werden. + Bei Nichteinhaltung der Randbedingungen wird die Schreiboperation (POST/PUT) mit + Fehler (HTTP Status 400) und entsprechendem Fehlertext beendet. specialization: maxItems: 100 type: array diff --git a/src/openapi/DirectoryApplicationMaintenance.yaml b/src/openapi/DirectoryApplicationMaintenance.yaml index 58297d37..5ee12684 100644 --- a/src/openapi/DirectoryApplicationMaintenance.yaml +++ b/src/openapi/DirectoryApplicationMaintenance.yaml @@ -6,9 +6,13 @@ info: # REST Schnittstelle zur Pflege der Fachanwendungsdaten der Verzeichniseinträge Über diese Schnittstelle können Fachanwendungsdaten der Verzeichniseinträge erzeugt, aktualisiert und gelöscht werden. - version: 1.4.0 + version: 1.4.1 + # Änderungen in Version 1.4.1 + # - Operation appTags: Return Type definiert + # - Operation read_Directory_Entry: Suchparameter für komLeData und kimData vereinfacht + # # Änderungen in Version 1.4.0 # - Operation appTags ergänzt # - Flag "noVzdMailEntry" für add_Directory_FA-Attributes und modify_Directory_FA-Attributes @@ -169,6 +173,8 @@ paths: - holder - professionOID - mail + - komLeData + - kimData - Suche nach Vorhandensein oder leerem Inhalt eines Attributs des VZD Datensatzes mit dem Kode \00 in den Parametern - givenName @@ -372,50 +378,36 @@ paths: Selektiert alle Datensätze, deren Attribut FAD1.mail den angegebenen String in einem Wert des arry's enthält. schema: type: string - - name: komLeData-mail - in: query - description: | - Erlaubt die Suche mit Hilfe des Attributs FAD1.komLeData.mail - - Selektiert alle Datensätze, deren Attribut FAD1.komLeData.mail den angegebenen String in einem Wert des arry's enthält. - Bitte beachten: Dieser Suchparameter wird auf eine LDAP Wildcard Suche mit führendem * abgebildet und verlangsamt die Operation signifikant. - schema: - type: string - - name: komLeData-version + - name: komLeData in: query description: | - Erlaubt die Suche mit Hilfe des Attributs FAD1.komLeData.version + Erlaubt die Suche mit Hilfe des Attributs FAD1.komLeData - Selektiert alle Datensätze, deren Attribut FAD1.komLeData.version den angegebenen String in einem Wert des arry's enthält. + Selektiert alle Datensätze, deren Attribut FAD1.komLeData den angegebenen String in einem Wert des array's enthält. + komLeData enthält die "version" und "mail" durch Komma getrennt in einem array. + Beispiel: 1.0,mc_smcb_za@dom1.komle.telematik-test + Für diesen Suchparameter kann ein Wildcard genutzt werden. schema: type: string - - name: kimData-mail + - name: kimData in: query description: | Erlaubt die Suche mit Hilfe des Attributs FAD1.kimData.mail Selektiert alle Datensätze, deren Attribut FAD1.kimData.mail den angegebenen String in einem Wert des arry's enthält. + + Selektiert alle Datensätze, deren Attribut FAD1.kimData den angegebenen String in einem Wert des array's enthält. + komLeData enthält die "mail", "version" und "appTags" durch Komma getrennt in einem array. + Die appTags werden durch das Pipe Zeichen getrennt. + Bitte beachten: Wenn das Pipe Zeichen im Suchstring genutzt wird muss die besondere + Bedeutung dieses Zeichens bei der LDAP Suche beachtet werden. + Beispiel: mz_smcb_za@dom2.kim.telematik-test,1.0,DALE-UV;Einsendung;V1.0|eEB;V1.0 + Für diesen Suchparameter kann ein Wildcard genutzt werden, z.B. + mz_smcb_za@dom2.kim.telematik-test* + schema: type: string - - name: kimData-version - in: query - description: | - Erlaubt die Suche mit Hilfe des Attributs FAD1.kimData.version - - Selektiert alle Datensätze, deren Attribut FAD1.kimData.version den angegebenen String in einem Wert des arry's enthält. - Bitte beachten: Dieser Suchparameter wird auf eine LDAP Wildcard Suche mit führendem * abgebildet und verlangsamt die Operation signifikant. - schema: - type: string - - name: kimData-appTags - in: query - description: | - Erlaubt die Suche mit Hilfe des Attributs FAD1.kimData.appTags - - Selektiert alle Datensätze, deren Attribut FAD1.kimData.appTags den angegebenen String in einem Wert des arry's enthält. - Bitte beachten: Dieser Suchparameter wird auf eine LDAP Wildcard Suche mit führendem * abgebildet und verlangsamt die Operation signifikant. - schema: - type: string - + responses: 200: description: | @@ -958,19 +950,18 @@ paths: - appTags summary: Abfrage der Anwendungskennzeichen description: Es wird die Liste der Anwendungskennzeichen abgefragt. - Die Anwendungskennzeichen werden als FHIR Codesystem in der - Response übergeben + Die Anwendungskennzeichen werden als FHIR Codesystem im Response zurückgegeben operationId: getAppTags responses: 200: description: OK # Rückgabe der Anwendungskennzeichen als FHIR CodeSystem (ServiceIdentifierCS) - # Siehe https://simplifier.net/app-transport-framework/service-identifier-cs/~json + # Datenstruktur siehe https://simplifier.net/app-transport-framework/service-identifier-cs/~json content: application/json: schema: - {} + type: string 500: description: Internal Server Error content: @@ -1113,11 +1104,13 @@ components: noVzdMailEntry: type: boolean default: false - description: Wenn "noVzdMailEntry == true" dann werden durch den VZD die "mail" und komLeData - Attribute nicht befüllt oder im Fall von PUT werden vorhandene mail und komLeData Attribute gelöscht. + description: | + Wenn "noVzdMailEntry == true" dann werden durch den VZD die "mail" und "komLeData" + Attribute nicht befüllt oder im Fall von PUT werden vorhandene "mail" und + "komLeData" Attribute gelöscht. Nach Ausführung der Operation ist in diesem Fall nur + kimData gefüllt und die "mail" und "komLeData" Attribute sind leer. Dieses neue Attribut soll client-seitig nur vom Basis Consumer unterstützt werden. - description: | Liste von KIM-Adressen mit der zugehörigen KIM-Version und Anwendungskennzeichen. Für jede Mail Adresse darf nur einen Element in der Liste `komLeData` existieren. diff --git a/src/openapi/I_VZD_TIM_Provider_Services.yaml b/src/openapi/I_VZD_TIM_Provider_Services.yaml index f988534b..45f4677a 100644 --- a/src/openapi/I_VZD_TIM_Provider_Services.yaml +++ b/src/openapi/I_VZD_TIM_Provider_Services.yaml @@ -3,7 +3,11 @@ info: title: I_VZD_TIM_Provider_Services description: REST interface to retrieve the TI-Messenger federation list and to administrate the TI-Messenger domains. - version: 1.3.0 + version: 1.3.1 + + # version 1.3.1 + # - added server urls for test, ref and prod + # - corrected example for matrix uri (replaced /user with /u) # version 1.3.0 # - Attribut "domain" in the FederationList is not more a hash @@ -55,7 +59,12 @@ externalDocs: description: I_VZD_TIMessenger_services REST interface url: https://www.gematik.de servers: -- url: https://vzd-fhir-directory.vzd.ti-dienste.de/tim-provider-services +- url: https://fhir-directory-test.vzd.ti-dienste.de/tim-provider-services + description: Development server +- url: https://fhir-directory-ref.vzd.ti-dienste.de/tim-provider-services + description: Reference server +- url: https://fhir-directory.vzd.ti-dienste.de/tim-provider-services + description: roduction server tags: - name: getInfo description: This operation returns meta data about this interface @@ -164,10 +173,10 @@ paths: - name: mxid in: query description: | - MXID (MXID in URL Form) + MXID (MXID in URI Form) Format: matrix:user/localpart:domainpart - Beispiel MatrixID: @1-1tst-auto-ts-ow2:tim.test.gematik.de - MatrixID im URL Format: matrix:user/1-1tst-auto-ts-ow2:tim.test.gematik.de + Example MatrixID: @1-1tst-auto-ts-ow2:tim.test.gematik.de + MatrixID im URI Format: matrix:u/1-1tst-auto-ts-ow2:tim.test.gematik.de schema: type: string diff --git a/src/plantuml/SequenceDiagram.FHIR-Directory.LinkApproval.puml b/src/plantuml/SequenceDiagram.FHIR-Directory.LinkApproval.puml new file mode 100644 index 00000000..87b10ccf --- /dev/null +++ b/src/plantuml/SequenceDiagram.FHIR-Directory.LinkApproval.puml @@ -0,0 +1,61 @@ +@startuml SequenceDiagram.FHIR-Directory.linkApproval +skinparam dpi 100 +skinparam WrapWidth 200 +skinparam monochrome true +autonumber "[00]" + +'title "FHIR-Directory, Sequenzdiagram link approval' +actor Nutzer +participant cl as "FHIR-VZD-Client" +box FHIR-Directory #WhiteSmoke + participant fp as "FHIR-Proxy" + participant fd as "FHIR-Directory" + participant fa as "FHIR-VZD-Administration" +end box + +Nutzer -> cl:Öffne Administration GUI im Client +activate cl + + +group Lese alle Verlinkungsanfragen, die auf Approval durch Nutzer warten + cl -> fa: getPersonInstitutionLinks {} + activate fa + fa -> fa: prüfe owner-accesstoken + + alt accesstoken is valid + fa -> fa: Lesen der Verlinkungsdaten + fa --> cl: HTTP 200 OK\n(Result Body json) + cl -> cl: Filtern nach Verlinkungsanfragen, die auf Approval durch Nutzer warten + + else owner-accesstoken is invalid + fa --> cl: HTTP 401 + deactivate fa + end +end + +cl --> Nutzer:Anzeige Verlinkungsanfragen, die auf Approval durch Nutzer warten\n(kann auch nur ein Hinweis auf offene Anfragen im GUI sein) +Nutzer -> Nutzer: Auswahl der zu Verlinkungsanfragen, die bestätigt werden sollen +Nutzer -> cl: Verlinkungsapproval \nmit selektierten Verlinkungsanfragen + +group VerlinkungsApproval + cl -> fa: approvePersonInstitutionLink {id} + activate fa + fa -> fa: prüfe owner-accesstoken + + alt accesstoken is valid \n& Verlinkungsanfrage wartet auf Approval durch den Nutzer (telematikID aus dem accesstoken) + fa -> fa: Eintragen des Verlinkungsapprovals + fa -> fd: Eintragung der Verlinkung in die FHIR Daten + fd --> fa: HTTP 200 OK + fa --> cl: HTTP 200 OK\n(Result Body json) + + else owner-accesstoken is invalid\noder Verlinkungsanfrage wartet nicht auf Approval durch den authentisierten Nutzer + fa --> cl: HTTP 401 + deactivate fa + end +end + +cl -> Nutzer: Ergebnis Verlinkungsapproval + +deactivate cl + +@enduml diff --git a/src/plantuml/SequenceDiagram.FHIR-Directory.LinkRemoval.puml b/src/plantuml/SequenceDiagram.FHIR-Directory.LinkRemoval.puml new file mode 100644 index 00000000..1138930a --- /dev/null +++ b/src/plantuml/SequenceDiagram.FHIR-Directory.LinkRemoval.puml @@ -0,0 +1,62 @@ +@startuml SequenceDiagram.FHIR-Directory.linkRemoval +skinparam dpi 100 +skinparam WrapWidth 200 +skinparam monochrome true +autonumber "[00]" + +'title "FHIR-Directory, Sequenzdiagram link removal' +actor Nutzer +participant cl as "FHIR-VZD-Client" +box FHIR-Directory #WhiteSmoke + participant fp as "FHIR-Proxy" + participant fd as "FHIR-Directory" + participant fa as "FHIR-VZD-Administration" +end box + +Nutzer -> cl:Suche nach eigenen verlinkten Ressourcen +activate cl + + +group Lese alle eigenen verlinkten Rassourcen + cl -> fp: GET /owner?... (Suche alle eigenen HealthcareService oder PractitionerRole \nmit telematikID aus dem accesstoken \noder clientID/holder aus dem accesstoken (Kartenherausgeber)) + activate fp + fp -> fp: prüfe owner-accesstoken + + alt accesstoken is valid + fp -> fd: GET /?... + activate fd + fd --> fp: HTTP 200 OK\n(Result Body json) + deactivate fd + fp --> cl: HTTP 200 OK (Result Body json) + else search-accesstoken is invalid + fp --> cl: HTTP 401 + deactivate fp + end +end + +cl --> Nutzer:Anzeige eigener, verlinkter Ressourcen +Nutzer -> Nutzer: Auswahl der Verlinkungen, die gelöscht werden sollen +Nutzer -> cl: Lösche Verlinkungen \nmit selektierten Ressourcen + +group VerlinkungsRemoval + cl -> fa: deletePersonInstitutionLink {id} + activate fa + fa -> fa: prüfe owner-accesstoken + + alt accesstoken is valid \n& Verlinkung gehört zu eigener Ressource (telematikID/clientID/holder aus dem accesstoken) + fa -> fa: Eintragen des Verlinkungsremovals + fa -> fd: Löschen der Verlinkung in die FHIR Daten + fd --> fa: HTTP 200 OK + fa --> cl: HTTP 200 OK\n(Result Body json) + + else owner-accesstoken is invalid\noder Verlinkung bezieht sich nicht auf eigene Ressourcen/Zuständigkeitsbereich + fa --> cl: HTTP 401 + deactivate fa + end +end + +cl -> Nutzer: Ergebnis Verlinkungsapproval + +deactivate cl + +@enduml diff --git a/src/plantuml/SequenceDiagram.FHIR-Directory.LinkRequest.puml b/src/plantuml/SequenceDiagram.FHIR-Directory.LinkRequest.puml new file mode 100644 index 00000000..cf3c8819 --- /dev/null +++ b/src/plantuml/SequenceDiagram.FHIR-Directory.LinkRequest.puml @@ -0,0 +1,90 @@ +@startuml SequenceDiagram.FHIR-Directory.linkRequest +skinparam dpi 100 +skinparam WrapWidth 200 +skinparam monochrome true +autonumber "[00]" + +'title "FHIR-Directory, Sequenzdiagram link request' +actor Nutzer +participant cl as "FHIR-VZD-Client" +box FHIR-Directory #WhiteSmoke + participant fp as "FHIR-Proxy" + participant fd as "FHIR-Directory" + participant fa as "FHIR-VZD-Administration" +end box + +Nutzer -> cl:Start Verlinkungsanfrage \nmit Suche nach der zu verlinkenden Partner-Ressourcen +activate cl + +group Suche aller eigenen Ressourcen, die verlinkt werden können + cl -> fp: GET /owner?... (Suche alle eigenen HealthcareService oder PractitionerRole \nmit telematikID aus dem accesstoken) + activate fp + fp -> fp: prüfe owner-accesstoken + + alt accesstoken is valid + fp -> fd: GET /?... + activate fd + fd --> fp: HTTP 200 OK\n(Result Body json) + deactivate fd + fp --> cl: HTTP 200 OK (Result Body json) + else search-accesstoken is invalid + fp --> cl: HTTP 401 + deactivate fp + end +end + +group Suche aller Partner Ressourcen, die verlinkt werden können + cl -> fp: GET /owner?... (Mit Nutzer Suchstring für \nPartner HealthcareService oder PractitionerRole) + activate fp + fp -> fp: prüfe owner-accesstoken + + alt accesstoken is valid + fp -> fd: GET /?... + activate fd + fd --> fp: HTTP 200 OK\n(Result Body json) + deactivate fd + fp --> cl: HTTP 200 OK (Result Body json) + else search-accesstoken is invalid + fp --> cl: HTTP 401 + deactivate fp + end +end + +group Lese alle vorhandenen Verlinkungsdaten + cl -> fa: getPersonInstitutionLinks {} + activate fa + fa -> fa: prüfe owner-accesstoken + alt accesstoken is valid + fa -> fa: Lesen der Verlinkungsdaten + fa --> cl: HTTP 200 OK\n(Result Body json) + + else owner-accesstoken is invalid + fa --> cl: HTTP 401 + deactivate fa + end +end + +cl --> Nutzer:Anzeige aller eigenen und Partner Ressourcen \n(HealthcareService und PractitionerRole) \nsowie vorhandene Verlinkungsdaten +Nutzer -> Nutzer: Auswahl der zu zu verlinkenden Ressourcen +Nutzer -> cl: Verlinkungsanfrage \nmit ausgewählten Ressourcen \n{HealthcareService, PractitionerRole} + +group VerlinkungsRequest + cl -> fa: suggestPersonInstitutionLink {HealthcareService, PractitionerRole} + activate fa + fa -> fa: prüfe owner-accesstoken\n& Prüfe, dass eine der Ressourcen \neine eigene Ressource ist + + alt accesstoken is valid + fa -> fa: Eintragen des Verlinkungsrequests + fa --> cl: HTTP 200 OK\n(Result Body json) + + else owner-accesstoken is invalid\noder keine eigene Ressource ausgewählt + fa --> cl: HTTP 401 + deactivate fa + end +end + +cl -> Nutzer: Ergebnis Verlinkungsanfrage + +deactivate cl + +@enduml diff --git a/src/plantuml/SequenceDiagram.FHIR-Directory.owner_auth_authenticator.puml b/src/plantuml/SequenceDiagram.FHIR-Directory.owner_auth_authenticator.puml new file mode 100644 index 00000000..a4cfb967 --- /dev/null +++ b/src/plantuml/SequenceDiagram.FHIR-Directory.owner_auth_authenticator.puml @@ -0,0 +1,75 @@ +@startuml +autonumber 1 1 "[00]" +title "Entkoppelte FHIR-VZD Authentisierung" + +actor User as "Leistungserbringer" +participant TIMClient as "TI-M Client" +participant Authenticator as "gematik Authenticator" + +participant "gematik IDP-Dienst" as IdpDienst +box VZD-FHIR-Directory #WhiteSmoke + participant "Auth-Service" as VzdAuth +end box + +User->TIMClient++: Anmeldung starten + +TIMClient -> VzdAuth++: Decoupled Authorization Request\nPOST /owner-authenticate-decoupled\nHeader: Content-Type=application/x-www-form-urlencoded\nBody: grant_type=urn:telematik:params:grant-type:decoupled + VzdAuth -> VzdAuth: Erzeuge PKCE_code_challenge, PKCE_code_verifier und state +VzdAuth -> VzdAuth: Erzeuge auth_req_id +note right: **Siehe Bildungsregel:**\nhttps://openid.net/specs/openid-client-initiated-backchannel\n-authentication-core-1_0.html#rfc.section.7.3 +VzdAuth -> VzdAuth: code, state und auth_req_id werden als Autorisierungsauftrag\n in einem persistent Store gespeichert + + +VzdAuth --> TIMClient: Decoupled Authorization Response 200 OK \n(\n\t"auth_req_id": "...",\n\t"poll_uri": "...",\n\t//{redirect_uri}//: "https://idp-ref.app.ti-dienste.de/auth?\n\t\tresponse_type=code\n\t\t&client_id=GEMgematFHI4HkPrd8SR\n\t\t&scope=fhir-vzd+openid\n\t\t&redirect_uri=https%3A%2F%2Ffhir-directory-ref.vzd.ti-dienste.de%2Fsignin-gematik-idp-dienst\n\t\t&state=HkX8By1qMekEg4a7B1aXyw\n\t\t&code_challenge=a0kY3HugNKgveqhBQjc1tmX4_m-OT7FMF175rDlOIOM\n\t\t&code_challenge_method=S256",\n\t "expires_in": 600,\n\t "interval": 3\n) + +par Authenticator Flow + +TIMClient -> Authenticator++: Deeplink-Aufruf:\nauthenticator://?\n challenge_path=//{redirect_uri}//\n\t**&callback=DIRECT**\n\t**&cardType=HBA** +Authenticator <--> IdpDienst++: Der Authenticator interagiert mit dem IDP\n und über einen Konnektor mit den Smartcards.\nAm Ende des Prozesses erhält der Authenticator\n den auth_code vom IDP. **Siehe nächster Aufruf!** +IdpDienst -> Authenticator: 302 Redirect auf die redirect_uri des VZD-FHIR\n mit dem auth_code und dem state +deactivate IdpDienst +Authenticator -> VzdAuth: Der Authenticator ruft selbst mit einem HTTP Get,\nredirect_uri&code=XXX&state=YYY auf.\n) +VzdAuth -> VzdAuth: Finde via state den Autorisierungsauftrag\nund speichere auth_code in diesem Autorisierungsauftrag +VzdAuth -> Authenticator: 200 OK, Empty Body +Authenticator->Authenticator--: Anwendung wird beendet +VzdAuth->IdpDienst++: Übergabe des auth_code und des\nkey_verifier an den Token Endpunkt +note left: **Siehe:**\nhttps://github.com/gematik/api-ti-messenger/blob/main/docs/IDP/\nidp.adoc#3231-erzeugung-des-key_verifier-durch-die-relying-party +return signierter id_token +VzdAuth->VzdAuth: Erzeuge owner-accesstoken auf Basis des id_tokens\nund speichere dieses am Autorisierungsauftrag + +else TI-M Client pollt + +TIMClient -> VzdAuth: Access Token Request POST {poll_uri}\naus Decopled Authorization Response\nBody: auth_req_id={auth_req_id} +VzdAuth->VzdAuth: Prüfe ob für die übergebene auth_req_id\n ein Autorisierungsauftrag vorliegt und \nggf. bereits ein owner-accesstoken + +alt Poll Pending +VzdAuth --> TIMClient: 400 Bad Request (Pending) +note left +{ + "error":"authorization_pending" +} +end note +else Poll Success +VzdAuth -> TIMClient: 200 OK (Success) +note left +{ + "access_token": "..." +} +end note +else Poll Error +VzdAuth -> TIMClient: 400 Bad Request (Error) +note left +{ + "error": "access_denied" + ..or.. + "error": "expired_token" + ..or.. + "error": "slow_down" +} +end note +end +deactivate TIMClient +deactivate VzdAuth +end +== ...fachlicher flow... == +@enduml \ No newline at end of file