Freigeben über


Problembehandlung der Identitätsanbieterkonfiguration für den FHIR-Dienst

Die API-Version 2023-12-01 des FHIR®-Diensts in Azure Health Data Services unterstützt zwei Identitätsanbieter zusätzlich zu Microsoft Entra ID. Konfigurieren Sie zum Bereitstellen des bereichsbezogenen Zugriffs für Benutzer die beiden Identitätsanbieter, indem Sie den Abschnitt smartIdentityProviders des authenticationConfiguration-Objekts auffüllen.

Fehlermeldungen

Hier sind die Fehlermeldungen, die auftreten, wenn die SMART-Identitätsanbieter des FHIR-Diensts ausfallen, und empfohlene Aktionen, um das Problem zu beheben.

Fehler Ursache Fix
Die maximale Anzahl von SMART-Identitätsanbietern beträgt 2. Die Anzahl der konfigurierten Identitätsanbieter ist mehr als zwei. Verringern Sie die Anzahl der Identitätsanbieter auf zwei oder weniger.
Mindestens ein Autoritätswert für den SMART-Identitätsanbieter ist NULL, leer oder ungültig. Das authority-Element der Identitätsanbieterkonfiguration muss eine vollqualifizierte URL sein. Stellen Sie sicher, dass alle authority-Werte vollqualifizierte URLs sind.
Alle SMART-Identitätsanbieterautoritäten müssen eindeutig sein. Die authority-Elemente der Konfigurationen der beiden Identitätsanbieter sind identisch. Stellen Sie sicher, dass alle authority-Werte eindeutige, vollqualifizierte URLs sind.
Die maximale Anzahl von SMART-Identitätsanbieteranwendungen beträgt 2. Die Anzahl der Identitätsanbieteranwendungen in einer Identitätsanbieterkonfiguration ist mehr als zwei. Verringern Sie die Anzahl der Identitätsanbieteranwendungen auf einen oder zwei pro Identitätsanbieter.
Mindestens eine SMART-Anwendung ist NULL. Das applications-Element für mindestens einen Identitätsanbieter ist NULL oder enthält keine Anwendungen. Stellen Sie sicher, dass alle Konfigurationen der Identitätsanbieter mindestens eine Anwendung konfiguriert haben.
Mindestens eine SMART-Anwendung allowedDataActions enthält doppelte Elemente. Das allowedDataActions-Array in mindestens einer Anwendungskonfigurationen enthält doppelte Werte. Entfernen Sie alle doppelten Werte in den allowedDataActions-Arrays.
Mindestens ein allowedDataActions-Wert der SMART-Anwendung ist ungültig. Der einzige zulässige Wert im allowedDataActions-Array ist Read. Entfernen Sie alle nicht konformen Werte aus den allowedDataActions-Arrays.
Mindestens ein allowedDataActions-Wert der SMART-Anwendung ist NULL oder leer. Das allowedDataActions-Array in mindestens einer Anwendungskonfiguration ist NULL oder leer. Der einzige zulässige Wert im allowedDataActions-Array ist Read.
Mindestens ein audience-Wert der SMART-Anwendung ist NULL, leer oder ungültig. Die audience-Zeichenfolge in mindestens einer Anwendungskonfiguration ist NULL, leer oder nicht wohlgeformt. Stellen Sie sicher, dass die audience-Zeichenfolge nicht NULL oder leer und der Wert ein Zeichenfolgentyp ist.
Alle Client-IDs der SMART-Identitätsanbieteranwendung müssen eindeutig sein. Der clientId-Wert in mindestens einer Anwendungskonfiguration ist derselbe Wert wie ein anderer clientId-Wert. Stellen Sie sicher, dass alle clientId-Werte eindeutig sind (auch über verschiedene Identitätsanbieterkonfigurationen hinweg).
Mindestens eine Client-ID der SMART-Anwendung ist NULL, leer oder ungültig. Die clientId-Zeichenfolge in mindestens einer Anwendungskonfiguration ist NULL, leer oder nicht wohlgeformt. Stellen Sie sicher, dass die clientId-Zeichenfolge nicht NULL oder leer und der Wert ein Zeichenfolgentyp ist.

FHIR-API-Anforderungsfehler

Wenn Sie ein Token verwenden, das von einem SMART-Identitätsanbieter ausgegeben wurde, um Anforderungen an den FHIR-Dienst zu stellen, treten möglicherweise zwei häufige Fehlercodes auf: 401 Unauthorized oder 403 Forbidden. Um mit der Problembehandlung zu beginnen, überprüfen Sie die Konfiguration des smartIdentityProviders-Elements, insbesondere, wenn der FHIR-Dienst neu ist.

Folgen Sie diesen Schritten, um die richtige Konfiguration des smartIdentityProviders-Elements zu überprüfen.

  1. Überprüfen Sie, dass das smartIdentityProviders-Element ordnungsgemäß konfiguriert ist.

  2. Überprüfen Sie, dass die authority-Zeichenfolge korrekt ist. Stellen Sie sicher, dass die authority-Zeichenfolge die Tokenautorität für den Identitätsanbieter ist, der das Zugriffstoken ausgestellt hat.

  3. Überprüfen Sie, dass die authority-Zeichenfolge eine gültige Tokenautorität ist. Erstellen Sie eine Anforderung für die openid-connect-Konfiguration. Fügen Sie /.well-known/openid-configuration an das Ende der aubrowser navigatesthority-Zeichenfolge an, und fügen Sie dies dann in Ihren Browser ein. Wenn der Wert korrekt ist, navigiert der Browser zur openid-connect configuration. Falls nicht, liegt ein Problem mit der Zeichenfolge vor.

    Beispiel:

    https://<YOUR_IDENTITY_PROVIDER_AUTHORITY>/authority/v2.0/.well-known/openid-configuration
    
    
  4. Überprüfen Sie, dass die clientId-Zeichenfolge korrekt ist. Stellen Sie sicher, dass die clientId-Zeichenfolge mit der Client-ID (oder Anwendungs-ID) der im Identitätsanbieter definierten Ressourcenanwendung übereinstimmt.

  5. Überprüfen Sie, dass die Anforderungsmethode GET ist. Der einzige unterstützte Anforderungstyp ist GET, da die allowedDataActions-Werte nur Read unterstützen.

  6. Überprüfen Sie die Ansprüche des JSON-Webtokens (JWT). Wenn das Zugriffstoken verfügbar ist, decodieren Sie es mithilfe von Onlinetools wie jwt.ms. Nachdem das Token decodiert wurde, können die Ansprüche auf Richtigkeit überprüft werden.

    Screenshot von JWT-Webtokenansprüchen.

  7. Überprüfen Sie den iss (Ausstelleranspruch). Stellen Sie sicher, dass der iss-Anspruch exakt mit dem issuer-Wert in der OpenId-Konfiguration Ihrer Identitätsanbieter übereinstimmt.

    Nehmen Sie den authority-Wert aus der smartIdentityProvider-Identitätsanbieterkonfiguration, fügen Sie ihm /.well-known/openid-configuration an, und fügen Sie ihn dann in Ihren Browser ein. Wenn der Wert korrekt ist, navigiert der Browser zur openid-connect-Konfiguration.

    Beispiel:

    https://<YOUR_IDENTITY_PROVIDER_AUTHORITY>/authority/v2.0/.well-known/openid-configuration
    
  8. Überprüfen Sie die azp oder appid (autorisierte Partei oder appid-Anspruch). Der azp- oder appid-Anspruch muss exakt mit dem clientId-Wert übereinstimmen, der in dersmartIdentityProvider-Identitätsanbieterkonfiguration bereitgestellt wurde.

  9. Überprüfen Sie den aud (Zielgruppenanspruch). Der aud-Anspruch muss exakt mit dem audience-Wert übereinstimmen, der in der smartIdentityProvider-Identitätsanbieterkonfiguration bereitgestellt wurde.

  10. Überprüfen Sie den scp (Bereichsanspruch). Der scp-Anspruch ist erforderlich. Fehlt sie, schlägt die Anforderung fehl. Das Format des scp-Anspruchs muss SMART auf FHIR v1-Bereichen entsprechen. Es ist wichtig zu beachten, dass der FHIR-Dienst derzeit nur Lesebereiche unterstützt. Eine akzeptable Variation von SMART auf FHIR v1-Bereichen ersetzt jeden Schrägstrich (/) durch einen Punkt (.) und Sternchen (*) durch all. Beispielsweise ist patient.all.read eine akzeptable Version des SMART auf dem FHIR-Bereich patient/*.read.

Hinweis

Nur read-Bereiche werden unterstützt.

  1. Überprüfen Sie den fhirUser oder extension_fhirUser (FHIR-Benutzeranspruch). Der fhirUser- oder extension_fhirUser-Anspruch ist erforderlich. Fehlt sie, schlägt die Anforderung fehl. Dieser Anspruch verknüpft Benutzer*innen im Identitätsanbieter mit einer Benutzerressource im FHIR-Dienst. Der Wert muss die vollqualifizierte URL einer Ressource im FHIR-Dienst sein, welche die Person darstellt, an die das Zugriffstoken ausgegeben wird. Beispielsweise sollte das Zugriffstoken, das für angemeldete Patient*innen ausgestellt wurde, über einen fhirUser- oder extension_fhirUser-Anspruch verfügen, der die vollqualifizierte URL einer Patient*innen-Ressource im FHIR-Dienst besitzt.

Schema zum Konfigurieren von Identitätsanbietern

Das smartIdentityProviders-Element ist ein JSON-Array, das eine oder zwei identity provider configurations enthält. Eine identity provider configuration besteht aus:

  • Einem authority-Zeichenfolgenwert, der die vollqualifizierte URL der Identitätsanbieter-Tokenautorität sein muss.

  • Einem applications-Array, das die Identitätsanbieterressource application configurations enthält.

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

Das applications-Element ist ein JSON-Array, das eine oder zwei application configurations enthält.

application configuration umfasst Folgendes:

  • Ein clientId-Zeichenfolgenwert für die Client-ID (auch als Anwendungs-ID bezeichnet) der Identitätsanbieter-Ressourcenanwendung.

  • Eine audience-Zeichenfolge, die zum Überprüfen des aud-Anspruchs in Zugriffstoken verwendet wird.

  • Ein Array von allowedDataActions. Das allowedDataActions-Array kann nur den Zeichenfolgenwert Read enthalten.

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

Nächste Schritte

Verwenden von Azure Active Directory B2C zum Gewähren des Zugriffs auf den FHIR-Dienst

Konfigurieren mehrerer Identitätsanbieter

Hinweis

FHIR® ist eine eingetragene Marke von HL7 und wird mit Genehmigung von HL7 verwendet.