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

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, vous 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 et 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, vides ou ne sont pas valides. Le tableau allowedDataActions dans une ou plusieurs configurations d’application est nul, vide ou malformé. 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.

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.

  1. Vérifiez que l’élément smartIdentityProviders est correctement configuré.

  2. 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.

  3. 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
    
    
  4. 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é.

  5. 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.

  6. 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.

    Screenshot showing jwt web token claims.

  7. 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
    
  8. 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.

  9. 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.

  10. 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.

  1. 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 des éléments suivants :

  • 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.