Wzorzec tożsamości federacyjnej

Delegowanie uwierzytelniania do zewnętrznego dostawcy tożsamości. Może to uprościć programowanie, ograniczyć potrzebę administracji przez użytkowników oraz zwiększyć komfort korzystania z aplikacji.

Kontekst i problem

W ramach relacji biznesowych użytkownicy zwykle korzystają z wielu aplikacji, dostarczanych i hostowanych przez różne organizacje. Każda aplikacja może wymagać użycia określonych, unikatowych poświadczeń. Może to powodować następujące problemy:

• Wprowadzanie chaosu do środowiska użytkownika. Użytkownicy często zapominają poświadczenia logowania, jeśli muszą używać wielu różnych zestawów.

• Ujawnianie luk w zabezpieczeniach. Rozstanie się użytkownika z firmą wymaga natychmiastowego anulowania aprowizacji jego konta. Łatwo to przeoczyć w dużych organizacjach.

• Komplikacja zarządzania użytkownikami. Administratorzy muszą zarządzać poświadczeniami wszystkich użytkowników oraz wykonywać dodatkowe zadania, takie jak wysyłanie przypomnień dotyczących haseł.

Użytkownicy zazwyczaj wolą używać tych samych poświadczeń we wszystkich aplikacjach.

Rozwiązanie

Należy zaimplementować mechanizm uwierzytelniania, który może używać tożsamości federacyjnej. Uwierzytelnianie użytkownika należy oddzielić od kodu aplikacji i delegować je do zaufanego dostawcy tożsamości. Pozwoli to uprościć programowanie i zwiększyć liczbę dostawców tożsamości dostępnych dla użytkowników, a jednocześnie zmniejszyć narzuty administracyjne. Umożliwi to również wyraźne oddzielenie uwierzytelniania od autoryzacji.

Zaufani dostawcy tożsamości obejmują katalogi firmowe, lokalne usługi federacyjne, inne usługi tokenu zabezpieczającego (STS) udostępniane przez partnerów biznesowych oraz dostawców tożsamości społecznościowych, zdolnych do uwierzytelniania użytkowników, którzy mają na przykład konto Microsoft, Google, Yahoo! lub Facebook.

Na rysunku przedstawiono wzorzec tożsamości federacyjnej, w którym aplikacja kliencka potrzebuje dostępu do usługi wymagającej uwierzytelnienia. Uwierzytelnianie jest wykonywane przez dostawcę tożsamości, który współdziała z usługą STS. Dostawca tożsamości wystawia tokeny zabezpieczające, zawierające informacje o uwierzytelnionym użytkowniku. Te informacje, nazywane oświadczeniami, zawierają tożsamość użytkownika, a także mogą zawierać inne informacje, takie jak członkostwo w rolach i bardziej szczegółowe prawa dostępu.

Model ten jest często nazywany kontrolą dostępu opartą na oświadczeniach. Aplikacje oraz usługi autoryzują dostęp do funkcji i funkcjonalności na podstawie oświadczeń zawartych w tokenie. Między usługą wymagającą uwierzytelnienia a dostawcą tożsamości musi występować relacja zaufania. Aplikacja kliencka nawiązuje połączenie z dostawcą tożsamości, który przeprowadza uwierzytelnianie. Jeśli uwierzytelnianie zakończy się pomyślnie, dostawca tożsamości zwraca token zawierający oświadczenia, które identyfikują użytkownika w usłudze STS (warto pamiętać, że dostawca tożsamości może być taki sam jak usługa STS). Przed zwróceniem tokenu do klienta usługa STS może przekształcić i rozszerzyć oświadczenia na podstawie wstępnie zdefiniowanych reguł. Aplikacja kliencka może następnie przekazać ten token do usługi jako dowód swojej tożsamości.

W łańcuchu zaufania mogą istnieć dodatkowe usługi tokenów zabezpieczających. Na przykład w scenariuszu opisanym w dalszej części tego artykułu występuje relacja zaufania między lokalną usługą STS a usługą STS, która jest odpowiedzialna za uzyskiwanie dostępu do dostawcy tożsamości w celu uwierzytelnienia użytkownika. Metodę tę często stosuje się w przedsiębiorstwach, w których jest używana lokalna usługa STS i katalog.

Uwierzytelnianie federacyjne obsługuje logowanie jednokrotne i zapewnia oparte na standardach rozwiązanie problemu nawiązywania relacji zaufania z tożsamościami znajdującymi się w różnych domenach. Ten typ uwierzytelniania staje się coraz bardziej powszechny we wszystkich typach aplikacji, zwłaszcza w aplikacjach hostowanych w chmurze, ponieważ obsługuje logowanie jednokrotne bez konieczności bezpośredniego połączenia sieciowego z dostawcami tożsamości. Użytkownik nie musi wprowadzać poświadczeń dla każdej aplikacji. Zwiększa to bezpieczeństwo, ponieważ uniemożliwia tworzenie poświadczeń wymaganych do uzyskania dostępu do wielu różnych aplikacji, a także ukrywa poświadczenia użytkownika od wszystkich, ale oryginalnego dostawcy tożsamości. Aplikacje „widzą” tylko informacje o uwierzytelnionej tożsamości, które znajdują się w tokenie.

Dodatkową, ważną zaletą korzystania z tożsamości federacyjnej jest to, że zarządzanie tożsamością i poświadczeniami jest realizowane przez dostawcę tożsamości. Aplikacja lub usługa nie musi udostępniać funkcji zarządzania tożsamościami. Ponadto katalog firmowy nie musi mieć informacji o tym, czy między użytkownikiem a dostawcą tożsamości istnieje relacja zaufania (w scenariuszach korporacyjnych). Pozwala to pozbyć się całego narzutu administracyjnego związanego z zarządzaniem tożsamością użytkownika w katalogu.

Problemy i kwestie do rozważenia

Projektując aplikacje, które implementują uwierzytelnianie federacyjne, należy wziąć pod uwagę następujące kwestie:

• Uwierzytelnianie może stać się pojedynczym punktem awarii. W przypadku wdrożenia aplikacji w wielu centrach danych w tych samych centrach danych należy wdrożyć mechanizm zarządzania tożsamościami. Pozwoli to zachować niezawodność i dostępność aplikacji.

• Narzędzia uwierzytelniania umożliwiają konfigurowanie kontroli dostępu na podstawie oświadczeń roli zawartych w tokenie uwierzytelniania. Metoda ta, często określana jako kontrola dostępu oparta na rolach (RBAC), umożliwia bardziej precyzyjne sterowanie dostępem do funkcji i zasobów.

• W przeciwieństwie do katalogu firmowego w przypadku opartego na oświadczeniach uwierzytelniania za pomocą dostawców tożsamości społecznościowych zwykle są udostępniane tylko adres e-mail i — czasami — nazwa uwierzytelnianego użytkownika. Niektórzy dostawcy tożsamości społecznościowych, na przykład konto Microsoft, udostępniają tylko unikatowy identyfikator. Aplikacja zwykle musi przechowywać pewne informacje o zarejestrowanych użytkownikach i mieć możliwość dopasowania tych informacji do identyfikatora zawartego w oświadczeniach w tokenie. Zazwyczaj jest to realizowane podczas rejestracji, gdy użytkownik po raz pierwszy uzyskuje dostęp do aplikacji. Po kolejnych uwierzytelnieniach informacje są wprowadzane do tokenu jako dodatkowe oświadczenia.

• Jeśli dla usługi STS skonfigurowano więcej niż jednego dostawcę tożsamości, usługa STS musi określić dostawcę tożsamości, do którego ma zostać przekierowany użytkownik na potrzeby uwierzytelniania. Proces ten jest nazywany odnajdywaniem obszaru głównego. Usługa STS może być w stanie to zrobić automatycznie na podstawie adresu e-mail lub nazwy użytkownika udostępnianej przez użytkownika, poddomeny aplikacji, do których użytkownik uzyskuje dostęp, zakresu adresów IP użytkownika lub zawartości pliku cookie przechowywanego w przeglądarce użytkownika. Na przykład jeśli użytkownik wprowadzi adres e-mail z domeny firmy Microsoft, taki jak user@live.com, usługa STS przekieruje użytkownika na stronę logowania do konta Microsoft. Podczas kolejnych odwiedzin usługa STS może użyć pliku cookie z informacją o tym, że ostatnie logowanie odbyło się przy użyciu konta Microsoft. Jeśli automatyczne odnajdywanie nie może określić obszaru głównego, usługa STS wyświetla stronę odnajdywania obszaru głównego z listą zaufanych dostawców tożsamości, na której użytkownik musi wybrać odpowiednią opcję.

Kiedy używać tego wzorca

Ten wzorzec jest przydatny w następujących scenariuszach:

• Logowanie jednokrotne w przedsiębiorstwie. Ten scenariusz wymaga uwierzytelnienia pracowników w aplikacjach firmowych hostowanych w chmurze poza granicą zabezpieczeń firmy bez konieczności każdorazowego logowania się podczas uruchamiania aplikacji. Środowisko użytkownika jest takie samo jak w przypadku korzystania z aplikacji lokalnych, gdy użytkownicy są uwierzytelniani podczas logowania do sieci firmowej, uzyskując dostęp do wszystkich odpowiednich aplikacji bez konieczności ponownego zalogowania.

• Tożsamość federacyjna z wieloma partnerami. Ten scenariusz wymaga uwierzytelniania zarówno pracowników firmowych, jak i partnerów biznesowych, którzy nie mają kont w katalogu firmy. To typowa sytuacja dla aplikacji międzyfirmowych oraz aplikacji zintegrowanych z usługami innych podmiotów, a także różnych systemów IT, które korzystają ze scalonych lub udostępnionych zasobów.

• Tożsamość federacyjna w aplikacjach SaaS. W tym scenariuszu niezależni dostawcy oprogramowania dostarczają gotowe usługi, przeznaczone dla wielu klientów lub dzierżaw. Uwierzytelnianie w poszczególnych dzierżawach odbywa się przy użyciu odpowiednich dostawców tożsamości. Na przykład użytkownicy biznesowi używają poświadczeń firmowych, a konsumenci i klienci w dzierżawie — poświadczeń tożsamości społecznościowych.

Ten wzorzec może nie być użyteczny w następujących sytuacjach:

• Wszyscy użytkownicy aplikacji mogą zostać uwierzytelnieni przez jednego dostawcę tożsamości i nie jest wymagane użycie innego dostawcy tożsamości. To typowa sytuacja dla aplikacji biznesowych, w których uwierzytelnianie odbywa się przy użyciu katalogu firmowego (dostępnego w aplikacji) za pośrednictwem sieci VPN lub (w scenariuszu obejmującym hostowanie w chmurze) połączenia sieci wirtualnej między katalogiem lokalnym i aplikacją.

• W aplikacji pierwotnie wdrożono inny mechanizm uwierzytelniania, który może korzystać z niestandardowych magazynów użytkownika, lub nie obsługuje ona standardów negocjacyjnych używanych w technologiach opartych na oświadczeniach. Modernizacja istniejących aplikacji pod kątem uwierzytelniania i kontroli dostępu opartych na oświadczeniach może okazać się złożona i prawdopodobnie nieopłacalna.

Projekt obciążenia

Architekt powinien ocenić, w jaki sposób wzorzec tożsamości federacyjnej może być używany w projekcie obciążenia, aby sprostać celom i zasadom opisanym w filarach platformy Azure Well-Architected Framework. Na przykład:

Podobnie jak w przypadku każdej decyzji projektowej, należy rozważyć wszelkie kompromisy w stosunku do celów innych filarów, które mogą zostać wprowadzone przy użyciu tego wzorca.

Przykład

Organizacja hostuje wielodostępną aplikację oprogramowania jako usługi (SaaS) na platformie Microsoft Azure. Aplikacja zawiera witrynę internetową, która pozwala zarządzać korzystaniem z tej aplikacji przez użytkowników w dzierżawach. Aplikacja umożliwia dzierżawcom dostęp do witryny internetowej przy użyciu tożsamości federacyjnej generowanej przez usługi Active Directory Federation Services (AD FS), gdy użytkownik jest uwierzytelniany przez własną usługę Active Directory.

Na rysunku przedstawiono sposób uwierzytelniania dzierżawców przy użyciu własnego dostawcy tożsamości (krok 1), w tym przypadku usług AD FS. Po pomyślnym uwierzytelnieniu dzierżawy usługi AD FS wystawiają token. Przeglądarka klienta przekazuje ten token do dostawcy federacyjnego aplikacji SaaS, który ufa tokenom wystawionym przez usługi AD FS dzierżawy, aby uzyskać token ważny dla dostawcy federacyjnego SaaS (krok 2). W razie potrzeby przed zwróceniem nowego tokenu do przeglądarki klienta dostawca federacyjny SaaS przekształca oświadczenia w tokenie do postaci rozpoznawanej przez aplikację (krok 3). Tokeny wystawione przez dostawcę federacyjnego SaaS są traktowane jako zaufane przez aplikację, która stosuje reguły autoryzacji na podstawie oświadczeń zawartych w tokenie (krok 4).

Dzierżawy nie muszą pamiętać oddzielnych poświadczeń w celu uzyskania dostępu do aplikacji, a administrator w firmie dzierżawy może skonfigurować we własnych usługach AD FS listę użytkowników, którzy mogą uzyskiwać dostęp do aplikacji.

Następne kroki

• Tożsamość Microsoft Entra
• Usługi Active Directory Domain Services
• Usługi Active Directory Federation Services
• Aplikacje wielodostępne na platformie Azure

Powiązane zasoby

• Zarządzanie tożsamościami dla aplikacji wielodostępnych na platformie Microsoft Azure
• Wzorzec strażnika
• Wzorzec konfiguracji obciążenia brzegowego
• Wzorzec konsolidacji zasobów obliczeniowych
• Wzorzec odciążania bramy