Wzorzec tożsamości federacyjnej

Delegowanie uwierzytelniania użytkowników do zewnętrznego dostawcy tożsamości w celu uproszczenia programowania, zminimalizowania zadań administracyjnych i ulepszania środowiska użytkownika aplikacji.

Kontekst i problem

Użytkownicy zazwyczaj muszą pracować z wieloma aplikacjami, które zapewniają i hostuje organizacje partnerskie. Może być konieczne użycie określonych, różnych poświadczeń logowania dla każdej aplikacji. To wymaganie może:

• Powoduje niespójny UX. Pracownicy często zapominają o wielu poświadczeniach logowania.

• Uwidaczniaj luki w zabezpieczeniach. Gdy pracownik opuszcza firmę, organizacja musi natychmiast dezaktywować konto. Duże organizacje często pomijają ten krytyczny krok.

• Komplikuj zarządzanie użytkownikami. Administratorzy zarządzają poświadczeniami użytkownika, wystawiają przypomnienia o hasłach i wykonują inne zadania administracyjne.

Użytkownicy zazwyczaj wolą używać tych samych poświadczeń logowania dla wszystkich aplikacji.

Rozwiązanie

Zaimplementuj mechanizm uwierzytelniania tożsamości federacyjnej. Oddziel uwierzytelnianie użytkownika od kodu aplikacji i powierz je zaufanemu dostawcy tożsamości (IdP). Proces ten upraszcza proces tworzenia aplikacji, minimalizuje obciążenia administracyjne i zapewnia uwierzytelnianie użytkowników za pośrednictwem różnych dostawców tożsamości (IdP). Tożsamość federacyjna oddziela również uwierzytelnianie od autoryzacji.

Zaufani dostawcy tożsamości obejmują katalogi firmowe, lokalne usługi federacyjne, usługi tokenów zabezpieczeń (STS) oraz społecznościowych dostawców tożsamości, takich jak Microsoft, Google, Yahoo! lub Facebook.

Na poniższym diagramie przedstawiono wzorzec tożsamości federacyjnej dla aplikacji klienckiej, która uzyskuje dostęp do usługi wymagającej uwierzytelniania. IdP współpracuje z usługą STS, aby zapewnić uwierzytelnianie. Dostawca tożsamości (IdP) wydaje tokeny zabezpieczające, zawierające informacje o uwierzytelnionym użytkowniku. Te informacje, nazywane oświadczeniami, zawierają tożsamość użytkownika i mogą również zawierać inne oświadczenia, takie jak członkostwo w rolach i bardziej szczegółowe prawa dostępu.

Ten model jest również nazywany kontrolą dostępu opartą na oświadczeniach. Aplikacje i usługi autoryzują dostęp do funkcji i funkcjonalności na podstawie oświadczeń. Między usługą wymagającą uwierzytelnienia a dostawcą tożsamości musi występować relacja zaufania. Aplikacja kliencka kontaktuje się z dostawcą tożsamości (IdP) w celu uwierzytelnienia. Jeśli uwierzytelnianie powiedzie się, dostawca tożsamości (IdP) zwróci do usługi STS token zawierający informacje identyfikujące użytkownika. IdP i usługa STS mogą być częścią tej samej usługi. Usługa STS może przekształcać i wzbogacać oświadczenia na podstawie wstępnie zdefiniowanych reguł, zanim zwróci klientowi token. Następnie aplikacja kliencka przekazuje ten token do usługi jako dowód tożsamości.

Uwierzytelnianie federacyjne zapewnia opartą na standardach metodę ustanawiania zaufania w tożsamościach między domenami i obsługuje logowanie jednokrotne (SSO). Wiele aplikacji, zwłaszcza aplikacji hostowanych w chmurze, korzysta z uwierzytelniania federacyjnego, ponieważ umożliwia ono logowanie jednokrotne (SSO) bez bezpośredniego połączenia sieciowego z dostawcą tożsamości (IdP). Ten projekt zwiększa bezpieczeństwo, ponieważ użytkownik nie musi tworzyć i wprowadzać różnych poświadczeń logowania dla wielu aplikacji. Ogranicza również ujawnienie poświadczeń wyłącznie do pierwotnego dostawcy tożsamości. Aplikacje widzą tylko uwierzytelnione informacje o tożsamości w tokenie.

Aplikacje i usługi korzystające z uwierzytelniania federacyjnego nie muszą zapewniać funkcji zarządzania tożsamościami. Zamiast tego za zarządzanie tożsamościami i poświadczeniami odpowiada dostawca tożsamości (IdP). Gdy katalog firmowy ufa IdP, nie musi zarządzać tożsamością użytkownika. Takie podejście eliminuje koszty administracyjne związane z zarządzaniem tożsamościami użytkowników opartymi na katalogach.

Problemy i zagadnienia

Podczas podejmowania decyzji o zaimplementowaniu tego wzorca należy wziąć pod uwagę następujące kwestie:

• Uwierzytelnianie może stać się jednym punktem awarii. Aby zachować niezawodność i dostępność aplikacji w wielu regionach, rozważ wdrożenie mechanizmu zarządzania tożsamościami w tych samych regionach co aplikacja.

• Aby skonfigurować kontrolę dostępu opartą na rolach (RBAC), użyj narzędzi uwierzytelniania. Kontrola dostępu oparta na rolach umożliwia precyzyjną kontrolę dostępu do funkcji i zasobów.

• W przeciwieństwie do katalogu firmowego uwierzytelnianie oparte na oświadczeniach, które używa dostawców tożsamości społecznościowych, zwykle udostępnia tylko adres e-mail uwierzytelnionego użytkownika, a czasami ich nazwę. Niektóre identyfikatory społecznościowe, takie jak Microsoft, zawierają tylko unikatowy identyfikator. Aplikacja zwykle przechowuje pewne informacje o zarejestrowanych użytkownikach, dzięki czemu może dopasować te informacje do identyfikatora w oświadczeniach. To zadanie jest zwykle wykonywane podczas rejestracji, gdy użytkownik po raz pierwszy uzyskuje dostęp do aplikacji. Informacje są następnie wstrzykiwane do tokenu jako nowe oświadczenia po każdym uwierzytelnieniu.

• Jeśli dla usługi STS skonfigurowano wiele dostawców tożsamości (IdP), usługa STS musi ustalić, który dostawca tożsamości powinien uwierzytelnić użytkownika. Ten proces jest nazywany odnajdywaniem obszaru macierzystego. Usługa STS może automatycznie ustalić dostawcę tożsamości (IdP) na podstawie informacji podanych przez użytkownika, takich jak adres e-mail lub nazwa użytkownika, poddomena aplikacji, zakres adresów IP użytkownika lub plik cookie przechowywany w przeglądarce użytkownika. Jeśli na przykład użytkownik wprowadzi Microsoft adres e-mail, taki jak user@live.com, usługa STS przekierowuje użytkownika do strony logowania konto Microsoft. Podczas kolejnych wizyt usługa STS może użyć pliku cookie, który wskazuje, że użytkownik wcześniej zalogował się przy użyciu konto Microsoft. Jeśli usługa STS nie może automatycznie określić obszaru macierzystego, zostanie wyświetlona strona odnajdywania obszaru macierzystego z listą zaufanych dostawców tożsamości. Następnie użytkownik wybiera IdP.

Kiedy należy używać tego wzorca

Użyj tego wzorca, jeśli potrzebujesz:

• SSO w firmie. W tym scenariuszu należy uwierzytelnić pracowników dla aplikacji firmowych hostowanych w chmurze poza granicą zabezpieczeń firmowych bez logowania za każdym razem, gdy odwiedzają aplikację. Środowisko użytkownika jest zgodne z aplikacjami lokalnymi. Użytkownicy uwierzytelniają się podczas logowania się do sieci firmowej, a następnie mogą uzyskiwać dostęp do odpowiednich aplikacji bez innego logowania.

• Tożsamość federacyjna z wieloma partnerami. W tym scenariuszu należy uwierzytelnić pracowników firmowych i partnerów biznesowych, którzy nie mają kont w katalogu firmowym. Ta praktyka jest powszechna w aplikacjach biznesowych, aplikacjach integrujących się z usługami partnerskimi oraz w firmach korzystających z różnych systemów IT, scalonych lub udostępnionych zasobów.

• Tożsamość federacyjna w aplikacjach opartych na modelu SaaS. W tym scenariuszu niezależni dostawcy oprogramowania udostępniają gotową do użycia usługę dla wielu klientów lub dzierżaw. Dzierżawcy uwierzytelniają się za pomocą odpowiedniego IdP. Na przykład użytkownicy biznesowi używają swoich poświadczeń firmowych, podczas gdy użytkownicy dzierżawy i klienci używają poświadczeń tożsamości społecznościowych.

• Tożsamość federacyjna do uzyskiwania dostępu do obciążeń roboczych. W tym scenariuszu aplikacje dzierżawcy, zautomatyzowane przepływy pracy lub systemy ciągłej integracji i ciągłego dostarczania muszą wywoływać interfejsy API bez obecności użytkownika. Dzierżawcy uwierzytelniają się za pośrednictwem własnych dostawców tożsamości (IdP) za pomocą tożsamości obciążeń roboczych. Aplikacja autoryzuje dostęp przy użyciu weryfikacji oświadczeń w zakresie dzierżawy.

Ten wzorzec może nie być odpowiedni w następujących przypadkach:

• Jeden IdP. W tym scenariuszu użytkownicy aplikacji uwierzytelniają się przy użyciu jednego dostawcy tożsamości i nie muszą uwierzytelniać się za pomocą innego dostawcy tożsamości. Taka sytuacja jest typowa w aplikacjach korzystających z katalogu firmowego do uwierzytelniania za pośrednictwem sieci VPN lub połączenia sieci wirtualnej między aplikacją a katalogiem lokalnym.

• Niezgodne mechanizmy uwierzytelniania. W tym scenariuszu aplikacja używa innego mechanizmu uwierzytelniania, na przykład poprzez użycie niestandardowych magazynów danych użytkowników, albo nie może obsługiwać standardów negocjacji technologii opartej na oświadczeniach. Wdrożenie uwierzytelniania opartego na deklaracjach oraz kontroli dostępu w istniejącej aplikacji może być złożone i kosztowne.

Projektowanie obciążenia pracy

Oceń, jak użyć wzorca tożsamości federacyjnej w architekturze obciążenia, aby uwzględnić cele i zasady opisane w filarach Azure Well-Architected Framework. Poniższa tabela zawiera wskazówki dotyczące tego, jak ten wzorzec obsługuje cele poszczególnych filarów.

Jeśli ten wzorzec wprowadza kompromisy w ramach filaru, rozważ je przed celami innych filarów.

Example

Organizacja hostuje wieloskładniową aplikację opartą na chmurze, która obejmuje fronton internetowy i interfejs API zaplecza. Aplikacja deleguje uwierzytelnianie do scentralizowanego dostawcy tożsamości za pomocą Microsoft Entra ID, zamiast implementować logikę uwierzytelniania w każdym komponencie.

Pobierz plik programu Visio tej architektury.

Poniższy przepływ pracy odpowiada poprzedniemu diagramowi.

1. Użytkownik uzyskuje dostęp do aplikacji internetowej.

2. Aplikacja internetowa przekierowuje użytkownika do Microsoft Entra ID na potrzeby uwierzytelniania.

3. Po pomyślnym uwierzytelnieniu Microsoft Entra ID przekierowuje użytkownika z powrotem do aplikacji internetowej przy użyciu kodu autoryzacji.

4. Aplikacja internetowa wymienia kod autoryzacji tokenów i wysyła żądanie POST do punktu końcowego tokenu.

5. Microsoft Entra ID wystawia token zawierający oświadczenia dotyczące użytkownika.

6. Aplikacja internetowa używa tego tokenu do wywoływania interfejsu API zaplecza.

7. Aplikacja internetowa i interfejs API zaplecza weryfikują token i egzekwują swoje reguły autoryzacji na podstawie zawartych w nim atrybutów.

8. API zwraca odpowiedź do aplikacji internetowej.

Kluczowe cechy:

• Scentralizowane uwierzytelnianie. Składniki korzystają z Microsoft Entra ID do uwierzytelniania użytkowników, co eliminuje potrzebę niestandardowej logiki uwierzytelniania w aplikacji.

• Autoryzacja zdecentralizowana. Składniki aplikacji niezależnie wymuszają decyzje dotyczące autoryzacji na podstawie oświadczeń.

• Kontrola dostępu oparta na oświadczeniach. Dostęp do funkcji jest określany przy użyciu oświadczeń, takich jak role lub zakresy.

• Protokoły oparte na standardach. Składniki używają protokołu OAuth 2.0 i OpenID Connect do uwierzytelniania.

• Opcjonalne wymuszanie uwierzytelniania wieloskładnikowego. Jeśli profil ryzyka wymaga silniejszego zapewnienia logowania, możesz wymusić uwierzytelnianie wieloskładnikowe przy użyciu zasad dostępu warunkowego w Microsoft Entra ID.

• Opcjonalna rozszerzalność za pośrednictwem federacji. Microsoft Entra ID można skonfigurować tak, aby ufało partnerskiej dzierżawie Microsoft Entra za pomocą ustawień dostępu między dzierżawami. Użytkownicy partnerów mogą następnie uzyskiwać dostęp do aplikacji bez zmian w składnikach aplikacji.

Następne kroki

• Co to jest Microsoft Entra?
• OpenID Connect na platformie Microsoft Identity Platform
• Konwertowanie aplikacji jednodzierżawnej na wielodzierżawną przy użyciu Microsoft Entra ID
• Co to jest dostęp warunkowy?

Powiązane zasoby

• Kwestie architektoniczne w zakresie tożsamości w rozwiązaniu wielodomenowym
• Wzorzec strażnika
• Wzorzec Valet Key
• Wzorzec odciążania gatewaya