Share via


Configuratie van Azure Active Directory-identiteit voor Azure API for FHIR

Wanneer u met gegevens in de gezondheidszorg werkt, is het belangrijk om ervoor te zorgen dat de gegevens veilig zijn en niet toegankelijk zijn voor onbevoegde gebruikers of toepassingen. FHIR-servers gebruiken OAuth 2.0 om deze gegevensbeveiliging te garanderen. Azure API for FHIR is beveiligd met behulp van Azure Active Directory, een voorbeeld van een OAuth 2.0-id-provider. Dit artikel bevat een overzicht van FHIR-serverautorisatie en de stappen die nodig zijn om een token te verkrijgen voor toegang tot een FHIR-server. Hoewel deze stappen van toepassing zijn op elke FHIR-server en elke id-provider, doorlopen we Azure API for FHIR als de FHIR-server en Azure Active Directory (Azure AD) als id-provider in dit artikel.

Overzicht van toegangsbeheer

Een clienttoepassing kan alleen toegang krijgen tot Azure API for FHIR als er een toegangstoken wordt weergegeven. Het toegangstoken is een ondertekende, Base64 gecodeerde verzameling eigenschappen (claims) die informatie overbrengen over de identiteit van de client en rollen en bevoegdheden die aan de client worden verleend.

Er zijn veel manieren om een token te verkrijgen, maar het maakt de Azure API for FHIR niet uit hoe het token wordt verkregen, zolang het maar een juist ondertekend token met de juiste claims is.

Als u bijvoorbeeld een autorisatiecodestroom gebruikt, voert de toegang tot een FHIR-server de volgende vier stappen uit:

FHIR-autorisatie

  1. De client verzendt een aanvraag naar het /authorize eindpunt van Azure AD. Azure AD leidt de client om naar een aanmeldingspagina waar de gebruiker zich verifieert met de juiste referenties (bijvoorbeeld gebruikersnaam en wachtwoord of tweeledige verificatie). Zie meer informatie over het verkrijgen van een autorisatiecode. Wanneer de verificatie is geslaagd, wordt een autorisatiecode geretourneerd naar de client. Azure AD staat alleen toe dat deze autorisatiecode wordt geretourneerd naar een geregistreerde antwoord-URL die is geconfigureerd in de registratie van de clienttoepassing.
  2. De clienttoepassing wisselt de autorisatiecode uit voor een toegangstoken op het /token eindpunt van Azure AD. Wanneer u een token aanvraagt, moet de clienttoepassing mogelijk een clientgeheim (het wachtwoord van de toepassing) opgeven. Meer informatie over het verkrijgen van een toegangstoken.
  3. De client dient bijvoorbeeld een aanvraag in bij Azure API for FHIR GET /Patientom alle patiënten te doorzoeken. Wanneer de client de aanvraag indient, neemt deze het toegangstoken op in een HTTP-aanvraagheader, bijvoorbeeld Authorization: Bearer eyJ0e..., waarbij eyJ0e... het met Base64 gecodeerde toegangstoken wordt aangeduid.
  4. Azure API for FHIR valideert dat het token de juiste claims (eigenschappen in het token) bevat. Als alles is uitgecheckt, wordt de aanvraag voltooid en wordt een FHIR-bundel met resultaten aan de client geretourneerd.

Het is belangrijk te weten dat Azure API for FHIR niet betrokken is bij het valideren van gebruikersreferenties en dat het token niet wordt opgegeven. De verificatie en het token worden gemaakt door Azure AD. Azure API for FHIR valideert eenvoudigweg of het token correct is ondertekend (het is authentiek) en of het de juiste claims heeft.

Structuur van een toegangstoken

De ontwikkeling van FHIR-toepassingen® (Fast Healthcare Interoperability Resources) omvat vaak het opsporen van toegangsproblemen. Als een client de toegang tot Azure API for FHIR wordt geweigerd, is het handig om inzicht te krijgen in de structuur van het toegangstoken en hoe dit kan worden gedecodeerd om de inhoud (de claims) van het token te inspecteren.

FHIR-servers verwachten doorgaans een JSON-webtoken (JWT, soms uitgesproken als 'jot'). Het bestaat uit drie delen:

Deel 1: Een header, die er als volgt uit kan zien:

    {
      "alg": "HS256",
      "typ": "JWT"
    }

Deel 2: De nettolading (de claims), bijvoorbeeld:

    {
     "oid": "123",
     "iss": "https://issuerurl",
     "iat": 1422779638,
     "roles": [
        "admin"
      ]
    }

Deel 3: Een handtekening, die wordt berekend door de met Base64 gecodeerde inhoud van de header en de nettolading samen te brengen en een cryptografische hash ervan te berekenen op basis van het algoritme (alg) dat is opgegeven in de header. Een server kan openbare sleutels van de id-provider verkrijgen en valideren dat dit token is uitgegeven door een specifieke id-provider en dat er niet mee is geknoeid.

Het volledige token bestaat uit de Base64-gecodeerde (eigenlijk Base64 URL gecodeerde) versies van deze drie segmenten. De drie segmenten worden samengevoegd en gescheiden door een . (punt).

Een voorbeeld van een token wordt weergegeven als:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvaWQiOiIxMjMiLCAiaXNzIjoiaHR0cHM6Ly9pc3N1ZXJ1cmwiLCJpYXQiOjE0MjI3Nzk2MzgsInJvbGVzIjpbImFkbWluIl19.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

Het token kan worden gedecodeerd en geïnspecteerd met hulpprogramma's zoals https://jwt.ms. Het resultaat van het decoderen van het token is:

{
  "alg": "HS256",
  "typ": "JWT"
}.{
  "oid": "123",
  "iss": "https://issuerurl",
  "iat": 1422779638,
  "roles": [
    "admin"
  ]
}.[Signature]

Een toegangstoken verkrijgen

Zoals vermeld, zijn er verschillende manieren om een token te verkrijgen van Azure AD. Ze worden in detail beschreven in de documentatie voor Azure AD ontwikkelaars.

Gebruik een van de volgende verificatieprotocollen:

Er zijn andere variaties (bijvoorbeeld vanwege stroom) voor het verkrijgen van een token. Raadpleeg de documentatie Azure AD voor meer informatie. Wanneer u Azure API for FHIR gebruikt, zijn er enkele snelkoppelingen voor het verkrijgen van een toegangstoken (zoals voor foutopsporingsdoeleinden) met behulp van de Azure CLI.

Volgende stappen

In dit document hebt u enkele basisconcepten geleerd die betrekking hebben op het beveiligen van toegang tot de Azure API for FHIR met behulp van Azure AD. Zie voor meer informatie over het implementeren van de Azure API for FHIR-service

FHIR® is een gedeponeerd handelsmerk van HL7 en wordt gebruikt met toestemming van HL7.