Udostępnij za pośrednictwem

Zagadnienia dotyczące architektury dotyczące tożsamości w rozwiązaniu wielodostępnym

  • Artykuł

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

  • Sprawdzanie, kto jest użytkownikiem (uwierzytelnianie).
  • Wymuszanie uprawnień użytkownika w zakresie dzierżawy (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 uzyska dostęp. Ważne jest, aby wziąć pod uwagę wymagania dotyczące tożsamości, aby odizolować aplikację i dane między dzierżawami.

Uwaga

Usługi uwierzytelniania i autoryzacji, w aplikacjach wielodostępnych i SaaS, są zwykle udostępniane przez dostawcę tożsamości innej firmy. Dostawca tożsamości jest zwykle integralną częścią platformy tożsamości jako usługi (IDaaS).

Tworzenie własnego dostawcy tożsamości jest złożone, kosztowne i trudne do bezpiecznego tworzenia. Tworzenie własnego dostawcy tożsamości jest antywzorzec. Nie zalecamy tego.

Przed zdefiniowaniem wielodostępnej strategii tożsamości należy najpierw wziąć pod uwagę wymagania dotyczące tożsamości wysokiego poziomu usługi, w tym następujące wymagania:

  • Czy tożsamości użytkowników lub obciążeń będą używane do uzyskiwania dostępu do jednej aplikacji lub wielu aplikacji w ramach rodziny produktów? Na przykład rodzina produktów detalicznych może mieć zarówno aplikację do obsługi punktów sprzedaży, jak i aplikację do zarządzania zapasami, która współużytkuje to samo rozwiązanie tożsamości.
  • Czy planujesz zaimplementowanie nowoczesnego uwierzytelniania i autoryzacji, takich jak OAuth2 i OpenID Connect?
  • Czy twoje rozwiązanie zapewnia tylko uwierzytelnianie w aplikacjach opartych na interfejsie użytkownika? Czy też zapewniasz dostęp do interfejsu API dzierżawcom i firmom trzecim?
  • Czy dzierżawcy będą musieli sfederować się z własnym dostawcą tożsamości i czy dla każdej dzierżawy musi być obsługiwanych wielu różnych dostawców tożsamości? Na przykład możesz mieć dzierżawy z identyfikatorem Entra firmy Microsoft, Auth0 i usługami Active Directory Federation Services (ADFS), w których każda z nich chce federować z rozwiązaniem. Musisz również zrozumieć, które protokoły federacyjne dostawców tożsamości dzierżawy będą obsługiwane, ponieważ protokoły wpływają na wymagania dotyczące własnego dostawcy tożsamości.
  • Czy istnieją określone wymagania dotyczące zgodności, które muszą spełnić, takie jak RODO?
  • Czy dzierżawcy wymagają, aby informacje o tożsamości znajdowały się w określonym regionie geograficznym?
  • Czy użytkownicy rozwiązania wymagają dostępu do danych z jednej dzierżawy lub z wielu dzierżaw w aplikacji? Czy potrzebują oni możliwości szybkiego przełączania się między dzierżawami lub wyświetlania skonsolidowanych informacji z wielu dzierżaw? Na przykład użytkownicy, którzy zalogowali się do witryny 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.

Po ustanowieniu wymagań wysokiego poziomu możesz rozpocząć planowanie bardziej szczegółowych szczegółów i wymagań, takich jak źródła katalogów użytkowników i przepływy rejestracji/logowania.

Katalog 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 lub może zawierać odwołania do tożsamości zewnętrznych przechowywanych w katalogu innego dostawcy tożsamości.

Podczas projektowania systemu tożsamości dla rozwiązania wielodostępnego należy rozważyć, które z następujących typów dostawcy 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. Dostawca tożsamości 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 innego dostawcy tożsamości publicznej, takiego jak Facebook, Google lub osobiste konto Microsoft.
  • Użyj katalogu Microsoft Entra ID dzierżawy. Dzierżawy mogą już mieć własny katalog Microsoft Entra ID i mogą chcieć, aby twoje rozwiązanie używało ich katalogu jako dostawcy tożsamości 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 dzierżawy. Dzierżawy mogą mieć własną dostawcę tożsamości, inną niż Microsoft Entra ID, i mogą chcieć, aby Twoje rozwiązanie było z nim sfederować. Federacja umożliwia logowanie jednokrotne i umożliwia dzierżawcom zarządzanie cyklem życia i zasadami zabezpieczeń użytkowników niezależnie od rozwiązania.

Należy rozważyć, czy dzierżawcy muszą obsługiwać wielu dostawców tożsamości. Na przykład może być konieczne obsługa tożsamości lokalnych, tożsamości społecznościowych i tożsamości federacyjnych w ramach jednej dzierżawy. To wymaganie jest powszechne, gdy firmy korzystają z rozwiązania zarówno dla własnych pracowników, jak i dla wykonawców. Mogą korzystać z federacji na potrzeby dostępu własnych pracowników do rozwiązania, a jednocześnie zezwalać na dostęp do wykonawców lub użytkowników-gości, którzy nie mają konta w federacyjnym 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ług, w tym ich nazwy i inne informacje wymagane przez dzierżawy.
  • Informacje wymagane do bezpiecznego uwierzytelniania użytkowników, w tym informacje wymagane do zapewnienia uwierzytelniania wieloskładnikowego (MFA).
  • Informacje specyficzne dla dzierżawy, takie jak role dzierżawy i uprawnienia. Te informacje są używane do autoryzacji.

Uwaga

Nie zalecamy samodzielnego kompilowania procesów uwierzytelniania. Nowoczesne dostawcy tożsamości udostępniają te usługi uwierzytelniania aplikacji, a także obejmują inne ważne funkcje, takie jak uwierzytelnianie wieloskładnikowe i dostęp warunkowy. Tworzenie własnego dostawcy tożsamości jest antywzorzec. 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 dostawcy tożsamości i udostępniaj je między wieloma dzierżawami.
  • Zapisz poświadczenia użytkownika w katalogu dostawcy tożsamości i zapisz informacje o autoryzacji w warstwie aplikacji wraz z informacjami o dzierżawie.

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

W przypadku rozwiązań wielodostępnych często można zezwolić użytkownikowi lub tożsamości obciążenia na dostęp do aplikacji i danych wielu dzierżaw. Zastanów się, czy to podejście jest wymagane dla Twojego rozwiązania. Jeśli tak jest, należy wziąć pod uwagę następujące pytania:

  • Czy należy utworzyć jedną tożsamość użytkownika dla każdej osoby lub utworzyć oddzielne tożsamości dla każdej kombinacji użytkownika dzierżawy?
    • Najlepiej używać pojedynczej tożsamości dla każdej osoby, wszędzie tam, gdzie to możliwe. Zarządzanie wieloma kontami użytkowników, zarówno dla Ciebie, jako dostawcy rozwiązań, jak i dla użytkowników, staje się trudne. Ponadto wiele inteligentnych ochrony przed zagrożeniami oferowanych przez nowoczesnego dostawcę tożsamości polega na każdej osobie mającej jedno konto użytkownika.
    • Jednak w niektórych sytuacjach może być konieczne, aby użytkownik miał wiele różnych 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. Ewentualnie, jeśli dzierżawcy mają ścisłe wymagania prawne lub dotyczące magazynu danych geograficznych, mogą wymagać od osoby posiadania wielu tożsamości, aby mogły one być zgodne z przepisami lub przepisami.
  • Jeśli używasz tożsamości dla dzierżawy, unikaj wielokrotnego przechowywania poświadczeń. Użytkownicy powinni mieć swoje poświadczenia przechowywane względem jednej tożsamości i należy użyć funkcji, takich jak tożsamości gościa, aby odwoływać się do tych samych poświadczeń użytkownika z wielu rekordów tożsamości dzierżawy.

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

Rozważ sposób mapowania użytkowników na dzierżawę. Na przykład podczas procesu rejestracji można użyć unikatowego kodu zaproszenia, który wprowadza po raz pierwszy, gdy uzyskuje dostęp do dzierżawy. W niektórych rozwiązaniach możesz użyć nazwy domeny adresów e-mail rejestracji użytkowników jako sposobu identyfikowania dzierżawy, do której należą. Możesz też użyć innego atrybutu rekordu tożsamości użytkownika, aby zamapować użytkownika na dzierżawę. Następnie należy przechowywać mapowanie na podstawie niezmiennych unikatowych identyfikatorów zarówno dla dzierżawy, jak i użytkownika.

Jeśli rozwiązanie zostało zaprojektowane tak, aby jeden użytkownik uzyskiwał dostęp tylko do danych dla jednej dzierżawy, należy wziąć pod uwagę następujące decyzje:

  • W jaki sposób dostawca tożsamości wykrywa, do której dzierżawy uzyskuje dostęp użytkownik?
  • W jaki sposób dostawca tożsamości komunikuje identyfikator dzierżawy z aplikacją? Często do tokenu jest dodawane oświadczenie 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:

  • W jaki sposób rozwiązanie identyfikuje i udziela uprawnień użytkownikowi, który ma dostęp do wielu dzierżaw? Na przykład czy użytkownik może być administratorem w dzierżawie szkoleniowej i mieć dostęp tylko do odczytu do dzierżawy produkcyjnej? Możesz też mieć oddzielne dzierżawy dla różnych działów w organizacji, ale musisz zachować spójne tożsamości użytkowników we wszystkich dzierżawach?
  • Jak użytkownik przełącza się między dzierżawami?
  • Jeśli używasz tożsamości obciążeń, w jaki sposób tożsamość obciążenia określa dzierżawę, do której musi uzyskać dostęp?
  • Czy istnieją informacje specyficzne dla dzierżawy przechowywane w rekordzie tożsamości użytkownika, które mogą wyciekać informacje między dzierżawami? Załóżmy na przykład, że użytkownik zarejestrował się przy użyciu tożsamości społecznościowej, a następnie udzielił dostępu do dwóch dzierżaw. Dzierżawa A wzbogaciła tożsamość użytkownika o więcej informacji. Czy dzierżawa B powinna mieć dostęp do wzbogaconych informacji?

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

Niektóre dzierżawy mogą wymagać zezwolenia użytkownikom na zarejestrowanie się w celu uzyskania tożsamości w rozwiązaniu. Rejestracja samoobsługowa może być wymagana, jeśli nie potrzebujesz federacji z dostawcą tożsamości dzierżawy. Jeśli potrzebny jest proces samodzielnej rejestracji, należy wziąć pod uwagę następujące pytania:

  • Z których źródeł tożsamości użytkownicy mogą się zarejestrować? Na przykład czy użytkownik może utworzyć tożsamość lokalną, a także użyć dostawcy tożsamości społecznościowych?
  • Jeśli dozwolone są tylko tożsamości lokalne, będą dozwolone tylko określone domeny poczty e-mail? Na przykład czy dzierżawa może określić, że tylko użytkownicy, którzy mają @contoso.com adres e-mail, mogą się zarejestrować?
  • Jaka jest główna nazwa użytkownika (UPN), która powinna być używana do unikatowego identyfikowania każdej tożsamości lokalnej podczas procesu logowania? Na przykład adres e-mail, nazwa użytkownika, numer telefonu i numer karty nagrody są typowymi opcjami nazw UPN. Jednak nazwy UPN mogą się zmieniać w czasie. Jeśli odwołujesz się do tożsamości w regułach autoryzacji aplikacji lub dziennikach inspekcji, dobrym rozwiązaniem jest użycie bazowego niezmiennego unikatowego identyfikatora tożsamości. Identyfikator entra firmy Microsoft zawiera identyfikator obiektu (OID), który jest niezmiennym identyfikatorem.
  • Czy użytkownik będzie musiał zweryfikować swoją nazwę UPN? Jeśli na przykład adres e-mail lub numer telefonu użytkownika jest używany jako nazwa UPN, jak sprawdzić, czy informacje są dokładne?
  • Czy administratorzy dzierżawy muszą zatwierdzić rejestrację?
  • Czy dzierżawy wymagają środowiska rejestracji lub adresu URL specyficznego dla dzierżawy? Czy na przykład dzierżawy wymagają środowiska rejestracji markowej, gdy użytkownicy zarejestrują się? Czy dzierżawy wymagają możliwości przechwycenia żądania rejestracji i przeprowadzenia dodatkowej weryfikacji przed kontynuowaniem?

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

Gdy użytkownicy mogą zarejestrować się w celu uzyskania tożsamości, zwykle musi istnieć proces, aby udzielić im dostępu do dzierżawy. Przepływ rejestracji może obejmować proces udzielania dostępu lub może zostać zautomatyzowany 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 pytania:

  • W jaki sposób przepływ rejestracji określi, że użytkownik powinien mieć dostęp do określonej dzierżawy?
  • Jeśli użytkownicy nie powinni już mieć dostępu do dzierżawy, rozwiązanie automatycznie odwołuje dostęp? Na przykład gdy użytkownicy opuszczają organizację, musi istnieć proces ręczny lub zautomatyzowany, który usuwa dostęp z dzierżawy.
  • Czy należy zapewnić dzierżawcom możliwość inspekcji użytkowników, którzy mają dostęp do swoich dzierżaw i ich uprawnień?

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 dołączania kont. Otwarte protokoły, takie jak System for Cross-domain Identity Management (SCIM), zapewniają standardowe w branży podejście do automatyzacji. Ten zautomatyzowany proces zwykle obejmuje nie tylko tworzenie i usuwanie rekordów tożsamości, ale także 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 pytania:

  • Czy klienci muszą skonfigurować zautomatyzowany proces cyklu życia dla dzierżawy i zarządzać nim? Na przykład po dołączeniu użytkownika może być konieczne utworzenie tożsamości w wielu dzierżawach w aplikacji, gdzie każda dzierżawa ma inny zestaw uprawnień.
  • Czy musisz zaimplementować program SCIM lub zamiast tego zapewnić federację dzierżaw, aby zachować źródło prawdy dla użytkowników pod kontrolą dzierżawy, zamiast zarządzać użytkownikami lokalnymi?

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 pytania:

  • Czy dzierżawcy muszą skonfigurować własne zasady 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ń.
  • Czy dzierżawcy muszą skonfigurować własne reguły dostępu warunkowego? Na przykład różne dzierżawy mogą wymagać zablokowania prób logowania z określonych regionów geograficznych.
  • Czy dzierżawcy muszą dostosować proces logowania dla każdej dzierżawy? Czy na przykład musisz wyświetlić logo klienta? Czy też informacje o każdym użytkowniku muszą zostać wyodrębnione z innego systemu, takiego jak numer nagrody i zwrócone do dostawcy tożsamości, aby dodać go do profilu użytkownika?
  • Czy użytkownicy muszą personifikować 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.
  • Czy użytkownicy muszą uzyskać dostęp do interfejsów API dla twojego rozwiązania? Na przykład użytkownicy lub aplikacje innych firm mogą wymagać bezpośredniego wywołania interfejsów API w celu rozszerzenia rozwiązania bez interfejsu użytkownika w celu zapewnienia przepływu uwierzytelniania.

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 obciążeń przez usługi i aplikacje w celu uzyskania dostępu do zasobów aplikacji. Na przykład dzierżawcy mogą potrzebować dostępu do interfejsu API udostępnianego przez rozwiązanie, aby umożliwić im zautomatyzowanie niektórych zadań zarządzania.

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 używają uwierzytelniania wieloskładnikowego. Zamiast tego tożsamości obciążeń zwykle wymagają innych mechanizmów kontroli zabezpieczeń, takich jak zwykłe wycofywanie kluczy i wygaśnięcie certyfikatu.

Jeśli dzierżawcy oczekują włączenia dostępu tożsamości obciążenia do rozwiązania wielodostępnego, należy rozważyć następujące pytania:

  • W jaki sposób tożsamości obciążeń będą tworzone i zarządzane w każdej dzierżawie?
  • W jaki sposób żądania tożsamości obciążenia będą ograniczone do dzierżawy?
  • Czy musisz ograniczyć liczbę tożsamości obciążeń tworzonych przez każdą dzierżawę?
  • Czy musisz zapewnić kontrolę dostępu warunkowego w tożsamościach obciążeń dla każdej dzierżawy? Na przykład dzierżawa może chcieć ograniczyć tożsamość obciążenia z uwierzytelniania spoza określonego regionu.
  • Które mechanizmy kontroli zabezpieczeń udostępnią dzierżawcom, aby zapewnić bezpieczeństwo tożsamości obciążeń? Na przykład automatyczne stopniowe wprowadzanie kluczy, wygaśnięcie klucza, wygaśnięcie certyfikatu i monitorowanie ryzyka logowania to wszystkie metody ograniczania ryzyka, w których tożsamość obciążenia może być niewłaściwa.

Federate with an identity provider for single sign-on (SSO) (Federate with an identity provider for single sign-on (SSO) (Federate with an identity provider for single sign-on (SSO)

Dzierżawcy, którzy mają już własne katalogi użytkowników, mogą chcieć, aby twoje rozwiązanie sfederować do swoich katalogów. 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 włączyć środowiska logowania jednokrotnego.

Jeśli oczekujesz, że dzierżawy będą federować z rozwiązaniem, należy wziąć pod uwagę następujące pytania:

  • Jaki jest proces konfigurowania federacji dla dzierżawy? Czy dzierżawcy mogą skonfigurować federację samodzielnie lub czy proces wymaga ręcznej konfiguracji i konserwacji przez zespół?
  • Które protokoły federacyjne będą obsługiwane?
  • Jakie procesy są na miejscu w celu zapewnienia, że federacja nie może być nieprawidłowo skonfigurowana, aby udzielić dostępu do innej dzierżawy?
  • Czy dostawca tożsamości pojedynczej dzierżawy musi być federacyjny do więcej niż jednej dzierżawy w rozwiązaniu? Jeśli na przykład klienci mają zarówno dzierżawę szkoleniową, jak i produkcyjną, może być konieczne sfederowanie tego samego dostawcy tożsamości do obu dzierżaw.

Modele autoryzacji

Zdecyduj się na model autoryzacji, który ma największe znaczenie dla twojego rozwiązania. Istnieją dwa 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. Można udostępnić różne warstwy licencji użytkowników z różnymi możliwościami. 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.

Mimo że śledzenie i wymuszanie uprawnień jest podobne do autoryzacji, zwykle jest obsługiwane przez kod aplikacji lub przez dedykowany system uprawnień, a nie zarządzany przez system tożsamości.

Skalowanie tożsamości i wolumin uwierzytelniania

Wraz ze wzrostem liczby rozwiązań wielodostępnych liczba użytkowników i żądań logowania, które muszą zostać przetworzone przez rozwiązanie, zwiększy się. Należy wziąć pod uwagę następujące pytania:

  • Czy katalog użytkownika będzie skalowany do wymaganej liczby użytkowników?
  • Czy proces uwierzytelniania będzie obsługiwał oczekiwaną liczbę logów i rejestracji?
  • Czy wystąpią skoki, których system uwierzytelniania nie może obsłużyć? Na przykład o 9:00 PST wszyscy w regionie zachodnich Stany Zjednoczone mogą rozpocząć pracę i zalogować się do rozwiązania, co powoduje wzrost liczby żądań logowania. Sytuacje te są czasami nazywane burzami logowania.
  • Czy duże obciążenie w innych częściach rozwiązania może mieć wpływ na wydajność procesu uwierzytelniania? Jeśli na przykład proces uwierzytelniania wymaga wywołania interfejsu API warstwy aplikacji, duża liczba żądań uwierzytelniania spowoduje problemy z resztą rozwiązania?
  • Co się stanie, jeśli Dostawca tożsamości stanie się niedostępny? Czy istnieje usługa uwierzytelniania kopii zapasowej, która może przejąć w celu zapewnienia ciągłości działania, podczas gdy dostawca tożsamości jest niedostępny?

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Autorzy zabezpieczeń:

Inni współautorzy:

Następne kroki

Zapoznaj się z podejściami architektury do obsługi tożsamości w rozwiązaniach wielodostępnych.