Rozwiązywanie problemów z konfiguracją dostawcy tożsamości na potrzeby usługi FHIR

Interfejs API w wersji 2023-12-01 usługi FHIR® w usługach Azure Health Data Services obsługuje dwóch dostawców tożsamości oprócz identyfikatora Entra firmy Microsoft. Aby zapewnić użytkownikom dostęp o określonym zakresie, należy skonfigurować dwóch dostawców tożsamości, wypełniając sekcję smartIdentityProviders obiektu authenticationConfiguration.

Komunikaty o błędach

Poniżej przedstawiono komunikaty o błędach występujące w przypadku problemów z dostawcami tożsamości SMART usługi FHIR oraz zalecane działania, które należy podjąć w celu rozwiązania problemu.

Błąd Przyczyna Napraw
Maksymalna liczba dostawców tożsamości SMART wynosi 2. Liczba skonfigurowanych dostawców tożsamości jest większa niż dwa. Zmniejsz liczbę dostawców tożsamości do maksymalnie dwóch.
Co najmniej jedna wartość urzędu dostawcy tożsamości SMART ma wartość null, jest pusta lub nieprawidłowa. Element authority konfiguracji dostawcy tożsamości musi być w pełni kwalifikowanym adresem URL. Upewnij się, że wszystkie wartości authority są w pełni kwalifikowanymi adresami URL.
Wszystkie urzędy dostawcy tożsamości SMART muszą być unikatowe. Elementy authority dwóch konfiguracji dostawcy tożsamości są identyczne. Upewnij się, że wszystkie wartości authority są unikatowymi, w pełni kwalifikowanymi adresami URL.
Maksymalna liczba aplikacji dostawcy tożsamości SMART wynosi 2. Liczba aplikacji dostawcy tożsamości w konfiguracji dostawcy tożsamości jest większa od dwóch. Zmniejsz liczbę aplikacji dostawcy tożsamości do jednej lub dwóch na dostawcę tożsamości.
Co najmniej jedna aplikacja SMART ma wartość null. Element applications dla co najmniej jednego dostawcy tożsamości ma wartość null lub nie zawiera żadnych aplikacji. Upewnij się, że wszystkie konfiguracje dostawcy tożsamości mają skonfigurowaną co najmniej jedną aplikację.
Co najmniej jedna aplikacja SMART allowedDataActions zawiera zduplikowane elementy. Tablica allowedDataActions w co najmniej jednej konfiguracji aplikacji zawiera zduplikowane wartości. Usuń wszystkie zduplikowane wartości w tablicach allowedDataActions.
Co najmniej jedna wartość aplikacji SMART allowedDataActions jest nieprawidłowa. Jedyną akceptowalną wartością w tablicy allowedDataActions jest Read. Usuń wszystkie niezgodne wartości z tablic allowedDataActions.
Co najmniej jedna wartość aplikacji SMART allowedDataActions ma wartość null, jest pusta lub nieprawidłowa. Tablica allowedDataActions w co najmniej jednej konfiguracji aplikacji ma wartość null, jest pusta lub źle sformułowana. Jedyną akceptowalną wartością w tablicy allowedDataActions jest Read.
Co najmniej jedna wartość aplikacji SMART audience ma wartość null, jest pusta lub nieprawidłowa. Ciąg audience w co najmniej jednej konfiguracji aplikacji ma wartość null, jest pusty lub źle sformułowany. Upewnij się, że ciąg audience nie ma wartości null ani nie jest pusty i że wartość jest typem ciągu.
Wszystkie identyfikatory klienta aplikacji dostawcy tożsamości SMART muszą być unikatowe. Wartość clientId w co najmniej jednej konfiguracji aplikacji jest taka sama jak inna wartość clientId. Upewnij się, że wszystkie wartości clientId są unikatowe (w tym w konfiguracjach dostawcy tożsamości).
Co najmniej jedna wartość identyfikatora klienta aplikacji SMART ma wartość null, jest pusta lub nieprawidłowa. Ciąg clientId w co najmniej jednej konfiguracji aplikacji ma wartość null, jest pusty lub źle sformułowany. Upewnij się, że ciąg clientId nie ma wartości null ani nie jest pusty i że wartość jest typem ciągu.

Błędy żądań interfejsu API FHIR

Jeśli używasz tokenu wystawionego przez dostawcę tożsamości SMART do wykonywania żądań do usługi FHIR, możesz napotkać na dwa typowe kody błędów: 401 Unauthorized lub 403 Forbidden. Aby rozpocząć rozwiązywanie problemów, sprawdź konfigurację elementu smartIdentityProviders, zwłaszcza jeśli usługa FHIR jest nowa.

Wykonaj następujące kroki, aby zweryfikować poprawną konfigurację elementu smartIdentityProviders.

  1. Sprawdź, czy element smartIdentityProviders jest poprawnie skonfigurowany.

  2. Sprawdź, czy ciąg authority jest poprawny. Upewnij się, że ciąg authority jest urzędem tokenu dostawcy tożsamości, który wystawił token dostępu.

  3. Sprawdź, czy ciąg authority jest prawidłowym urzędem tokenu. Utwórz żądanie konfiguracji openid-connect. Dołącz /.well-known/openid-configuration na końcu ciągu aubrowser navigatesthority, a następnie wklej go w przeglądarce. Jeśli wartość jest poprawna, przeglądarka przejdzie do openid-connect configuration. Jeśli nie, występuje problem z ciągiem.

    Przykład:

    https://<YOUR_IDENTITY_PROVIDER_AUTHORITY>/authority/v2.0/.well-known/openid-configuration
    
    
  4. Sprawdź, czy ciąg clientId jest poprawny. Upewnij się, że ciąg clientId jest zgodny z identyfikatorem klienta (lub identyfikatorem aplikacji) aplikacji zasobów zdefiniowanej w dostawcy tożsamości.

  5. Sprawdź, czy metoda żądania to GET. Jedynym obsługiwanym typem żądania jest GET, ponieważ wartości allowedDataActions obsługują tylko Read.

  6. Sprawdź oświadczenia JSON web token (JWT). Jeśli token dostępu jest dostępny, zdekoduj go przy użyciu narzędzi online, takich jak jwt.ms. Po zdekodowaniu tokenu oświadczenia można sprawdzić pod kątem poprawności.

    Screenshot showing jwt web token claims.

  7. Sprawdź iss (oświadczenie wystawcy). Upewnij się, że oświadczenie iss jest całkowicie zgodne z wartością issuer w konfiguracji OpenId dostawców tożsamości.

    Zanotuj wartość authority z konfiguracji dostawcy tożsamości smartIdentityProvider, dołącz ją za pomocą /.well-known/openid-configuration, a następnie wklej ją w przeglądarce. Jeśli wartość jest poprawna, przeglądarka przejdzie do konfiguracji openid-connect.

    Przykład:

    https://<YOUR_IDENTITY_PROVIDER_AUTHORITY>/authority/v2.0/.well-known/openid-configuration
    
  8. Sprawdź polecenie azp lub appid (autoryzowana strona lub oświadczenie appid). Oświadczenie azp lub appid musi dokładnie odpowiadać wartości clientId podanej w konfiguracji dostawcy tożsamości smartIdentityProvider.

  9. Sprawdź aud (oświadczenie odbiorcy). Oświadczenie aud musi dokładnie odpowiadać wartości audience podanej w konfiguracji dostawcy tożsamości smartIdentityProvider.

  10. Sprawdź spc (oświadczenie zakresu). Wymagane jest oświadczenie scp. Jeśli go brakuje, żądanie zakończy się niepowodzeniem. Format oświadczenia scp musi być zgodny z zakresami SMART w usłudze FHIR v1. Pamiętaj, że usługa FHIR obsługuje obecnie tylko zakresy Read (odczyt). Akceptowalna wariacja zakresów SMART w usłudze FHIR v1 zastępuje dowolny ukośnik (/) kropką (.) i gwiazdkę (*) wartością all. Na przykład akceptowalną wersją zakresu SMART w usłudze FHIR patient/*.read jest patient.all.read.

Uwaga

Obsługiwane są tylko read zakresy.

  1. Sprawdź fhirUser lub extension_fhirUser (oświadczenie użytkownika FHIR). Wymagane jest oświadczenie fhirUser lub extension_fhirUser. Jeśli go brakuje, żądanie zakończy się niepowodzeniem. To oświadczenie łączy użytkownika w dostawcy tożsamości z zasobem użytkownika w usłudze FHIR. Wartość musi być w pełni kwalifikowanym adresem URL zasobu w usłudze FHIR reprezentującej osobę, dla której wystawiany jest token dostępu. Na przykład token dostępu wystawiony dla zalogowanego pacjenta powinien mieć oświadczenie fhirUser lub extension_fhirUser zawierające w pełni kwalifikowany adres URL zasobu pacjenta w usłudze FHIR.

Schemat konfigurowania dostawców tożsamości

Element smartIdentityProviders jest tablicą JSON zawierającą jedną lub dwie konfiguracje identity provider configurations. Konfiguracja identity provider configuration składa się z następujących elementów:

  • Wartość ciągu authority, która musi być w pełni kwalifikowanym adresem URL urzędu tokenu dostawców tożsamości.

  • Tablica applications zawierająca zasób dostawcy tożsamości application configurations.

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

Element applications jest tablicą JSON zawierającą jedną lub dwie konfiguracje application configurations.

Konfiguracja application configuration składa się z następujących elementów:

  • Wartość ciągu clientId dla identyfikatora klienta (nazywanego również identyfikatorem aplikacji) aplikacji zasobu dostawcy tożsamości.

  • Ciąg audience używany do walidacji oświadczenia aud w tokenach dostępu.

  • Tablica allowedDataActions. Tablica allowedDataActions może zawierać tylko wartość ciągu Read.

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

Następne kroki

Udzielanie dostępu do usługi FHIR przy użyciu usługi Azure Active Directory B2C

Konfigurowanie wielu dostawców tożsamości

Uwaga

FHIR® jest zastrzeżonym znakiem towarowym HL7 i jest używany z uprawnieniem HL7.