Udostępnij za pośrednictwem

Zagadnienia architektoniczne związane z tożsamością w rozwiązaniu wielodostępowym

Tożsamość jest ważnym aspektem każdego rozwiązania wielodostępnego. Składniki tożsamości aplikacji są odpowiedzialne za następujące zadania:

  • Weryfikowanie tożsamości użytkownika, znanej jako uwierzytelnianie

  • Egzekwowanie uprawnień użytkownika w ramach dzierżawy, znane jako autoryzacja

Klienci mogą również chcieć autoryzować aplikacje zewnętrzne w celu uzyskania dostępu do swoich danych lub zintegrować je z rozwiązaniem. Tożsamość użytkownika określa, do jakich informacji użytkownik lub usługa może mieć dostęp. Ważne jest, aby wziąć pod uwagę wymagania dotyczące tożsamości w celu odizolowania aplikacji i danych między dzierżawcami.

Uwaga

Usługi uwierzytelniania i autoryzacji w aplikacjach wielodostępnych i oprogramowania jako usługi (SaaS) są zwykle udostępniane przez zewnętrznego dostawcę tożsamości . IdP jest zwykle integralną częścią zarządzanej platformy tożsamości.

Tworzenie własnego IdP (dostawcy tożsamości) jest skomplikowane, kosztowne i trudne do zabezpieczenia. Jest uważany za antywzorzec i nie zalecamy go.

Przed zdefiniowaniem strategii zarządzania tożsamością dla wielu dzierżawców należy najpierw rozważyć następujące ogólne wymagania dotyczące tożsamości dla usługi:

  • Ustal, czy tożsamości użytkowników lub obciążeń uzyskują dostęp do jednej aplikacji, czy wielu aplikacji w ramach rodziny produktów. Niektóre rodziny produktów mogą obejmować różne aplikacje, które współdzielą tę samą infrastrukturę tożsamości, takie jak systemy punktów sprzedaży i platformy zarządzania zapasami.

  • Zastanów się, czy rozwiązanie implementuje nowoczesne standardy uwierzytelniania i autoryzacji, takie jak OAuth2 i OpenID Connect.

  • Oceń, czy uwierzytelnianie jest ograniczone do aplikacji opartych na interfejsie użytkownika, czy też ma zastosowanie do najemców i systemów firm trzecich.

  • Ustal, czy najemcy muszą federować się z własnymi dostawcami tożsamości i czy dla każdego najemcy musi być obsługiwanych wielu dostawców tożsamości. Na przykład możesz mieć dzierżawców z Microsoft Entra ID, Auth0 i usługami federacyjnymi Active Directory, gdzie każda dzierżawa współpracuje z twoim rozwiązaniem. Zidentyfikuj, które protokoły federacyjne używają ich dostawcy tożsamości, ponieważ te protokoły określają, co musi obsługiwać twój dostawca tożsamości.

  • Przejrzyj wszelkie odpowiednie wymagania dotyczące zgodności, które muszą spełnić, takie jak ogólne rozporządzenie o ochronie danych (RODO), które kształtuje strategię tożsamości.

  • Ustal, czy dzierżawy wymagają przechowywania danych tożsamości w określonych regionach geograficznych w celu spełnienia wymagań prawnych, zgodności lub operacyjnych.

  • Oceń, czy użytkownicy uzyskują dostęp do danych z wielu dzierżaw w aplikacji. Jeśli tak, może być konieczne zapewnienie bezproblemowego przełączania dzierżawy lub udostępnienie skonsolidowanych widoków między dzierżawami dla określonych użytkowników. Na przykład użytkownicy logujący się w witrynie Azure Portal mogą łatwo przełączać się między różnymi katalogami identyfikatorów Entra firmy Microsoft i subskrypcjami, do których mają dostęp.

Podczas ustanawiania wymagań wysokiego poziomu możesz zacząć planować bardziej szczegółowe informacje i wymagania, takie jak źródła katalogów użytkowników i przepływy rejestracji i logowania.

Rejestr tożsamości

Aby rozwiązanie wielodostępne uwierzytelniło i autoryzuje użytkownika lub usługę, potrzebuje miejsca do przechowywania informacji o tożsamości. Katalog może zawierać autorytatywne rekordy dla każdej tożsamości. Może także zawierać odniesienia do zewnętrznych tożsamości przechowywanych w katalogu innego dostawcy tożsamości (IdP).

Podczas projektowania systemu tożsamości dla rozwiązania wielodostępnego należy rozważyć następujące typy dostawców tożsamości, których mogą potrzebować dzierżawcy i klienci:

  • Lokalny dostawca tożsamości: Lokalny dostawca tożsamości umożliwia użytkownikom zarejestrowanie się w usłudze. Użytkownicy podają nazwę użytkownika, adres e-mail lub identyfikator, taki jak numer karty nagrody. Udostępniają również poświadczenia, takie jak hasło. IdP przechowuje zarówno identyfikator użytkownika, jak i poświadczenia.

  • Dostawca tożsamości społecznościowych: Dostawca tożsamości społecznościowych umożliwia użytkownikom korzystanie z tożsamości, którą mają w sieci społecznościowej lub innej publicznej dostawcy tożsamości, takiej jak Facebook, Google lub osobiste konto Microsoft. Dostawcy tożsamości społecznościowych są często wykorzystywani w rozwiązaniach SaaS typu business-to-consumer (B2C).

  • Katalog Microsoft Entra ID najemcy: W wielu rozwiązaniach SaaS w modelu business-to-business (B2B) najemcy mogą już mieć własny katalog Microsoft Entra ID i mogą chcieć, aby Twoje rozwiązanie korzystało z ich katalogu jako dostawcy tożsamości (IdP) w celu uzyskania dostępu do rozwiązania. Takie podejście jest możliwe, gdy rozwiązanie jest tworzone jako wielodostępna aplikacja firmy Microsoft Entra.

  • Federacja z dostawcą tożsamości najemcy: W niektórych rozwiązaniach B2B SaaS, najemcy mogą mieć własnego dostawcę tożsamości innego niż Microsoft Entra ID i mogą chcieć, aby Twoje rozwiązanie było z nim zintegrowane. Federacja włącza logowanie jednokrotne (SSO). Umożliwia również dzierżawcom zarządzanie cyklem życia i zasadami zabezpieczeń użytkowników niezależnie od rozwiązania.

Należy rozważyć, czy Twoi dzierżawcy muszą obsługiwać wielu dostawców tożsamości. Na przykład pojedynczy najemca może wymagać obsługi tożsamości lokalnych, tożsamości społecznościowych i tożsamości federacyjnych. To wymaganie jest typowe, gdy firmy korzystają z rozwiązania przeznaczonego zarówno dla swoich pracowników, jak i wykonawców. Mogą oni używać federacji do udzielania pracownikom dostępu, a jednocześnie zezwalać na dostęp dla wykonawców lub użytkowników, którzy nie mają kont w sfederowanym dostawcy tożsamości.

Przechowywanie informacji o uwierzytelnianiu i autoryzacji dzierżawy

W rozwiązaniu wielodostępnym należy rozważyć miejsce przechowywania kilku typów informacji o tożsamości, w tym następujących typów:

  • Szczegółowe informacje o kontach użytkowników i usługach, w tym nazwy oraz inne dane wymagane przez dzierżawców.

  • Informacje wymagane do bezpiecznego uwierzytelniania użytkowników, w tym informacje na temat uwierzytelniania wieloskładnikowego (MFA).

  • Informacje specyficzne dla najemcy, takie jak role i uprawnienia najemcy, na potrzeby autoryzacji.

Uwaga

Nie zalecamy samodzielnego kompilowania procesów uwierzytelniania. Nowocześni dostawcy usług identyfikacyjnych zapewniają usługi uwierzytelniania dla twojej aplikacji oraz zawierają inne istotne funkcje, takie jak uwierzytelnianie wieloskładnikowe i dostęp warunkowy. Tworzenie własnego dostawcy tożsamości jest antywzorcem. Nie zalecamy tego.

Rozważ następujące opcje przechowywania informacji o tożsamości:

  • Przechowuj wszystkie informacje o tożsamości i autoryzacji w katalogu IdP i udostępniaj je pomiędzy wieloma dzierżawcami.

  • Przechowuj poświadczenia użytkownika w katalogu IdP. Przechowuj dane autoryzacji w warstwie aplikacji wraz z informacjami o dzierżawie.

Określanie liczby tożsamości użytkownika

Rozwiązania wielodostępne często umożliwiają tożsamości użytkownika lub obciążenia uzyskiwanie dostępu do zasobów aplikacji i danych w wielu dzierżawach. Jeśli to podejście jest wymagane, należy wziąć pod uwagę następujące czynniki:

  • Zdecyduj, czy utworzyć jedną tożsamość użytkownika dla każdej osoby, czy utworzyć oddzielne tożsamości dla każdej kombinacji użytkownik-dzierżawa.

    • Jeśli to możliwe, użyj jednej tożsamości dla każdej osoby. Upraszcza zarządzanie kontami zarówno dla dostawcy rozwiązań, jak i użytkowników. Ponadto wiele inteligentnych form ochrony przed zagrożeniami, które zapewniają nowocześni dostawcy tożsamości, polega na tym, że każda osoba ma jedyne konto użytkownika.

    • W niektórych scenariuszach użyj wielu odrębnych tożsamości. Jeśli na przykład użytkownicy używają systemu zarówno do celów służbowych, jak i osobistych, mogą chcieć oddzielić swoje konta użytkowników. Jeśli dzierżawcy mają ścisłe wymagania prawne lub geograficzne dotyczące przechowywania danych, mogą wymagać, aby osoba miała wiele tożsamości, aby mogły one być zgodne z przepisami lub regulacjami.

  • Unikaj wielokrotnego przechowywania poświadczeń, jeśli używasz tożsamości przypisanych do dzierżawy. Użytkownicy powinni mieć swoje poświadczenia przechowywane względem jednej tożsamości, a należy używać funkcji, takich jak tożsamości gości, aby odnosić się do tych samych poświadczeń użytkownika z wielu rekordów tożsamości najemców.

Udzielanie użytkownikom dostępu do danych dzierżawy

Zastanów się, jak planujesz przypisywać użytkowników do klienta. Na przykład podczas procesu tworzenia konta możesz podać unikatowy kod zaproszenia dla użytkowników, który użytkownicy mają wprowadzić podczas uzyskiwania dostępu do klienta po raz pierwszy. W niektórych rozwiązaniach nazwa domeny adresu e-mail rejestracyjnego użytkownika może zidentyfikować skojarzoną dzierżawę. Alternatywnie możesz użyć innego atrybutu z rekordu tożsamości użytkownika, aby określić mapowanie tenant. To skojarzenie powinno być następnie przechowywane na podstawie niezmiennych, unikatowych identyfikatorów zarówno dla najemcy, jak i użytkownika.

Jeśli rozwiązanie ogranicza każdemu użytkownikowi dostęp do danych dla jednej dzierżawy, należy wziąć pod uwagę następujące decyzje:

  • Ustal, jak dostawca tożsamości wykrywa, do której dzierżawy uzyskuje dostęp użytkownik.

  • Wyjaśnij, w jaki sposób dostawca tożsamości komunikuje identyfikator najemcy do aplikacji. Zazwyczaj do tokenu jest dodawana klauzula identyfikatora dzierżawy.

Jeśli jeden użytkownik musi mieć dostęp do wielu dzierżaw, należy wziąć pod uwagę następujące decyzje:

  • Rozwiązanie musi obsługiwać logikę identyfikowania użytkowników i udzielania odpowiednich uprawnień w ramach dzierżaw. Na przykład użytkownik może mieć uprawnienia administracyjne w jednej dzierżawie, ale ograniczony dostęp w innej dzierżawie. Załóżmy na przykład, że użytkownik zarejestrował się przy użyciu tożsamości w mediach społecznościowych, a następnie uzyskał dostęp do dwóch dzierżaw. Najemca A wzbogacił tożsamość użytkownika o więcej informacji. Czy najemca B powinien mieć dostęp do wzbogaconych informacji?

  • Przejrzysty mechanizm powinien umożliwiać użytkownikom przełączanie się między dzierżawami. Takie podejście zapewnia płynne doświadczenie użytkownika i zapobiega przypadkowemu dostępowi między najemcami.

  • Tożsamości robocze, jeśli ich używasz, muszą określić, którego dzierżawcy próbują uzyskać dostęp. To wymaganie może obejmować osadzanie kontekstu specyficznego dla dzierżawy w żądaniach uwierzytelniania.

  • Zastanów się, czy informacje charakterystyczne dla najemcy, przechowywane w rekordzie tożsamości użytkownika, mogą przypadkowo wyciekać między różnymi najemcami. Jeśli na przykład użytkownik zarejestruje się przy użyciu tożsamości społecznej i uzyska dostęp do dwóch tenantów, a Tenant A wzbogaca profil użytkownika, określ, czy Tenant B powinien mieć dostęp do tych wzbogaconych informacji.

Proces rejestracji użytkownika dla tożsamości lokalnych lub tożsamości społecznościowych

Niektórzy najemcy mogą potrzebować zezwolić użytkownikom na samodzielne zakładanie tożsamości w rozwiązaniu. Rejestracja samoobsługowa może być wymagana, jeśli nie potrzebujesz federacji z IdP dzierżawcy. Jeśli potrzebny jest proces samodzielnej rejestracji, należy wziąć pod uwagę następujące czynniki:

  • Określ, z których źródeł tożsamości użytkownicy mogą się zarejestrować. Na przykład określ, czy użytkownicy mogą utworzyć tożsamość lokalną, a także skorzystać z dostawcy tożsamości społecznościowej.

  • Określ, czy rozwiązanie zezwala tylko na określone domeny poczty e-mail, jeśli są używane tożsamości lokalne. Na przykład określ, czy tenant (dzierżawca) może ograniczyć rejestrację do użytkowników z @contoso.com adresem e-mail.

  • Główna nazwa użytkownika (UPN) używana do identyfikowania tożsamości lokalnych musi być wyraźnie ustalona. Typowe nazwy UPN obejmują adresy e-mail, nazwy użytkowników, numery telefonów lub identyfikatory członkostwa. Ponieważ nazwy UPN mogą ulec zmianie, zaleca się odwołanie do bazowego niezmiennego unikatowego identyfikatora autoryzacji i audytu. Przykładem jest identyfikator obiektu (OID) w identyfikatorze Entra firmy Microsoft.

  • Weryfikacja identyfikatorów UPN może być wymagana w celu zapewnienia ich dokładności. Ten proces może obejmować weryfikowanie własności adresu e-mail lub numeru telefonu przed udzieleniem dostępu.

  • Niektóre rozwiązania mogą wymagać od administratorów dzierżawy zatwierdzenia rejestracji użytkowników. Ten proces zatwierdzania umożliwia kontrolę administracyjną nad tym, kto dołącza do dzierżawy.

  • Zdecyduj, czy najemcy wymagają indywidualnego doświadczenia rejestracyjnego lub unikalnego adresu URL. Na przykład określ, czy najemcy potrzebują spersonalizowanego procesu rejestracji podczas zapisywania użytkowników lub możliwość przechwytywania żądania rejestracji i przeprowadzania dodatkowej weryfikacji przed kontynuowaniem.

Dostęp do dzierżawy dla użytkowników z rejestracją własną

Jeśli użytkownicy mogą sami zarejestrować się, aby uzyskać tożsamość, zdefiniuj proces przyznawania im dostępu do środowiska tenant. Przepływ rejestracji może obejmować proces udzielania dostępu ręcznego lub zautomatyzowany proces na podstawie informacji o użytkownikach, takich jak ich adresy e-mail. Ważne jest, aby zaplanować ten proces i wziąć pod uwagę następujące czynniki:

  • Zdefiniuj, jak przepływ rejestracji określa, że użytkownik ma dostęp do określonego tenanta.

  • Określ, czy rozwiązanie automatycznie odwołuje dostęp użytkownika do dzierżawy, jeśli jest to konieczne. Na przykład gdy użytkownicy opuszczają organizację, powinien istnieć proces ręczny lub zautomatyzowany w celu usunięcia dostępu.

  • Zapewnij możliwość inspekcji użytkowników, aby dzierżawcy mogli sprawdzić, którzy użytkownicy mają dostęp do swojego środowiska i zrozumieć przypisane uprawnienia.

Zautomatyzowane zarządzanie cyklem życia konta

Typowym wymaganiem dla klientów firmowych lub korporacyjnych rozwiązania jest zestaw funkcji, które umożliwiają im automatyzowanie dołączania i odłączania kont. Otwarte protokoły, takie jak System for Cross-Domain Identity Management (SCIM), zapewniają standardowe podejście do automatyzacji. Ten zautomatyzowany proces zwykle obejmuje tworzenie i usuwanie rekordów tożsamości oraz zarządzanie uprawnieniami dzierżawy. Podczas implementowania zautomatyzowanego zarządzania cyklem życia konta w rozwiązaniu wielodostępnym należy wziąć pod uwagę następujące czynniki:

  • Ustal, czy klienci muszą skonfigurować zautomatyzowany proces cyklu życia dla każdej dzierżawy i zarządzać nim. Na przykład, kiedy użytkownik zostanie wdrożony, może być konieczne utworzenie jego tożsamości wewnątrz wielu dzierżaw w aplikacji, gdzie każda z tych dzierżaw ma inny zestaw uprawnień.

  • Ustal, czy musisz zaimplementować SCIM, czy zaoferować federację. Federacja pozwala dzierżawcom zachować kontrolę nad zarządzaniem użytkownikami, zachowując źródło prawdy we własnych systemach zamiast zarządzać użytkownikami lokalnymi w rozwiązaniu.

Proces uwierzytelniania użytkownika

Gdy użytkownik loguje się do aplikacji wielodostępnej, system tożsamości uwierzytelnia użytkownika. Podczas planowania procesu uwierzytelniania należy wziąć pod uwagę następujące czynniki:

  • Niektórzy najemcy mogą potrzebować możliwości skonfigurowania własnych zasad uwierzytelniania wieloskładnikowego. Jeśli na przykład dzierżawcy znajdują się w branży usług finansowych, muszą wdrożyć ścisłe zasady uwierzytelniania wieloskładnikowego, podczas gdy mały sprzedawca internetowy może nie mieć tych samych wymagań.

  • Opcja definiowania niestandardowych reguł dostępu warunkowego może być ważna dla dzierżawców. Na przykład różni najemcy mogą potrzebować zablokować próby logowania z określonych regionów geograficznych.

  • Ustal, czy dzierżawcy muszą indywidualnie dostosować proces logowania. Na przykład rozwiązanie może wymagać wyświetlenia logo klienta. Może być również konieczne pobranie informacji o użytkowniku, takich jak numer programu lojalnościowego, z innego systemu i zwrócenie go do dostawcy tożsamości w celu wzbogacenia profilu użytkownika.

  • Niektórzy użytkownicy mogą potrzebować wcielać się w innych użytkowników. Na przykład członek zespołu pomocy technicznej może chcieć zbadać problem, który ma inny użytkownik, personifikując swoje konto użytkownika bez konieczności uwierzytelniania jako użytkownik.

  • Dostęp do interfejsu API może być wymagany dla niektórych użytkowników lub aplikacji zewnętrznych. Te scenariusze mogą obejmować bezpośrednie wywoływanie interfejsów API systemu, omijając standardowe procedury uwierzytelniania użytkowników.

Tożsamości obciążeń

W większości rozwiązań tożsamość często reprezentuje użytkownika. Niektóre systemy wielodostępne umożliwiają również używanie tożsamości roboczych przez usługi i aplikacje w celu uzyskania dostępu do zasobów Twojej aplikacji. Na przykład dzierżawcy mogą potrzebować dostępu do interfejsu API udostępnianego przez rozwiązanie, aby umożliwić im zautomatyzowanie zadań zarządzania.

Microsoft Entra obsługuje tożsamości dla obciążeń, a inni dostawcy tożsamości także często je obsługują.

Tożsamości obciążeń są podobne do tożsamości użytkowników, ale zwykle wymagają różnych metod uwierzytelniania, takich jak klucze lub certyfikaty. Tożsamości obciążeń nie potrzebują używać uwierzytelniania wieloskładnikowego. Zamiast tego, tożsamości robocze zwykle wymagają innych zabezpieczeń, takich jak regularna rotacja kluczy i wygasanie certyfikatów.

Jeśli dzierżawcy mogą włączyć dostęp tożsamości obciążenia do rozwiązania wielodostępnego, należy wziąć pod uwagę następujące czynniki:

  • Określ sposób tworzenia tożsamości obciążeń i zarządzania nimi w każdej dzierżawie.

  • Zdecyduj, w jaki sposób żądania dotyczące tożsamości są przypisane do dzierżawy.

  • Oceń, czy musisz ograniczyć liczbę tożsamości obciążeń roboczych tworzonych przez każdego dzierżawcę.

  • Ustalenie, czy dla tożsamości roboczych w każdej dzierżawie są wymagane mechanizmy kontroli dostępu warunkowego. Na przykład najemca może chcieć ograniczyć tożsamość obciążenia roboczego, aby nie była uwierzytelniana spoza określonego regionu geograficznego.

  • Zidentyfikuj mechanizmy kontroli zabezpieczeń, które udostępniasz najemcom, aby zapewnić bezpieczeństwo tożsamości obiektów roboczych. Na przykład automatyczne zmienianie kluczy, wygaśnięcie klucza, wygaśnięcie certyfikatu i monitorowanie ryzyka przy logowaniu pomaga zmniejszyć ryzyko nieprawidłowego użycia tożsamości obciążeniowej.

Połącz się z dostawcą tożsamości (IdP) w celu jednokrotnego logowania (SSO)

Klienci, którzy mają już własne katalogi użytkowników, mogą chcieć, aby Twoje rozwiązanie zostało sfederowane z ich katalogami. Federacja umożliwia rozwiązaniu używanie tożsamości w katalogu zamiast zarządzania innym katalogiem z różnymi tożsamościami.

Federacja jest szczególnie ważna, gdy niektórzy dzierżawcy chcą określić własne zasady tożsamości lub umożliwić SSO.

Jeśli oczekujesz, że najemcy będą nawiązywać współpracę z Twoim rozwiązaniem, rozważ następujące czynniki:

  • Rozważ proces konfigurowania federacji dla dzierżawy. Ustal, czy dzierżawcy konfigurują federację samodzielnie, czy proces wymaga ręcznej konfiguracji i konserwacji przez zespół.

  • Zdefiniuj protokoły federacyjne obsługiwane przez rozwiązanie.

  • Ustanów procesy, które zapobiegają błędom konfiguracji federacyjnych przed przyznawaniem dostępu do nieautoryzowanych dzierżaw.

  • Zaplanuj, czy dostawca tożsamości dla pojedynczego dzierżawcy musi zostać sfederowany do więcej niż jednego dzierżawcy w Twoim rozwiązaniu. Jeśli na przykład klienci mają zarówno środowisko szkoleniowe, jak i produkcyjne, może być konieczne użycie tego samego dostawcy tożsamości dla każdego tenanta.

Modele autoryzacji

Zdecyduj się na model autoryzacji, który ma największe znaczenie dla twojego rozwiązania. Rozważ następujące typowe podejścia do autoryzacji:

  • Autoryzacja oparta na rolach: Użytkownicy są przypisywani do ról. Niektóre funkcje aplikacji są ograniczone do określonych ról. Na przykład użytkownik w roli administratora może wykonać dowolną akcję, podczas gdy użytkownik w niższej roli może mieć podzbiór uprawnień w całym systemie.

  • Autoryzacja oparta na zasobach: Rozwiązanie udostępnia zestaw odrębnych zasobów, z których każdy ma własny zestaw uprawnień. Określony użytkownik może być administratorem jednego zasobu i nie ma dostępu do innego zasobu.

Te modele są odrębne, a wybrane podejście wpływa na implementację i złożoność zasad autoryzacji, które można zaimplementować.

Uprawnienia i licencjonowanie

W niektórych rozwiązaniach możesz użyć licencjonowania poszczególnych użytkowników w ramach modelu cen komercyjnych. W tym scenariuszu udostępniasz różne warstwy licencji użytkowników, które mają różne możliwości. Na przykład użytkownicy z jedną licencją mogą korzystać z podzestawu funkcji aplikacji. Możliwości, do których mogą uzyskiwać dostęp konkretni użytkownicy, na podstawie licencji, są czasami nazywane uprawnieniem.

Kod aplikacji lub dedykowany system uprawnień zwykle śledzi i wymusza uprawnienia zamiast systemu tożsamości. Ten proces jest podobny do autoryzacji, ale występuje poza warstwą zarządzania tożsamościami.

Rozszerzenie zakresu tożsamości i natężenie uwierzytelniania

W miarę jak rozwiązania wielodostępne stają się coraz bardziej rozbudowane, rośnie liczba użytkowników i żądań logowania, które to rozwiązania muszą przetwarzać. Rozważmy następujący czynniki:

  • Oceń, czy katalog użytkowników jest skalowany w celu obsługi wymaganej liczby użytkowników.

  • Oceń, czy proces uwierzytelniania obsługuje oczekiwaną liczbę logów i rejestracji.

  • Ustal, czy występują skoki, których system uwierzytelniania nie może obsłużyć. Na przykład o 9:00 czasu pacyficznego wszyscy w zachodnich Stanach Zjednoczonych mogą rozpocząć pracę i zalogować się do rozwiązania, co powoduje wzrost liczby żądań logowania. Te scenariusze są czasami nazywane burzami logowania.

  • Ustal, czy duże obciążenie w częściach rozwiązania wpływa na wydajność procesu uwierzytelniania. Jeśli na przykład uwierzytelnianie wymaga wywołania interfejsu API warstwy aplikacji, wzrost liczby żądań uwierzytelniania może mieć wpływ na ogólną wydajność systemu.

  • Zdefiniuj sposób działania rozwiązania, jeśli IdP będzie niedostępny. Zastanów się, czy należy uwzględnić usługę uwierzytelniania kopii zapasowych w celu zachowania ciągłości działania.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główni autorzy:

Inni współautorzy:

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.