Authentification et autorisation pour Azure Health Data Services

  • Article

Authentification

Services de données de santé Azure est une collection de services managés sécurisés utilisant Azure Active Directory (Azure AD), un fournisseur d’identité global prenant en charge OAuth 2.0.

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

Azure Health Data Services ne prend pas en charge d’autres fournisseurs d’identité. Toutefois, vous pouvez utiliser leur propre fournisseur d’identité pour sécuriser les applications et leur permettre d’interagir avec Health Data Services en gérant les applications clientes et les contrôles d’accès aux données utilisateur.

Les applications clientes sont inscrites dans Azure AD 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 une logique métier.

Rôles d’application

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

Le service FHIR d’Azure Health Data Services fournit les rôles suivants :

  • Lecteur de données FHIR : peut lire (et rechercher) des données FHIR.
  • Enregistreur de données FHIR : peut lire, écrire et supprimer des données FHIR.
  • FHIR Data Exporter : peut lire et exporter des données (opérateur $export).
  • FHIR Data Importer : peut lire et importer des données (opérateur $import).
  • Contributeur de données FHIR : peut effectuer toutes les opérations de plan de données.
  • Convertisseur de données FHIR : peut utiliser le convertisseur pour effectuer la conversion de données.
  • Utilisateur FHIR SMART : le rôle permet à l’utilisateur de lire et d’écrire des données FHIR conformément aux spécifications DE SMART IG V1.0.0.

Le service DICOM d’Azure Health Data Services fournit les rôles suivants :

  • Propriétaire des données DICOM : peut lire, écrire et supprimer des données DICOM.
  • Lecture des données DICOM : peut lire les données DICOM.

Le service MedTech ne nécessite pas de rôles d’application, mais il s’appuie sur le « 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 du client.

Autorisation

Après avoir reçu des rôles d’application appropriés, les utilisateurs authentifiés et les applications clientes peuvent accéder à Azure Health Data Services en obtenant un jeton d’accès valide émis par Azure AD et effectuer des opérations spécifiques 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 dicom.healthcareapis.azure.com ressource, et non à un service spécifique.
  • Pour le service MedTech, le jeton d’accès n’est pas requis, 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écrites en détail dans la documentation Azure AD : flux de code d’autorisation et flux d’informations d’identification client.

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

  1. Le client envoie une requête au point de terminaison d’autorisation Azure AD. Azure AD 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. Azure AD autorise uniquement le retour de ce code d’autorisation à une URL de réponse inscrite configurée dans l’inscription de l’application cliente.

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

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

  4. Azure Health Data Services vérifie que le jeton contient les revendications appropriées (propriétés dans le jeton). S’il est valide, il termine la demande et retourne les 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 aucun utilisateur n’est impliqué dans l’authentification. Par conséquent, il est différent du flux de code d’autorisation des manières suivantes :

  • 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 une collection signée, encodée en Base64 , de propriétés (revendications) qui transmettent 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 (les revendications)
  • Signature, comme indiqué dans l’image. Pour plus d’informations, consultez Jetons d’accès Azure.

Signature de jeton web JASON.

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 Remarques
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 d’émission de jeton de sécurité (STS) qui construit et retourne le jeton, ainsi que le client Azure AD 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é. Notez qu’une ressource peut rejeter le jeton avant cette date, par exemple si une modification de l’authentification est requise ou si une révocation de jeton a été détectée.
aio E2ZgYxxx Revendication interne utilisée par Azure AD 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 Azure AD.
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 De l’émetteur, sauf si le compte d’utilisateur ne se trouve pas dans le même locataire que l’émetteur - invités, pour instance. Si la revendication n’est pas présente, cela signifie que la valeur de iss peut être utilisée à la place. Pour les comptes personnels utilisés dans un contexte organisationnel (pour instance, un compte personnel invité à un locataire Azure AD), 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 des 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 . Ils sont considérés 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. Il doit être ignoré.
sub Par exemple, tenantid Principe sur lequel le jeton affirme des informations, telles que l’utilisateur d’une application. Cette valeur est immuable et ne peut pas être réaffectée ou réutilisée. Le sujet est un identificateur par paire: 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 pouvez ou non souhaiter ce résultat en fonction de vos exigences en matière d’architecture et de confidentialité.
tid Par exemple, tenantid GUID représentant le client Azure AD d’où provient l’utilisateur. 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. Il doit être ignoré.
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 Azure AD.

Chiffrement

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

  • 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 lorsque les données d’imagerie, y compris les métadonnées incorporées, sont conservées 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 de l’appareil vers le service FHIR, qui est chiffré automatiquement. Dans les cas où des 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

Dans ce document, vous avez appris l’authentification et l’autorisation d’Azure Health Data Services. Pour savoir comment déployer une instance d’Azure Health Data Services, consultez

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

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