Uwierzytelnianie i autoryzacja dla usług Azure Health Data Services

Authentication

Azure Health Data Services to zbiór zabezpieczonych usług zarządzanych przy użyciu usługi Azure Active Directory (Azure AD) — globalnego dostawcy tożsamości obsługującego protokół OAuth 2.0.

Aby usługi Azure Health Data Services mogły uzyskiwać dostęp do zasobów platformy Azure, takich jak konta magazynu i centra zdarzeń, należy włączyć tożsamość zarządzaną przez system i udzielić odpowiednich uprawnień tożsamości zarządzanej. Aby uzyskać więcej informacji, zobacz Tożsamości zarządzane platformy Azure.

Usługi Azure Health Data Services nie obsługują innych dostawców tożsamości. Jednak klienci mogą używać własnego dostawcy tożsamości do zabezpieczania aplikacji i umożliwiać im interakcję z usługami danych kondycji, zarządzając aplikacjami klienckimi i kontrolami dostępu do danych użytkowników.

Aplikacje klienckie są rejestrowane w usłudze Azure AD i mogą służyć do uzyskiwania dostępu do usług Azure Health Data Services. Mechanizmy kontroli dostępu do danych użytkownika są wykonywane w aplikacjach lub usługach implementujących logikę biznesową.

Role aplikacji

Uwierzytelnieni użytkownicy i aplikacje klienckie usług Azure Health Data Services muszą mieć odpowiednie role aplikacji.

Usługa FHIR usług Azure Health Data Services oferuje następujące role:

  • Czytnik danych FHIR: może odczytywać (i wyszukiwać) dane FHIR.
  • Zapis danych FHIR: może odczytywać, zapisywać i usuwać nietrwałe dane FHIR.
  • Podmiot przekazujący dane FHIR: może odczytywać i eksportować dane (operator $export).
  • Współautor danych FHIR: może wykonywać wszystkie operacje płaszczyzny danych.
  • Konwerter danych FHIR: może użyć konwertera do przeprowadzenia konwersji danych.

Usługa DICOM usług Azure Health Data Services zapewnia następujące role:

  • Właściciel danych DICOM: może odczytywać, zapisywać i usuwać dane DICOM.
  • Odczyt danych DICOM: może odczytywać dane DICOM.

Usługa MedTech nie wymaga ról aplikacji, ale korzysta z "odbiornika danych usługi Azure Event Hubs", aby pobrać dane przechowywane w centrum zdarzeń subskrypcji klienta.

Autoryzacja

Po udzieleniu odpowiednich ról aplikacji uwierzytelnieni użytkownicy i aplikacje klienckie mogą uzyskiwać dostęp do usług Azure Health Data Services, uzyskując prawidłowy token dostępu wystawiony przez usługę Azure AD i wykonując określone operacje zdefiniowane przez role aplikacji.

  • W przypadku usługi FHIR token dostępu jest specyficzny dla usługi lub zasobu.
  • W przypadku usługi DICOM token dostępu jest udzielany zasobowi dicom.healthcareapis.azure.com , a nie określonej usłudze.
  • W przypadku usługi MedTech token dostępu nie jest wymagany, ponieważ nie jest on udostępniany użytkownikom ani aplikacjom klienckim.

Kroki autoryzacji

Istnieją dwa typowe sposoby uzyskiwania tokenu dostępu, szczegółowo opisane w dokumentacji usługi Azure AD: przepływ kodu autoryzacji i przepływ poświadczeń klienta.

Aby uzyskać token dostępu dla usług Azure Health Data Services, wykonaj następujące kroki przy użyciu przepływu kodu autoryzacji:

  1. Klient wysyła żądanie do punktu końcowego autoryzacji usługi Azure AD. Usługa Azure AD przekierowuje klienta do strony logowania, na której użytkownik uwierzytelnia się przy użyciu odpowiednich poświadczeń (na przykład: nazwa użytkownika i hasło lub uwierzytelnianie dwuskładnikowe). Po pomyślnym uwierzytelnieniu kod autoryzacji jest zwracany do klienta. Usługa Azure AD umożliwia zwrócenie tego kodu autoryzacji tylko do zarejestrowanego adresu URL odpowiedzi skonfigurowanego podczas rejestracji aplikacji klienckiej.

  2. Aplikacja kliencka wymienia kod autoryzacji tokenu dostępu w punkcie końcowym tokenu usługi Azure AD. Podczas żądania tokenu aplikacja kliencka może wymagać podania wpisu tajnego klienta (który można dodać podczas rejestracji aplikacji).

  3. Klient wysyła żądanie do usług Azure Health Data Services, na przykład GET żądanie przeszukania wszystkich pacjentów w usłudze FHIR. Podczas wprowadzania żądania zawiera token dostępu w nagłówku HTTP żądania, na przykład Authorization: Bearer xxx.

  4. Usługa Azure Health Data Services sprawdza, czy token zawiera odpowiednie oświadczenia (właściwości w tokenie). Jeśli jest on prawidłowy, kończy żądanie i zwraca dane do klienta.

W przepływie poświadczeń klienta uprawnienia są przyznawane bezpośrednio do samej aplikacji. Gdy aplikacja przedstawia token do zasobu, zasób wymusza, że sama aplikacja ma autoryzację do wykonania akcji, ponieważ nie ma żadnego użytkownika zaangażowanego w uwierzytelnianie. W związku z tym różni się on od przepływu kodu autoryzacji w następujący sposób:

  • Użytkownik lub klient nie musi logować się interaktywnie
  • Kod autoryzacji nie jest wymagany.
  • Token dostępu jest uzyskiwany bezpośrednio za pośrednictwem uprawnień aplikacji.

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, rolach i uprawnieniach klienta klienta.

Usługi Azure Health Data Services zwykle oczekują tokenu internetowego JSON. Składa się z trzech części:

  • Nagłówek
  • Payload (oświadczenia)
  • Podpis, jak pokazano na poniższej ilustracji. Aby uzyskać więcej informacji, zobacz Tokeny dostępu platformy Azure.

JASON web token signature.

Możesz użyć narzędzi online, takich jak https://jwt.ms do wyświetlania zawartości tokenu. Można na przykład wyświetlić szczegóły oświadczeń.

Typ oświadczenia Wartość Uwagi
AUD https://xxx.fhir.azurehealthcareapis.com Identyfikuje zamierzonego adresata tokenu. W id_tokensprogramie odbiorcy to identyfikator aplikacji twojej aplikacji przypisany do aplikacji w witrynie Azure Portal. Aplikacja powinna zweryfikować tę wartość i odrzucić token, jeśli wartość nie jest zgodna.
Iss https://sts.windows.net/{tenantid}/ Identyfikuje usługę tokenu zabezpieczającego (STS), która tworzy i zwraca token, oraz dzierżawę usługi Azure AD, w której użytkownik został uwierzytelniony. Jeśli token został wystawiony przez punkt końcowy w wersji 2.0, identyfikator URI zakończy się na /v2.0. Identyfikator GUID wskazujący, że użytkownik jest użytkownikiem konsumenckim z konta Microsoft, to 9188040d-6c67-4c5b-b112-36a304b66dad. Aplikacja powinna używać części identyfikatora GUID oświadczenia, aby ograniczyć zestaw dzierżaw, które mogą logować się do aplikacji, jeśli ma to zastosowanie.
Iat (sygnatura czasowa) Wyrażenie "Wystawione pod" wskazuje, kiedy wystąpiło uwierzytelnianie dla tego tokenu.
Nbf (sygnatura czasowa) Oświadczenie "nbf" (nie przed) identyfikuje czas, przed którym JWT NIE MOŻE zostać zaakceptowany do przetwarzania.
exp (sygnatura czasowa) Oświadczenie "exp" (czas wygaśnięcia) identyfikuje czas wygaśnięcia w dniu lub po upływie którego JWT NIE MOŻE zostać zaakceptowany do przetwarzania. Należy pamiętać, że zasób może również odrzucić token przed tym razem, jeśli na przykład wymagana jest zmiana uwierzytelniania lub wykryto odwołanie tokenu.
Aio E2ZgYxxx Wewnętrzne oświadczenie używane przez usługę Azure AD do rejestrowania danych w celu ponownego użycia tokenu. Należy zignorować.
Appid e97e1b8c-xxx Jest to identyfikator aplikacji klienta przy użyciu tokenu. Aplikacja może działać jako sama lub w imieniu użytkownika. Identyfikator aplikacji zazwyczaj reprezentuje obiekt aplikacji, ale może również reprezentować obiekt jednostki usługi w usłudze Azure AD.
appidacr 1 Wskazuje sposób uwierzytelniania klienta. W przypadku klienta publicznego wartość to "0". Jeśli używany jest identyfikator klienta i klucz tajny klienta, wartość to "1". Jeśli certyfikat klienta został użyty do uwierzytelniania, wartość to "2".
Idp https://sts.windows.net/{tenantid}/ Rejestruje dostawcę tożsamości, który uwierzytelnił podmiot tokenu. Ta wartość jest identyczna z wartością oświadczenia wystawcy, chyba że konto użytkownika nie znajduje się w tej samej dzierżawie co wystawca — goście, na przykład. Jeśli oświadczenie nie jest obecne, oznacza to, że zamiast tego można użyć wartości iss. W przypadku kont osobistych używanych w kontekście organizacji (na przykład konta osobistego zaproszonego do dzierżawy usługi Azure AD) oświadczenie dostawcy tożsamości może mieć wartość "live.com" lub identyfikator URI usługi STS zawierający dzierżawę konta Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
Oid Na przykład identyfikator dzierżawy Jest to niezmienny identyfikator obiektu w systemie tożsamości firmy Microsoft, w tym przypadku konto użytkownika. Ten identyfikator jednoznacznie identyfikuje użytkownika w aplikacjach — dwie różne aplikacje logując się do tego samego użytkownika otrzymają tę samą wartość w oświadczeniu oid. Program Microsoft Graph zwróci ten identyfikator jako właściwość ID dla danego konta użytkownika. Ponieważ identyfikator oid umożliwia korelowanie użytkowników z wieloma aplikacjami, zakres profilu jest wymagany do otrzymania tego oświadczenia. Uwaga: jeśli jeden użytkownik istnieje w wielu dzierżawach, użytkownik będzie zawierać inny identyfikator obiektu w każdej dzierżawie — są traktowane jako różne konta, mimo że użytkownik loguje się do każdego konta przy użyciu tych samych poświadczeń.
Rh 0.ARoxxx Oświadczenie wewnętrzne używane przez platformę Azure do ponownego określania tokenów. Należy go zignorować.
Sub Na przykład identyfikator dzierżawy Podmiot zabezpieczeń, o którym token potwierdza informacje, takie jak użytkownik aplikacji. Ta wartość jest niezmienna i nie można jej ponownie przypisać ani ponownie użyć. Temat jest identyfikatorem sparowanym — jest unikatowy dla określonego identyfikatora aplikacji. W związku z tym jeśli jeden użytkownik zaloguje się do dwóch różnych aplikacji przy użyciu dwóch różnych identyfikatorów klientów, te aplikacje otrzymają dwie różne wartości oświadczenia podmiotu. Może to być wymagane w zależności od architektury i wymagań dotyczących prywatności.
Tid Na przykład identyfikator dzierżawy Identyfikator GUID reprezentujący dzierżawę usługi Azure AD, z którego pochodzi użytkownik. W przypadku kont służbowych identyfikator GUID jest niezmiennym identyfikatorem dzierżawy organizacji, do którego należy użytkownik. W przypadku kont osobistych wartość to 9188040d-6c67-4c5b-b112-36a304b66dad. Zakres profilu jest wymagany w celu otrzymania tego oświadczenia.
Uti bY5glsxxx Oświadczenie wewnętrzne używane przez platformę Azure do ponownego określania tokenów. Należy go zignorować.
Ver 1 Wskazuje wersję tokenu.

Token dostępu jest domyślnie ważny przez jedną godzinę. Możesz uzyskać nowy token lub odnowić go przy użyciu tokenu odświeżania, zanim wygaśnie.

Aby uzyskać token dostępu, możesz użyć narzędzi, takich jak Postman, rozszerzenie klienta REST w programie Visual Studio Code, programie PowerShell, interfejsie wiersza polecenia, narzędziu curl i bibliotekach uwierzytelniania usługi Azure AD.

Szyfrowanie

Podczas tworzenia nowej usługi usług Azure Health Data Services dane są domyślnie szyfrowane przy użyciu kluczy zarządzanych przez firmę Microsoft .

  • Usługa FHIR zapewnia szyfrowanie danych magazynowanych, gdy dane są utrwalane w magazynie danych.
  • Usługa DICOM zapewnia szyfrowanie danych magazynowanych podczas tworzenia obrazów danych, w tym osadzonych metadanych, jest utrwalane w magazynie danych. Gdy metadane są wyodrębniane i utrwalane w usłudze FHIR, są szyfrowane automatycznie.
  • Usługa MedTech po mapowaniu i normalizacji danych utrwala komunikaty urządzeń w usłudze FHIR, która jest szyfrowana automatycznie. W przypadkach, gdy komunikaty urządzenia są wysyłane do usługi Azure Event Hubs, która używa usługi Azure Storage do przechowywania danych, dane są automatycznie szyfrowane przy użyciu usługi Azure Storage Service Encryption (Azure SSE).

Następne kroki

W tym dokumencie przedstawiono uwierzytelnianie i autoryzację usług Azure Health Data Services. Aby dowiedzieć się, jak wdrożyć wystąpienie usług Azure Health Data Services, zobacz

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