Udostępnij za pośrednictwem


Rejestrowanie aplikacji usługi Azure Active Directory dla usługi Azure API for FHIR

Istnieje kilka opcji konfiguracji do wyboru podczas konfigurowania usługi Azure API for FHIR lub serwera FHIR Server for Azure (OSS). W oprogramowaniu open source należy utworzyć własną rejestrację aplikacji zasobów. W przypadku usługi Azure API for FHIR ta aplikacja zasobów jest tworzona automatycznie.

Rejestracje aplikacji

Aby aplikacja mogła wchodzić w interakcje z Azure AD, należy ją zarejestrować. W kontekście serwera FHIR istnieją dwa rodzaje rejestracji aplikacji do omówienia:

  1. Rejestracje aplikacji zasobów.
  2. Rejestracje aplikacji klienckich.

Aplikacje zasobów to reprezentacje w Azure AD interfejsu API lub zasobu, który jest zabezpieczony za pomocą Azure AD, w szczególności będzie to interfejs API platformy Azure dla standardu FHIR. Aplikacja zasobów dla usługi Azure API for FHIR zostanie utworzona automatycznie podczas aprowizacji usługi, ale jeśli używasz serwera open source, musisz zarejestrować aplikację zasobów w Azure AD. Ta aplikacja zasobów będzie mieć identyfikator URI identyfikatora. Zaleca się, aby ten identyfikator URI był taki sam jak identyfikator URI serwera FHIR. Ten identyfikator URI powinien być używany jako Audience serwer FHIR. Aplikacja kliencka może zażądać dostępu do tego serwera FHIR, gdy żąda tokenu.

Aplikacje klienckie to rejestracje klientów, którzy będą żądać tokenów. Często w standardzie OAuth 2.0 rozróżniamy co najmniej trzy różne typy aplikacji:

  1. Poufni klienci, znani również jako aplikacje internetowe w Azure AD. Poufne klienci to aplikacje korzystające z przepływu kodu autoryzacji w celu uzyskania tokenu w imieniu zalogowanego użytkownika przedstawiającego prawidłowe poświadczenia. Są one nazywane poufnymi klientami, ponieważ są w stanie przechowywać wpis tajny i przedstawią ten wpis tajny Azure AD podczas wymiany kodu uwierzytelniania dla tokenu. Ponieważ poufne klienci mogą uwierzytelniać się przy użyciu klucza tajnego klienta, są zaufani bardziej niż klienci publiczni i mogą mieć tokeny dłuższego życia i otrzymać token odświeżania. Przeczytaj szczegółowe informacje na temat rejestrowania poufnego klienta. Należy pamiętać, że należy zarejestrować adres URL odpowiedzi, pod którym klient otrzyma kod autoryzacji.
  2. Klienci publiczni. Są to klienci, którzy nie mogą przechowywać wpisu tajnego. Zazwyczaj jest to aplikacja urządzenia przenośnego lub jednostronicowa aplikacja JavaScript, w której użytkownik może odnaleźć wpis tajny w kliencie. Klienci publiczni używają również przepływu kodu autoryzacji, ale nie mogą przedstawić wpisu tajnego podczas uzyskiwania tokenu i mogą mieć tokeny o krótszym czasie użytkowania i nie mogą być tokenami odświeżania. Przeczytaj szczegółowe informacje na temat rejestrowania klienta publicznego.
  3. Klienci usług. Ci klienci uzyskują tokeny w imieniu siebie (nie w imieniu użytkownika) przy użyciu przepływu poświadczeń klienta. Zazwyczaj reprezentują one aplikacje, które uzyskują dostęp do serwera FHIR w sposób nieinterakcyjny. Przykładem może być proces pozyskiwania. W przypadku korzystania z klienta usługi nie jest konieczne rozpoczęcie procesu uzyskiwania tokenu z wywołaniem punktu końcowego /authorize . Klient usługi może przejść bezpośrednio do punktu końcowego /token i przedstawić identyfikator klienta i klucz tajny klienta w celu uzyskania tokenu. Przeczytaj szczegółowe informacje na temat rejestrowania klienta usługi

Następne kroki

W tym omówieniu przedstawiono typy rejestracji aplikacji, które mogą być potrzebne do pracy z interfejsem API FHIR.

Na podstawie konfiguracji zapoznaj się z instrukcjami dotyczącymi rejestrowania aplikacji:

Po zarejestrowaniu aplikacji możesz wdrożyć usługę Azure API for FHIR.

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