Partager via

Configuration d’identité Azure Active Directory de l’API Azure pour FHIR

  • Article

Lorsque vous utilisez des données de santé, il est important de vous assurer que les données sont sécurisées et qu’elles ne sont pas accessibles par des utilisateurs ou des applications non autorisés. Les serveurs FHIR utilisent OAuth 2.0 pour garantir la sécurité des données. L’API Azure pour FHIR est sécurisée à l’aide d’Azure Active Directory, qui est un exemple de fournisseur d’identité OAuth 2.0. Cet article fournit une vue d’ensemble du principe d’autorisation relatif à un serveur FHIR ainsi que les étapes nécessaires à l’obtention d’un jeton d’accès à un serveur FHIR. Bien que ces étapes s’appliquent à n’importe quel serveur FHIR et à tout fournisseur d’identité, nous allons parcourir l’API Azure pour FHIR en tant que serveur FHIR et Azure Active Directory (Azure AD) en tant que fournisseur d’identité dans cet article.

Présentation du contrôle d’accès

Pour qu’une application cliente puisse accéder à l’API Azure pour FHIR, elle doit présenter un jeton d’accès. Le jeton d’accès est une collection de propriétés (revendications) encodée au format Base64 et signée, qui transmet des informations sur l’identité du client ainsi que les rôles et privilèges accordés au client.

Il existe de nombreuses façons d’obtenir un jeton, mais l’API Azure pour FHIR ne se soucie pas de la façon dont le jeton est obtenu tant qu’il s’agit d’un jeton correctement signé avec les revendications correctes.

Par exemple, lorsque vous utilisez un flux de code d’autorisation, l’accès à un serveur FHIR passe par les quatre étapes suivantes :

Autorisation FHIR

  1. Le client envoie une requête au point de terminaison /authorize d’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 un nom d’utilisateur et un mot de passe, ou une authentification à 2 facteurs). Pour plus d’informations, consultez les détails relatifs à l’obtention d’un code d’autorisation. 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 niveau du point de terminaison /token d’Azure AD. Lorsque vous demandez un jeton, l’application cliente peut devoir fournir une clé secrète client (le mot de passe des applications). Pour plus d’informations, consultez les détails relatifs à l’obtention d’un jeton d’accès.
  3. Le client effectue une demande auprès de l’API Azure pour FHIR, par exemple GET /Patient, pour rechercher tous les patients. Lorsque le client effectue la demande, il inclut le jeton d’accès dans un en-tête de requête HTTP, par exemple Authorization: Bearer eyJ0e..., où eyJ0e... représente le jeton d’accès encodé en Base64.
  4. L’API Azure pour FHIR vérifie que le jeton contient les revendications appropriées (propriétés dans le jeton). Si tout est correct, la requête est soumise et un bundle FHIR est retourné avec les résultats appropriés au client.

Il est important de noter que l’API Azure pour FHIR n’est pas impliquée dans la validation des informations d’identification de l’utilisateur et qu’elle n’émet pas le jeton. L’authentification et la création de jeton sont effectuées par Azure AD. L’API Azure pour FHIR valide simplement que le jeton est signé correctement (il est authentique) et qu’il a des revendications appropriées.

Structure d’un jeton d’accès

Le développement d’applications FHIR® (Fast Healthcare Interoperability Resources) implique souvent le débogage de problèmes d’accès. Si un client se voit refuser l’accès à l’API Azure pour FHIR, il est utile de comprendre la structure du jeton d’accès et comment il peut être décodé pour inspecter le contenu (les revendications) du jeton.

Les serveurs FHIR attendent généralement un JSON Web Token (JWT, parfois prononcé « jot »). Il se compose de trois parties :

Partie 1 : En-tête, qui peut ressembler à :

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

Partie 2 : Charge utile (les revendications), par exemple :

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

Partie 3 : Signature, qui est calculée en concaténant le contenu encodé en Base64 de l’en-tête et de la charge utile et en calculant un hachage de chiffrement de ceux-ci en fonction de l’algorithme (alg) spécifié dans l’en-tête. Un serveur peut obtenir des clés publiques auprès du fournisseur d’identité et vérifier que le jeton a été émis par un fournisseur d’identité spécifique, et qu’il n’a pas été falsifié.

Le jeton complet se compose des versions encodées au format Base64 (en fait encodées en tant qu’URL au format Base64) de ces trois segments. Les trois segments sont concaténés et séparés par un . (point).

Un exemple de jeton s’affiche comme suit :

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvaWQiOiIxMjMiLCAiaXNzIjoiaHR0cHM6Ly9pc3N1ZXJ1cmwiLCJpYXQiOjE0MjI3Nzk2MzgsInJvbGVzIjpbImFkbWluIl19.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

Le jeton peut être décodé et inspecté à l’aide d’outils tels que https://jwt.ms. Le résultat du décodage du jeton est le suivant :

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

Obtention d’un jeton d’accès

Comme mentionné précédemment, il existe plusieurs façons d’obtenir un jeton auprès d’Azure AD. Ils sont décrits en détail dans la documentation du développeur Azure AD.

Utilisez l’un des protocoles d’authentification suivants :

Il existe d’autres variantes (par exemple en raison d’un flux) pour l’obtention d’un jeton. Pour plus d’informations, consultez la documentation Azure AD . Lorsque vous utilisez l’API Azure pour FHIR, il existe des raccourcis permettant d’obtenir un jeton d’accès (par exemple, à des fins de débogage) à l’aide d’Azure CLI.

Étapes suivantes

Dans ce document, vous avez découvert certains concepts de base liés à la sécurisation de l’accès à l’API Azure pour FHIR via Azure AD. Pour plus d’informations sur le déploiement de l’API Azure pour le service FHIR, consultez

Déployer l’API Azure pour FHIR

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