Uwierzytelnianie i autoryzacja dla usług Azure Health Data Services

Authentication

Azure Health Data Services to kolekcja 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ą systemu i udzielić odpowiednich uprawnień do 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. Można jednak użyć własnego dostawcy tożsamości do zabezpieczania aplikacji i umożliwić 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 Azure AD i mogą być używane 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).
• Importer danych FHIR: może odczytywać i importować dane (operator $import).
• Współautor danych FHIR: może wykonywać wszystkie operacje płaszczyzny danych.
• Konwerter danych FHIR: może używać konwertera do przeprowadzania konwersji danych.
• FHIR SMART User: rola umożliwia użytkownikowi odczytywanie i zapisywanie danych FHIR zgodnie ze specyfikacjami SMART IG V1.0.0.

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 polega na "odbiorniku danych 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 Azure AD i wykonywać 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 przyznawany 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 Azure AD: przepływ kodu autoryzacji i przepływ poświadczeń klienta.

Poniżej przedstawiono sposób uzyskiwania tokenu dostępu dla usług Azure Health Data Services przy użyciu przepływu kodu autoryzacji:

1. Klient wysyła żądanie do punktu końcowego autoryzacji Azure AD. 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 do klienta jest zwracany kod autoryzacji. Azure AD umożliwia zwrócenie tego kodu autoryzacji tylko do zarejestrowanego adresu URL odpowiedzi skonfigurowanego w rejestracji aplikacji klienckiej.

2. Aplikacja kliencka wymienia kod autoryzacji tokenu dostępu w punkcie końcowym tokenu Azure AD. Gdy aplikacja kliencka żąda tokenu, aplikacja może wymagać podania klucza 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. Żądanie 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, wykonuje żądanie i zwraca dane do klienta.

W przepływie poświadczeń klienta uprawnienia są przyznawane bezpośrednio samej aplikacji. Gdy aplikacja przedstawia token do zasobu, zasób wymusza, że sama aplikacja ma autoryzację do wykonania akcji, ponieważ nie ma 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 się logować 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 klienta, rolach i uprawnieniach przyznanych użytkownikowi lub klientowi.

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

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

Użyj narzędzi online, takich jak https://jwt.ms wyświetlanie zawartości tokenu. Na przykład możesz wyświetlić szczegóły oświadczeń.

Typ oświadczenia	Wartość	Uwagi
AUD	https://xxx.fhir.azurehealthcareapis.com	Identyfikuje zamierzonego adresata tokenu. W id_tokenssystemie odbiorcy to identyfikator aplikacji aplikacji przypisany do aplikacji w 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ę Azure AD, w której użytkownik został uwierzytelniony. Jeśli token został wystawiony przez punkt końcowy w wersji 2.0, identyfikator URI kończy się na ./v2.0 Identyfikator GUID wskazujący, że użytkownik jest użytkownikiem użytkownika 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ą zalogować 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 wcześniej) identyfikuje czas, przed którym JWT NIE MOŻE zostać zaakceptowane do przetwarzania.
exp	(sygnatura czasowa)	Oświadczenie "exp" (czas wygaśnięcia) identyfikuje czas wygaśnięcia lub po którym JWT NIE MOŻE zostać zaakceptowane do przetwarzania. Należy pamiętać, że zasób może odrzucić token przed tym razem, na przykład jeśli wymagana jest zmiana uwierzytelniania lub wykryto odwołanie tokenu.
Aio	E2ZgYxxx	Wewnętrzne oświadczenie używane przez Azure AD do rejestrowania danych w celu ponownego użycia tokenu. Należy zignorować.
Appid	e97e1b8c-xxx	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 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 można zamiast tego użyć wartości iss. W przypadku kont osobistych używanych w kontekście organizacji (na przykład konto osobiste zaproszone do dzierżawy Azure AD), oświadczenie dostawcy tożsamości może być "live.com" lub identyfikator URI STS zawierający dzierżawę konta Microsoft 9188040d-6c67-4c5b-b112-36a304b66dad.
Oid	Na przykład identyfikator dzierżawy	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ące się w tym samym użytkowniku otrzymują tę samą wartość w oświadczeniu identyfikatora oid. Program Microsoft Graph zwraca ten identyfikator jako właściwość ID dla danego konta użytkownika. Ponieważ identyfikator oid umożliwia wielu aplikacjom korelowanie użytkowników, zakres profilu jest wymagany do otrzymania tego oświadczenia. Uwaga: jeśli jeden użytkownik istnieje w wielu dzierżawach, użytkownik 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	Wewnętrzne oświadczenie używane przez platformę Azure do ponownego określania tokenów. Należy go zignorować.
Sub	Na przykład identyfikator dzierżawy	Zasada, o której 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 parowania — jest unikatowy dla określonego identyfikatora aplikacji. W związku z tym, jeśli jeden użytkownik loguje się do dwóch różnych aplikacji przy użyciu dwóch różnych identyfikatorów klientów, te aplikacje otrzymują dwie różne wartości dla oświadczenia podmiotu. Ten wynik może być pożądany 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ę 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	Wewnętrzne oświadczenie 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 Visual Studio Code, programie PowerShell, interfejsie wiersza polecenia, curl i bibliotekach uwierzytelniania Azure AD.

Szyfrowanie

Podczas tworzenia nowej usługi usługi 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 utrwalana w magazynie danych. Gdy metadane są wyodrębniane i utrwalane w usłudze FHIR, są szyfrowane automatycznie.
• Usługa MedTech, po mapowaniu danych i normalizacji, utrwala komunikaty urządzeń do usługi FHIR, która jest szyfrowana automatycznie. W przypadkach, gdy komunikaty urządzeń są wysyłane do Azure Event Hubs, które używają usługi Azure Storage do przechowywania danych, dane są automatycznie szyfrowane za pomocą 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

Wdrażanie obszaru roboczego usługi Azure Health Data Services przy użyciu Azure Portal

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