Unter Fachanwendungen im Kontext der TI-Föderation werden medizinische Anwendungen verstanden, die zur Nutzerauthentifizierung die sektoralen Identity Provider der TI-Föderation nutzen. Fachanwendungen (teilweise auch als Fachdienste bezeichnet) sind nach aktueller Definition:
Ein weiteres Kriterium der Fachanwendungen ist deren Zielgruppe und damit verbunden die im Rahmen einer Nutzerauthentifizierung zielgruppenspezifische Daten- und Sicherheitsanforderungen:
Zum jetzigen Zeitpunkt sind Fachanwendungen vorgesehen, die gesetzlich zur Integration der TI-Föderation verpflichtet sind. Dies sind insbesondere TI-Anwendungen und Digitale Gesundheitsanwendungen (DiGA). Es werden aktuell in Abstimmungen mit dem BMG, den gesetzlichen Krankenkassen und weiteren Stakeholdern Anforderungen und Kriterien für weitere Anwendungsgruppen erarbeitet. |
Eine Fachanwendung in der TI-Föderation besteht im Allgemeinen aus den folgenden Komponenten (siehe auch Fachliche & technische Grundlagen sowie Standards):
Die folgende Tabelle enthält einen kurzen Überblick über die Schnittstellen der Komponenten des Fachdienstes. Detailliertere Informationen zum den Abläufen und den Schnittstellen findet man im App2App-Flow, Web2App-Flow und 2-Geräte-Flow.
Komponenten des Fachdienstes | Schnittstelle | Komponente | Beschreibung |
---|---|---|---|
Anwendungsfrontend | |||
Initiale Nutzeraktion zur Nutzung der Fachanwendung (anwendungsspezifisch) | UI-Backend | Der Nutzer möchte den Fachdienst verwenden. Eine Interaktion des Nutzers mit dem Anwendungsfrontend löst ein Ereignis aus, um den Nutzer für den Zugriff zu autorisieren. | |
UI-Backend / Anwendungsfrontend | |||
Anfrage Liste registrierter IDPs (anwendungsspezifisch) | Authorization-Server | Das UI-Backend bzw. Anwendungsfrontend erfragt beim Authorization-Server des Fachdienstes die Liste der in der TI-Föderation registrierten sektoralen Identity Provider. | |
Authorization-Request | Authorization-Server | Das UI-Backend bzw. Anwendungsfrontend startet die Nutzerautorisierung. Dazu sendet es dem Authorization-Server des Fachdienstes einen Authorization-Request mit einer Code-Challenge sowie den zur Nutzerauthentisierung gewählten IDP. Als Ergebnis liefert der Authorization-Server nach erfolgreicher Nutzerauthentisierung und Prüfung der Berechtigungen (Autorisierung) dem UI-Backend (bzw. je nach technischer Implementierung dem Anwendungsfrontend) ein Access-Token als Zugriffserlaubnis auf die Business-Services des Fachdienstes. | |
Datenaustausch (anwendungsspezifisch) | Resource Server | Der Datenaustausch zwischen UI-Backend bzw. Anwendungsfrontend und den Business-Services des Fachdienstes ist anwendungsspezifisch. Allerdings wird das Access-Token in der Schnittstellenkommunikation benötigt. Der Resource Server prüft damit die Zugriffsberechtigung. | |
Authorization-Server | |||
Anfrage Entity Statement Federation Master | Federation Master | Der Authorization-Server erfragt über die /.well-known Schnittstelle des Federation Master dessen Entity Statement | |
Anfrage der Liste registrierter IDPs | Federation Master | Der Authorization-Server erfragt über die im Entity Statement veröffentlichte Schnittstelle des Federation Master die Liste der in der TI-Föderation registrierten Identity Provider. | |
Teilnehmerauskunft zu Identity Provider | Federation Master | Der Authorization-Server erfragt über die im Entity Statement veröffentlichte Schnittstelle des Federation Master Auskunft zu einem registrieren Identity Provider. | |
Anfrage Entity Statement Identity Provider | Identity Provider | Der Authorization-Server erfragt über die /.well-known Schnittstelle des Identity Provider dessen Entity Statement | |
Authentication-Request | Identity Provider | Aufgrund einer Nutzeranfrage über das UI-Backend oder Anwendungsfrontend sendet der Authorization-Server einen "Pushed-Authorization-Request" an die im Entity Statement veröffentlichte Schnittstelle des Identity Provider. Dieser leitet den Prozess der Nutzerauthentisierung ein. Dazu muss der Nutzer Interaktionen mit der Clientkomponente des Identity Provider - dem Authenticator-Modul - durchführen. Der Prozess beginnt mit einer Antwort auf dem PAR an den Authorization-Server des Fachdienstes und endet bei erfolgreicher Authentisierung mit der Rückgabe eines Authorization-Code an den Authorization-Server des Fachdienstes. | |
Abruf des ID-Token | Identity Provider | Der Authorization-Server des Fachdienstes stellt einen Request an den Identity Provider in dem er diesem den Authorization-Code übergibt. Nach Prüfung erstellt der Identity Provider ein ID-Token (und ein Access-Token) und gibt dem Authorization-Server diese als Antwort auf dessen Request zurück. Aufgrund der Informationen aus dem ID-Token prüft der Authorization-Server die Rechte des anfragenden Nutzers zur Ausführung der Business-Services des Fachdienstes. Ist die Prüfung positiv, so antwortet der Authorization-Server des Fachdienstes auf die ursprüngliche Nutzeranfrage vom UI-Backend oder Anwendungsfrontend mit einem eigenen Access-Token. Dieses Access-Token muss UI-Backend oder Anwendungsfrontend bei jeder Kommunikation mit Business-Services - also dem Ressource-Server - zum Nachweis der Berechtigung mit übergeben. | |
Resource Server | |||
Datenaustausch (anwendungsspezifisch) | UI-Backend / Anwendungsfrontend | Der Resource Server prüft bei jedem Request aus dem UI-Backend oder Anwendungsfrontend des übergebene Access-Token. Bei gültigem Token führt der Resource Server die angeforderte Funktion aus. Bei ungültigem Token antwortet der Resource Server dem UI-Backend / Anwendungsfrontend mit einer Fehlermeldung. |
Die Anforderungen für die Telematik Infrastruktur sind in Spezifikationen der gematik veröffentlicht. Für einen Fachdienst in der TI-Föderation sind vor allem diese Spezifikationen relevant
Im Folgenden werden einige wichtige Informationen aus den Spezifikationen erläutert.
Jeder Teilnehmer der TI-Föderation muss Auskunft über sich in Form eines standardkonformen Entity Statement abgeben. Ein Entity Statement ist immer ein signiertes JWT (Beispiel des JWT des Entity Statement eines sektoralen IDP - siehe Umgebungen, Referenzimplementierungen, Codebeispiele sektoraler IDP). Die Anforderungen an das Entity Statement eines Fachdienstes können in den gematik Spezifikationen gemSpec_IDP_FD und den Anlagen von gemSpec_IDP_Sek nachgeschlagen werden.
Die Tabelle zeigt ein Beispiel für das Entity Statement eines Fachdienstes (Auszug aus gemSpec_IDP_Sek Kapitel 7):
Name | Werte | Anmerkungen |
---|---|---|
iss | URL | URL des Fachdienstes (seine client_id bei Anfragen an sektorale IDPs) |
sub | URL | URL des Fachdienstes (=iss) |
iat | Alle time Werte in Sekunden seit 1970, RFC 7519 Sect.2 | Das Entity Statement ist gültig ab |
exp | Alle time Werte in Sekunden seit 1970, RFC 7519 Sect.2 | Das Entity Statement ist gültig bis |
jwks | JWKS Objekt | Schlüssel für die Signatur des Entity Statement |
authority_hints | [ string ] | iss Bezeichnung des Federation Master |
metadata { | Begin des Blocks für die Metadaten des Fachdienstes | |
openid_relying_party { | Begin des Blocks für die Metadaten des Fachdienstes als Relying Party | |
signed_jwks_uri | URL | Unter der URL kann das Schlüsselset des Fachdienstes als JWKS abgerufen werden. Es enthält Schlüssel für die Signatur des Entity Statement, die TLS Client Schlüssel und Zertifikate (x5c, use = sig) und für die Verschlüsselung der ID_TOKEN (use = enc). Der claim ist optional - gemäß https://openid.net/specs/openid-connect-federation-1_0.html#name-openid-connect-and-oauth2-m |
jwks | Liste von JWKS Objekten | Optional - gemäß https://openid.net/specs/openid-connect-federation-1_0.html#name-openid-connect-and-oauth2-m für den Fall das ein Fachdienst signed_jwks_uri nicht anbieten kann. |
organization_name | String | Optional: Name der Organisation die hinter dem Fachdienst steht |
client_name | String | Name des Fachdienstes (redundant zum claim "name" in den "Federation Entity" claims) |
logo_uri | URL | Optional: URL, unter der das Logo der Organisation oder des Fachdienstes abgerufen werden kann |
redirect_uris | [ URL ] | Liste aller URLs, zu denen die Antwort des Identity Provider über redirect propagiert werden kann. Ein Authorization-Request des Fachdienstes muss im eine URL aus dieser Liste als Parameter redirect_uri enthalten. |
response_types | [ code ] | Der claim "response_types" enthält nur "code" |
client_registration_types | [automatic] | gemäß OpenID Connect Federation 1.0 (section-4.1) |
grant_types | [ authorization_code ] | OpenID Connect Dynamic Client Registration 1.0 (section-2) |
require_pushed_authorization_requests | true | OAuth 2.0 Pushed Authorization Requests (section-6) |
token_endpoint_auth_method | self_signed_tls_client_auth | |
default_acr_values | "gematik-ehealth-loa-high" oder "gematik-ehealth-loa-substantial" | Das default_acr_values gibt an, auf welchem Vertrauensniveau der Nutzer authentisiert werden muss wenn im Authorization Request der claim "acr_values" nicht belegt ist. |
id_token_signed_response_alg | ES256 | Weitere Werte sind möglich |
id_token_encrypted_response_alg | ECDH-ES | Weitere Werte sind möglich |
id_token_encrypted_response_enc | A256GCM | Weitere Werte sind möglich |
scope | [ string ] | Der claim "scope" ist ein String mit space-delimited scope values. Die scope values sagen aus, welche Informationen über den Nutzer der Fachdienst im ID-Token übermittelt bekommen möchte. Die von der TI-Föderation unterstützten scopes sind in der Spezifikation gemSpec_IDP_Sek definiert. Beispiele für unterstützte scopes sind
|
} | Ende des Blocks für die Metadaten des Fachdienstes als Relying Party | |
federation_entity { | Begin des Blocks für die Metadaten des Fachdienstes als Teilnehmer der Föderation | |
name | string | Optional: Der Name des Fachdienstes wird z. B. in der Consent-Freigabe des Anwenders genutzt. Der claim ist redundant zum claim "client_name". |
contacts | string | Optional: Kontaktdaten, z.B. für Support-Anfragen |
homepage_uri | URL | Optional: URL der Homepage der Organisation oder des Fachdienstes |
} | Ende des Blocks für die Metadaten des Fachdienstes als Teilnehmer der Föderation | |
} | Ende des Blocks für die Metadaten |
Unter der signed_jwks_uri (oder alternativ als zusätzliches jwks unterhalb von metadata/openid_relying_party) finden sich dann die weiteren Schlüssel des Fachdienstes
Schlüssel für die TLS Client Authentisierung sind erkennbar am gesetztem x5c Wert und use=sig.
Schlüssel für die Verschlüsselung der übertragenen ID_Token durch den IDP sind erkennbar an use=enc.
Name | Werte | Beispiel | Anmerkungen |
---|---|---|---|
keys { | |||
kty | EC | ||
kid | Fachdienst007-42 / Fachdienst007-69 | ||
crv | P-256 | ||
x | qAOdPQROkHfZY1daGofOmSNQWpYK8c9G2m2Rbkpbd4c / .... | ||
y | G_7fF-T8n2vONKM15Mzj4KR_shvHBxKGjMosF6FdoPY / ... | ||
use | sig / enc | nach JSON Web Key (section-4.2) Der Fachdienst listet sowohl sig als auch enc Schlüssel | |
x5c | MIIDQjCCAiqgAwIBAgIGATz/FuLiMA0GCSqGSIb3DQEBBQUAMGIxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDTzEPMA0GA1UEBxMGRGVudmVyMRwwGgYDVQQKExNQaW5nI... | Zertifikat für die TLS Client Authentisierung des Fachdienst gegenüber dem IDP | |
} | |||
iss | URL | "https://Fachdienst007.de" | URL des IDP (variabel je Mandant/Kasse) |
iat | Alle time Werte in Sekunden seit 1970, RFC 7519 Sect.2, | 1645484401 |
Die Kommunikation zwischen den Teilnehmern der Föderation ist über kryptografische Verfahren gesichert.
Die Schlüssel und Zertifikate sind über das Entity Statement des jeweiligen Teilnehmer verfügbar (Root-claim "jwks" und Metadata-claim "signed_jwks_uri"). Die Angaben über die supporteten Signatur- und Verschlüsselungsalgorithmen sind ebenfalls über die Entity Statements der Teilnehmer öffentlich zugänglich.
Weitere Maßnahmen erhöhen die Sicherheit in der Teilnehmerkommunikation gegen Angriffsszenarien :
Fachdienste können die Integration der TI-Föderation testen. Hierzu steht sowohl eine Referenzimplementierung des Federation Masters als auch ein von der gematik entwickelte Implementierung eines sektoralen IDPs bereit. Um Ende-zu-Ende Tests durchzuführen, ist eine Registrierung in der Testumgebung notwendig. Alle Informationen hierzu finden Sie hier: Fachdienste Test-Umgebungen
Perspektivisch werden auch Tests gegen Referenzimplementierungen der sektoralen IDPs der Kostenträger inkl. Authenticator-Apps möglich sein. Die Bereitstellung beider Komponenten befindet sich aktuell noch in Abstimmung.