Uwierzytelnianie i autoryzacja na platformie ASP.NET Core Blazor

W tym artykule opisano obsługę konfiguracji i zarządzania zabezpieczeniami w aplikacjach Blazor na platformie ASP.NET Core.

Blazor używa istniejących mechanizmów uwierzytelniania ASP.NET Core w celu ustanowienia użytkownika identity. Dokładny mechanizm zależy od sposobu, w jaki Blazor aplikacja jest hostowana, po stronie serwera lub po stronie klienta.

Scenariusze zabezpieczeń różnią się między kodem autoryzacji działającym po stronie serwera i po stronie klienta w Blazor aplikacjach. W przypadku kodu autoryzacji uruchamianego na serwerze kontrole autoryzacji są w stanie wymusić reguły dostępu dla obszarów aplikacji i składników. Ponieważ wykonywanie kodu po stronie klienta może zostać naruszone, kod autoryzacji wykonywany na kliencie nie może być zaufany w celu bezwzględnego wymuszania reguł dostępu ani kontrolowania wyświetlania zawartości po stronie klienta.

Jeśli wymuszanie reguły autoryzacji musi być gwarantowane, nie implementuj kontroli autoryzacji w kodzie po stronie klienta. Utwórz element Blazor Web App , który opiera się tylko na renderowaniu po stronie serwera (SSR) na potrzeby kontroli autoryzacji i wymuszania reguł.

Konwencje autoryzacji rozwiązania Razor Pages nie są stosowane do składników Razor obsługujących routing. Jeśli składnik bez routingu Razor jest osadzony na stronie Razor aplikacji Pages, konwencje autoryzacji strony pośrednio wpływają na Razor składnik wraz z rest zawartością strony.

Uwaga

Przykłady kodu w tym artykule przyjmują typy odwołań dopuszczających wartość null (NRTs) i statyczną analizę stanu null kompilatora platformy .NET, które są obsługiwane w programie ASP.NET Core na platformie .NET 6 lub nowszym. W przypadku określania wartości docelowej ASP.NET Core 5.0 lub starszej usuń oznaczenie typu null (?) z przykładów w tym artykule.

Bezpieczne utrzymywanie poufnych danych i poświadczeń

Nie przechowuj wpisów tajnych aplikacji, parametry połączenia, poświadczeń, haseł, osobistych numerów identyfikacyjnych (PIN), prywatnego kodu .NET/C# ani kluczy prywatnych/tokenów w kodzie po stronie klienta, który jest zawsze niepewny. Kod po stronie Blazor klienta powinien uzyskiwać dostęp do bezpiecznych usług i baz danych za pośrednictwem bezpiecznego internetowego interfejsu API, który kontrolujesz.

W środowiskach testowych/przejściowych i produkcyjnych kod po stronie Blazor serwera i internetowe interfejsy API powinny używać bezpiecznych przepływów uwierzytelniania, które unikają utrzymywania poświadczeń w kodzie projektu lub plikach konfiguracji. Poza lokalnymi testami programistycznymi zalecamy unikanie używania zmiennych środowiskowych do przechowywania poufnych danych, ponieważ zmienne środowiskowe nie są najbezpieczniejszym podejściem. W przypadku lokalnego testowania programistycznego narzędzie Secret Manager jest zalecane do zabezpieczania poufnych danych. Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Bezpieczne przepływy uwierzytelniania (dokumentacja ASP.NET Core)
• Tożsamości zarządzane dla usług platformy Microsoft Azure (ten artykuł)

W przypadku programowania i testowania lokalnego po stronie klienta i po stronie serwera użyj narzędzia Secret Manager, aby zabezpieczyć poufne poświadczenia.

Tożsamości zarządzane dla usług platformy Microsoft Azure

W przypadku usług platformy Microsoft Azure zalecamy używanie tożsamości zarządzanych. Tożsamości zarządzane bezpiecznie uwierzytelniają się w usługach platformy Azure bez przechowywania poświadczeń w kodzie aplikacji. Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Co to są tożsamości zarządzane dla zasobów platformy Azure? (Dokumentacja firmy Microsoft Entra)
• Dokumentacja usług platformy Azure
  • Tożsamości zarządzane w usłudze Microsoft Entra for Azure SQL
  • Jak używać tożsamości zarządzanych dla usług App Service i Azure Functions

Obsługa ochrony przed fałszerzami

Szablon Blazor :

• Dodaje usługi ochrony przed fałszerzami automatycznie, gdy AddRazorComponents jest wywoływana Program w pliku.
• Dodaje oprogramowanie pośredniczące chroniące przed fałszerzami przez wywołanie UseAntiforgery w potoku przetwarzania żądań w Program pliku i wymaga ochrony przed złośliwym kodem punktu końcowego w celu ograniczenia zagrożeń fałszerzowania żądań między witrynami (CSRF/XSRF). UseAntiforgery jest wywoływana po UseHttpsRedirection. Wywołanie UseAntiforgery musi zostać umieszczone po wywołaniach, jeśli istnieje, do UseAuthentication i UseAuthorization.

Składnik AntiforgeryToken renderuje token antyforgery jako ukryte pole, a ten składnik jest automatycznie dodawany do wystąpień formularza (EditForm). Aby uzyskać więcej informacji, zobacz omówienie formularzy ASP.NET CoreBlazor.

AntiforgeryStateProvider Usługa zapewnia dostęp do tokenu antyforgery skojarzonego z bieżącą sesją. Wstrzyknąć usługę i wywołać jej GetAntiforgeryToken() metodę w celu uzyskania bieżącego AntiforgeryRequestTokenelementu . Aby uzyskać więcej informacji, zobacz Wywoływanie internetowego interfejsu API z aplikacji ASP.NET CoreBlazor.

Blazor przechowuje tokeny żądań w stanie składnika, co gwarantuje, że tokeny antyforgeryjne są dostępne dla składników interaktywnych, nawet jeśli nie mają dostępu do żądania.

Uwaga

Środki zaradcze są wymagane tylko podczas przesyłania danych formularza do serwera zakodowanego jako application/x-www-form-urlencoded, multipart/form-datalub text/plain ponieważ są to jedyne prawidłowe typy formularzy.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Zapobieganie atakom fałszowania żądań między witrynami (XSRF/CSRF) w ASP.NET Core: ten artykuł jest podstawowym artykułem ASP.NET Core na ten temat, który dotyczy po stronie Blazor Serverserwera, projektu Blazor Web Appserwera s i Blazor integracji z MVC/Razor Pages.
• omówienie formularzy ASP.NET CoreBlazor: sekcja pomocy technicznej dotycząca ochrony przed fałszerzami artykułu dotyczy Blazor obsługi ochrony przed fałszerzami formularzy.

Uwierzytelnianie po stronie Blazor serwera

Aplikacje po stronie Blazor serwera są konfigurowane pod kątem zabezpieczeń w taki sam sposób jak aplikacje ASP.NET Core. Aby uzyskać więcej informacji, zobacz artykuły w tematach dotyczących zabezpieczeń platformy ASP.NET Core.

Kontekst uwierzytelniania jest ustanawiany tylko po uruchomieniu aplikacji, czyli wtedy, gdy aplikacja najpierw łączy się z protokołem WebSocket za pośrednictwem połączenia z klientemSignalR. Uwierzytelnianie może być oparte na tokenie elementu nośnego cookie lub innego elementu nośnego, ale uwierzytelnianie jest zarządzane za pośrednictwem SignalR centrum i w całości w obrębie obwodu. Kontekst uwierzytelniania jest utrzymywany przez cały okres istnienia obwodu. Aplikacje okresowo zmieniają stan uwierzytelniania użytkownika co 30 minut.

Jeśli aplikacja musi przechwytywać użytkowników dla usług niestandardowych lub reagować na aktualizacje użytkownika, zobacz ASP.NET Podstawowe scenariusze zabezpieczeń i Blazor Web App dodatkowe scenariusze zabezpieczeń.

Blazor różni się od tradycyjnych aplikacji internetowych renderowanych przez serwer, które tworzą nowe żądania HTTP z plikami cookie w każdej nawigacji na stronie. Uwierzytelnianie jest sprawdzane podczas zdarzeń nawigacji. Pliki cookie nie są jednak zaangażowane. Pliki cookie są wysyłane tylko podczas wysyłania żądania HTTP do serwera, co nie jest wykonywane po przejściu Blazor użytkownika w aplikacji. Podczas nawigacji stan uwierzytelniania użytkownika jest sprawdzany w obwodzie Blazor , który można aktualizować w dowolnym momencie na serwerze przy użyciu RevalidatingAuthenticationStateProvider abstrakcji.

Ważne

Implementowanie niestandardowego NavigationManager elementu w celu uzyskania weryfikacji uwierzytelniania podczas nawigacji nie jest zalecane. Jeśli aplikacja musi wykonywać niestandardową logikę stanu uwierzytelniania podczas nawigacji, użyj niestandardowego AuthenticationStateProviderelementu .

Uwaga

Przykłady kodu w tym artykule przyjmują typy odwołań dopuszczających wartość null (NRTs) i statyczną analizę stanu null kompilatora platformy .NET, które są obsługiwane w programie ASP.NET Core na platformie .NET 6 lub nowszym. W przypadku określania wartości docelowej ASP.NET Core 5.0 lub starszej usuń oznaczenie typu null (?) z przykładów w tym artykule.

Wbudowana lub niestandardowa AuthenticationStateProvider usługa uzyskuje dane stanu uwierzytelniania z ASP.NET Core HttpContext.User. W ten sposób stan uwierzytelnienia integruje się z istniejącymi mechanizmami uwierzytelnianie platformy ASP.NET Core.

Aby uzyskać więcej informacji na temat uwierzytelniania po stronie serwera, zobacz ASP.NET Podstawowe Blazor uwierzytelnianie i autoryzacja.

IHttpContextAccessor/HttpContext w Razor składnikach

IHttpContextAccessor należy unikać renderowania interakcyjnego, ponieważ nie ma prawidłowej HttpContext dostępności.

IHttpContextAccessor Może służyć do składników, które są statycznie renderowane na serwerze. Zalecamy jednak unikanie go, jeśli to możliwe.

HttpContextMoże być używany jako parametr kaskadowy tylko w statycznie renderowanych składnikach głównych dla zadań ogólnych, takich jak inspekcja i modyfikowanie nagłówków lub innych właściwości w składniku App (Components/App.razor). Wartość jest zawsze null dla renderowania interakcyjnego.

[CascadingParameter]
public HttpContext? HttpContext { get; set; }

W przypadku scenariuszy, w których HttpContext element jest wymagany w składnikach interaktywnych, zalecamy przepływ danych za pośrednictwem stanu trwałego składnika z serwera. Aby uzyskać więcej informacji, zobacz scenariusze ASP.NET Core po stronie serwera i Blazor Web App dodatkowe scenariusze zabezpieczeń.

Stan udostępniony

Aplikacje po stronie Blazor serwera działają w pamięci serwera, a wiele sesji aplikacji jest hostowanych w ramach tego samego procesu. Dla każdej sesji Blazor aplikacji rozpoczyna obwód z własnym zakresem kontenera wstrzykiwania zależności, w związku z czym usługi o określonym zakresie są unikatowe dla Blazor sesji.

Ostrzeżenie

Nie zalecamy, aby aplikacje na tym samym serwerze miały stan udostępniania przy użyciu usług singleton, chyba że zostanie podjęta skrajna ostrożność, ponieważ może to powodować luki w zabezpieczeniach, takie jak wyciek stanu użytkownika między obwodami.

Możesz używać stanowych pojedynczych usług w Blazor aplikacjach, jeśli zostały one specjalnie zaprojektowane. Na przykład użycie pojedynczej pamięci podręcznej jest dopuszczalne, ponieważ pamięć podręczna pamięci wymaga klucza dostępu do danego wpisu. Zakładając, że użytkownicy nie mają kontroli nad kluczami pamięci podręcznej używanymi z pamięcią podręczną, stan przechowywany w pamięci podręcznej nie przecieka między obwodami.

Aby uzyskać ogólne wskazówki dotyczące zarządzania stanem, zobacz zarządzanie stanem ASP.NET CoreBlazor.

Zabezpieczenia po stronie serwera poufnych danych i poświadczeń

W środowiskach testowych/przejściowych i produkcyjnych kod po stronie Blazor serwera i internetowe interfejsy API powinny używać bezpiecznych przepływów uwierzytelniania, które unikają utrzymywania poświadczeń w kodzie projektu lub plikach konfiguracji. Poza lokalnymi testami programistycznymi zalecamy unikanie używania zmiennych środowiskowych do przechowywania poufnych danych, ponieważ zmienne środowiskowe nie są najbezpieczniejszym podejściem. W przypadku lokalnego testowania programistycznego narzędzie Secret Manager jest zalecane do zabezpieczania poufnych danych. Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Bezpieczne przepływy uwierzytelniania (dokumentacja ASP.NET Core)
• Tożsamości zarządzane dla usług platformy Microsoft Azure (Blazor dokumentacja)

W przypadku programowania i testowania lokalnego po stronie klienta i po stronie serwera użyj narzędzia Secret Manager, aby zabezpieczyć poufne poświadczenia.

Szablon projektu

Utwórz nową aplikację po stronie Blazor serwera, postępując zgodnie ze wskazówkami w temacie Tooling for ASP.NET Core Blazor.

Program Visual Studio

Po wybraniu szablonu aplikacji po stronie serwera i skonfigurowaniu projektu wybierz uwierzytelnianie aplikacji w obszarze Typ uwierzytelniania:

• Brak (wartość domyślna): brak uwierzytelniania.
• Indywidualne konta: konta użytkowników są przechowywane w aplikacji przy użyciu ASP.NET Core Identity.

Visual Studio Code

Podczas wydawania polecenia interfejsu wiersza polecenia platformy .NET w celu utworzenia i skonfigurowania aplikacji po stronie Blazor serwera wskaż mechanizm uwierzytelniania z opcją -au|--auth :

-au {AUTHENTICATION}

Uwaga

Aby uzyskać pełne polecenie, zobacz Tooling for ASP.NET Core (Narzędzia dla platformy ASP.NET Core Blazor).

Dopuszczalne wartości uwierzytelniania dla symbolu zastępczego {AUTHENTICATION} są wyświetlane w poniższej tabeli.

Mechanizm uwierzytelniania	opis
None (domyślne)	Bez uwierzytelniania
Individual	Użytkownicy przechowywani w aplikacji przy użyciu systemu ASP.NET Core Identity

Aby uzyskać więcej informacji, zobacz polecenie dotnet new w Przewodniku platformy .NET Core.

Interfejs wiersza polecenia platformy .NET

Podczas wydawania polecenia interfejsu wiersza polecenia platformy .NET w celu utworzenia i skonfigurowania aplikacji po stronie Blazor serwera wskaż mechanizm uwierzytelniania z opcją -au|--auth :

-au {AUTHENTICATION}

Uwaga

Aby uzyskać pełne polecenie, zobacz Tooling for ASP.NET Core (Narzędzia dla platformy ASP.NET Core Blazor).

Dopuszczalne wartości uwierzytelniania dla symbolu zastępczego {AUTHENTICATION} są wyświetlane w poniższej tabeli.

Mechanizm uwierzytelniania	opis
None (domyślne)	Bez uwierzytelniania
Individual	Użytkownicy przechowywani w aplikacji przy użyciu systemu ASP.NET Core Identity

Więcej informacji:

• Zobacz polecenie dotnet new w Przewodniku platformy .NET Core.

• Wykonaj polecenie pomocy dla szablonu w powłoce poleceń:

  dotnet new {PROJECT TEMPLATE} --help
  

  W poprzednim poleceniu {PROJECT TEMPLATE} symbol zastępczy jest szablonem projektu.

BlazorIdentity Interfejs użytkownika (indywidualne konta)

Blazorprogram obsługuje generowanie pełnego BlazorIdentity interfejsu użytkownika podczas wybierania opcji uwierzytelniania dla indywidualnych kont.

Kod Blazor Web App szkieletu Identity szablonu dla bazy danych programu SQL Server. Wersja wiersza polecenia używa biblioteki SQLite i zawiera bazę danych SQLite dla programu Identity.

Szablon:

• Obsługuje interaktywne renderowanie po stronie serwera (interakcyjne SSR) i scenariusze renderowania po stronie klienta (CSR) z uwierzytelnionymi użytkownikami.
• Dodaje IdentityRazor składniki i powiązaną logikę dla rutynowych zadań uwierzytelniania, takich jak logowanie użytkowników i ich out. Składniki Identity obsługują również zaawansowane Identity funkcje, takie jak potwierdzenie konta i odzyskiwanie hasła oraz uwierzytelnianie wieloskładnikowe przy użyciu aplikacji innej firmy. Należy pamiętać, że Identity same składniki nie obsługują interakcyjności.
• IdentityDodaje powiązane pakiety i zależności.
• Odwołuje się do Identity pakietów w pliku _Imports.razor.
• Tworzy niestandardową klasę użytkownika Identity (ApplicationUser).
• Tworzy i rejestruje EF Core kontekst bazy danych (ApplicationDbContext).
• Konfiguruje routing dla wbudowanych Identity punktów końcowych.
• Obejmuje Identity walidację i logikę biznesową.

Aby sprawdzić Blazor składniki platformyIdentity, uzyskaj dostęp do nich w Pages folderachAccount i Shared w szablonie Blazor Web App projektu (źródle odwołania).

Po wybraniu trybów renderowania Interactive WebAssembly lub Interactive Auto serwer obsługuje wszystkie żądania uwierzytelniania i autoryzacji, a Identity składniki są renderowane statycznie na serwerze w Blazor Web Appgłównym projekcie programu .

Platforma udostępnia niestandardowe AuthenticationStateProvider zarówno w projektach serwera, jak i klienta (.Client) w celu przepływu stanu uwierzytelniania użytkownika do przeglądarki. Projekt serwera wywołuje metodę AddAuthenticationStateSerialization, podczas gdy projekt klienta wywołuje metodę AddAuthenticationStateDeserialization. Uwierzytelnianie na serwerze zamiast klienta umożliwia aplikacji dostęp do stanu uwierzytelniania podczas prerenderingu i przed zainicjowanym środowiskiem uruchomieniowym zestawu WebAssembly platformy .NET. Implementacje niestandardowe AuthenticationStateProvider używają usługi stanu trwałego składnika (PersistentComponentState) do serializacji stanu uwierzytelniania w komentarzach HTML, a następnie odczytują go z powrotem z zestawu WebAssembly w celu utworzenia nowego AuthenticationState wystąpienia. Aby uzyskać więcej informacji, zobacz sekcję Zarządzanie stanem uwierzytelniania w Blazor Web Appsekcji s .

Tylko w przypadku rozwiązań interactive Server (źródło referencyjne) jest po stronie AuthenticationStateProvider serwera, IdentityRevalidatingAuthenticationStateProvider która rewalyduje sygnaturę zabezpieczeń dla połączonego użytkownika co 30 minut połączony obwód interaktywny.

BlazorIdentity zależy DbContext od wystąpień, które nie są tworzone przez fabrykę, co jest zamierzone, ponieważ DbContext jest wystarczające, aby składniki szablonu Identity projektu były renderowane statycznie bez obsługi interakcyjności.

Aby zapoznać się z opisem sposobu stosowania globalnych trybów renderowania interakcyjnego do składników innychIdentity niż składniki, a jednocześnie wymuszania statycznego przewodnika SSR dla Identity składników, zobacz ASP.NET Tryby renderowania PodstawoweBlazor.

Aby uzyskać więcej informacji na temat utrwalania stanu wstępnego, zobacz Prerender ASP.NET Core components (Składniki prerender ASP.NET CoreRazor).

Aby uzyskać więcej informacji na temat interfejsu BlazorIdentity użytkownika i wskazówek dotyczących integrowania identyfikatorów logowania zewnętrznego za pośrednictwem witryn społecznościowych, zobacz Co nowego w identity programie .NET 8.

Uwaga

Linki dokumentacji do źródła referencyjnego platformy .NET zwykle ładują domyślną gałąź repozytorium, która odzwierciedla bieżące programowanie dla następnej wersji platformy .NET. Aby wybrać tag dla określonej wersji, użyj listy rozwijanej Przełącz gałęzie lub tagi. Aby uzyskać więcej informacji, zobacz Jak wybrać tag wersji kodu źródłowego platformy ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Zarządzanie stanem uwierzytelniania w s Blazor Web App

Ta sekcja ma zastosowanie do Blazor Web Apptych, które przyjmują:

• Indywidualne konta
• Renderowanie po stronie klienta (CSR, interakcyjność oparta na zestawie WebAssembly).

Dostawca stanu uwierzytelniania po stronie klienta jest używany tylko w ramach Blazor programu i nie jest zintegrowany z systemem uwierzytelniania ASP.NET Core. Podczas prerenderingu Blazor uwzględnia metadane zdefiniowane na stronie i używa systemu uwierzytelniania ASP.NET Core w celu określenia, czy użytkownik jest uwierzytelniony. Gdy użytkownik przechodzi z jednej strony do innej, jest używany dostawca uwierzytelniania po stronie klienta. Gdy użytkownik odświeży stronę (załaduj ponownie pełną stronę), dostawca stanu uwierzytelniania po stronie klienta nie jest zaangażowany w decyzję uwierzytelniania na serwerze. Ponieważ stan użytkownika nie jest utrwalany przez serwer, każdy stan uwierzytelniania utrzymywany po stronie klienta zostanie utracony.

Aby rozwiązać ten problem, najlepszym rozwiązaniem jest przeprowadzenie uwierzytelniania w systemie uwierzytelniania ASP.NET Core. Dostawca stanu uwierzytelniania po stronie klienta zajmuje się tylko odzwierciedleniem stanu uwierzytelniania użytkownika. Przykłady tego, jak to zrobić za pomocą dostawców stanu uwierzytelniania, są przedstawiane przez Blazor Web App szablon projektu i opisane poniżej.

W pliku projektu Program serwera wywołaj metodę AddAuthenticationStateSerialization, która serializuje AuthenticationState zwrócone przez serwer po stronie AuthenticationStateProvider serwera przy użyciu usługi stan składnika trwałego (PersistentComponentState):

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization();

Interfejs API serializuje tylko nazwę po stronie serwera i oświadczenia roli w celu uzyskania dostępu w przeglądarce. Aby uwzględnić wszystkie oświadczenia, ustaw wartość SerializeAllClaims na true w wywołaniu po stronie serwera na wartość AddAuthenticationStateSerialization:

builder.Services.AddRazorComponents()
    .AddInteractiveWebAssemblyComponents()
    .AddAuthenticationStateSerialization(
        options => options.SerializeAllClaims = true);

W pliku projektu klienta (.Client) wywołaj metodę AddAuthenticationStateDeserialization, która dodaje lokalizację AuthenticationStateProvider AuthenticationState deserializacji z serwera przy użyciu i AuthenticationStateData trwałej usługi stanu składnika (PersistentComponentState).Program W projekcie serwera powinno istnieć AddAuthenticationStateSerialization odpowiednie wywołanie.

builder.Services.AddAuthorizationCore();
builder.Services.AddCascadingAuthenticationState();
builder.Services.AddAuthenticationStateDeserialization();

Dodatkowe oświadczenia i tokeny od dostawców zewnętrznych

Aby przechowywać dodatkowe oświadczenia od dostawców zewnętrznych, zobacz Utrwalanie dodatkowych oświadczeń i tokenów od dostawców zewnętrznych na platformie ASP.NET Core.

Usługa Azure App Service dla systemu Linux z serwerem Identity

Podczas wdrażania w usłudze Azure App Service dla systemu Linux z serwerem Identity jawnie określ wystawcę. Aby uzyskać więcej informacji, zobacz Zabezpieczanie Identity zaplecza internetowego interfejsu API dla spAs.

Wstrzykiwanie AuthenticationStateProvider dla usług o zakresie do składnika

Nie próbuj rozwiązywać problemów AuthenticationStateProvider w zakresie niestandardowym, ponieważ powoduje utworzenie nowego wystąpienia obiektu AuthenticationStateProvider , które nie zostało poprawnie zainicjowane.

Aby uzyskać dostęp do AuthenticationStateProvider elementu w ramach usługi o zakresie składnika, należy wstrzyknąć AuthenticationStateProvider element z @inject dyrektywą lub [Inject] atrybutem i przekazać go do usługi jako parametr. Takie podejście gwarantuje, że poprawne, zainicjowane wystąpienie AuthenticationStateProvider obiektu jest używane dla każdego wystąpienia aplikacji użytkownika.

ExampleService.cs:

public class ExampleService
{
    public async Task<string> ExampleMethod(AuthenticationStateProvider authStateProvider)
    {
        var authState = await authStateProvider.GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            return $"{user.Identity.Name} is authenticated.";
        }
        else
        {
            return "The user is NOT authenticated.";
        }
    }
}

Zarejestruj usługę jako zakres. W aplikacji po stronie Blazor serwera zakres usług ma okres istnienia równy czasowi trwania obwodu połączenia klienta.

W pliku Program:

builder.Services.AddScoped<ExampleService>();

W poniższym składniku InjectAuthStateProvider:

• Składnik dziedziczy element OwningComponentBase.
• Element AuthenticationStateProvider jest wstrzykiwany i przekazywany do .ExampleService.ExampleMethod
• ExampleService jest rozpoznawany za pomocą OwningComponentBase.ScopedServices funkcji i GetRequiredService, która zwraca poprawne, zainicjowane wystąpienie ExampleService , które istnieje przez okres istnienia obwodu użytkownika.

InjectAuthStateProvider.razor:

@page "/inject-auth-state-provider"
@inherits OwningComponentBase
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>Inject <code>AuthenticationStateProvider</code> Example</h1>

<p>@message</p>

@code {
    private string? message;
    private ExampleService? ExampleService { get; set; }

    protected override async Task OnInitializedAsync()
    {
        ExampleService = ScopedServices.GetRequiredService<ExampleService>();

        message = await ExampleService.ExampleMethod(AuthenticationStateProvider);
    }
}

Aby uzyskać więcej informacji, zobacz wskazówki dotyczące OwningComponentBase iniekcji zależności ASP.NET CoreBlazor.

Wyświetlanie nieautoryzowanej zawartości podczas prerenderingu za pomocą niestandardowego AuthenticationStateProvider

Aby uniknąć wyświetlania nieautoryzowanej zawartości, na przykład zawartości w składnikuAuthorizeView, podczas prerendering z niestandardowym AuthenticationStateProviderelementem , należy zastosować jedną z następujących metod:

• Zaimplementuj IHostEnvironmentAuthenticationStateProvider obsługę prerenderingu niestandardowegoAuthenticationStateProvider: aby zapoznać się z przykładową implementacją IHostEnvironmentAuthenticationStateProviderprogramu , zobacz Blazor implementację ServerAuthenticationStateProvider platformy w ServerAuthenticationStateProvider.cs (źródle referencyjnym).

  Uwaga

  Linki dokumentacji do źródła referencyjnego platformy .NET zwykle ładują domyślną gałąź repozytorium, która odzwierciedla bieżące programowanie dla następnej wersji platformy .NET. Aby wybrać tag dla określonej wersji, użyj listy rozwijanej Przełącz gałęzie lub tagi. Aby uzyskać więcej informacji, zobacz Jak wybrać tag wersji kodu źródłowego platformy ASP.NET Core (dotnet/AspNetCore.Docs #26205).

• Wyłącz prerendering: wskazuje tryb renderowania z parametrem prerender ustawionym na false najwyższy poziom składnika w hierarchii składników aplikacji, który nie jest składnikiem głównym.

  Uwaga

  Tworzenie składnika głównego interakcyjnego, takiego jak App składnik, nie jest obsługiwane. W związku z tym prerendering nie może być wyłączony bezpośrednio przez App składnik.

  W przypadku aplikacji opartych na szablonie Blazor Web App projektu prerendering jest zwykle wyłączony, gdy Routes składnik jest używany w składniku App (Components/App.razor) :

  <Routes @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  Ponadto wyłącz prerendering dla HeadOutlet składnika:

  <HeadOutlet @rendermode="new InteractiveServerRenderMode(prerender: false)" />
  

  Można również selektywnie sterować trybem renderowania zastosowanym Routes do wystąpienia składnika. Zobacz na przykład tryby renderowania ASP.NET CoreBlazor.

• Uwierzytelnij użytkownika na serwerze przed rozpoczęciem działania aplikacji: aby zastosować to podejście, aplikacja musi odpowiadać na początkowe żądanie użytkownika przy użyciu strony logowania lub wyświetlania opartego Identityna protokole i uniemożliwić uwierzytelnianie żądań do Blazor punktów końcowych. Aby uzyskać więcej informacji, zobacz Tworzenie aplikacji ASP.NET Core z danymi użytkownika chronionymi przez autoryzację. Po uwierzytelnieniu nieautoryzowana zawartość w prerenderowanych Razor składnikach jest wyświetlana tylko wtedy, gdy użytkownik jest naprawdę nieautoryzowany do wyświetlania zawartości.

Zarządzanie stanem użytkownika

Pomimo słowa "state" w nazwie AuthenticationStateProvider nie jest przeznaczony do przechowywania stanu użytkownika ogólnego. AuthenticationStateProvider Wskazuje tylko stan uwierzytelniania użytkownika w aplikacji, niezależnie od tego, czy są oni zalogowani do aplikacji i którzy są zalogowani jako.

Uwierzytelnianie używa tego samego uwierzytelniania ASP.NET Core Identity co Razor aplikacje Pages i MVC. Stan użytkownika przechowywany dla przepływów ASP.NET Core Identity do Blazor bez dodawania dodatkowego kodu do aplikacji. Postępuj zgodnie ze wskazówkami w artykułach ASP.NET Core Identity i samouczkach dotyczących Identity funkcji, które zostaną zastosowane w Blazor częściach aplikacji.

Aby uzyskać wskazówki dotyczące ogólnego zarządzania stanem poza programem ASP.NET CoreIdentity, zobacz zarządzanie stanem ASP.NET CoreBlazor.

Dodatkowe abstrakcje zabezpieczeń

Dwie dodatkowe abstrakcje uczestniczą w zarządzaniu stanem uwierzytelniania:

• ServerAuthenticationStateProvider(źródło referencyjne): Element AuthenticationStateProviderużywany przez platformę Blazor do uzyskiwania stanu uwierzytelniania z serwera.

• RevalidatingServerAuthenticationStateProvider (źródło referencyjne): klasa bazowa usług AuthenticationStateProvider używanych przez Blazor platformę do odbierania stanu uwierzytelniania ze środowiska hosta i ich ponownego aktualizowania w regularnych odstępach czasu.

  Domyślny interwał 30-minutowej zmiany można dostosować w (RevalidatingIdentityAuthenticationStateProviderAreas/Identity/RevalidatingIdentityAuthenticationStateProvider.cs). Poniższy przykład skraca interwał do 20 minut:

  protected override TimeSpan RevalidationInterval => TimeSpan.FromMinutes(20);
  

Uwaga

Linki dokumentacji do źródła referencyjnego platformy .NET zwykle ładują domyślną gałąź repozytorium, która odzwierciedla bieżące programowanie dla następnej wersji platformy .NET. Aby wybrać tag dla określonej wersji, użyj listy rozwijanej Przełącz gałęzie lub tagi. Aby uzyskać więcej informacji, zobacz Jak wybrać tag wersji kodu źródłowego platformy ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Zarządzanie stanem uwierzytelniania przy wylogowywaniu

Po stronie Blazor serwera stan uwierzytelniania użytkownika jest utrwalany przez cały okres istnienia obwodu, w tym na kartach przeglądarki. Aby aktywnie oznaczać użytkownika na kartach przeglądarki, gdy użytkownik wyloguje się na jednej karcie, musisz zaimplementować RevalidatingServerAuthenticationStateProvider (źródło referencyjne) z krótkim RevalidationInterval.

Uwaga

Linki dokumentacji do źródła referencyjnego platformy .NET zwykle ładują domyślną gałąź repozytorium, która odzwierciedla bieżące programowanie dla następnej wersji platformy .NET. Aby wybrać tag dla określonej wersji, użyj listy rozwijanej Przełącz gałęzie lub tagi. Aby uzyskać więcej informacji, zobacz Jak wybrać tag wersji kodu źródłowego platformy ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Czas trwania ważności tymczasowego adresu URL przekierowania

Ta sekcja dotyczy s Blazor Web App.

RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration Użyj opcji , aby uzyskać lub ustawić okres istnienia ważności ASP.NET Core Data Protection dla tymczasowych adresów URL przekierowania emitowanych przez Blazor renderowanie po stronie serwera. Są one używane tylko w sposób przejściowy, więc okres istnienia musi być wystarczająco długi, aby klient odbierał adres URL i rozpoczynał nawigację do niego. Jednak powinno to być również wystarczająco długie, aby umożliwić niesymetryczność zegara na serwerach. Wartość domyślna to pięć minut.

W poniższym przykładzie wartość jest rozszerzona do siedmiu minut:

builder.Services.AddRazorComponents(options => 
    options.TemporaryRedirectionUrlValidityDuration = 
        TimeSpan.FromMinutes(7));

Uwierzytelnianie po stronie Blazor klienta

W aplikacjach po stronie klienta można pominąć kontrole uwierzytelniania po stronie Blazor klienta, ponieważ cały kod po stronie klienta może być modyfikowany przez użytkowników. To samo dotyczy wszystkich technologii aplikacji po stronie klienta, w tym struktur SPA Języka JavaScript i aplikacji natywnych dla dowolnego systemu operacyjnego.

Dodaj następujące elementy:

• Odwołanie do Microsoft.AspNetCore.Components.Authorization pakietu NuGet.

  Uwaga

  Aby uzyskać instrukcje dodawania pakietów do aplikacji .NET, zobacz artykuły w sekcji Instalowanie pakietów i zarządzanie nimi w temacie Przepływ pracy użycia pakietów (dokumentacja programu NuGet). Sprawdź prawidłowe wersje pakietów pod adresem NuGet.org.

• Przestrzeń nazw Microsoft.AspNetCore.Components.Authorization w pliku _Imports.razor aplikacji.

Aby obsłużyć uwierzytelnianie, użyj wbudowanej lub niestandardowej AuthenticationStateProvider usługi.

Aby uzyskać więcej informacji na temat uwierzytelniania po stronie klienta, zobacz Secure ASP.NET Core Blazor WebAssembly.

Usługa AuthenticationStateProvider

AuthenticationStateProvider to podstawowa usługa używana przez AuthorizeView składnik i kaskadowe usługi uwierzytelniania w celu uzyskania stanu uwierzytelniania dla użytkownika.

Zazwyczaj nie używa się usługi AuthenticationStateProvider bezpośrednio. Należy skorzystać z metod z użyciem składnika AuthorizeView lub Task<AuthenticationState> opisanych w dalszej części tego artykułu. Główną wadą bezpośredniego używania usługi AuthenticationStateProvider jest fakt, że składnik nie jest automatycznie powiadamiany w przypadku zmiany podstawowych danych o stanie uwierzytelnienia.

Aby zaimplementować niestandardowy AuthenticationStateProviderelement , zobacz ASP.NET Stan uwierzytelniania podstawowegoBlazor, który zawiera wskazówki dotyczące implementowania powiadomień o zmianie stanu uwierzytelniania użytkownika.

Uzyskiwanie danych podmiotu zabezpieczeń oświadczeń użytkownika

Usługa AuthenticationStateProvider może dostarczyć dane bieżącego użytkownika ClaimsPrincipal , jak pokazano w poniższym przykładzie.

ClaimsPrincipalData.razor:

@page "/claims-principal-data"
@using System.Security.Claims
@inject AuthenticationStateProvider AuthenticationStateProvider

<h1>ClaimsPrincipal Data</h1>

<button @onclick="GetClaimsPrincipalData">Get ClaimsPrincipal Data</button>

<p>@authMessage</p>

@if (claims.Any())
{
    <ul>
        @foreach (var claim in claims)
        {
            <li>@claim.Type: @claim.Value</li>
        }
    </ul>
}

<p>@surname</p>

@code {
    private string? authMessage;
    private string? surname;
    private IEnumerable<Claim> claims = Enumerable.Empty<Claim>();

    private async Task GetClaimsPrincipalData()
    {
        var authState = await AuthenticationStateProvider
            .GetAuthenticationStateAsync();
        var user = authState.User;

        if (user.Identity is not null && user.Identity.IsAuthenticated)
        {
            authMessage = $"{user.Identity.Name} is authenticated.";
            claims = user.Claims;
            surname = user.FindFirst(c => c.Type == ClaimTypes.Surname)?.Value;
        }
        else
        {
            authMessage = "The user is NOT authenticated.";
        }
    }
}

W powyższym przykładzie:

• ClaimsPrincipal.Claims Zwraca oświadczenia użytkownika (claims) dla wyświetlania w interfejsie użytkownika.
• Wiersz, który uzyskuje nazwisko użytkownika (surname) wywołuje ClaimsPrincipal.FindAll z predykatem w celu filtrowania roszczeń użytkownika.

Jeśli parametr user.Identity.IsAuthenticated ma wartość true, ponieważ użytkownik jest obiektem ClaimsPrincipal, można wyliczyć oświadczenia i ocenić członkostwo w rolach.

Aby uzyskać więcej informacji na temat usług i wstrzykiwania zależności, zobacz Wstrzykiwanie zależności Blazor w środowisku ASP.NET Core i Wstrzykiwanie zależności w środowisku ASP.NET Core. Aby uzyskać informacje na temat implementowania niestandardowego AuthenticationStateProviderelementu , zobacz ASP.NET Stan uwierzytelniania podstawowegoBlazor.

Uwidacznianie stanu uwierzytelnienia jako parametru kaskadowego

Jeśli dane stanu uwierzytelniania są wymagane dla logiki proceduralnej, takiej jak podczas wykonywania akcji wyzwalanej przez użytkownika, uzyskaj dane stanu uwierzytelniania, definiując kaskadowy parametr typu Task<AuthenticationState>, jak pokazano w poniższym przykładzie.

CascadeAuthState.razor:

@page "/cascade-auth-state"

<h1>Cascade Auth State</h1>

<p>@authMessage</p>

@code {
    private string authMessage = "The user is NOT authenticated.";

    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    protected override async Task OnInitializedAsync()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user?.Identity is not null && user.Identity.IsAuthenticated)
            {
                authMessage = $"{user.Identity.Name} is authenticated.";
            }
        }
    }
}

Jeśli parametr user.Identity.IsAuthenticated ma wartość true, można wyliczyć oświadczenia i ocenić członkostwo w rolach.

Skonfiguruj parametr kaskadowy Task<AuthenticationState> przy użyciu AuthorizeRouteView usług stanu uwierzytelniania kaskadowego i .

Podczas tworzenia Blazor aplikacji na podstawie jednego Blazor z szablonów projektów z włączonym uwierzytelnianiem aplikacja zawiera AuthorizeRouteView wywołanie i pokazane AddCascadingAuthenticationState w poniższym przykładzie. Aplikacja po stronie Blazor klienta obejmuje również wymagane rejestracje usług. Dodatkowe informacje są prezentowane w sekcji Dostosowywanie nieautoryzowanej zawartości ze składnikiemRouter.

<Router ...>
    <Found ...>
        <AuthorizeRouteView RouteData="routeData" 
            DefaultLayout="typeof(Layout.MainLayout)" />
        ...
    </Found>
</Router>

Program W pliku zarejestruj kaskadowe usługi stanu uwierzytelniania:

builder.Services.AddCascadingAuthenticationState();

W aplikacji po stronie Blazor klienta dodaj usługi autoryzacji do Program pliku:

builder.Services.AddAuthorizationCore();

W aplikacji po stronie Blazor serwera usługi dla opcji i autoryzacji są już obecne, więc nie są wymagane żadne dalsze kroki.

Autoryzacja

Po uwierzytelnieniu użytkownika stosowane są reguły autoryzacji, określające, co ten użytkownik może robić.

O udzieleniu lub odmowie dostępu decydują następujące czynniki:

• Uwierzytelnienie (zalogowanie) użytkownika.
• Członkostwo użytkownika w roli.
• Posiadanie oświadczenia przez użytkownika.
• Spełnienie zasad.

Każda z tych koncepcji jest taka sama jak w przypadku aplikacji MVC lub Razor Pages platformy ASP.NET Core. Aby uzyskać więcej informacji na temat zabezpieczeń platformy ASP.NET Core, zobacz artykuły wymienione w sekcji ASP.NET Core Security and Identity.

AuthorizeView cm6long

Składnik AuthorizeView selektywnie wyświetla zawartość interfejsu użytkownika w zależności od tego, czy użytkownik jest autoryzowany. Takie podejście jest przydatne, gdy trzeba tylko wyświetlać dane dla użytkownika i nie trzeba używać identity ich w logice proceduralnej.

Składnik uwidacznia zmienną context typu AuthenticationState (@context w Razor składni), której można użyć do uzyskiwania dostępu do informacji o zalogowanym użytkowniku:

<AuthorizeView>
    <p>Hello, @context.User.Identity?.Name!</p>
</AuthorizeView>

Możesz również podać inną zawartość do wyświetlania, jeśli użytkownik nie jest autoryzowany za pomocą kombinacji parametrów Authorized i NotAuthorized :

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
        <p><button @onclick="HandleClick">Authorized Only Button</button></p>
    </Authorized>
    <NotAuthorized>
        <p>You're not authorized.</p>
    </NotAuthorized>
</AuthorizeView>

@code {
    private void HandleClick() { ... }
}

AuthorizeView Mimo że składnik kontroluje widoczność elementów na podstawie stanu autoryzacji użytkownika, nie wymusza zabezpieczeń w samej procedurze obsługi zdarzeń. W poprzednim przykładzie HandleClick metoda jest skojarzona tylko z przyciskiem widocznym dla autoryzowanych użytkowników, ale nic nie uniemożliwia wywołania tej metody z innych miejsc. Aby zapewnić bezpieczeństwo na poziomie metody, zaimplementuj dodatkową logikę autoryzacji w ramach samego programu obsługi lub w odpowiednim interfejsie API.

RazorBlazor Web Appskładniki nigdy nie wyświetlają <NotAuthorized> zawartości, gdy autoryzacja kończy się niepowodzeniem po stronie serwera podczas statycznego renderowania po stronie serwera (statyczne SSR). Autoryzacja potoku po stronie serwera ASP.NET Core na serwerze. Użyj technik po stronie serwera do obsługi nieautoryzowanych żądań. Aby uzyskać więcej informacji, zobacz tryby renderowania ASP.NET CoreBlazor.

Ostrzeżenie

Znaczniki i metody skojarzone z elementem AuthorizeView po stronie klienta są chronione tylko przed wyświetlaniem i wykonywaniem w renderowanych interfejsach użytkownika w aplikacjach po stronie Blazor klienta. Aby chronić autoryzowaną zawartość i bezpieczne metody po stronie Blazorklienta, zawartość jest zwykle dostarczana przez bezpieczne, autoryzowane wywołanie internetowego interfejsu API do interfejsu API serwera i nigdy nie są przechowywane w aplikacji. Aby uzyskać więcej informacji, zobacz Wywoływanie internetowego interfejsu API z aplikacji ASP.NET Core Blazor i ASP.NET Core Blazor WebAssembly dodatkowych scenariuszy zabezpieczeń.

Zawartość elementów Authorized i NotAuthorized może zawierać dowolne elementy, takie jak inne składniki interaktywne.

Warunki autoryzacji, takie jak role i zasady używane do zarządzania dostępem i opcjami interfejsu użytkownika, omówiono w sekcji Autoryzacja.

Jeśli nie określono warunków autoryzacji, AuthorizeView użyj zasad domyślnych:

• Uwierzytelnieni (zalogowani) użytkownicy są autoryzowani.
• Użytkownicy nieuwierzytelnieni (wylogowani) nie są autoryzowani.

Składnika AuthorizeView można używać w składniku NavMenu (Shared/NavMenu.razor) w celu wyświetlania składnika NavLink (NavLink), należy jednak zauważyć, że to rozwiązanie umożliwia jedynie usunięcie elementu listy z przedstawionych danych wyjściowych. Nie uniemożliwia użytkownikowi przejścia do składnika. Zaimplementuj autoryzację oddzielnie w składniku docelowym.

Autoryzacja na podstawie ról i zasad

Składnik AuthorizeView obsługuje autoryzację na podstawie ról lub zasad.

W przypadku autoryzacji opartej na rolach użyj parametru Roles . W poniższym przykładzie użytkownik musi mieć oświadczenie roli dla Admin ról lub Superuser :

<AuthorizeView Roles="Admin, Superuser">
    <p>You have an 'Admin' or 'Superuser' role claim.</p>
</AuthorizeView>

Aby wymagać od użytkownika oświadczeń zarówno roli, jak Admin i Superuser , składniki zagnieżdżenia AuthorizeView :

<AuthorizeView Roles="Admin">
    <p>User: @context.User</p>
    <p>You have the 'Admin' role claim.</p>
    <AuthorizeView Roles="Superuser" Context="innerContext">
        <p>User: @innerContext.User</p>
        <p>You have both 'Admin' and 'Superuser' role claims.</p>
    </AuthorizeView>
</AuthorizeView>

Powyższy kod ustanawia element Context dla składnika wewnętrznego AuthorizeView , aby zapobiec AuthenticationState kolizji kontekstu. Dostęp AuthenticationState do kontekstu jest dostępny na zewnątrz AuthorizeView przy użyciu standardowego podejścia do uzyskiwania dostępu do kontekstu (@context.User). Dostęp do kontekstu jest uzyskiwany wewnętrznych AuthorizeView z nazwanym innerContext kontekstem (@innerContext.User).

Aby uzyskać więcej informacji, w tym wskazówki dotyczące konfiguracji, zobacz Autoryzacja na podstawie ról na platformie ASP.NET Core.

W przypadku autoryzacji opartej na zasadach użyj parametru Policy z pojedynczą nazwą zasad:

<AuthorizeView Policy="Over21">
    <p>You satisfy the 'Over21' policy.</p>
</AuthorizeView>

Aby obsłużyć przypadek, w którym użytkownik powinien spełnić jedną z kilku zasad, utwórz zasady, które potwierdzają, że użytkownik spełnia inne zasady.

Aby obsłużyć przypadek, w którym użytkownik musi spełnić kilka zasad jednocześnie, wykonaj jedną z następujących metod:

• Utwórz zasady, które AuthorizeView potwierdzają, że użytkownik spełnia kilka innych zasad.

• Zagnieżdżanie zasad w wielu AuthorizeView składnikach:

  <AuthorizeView Policy="Over21">
      <AuthorizeView Policy="LivesInCalifornia">
          <p>You satisfy the 'Over21' and 'LivesInCalifornia' policies.</p>
      </AuthorizeView>
  </AuthorizeView>
  

Autoryzacja na podstawie oświadczeń to szczególny przypadek autoryzacji na podstawie zasad. Można na przykład zdefiniować zasady, które wymagają od użytkowników posiadania określonego oświadczenia. Aby uzyskać więcej informacji, zobacz Autoryzacja na podstawie zasad na platformie ASP.NET Core.

Jeśli żadna z Roles Policy nich nie zostanie określona, AuthorizeView użyj zasad domyślnych:

• Uwierzytelnieni (zalogowani) użytkownicy są autoryzowani.
• Użytkownicy nieuwierzytelnieni (wylogowani) nie są autoryzowani.

Ponieważ w porównaniach ciągów platformy .NET uwzględniana jest wielkość liter, uwzględniana jest również dopasowywanie nazw ról i zasad. Na przykład Admin (wielkie litery A) nie jest traktowana jako ta sama rola co admin (małe litery a).

Przypadek Pascal jest zwykle używany dla nazw ról i zasad (na przykład BillingAdministrator), ale użycie przypadku Pascal nie jest ścisłym wymaganiem. Różne schematy wielkości liter, takie jak przypadek wielbłąda, przypadek kebab i przypadek węża, są dozwolone. Używanie spacji w nazwach ról i zasad jest nietypowe, ale dozwolone przez platformę. Na przykład billing administrator jest to nietypowy format nazwy roli lub zasad w aplikacjach platformy .NET, ale jest to prawidłowa nazwa roli lub zasad.

Zawartość wyświetlana podczas uwierzytelniania asynchronicznego

Struktura Blazor umożliwia asynchroniczne określanie stanu uwierzytelnienia. Podstawowym scenariuszem tego podejścia są aplikacje po stronie Blazor klienta, które wysyłają żądanie do zewnętrznego punktu końcowego na potrzeby uwierzytelniania.

W trakcie AuthorizeView uwierzytelniania nie jest wyświetlana żadna zawartość. Aby wyświetlić zawartość podczas uwierzytelniania, przypisz zawartość do parametru Authorizing :

<AuthorizeView>
    <Authorized>
        <p>Hello, @context.User.Identity?.Name!</p>
    </Authorized>
    <Authorizing>
        <p>You can only see this content while authentication is in progress.</p>
    </Authorizing>
</AuthorizeView>

Takie podejście nie ma zwykle zastosowania do aplikacji po stronie Blazor serwera. Aplikacje po stronie Blazor serwera znają stan uwierzytelniania natychmiast po ustanowieniu stanu. Authorizing zawartość może być dostarczana w składniku AuthorizeView aplikacji, ale zawartość nigdy nie jest wyświetlana.

Atrybut [Authorize]

Atrybut [Authorize] jest dostępny w Razor składnikach:

@page "/"
@attribute [Authorize]

You can only see this if you're signed in.

Ważne

Używaj [Authorize] @page tylko składników osiągnięto za pośrednictwem routera Blazor . Autoryzacja jest przeprowadzana tylko jako aspekt routingu i nie dotyczy składników podrzędnych renderowanych na stronie. Aby autoryzować wyświetlanie konkretnych części strony, należy użyć składnika AuthorizeView.

Atrybut [Authorize] także obsługuje autoryzację na podstawie ról lub zasad. W przypadku autoryzacji na podstawie ról należy użyć parametru Roles:

@page "/"
@attribute [Authorize(Roles = "Admin, Superuser")]

<p>You can only see this if you're in the 'Admin' or 'Superuser' role.</p>

W przypadku autoryzacji na podstawie zasad należy użyć parametru Policy:

@page "/"
@attribute [Authorize(Policy = "Over21")]

<p>You can only see this if you satisfy the 'Over21' policy.</p>

Jeśli żadna z Roles Policy nich nie zostanie określona, [Authorize] użyj zasad domyślnych:

• Uwierzytelnieni (zalogowani) użytkownicy są autoryzowani.
• Użytkownicy nieuwierzytelnieni (wylogowani) nie są autoryzowani.

Gdy użytkownik nie jest autoryzowany i jeśli aplikacja nie dostosowuje nieautoryzowanej zawartości ze składnikiemRouter, platforma automatycznie wyświetla następujący komunikat rezerwowy:

Not authorized.

Autoryzacja na potrzeby zasobów

Aby autoryzować użytkowników na potrzeby dostępu do zasobów, należy przekazać dane trasy żądania do parametru Resource składnika AuthorizeRouteView.

Router.Found W zawartości żądanej trasy:

<AuthorizeRouteView Resource="routeData" RouteData="routeData" 
    DefaultLayout="typeof(MainLayout)" />

Aby uzyskać więcej informacji na temat sposobu przekazywania danych o stanie autoryzacji i używania ich w logice proceduralnej, zobacz sekcję Uwidacznianie stanu uwierzytelnienia jako parametru kaskadowego.

Po odebraniu danych trasy do zasobu przez składnik AuthorizeRouteView zasady autoryzacji otrzymują dostęp do właściwości RouteData.PageType i RouteData.RouteValues, co umożliwia zastosowanie logiki niestandardowej w celu podejmowania decyzji dotyczących autoryzacji.

W poniższym przykładzie utworzono zasady EditUser w składniku AuthorizationOptions na potrzeby konfiguracji usługi autoryzacji dla aplikacji (AddAuthorizationCore), z następującą logiką:

• Należy określić, czy istnieje wartość trasy z kluczem id. Jeśli ten klucz istnieje, wartość trasy jest zapisywana jako value.
• W zmiennej o nazwie id wartość value jest zapisywana jako ciąg lub jest ustawiana pusta wartość ciągu (string.Empty).
• Jeśli zmienna id nie zawiera pustego ciągu, należy stwierdzić, że zasady są spełnione (zwrócić wartość true), jeśli wartość ciągu zaczyna się od EMP. W przeciwnym razie należy stwierdzić, że zasady nie są spełnione (zwrócić wartość false).

W pliku Program:

• Dodaj przestrzenie nazw Microsoft.AspNetCore.Components i System.Linq:

  using Microsoft.AspNetCore.Components;
  using System.Linq;
  

• Dodaj zasady:

  options.AddPolicy("EditUser", policy =>
      policy.RequireAssertion(context =>
      {
          if (context.Resource is RouteData rd)
          {
              var routeValue = rd.RouteValues.TryGetValue("id", out var value);
              var id = Convert.ToString(value, 
                  System.Globalization.CultureInfo.InvariantCulture) ?? string.Empty;
  
              if (!string.IsNullOrEmpty(id))
              {
                  return id.StartsWith("EMP", StringComparison.InvariantCulture);
              }
          }
  
          return false;
      })
  );
  

Powyższy przykład przedstawia bardzo uproszczone zasady autoryzacji, służące wyłącznie do zilustrowania tej koncepcji przy użyciu działającego przykładu. Aby uzyskać więcej informacji na temat tworzenia i konfigurowania zasad autoryzacji, zobacz Autoryzacja na podstawie zasad na platformie ASP.NET Core.

W poniższym składniku EditUser zasób w pozycji /users/{id}/edit zawiera parametr trasy dla identyfikatora użytkownika ({id}). Ten składnik używa poprzednich zasad autoryzacji EditUser do określenia, czy wartość trasy dla zmiennej id zaczyna się od EMP. Jeśli zmienna id zaczyna się od EMP, zasady są spełnione i dostęp do składnika jest autoryzowany. Jeśli zmienna id zaczyna się od wartości innej niż EMP lub jeśli zmienna id zawiera pusty ciąg, zasady nie są spełnione, a składnik nie zostanie załadowany.

EditUser.razor:

@page "/users/{id}/edit"
@using Microsoft.AspNetCore.Authorization
@attribute [Authorize(Policy = "EditUser")]

<h1>Edit User</h1>

<p>The "EditUser" policy is satisfied! <code>Id</code> starts with 'EMP'.</p>

@code {
    [Parameter]
    public string? Id { get; set; }
}

Dostosowywanie nieautoryzowanej zawartości za pomocą Router składnika

Składnik Router w połączeniu ze składnikiem AuthorizeRouteView umożliwia określenie zawartości niestandardowej w aplikacji, gdy:

• Użytkownik nie spełnia warunku [Authorize] zastosowanego do składnika. Są wyświetlane znaczniki elementu <NotAuthorized>. Atrybut [Authorize] omówiono w sekcji Atrybut [Authorize].
• Autoryzacja asynchroniczna jest w toku, co zwykle oznacza, że trwa proces uwierzytelniania użytkownika. Są wyświetlane znaczniki elementu <Authorizing>.

Ważne

Blazor funkcje routera, które wyświetlają <NotAuthorized> i <NotFound> zawartość nie działają podczas statycznego renderowania po stronie serwera (statyczne SSR), ponieważ przetwarzanie żądań jest w pełni obsługiwane przez przetwarzanie żądań potoku oprogramowania pośredniczącego ASP.NET Core i Razor składniki nie są renderowane w ogóle dla nieautoryzowanych lub nieprawidłowych żądań. Użyj technik po stronie serwera, aby obsługiwać nieautoryzowane i nieprawidłowe żądania podczas statycznego rejestrowania SSR. Aby uzyskać więcej informacji, zobacz tryby renderowania ASP.NET CoreBlazor.

<Router ...>
    <Found ...>
        <AuthorizeRouteView ...>
            <NotAuthorized>
                ...
            </NotAuthorized>
            <Authorizing>
                ...
            </Authorizing>
        </AuthorizeRouteView>
    </Found>
</Router>

Zawartość elementów Authorized i NotAuthorized może zawierać dowolne elementy, takie jak inne składniki interaktywne.

Uwaga

Powyższe wymaga kaskadowej rejestracji usług stanu uwierzytelniania w pliku aplikacji Program :

builder.Services.AddCascadingAuthenticationState();

Jeśli NotAuthorized zawartość nie zostanie określona, zostanie użyta AuthorizeRouteView następująca wiadomość rezerwowa:

Not authorized.

Aplikacja utworzona na podstawie Blazor WebAssembly szablonu projektu z włączonym uwierzytelnianiem RedirectToLogin zawiera składnik umieszczony w <NotAuthorized> zawartości Router składnika. Gdy użytkownik nie jest uwierzytelniony (context.User.Identity?.IsAuthenticated != true), RedirectToLogin składnik przekierowuje przeglądarkę do punktu końcowego authentication/login na potrzeby uwierzytelniania. Użytkownik jest zwracany do żądanego adresu URL po uwierzytelnieniu u dostawcy identity .

Logika proceduralna

Jeśli aplikacja jest wymagana do sprawdzania reguł autoryzacji w ramach logiki proceduralnej, użyj kaskadowego parametru typuTask<AuthenticationState>, aby uzyskać obiekt ClaimsPrincipal użytkownika. Parametr Task<AuthenticationState> można połączyć z innymi usługami, takimi jak IAuthorizationService, w celu oceny zasad.

W poniższym przykładzie:

• Funkcja user.Identity.IsAuthenticated wykonuje kod dla uwierzytelnionych (zalogowanych) użytkowników.
• Wykonuje user.IsInRole("admin") kod dla użytkowników w roli "Administrator".
• Wykonuje (await AuthorizationService.AuthorizeAsync(user, "content-editor")).Succeeded kod dla użytkowników spełniających zasady "content-editor".

Aplikacja po stronie Blazor serwera zawiera odpowiednie przestrzenie nazw utworzone na podstawie szablonu projektu. W aplikacji po stronie Blazor klienta potwierdź obecność Microsoft.AspNetCore.Authorization przestrzeni nazw i Microsoft.AspNetCore.Components.Authorization w składniku lub w pliku aplikacji _Imports.razor :

@using Microsoft.AspNetCore.Authorization
@using Microsoft.AspNetCore.Components.Authorization

ProceduralLogic.razor:

@page "/procedural-logic"
@inject IAuthorizationService AuthorizationService

<h1>Procedural Logic Example</h1>

<button @onclick="@DoSomething">Do something important</button>

@code {
    [CascadingParameter]
    private Task<AuthenticationState>? authenticationState { get; set; }

    private async Task DoSomething()
    {
        if (authenticationState is not null)
        {
            var authState = await authenticationState;
            var user = authState?.User;

            if (user is not null)
            {
                if (user.Identity is not null && user.Identity.IsAuthenticated)
                {
                    // ...
                }

                if (user.IsInRole("Admin"))
                {
                    // ...
                }

                if ((await AuthorizationService.AuthorizeAsync(user, "content-editor"))
                    .Succeeded)
                {
                    // ...
                }
            }
        }
    }
}

Rozwiązywanie problemów

Typowe błędy:

• Autoryzacja wymaga parametru kaskadowego typu Task<AuthenticationState>. Rozważ użycie klasy CascadingAuthenticationState w celu dostarczenia go.

• Wartość null odbierana dla elementu authenticationStateTask

Prawdopodobnie projekt nie został utworzony przy użyciu szablonu po stronie Blazor serwera z włączonym uwierzytelnianiem.

Na platformie .NET 7 lub starszej zawijaj <CascadingAuthenticationState> część drzewa interfejsu użytkownika, na przykład wokół routera Blazor :

<CascadingAuthenticationState>
    <Router ...>
        ...
    </Router>
</CascadingAuthenticationState>

W programie .NET 8 lub nowszym CascadingAuthenticationState nie używaj składnika:

- <CascadingAuthenticationState>
      <Router ...>
          ...
      </Router>
- </CascadingAuthenticationState>

Zamiast tego dodaj kaskadowe usługi stanu uwierzytelniania do kolekcji usług w Program pliku :

builder.Services.AddCascadingAuthenticationState();

Składnik CascadingAuthenticationState (.NET 7 lub starszy) lub usługi udostępniane przez AddCascadingAuthenticationState program (.NET 8 lub nowszy) dostarcza> Task<AuthenticationStateparametr kaskadowy, który z kolei otrzymuje z bazowej AuthenticationStateProvider usługi wstrzykiwania zależności.

Dane osobowe (PII)

Firma Microsoft używa definicji RODO dla "danych osobowych" (RODO 4.1), gdy w dokumentacji omówiono dane osobowe (PII).

Dane osobowe dotyczą wszelkich informacji dotyczących zidentyfikowanej lub możliwej do zidentyfikowania osoby fizycznej. Możliwa do zidentyfikowania osoba fizyczna to osoba, która może zostać zidentyfikowana bezpośrednio lub pośrednio z dowolną z następujących czynności:

• Nazwisko
• Numer identyfikacyjny
• Współrzędne lokalizacji
• Identyfikator online
• Inne konkretne czynniki
  • Fizyczne
  • Fizjologiczne
  • Genetyczny
  • Mentalny (psychologiczny)
  • Ekonomiczny
  • Kulturalny
  • Społeczny identity

Dodatkowe zasoby

• Zasoby i Blazor Web App po stronie serwera
  • Szybki start: dodawanie logowania przy użyciu konta Microsoft do aplikacji internetowej platformy ASP.NET Core
  • Szybki start: ochrona internetowego interfejsu API identity platformy Microsoft ASP.NET Core
  • Konfigurowanie ASP.NET Core do pracy z serwerami proxy i modułami równoważenia obciążenia: zawiera wskazówki dotyczące:
    • Używanie oprogramowania pośredniczącego nagłówków przekazywanych w celu zachowania informacji o schemacie HTTPS między serwerami proxy i sieciami wewnętrznymi.
    • Dodatkowe scenariusze i przypadki użycia, w tym ręczna konfiguracja schematu, żądanie zmiany ścieżki żądania na potrzeby prawidłowego routingu żądań i przekazywanie schematu żądań dla zwrotnych serwerów proxy systemu Linux i innych niż IIS.
• Dokumentacja platformy Microsoft identity
  • Omówienie
  • Protokoły OAuth 2.0 i OpenID Connect na platformie Microsoft identity
  • Przepływ kodu autoryzacji OAuth 2.0 i platformy Microsoft identity
  • Tokeny identyfikatorów platformy Microsoft identity
  • Tokeny dostępu platformy Microsoft identity
• Tematy dotyczące zabezpieczeń platformy ASP.NET Core
• Konfigurowanie uwierzytelniania systemu Windows na platformie ASP.NET Core
• Tworzenie niestandardowej wersji biblioteki JavaScript Authentication.MSAL
• Awesome Blazor: Authentication — linki do przykładów ze społeczności
• Uwierzytelnianie i autoryzacja w aplikacjach Blazor Hybrid na platformie ASP.NET Core