Partager via

Authentification et autorisation pour Azure Health Data Services

  • Article

Authentification

Services de données de santé Azure est une collection de services gérés sécurisés utilisant Microsoft Entra ID, un fournisseur d’identité global prenant en charge OAuth 2.0.

Pour qu’Azure Health Data Services accède aux ressources Azure, telles que les comptes de stockage et les hubs d’événements, vous devez activer l’identité managée du système et accorder des autorisations appropriées à l’identité managée. Pour plus d’informations, consultez des identités managées Azure.

Les applications clientes sont inscrites dans l’ID Microsoft Entra et peuvent être utilisées pour accéder à Azure Health Data Services. Les contrôles d’accès aux données utilisateur sont effectués dans les applications ou services qui implémentent la logique métier.

Rôles d’application

Les utilisateurs authentifiés et les applications clientes d’Azure Health Data Services doivent être affectés au rôle d’application approprié.

Le service FHIR® dans Azure Health Data Services fournit les rôles suivants :

  • lecteur de données FHIR: lire et rechercher des données FHIR.
  • enregistreur de données FHIR: données FHIR de lecture, d’écriture et de suppression réversible.
  • L’exportateur de données FHIR: données de lecture et d’exportation (opérateur $export).
  • 'importateur de données FHIR: données de lecture et d’importation (opérateur $import).
  • Contributeur de données FHIR : effectuez toutes les opérations de plan de données.
  • Convertisseur de données FHIR: utilisez le convertisseur pour effectuer la conversion de données.
  • Utilisateur SMART FHIR : permet à l’utilisateur de lire et d’écrire des données FHIR en fonction de spécifications SMART IG V1.0.0.

Le service DICOM® dans Azure Health Data Services fournit les rôles suivants :

  • propriétaire des données DICOM: lire, écrire et supprimer des données DICOM.
  • données DICOM Read: Lire les données DICOM.

Le service MedTech ne nécessite pas de rôles d’application, mais il s’appuie sur récepteur de données Azure Event Hubs pour récupérer les données stockées dans le hub d’événements de l’abonnement de votre organisation.

Autorisation

Après s’être vu recevoir des rôles d’application, les utilisateurs authentifiés et les applications clientes peuvent accéder aux services de données de santé Azure en obtenant un jeton d’accès valide émis par Microsoft Entra ID, et effectuer les opérations définies par les rôles d’application.

  • Pour le service FHIR, le jeton d’accès est spécifique au service ou à la ressource.
  • Pour le service DICOM, le jeton d’accès est accordé à la ressource dicom.healthcareapis.azure.com, et non à un service spécifique.
  • Pour le service MedTech, le jeton d’accès n’est pas obligatoire, car il n’est pas exposé aux utilisateurs ou aux applications clientes.

Étapes d’autorisation

Il existe deux façons courantes d’obtenir un jeton d’accès, décrit en détail par la documentation Microsoft Entra : flux de code d’autorisation et flux d’informations d’identification du client.

Voici comment un jeton d’accès pour Azure Health Data Services est obtenu à l’aide de flux de code d’autorisation:

  1. Le client envoie une demande au point de terminaison d’autorisation Microsoft Entra. Microsoft Entra ID redirige le client vers une page de connexion où l’utilisateur s’authentifie à l’aide des informations d’identification appropriées (par exemple : nom d’utilisateur et mot de passe ou authentification à deux facteurs). Une fois l’authentification réussie, un code d’autorisation est retourné au client. Microsoft Entra-only autorise ce code d’autorisation à retourner à une URL de réponse inscrite configurée dans l’inscription de l’application cliente.

  2. L’application cliente échange le code d’autorisation pour un jeton d’accès au point de terminaison de jeton Microsoft Entra. Lorsque l’application cliente demande un jeton, l’application peut avoir à fournir une clé secrète client (que vous pouvez ajouter lors de l’inscription de l’application).

  3. Le client envoie une demande au service Azure Health Data Services, par exemple, une demande de GET pour rechercher tous les patients dans le service FHIR. La demande inclut le jeton d’accès dans un en-tête de requête HTTP, par exemple, Authorization: Bearer xxx.

  4. Azure Health Data Services valide que le jeton contient les revendications appropriées (propriétés du jeton). S’il’est valide, il termine la demande et retourne des données au client.

Dans le flux d’informations d’identification du client, les autorisations sont accordées directement à l’application elle-même. Lorsque l’application présente un jeton à une ressource, la ressource applique que l’application elle-même a l’autorisation d’effectuer une action, car il n’y a aucun utilisateur impliqué dans l’authentification. Par conséquent, il diffère du flux de code d’autorisation de ces façons :

  • L’utilisateur ou le client n’a pas besoin de se connecter de manière interactive.
  • Le code d’autorisation n’est pas obligatoire.
  • Le jeton d’accès est obtenu directement via les autorisations d’application.

Access token (Jeton d’accès)

Le jeton d’accès est un jeton d’accès signé, Base64 collection codée de propriétés (revendications) qui transmet des informations sur l’identité, les rôles et les privilèges du client accordés à l’utilisateur ou au client.

Azure Health Data Services attend généralement un jeton web JSON. Il se compose de trois parties :

  • En-tête
  • Charge utile (revendications)
  • Signature, comme indiqué dans l’image. Pour plus d’informations, consultez jetons d’accès Azure.

Capture d’écran montrant la signature de jeton web

Utilisez des outils en ligne tels que https://jwt.ms pour afficher le contenu du jeton. Par exemple, vous pouvez afficher les détails des revendications.

type de revendication Valeur Notes
aud https://xxx.fhir.azurehealthcareapis.com Identifie le destinataire du jeton. Dans les jetons id_tokens, l'audience est l'ID attribué à votre application dans le portail Azure. Votre application doit valider cette valeur et rejeter le jeton si la valeur ne correspond pas.
iss https://sts.windows.net/{tenantid}/ Identifie le service de jeton de sécurité (STS) qui construit et retourne le jeton, et le locataire Microsoft Entra dans lequel l’utilisateur a été authentifié. Si le jeton a été émis par le point de terminaison v2.0, l’URI se termine par /v2.0. La partie GUID qui indique que l’utilisateur est un utilisateur consommateur d’un compte Microsoft est 9188040d-6c67-4c5b-b112-36a304b66dad. Votre application doit utiliser la partie GUID de la revendication pour restreindre l’ensemble de locataires qui peuvent se connecter à l’application, le cas échéant.
iat (horodatage) « Issued At » (Délivré le) indique quand l'authentification de ce jeton a eu lieu.
nbf (horodatage) La revendication « nbf » (pas avant) indique le délai avant lequel le JWT ne doit PAS être accepté pour être traité.
exp (horodatage) La revendication « exp » (délai d'expiration) indique le délai d'expiration à partir duquel le JWT ne doit PAS être accepté pour être traité. Une ressource peut rejeter le jeton avant cette heure, par exemple si une modification de l’authentification est requise ou qu’une révocation de jetons est détectée.
aio E2ZgYxxx Revendication interne utilisée par Microsoft Entra ID pour enregistrer des données afin de réutiliser les jetons. Cette valeur doit être ignorée.
appid e97e1b8c-xxx ID de l’application du client utilisant le jeton. L'application peut agir pour elle-même ou pour le compte d'un utilisateur. L’ID d’application représente généralement un objet d’application, mais elle peut également représenter un objet du principal du service dans Microsoft Entra ID.
appidacr 1 Indique comment le client a été authentifié. Pour un client public, la valeur est 0. Si l'ID client et la clé secrète client sont utilisés, la valeur est 1. Si un certificat client a été utilisé pour l’authentification, la valeur est 2.
idp https://sts.windows.net/{tenantid}/ Enregistre le fournisseur d’identité qui a authentifié le sujet du jeton. Cette valeur est identique à la valeur de la revendication Émetteur, sauf si le compte d’utilisateur n’est pas dans le même locataire que l’émetteur, les invités, par exemple. Si la revendication n’est pas présente, cela signifie que la valeur d’iss peut être utilisée à la place. Pour les comptes personnels utilisés dans un contexte organisationnel (par exemple, un compte personnel invité à un locataire Microsoft Entra), la revendication idp peut être « live.com » ou un URI STS contenant le locataire de compte Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
oid Par exemple, tenantid Identificateur immuable pour un objet dans le système d’identité Microsoft, dans cet exemple, un compte d’utilisateur. Cet ID identifie de manière unique l’utilisateur entre les applications : deux applications différentes qui se connectent au même utilisateur reçoivent la même valeur dans la revendication oid. Microsoft Graph retourne cet ID en tant que propriété ID pour un compte d’utilisateur donné. Étant donné que l’oid permet à plusieurs applications de mettre en corrélation les utilisateurs, l’étendue du profil est requise pour recevoir cette revendication. Remarque : si un seul utilisateur existe dans plusieurs locataires, l’utilisateur contient un ID d’objet différent dans chaque locataire. Il est considéré comme des comptes différents, même si l’utilisateur se connecte à chaque compte avec les mêmes informations d’identification.
rh 0.ARoxxx Revendication interne utilisée par Azure pour revalider des jetons. Elle doit être ignorée.
sub Par exemple, tenantid Principal sur lequel portent les assertions d’informations du jeton, comme l’utilisateur d’une application. Cette valeur est immuable et ne peut pas être réaffectée ou réutilisée. L’objet est un identificateur pair- il est unique à un ID d’application particulier. Par conséquent, si un seul utilisateur se connecte à deux applications différentes à l’aide de deux ID client différents, ces applications reçoivent deux valeurs différentes pour la revendication d’objet. Vous ne souhaiterez peut-être pas ce résultat en fonction de vos exigences en matière d’architecture et de confidentialité.
tid Par exemple, tenantid GUID qui représente le locataire Microsoft Entra à partir duquel l’utilisateur provient. Pour les comptes professionnels et scolaires, le GUID correspond à l’ID de client immuable de l’organisation à laquelle appartient l’utilisateur. Pour les comptes personnels, la valeur est 9188040d-6c67-4c5b-b112-36a304b66dad. L’étendue du profil est requise pour recevoir cette revendication.
uti bY5glsxxx Revendication interne utilisée par Azure pour revalider des jetons. Elle doit être ignorée.
ver 1 Indique la version du jeton.

Le jeton d’accès est valide pendant une heure par défaut. Vous pouvez obtenir un nouveau jeton ou le renouveler à l’aide du jeton d’actualisation avant son expiration.

Pour obtenir un jeton d’accès, vous pouvez utiliser des outils tels que Postman, l’extension client REST dans Visual Studio Code, PowerShell, CLI, curl et les bibliothèques d’authentification Microsoft Entra.

Chiffrement

Quand vous créez un service d’Azure Health Data Services, vos données sont chiffrées par défaut à l’aide de clés managées par Microsoft.

  • Le service FHIR fournit le chiffrement des données au repos lorsque les données sont conservées dans le magasin de données.
  • Le service DICOM fournit le chiffrement des données au repos lors de l’imagerie des données, y compris les métadonnées incorporées, est conservé dans le magasin de données. Lorsque les métadonnées sont extraites et conservées dans le service FHIR, elles sont chiffrées automatiquement.
  • Le service MedTech, après le mappage et la normalisation des données, conserve les messages d’appareil au service FHIR, qui est chiffré automatiquement. Dans les cas où les messages d’appareil sont envoyés à Azure Event Hubs, qui utilisent Stockage Azure pour stocker les données, les données sont automatiquement chiffrées avec Azure Storage Service Encryption (Azure SSE).

Étapes suivantes

Déployer l’espace de travail Azure Health Data Services à l’aide du portail Azure

Utiliser Azure Active Directory B2C pour accorder l’accès au service FHIR

Remarque

FHIR® est une marque déposée de HL7 utilisé avec l’autorisation de HL7.

DICOM® est une marque déposée de la National Electrical Manufacturers Association pour ses publications de standards relatifs aux communications numériques des informations médicales.