Konfiguration der Azure Active Directory-Identität für Azure API for FHIR
Wenn Sie mit Gesundheitsdaten arbeiten, ist es wichtig, sicherzustellen, dass die Daten sicher sind und nicht von nicht autorisierten Benutzern oder Anwendungen darauf zugegriffen werden kann. FHIR-Server verwenden OAuth 2.0, um diese Datensicherheit zu gewährleisten. Azure API for FHIR wird mithilfe von Azure Active Directory gesichert, einem Beispiel für einen OAuth 2.0-Identitätsanbieter. Dieser Artikel bietet einen Überblick über die Autorisierung von FHIR-Servern und die notwendigen Schritte, um ein Token für den Zugriff auf einen FHIR-Server zu erhalten. Diese Schritte gelten zwar für jeden FHIR-Server und jeden Identitätsanbieter, aber in diesem Artikel werden Azure API for FHIR als FHIR-Server und Azure Active Directory (Azure AD) als Identitätsanbieter erläutert.
Übersicht über die Zugriffssteuerung
Damit eine Clientanwendung auf Azure API for FHIR zugreifen kann, muss sie ein Zugriffstoken vorlegen. Beim Zugriffstoken handelt es sich um eine signierte mit Base64 codierte Sammlung von Eigenschaften (Ansprüchen), die Informationen zur Identität des Clients und zu den ihm gewährten Rollen und Berechtigungen enthalten.
Es gibt viele Möglichkeiten, ein Token abzurufen, aber der Azure-API für FHIR ist es egal, wie das Token abgerufen wird, solange es sich um ein entsprechend signiertes Token mit den richtigen Ansprüchen handelt.
Wenn Sie beispielsweise den Autorisierungscodeflow verwenden, führt der Zugriff auf einen FHIR-Server die folgenden vier Schritte aus:
- Der Kunde sendet eine Anforderung an den
/authorize-Endpunkt von Azure AD. Azure AD leitet den Client zu einer Anmeldeseite um, auf der sich der Benutzer mit den entsprechenden Anmeldeinformationen (z. B. Benutzername und Kennwort oder Zwei-Faktor-Authentifizierung) authentifiziert. Weitere Informationen finden Sie unter Abrufen eines Autorisierungscodes. Nach erfolgreicher Authentifizierung wird ein Autorisierungscode an den Client zurückgegeben. Azure AD lässt nur zu, dass dieser Autorisierungscode an eine registrierte Antwort-URL zurückgegeben wird, die in der Clientanwendungsregistrierung konfiguriert ist. - Die Clientanwendung tauscht den Autorisierungscode gegen ein Zugriffstoken am
/token-Endpunkt von Azure AD aus. Wenn Sie ein Token anfordern, muss die Clientanwendung möglicherweise einen geheimen Clientschlüssel (das Anwendungskennwort) angeben. Weitere Informationen finden Sie unter Abrufen eines Zugriffstokens. - Der Client sendet eine Anforderung an Azure API for FHIR, z. B
GET /Patient. , um alle Patienten zu durchsuchen. Wenn der Client die Anforderung vornimmt, schließt er das Zugriffstoken in einen HTTP-Anforderungsheader ein, z. BAuthorization: Bearer eyJ0e.... , wobeieyJ0e...das Base64-codierte Zugriffstoken darstellt. - Azure API for FHIR überprüft, ob das Token geeignete Ansprüche (Eigenschaften im Token) enthält. Wenn alles in Ordnung ist, wird die Anforderung erfüllt und ein FHIR-Paket mit Ergebnissen an den Client zurückgegeben.
Es ist wichtig zu beachten, dass Azure API for FHIR nicht an der Überprüfung von Benutzeranmeldeinformationen beteiligt ist und das Token nicht ausgibt. Authentifizierung und Tokenerstellung übernimmt Azure AD. Azure API for FHIR überprüft einfach, ob das Token ordnungsgemäß signiert ist (es ist authentisch) und ob es über entsprechende Ansprüche verfügt.
Struktur eines Zugriffstokens
Die Entwicklung von FHIR-Anwendungen® (Fast Healthcare Interoperability Resources) umfasst häufig das Debuggen von Zugriffsproblemen. Wenn einem Client der Zugriff auf Azure API for FHIR verweigert wird, ist es hilfreich, die Struktur des Zugriffstokens zu verstehen und wie es decodiert werden kann, um den Inhalt (die Ansprüche) des Tokens zu überprüfen.
FHIR-Server erwarten üblicherweise ein JSON-Webtoken (JWT). Es besteht aus drei Teilen:
Teil 1: Eine Kopfzeile, die wie folgt aussehen könnte:
{
"alg": "HS256",
"typ": "JWT"
}
Teil 2: Die Nutzlast (die Ansprüche), z. B.:
{
"oid": "123",
"iss": "https://issuerurl",
"iat": 1422779638,
"roles": [
"admin"
]
}
Teil 3: Eine Signatur, die berechnet wird, indem der Base64-codierte Inhalt des Headers und die Nutzlast verkettet und ein kryptografischer Hash dieser Auf der Grundlage des im Header angegebenen Algorithmus (alg) berechnet wird. Ein Server kann öffentliche Schlüssel vom Identitätsanbieter abrufen und prüfen, ob dieses Token von einem bestimmten Identitätsanbieter ausgestellt und nicht manipuliert wurde.
Das vollständige Token besteht aus den mit Base64 codierten (eigentlich mit Base64-URL codierten) Versionen dieser drei Segmente. Die drei Segmente werden verkettet und mit einem . (Punkt) getrennt.
Ein Beispiel für ein Token wird wie folgt gezeigt:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvaWQiOiIxMjMiLCAiaXNzIjoiaHR0cHM6Ly9pc3N1ZXJ1cmwiLCJpYXQiOjE0MjI3Nzk2MzgsInJvbGVzIjpbImFkbWluIl19.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI
Das Token kann mit Tools wie https://jwt.ms decodiert und untersucht werden. Das Ergebnis der Decodierung des Tokens lautet wie folgt:
{
"alg": "HS256",
"typ": "JWT"
}.{
"oid": "123",
"iss": "https://issuerurl",
"iat": 1422779638,
"roles": [
"admin"
]
}.[Signature]
Abrufen eines Zugriffstokens
Wie bereits erwähnt, gibt es mehrere Möglichkeiten, ein Token von Azure AD abzurufen. Sie werden in der Azure AD-Entwicklerdokumentation ausführlich beschrieben.
Verwenden Sie eines der folgenden Authentifizierungsprotokolle:
Es gibt andere Variationen (z. B. aufgrund eines Flows) zum Abrufen eines Tokens. Weitere Informationen finden Sie in der Azure AD-Dokumentation . Wenn Sie Azure API for FHIR verwenden, gibt es einige Tastenkombinationen zum Abrufen eines Zugriffstokens (z. B. zu Debugzwecken) mithilfe der Azure CLI.
Nächste Schritte
In diesem Dokument haben Sie einige der grundlegenden Konzepte zur Absicherung des Zugriffs auf die Azure API for FHIR mit Azure AD kennengelernt. Informationen zum Bereitstellen des Azure API for FHIR-Diensts finden Sie unter
FHIR® ist eine eingetragene Marke von HL7 und wird mit Genehmigung von HL7 verwendet.