Autentisering och auktorisering för Azure Health Data Services

Autentisering

Azure Health Data Services är en samling skyddade hanterade tjänster med hjälp av Microsoft Entra ID, en global identitetsprovider som stöder OAuth 2.0.

För att Azure Health Data Services ska få åtkomst till Azure-resurser, till exempel lagringskonton och händelsehubbar, måste du aktivera den systemhanterade identiteten och bevilja rätt behörigheter till den hanterade identiteten. Mer information finns i Hanterade Azure-identiteter.

Klientprogrammen är registrerade i Microsoft Entra-ID:t och kan användas för att komma åt Azure Health Data Services. Användardataåtkomstkontroller utförs i de program eller tjänster som implementerar affärslogik.

Programroller

Autentiserade användare och klientprogram för Azure Health Data Services måste tilldelas rätt programroll.

FHIR-tjänsten® i Azure Health Data Services tillhandahåller följande roller:

• FHIR-dataläsare: Läsa och söka efter FHIR-data.
• FHIR-dataskrivare: Läsa, skriva och mjuk borttagning av FHIR-data.
• FHIR-dataexportör: Läsa och exportera ($export operator) data.
• FHIR-dataimportör: Läsa och importera ($import operator) data.
• FHIR-datadeltagare: Utför alla dataplansåtgärder.
• FHIR-datakonverterare: Använd konverteraren för att utföra datakonvertering.
• FHIR SMART-användare: Tillåter att användaren läser och skriver FHIR-data enligt SPECIFIKATIONERna för SMART IG V1.0.0.

DICOM-tjänsten® i Azure Health Data Services innehåller följande roller:

• DICOM-dataägare: Läsa, skriva och ta bort DICOM-data.
• DICOM-data läs: Läs DICOM-data.

MedTech-tjänsten kräver inte programroller, men den förlitar sig på att Azure Event Hubs Data Receiver hämtar data som lagras i händelsehubben för din organisations prenumeration.

Auktorisering

När du har beviljats rätt programroller kan autentiserade användare och klientprogram komma åt Azure Health Data Services genom att hämta en giltig åtkomsttoken som utfärdats av Microsoft Entra-ID och utföra specifika åtgärder som definierats av programrollerna.

• För FHIR-tjänsten är åtkomsttoken specifik för tjänsten eller resursen.
• För DICOM-tjänsten beviljas åtkomsttoken till resursen dicom.healthcareapis.azure.com , inte en specifik tjänst.
• För MedTech-tjänsten krävs inte åtkomsttoken eftersom den inte exponeras för användarna eller klientprogrammen.

Steg för auktorisering

Det finns två vanliga sätt att hämta en åtkomsttoken, som beskrivs i detalj i Microsoft Entra-dokumentationen: auktoriseringskodflöde och flöde för klientautentiseringsuppgifter.

Så här hämtas en åtkomsttoken för Azure Health Data Services med hjälp av auktoriseringskodflöde:

1. Klienten skickar en begäran till Microsoft Entra-auktoriseringsslutpunkten. Microsoft Entra-ID omdirigerar klienten till en inloggningssida där användaren autentiserar med lämpliga autentiseringsuppgifter (till exempel användarnamn och lösenord eller tvåfaktorsautentisering). Vid lyckad autentisering returneras en auktoriseringskod till klienten. Microsoft Entra tillåter endast att den här auktoriseringskoden returneras till en registrerad svars-URL som konfigurerats i klientprogramregistreringen.

2. Klientprogrammet utbyter auktoriseringskoden för en åtkomsttoken vid Microsoft Entra-tokenslutpunkten. När klientprogrammet begär en token kan programmet behöva ange en klienthemlighet (som du kan lägga till under programregistreringen).

3. Klienten skickar en begäran till Azure Health Data Services, till exempel en GET begäran om att söka efter alla patienter i FHIR-tjänsten. Begäran innehåller åtkomsttoken i ett HTTP begärandehuvud, Authorization: Bearer xxxtill exempel .

4. Azure Health Data Services verifierar att token innehåller lämpliga anspråk (egenskaper i token). Om den är giltig slutför den begäran och returnerar data till klienten.

I flödet för klientautentiseringsuppgifter beviljas behörigheter direkt till själva programmet. När programmet visar en token för en resurs framtvingar resursen att själva programmet har behörighet att utföra en åtgärd eftersom det inte finns någon användare som är involverad i autentiseringen. Därför skiljer det sig från auktoriseringskodflödet på följande sätt:

• Användaren eller klienten behöver inte logga in interaktivt.
• Auktoriseringskoden krävs inte.
• Åtkomsttoken hämtas direkt via programbehörigheter.

Åtkomsttoken

Åtkomsttoken är en signerad Base64-kodad samling egenskaper (anspråk) som förmedlar information om klientens identitet, roller och behörigheter som beviljats användaren eller klienten.

Azure Health Data Services förväntar sig vanligtvis en JSON-webbtoken. Den består av tre delar:

• Header
• Nyttolast (anspråken)
• Signatur, som visas i bilden. Mer information finns i Azure-åtkomsttoken.

Använd onlineverktyg som https://jwt.ms för att visa tokeninnehållet. Du kan till exempel visa anspråksinformationen.

Anspråkstyp	Värde	Anteckningar
Aud	https://xxx.fhir.azurehealthcareapis.com	Identifierar den avsedda mottagaren av token. I id_tokensär målgruppen appens program-ID som tilldelats din app i Azure-portalen. Din app bör verifiera det här värdet och avvisa token om värdet inte matchar.
iss	https://sts.windows.net/{tenantid}/	Identifierar säkerhetstokentjänsten (STS) som konstruerar och returnerar token och Microsoft Entra-klientorganisationen där användaren autentiserades. Om token har utfärdats av v2.0-slutpunkten slutar URI:n i /v2.0. DET GUID som anger att användaren är en konsumentanvändare från ett Microsoft-konto är 9188040d-6c67-4c5b-b112-36a304b66dad. Din app bör använda GUID-delen av anspråket för att begränsa den uppsättning klienter som kan logga in på appen, om det är tillämpligt.
iat	(tidsstämpel)	"Utfärdat vid" anger när autentiseringen för den här token inträffade.
Nbf	(tidsstämpel)	Anspråket "nbf" (inte före) identifierar den tid innan JWT INTE får godkännas för bearbetning.
exp	(tidsstämpel)	Anspråket "exp" (förfallotid) identifierar förfallotiden på eller efter vilken JWT INTE får godkännas för bearbetning. En resurs kan avvisa token före den här tiden, till exempel om en autentiseringsändring krävs eller om ett tokenåterkallning har identifierats.
Aio	E2ZgYxxx	Ett internt anspråk som används av Microsoft Entra-ID för att registrera data för återanvändning av token. Bör ignoreras.
Appid	e97e1b8c-xxx	Program-ID:t för klienten med hjälp av token. Programmet kan fungera som sig självt eller för en användares räkning. Program-ID:t representerar vanligtvis ett programobjekt, men det kan också representera ett objekt för tjänstens huvudnamn i Microsoft Entra-ID.
appidacr	1	Anger hur klienten autentiserades. För en offentlig klient är värdet 0. Om klient-ID och klienthemlighet används är värdet 1. Om ett klientcertifikat användes för autentisering är värdet 2.
Idp	https://sts.windows.net/{tenantid}/	Registrerar den identitetsprovider som har autentiserat subjektet för token. Det här värdet är identiskt med värdet för utfärdaranspråket såvida inte användarkontot inte finns i samma klientorganisation som utfärdaren – gäster, till exempel. Om anspråket inte finns innebär det att värdet för iss kan användas i stället. För personliga konton som används i en organisationskontext (till exempel ett personligt konto som bjuds in till en Microsoft Entra-klientorganisation) kan idp-anspråket vara "live.com" eller en STS-URI som innehåller Microsoft-kontoklientorganisationen 9188040d-6c67-4c5b-b112-36a304b66dad.
Oid	Till exempel tenantid	Den oföränderliga identifieraren för ett objekt i Microsofts identitetssystem, i det här fallet ett användarkonto. Det här ID:t identifierar användaren unikt mellan program – två olika program som loggar in samma användare får samma värde i oid-anspråket. Microsoft Graph returnerar detta ID som ID-egenskap för ett visst användarkonto. Eftersom oid tillåter att flera appar korrelerar användare krävs profilomfånget för att ta emot det här anspråket. Obs! Om det finns en enskild användare i flera klientorganisationer innehåller användaren ett annat objekt-ID i varje klientorganisation – de betraktas som olika konton, även om användaren loggar in på varje konto med samma autentiseringsuppgifter.
Rh	0.ARoxxx	Ett internt anspråk som används av Azure för att återskapa token. Det bör ignoreras.
under	Till exempel tenantid	Det huvudnamn som token anger information om, till exempel användaren av en app. Det här värdet är oföränderligt och kan inte omtilldelas eller återanvändas. Ämnet är en parvis identifierare – det är unikt för ett visst program-ID. Om en enskild användare loggar in i två olika appar med två olika klient-ID får dessa appar därför två olika värden för ämnesanspråket. Du kanske inte vill ha det här resultatet beroende på din arkitektur och sekretesskrav.
tid	Till exempel tenantid	Ett GUID som representerar Microsoft Entra-klientorganisationen som användaren kommer från. För arbets- och skolkonton är GUID det oföränderliga klient-ID:t för organisationen som användaren tillhör. För personliga konton är värdet 9188040d-6c67-4c5b-b112-36a304b66dad. Profilomfånget krävs för att kunna ta emot det här anspråket.
Uvi	bY5glsxxx	Ett internt anspråk som används av Azure för att återskapa token. Det bör ignoreras.
Ver	1	Anger versionen av token.

Åtkomsttoken är giltig i en timme som standard. Du kan hämta en ny token eller förnya den med hjälp av uppdateringstoken innan den upphör att gälla.

För att hämta en åtkomsttoken kan du använda verktyg som Postman, REST-klienttillägget i Visual Studio Code, PowerShell, CLI, curl och Microsoft Entra-autentiseringsbiblioteken.

Kryptering

När du skapar en ny tjänst för Azure Health Data Services krypteras dina data som standard med hjälp av Microsoft-hanterade nycklar .

• FHIR-tjänsten tillhandahåller kryptering av vilande data när data sparas i datalagret.
• DICOM-tjänsten tillhandahåller kryptering av vilande data när avbildningsdata, inklusive inbäddade metadata, sparas i datalagret. När metadata extraheras och sparas i FHIR-tjänsten krypteras de automatiskt.
• MedTech-tjänsten bevarar efter datamappning och normalisering enhetsmeddelanden till FHIR-tjänsten, som krypteras automatiskt. Om enhetsmeddelanden skickas till Azure Event Hubs, som använder Azure Storage för att lagra data, krypteras data automatiskt med Azure Storage Service Encryption (Azure SSE).

Nästa steg

Distribuera Azure Health Data Services-arbetsytan med hjälp av Azure-portalen

Använda Azure Active Directory B2C för att bevilja åtkomst till FHIR-tjänsten

Kommentar

FHIR® är ett registrerat varumärke som tillhör HL7 och används med tillstånd av HL7.

DICOM® är ett registrerat varumärke som tillhör National Electrical Manufacturers Association för dess standarder publikationer som rör digital kommunikation av medicinsk information.