Konfiguracja tożsamości usługi Azure Active Directory dla usługi Azure API for FHIR

  • Artykuł

Podczas pracy z danymi opieki zdrowotnej ważne jest, aby upewnić się, że dane są bezpieczne i nie mogą być dostępne przez nieautoryzowanych użytkowników lub aplikacje. Serwery FHIR używają protokołu OAuth 2.0 w celu zapewnienia bezpieczeństwa danych. Interfejs API platformy Azure dla standardu FHIR jest zabezpieczony przy użyciu usługi Azure Active Directory, która jest przykładem dostawcy tożsamości OAuth 2.0. Ten artykuł zawiera omówienie autoryzacji serwera FHIR oraz kroki wymagane do uzyskania tokenu w celu uzyskania dostępu do serwera FHIR. Chociaż te kroki dotyczą dowolnego serwera FHIR i dowolnego dostawcy tożsamości, przejdziemy przez usługę Azure API for FHIR jako serwer FHIR i usługę Azure Active Directory (Azure AD) jako dostawcę tożsamości w tym artykule.

Omówienie kontroli dostępu

Aby aplikacja kliencka mogła uzyskać dostęp do usługi Azure API for FHIR, musi przedstawić token dostępu. Token dostępu to podpisana, zakodowana w formacie Base64 kolekcja właściwości (oświadczeń), która przekazuje informacje o tożsamości klienta oraz rolach i uprawnieniach przyznanych klientowi.

Istnieje wiele sposobów uzyskania tokenu, ale interfejs API platformy Azure dla standardu FHIR nie obchodzi sposobu uzyskania tokenu, o ile jest to odpowiednio podpisany token z poprawnymi oświadczeniami.

Na przykład w przypadku korzystania z przepływu kodu autoryzacji uzyskiwanie dostępu do serwera FHIR odbywa się w następujących czterech krokach:

Autoryzacja FHIR

  1. Klient wysyła żądanie do /authorize punktu końcowego Azure AD. Azure AD przekierowuje klienta do strony logowania, na której użytkownik będzie uwierzytelniać się przy użyciu odpowiednich poświadczeń (na przykład nazwy użytkownika i hasła lub uwierzytelniania dwuskładnikowego). Zobacz szczegółowe informacje na temat uzyskiwania kodu autoryzacji. Po pomyślnym uwierzytelnieniu kod autoryzacji jest zwracany do klienta. Azure AD zezwoli na powrót tego kodu autoryzacji tylko do zarejestrowanego adresu URL odpowiedzi skonfigurowanego podczas rejestracji aplikacji klienckiej.
  2. Aplikacja kliencka wymienia kod autoryzacji dla tokenu dostępu w /token punkcie końcowym Azure AD. Podczas żądania tokenu aplikacja kliencka może wymagać podania klucza tajnego klienta (hasła aplikacji). Zobacz szczegółowe informacje na temat uzyskiwania tokenu dostępu.
  3. Klient wysyła żądanie do usługi Azure API for FHIR, na przykład GET /Patient, aby przeszukać wszystkich pacjentów. Gdy klient wysyła żądanie, dołącza token dostępu w nagłówku żądania HTTP, na przykład Authorization: Bearer eyJ0e..., gdzie eyJ0e... reprezentuje token dostępu zakodowany w formacie Base64.
  4. Interfejs API platformy Azure dla standardu FHIR sprawdza, czy token zawiera odpowiednie oświadczenia (właściwości w tokenie). Jeśli wszystko zostanie wyewidencjonowana, zakończy żądanie i zwróci pakiet FHIR z wynikami do klienta.

Należy pamiętać, że usługa Azure API for FHIR nie jest zaangażowana w weryfikowanie poświadczeń użytkownika i nie wystawia tokenu. Uwierzytelnianie i tworzenie tokenu odbywa się przez Azure AD. Interfejs API platformy Azure dla standardu FHIR po prostu sprawdza, czy token jest podpisany poprawnie (jest autentyczny) i czy ma odpowiednie oświadczenia.

Struktura tokenu dostępu

Opracowywanie aplikacji Fast Healthcare Interoperability Resources (FHIR®) często obejmuje problemy z dostępem do debugowania. Jeśli klient nie ma dostępu do usługi Azure API for FHIR, warto zrozumieć strukturę tokenu dostępu i sposób jego dekodowania w celu sprawdzenia zawartości (oświadczeń) tokenu.

Serwery FHIR zwykle oczekują tokenu internetowego JSON (JWT, czasami wymawiane "jot"). Składa się z trzech części:

Część 1. Nagłówek, który może wyglądać następująco:

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

Część 2. Ładunek (oświadczenia), na przykład:

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

Część 3. Podpis, który jest obliczany przez łączenie zakodowanej zawartości nagłówka Base64 i ładunku oraz obliczanie skrótu kryptograficznego na podstawie algorytmu (alg) określonego w nagłówku. Serwer będzie mógł uzyskać klucze publiczne od dostawcy tożsamości i sprawdzić, czy ten token został wystawiony przez określonego dostawcę tożsamości i nie został naruszony.

Pełny token składa się z zakodowanych w formacie Base64 (faktycznie zakodowanych adresów URL Base64) wersji tych trzech segmentów. Trzy segmenty są łączone i oddzielone kropką . .

Przykład tokenu jest wyświetlany jako:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJvaWQiOiIxMjMiLCAiaXNzIjoiaHR0cHM6Ly9pc3N1ZXJ1cmwiLCJpYXQiOjE0MjI3Nzk2MzgsInJvbGVzIjpbImFkbWluIl19.gzSraSYS8EXBxLN_oWnFSRgCzcmJmMjLiuyu5CSpyHI

Token można zdekodować i sprawdzić za pomocą narzędzi, takich jak https://jwt.ms. Wynikiem dekodowania tokenu jest:

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

Uzyskiwanie tokenu dostępu

Jak wspomniano, istnieje kilka sposobów uzyskania tokenu z Azure AD. Zostały one szczegółowo opisane w dokumentacji dewelopera Azure AD.

Użyj jednego z następujących protokołów uwierzytelniania:

Istnieją inne odmiany (na przykład ze względu na przepływ) w celu uzyskania tokenu. Szczegółowe informacje można znaleźć w dokumentacji Azure AD. W przypadku korzystania z interfejsu API platformy Azure dla standardu FHIR istnieją skróty do uzyskiwania tokenu dostępu (na przykład do celów debugowania) przy użyciu interfejsu wiersza polecenia platformy Azure.

Następne kroki

W tym dokumencie przedstawiono niektóre podstawowe pojęcia związane z zabezpieczaniem dostępu do interfejsu API platformy Azure for FHIR przy użyciu Azure AD. Aby uzyskać informacje o sposobie wdrażania usługi Azure API for FHIR, zobacz

Wdrażanie usługi Azure API for FHIR

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