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.

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 na stránce Razor aplikace Pages vložena nesměrovatelná Razor komponenta, zásady autorizace stránky nepřímo ovlivňují Razor komponentu spolu s rest 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 ASP.NET Přehled formulářů CoreBlazor.

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 Volání webového rozhraní API z aplikace ASP.NET CoreBlazor.

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í

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.

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

Interaktivně vykreslená serverová strana Blazor funguje přes SignalR připojení s klientem. Ověřování v aplikacích založených na SignalR se zpracovává při navázání tohoto připojení. 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.

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 Zabezpečené ASP.NET aplikace na straně Blazor serveru.

IHttpContextAccessor/HttpContext v Razor součástech

IHttpContextAccessor musí se vyhnout interaktivnímu vykreslování, protože není k dispozici platný HttpContext .

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 Další scénáře zabezpečení na straně serveru ASP.NET CoreBlazor.

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.

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 ASP.NET Stavu ověřování jádraBlazor, 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<AuthorizeRouteViewAuthenticationState> 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="SecureMethod">Authorized Only Button</button></p>
    </Authorized>
    <NotAuthorized>
        <p>You're not authorized.</p>
    </NotAuthorized>
</AuthorizeView>

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

Výchozí obslužnou rutina události pro autorizovaný element, jako je například metoda SecureMethod elementu <button> v předchozím příkladu, může vyvolat pouze autorizovaný uživatel.

RazorBlazor 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 ASP.NET režimy vykreslování coreBlazor.

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 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ž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 Admin Superuser 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í AuthorizeView komponentu, Context 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 jednou zásadou:

<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 AuthorizationOptions vytvoří zásady EditUser 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 ASP.NET režimy vykreslování coreBlazor.

<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 _Imports.razor a Microsoft.AspNetCore.Components.Authorization 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<AuthenticationStatekaská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

• 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