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í identity uživatele. 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 serverové vykreslování (SSR) pro kontrolu autorizace a prosazování pravidel.

Razor Zásady autorizace stránek se nevztahují na směrovatelné Razor komponenty. Pokud je nesměrovatelná komponenta , vložena na stránku aplikace Pages, zásady autorizace stránky nepřímo ovlivňují komponentu spolu se zbytkem obsahu stránky.

Note

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

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

Neukládejte tajné kódy aplikací, připojovací řetězce, přihlašovací údaje, hesla, osobní identifikační čísla (PIN), privátní kód .NET/C# ani 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.

Ve testovacích, přípravných a produkčních prostředích by serverový kód a webová rozhraní API měly používat toky zabezpečeného ověřování, které se vyhýbají uchovávání přihlašovacích údajů v projektovém kódu 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 ochrany proti padělání

Šablona Blazor :

• Automaticky přidá služby proti falšování, když je AddRazorComponents volána v Program souboru.
• Přidá middleware antiforgery voláním UseAntiforgery ve svém kanálu zpracování požadavků v Program souboru a vyžaduje antiforgery ochranu koncového bodu, aby zmírnil hrozby pro padělání požadavků mezi weby (CSRF/XSRF). UseAntiforgery je voláno po UseHttpsRedirection. Volání UseAntiforgery musí být umístěno po voláních do UseAuthentication a UseAuthorization, pokud jsou k dispozici.

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 Přehled formulářů ASP.NET CoreBlazor.

Služba AntiforgeryStateProvider poskytuje přístup k tokenu proti padělání přidruženému k aktuální relaci. Vložte službu a zavolejte její GetAntiforgeryToken() metodu k získání aktuálního AntiforgeryRequestToken. Další informace najdete v tématu Volání webového rozhraní API z aplikace ASP.NET CoreBlazor.

Blazor ukládá tokeny spojené se žádostí do stavu komponenty, což zaručuje, že tokeny proti padělání jsou k dispozici interaktivním komponentám, i když nemají přístup k této žádosti.

Note

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:

• Zabránit útokům 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 tématech o 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ženo na cookie nebo jiném bearer tokenu, ale ověřování je spravováno prostřednictvím SignalR hubu 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í zachytit uživatele pro vlastní služby nebo potřeby nebo reagovat na aktualizace uživatele, viz ASP.NET Core na straně serveru 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 generují nové požadavky HTTP s soubory cookie. Během navigačních událostí se kontroluje autentizace. Soubory cookie nejsou zapojeny. 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.

Important

Nedoporučuje se implementovat vlastní NavigationManager pro ověřování a validaci při navigaci. Pokud aplikace musí během navigace provádět vlastní logiku autentizačního stavu, použijte vlastní AuthenticationStateProvider.

Note

Příklady kódu v tomto článku používají referenční typy s možnou hodnotou null (NRT) a statickou analýzu stavu null kompilátoru .NET, které jsou podporovány v ASP.NET Core ve verzích .NET 6 nebo novější. Při cílení na .NET 5 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.

Sdílený stav

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

Warning

Nedoporučujeme, aby aplikace na stejném serveru sdílely stav pomocí singletonových služeb, pokud není věnována mimořádná péče, protože to může představovat ohrožení zabezpečení, například únik stavu uživatele napříč instancemi.

Stavové singleton služby můžete v Blazor aplikacích používat, pokud jsou speciálně navrženy pro tento účel. 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 Přehled správy základního stavu.

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

Ve testovacích, přípravných a produkčních prostředích by serverový kód a webová rozhraní API měly používat toky zabezpečeného ověřování, které se vyhýbají uchovávání přihlašovacích údajů v projektovém kódu 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 aplikaci na straně Blazor serveru 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}

Note

Ú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í	Description
None (výchozí)	Bez ověřování
Individual	Uživatelé, kteří jsou uloženi v aplikaci používající ASP.NET Core Identity

Další informace naleznete v příručce .NET v části dotnet new.

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

Note

Ú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í	Description
None (výchozí)	Bez ověřování
Individual	Uživatelé, kteří jsou uloženi v aplikaci používající ASP.NET Core Identity

Další informace:

• dotnet new Viz příkaz v příručce .NET.

• 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 je zástupný symbol {PROJECT TEMPLATE} šablonou projektu.

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

Blazor podporuje vytváření úplného uživatelského rozhraní založeného na BlazorIdentity, když zvolíte možnost ověřování pro jednotlivé účty.

Šablona Blazor Web App tvoří Identity kód 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 komponenty rámce Blazor, přejděte k nim ve složkách Identity a Pages ve složce Shared serverového projektu Components/Account.

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 v projektech serveru a klienta .Client pro předání stavu ověření uživatele do prohlížeče. Projekt serveru volá AddAuthenticationStateSerialization, zatímco projekt klienta volá AddAuthenticationStateDeserialization. Ověřování na serveru namísto klienta umožňuje aplikaci mít přístup ke stavu ověřování během předběžného vykreslování a před inicializací prostředí .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í Interactive Server (IdentityRevalidatingAuthenticationStateProviderComponents/Account/IdentityRevalidatingAuthenticationStateProvider.cs) v serverovém projektu šablony Blazor Web App projektu (dotnet/aspnetcore úložiště GitHub) je serverová strana AuthenticationStateProvider, která znovu ověřuje razítko zabezpečení pro připojeného uživatele každých 30 minut, pokud 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.

Pro popis toho, jak jsou globální interaktivní režimy vykreslování aplikovány na komponenty, které nejsou Identity, a současně zajištěno statické SSR pro komponenty Identity, najdete v tématu ASP.NET Core režimy vykreslováníBlazor.

Další informace o přetrvání předrenderovaného stavu najdete v tématu ASP.NET Core přetrvání předrenderovaného stavu.

Note

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

Tato část se vztahuje na Blazor Web App, které přijímají:

• 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. Poskytovatel autentizačního stavu na straně klienta se pouze stará o zrcadlení uživatelského stavu ověření. Příklady, jak toho dosáhnout použitím zprostředkovatelů stavu ověřování, jsou demonstrovány šablonou Blazor Web App projektu a popsány níže.

V souboru projektu na straně serveru volejte , který serializuje vrácené serverovým pomocí služby trvalého stavu komponenty ().

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

Rozhraní API serializuje pouze serverové jméno a role pro přístup v prohlížeči. Pokud chcete zahrnout všechny nároky, nastavte SerializeAllClaims na true ve volání AddAuthenticationStateSerialization na straně serveru:

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

V souboru projektu klienta (.Client) volejte Program, což přidá AddAuthenticationStateDeserialization, kde je AuthenticationStateProvider deserializován ze serveru pomocí AuthenticationState a služby pro trvalý stav komponent (AuthenticationStateData). V projektu serveru by mělo být odpovídající volání na AddAuthenticationStateSerialization.

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

Další nároky a tokeny od externích poskytovatelů

Pokud chcete ukládat další deklarace identity od externích zprostředkovatelů, přečtěte si téma 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žte AuthenticationStateProvider pro služby 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 v rámci služby omezené na komponentu, vložte do komponenty AuthenticationStateProvider 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 aplikuje a předává se ExampleService.ExampleMethod.
• ExampleService je vyřešen pomocí OwningComponentBase.ScopedServices a GetRequiredService, což 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);
    }
}

Pro více informací si přečtěte pokyny na ve vkládání závislostí prostřednictvím ASP.NET Core.

Neautorizovaný obsah zobrazen během předkreslování s vlastním AuthenticationStateProvider

Abyste se vyhnuli zobrazení neoprávněného obsahu, například obsahu v komponentě , při předběžném vykreslování s vlastním , přijměte 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)

  Note

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

  Note

  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 na šabloně projektu Blazor Web App 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 například na režimy vykreslování ASP.NET CoreBlazor.

• Před spuštěním aplikace ověřte uživatele na serveru: Pokud chcete tento přístup přijmout, musí aplikace reagovat na počáteční uživatelský požadavek přihlašovací stránkou nebo zobrazením založeným na Identity a zabránit jakýmkoli požadavkům na koncové body Blazor až do jejich ověření. 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í určeno pro ukládání obecného stavu 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í využívá stejný mechanismus ASP.NET Core Identity jako aplikace MVC a Pages. Uživatelský stav uložený pro ASP.NET Core Identity se přenáší do Blazor bez nutnosti přidání dalšího kódu do aplikace. Postupujte podle pokynů v článcích a kurzech ASP.NET Core Identity, aby se funkce Identity projevily v částech aplikace Blazor.

Pokyny k obecné správě stavu mimo ASP.NET Core Identitynajdete v přehledu správy stavu ASP.NET CoreBlazor.

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.

Note

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

V aplikacích generovaných ze Blazor šablony projektu pro .NET 8 nebo novější upravte výchozí 30minutový interval opětovného ověření v IdentityRevalidatingAuthenticationStateProvider. V dřívějších verzích než .NET 8 upravte interval v RevalidatingIdentityAuthenticationStateProvider. Následující příklad zkracuje interval na 20 minut:

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

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

Na serverové straně Blazor se uchovává stav autentizace uživatele po celou dobu životnosti okruhu, i napříč kartami prohlížeče. Pokud chcete uživatele automaticky odhlásit ve všech kartách prohlížeče poté, co se uživatel odhlásí na jedné z nich, musíte implementovat RevalidatingServerAuthenticationStateProvider (referenční zdroj) s krátkým RevalidationInterval.

Note

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 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 adresy URL dočasného přesměrování

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

Pomocí možnosti RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration můžete získat nebo nastavit dobu platnosti ochrany dat ASP.NET Core pro dočasné URL přesměrování generované renderováním na straně Blazor 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.

  Note

  Pokyny k přidávání balíčků do aplikací .NET najdete v článcích o instalaci a správě balíčků v pracovním postupu Používání balíčků (dokumentace NuGet). Ověřte správné verze balíčků v NuGet.org.

• Nastavení oboru názvů Microsoft.AspNetCore.Components.Authorization pro soubor _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.

Zabezpečte data v Blazor Web Apps pomocí interaktivního automatického vykreslování.

Blazor Web App Když přijme vykreslování na straně serveru (SSR) a vykreslování na straně klienta (CSR) pro komponenty nebo celou aplikaci, která určuje režim interaktivního automatického vykreslování, autorizace pro přístup k komponentám a datům se použije na dvou místech. Komponenta při vykreslení na serveru omezuje přístup k sobě samé (a ke všem datům, která získává) na základě autorizačního atributu v definičním souboru komponenty (@attribute [Authorize]). Při vykreslení komponenty na klientovi je přístup k datům omezen prostřednictvím koncových bodů webového rozhraní API serveru, které jsou volány z klienta. Při zabezpečení přístupu k datům v obou umístěních je potřeba věnovat pozornost, aby se zabránilo nesprávnému přístupu k datům.

Představte si následující scénář, ve kterém komponenta zobrazuje zabezpečená data o počasí. Ukázky některých z následujících přístupů je možné vyhodnotit a otestovat pomocí BlazorWebAppEntra/BlazorWebAppEntraBffukázek (.NET 9 nebo novějších) neboBlazorWebAppOidc/BlazorWebAppOidcBffukázek (.NET 8 nebo novější) v Blazor úložišti GitHubu () ukázek (dotnet/blazor-samples) (jak stáhnout).

Projekt klienta udržuje třídu WeatherForecast, která uchovává data o počasí:

public sealed class WeatherForecast(DateOnly date, int temperatureC, string summary)
{
    public DateOnly Date { get; set; } = date;
    public int TemperatureC { get; set; } = temperatureC;
    public string? Summary { get; set; } = summary;
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
}

Rozhraní klientského projektu IWeatherForecaster definuje metodu GetWeatherForecastAsync pro získání dat o počasí:

public interface IWeatherForecaster
{
    Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync();
}

Služba ClientWeatherForecaster implementuje IWeatherForecaster v rámci projektu klienta. Metoda GetWeatherForecastAsync volá webové rozhraní API v serverovém projektu na koncovém bodě /weather-forecast pro data o počasí.

internal sealed class ClientWeatherForecaster(HttpClient httpClient) 
    : IWeatherForecaster
{
    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync() =>
        await httpClient.GetFromJsonAsync<WeatherForecast[]>("/weather-forecast") ??
            throw new IOException("No weather forecast!");
}

Klientský projekt udržuje Weather komponentu, která:

• Vynucuje autorizaci pomocí atributu[Authorize].
• Používá službu Stavu trvalých komponent (PersistentComponentState) k zachování dat předpovědi počasí, když komponenta přejde ze statického na interaktivní SSR na serveru. Další informace najdete v tématu ASP.NET Core Blazor trvalost stavu předrenderování.

@page "/weather"
@using Microsoft.AspNetCore.Authorization
@using BlazorWebAppEntra.Client.Weather
@attribute [Authorize]
@inject IWeatherForecaster WeatherForecaster

<PageTitle>Weather</PageTitle>

<h1>Weather</h1>

<p>This component demonstrates showing data.</p>

@if (Forecasts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Date</th>
                <th aria-label="Temperature in Celsius">Temp. (C)</th>
                <th aria-label="Temperature in Fahrenheit">Temp. (F)</th>
                <th>Summary</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var forecast in Forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>
    </table>
}

@code {
    [PersistentState]
    public IEnumerable<WeatherForecast>? Forecasts { get; set; }

    protected override async Task OnInitializedAsync()
    {
        Forecasts ??= await WeatherForecaster.GetWeatherForecastAsync();
    }
}

Serverový projekt implementuje IWeatherForecaster jako ServerWeatherForecaster, který generuje a vrací data o počasí prostřednictvím své GetWeatherForecastAsync metody:

internal sealed class ServerWeatherForecaster() : IWeatherForecaster
{
    public readonly string[] summaries =
    [
        "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", 
        "Sweltering", "Scorching"
    ];

    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync()
    {
        // Simulate asynchronous loading to demonstrate streaming rendering
        await Task.Delay(500);

        return Enumerable.Range(1, 5).Select(index =>
            new WeatherForecast
            (
                DateOnly.FromDateTime(DateTime.Now.AddDays(index)),
                Random.Shared.Next(-20, 55),
                summaries[Random.Shared.Next(summaries.Length)]
            ))
        .ToArray();
    }
}

Pokud aplikace musí volat externí webové rozhraní API pro získání dat o počasí, můžete vložit klienta HTTP (HttpClient) pro vyžádání dat:

internal sealed class ServerWeatherForecaster(HttpClient httpClient, 
    IHttpContextAccessor httpContextAccessor) : IWeatherForecaster
{
    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync()
    {
        var httpContext = httpContextAccessor.HttpContext ??
            throw new InvalidOperationException("No HttpContext!");
        var accessToken = await httpContext.GetTokenAsync("access_token") ??
            throw new InvalidOperationException("No access_token was saved");
        using var request = 
            new HttpRequestMessage(HttpMethod.Get, "/weather-forecast");
        request.Headers.Authorization = new("Bearer", accessToken);
        using var response = await httpClient.SendAsync(request);
        response.EnsureSuccessStatusCode();

        return await response.Content.ReadFromJsonAsync<WeatherForecast[]>() ??
            throw new IOException("No weather forecast!");
    }
}

V dalším přístupu můžete vložit objekt pro vytváření klienta HTTP (IHttpClientFactory) do ServerWeatherForecaster externího webového rozhraní API a volat ho pomocí pojmenovaného klienta HTTP s obslužnou rutinou tokenu. Další informace najdete v tématu Volání webového rozhraní API z aplikace ASP.NET CoreBlazor.

Pokud aplikace používá platformu Microsoft Identity Platform s webovými balíčky Microsoftu Identity pro Microsoft Entra ID (viz volání webového rozhraní API z aplikace ASP.NET CoreBlazor), ukazuje následující ServerWeatherForecaster příklad volání externího webového rozhraní API. Přístupový token se automaticky připojí k požadavku.

internal sealed class ServerWeatherForecaster(IDownstreamApi downstreamApi) : IWeatherForecaster
{
    public async Task<IEnumerable<WeatherForecast>> GetWeatherForecastAsync()
    {
        using var response = await downstreamApi.CallApiForUserAsync("DownstreamApi",
            options =>
            {
                options.RelativePath = "/weather-forecast";
            });

        return await response.Content.ReadFromJsonAsync<WeatherForecast[]>() ??
            throw new IOException("No weather forecast!");
    }
}

Bez ohledu na přístup použitý ServerWeatherForecaster k získávání dat udržuje serverový projekt zabezpečený koncový bod webového rozhraní API pro volání klientských dat o počasí. Výsledkem tohoto koncového bodu je ServerWeatherForecaster.GetWeatherForecastAsync volání na serveru:

app.MapGet("/weather-forecast", (
    [FromServices] IWeatherForecaster WeatherForecaster) =>
{
    return WeatherForecaster.GetWeatherForecastAsync();
}).RequireAuthorization();

Při použití předchozího přístupu existují dva systémy, které uživatelům poskytují zabezpečená data o počasí:

• Weather Při vykreslení komponenty na serveruServerWeatherForecaster se metoda služby GetWeatherForecastAsync používá přímo k získání dat o počasí. Zabezpečení dat je vynuceno atributem komponenty[Authorize]. Stručně řečeno, komponenta vynucuje zabezpečení dat o počasí.
• Když se komponenta Weathervykreslí na klientovi, ClientWeatherForecaster služba se použije k volání webového rozhraní API do zabezpečeného /weather-forecast koncového bodu, který použije metodu RequireAuthorization rozšíření. Pokud má uživatel oprávnění pro přístup k datům o počasí, koncový bod používá službu ServerWeatherForecaster k volání GetWeatherForecastAsync. Data se vrátí klientovi. Stručně řečeno, zabezpečení dat o počasí vynucuje koncový bod webového rozhraní API serverové aplikace.

Předchozí přístup funguje dobře, když požadavky na zabezpečení webového rozhraní API odpovídají požadavkům na zabezpečení komponenty. Stejné zásady autorizace se dají použít například pro koncový bod webového rozhraní API i pro komponentu.

Složité scénáře vyžadují další plánování a implementaci. Například serverové webové rozhraní API, které má více volajících s různými přístupovými oprávněními, vyžaduje sofistikovanější zásady autorizace, jednu nebo více dalších zásad nebo další koncové body s různými požadavky na přístup.

Při sestavování zabezpečení aplikací, které přijímají interaktivní automatické vykreslování, mějte na paměti, že zabezpečení implementované pro koncové body webového rozhraní API serveru nezabezpečí implementaci služby serveru, která se používá při vykreslení komponenty na serveru a přistupuje k datům prostřednictvím služby. Pečlivě zvažte rozdíl mezi přístupem k datům na serveru během SSR a přístupem k datům v požadavku klientského webového rozhraní API během csr. Strategicky použijte zabezpečení, abyste se vyhnuli nesprávnému přístupu k datům.

Příklady v Blazor ukázkovém úložišti GitHub () (dotnet/blazor-samplespostup stažení), které ukazují přístup popsaný v této části:

• BlazorWebAppOidc
• BlazorWebAppOidcBff
• BlazorWebAppEntra
• BlazorWebAppEntraBff

AuthenticationStateProvider služba

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 metody 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 AuthenticationStateProvider naleznete v tématu ASP.NET Core Blazor stavu ověřování, který obsahuje pokyny k implementaci oznámení o změnách stavu ověřování uživatelů.

Získání údajů o nárocích 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 vrací uživatelské nároky (claims) pro zobrazení v uživatelském rozhraní.
• Řádek, který získá příjmení uživatele (surname), volá ClaimsPrincipal.FindAll s predikátem pro filtrování uživatelských nároků.

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

Další informace o dependency injection (DI) a službách najdete v tématu injektáž závislostí v ASP.NET Core Blazor a Dependency Injection v ASP.NET Core. Informace o tom, jak implementovat vlastní AuthenticationStateProvider, najdete v tématu ASP.NET Core Blazor 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.";
            }
        }
    }
}

Lze vyčíslit nároky a vyhodnotit členství v rolích, pokud user.Identity.IsAuthenticated je true.

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

Když vytvoříte Blazor aplikaci z jedné ze Blazor projektových šablon s povoleným ověřováním, aplikace zahrnuje AuthorizeRouteView a volání AddCascadingAuthenticationState, jak je ukázáno v následujícím příkladu. Klientská Blazor aplikace obsahuje i požadované registrace služeb. Další informace jsou uvedeny v části Upravit neoprávněný obsah pomocí komponenty Router.

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

V souboru Program zaregistrujte služby kaskádového stavu 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.

Authorization

Po ověření uživatele se autorizační pravidla použijí 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á nárok.
• Tato zásada je 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 v části ASP.NET Core Security a Identity.

AuthorizeView součást

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 zobrazit data jenom pro uživatele a nemusíte v procedurální logice používat identitu uživatele.

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 součásti Blazor Web App nikdy nezobrazují obsah <NotAuthorized>, pokud autorizace selže na straně serveru během statického serverového vykreslování (statické SSR). Na serverové straně ASP.NET Core kanál zpracovává autorizaci na serveru. Použijte techniky na straně serveru, například konfiguraci LoginPath pro zpracování neautorizovaných požadavků. Další informace najdete v tématu ASP.NET Core režimy vykreslováníBlazor.

Warning

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 Volání webového rozhraní API z aplikace ASP.NET Core Blazor a další scénáře zabezpečení ASP.NET CoreBlazor WebAssembly.

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živatelé nejsou oprávněni.

Komponentu AuthorizeView lze použít v komponentě NavMenu (Shared/NavMenu.razor) k zobrazení NavLink komponenty (NavLink), ale všimněte si, že tento přístup odebere položku seznamu pouze 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ákladě zásad .

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 Admin nebo Superuser.

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

Pokud chcete, aby měl uživatel nároky na roli Admin a Superuser, vnořte komponenty 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>

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

Další informace, včetně pokynů ke konfiguraci, najdete v tématu Autorizace na základě role 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řte zásady 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ě nároků. 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 založená na zásadách v ASP.NET Core.

Pokud jsou obě Roles i Policy nastavené, autorizace proběhne úspěšně pouze v případě, že jsou splněny obě podmínky. To znamená, že uživatel musí patřit alespoň do jedné ze zadaných rolí a splňovat požadavky definované zásadou.

Pokud není zadán ani Roles ani Policy, AuthorizeView použije výchozí zásadu.

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

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

Pascal case se obvykle používá pro názvy rolí a politik (například BillingAdministrator), ale použití Pascal case není striktním požadavkem. 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 v rámci 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. Serverové Blazor aplikace znají stav ověřování, jakmile je tento stav vytvořen. 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.

Important

Používejte [Authorize] pouze na @page komponenty dosažené přes Blazor směrovač. Autorizace se provádí pouze jako aspekt směrování, nikoli 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 na základě rolí nebo zásad. 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>

Pokud není zadán ani Roles ani Policy, [Authorize] použije výchozí zásadu.

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

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ů

Chcete-li autorizovat uživatele k prostředkům, předejte údaje o směrování požadavku do parametru Resource v rámci AuthorizeRouteView.

Router.Found V obsahu požadované trasy:

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

Další informace o předávání a použití dat stavu autorizace v procedurální logice najdete v části Zveřejnění stavu ověřování jako kaskádové části parametru .

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

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

• Určete, zda existuje směrovací hodnota 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á zdroj na /users/{id}/edit parametr trasy pro identifikátor uživatele ({id}). Tento komponent využívá předchozí zásady autorizace EditUser k určení, zda hodnota trasy id začíná 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ůsobte neoprávněný obsah pomocí komponenty Router

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

• Uživatel nesplní podmínku [Authorize] aplikovanou na komponentu. Zobrazuje se značka elementu <NotAuthorized>. Atribut [Authorize] je popsaný v části atributu[Authorize].
• Probíhá asynchronní autorizace, což obvykle znamená, že probíhá proces ověřování uživatele. Zobrazuje se značka elementu <Authorizing>.

Important

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ů zcela probíhá prostřednictvím kanálu middlewaru ASP.NET Core a Razor komponenty se nevykreslují vůbec pro neautorizované nebo chybné požadavky. Použijte techniky na straně serveru ke zpracování neoprávněných a chybných požadavků během statického SSR. Další informace najdete v tématu ASP.NET Core režimy vykreslováníBlazor.

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

Note

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

builder.Services.AddCascadingAuthenticationState();

V případě, že obsah NotAuthorized není uveden, AuthorizeRouteView použije následující záložní zprávu.

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í. Po ověření u zprostředkovatele identity se uživatel 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 autentikované (přihlášené) uživatele.
• Spustí user.IsInRole("admin") kód pro uživatele s rolí Správce.
• Služba (await AuthorizationService.AuthorizeAsync(user, "content-editor")).Succeeded provádí kód pro uživatele, kteří splňují zásady "editora obsahu".

Serverová Blazor aplikace obsahuje příslušné obory názvů vytvořené ze šablony projektu. V aplikaci na straně klienta Blazor ověřte přítomnost oborů názvů Microsoft.AspNetCore.Authorization a Microsoft.AspNetCore.Components.Authorization buď v komponentě, nebo v souboru aplikace _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)
                {
                    // ...
                }
            }
        }
    }
}

Ř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í.

• null hodnota se přijímá pro authenticationStateTask

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

V .NET 7 nebo starších verzích rozhraní obtočte <CascadingAuthenticationState> kolem čá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 přidejte do kolekce služeb v souboru Program kaskádové služby stavu ověřování:

builder.Services.AddCascadingAuthenticationState();

Komponenta CascadingAuthenticationState (.NET 7 nebo starší) nebo služby poskytované AddCascadingAuthenticationState (.NET 8 nebo novější) dodávají kaskádový parametr Task<AuthenticationState>, který je přijímán ze služby pro injektování 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í:

• Name
• Identifikační číslo
• Souřadnice umístění
• Online identifikátor
• Další specifické faktory
  • Physical
  • Physiological
  • Genetic
  • Duševní (psychická)
  • Economic
  • Cultural
  • Sociální identita

Dodatečné zdroje

• Prostředky na straně serveru a Blazor Web App zdroje
  • Rychlý start: Přidání přihlášení pomocí Microsoftu do webové aplikace ASP.NET Core
  • Rychlý start: Ochrana webového rozhraní API ASP.NET Core pomocí platformy Microsoft Identity Platform
  • 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ě manuální 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é a jiné než IIS reverzní proxy servery.
• Dokumentace k platformě Microsoft Identity Platform
  • Overview
  • Protokoly OAuth 2.0 a OpenID Connect na platformě Microsoft Identity Platform
  • Platforma Microsoft Identity a tok autorizačního kódu OAuth 2.0
  • Tokeny ID platformy Microsoft Identity Platform
  • Přístupové tokeny platformy Microsoft Identity Platform
• Témata týkající se zabezpečení ASP.NET Core
• Konfigurace ověřování systému Windows v ASP.NET Core
• IHttpContextAccessor/HttpContext v aplikacích ASP.NET Core Blazor
• Vytvoření vlastní verze knihovny Authentication.MSAL JavaScript
• Skvělé Blazor: Komunitní vzorové odkazy na ověřování
• ověřování a autorizace ASP.NET Core Blazor Hybrid