Ověřování a autorizace ASP.NET Core Blazor

Tento článek popisuje podporu konfigurace a správy zabezpečení ASP.NET Core v aplikacích Blazor.

Blazor používá existující mechanismy ověřování ASP.NET Core k vytvoření uživatele identity. Přesný mechanismus závisí na tom, jak Blazor je aplikace hostovaná, na straně serveru nebo na straně klienta.

Scénáře zabezpečení se liší mezi autorizačním kódem spuštěným na straně serveru a klientem v Blazor aplikacích. U autorizačního kódu, který běží na serveru, jsou kontroly autorizace schopné vynutit pravidla přístupu pro oblasti aplikace a komponent. Vzhledem k tomu, že spouštění kódu na straně klienta může být manipulováno, nemůže být autorizační kód spuštěný na klientovi důvěryhodný, aby zcela vynucoval pravidla přístupu nebo kontroloval zobrazení obsahu na straně klienta.

Pokud musí být zaručeno vynucení autorizačního pravidla, neimplementujte kontroly autorizace v kódu na straně klienta. Sestavte, Blazor Web App která se spoléhá pouze na vykreslování na straně serveru (SSR) pro kontroly autorizace a vynucení pravidel.

Konvence autorizace Razor Pages se nevztahují na směrovatelné komponenty Razor. Pokud je Razor Pages vložena nesměrovatelná Razor komponenta, zásady autorizace stránky nepřímo ovlivňují komponentu spolu s Razor obsahem stránky.

Poznámka:

Příklady kódu v tomto článku přijímají referenční typy s možnou hodnotou null (NRT) a statickou analýzu stavu null-stav kompilátoru .NET, které jsou podporovány v ASP.NET Core v .NET 6 nebo novější. Pokud cílíte na ASP.NET Core 5.0 nebo starší, odeberte z příkladů v tomto článku označení typu null (?).

Zabezpečená údržba citlivých dat a přihlašovacích údajů

Neukládejte tajné kódy aplikací, připojovací řetězec, přihlašovací údaje, hesla, osobní identifikační čísla (PIN), privátní kód .NET/C# nebo privátní klíče/tokeny v kódu na straně klienta, což je vždy nezabezpečené. Kód na straně Blazor klienta by měl přistupovat k zabezpečeným službám a databázím prostřednictvím zabezpečeného webového rozhraní API, které řídíte.

V testovacích a pracovních a produkčních prostředích by kód na straně Blazor serveru a webová rozhraní API měly používat toky zabezpečeného ověřování, které se vyhýbají údržbě přihlašovacích údajů v kódu projektu nebo konfiguračních souborech. Mimo místní testování vývoje doporučujeme vyhnout se použití proměnných prostředí k ukládání citlivých dat, protože proměnné prostředí nejsou nejbezpečnějším přístupem. Pro místní testování vývoje se pro zabezpečení citlivých dat doporučuje nástroj Secret Manager. Další informace naleznete v následujících zdrojích:

• Toky zabezpečeného ověřování (dokumentace k ASP.NET Core)
• Spravované identity pro služby Microsoft Azure (tento článek)

Pro místní vývoj a testování na straně klienta a serveru použijte nástroj Secret Manager k zabezpečení citlivých přihlašovacích údajů.

Spravované identity pro služby Microsoft Azure

Pro služby Microsoft Azure doporučujeme používat spravované identity. Spravované identity se bezpečně ověřují ve službách Azure bez uložení přihlašovacích údajů v kódu aplikace. Další informace naleznete v následujících zdrojích:

• Co jsou spravované identity pro prostředky Azure? (Dokumentace k Microsoft Entra)
• Dokumentace ke službám Azure
  • Spravované identity v Microsoft Entra pro Azure SQL
  • Jak používat spravované identity pro App Service a Azure Functions

Podpora antiforgery

Šablona Blazor :

• Přidá antiforgery služby automaticky, když AddRazorComponents je volána v Program souboru.
• Přidá Middleware Antiforgery voláním UseAntiforgery do kanálu zpracování požadavků v Program souboru a vyžaduje ochranu proti padělání koncového bodu, aby se zmírnit hrozby pro padělání požadavků mezi weby (CSRF/XSRF). UseAntiforgery je volána po UseHttpsRedirection. Hovor UseAntiforgery musí být umístěn po volání, pokud je k dispozici, do UseAuthentication a UseAuthorization.

Komponenta AntiforgeryToken vykreslí antiforgery token jako skryté pole a tato komponenta se automaticky přidá do instancí formuláře (EditForm). Další informace najdete v tématu Blazor formulářů Core.

Služba AntiforgeryStateProvider poskytuje přístup k tokenu antiforgery přidruženému k aktuální relaci. Vloží službu a zavolá její GetAntiforgeryToken() metodu k získání aktuálního AntiforgeryRequestToken. Další informace najdete v tématu Blazor ASP.NET Core.

Blazor ukládá tokeny žádostí do stavu komponenty, což zaručuje, že antiforgery tokeny jsou k dispozici interaktivním komponentám, i když nemají přístup k žádosti.

Poznámka:

Omezení rizik proti padělání je vyžadováno pouze při odesílání dat formuláře na server kódovaný jako application/x-www-form-urlencoded, multipart/form-datanebo text/plain protože se jedná o jediné platné typy entypů formuláře.

Další informace naleznete v následujících zdrojích:

• Prevence útoků XSRF/CSRF (Cross-Site Request Forgery) v ASP.NET Core: Tento článek je primárním článkem o ASP.NET Core, který se vztahuje na serverovou stranu Blazor Server, projekt Blazor Web Appserveru a Blazor integraci s MVC/Razor Pages.
• Blazor ASP.NET Základní formuláře – přehled: Oddíl podpory antiforgery článku se týká Blazor formulářů podpory antiforgery.

Ověřování na straně serveru Blazor

Aplikace na straně Blazor serveru se konfigurují pro zabezpečení stejným způsobem jako aplikace ASP.NET Core. Další informace najdete v článcích věnovaných zabezpečení ASP.NET Core .

Kontext ověřování se naváže pouze při spuštění aplikace, což je, když se aplikace poprvé připojí k webSocketu přes SignalR připojení s klientem. Ověřování může být založené na nosné cookie tokenu nebo na jiném nosném tokenu, ale ověřování se spravuje prostřednictvím SignalR centra a zcela v okruhu. Kontext ověřování se udržuje po celou dobu životnosti okruhu. Aplikace pravidelně obnovují stav ověřování uživatele každých 30 minut.

Pokud aplikace musí zachytávat uživatele pro vlastní služby nebo reagovat na aktualizace uživatele, podívejte se na ASP.NET základní scénáře zabezpečení a Blazor Web App další scénáře zabezpečení.

Blazor liší se od tradičních webových aplikací vykreslených serverem, které při každé navigaci na stránce vytvoří nové požadavky HTTP s soubory cookie. Během událostí navigace se kontroluje ověřování. Soubory cookie se ale nezajímají. Soubory cookie se odesílají jenom při vytváření požadavku HTTP na server, což není to, co se stane, když uživatel přejde v Blazor aplikaci. Během navigace se stav ověřování uživatele kontroluje v okruhu Blazor , který můžete aktualizovat kdykoli na serveru pomocí RevalidatingAuthenticationStateProvider abstrakce.

Důležité

Implementace vlastního NavigationManager ověřování pro ověření během navigace se nedoporučuje. Pokud aplikace musí během navigace spouštět vlastní logiku stavu ověřování, použijte vlastní AuthenticationStateProvider.

Poznámka:

Příklady kódu v tomto článku přijímají referenční typy s možnou hodnotou null (NRT) a statickou analýzu stavu null-stav kompilátoru .NET, které jsou podporovány v ASP.NET Core v .NET 6 nebo novější. Pokud cílíte na ASP.NET Core 5.0 nebo starší, odeberte z příkladů v tomto článku označení typu null (?).

Integrovaná nebo vlastní AuthenticationStateProvider služba získává data o stavu ověřování z ASP.NET Core HttpContext.User. Takto se stav ověřování integruje se stávajícími mechanismy ověřování ASP.NET Core.

Další informace o ověřování na straně serveru najdete v tématu ASP.NET Základní Blazor ověřování a autorizace.

IHttpContextAccessor/HttpContext

IHttpContextAccessor byste se obecně měli vyhnout interaktivnímu vykreslování, protože platný HttpContext není vždy k dispozici.

IHttpContextAccessor lze použít pro součásti, které jsou staticky vykresleny na serveru. Pokud je to ale možné, doporučujeme ho vyhnout.

HttpContext lze použít jako kaskádový parametr pouze v staticky vykreslovaných kořenových komponentách pro obecné úlohy, jako je kontrola a úprava hlaviček nebo jiných vlastností v komponentě App (Components/App.razor). Hodnota je vždy null určená pro interaktivní vykreslování.

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

Pro scénáře, ve HttpContext kterých se vyžaduje v interaktivních komponentách, doporučujeme tok dat přes trvalý stav komponenty ze serveru. Další informace najdete v tématu ASP.NET základní serverové a Blazor Web App další scénáře zabezpečení.

Sdílený stav

Aplikace na straně Blazor serveru jsou živé v paměti serveru a několik relací aplikací se hostuje ve stejném procesu. Pro každou relaci Blazor aplikace spustí okruh s vlastním oborem kontejneru injektáže závislostí, takže služby s vymezeným oborem jsou jedinečné pro každou Blazor relaci.

Upozorňující

Nedoporučujeme aplikace ve stejném stavu sdílení serveru, které používají singletonové služby, pokud se o to nezajímá extrémní péče, protože to může představovat ohrožení zabezpečení, jako je únik stavu uživatele napříč okruhy.

Stavové jednoúčelové služby můžete v Blazor aplikacích používat, pokud jsou speciálně navržené. Například použití jednoúčelové mezipaměti paměti je přijatelné, protože mezipaměť paměti vyžaduje klíč pro přístup k dané položce. Za předpokladu, že uživatelé nemají kontrolu nad klíči mezipaměti, které se používají s mezipamětí, nedojde k úniku stavu uloženého v mezipaměti mezi okruhy.

Obecné pokyny ke správě stavu najdete v tématu ASP.NET Blazor Základní správa stavu.

Zabezpečení citlivých dat a přihlašovacích údajů na straně serveru

V testovacích a pracovních a produkčních prostředích by kód na straně Blazor serveru a webová rozhraní API měly používat toky zabezpečeného ověřování, které se vyhýbají údržbě přihlašovacích údajů v kódu projektu nebo konfiguračních souborech. Mimo místní testování vývoje doporučujeme vyhnout se použití proměnných prostředí k ukládání citlivých dat, protože proměnné prostředí nejsou nejbezpečnějším přístupem. Pro místní testování vývoje se pro zabezpečení citlivých dat doporučuje nástroj Secret Manager. Další informace naleznete v následujících zdrojích:

• Toky zabezpečeného ověřování (dokumentace k ASP.NET Core)
• Spravované identity pro služby Microsoft Azure (Blazor dokumentace)

Pro místní vývoj a testování na straně klienta a serveru použijte nástroj Secret Manager k zabezpečení citlivých přihlašovacích údajů.

Šablona projektu

Vytvořte novou serverovou Blazor aplikaci podle pokynů v nástrojích pro ASP.NET Core Blazor.

Visual Studio

Po výběru šablony aplikace na straně serveru a konfiguraci projektu vyberte ověřování aplikace v části Typ ověřování:

• Žádné (výchozí): Žádné ověřování.
• Jednotlivé účty: Uživatelské účty jsou uloženy v aplikaci pomocí ASP.NET Core Identity.

Visual Studio Code

Při vydávání příkazu .NET CLI pro vytvoření a konfiguraci aplikace na straně Blazor serveru uveďte mechanismus ověřování s -au|--auth možností:

-au {AUTHENTICATION}

Poznámka:

Úplný příkaz naleznete v části Nástroje pro ASP.NET Core Blazor.

Přípustné hodnoty ověřování pro {AUTHENTICATION} zástupný symbol jsou uvedeny v následující tabulce.

Mechanismus ověřování	Popis
None (výchozí)	Bez ověřování
Individual	Uživatelé uložení v aplikaci s ASP.NET Core Identity

Další informace najdete v popisu příkazu dotnet new v příručce k .NET Core.

.NET CLI

Při vydávání příkazu .NET CLI pro vytvoření a konfiguraci aplikace na straně Blazor serveru uveďte mechanismus ověřování s -au|--auth možností:

-au {AUTHENTICATION}

Poznámka:

Úplný příkaz naleznete v části Nástroje pro ASP.NET Core Blazor.

Přípustné hodnoty ověřování pro {AUTHENTICATION} zástupný symbol jsou uvedeny v následující tabulce.

Mechanismus ověřování	Popis
None (výchozí)	Bez ověřování
Individual	Uživatelé uložení v aplikaci s ASP.NET Core Identity

Další informace:

• Projděte si příkaz dotnet new v příručce k .NET Core.

• Spusťte příkaz nápovědy pro šablonu v příkazovém prostředí:

  dotnet new {PROJECT TEMPLATE} --help
  

  V předchozím příkazu {PROJECT TEMPLATE} je zástupný symbol šablonou projektu.

Blazor Identity Uživatelské rozhraní (jednotlivé účty)

Blazorpodporuje generování úplného BlazorIdentity uživatelského rozhraní, když zvolíte možnost ověřování pro jednotlivé účty.

Vygeneruje Blazor Web App kód šablony Identity pro databázi SQL Serveru. Verze příkazového řádku používá SQLite a obsahuje databázi SQLite pro Identity.

Šablona:

• Podporuje interaktivní vykreslování na straně serveru (interaktivní SSR) a scénáře vykreslování na straně klienta (CSR) s ověřenými uživateli.
• Přidá IdentityRazor komponenty a související logiku pro rutinní úlohy ověřování, jako je přihlášení a odhlášení uživatelů. Komponenty Identity také podporují pokročilé Identity funkce, jako je potvrzení účtu a obnovení hesla a vícefaktorové ověřování pomocí aplikace třetí strany. Všimněte si, že Identity samotné komponenty nepodporují interaktivitu.
• IdentityPřidá související balíčky a závislosti.
• Odkazuje na Identity balíčky v souboru _Imports.razor.
• Vytvoří vlastní třídu uživatele Identity (ApplicationUser).
• Vytvoří a zaregistruje EF Core kontext databáze (ApplicationDbContext).
• Konfiguruje směrování pro předdefinované Identity koncové body.
• Zahrnuje Identity ověřování a obchodní logiku.

Pokud chcete zkontrolovat Blazor komponenty architekturyIdentity, přejděte k nim ve PagesShared složkách Account složky v Blazor Web App šabloně projektu (referenční zdroj).

Když zvolíte režim interaktivního automatického vykreslování WebAssembly nebo Interactive Auto Render, server zpracuje všechny požadavky na ověřování a autorizaci a Identity komponenty se na serveru Blazor Web Appv hlavním projektu vykreslují staticky.

Architektura poskytuje vlastní AuthenticationStateProvider projekt v projektech serveru i klienta.Client pro tok stavu ověřování uživatele do prohlížeče. Volání projektu AddAuthenticationStateSerializationserveru , zatímco klient projekt volání AddAuthenticationStateDeserialization. Ověřování na serveru místo klienta umožňuje aplikaci přístup ke stavu ověřování během předkončování a před inicializováním modulu runtime .NET WebAssembly. Vlastní AuthenticationStateProvider implementace používají službu Persistent Component State Service (PersistentComponentState) k serializaci stavu ověřování do komentářů HTML a pak ji číst zpět z WebAssembly k vytvoření nové AuthenticationState instance. Další informace najdete v části Správa stavu ověřování.Blazor Web App

Pouze pro řešení interaktivního serveru (referenční zdroj) je serverová stranaIdentityRevalidatingAuthenticationStateProvider, AuthenticationStateProvider která aktualizuje razítko zabezpečení pro připojeného uživatele každých 30 minut, je připojený interaktivní okruh.

Blazor Identity závisí na DbContext instancích, které nevytvořila továrna, což je záměrné, protože stačí, aby DbContext komponenty šablony Identity projektu vykreslovány staticky bez podpory interaktivity.

Popis toho, jak se režimy globálního interaktivního vykreslování použijí u jinýchIdentity než komponent a současně vynucují statické SSR pro Identity komponenty, najdete v tématu Blazor vykreslování jádra.

Další informace o trvalém předrenderovaného stavu naleznete v tématu Prerender ASP.NET Základní Razor komponenty.

Poznámka:

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepnutí větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Správa stavu ověřování v Blazor Web Apps

Tato část se týká Blazor Web Apptoho, co přijímá:

• Jednotlivé účty
• Vykreslování na straně klienta (CSR, interaktivita založená na WebAssembly).

Zprostředkovatel stavu ověřování na straně klienta se používá jenom uvnitř Blazor a není integrovaný se systémem ověřování ASP.NET Core. Během předdefinování respektuje metadata definovaná na stránce a používá ověřovací systém ASP.NET Core k určení, Blazor jestli je uživatel ověřený. Když uživatel přejde z jedné stránky na jinou, použije se zprostředkovatel ověřování na straně klienta. Když uživatel aktualizuje stránku (znovu načíst celou stránku), není zprostředkovatel stavu ověřování na straně klienta zapojen do rozhodnutí o ověření na serveru. Vzhledem k tomu, že stav uživatele není serverem trvalý, dojde ke ztrátě stavu ověřování udržovaného na straně klienta.

Nejlepší způsob řešení je provést ověřování v rámci systému ověřování ASP.NET Core. Zprostředkovatel stavu ověřování na straně klienta se postará jenom o to, aby odrážel stav ověřování uživatele. Příklady, jak toho dosáhnout pomocí zprostředkovatelů stavu ověřování, jsou demonstrovány šablonou Blazor Web App projektu a popsány níže.

V souboru projektu Program serveru volání AddAuthenticationStateSerialization, který serializuje AuthenticationState vrácené server-side AuthenticationStateProvider pomocí trvalé stavová služba komponent (PersistentComponentState):

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

Rozhraní API serializuje pouze název na straně serveru a deklarace identity rolí pro přístup v prohlížeči. Pokud chcete zahrnout všechny deklarace identity, nastavte SerializeAllClaims na true volání AddAuthenticationStateSerializationna straně serveru:

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

V souboru projektu klienta (.Client) volání Program, který přidá místo AddAuthenticationStateDeserializationAuthenticationStateProvider, kde je deserializován ze serveru pomocí AuthenticationState a AuthenticationStateData).PersistentComponentState V projektu serveru by mělo existovat odpovídající volání AddAuthenticationStateSerialization .

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

Další deklarace identity a tokeny od externích zprostředkovatelů

Pokud chcete ukládat další deklarace identity od externích zprostředkovatelů, přečtěte si téma věnované zachování dalších deklarací identity a tokenů od externích zprostředkovatelů v ASP.NET Core.

Azure App Service v Linuxu s Identity Serverem

Při nasazování do služby Azure App Service v Linuxu s Identity Serverem zadejte vystavitele explicitně. Další informace najdete v tématu Použití Identity k zabezpečení back-endu webového rozhraní API pro služby SPA.

Vložení AuthenticationStateProvider služeb s vymezeným na komponentu

Nepokoušejte se vyřešit AuthenticationStateProvider v rámci vlastního oboru, protože výsledkem je vytvoření nové instance AuthenticationStateProvider , která není správně inicializována.

Pokud chcete získat přístup k AuthenticationStateProvider komponentě v rámci služby, zadejte AuthenticationStateProvider@inject direktivu [Inject] nebo atribut a předejte ji službě jako parametr. Tento přístup zajišťuje, aby se pro každou instanci aplikace uživatele používala správná inicializovaná instance AuthenticationStateProvider .

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.";
        }
    }
}

Zaregistrujte službu jako vymezenou. V aplikaci na straně Blazor serveru mají služby s vymezeným oborem životnost stejnou dobu trvání okruhu připojení klienta.

V souboru Program:

builder.Services.AddScoped<ExampleService>();

V následující komponentě InjectAuthStateProvider:

• Komponenta dědí OwningComponentBase.
• Přípravek AuthenticationStateProvider se vloží a předá ExampleService.ExampleMethod.
• ExampleService je vyřešen s OwningComponentBase.ScopedServices a GetRequiredService, který vrátí správnou, inicializovanou instanci ExampleService , která existuje po dobu životnosti okruhu uživatele.

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);
    }
}

Další informace najdete v pokynech k injektážiOwningComponentBase.Blazor

Neautorizováno zobrazení obsahu při předkreslování vlastního obsahu AuthenticationStateProvider

Abyste se vyhnuli zobrazení neoprávněného obsahu, například obsahu v komponentěAuthorizeView, při předvádění vlastními AuthenticationStateProviderpřístupy použijte jeden z následujících přístupů:

• Implementujte IHostEnvironmentAuthenticationStateProvider pro vlastní AuthenticationStateProvider podporu předkreslování: Příklad implementace IHostEnvironmentAuthenticationStateProviderarchitektury BlazorServerAuthenticationStateProvider v ServerAuthenticationStateProvider.cs (referenční zdroj)

  Poznámka:

  Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepnutí větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

• Zakázání předběžného vykreslování: Indikujte režim vykreslování s parametrem prerender nastaveným false na komponentu nejvyšší úrovně v hierarchii komponent aplikace, která není kořenovou komponentou.

  Poznámka:

  Interaktivní vytvoření kořenové komponenty, například App komponenty, není podporováno. Proto není možné předřazování přímo zakázat komponentou App .

  U aplikací založených Blazor Web App na šabloně projektu je prerendering obvykle zakázán, pokud se komponenta Routes používá v komponentě App (Components/App.razor) :

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

  Zakažte také předběžné předkreslování pro komponentu HeadOutlet :

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

  Můžete také selektivně řídit režim vykreslování použitý u Routes instance komponenty. Podívejte se Blazor vykreslování ASP.NET Core.

• Před zahájením aplikace ověřte uživatele na serveru: Pokud chcete tento přístup přijmout, musí aplikace reagovat na počáteční požadavek uživatele pomocí přihlašovací stránky nebo zobrazení založeného Identityna přihlašovací stránce nebo zobrazení a zabránit všem požadavkům na Blazor koncové body, dokud se neověří. Další informace najdete v tématu Vytvoření aplikace ASP.NET Core s uživatelskými daty chráněnými autorizací. Po ověření se neautorizovaný obsah v předem vyřazovaných Razor komponent zobrazí jenom v případě, že je uživatel skutečně neautorizovaný k zobrazení obsahu.

Správa stavu uživatele

Navzdory slovu "state" v názvu AuthenticationStateProvider není ukládání stavu obecného uživatele. AuthenticationStateProvider Označuje pouze stav ověřování uživatele do aplikace, jestli je přihlášený k aplikaci a kdo je přihlášený jako.

Ověřování používá stejné ověřování ASP.NET Core Identity jako Razor aplikace Pages a MVC. Stav uživatele uložený pro toky ASP.NET Core Identity bez Blazor přidání dalšího kódu do aplikace. Postupujte podle pokynů v článcích ASP.NET Core Identity a kurzech, Identity které se projeví v Blazor částech aplikace.

Pokyny k obecné správě stavu mimo ASP.NET Core Identitynajdete v tématu Blazor stavu jádra.

Další abstrakce zabezpečení

Správa stavu ověřování se účastní dvou dalších abstrakcí:

• ServerAuthenticationStateProvider (referenční zdroj): Rozhraní AuthenticationStateProvider používá Blazor k získání stavu ověřování ze serveru.

• RevalidatingServerAuthenticationStateProvider (referenční zdroj): Základní třída pro AuthenticationStateProvider služby používané architekturou Blazor pro příjem stavu ověřování z hostitelského prostředí a jeho opětovné obnovení v pravidelných intervalech.

  Výchozí 30minutový interval revalidace je možné upravit v RevalidatingIdentityAuthenticationStateProvider (Areas/Identity/RevalidatingIdentityAuthenticationStateProvider.cs). Následující příklad zkracuje interval na 20 minut:

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

Poznámka:

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepnutí větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Správa stavu ověřování při odhlášení

Na straně Blazor serveru se zachová stav ověřování uživatele po celou dobu životnosti okruhu, včetně na kartách prohlížeče. Pokud chcete proaktivně odhlásit uživatele na kartách prohlížeče, když se uživatel odhlásí na jedné kartě, musíte implementovat RevalidatingServerAuthenticationStateProvider (referenční zdroj) s krátkým RevalidationInterval.

Poznámka:

Odkazy na dokumentaci k referenčnímu zdroji .NET obvykle načítají výchozí větev úložiště, která představuje aktuální vývoj pro příští verzi .NET. Pokud chcete vybrat značku pro konkrétní verzi, použijte rozevírací seznam pro přepnutí větví nebo značek. Další informace najdete v tématu Jak vybrat značku verze zdrojového kódu ASP.NET Core (dotnet/AspNetCore.Docs #26205).

Doba platnosti dočasné adresy URL přesměrování

Tato část se týká Blazor Web Apps.

RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration Pomocí možnosti získat nebo nastavit dobu platnosti ASP.NET základní ochrany dat pro dočasné adresy URL přesměrování generované vykreslováním Blazor na straně serveru. Používají se jenom přechodně, takže životnost musí být dostatečná, aby klient získal adresu URL a začal na ni navigovat. Měla by však být dostatečně dlouhá, aby umožňovala nerovnoměrnou distribuci hodin mezi servery. Výchozí hodnota je pět minut.

V následujícím příkladu je hodnota prodloužena na sedm minut:

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

Ověřování na straně Blazor klienta

V aplikacích na straně klienta je možné obejít kontroly ověřování na straně Blazor klienta, protože všichni uživatelé můžou upravovat kód na straně klienta. Totéž platí pro všechny technologie aplikací na straně klienta, včetně architektur JavaScript SPA a nativních aplikací pro jakýkoli operační systém.

Přidejte následující:

• Referenční informace k Microsoft.AspNetCore.Components.Authorization balíčku NuGet.

  Poznámka:

  Pokyny k přidávání balíčků do aplikací .NET najdete v článcích v části Instalace a správa balíčků na webu Pracovní postup používání balíčků (dokumentace k NuGetu). Ověřte správné verze balíčků na NuGet.org.

• Obor názvů Microsoft.AspNetCore.Components.Authorization do souboru _Imports.razor aplikace.

Pokud chcete zpracovat ověřování, použijte integrovanou nebo vlastní AuthenticationStateProvider službu.

Další informace o ověřování na straně klienta naleznete v tématu Zabezpečení ASP.NET Core Blazor WebAssembly.

Služba AuthenticationStateProvider

AuthenticationStateProvider je základní služba používaná komponentou AuthorizeView a kaskádovými ověřovacími službami k získání stavu ověřování pro uživatele.

AuthenticationStateProvider se obvykle nepoužívá přímo. Použijte komponentu AuthorizeView nebo přístupy Task<AuthenticationState> popsané dále v tomto článku. Hlavní nevýhodou použití AuthenticationStateProvider přímo je to, že komponenta není automaticky upozorněna, pokud se změní podkladová data stavu ověřování.

Informace o implementaci vlastního AuthenticationStateProviderstavu najdete v tématu Blazor ověřování jádra, který obsahuje pokyny k implementaci oznámení o změnách stavu ověřování uživatelů.

Získání dat objektu zabezpečení deklarací identity uživatele

Služba AuthenticationStateProvider může poskytnout data aktuálního uživatele ClaimsPrincipal , jak je znázorněno v následujícím příkladu.

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.";
        }
    }
}

V předchozím příkladu:

• ClaimsPrincipal.Claims vrátí deklarace identity uživatele (claims) pro zobrazení v uživatelském rozhraní.
• Řádek, který získá volání příjmení (surname) ClaimsPrincipal.FindAll uživatele s predikátem k filtrování deklarací identity uživatele.

Pokud user.Identity.IsAuthenticated je true a uživatel je ClaimsPrincipal, je možné vyčíslit deklarace identity a vyhodnotit členství v rolích.

Další informace o injektáži závislostí (DI) a službách najdete v tématech Injektáž závislostí ASP.NET Core Blazor a Injektáž závislostí v ASP.NET Core. Informace o tom, jak implementovat vlastní AuthenticationStateProvider, najdete v tématu ASP.NET Blazor základní stav ověřování.

Zveřejnění stavu ověřování jako kaskádového parametru

Pokud se pro procedurální logiku, například při provádění akce aktivované uživatelem, vyžadují data o stavu ověřování definováním kaskádového parametru typu Task<AuthenticationState>, jak ukazuje následující příklad.

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.";
            }
        }
    }
}

Pokud user.Identity.IsAuthenticated je true, je možné vyčíslit deklarace identity a vyhodnotit členství v rolích.

Nastavte kaskádového parametru Task<AuthenticationState>AuthorizeRouteView pomocí a kaskádových ověřovacích stavových služeb.

Když vytvoříte Blazor aplikaci z jedné ze Blazor šablon projektu s povoleným ověřováním, aplikace obsahuje AuthorizeRouteView volání a volání, které se AddCascadingAuthenticationState zobrazí v následujícím příkladu. Aplikace na straně Blazor klienta zahrnuje také požadované registrace služeb. Další informace se zobrazí v části Přizpůsobení neoprávněného Router obsahu v části Komponenta .

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

Program V souboru zaregistrujte kaskádové stavové služby ověřování:

builder.Services.AddCascadingAuthenticationState();

V aplikaci na straně Blazor klienta přidejte do Program souboru autorizační služby:

builder.Services.AddAuthorizationCore();

V aplikaci na straně Blazor serveru už existují služby pro možnosti a autorizaci, takže nejsou potřeba žádné další kroky.

Autorizace

Po ověření uživatele se pravidla autorizace používají k řízení toho, co může uživatel dělat.

Přístup je obvykle udělen nebo odepřen na základě toho, jestli:

• Uživatel je ověřený (přihlášený).
• Uživatel je v roli.
• Uživatel má deklaraci identity.
• Zásady jsou splněné.

Všechny tyto koncepty jsou stejné jako v aplikaci ASP.NET Core MVC nebo Razor Pages. Další informace o zabezpečení ASP.NET Core najdete v článcích Zabezpečení ASP.NET Core a ASP.NET Core Identity.

AuthorizeView komponenta

Komponenta AuthorizeView selektivně zobrazuje obsah uživatelského rozhraní v závislosti na tom, jestli je uživatel autorizovaný. Tento přístup je užitečný, když potřebujete jenom zobrazit data pro uživatele a nemusíte používat identity uživatele v procedurální logice.

Komponenta zveřejňuje proměnnou context typu AuthenticationState (@context v Razor syntaxi), kterou můžete použít pro přístup k informacím o přihlášeném uživateli:

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

Můžete také zadat jiný obsah pro zobrazení, pokud uživatel nemá autorizaci pomocí kombinace Authorized parametrů a NotAuthorized parametrů:

<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() { ... }
}

Přestože komponenta AuthorizeView řídí viditelnost prvků na základě stavu autorizace uživatele, nevynucuje zabezpečení u samotné obslužné rutiny události. V předchozím příkladu HandleClick je metoda přidružena pouze k tlačítku viditelnému autorizovaným uživatelům, ale nic nebrání vyvolání této metody z jiných míst. Pokud chcete zajistit zabezpečení na úrovni metody, implementujte do samotné obslužné rutiny nebo v příslušném rozhraní API další autorizační logiku.

Razor Blazor Web Appsoučásti s nikdy nezobrazují <NotAuthorized> obsah, pokud autorizace selže na straně serveru během statického vykreslování na straně serveru (statické SSR). Na straně serveru ASP.NET základní kanál zpracovává autorizaci na serveru. Ke zpracování neautorizovaných požadavků použijte techniky na straně serveru. Další informace najdete v tématu Blazor vykreslování core.

Upozorňující

Značky a metody na straně klienta přidružené k objektu AuthorizeView jsou chráněny pouze před zobrazením a spouštěním v vykreslovaných uživatelských rozhraních v aplikacích na straně Blazor klienta. K ochraně autorizovaného obsahu a zabezpečených metod na straně Blazorklienta je obsah obvykle poskytován zabezpečeným, autorizovaným voláním webového rozhraní API na serverové rozhraní API a nikdy se neukládá v aplikaci. Další informace najdete v tématu Blazor ASP.NET Core a Blazor WebAssembly zabezpečení ASP.NET Core.

Obsah Authorized a NotAuthorized může obsahovat libovolné položky, například jiné interaktivní komponenty.

Podmínky autorizace, jako jsou role nebo zásady, které řídí možnosti uživatelského rozhraní nebo přístup, jsou popsané v části Autorizace.

Pokud nejsou zadané podmínky autorizace, AuthorizeView použije se výchozí zásada:

• Ověření (přihlášení) uživatelé mají oprávnění.
• Neověřené (odhlášené) uživatele nejsou neoprávnění.

Komponentu AuthorizeView lze použít v komponentě NavMenu (Shared/NavMenu.razor) k zobrazení komponenty NavLink (NavLink), ale nezapomeňte, že tento přístup odebere položku seznamu jenom z vykresleného výstupu. Nezabrání uživateli v přechodu na tuto komponentu. Implementujte autorizaci samostatně v cílové komponentě.

Autorizace na základě rolí a zásad

Komponenta AuthorizeView podporuje autorizaci založenou na rolích nebo na zásadách.

Pro autorizaci na základě role použijte Roles parametr. V následujícím příkladu musí mít uživatel deklaraci role pro role Admin nebo Superuser role:

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

Pokud chcete vyžadovat, aby měl uživatel deklarace AdminSuperuser identity rolí, vnoření AuthorizeView součástí:

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

Předchozí kód vytvoří pro vnitřní Context komponentu, AuthorizeView aby se zabránilo AuthenticationState kolizi kontextu. K AuthenticationState kontextu se přistupuje na vnější straně AuthorizeView pomocí standardního přístupu pro přístup k kontextu (@context.User). K kontextu se přistupuje ve vnitřní části AuthorizeView s pojmenovaným innerContext kontextem (@innerContext.User).

Další informace, včetně doprovodných materiálů ke konfiguraci, najdete v tématu Autorizace na základě rolí v ASP.NET Core.

Pro autorizaci na základě zásad použijte Policy parametr s jedním názvem zásady:

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

Pokud chcete vyřešit případ, kdy by měl uživatel splňovat jednu z několika zásad, vytvořte zásadu, která potvrzuje, že uživatel splňuje jiné zásady.

Pokud chcete vyřešit případ, kdy uživatel musí současně splňovat několik zásad, použijte jeden z následujících přístupů:

• Vytvořte zásadu, AuthorizeView která potvrzuje, že uživatel splňuje několik dalších zásad.

• Vnoření zásad do několika AuthorizeView komponent:

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

Speciálním případem autorizace na základě zásad je autorizace na základě deklarací identity. Můžete například definovat zásadu, která vyžaduje, aby uživatelé měli určitou deklaraci identity. Další informace najdete v tématu Autorizace na základě zásad v ASP.NET Core.

Roles Policy Pokud ani nezadáte, AuthorizeView použije se výchozí zásada:

• Ověření (přihlášení) uživatelé mají oprávnění.
• Neověřené (odhlášené) uživatele nejsou neoprávnění.

Vzhledem k tomu, že porovnávání řetězců .NET rozlišují malá a velká písmena, rozlišují se také odpovídající názvy rolí a zásad. Například Admin (velkáA) není považována za stejnou roli jako admin (malá).a

Písmena Pascal se obvykle používají pro názvy rolí a zásad (například BillingAdministrator), ale použití případu Pascal není striktní požadavek. Jsou povolena různá schémata, jako jsou velbloudí případ, případ kebabu a hadí případ. Použití mezer v názvech rolí a zásad je neobvyklé, ale architektura je povolená. Jedná se například billing administrator o neobvyklý formát názvu role nebo zásady v aplikacích .NET, ale jde o platnou roli nebo název zásady.

Obsah zobrazený během asynchronního ověřování

Blazor umožňuje asynchronně určit stav ověřování. Primární scénář pro tento přístup je v aplikacích na straně Blazor klienta, které požadují externí koncový bod pro ověřování.

Během ověřování se AuthorizeView nezobrazuje žádný obsah. Pokud chcete zobrazit obsah při ověřování, přiřaďte obsah k 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>

Tento přístup se obvykle nevztahuje na aplikace na straně Blazor serveru. Aplikace na straně Blazor serveru znají stav ověřování hned po vytvoření stavu. Authorizing obsah lze poskytnout v komponentě AuthorizeView aplikace, ale obsah se nikdy nezobrazí.

Atribut [Authorize]

Atribut [Authorize] je k dispozici v Razor komponentách:

@page "/"
@attribute [Authorize]

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

Důležité

Používejte [Authorize]@page pouze komponenty, které byly dosaženy Blazor přes směrovač. Autorizace se provádí pouze jako aspekt směrování a neprovádí se pro podřízené komponenty vykreslené na stránce. Pokud chcete autorizovat zobrazení konkrétních částí na stránce, použijte místo toho AuthorizeView.

Atribut [Authorize] také podporuje autorizaci založenou na rolích nebo na zásadách. Pro autorizaci na základě role použijte parametr Roles:

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

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

Pro autorizaci na základě zásad použijte parametr Policy:

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

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

Roles Policy Pokud ani nezadáte, [Authorize] použije se výchozí zásada:

• Ověření (přihlášení) uživatelé mají oprávnění.
• Neověřené (odhlášené) uživatele nejsou neoprávnění.

Pokud uživatel nemá autorizaci a pokud aplikace neautorizovaný obsah s Router komponentou nepřizpůsobí, architektura automaticky zobrazí následující záložní zprávu:

Not authorized.

Autorizace prostředků

Pokud chcete autorizovat uživatele pro prostředky, předejte data směrování požadavku do parametru Resource v AuthorizeRouteView.

Router.Found V obsahu požadované trasy:

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

Další informace o tom, jak se údaje o stavu autorizace předávají a využívají v procedurální logice, najdete v části Zveřejnění stavu ověřování jako kaskádového parametru.

Když AuthorizeRouteView získá data směrování pro prostředek, zásady autorizace mají přístup ke komponentám RouteData.PageType a RouteData.RouteValues, které umožňují pro rozhodování o autorizaci používat vlastní logiku.

V následujícím příkladu se v EditUser vytvoří zásady AuthorizationOptions pro konfiguraci autorizační služby aplikace (AddAuthorizationCore) s následující logikou:

• Určete, jestli existuje hodnota trasy s klíčem id. Pokud klíč existuje, hodnota trasy je uložená v value.
• V proměnné s názvem id uložte value jako řetězec nebo nastavte prázdnou hodnotu řetězce (string.Empty).
• Pokud id není prázdný řetězec, ověřte, že tato zásada je splněná (vrátí true), pokud hodnota řetězce má na začátku EMP. V opačném případě ověřte, že tato zásada selže (vrátí false).

V souboru Program:

• Přidejte obory názvů pro Microsoft.AspNetCore.Components a System.Linq:

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

• Přidejte zásady:

  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;
      })
  );
  

Předchozí příklad je přehnaně zjednodušená zásada autorizace, která slouží pouze k demonstraci tohoto konceptu na funkčním příkladu. Další informace o vytváření a konfiguraci zásad autorizace najdete v tématu Autorizace na základě zásad v ASP.NET Core.

V následující komponentě EditUser má prostředek v /users/{id}/edit parametr trasy pro identifikátor uživatele ({id}). Tato komponenta využívá předchozí zásady autorizace EditUser k určení, jestli hodnota trasy pro id má na začátku EMP. Pokud id má na začátku EMP, zásada je splněná a přístup ke komponentě je autorizovaný. Pokud id začíná jinou hodnotou než EMP nebo pokud id je prázdný řetězec, zásada selže a komponenta se nenačte.

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; }
}

Přizpůsobení neoprávněného Router obsahu pomocí komponenty

Komponenta Router ve spojení s komponentou AuthorizeRouteView umožňuje aplikaci určit vlastní obsah, pokud:

• Uživatel selže s podmínkou [Authorize] použitou pro komponentu. Zobrazuje se značka elementu <NotAuthorized>. Atribut [Authorize] je popsaný v části věnované atributům[Authorize].
• Probíhá asynchronní autorizace, což obvykle znamená, že probíhá proces ověřování uživatele. Zobrazuje se značka elementu <Authorizing>.

Důležité

Blazor Funkce směrovače, které zobrazují <NotAuthorized> a <NotFound> obsah nejsou funkční při vykreslování na straně statického serveru (static SSR), protože zpracování požadavků je zcela zpracováno ASP.NET zpracování požadavků kanálu middlewaru Core a Razor součásti se nevykreslují vůbec pro neoprávněné nebo chybné požadavky. Použití technik na straně serveru ke zpracování neoprávněných a chybných požadavků během statického serveru SSR. Další informace najdete v tématu Blazor vykreslování core.

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

Obsah Authorized a NotAuthorized může obsahovat libovolné položky, například jiné interaktivní komponenty.

Poznámka:

Předchozí postup vyžaduje kaskádovou registraci stavových služeb ověřování v souboru aplikace Program :

builder.Services.AddCascadingAuthenticationState();

Pokud NotAuthorized není zadaný obsah, použije se AuthorizeRouteView následující záložní zpráva:

Not authorized.

Aplikace vytvořená ze Blazor WebAssembly šablony projektu s povoleným ověřováním zahrnuje komponentu RedirectToLogin , která je umístěna v <NotAuthorized> obsahu Router komponenty. Pokud uživatel není ověřený (context.User.Identity?.IsAuthenticated != true), RedirectToLogin komponenta přesměruje prohlížeč na authentication/login koncový bod pro ověření. Uživatel se po ověření u identity poskytovatele vrátí na požadovanou adresu URL.

Procedurální logika

Pokud je aplikace nutná ke kontrole autorizačních pravidel v rámci procedurální logiky, použijte kaskádový parametr typu Task<AuthenticationState> k získání ClaimsPrincipal uživatele. Task< AuthenticationState > lze kombinovat s dalšími službami, jako je IAuthorizationService, k vyhodnocení zásad.

V následujícím příkladu:

• Spustí user.Identity.IsAuthenticated kód pro ověřené uživatele (přihlášené).
• Spustí user.IsInRole("admin") kód pro uživatele v roli Správce.
• Spustí (await AuthorizationService.AuthorizeAsync(user, "content-editor")).Succeeded kód pro uživatele, kteří splňují zásady content-editoru.

Aplikace na straně Blazor serveru obsahuje příslušné obory názvů při vytváření ze šablony projektu. V aplikaci na straně Blazor klienta ověřte přítomnost Microsoft.AspNetCore.Authorization komponent nebo v souboru aplikace Microsoft.AspNetCore.Components.Authorization a _Imports.razor obory názvů:

@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)
                {
                    // ...
                }
            }
        }
    }
}

Řešení chyb

Běžné chyby:

• Autorizace vyžaduje kaskádový parametr typu Task<AuthenticationState>. Zvažte použití CascadingAuthenticationState k jeho zajištění.

• Hodnota null je přijata pro authenticationStateTask

Je pravděpodobné, že projekt nebyl vytvořen pomocí šablony na straně Blazor serveru s povoleným ověřováním.

V rozhraní .NET 7 nebo starších obtékání <CascadingAuthenticationState> části stromu uživatelského rozhraní, například kolem Blazor směrovače:

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

V .NET 8 nebo novějších nepoužívejte komponentu CascadingAuthenticationState :

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

Místo toho do kolekce služby v Program souboru přidejte kaskádové stavové služby ověřování:

builder.Services.AddCascadingAuthenticationState();

Komponenta CascadingAuthenticationState (.NET 7 nebo starší) nebo služby poskytované platformou AddCascadingAuthenticationState (.NET 8 nebo novější) poskytujíTask<AuthenticationState>kaskádový parametr, který zase přijímá ze služby injektáže závislostí.AuthenticationStateProvider

Identifikovatelné osobní údaje (PII)

Microsoft používá definici GDPR pro "osobní údaje" (GDPR 4.1), když dokumentace popisuje identifikovatelné osobní údaje (PII).

PII odkazuje na všechny informace týkající se identifikované nebo identifikovatelné fyzické osoby. Identifikovatelná fyzická osoba je osoba, která může být identifikována přímo nebo nepřímo, s některou z následujících možností:

• Název
• Identifikační číslo
• Souřadnice umístění
• Online identifikátor
• Další specifické faktory
  • Fyzické
  • Fyziologický
  • Genetický
  • Duševní (psychická)
  • Hospodářský
  • Kulturní
  • Sociální identity

Další materiály

• Serverové prostředky a Blazor Web App prostředky
  • Rychlý start: Přidání přihlašování účtem Microsoft do webové aplikace ASP.NET Core
  • Rychlý start: Ochrana webového rozhraní API ASP.NET Core pomocí platformy Microsoft identity
  • Konfigurace ASP.NET Core pro práci s proxy servery a nástroji pro vyrovnávání zatížení: Obsahuje pokyny k:
    • Použití middlewaru Forwarded Headers k zachování informací o schématu HTTPS napříč proxy servery a interními sítěmi
    • Další scénáře a případy použití, včetně ruční konfigurace schématu, změn cesty požadavku pro správné směrování požadavků a předávání schématu požadavků pro linuxové proxy servery a proxy servery a jiné než IIS.
• Dokumentace k platformě Microsoftu identity
  • Přehled
  • Protokoly OAuth 2.0 a OpenID Connect na platformě Microsoftu identity
  • Tok autorizačního kódu microsoftu identity a OAuth 2.0
  • Tokeny ID platformy Microsoftu identity
  • Přístupové tokeny platformy Microsoftu identity
• Témata zabezpečení ASP.NET Core
• Konfigurace ověřování Windows v ASP.NET Core
• Sestavení vlastní verze knihovny Authentication.MSAL JavaScript
• Awesome Blazor: Odkazy na komunitní ukázky pro ověřování
• Ověřování a autorizace ASP.NET Core Blazor Hybrid