Udostępnij za pośrednictwem

Wybieranie rozwiązania do zarządzania tożsamościami

  • Artykuł

Większość aplikacji internetowych obsługuje uwierzytelnianie, aby upewnić się, że użytkownicy są tym, którzy twierdzą, że są. Użytkownik może być osobą lub inną aplikacją. Zarządzanie dostępem gwarantuje, że użytkownicy będą mogli wyświetlać i modyfikować tylko informacje, które mają uprawnienia do przeglądania i modyfikowania. Na przykład użytkownik końcowy nie powinien mieć dostępu do sekcji administracyjnej witryny internetowej. Identity Rozwiązania do zarządzania są tworzone w celu obsługi wymagań dotyczących zadań związanych z uwierzytelnianiem i autoryzacją. Aby dowiedzieć się więcej na temat zarządzania tożsamościami, zobacz Co to jest zarządzanie tożsamościami i dostępem? Dostępnych jest wiele rozwiązań do zarządzania tożsamościami dla aplikacji internetowych platformy .NET, z których każda ma różne możliwości i wymagania dotyczące używania lub instalowania. Ten artykuł zawiera wskazówki dotyczące wybierania odpowiedniego rozwiązania.

Podstawowe zarządzanie tożsamościami za pomocą platformy ASP.NET Core Identity

ASP.NET Core jest dostarczany z wbudowanym dostawcą uwierzytelniania: ASP.NET Core Identity. Dostawca obejmuje interfejsy API, interfejs użytkownika i konfigurację bazy danych zaplecza w celu obsługi zarządzania tożsamościami użytkowników, przechowywania poświadczeń użytkownika oraz udzielania lub odwołowywania uprawnień. Inne obsługiwane przez niego funkcje to:

W większości scenariuszy może to być jedyny wymagany dostawca.

Dodatkowe informacje:

W innych scenariuszach korzystne może być serwer lub usługa, która zarządza uwierzytelnianiem i tożsamością.

Określanie, czy wymagany jest serwer OIDC

Aplikacje internetowe wymagają sposobu zapamiętania poprzednich akcji, ponieważ sieć Web domyślnie jest bezstanowa. W przeciwnym razie użytkownicy będą musieli wprowadzać swoje poświadczenia za każdym razem, gdy przechodzą do nowej strony. Typowym rozwiązaniem do zapamiętania stanu jest cookiemechanizm oparty na przeglądarce do przechowywania danych. Serwer internetowy wysyła początkowe polecenie cookie, a następnie przeglądarka je przechowuje i wysyła z powrotem z każdym żądaniem. Odbywa się to automatycznie bez konieczności pisania kodu przez dewelopera. Cookies są łatwe w użyciu i wbudowane w przeglądarkę, ale są przeznaczone do użytku w jednej witrynie internetowej lub domenie internetowej. Domyślne rozwiązanie wbudowane w ASP.NET Core używa cookieuwierzytelniania opartego na protokole .

Tokeny to kontenery z metadanymi, które są jawnie przekazywane przez nagłówki lub treść żądań HTTP. Główną zaletą tokenów za pośrednictwem cookieprotokołu s jest to, że nie są one powiązane z określoną aplikacją lub domeną. Zamiast tego tokeny są zwykle podpisane przy użyciu kryptografii asymetrycznej. Na przykład serwery OIDC wystawiają tokeny z informacjami o tożsamości przy użyciu JSformatu ON Web Token (JWT), który obejmuje podpisywanie. Kryptografia asymetryczna używa kombinacji klucza prywatnego znanego tylko użytkownikowi podpisowi oraz klucza publicznego, który każdy może wiedzieć. Tokeny mogą być również szyfrowane.

Nie można manipulować podpisanym tokenem z powodu klucza prywatnego. Klucz publiczny:

  • Umożliwia zweryfikowanie tokenu w celu upewnienia się, że nie został on zmieniony.
  • Gwarantuje, że został wygenerowany przez jednostkę przechowującą klucz prywatny.

Główną wadą korzystania z tokenów jest to, że wymagają one usługi (zazwyczaj serwera OIDC) do problemu i zapewnienia weryfikacji tokenów. Usługa musi być zainstalowana, skonfigurowana i utrzymywana.

Typowym powodem, dla którego wymagany jest serwer OIDC, jest aplikacja, która uwidacznia internetowe interfejsy API używane przez inne aplikacje. W przypadku uwidocznionych internetowych interfejsów API interfejsy użytkownika klienta, takie jak aplikacje jednostronicowe (SPA), klienci mobilni i klienci klasyczni, są uważane za część tej samej aplikacji. Przykłady SPA obejmują Angular, React i Blazor WebAssembly. Jeśli aplikacje inne niż aplikacja internetowa lub interfejsy użytkownika klienta muszą wykonać bezpieczne wywołanie interfejsu API do aplikacji, prawdopodobnie zechcesz używać tokenów. Jeśli masz tylko interfejsy użytkownika klienta, ASP.NET Core Identity udostępnia opcję uzyskania tokenu podczas uwierzytelniania. Token uwierzytelniania wystawiony przez ASP.NET Core Identity:

  • Może być używany przez klientów mobilnych i stacjonarnych. CookieS są preferowane w przypadku tokenów zarówno dla bezpieczeństwa, jak i prostoty.
  • Nie nadaje się do zarządzania dostępem z aplikacji innych firm.

Innym powodem, dla którego wymagany jest serwer OIDC, jest udostępnianie logów innym aplikacjom. Ta funkcja umożliwia użytkownikom często logowanie jednokrotne:

  • Zaloguj się raz przy użyciu formularza aplikacji internetowej.
  • Użyj wynikowych poświadczeń, aby uwierzytelnić się w innych aplikacjach bez konieczności ponownego logowania lub wybierania innego hasła.

Serwer OIDC jest zwykle preferowany do zapewnienia bezpiecznego i skalowalnego rozwiązania do logowania jednokrotnego.

W przypadku aplikacji, które nie udostępniają identyfikatorów logowania innym aplikacjom, najprostszym sposobem szybkiego zabezpieczenia aplikacji jest użycie wbudowanego dostawcy ASP.NET Core Identity . W przeciwnym razie wymagany jest serwer OIDC udostępniany przez rozwiązanie do zarządzania tożsamościami innej firmy. Serwery OIDC są dostępne jako:

  • Produkty instalowane na serwerze o nazwie self-host.
  • Kontenery są uruchamiane na hoście, na przykład docker.
  • Usługi internetowe zintegrowane z usługami do zarządzania tożsamościami.

Niektóre rozwiązania są bezpłatne i open source, podczas gdy inne są licencjonowane komercyjnie. Zobacz Rozwiązania do zarządzania tożsamościami, aby zapoznać się z listą dostępnych opcji. Istnieje możliwość, że organizacja korzysta już z dostawcy tożsamości. W takim przypadku warto użyć istniejącego dostawcy zamiast korzystać z innego rozwiązania. Wszystkie główne rozwiązania zawierają dokumentację dotyczącą konfigurowania platformy ASP.NET Core do korzystania z ich produktu lub usługi.

Scenariusze z brakiem łączności

Wiele rozwiązań, takich jak Microsoft Entra ID, jest opartych na chmurze i wymaga połączenia internetowego z pracą. Jeśli środowisko nie zezwala na łączność z Internetem, nie będzie można korzystać z usługi.

ASP.NET Core Identity doskonale sprawdza się w scenariuszach bez połączenia, takich jak:

  • Aplikacja nie może uzyskać dostępu do Internetu.
  • Aplikacja musi nadal działać w sieci lokalnej, nawet jeśli Internet zostanie rozłączony.

Jeśli potrzebujesz pełnego serwera OIDC dla scenariusza bez połączenia, wybierz jedną z następujących opcji:

  • Rozwiązanie, które umożliwia instalowanie i uruchamianie usługi na własnych maszynach.
  • Uruchom usługę uwierzytelniania lokalnie jako kontener.

Decydowanie, gdzie są przechowywane dane użytkownika, takie jak logowania

Innym ważnym czynnikiem do rozważenia jest miejsce przechowywania danych logowania użytkownika. Wielu deweloperów wybiera zewnętrzne usługi oparte na chmurze, takie jak Microsoft Entra ID, aby zarządzać tożsamością. Dostawca usług oparty na chmurze:

  • Przejmuje obowiązki bezpiecznego przechowywania danych.
  • oprogramowanie jest aktualne wraz z najnowszymi poprawkami i wydaniami zabezpieczeń.
  • Przestrzega przepisów dotyczących prywatności.

Inni wolą przechowywać dane na własnych serwerach ze względu na przepisy, zgodność, zasady lub inne powody.

Jeśli dane są przechowywane na serwerach, najprawdopodobniej musisz wybrać rozwiązanie instalowane lub oparte na kontenerach.

Identity vs serwer OIDC

Skorzystaj z poniższego diagramu, aby określić, czy używać systemu ASP.NET Core Identity , czy serwera OIDC do uwierzytelniania i autoryzacji:

Identity management decision flow

W poniższej tabeli wymieniono niektóre kwestie, które należy wziąć pod uwagę podczas wybierania rozwiązania do zarządzania tożsamościami.

Funkcja Host własny (infrastruktura lub kontener) W chmurze
Integracja aplikacji Lokalne rozwiązania, które są implementowane jako biblioteki lub struktury, często można zintegrować bezpośrednio z własną aplikacją. Rozwiązania oparte na kontenerach wymagają przekazania między aplikacją internetową a usługą opartą na kontenerze. Rozwiązania oparte na chmurze zwykle integrują się w określonych punktach w przepływie logowania i zapewniają konfigurację aktualizacji interfejsu użytkownika w celu dopasowania do motywu, ale dostępny poziom dostosowywania jest ograniczony.
Konfiguracja Rozwiązania do samodzielnego hostowania wymagają skonfigurowania oprogramowania dla środowiska oprócz konfigurowania sposobu zarządzania tożsamościami. Rozwiązania oparte na kontenerach zwykle udostępniają internetowy interfejs użytkownika na potrzeby konfiguracji. Rozwiązania oparte na chmurze zwykle udostępniają internetowy interfejs użytkownika na potrzeby konfiguracji.
Dostosowywanie Rozwiązania do samodzielnego hostowania są zwykle wysoce dostosowywalne, w tym zmiany oparte na kodzie. Mimo że rozwiązania konteneryzowane zapewniają opcje rozszerzalności, są one często bardziej ograniczone. Usługi oparte na chmurze umożliwiają dostosowywanie, ale zwykle są ograniczone do zmian opartych na konfiguracji.
Konserwacja Zainstalowane produkty wymagają dedykowanego zasobu, aby zapewnić, że wszystkie poprawki zabezpieczeń są stosowane w odpowiednim czasie i do zarządzania uaktualnieniami. Proces uaktualniania i stosowania poprawek dla kontenerów jest zwykle niższy i polega po prostu na zainstalowaniu dostarczonego obrazu kontenera. Dostawca usług utrzymuje swoje rozwiązanie oparte na chmurze, w tym stosowanie wymaganych poprawek i obsługę uaktualnień.
Magazyn poświadczeń użytkownika Ponosisz odpowiedzialność za nadzór nad danymi i obsługę naruszeń. Zarządzanie ryzykiem związanym z obsługą poświadczeń użytkownika i przestrzeganie przepisów. jest delegowany do dostawcy usług.

Aby uzyskać więcej informacji na temat dostępnych opcji, zobacz Identity Rozwiązania do zarządzania dla platformy ASP.NET Core.

Następne kroki