Résoudre les problèmes de configuration des fournisseurs d’identité pour le service FHIR

Article
01/29/2024

L’API version 2023-12-01 du service FHIR® dans les Services de données de santé Azure prend en charge deux fournisseurs d’identité en plus de Microsoft Entra ID. Pour fournir un accès délimité aux utilisateurs, configurez les deux fournisseurs d’identité en remplissant la section smartIdentityProviders de l’objet authenticationConfiguration.

Messages d’erreur

Voici les messages d’erreur qui se produisent si les fournisseurs d’identité SMART du service FHIR échouent,avec les actions recommandées pour résoudre le problème.

Error	Cause	Fix
Le nombre maximal de fournisseurs d’identité SMART est de 2.	Le nombre de fournisseurs d’identité configurés est supérieur à deux.	Réduisez le nombre de fournisseurs d’identité à deux ou moins.
Une ou plusieurs valeurs d’autorité de fournisseur d’identité SMART sont nulles, vides ou non valides.	L’élément `authority` de la configuration du fournisseur d’identité doit être une URL complète.	Vérifiez que toutes les valeurs `authority` sont des URL complètes.
Toutes les autorités de fournisseur d’identité SMART doivent être uniques.	Les éléments `authority` des deux configurations de fournisseur d’identité sont identiques.	Vérifiez que toutes les valeurs `authority` sont des URL complètes et uniques.
Le nombre maximal d’applications de fournisseur d’identité SMART est de 2.	Le nombre d’applications de fournisseur d’identité dans une configuration de fournisseur d’identité est supérieur à deux.	Réduisez le nombre d’applications de fournisseur d’identité à un ou deux par fournisseur d’identité.
Une ou plusieurs applications SMART sont nulles.	L’élément `applications` pour un ou plusieurs fournisseurs d’identité est nul ou ne contient aucune application.	Vérifiez que toutes les configurations du fournisseur d’identité ont au moins une application configurée.
Une ou plusieurs applications SMART `allowedDataActions` contiennent des éléments en double.	Le tableau `allowedDataActions` dans une ou plusieurs configurations d’application contient des valeurs en double.	Supprimez les valeurs dupliquées dans les tableaux `allowedDataActions` .
Une ou plusieurs valeurs `allowedDataActions` d’application SMART ne sont pas valides.	La seule valeur acceptable dans le tableau `allowedDataActions` est `Read`.	Supprimez les valeurs non conformes des tableaux `allowedDataActions`.
Une ou plusieurs valeurs `allowedDataActions` d’application SMART sont nulles ou vides.	Le tableau `allowedDataActions` dans une ou plusieurs configurations d’application est nul ou vide.	La seule valeur acceptable dans le tableau `allowedDataActions` est `Read`.
Une ou plusieurs valeurs `audience` d’application SMART sont nulles, vides ou ne sont pas valides.	La chaîne `audience` dans une ou plusieurs configurations d’application est nulle, vide ou malformée.	Vérifiez que la chaîne `audience` n’est pas nulle ou vide et que la valeur est un type de chaîne.
tous les ID client d’application du fournisseur d’identité SMART doivent être uniques.	La valeur `clientId` dans une ou plusieurs configurations d’application est la même valeur qu’une autre valeur `clientId`.	Vérifiez que toutes les valeurs `clientId` sont uniques (y compris entre les configurations du fournisseur d’identité).
Une ou plusieurs valeurs d’ID client d’application SMART sont nulles, vides ou ne sont pas valides.	La chaîne `clientId` dans une ou plusieurs configurations d’application est nulle, vide ou malformée.	Vérifiez que la chaîne `clientId` n’est pas nulle ou vide et que la valeur est un type de chaîne.
Un échec d’autorisation avec l’API FHIR Azure Health Data Services à l’aide d’un fournisseur d’identité tiers.	Le rôle d’utilisateur(-trice) FHIR SMART provoque ce problème, car il ajoute une couche d’authentification.	Vérifiez que le rôle d’utilisateur(-trice) FHIR SMART n’est pas attribué.

Erreurs de requête d’API FHIR

Lorsque vous utilisez un jeton émis par un fournisseur d’identité SMART pour effectuer des demandes au service FHIR, vous pouvez rencontrer deux codes d’erreur courants : 401 Unauthorized ou 403 Forbidden. Pour démarrer la résolution des problèmes, vérifiez la configuration de l’élément smartIdentityProviders, en particulier si le service FHIR est nouveau.

Suivez ces étapes pour vérifier la configuration correcte de l’élément smartIdentityProviders.

Vérifiez que l’élément smartIdentityProviders est correctement configuré.
Vérifier que la chaîne authority est correcte. Veillez à ce que la chaîne authority est l’autorité de jeton du fournisseur d’identité qui a émis le jeton d’accès.
Vérifier que la chaîne authority est une autorité de jeton valide. Effectuez une requête pour la configuration openid-connect. Ajoutez /.well-known/openid-configuration à la fin de la chaîne aubrowser navigatesthority, puis collez-la dans votre navigateur. Si la valeur est correcte, le navigateur accède à openid-connect configuration. Si ce n’est pas le cas, il y a un problème lié à la chaîne.

Exemple :
```
https://<YOUR_IDENTITY_PROVIDER_AUTHORITY>/authority/v2.0/.well-known/openid-configuration
```
Vérifier que la chaîne clientId est correcte. Vérifiez que la chaîne clientId correspond à l’ID client (ou à l’ID d’application) de l’application de ressource définie dans le fournisseur d’identité.
Vérifier que la méthode de requête est GET. Le seul type de requête pris en charge est GET, car les valeurs allowedDataActions prennent uniquement en charge Read.
Vérifier les revendications de jeton web JSON (JWT). Si le jeton d’accès est disponible, décodez-le à l’aide d’outils en ligne tels que jwt.ms. Une fois le jeton décodé, les revendications peuvent être inspectées, afin d’être corrigées.
Vérifiez « l’iss » (revendication de l’émetteur) . Assurez-vous que la revendication iss correspond exactement à la valeur issuer dans votre configuration OpenId de fournisseur d’identité.

Prenez la valeur authority de la configuration du fournisseur d’identité smartIdentityProvider, ajoutez-la à /.well-known/openid-configuration, puis collez-la dans votre navigateur. Si la valeur est correcte, le navigateur accède à la configuration openid-connect.

Exemple :
```
https://<YOUR_IDENTITY_PROVIDER_AUTHORITY>/authority/v2.0/.well-known/openid-configuration
```
Vérifier l’azp ou appid (revendication de partie autorisée ou appid). La revendication azp ou appid doit correspondre exactement à la valeur clientId fournie dans la configuration du fournisseur d’identité smartIdentityProvider.
Vérifier « l’aud » (revendication d’audience). La revendication aud doit correspondre exactement à la valeur audience fournie dans la configuration du fournisseur d’identité smartIdentityProvider.
Vérifier la « scp » (revendication d’étendue). La revendication scp est obligatoire. Si elle est manquante, la requête échoue. Le format de la revendication scp doit être conforme aux étendues SMART sur FHIR v1. Il est important de noter qu’actuellement le service FHIR prend uniquement en charge les étendues de lecture. Une variante acceptable des étendues SMART sur FHIR v1 remplace toute barre oblique (/) par un point (.) et un astérisque (*) par all. Par exemple, une version acceptable de l’étendue SMART sur FHIR patient/*.read est patient.all.read.

Remarque

Seules les étendues read sont prises en charge.

Vérifiez fhirUser ou extension_fhirUser (revendication utilisateur FHIR). La revendication fhirUser ou extension_fhirUser est obligatoire. Si elle est manquante, la requête échoue. Cette revendication lie l’utilisateur dans le fournisseur d’identité à une ressource utilisateur dans le service FHIR. La valeur doit être l’URL complète d’une ressource dans le service FHIR qui représente l’individu auquel le jeton d’accès est émis. Par exemple, le jeton d’accès émis à un patient connecté doit avoir une revendication fhirUser ou extension_fhirUser qui a l’URL complète d’une ressource patient dans le service FHIR.

Schéma pour configurer des fournisseurs d’identité

L’élément smartIdentityProviders est un tableau JSON qui contient une ou deux identity provider configurations. Une identity provider configuration se compose de

Une valeur de chaîne authority qui doit être l’URL complète de l’autorité de jeton des fournisseurs d’identité.
Un tableau applications qui contient la ressource du fournisseur d’identité application configurations.

{
  "properties": {
    "authenticationConfiguration": {
      "authority": "string",
      "audience": "string",
      "smartProxyEnabled": "bool",
      "smartIdentityProviders": [
        {
          "authority": "string",
          "applications": [
            {
              "clientId": "string",
              "allowedDataActions": "array",
              "audience": "string"
            }
          ]
        }
      ]
    }
  }
}

L’élément applications est un tableau JSON qui contient une ou deux application configurations.

La signature application configuration est constituée des éléments suivants :

Une valeur de chaîne clientId pour l’ID client (également appelé ID d’application) de l’application de ressource du fournisseur d’identité.
Une audience chaîne utilisée pour valider la revendication aud dans les jetons d’accès.
Tableau de allowedDataActions. Le tableau allowedDataActions ne peut contenir que la valeur de chaîne Read.

{
  "authority": "string",
  "applications": [
    {
      "clientId": "string",
      "allowedDataActions": "array",
      "audience": "string"
    }
  ]
}

{
  "clientId": "string",
  "allowedDataActions": "array",
  "audience": "string"
}

Étapes suivantes

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

Configurer plusieurs fournisseurs d’identité

Remarque

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

Partager via

Résoudre les problèmes de configuration des fournisseurs d’identité pour le service FHIR

Messages d’erreur

Erreurs de requête d’API FHIR

Schéma pour configurer des fournisseurs d’identité

Étapes suivantes

Commentaires

Ressources supplémentaires