Authentifizierung und Autorisierung in ASP.NET Core Blazor

In diesem Artikel wird die ASP.NET Core-Unterstützung für die Konfiguration und Verwaltung der Sicherheit in Blazor-Apps beschrieben.

Das Sicherheitsszenario unterscheidet sich je nach Autorisierungscode, der serverseitig und clientseitig in Blazor-Apps ausgeführt wird. Bei Autorisierungscode, der auf dem Server ausgeführt wird, können Autorisierungsprüfungen Zugriffsregeln für Bereiche der App und Komponenten erzwingen. Da clientseitige Codeausführung manipuliert werden kann, ist Autorisierungscode, der auf dem Client ausgeführt wird, nicht vertrauenswürdig, um Zugriffsregeln absolut zu erzwingen oder die Anzeige clientseitiger Inhalte zu steuern.

Autorisierungskonventionen von Razor Pages gelten nicht für routingfähige Razor-Komponenten. Wenn eine nicht routingfähige Razor-Komponente auf einer Seite einer Razor Pages-App eingebettet wird, wirken sich die Autorisierungskonventionen der Seite indirekt auf die Razor-Komponente sowie auf den rest des Seiteninhalts aus.

Sichere Verwaltung vertraulicher Daten und Anmeldeinformationen

Speichern Sie keine geheimen App-Schlüssel, Verbindungszeichenfolge s, Anmeldeinformationen, Kennwörter, persönliche Identifikationsnummern (PINs), privaten .NET/C#-Code oder private Schlüssel/Token im clientseitigen Code, der immer unsicher ist. Clientseitiger Blazor Code sollte über eine sichere Web-API, die Sie steuern, auf sichere Dienste und Datenbanken zugreifen.

In Test-/Staging- und Produktionsumgebungen sollten serverseitiger Blazor Code und Web-APIs sichere Authentifizierungsflüsse verwenden, die die Authentifizierung von Anmeldeinformationen innerhalb von Projektcode- oder Konfigurationsdateien vermeiden. Außerhalb der lokalen Entwicklungstests wird empfohlen, die Verwendung von Umgebungsvariablen zum Speichern vertraulicher Daten zu vermeiden, da Umgebungsvariablen nicht der sicherste Ansatz sind. Für lokale Entwicklungstests wird das Tool "Geheimer Manager" zum Sichern vertraulicher Daten empfohlen. Weitere Informationen finden Sie in den folgenden Ressourcen:

• Sichere Authentifizierungsflüsse (ASP.NET Core-Dokumentation)
• Verwaltete Identitäten für Microsoft Azure-Dienste (dieser Artikel)

Verwenden Sie für clientseitige und serverseitige lokale Entwicklung und Tests das Tool "Geheimer Manager", um vertrauliche Anmeldeinformationen zu sichern.

Verwaltete Identitäten für Microsoft Azure-Dienste

Für Microsoft Azure-Dienste empfehlen wir die Verwendung von verwalteten Identitäten. Verwaltete Identitäten authentifizieren sich sicher bei Azure-Diensten, ohne dass Anmeldedaten im App-Code gespeichert werden müssen. Weitere Informationen finden Sie in den folgenden Ressourcen:

• Was sind verwaltete Identitäten für Azure-Ressourcen? (Dokumentation zu Microsoft Entra)
• Dokumentation zu Azure-Diensten
  • Verwaltete Identitäten in Microsoft Entra für Azure SQL
  • Verwenden verwalteter Identitäten für App Service und Azure Functions

Authentifizierung

Blazor verwendet die vorhandenen ASP.NET Core-Authentifizierungsmechanismen, um die Identität des Benutzers festzustellen. Der genaue Mechanismus hängt davon ab, ob die Blazor-App serverseitig oder clientseitig gehostet wird.

Serverseitige Blazor-Authentifizierung

Serverseitig wird das interaktiv dargestellte Blazor über eine SignalR-Verbindung mit dem Client ausgeführt. Die Authentifizierung in SignalR-basierten Apps wird verarbeitet, wenn die Verbindung hergestellt wird. Die Authentifizierung kann auf einem cookie oder einem anderen Bearertoken basieren, aber die Authentifizierung wird über den SignalR-Hub und vollständig innerhalb der Verbindung verwaltet.

Der integrierte oder benutzerdefinierte Dienst AuthenticationStateProvider ruft die Daten zum Authentifizierungsstatus von HttpContext.User von ASP. NET Core ab. Auf diese Weise lässt sich der Authentifizierungsstatus in bestehende Authentifizierungsmechanismen von ASP.NET Core integrieren.

Weitere Informationen finden Sie unter Sichern von serverseitigen Blazor-Apps in ASP.NET Core:

IHttpContextAccessor/HttpContext in Razor-Komponenten

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

Freigegebener Zustand

Serverseitige Blazor-Apps befinden sich im Serverspeicher, und mehrere App-Sitzungen werden innerhalb desselben Prozesses gehostet. Blazor startet für jede App-Sitzung eine Verbindung mit einem eigenen Containerbereich für Abhängigkeitsinjektion, sodass bereichsbezogene Dienste pro Blazor-Sitzung eindeutig sind.

Sie können zustandsbehaftete Singletondienste in Blazor-Apps verwenden, sofern diese speziell dafür konzipiert sind. Beispielsweise ist die Verwendung eines Singletonspeichercaches akzeptabel, da ein Speichercache einen Schlüssel für den Zugriff auf einen bestimmten Eintrag erfordert. Unter der Annahme, dass Benutzer keine Kontrolle über die Cacheschlüssel besitzen, die mit dem Cache verwendet werden, wird der im Cache gespeicherte Zustand nicht über Verbindungen hinweg weitergegeben.

Eine allgemeine Anleitung zur Zustandsverwaltung finden Sie unter ASP.NET Core Blazor-Zustandsverwaltung.

Clientseitige Blazor-Authentifizierung

In clientseitigen Blazor-Apps können clientseitige Authentifizierungsprüfungen umgangen werden, da der gesamte clientseitige Code von Benutzern geändert werden kann. Dasselbe gilt für alle clientseitigen App-Technologien, darunter JavaScript-SPA-Frameworks und native Apps für jedes Betriebssystem.

Fügen Sie Folgendes hinzu:

• Einen Paketverweis für das Microsoft.AspNetCore.Components.Authorization-NuGet-Paket.

  Hinweis

  Eine Anleitung zum Hinzufügen von Paketen zu .NET-Anwendungen finden Sie in den Artikeln unter Pakete installieren und verwalten unter Workflow für die Paketnutzung (NuGet-Dokumentation). Überprüfen Sie unter NuGet.org, ob die richtige Paketversion verwendet wird.

• Den Namespace Microsoft.AspNetCore.Components.Authorization zur _Imports.razor-Datei der App.

Verwenden Sie zur Authentifizierung den integrierten oder benutzerdefinierten AuthenticationStateProvider-Dienst.

Weitere Informationen zur clientseitigen Authentifizierung finden Sie unter Sichern von ASP.NET Core Blazor WebAssembly.

AuthenticationStateProvider-Dienst

AuthenticationStateProvider wird in der Regel nicht direkt verwendet. Verwenden Sie die später in diesem Artikel beschriebenen Ansätze AuthorizeView-Komponente oder Task<AuthenticationState>. Der Hauptnachteil bei der direkten Verwendung von AuthenticationStateProvider ist, dass die Komponente nicht automatisch benachrichtigt wird, wenn sich die zugrunde liegenden Daten des Authentifizierungsstatus ändern.

Informationen zur Implementierung eines benutzerdefinierten AuthenticationStateProvider finden Sie unter ASP.NET Core-Blazor-Authentifizierungsstatus, das auch eine Anleitung zur Implementierung von Benachrichtigungen über Änderungen des Benutzerauthentifizierungsstatus enthält.

Abrufen der Hauptdaten von Benutzenden

Der AuthenticationStateProvider-Dienst kann die ClaimsPrincipal-Daten des aktuellen Benutzers bereitstellen, wie im folgenden Beispiel gezeigt.

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

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

Wenn user.Identity.IsAuthenticated den Wert true hat und da der Benutzer ein ClaimsPrincipal ist, können Ansprüche aufgezählt und die Mitgliedschaft in Rollen ausgewertet werden.

Weitere Informationen zur Abhängigkeitsinjektion (Dependency Injection, DI) finden Sie unter Abhängigkeitsinjektion in Blazor in ASP.NET Core und Abhängigkeitsinjektion in ASP.NET Core. Weitere Informationen über die Implementierung eines benutzerdefinierten AuthenticationStateProvider finden Sie unter ASP.NET Core Blazor Authentifizierungsstatus.

Verfügbar machen des Authentifizierungsstatus als kaskadierender Parameter

Wenn für die prozedurale Logik Authentifizierungsstatusdaten erforderlich sind, z. B. bei der Ausführung einer vom Benutzer ausgelösten Aktion, rufen Sie die Authentifizierungsstatusdaten ab, indem Sie einen kaskadierenden Parameter vom Typ Task<AuthenticationState> definieren, wie im folgenden Beispiel gezeigt.

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

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

Wenn user.Identity.IsAuthenticated den Wert true hat, können Ansprüche aufgezählt und die Mitgliedschaft in Rollen ausgewertet werden.

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

builder.Services.AddCascadingAuthenticationState();

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

builder.Services.AddAuthorizationCore();

builder.Services.AddOptions();
builder.Services.AddAuthorizationCore();

In einer serverseitigen Blazor-App sind Dienste für Optionen und die Autorisierung bereits vorhanden. Es sind also keine weiteren Schritte erforderlich.

Autorisierung

Nachdem ein Benutzer authentifiziert wurde, werden Autorisierungsregeln angewendet, um zu steuern, welche Funktionen der Benutzer ausführen kann.

In der Regel wird der Zugriff in Abhängigkeit von folgenden Punkten gewährt oder verweigert:

• Ein Benutzer ist authentifiziert (angemeldet).
• Ein Benutzer hat eine Rolle.
• Ein Benutzer hat einen Anspruch.
• Ein Richtlinie wird erfüllt.

Jedes dieser Konzepte entspricht dem einer ASP.NET Core MVC- oder Razor Pages-App. Weitere Informationen zu ASP.NET Core-Sicherheit finden Sie im Artikel unter ASP.NET Core-Sicherheit und -IdentitätIdentity.

AuthorizeView-Komponente

Die AuthorizeView-Komponente zeigt selektiv den Inhalt der Benutzeroberfläche an, abhängig davon, ob der Benutzer dazu berechtigt ist. Dieser Ansatz ist nützlich, wenn Sie Daten für die Person nur anzeigen müssen und nicht ihre Identität in der prozeduralen Logik verwenden müssen.

Die Komponente macht eine Variable context vom Typ AuthenticationState (@context in der Razor-Syntax) verfügbar, mit der Sie auf Informationen über den angemeldeten Benutzer zugreifen können:

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

Mit einer Kombination aus den Parametern Authorized und NotAuthorized können Sie auch andere Inhalte für die Anzeige bereitstellen, wenn der Benutzer nicht autorisiert ist:

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

Obwohl die AuthorizeView Komponente die Sichtbarkeit von Elementen basierend auf dem Autorisierungsstatus des Benutzers steuert, erzwingt sie keine Sicherheit für den Ereignishandler selbst. Im vorherigen Beispiel ist die Methode nur mit einer Schaltfläche verknüpft, die HandleClick für autorisierte Benutzer sichtbar ist, aber nichts verhindert, dass diese Methode von anderen Stellen aus angevoziert wird. Um die Sicherheit auf Methodenebene sicherzustellen, implementieren Sie zusätzliche Autorisierungslogik innerhalb des Handlers selbst oder in der relevanten API.

Der Inhalt von Authorized und NotAuthorized kann beliebige Elemente beinhalten, wie beispielsweise andere interaktive Komponenten.

Autorisierungsbedingungen, wie Rollen oder Richtlinien, die Benutzeroberflächenoptionen oder den Zugriff steuern, werden im Abschnitt Autorisierung behandelt.

Wenn keine Autorisierungsbedingungen angegeben sind, verwendet AuthorizeView eine Standardrichtlinie:

• Authentifizierte (angemeldete) Benutzer werden autorisiert.
• Nicht authentifizierte (abgemeldete) Benutzer werden nicht autorisiert.

Die Komponente AuthorizeView kann in der Komponente NavMenu (Shared/NavMenu.razor) verwendet werden, um eine NavLink-Komponente (NavLink) anzuzeigen. Beachten Sie jedoch, dass bei diesem Ansatz nur das Listenelement aus der gerenderten Ausgabe entfernt wird. Benutzer werden nicht daran gehindert, zur Komponente zu navigieren. Implementieren Sie die Autorisierung separat in der Zielkomponente.

Rollenbasierte und richtlinienbasierte Autorisierung

Die AuthorizeView-Komponente unterstützt die rollenbasierte oder die richtlinienbasierte Autorisierung.

Verwenden Sie für die rollenbasierte Autorisierung den Roles-Parameter. Im folgenden Beispiel muss der Benutzer über einen Rollenanspruch für die Rolle Admin oder Superuser verfügen:

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

Um zu verlangen, dass ein Benutzer sowohl über den Rollenanspruch Admin als auch über den Rollenanspruch Superuser verfügt, schachteln Sie AuthorizeView-Komponenten:

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

Der vorangehende Code richtet einen Context für die innere AuthorizeView-Komponente ein, um einen AuthenticationState-Kontextkonflikt zu verhindern. Auf den AuthenticationState-Kontext wird im äußeren AuthorizeView mit dem Standardansatz für den Zugriff auf den Kontext zugegriffen (@context.User). Auf den Kontext wird im inneren AuthorizeView mit dem benannten innerContext-Kontext (@innerContext.User) zugegriffen.

Weitere Informationen, einschließlich Konfigurationsanleitungen, finden Sie unter Rollenbasierte Autorisierung in ASP.NET Core.

Verwenden Sie für die richtlinienbasierte Autorisierung den Policy Parameter mit einem einzelnen Richtliniennamen:

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

Für den Fall, dass der Benutzer eine von mehreren Richtlinien erfüllen muss, erstellen Sie eine Richtlinie, die bestätigt, dass der Benutzer andere Richtlinien erfüllt.

Für den Fall, dass der Benutzer mehrere Richtlinien gleichzeitig erfüllen muss, setzen Sie einen der folgenden Ansätze um:

• Erstellen Sie eine Richtlinie für AuthorizeView, die bestätigt, dass der Benutzer mehrere andere Richtlinien erfüllt.

• Schachteln Sie die Richtlinien in mehreren AuthorizeView-Komponenten:

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

Die anspruchsbasierte Autorisierung ist ein Sonderfall der richtlinienbasierten Autorisierung. Beispielsweise können Sie eine Richtlinie definieren, die vom Benutzer einen bestimmten Anspruch erfordert. Weitere Informationen finden Sie unter Richtlinienbasierte Autorisierung in ASP.NET Core.

Wenn weder Roles noch Policy angegeben wird, verwendet AuthorizeView die Standardrichtlinie:

• Authentifizierte (angemeldete) Benutzer werden autorisiert.
• Nicht authentifizierte (abgemeldete) Benutzer werden nicht autorisiert.

Da bei .NET-Zeichenfolgenvergleichen die Groß- und Kleinschreibung beachtet wird, wird beim Abgleich von Rollen- und Richtliniennamen ebenfalls die Groß- und Kleinschreibung beachtet. Beispielsweise wird Admin (mit Großbuchstabe A) nicht als dieselbe Rolle wie admin (mit Kleinbuchstabe a) behandelt.

Die Pascal-Schreibweise wird in der Regel für Rollen- und Richtliniennamen (z. B. BillingAdministrator) verwendet, aber die Verwendung der Pascal-Schreibweise ist keine strenge Anforderung. Unterschiedliche Groß-/Kleinschreibungen wie Camel Case, Kebab Case und Snake Case sind zulässig. Die Verwendung von Leerzeichen in Rollen- und Richtliniennamen ist ungewöhnlich, wird aber vom Framework zugelassen. Beispielsweise ist billing administrator ein ungewöhnliches Format für Rollen- oder Richtliniennamen in .NET-Apps. Dennoch ist dies ein gültiger Rollen- oder Richtlinienname.

Während der asynchronen Authentifizierung angezeigter Inhalt

Bei Blazor kann der Authentifizierungsstatus asynchron bestimmt werden. Das primäre Szenario für diesen Ansatz sind clientseitige Blazor-Apps, die eine Anforderung zur Authentifizierung an einen externen Endpunkt stellen.

Während die Authentifizierung läuft, zeigt AuthorizeView keinen Inhalt an. Um Inhalte während der Authentifizierung anzuzeigen, weisen Sie dem Authorizing Parameter Inhalte zu:

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

Dieser Ansatz gilt in der Regel nicht für serverseitige Blazor-Apps. Serverseitige Blazor-Apps kennen den Authentifizierungsstatus, sobald der Status hergestellt ist. Authorizing-Inhalte können zwar in der AuthorizeView-Komponente einer App bereitgestellt werden, der Inhalt wird aber nie angezeigt.

[Authorize]-Attribut

Das [Authorize]-Attribut ist in Razor-Komponenten verfügbar:

@page "/"
@attribute [Authorize]

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

Das [Authorize]-Attribut unterstützt auch die rollenbasierte oder die richtlinienbasierte Autorisierung. Verwenden Sie für die rollenbasierte Autorisierung den Roles-Parameter:

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

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

Verwenden Sie für die richtlinienbasierte Autorisierung den Policy-Parameter:

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

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

Wenn weder Roles noch Policy angegeben wird, verwendet [Authorize] die Standardrichtlinie:

• Authentifizierte (angemeldete) Benutzer werden autorisiert.
• Nicht authentifizierte (abgemeldete) Benutzer werden nicht autorisiert.

Wenn die Benutzerin bzw. der Benutzer nicht autorisiert ist und die App keine Anpassung nicht autorisierter Inhalte mit der Router-Komponente vornimmt, zeigt das Framework automatisch die folgende Fallbackmeldung an:

Not authorized.

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

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

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

Anpassen von unautorisierten Inhalten mit der Router-Komponente

Gemeinsam mit der AuthorizeRouteView-Komponente ermöglicht die Router-Komponente der App, benutzerdefinierten Inhalt anzugeben, wenn:

• Der Benutzer eine [Authorize]-Bedingung nicht erfüllt, die für die Komponente angewendet wird. Das Markup des <NotAuthorized>-Elements wird angezeigt. Das [Authorize]-Attribut wird im Abschnitt [Authorize]-Attribut behandelt.
• Asynchrone Autorisierung wird ausgeführt. Dies bedeutet in der Regel, dass der Benutzer authentifiziert wird. Das Markup des <Authorizing>-Elements wird angezeigt.

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

builder.Services.AddCascadingAuthenticationState();

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

Wenn der Inhalt NotAuthorized nicht angegeben ist, verwendet AuthorizeRouteView die folgende alternative Meldung:

Not authorized.

Eine App, die aus der Blazor WebAssembly-Projektvorlage mit aktivierter Authentifizierung erstellt wird, enthält eine RedirectToLogin-Komponente, die im <NotAuthorized>-Inhalt der Router-Komponente positioniert wird. Wenn ein Benutzer nicht authentifiziert ist (context.User.Identity?.IsAuthenticated != true), leitet die RedirectToLogin-Komponente den Browser zur Authentifizierung an den authentication/login-Endpunkt um. Die Person wird nach der Authentifizierung beim Identitätsanbieter an die angeforderte URL zurückgeleitet.

Prozedurale Logik

Wenn die App zur Überprüfung von Autorisierungsregeln im Rahmen der prozeduralen Logik benötigt wird, verwenden Sie einen kaskadierten Parameter vom Typ Task<AuthenticationState>, um das ClaimsPrincipal des Benutzers abzurufen. Task<AuthenticationState> kann zum Auswerten von Richtlinien mit anderen Diensten kombiniert werden, wie z. B. IAuthorizationService.

Im folgenden Beispiel:

• user.Identity.IsAuthenticated führt Code für authentifizierte (angemeldete) Benutzer aus.
• user.IsInRole("admin") führt Code für Benutzer mit der Rolle „Admin“ aus.
• (await AuthorizationService.AuthorizeAsync(user, "content-editor")).Succeeded führt Code für Benutzer aus, die die Richtlinie „content-editor“ erfüllen.

Eine serverseitige Blazor App enthält die entsprechenden Namespaces, wenn sie aus der Projektvorlage erstellt wird. Überprüfen Sie in einer clientseitigen Blazor-App, ob die Namespaces Microsoft.AspNetCore.Authorization und Microsoft.AspNetCore.Components.Authorization entweder in der Komponente oder in der Datei _Imports.razor der App vorhanden sind:

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

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

Fehlerbehandlung

Häufige Fehler:

• Die Autorisierung erfordert einen kaskadierenden Parameter vom Typ Task<AuthenticationState>. Verwenden Sie CascadingAuthenticationState, um diesen bereitzustellen.

• Für authenticationStateTask wird ein null -Wert empfangen.

Wahrscheinlich wurde das Projekt nicht mit einer serverseitigen Blazor-Vorlage mit aktivierter Authentifizierung erstellt.

Umschließen Sie in .NET 7 oder früher einen Teil der Benutzeroberflächenstruktur mit einem <CascadingAuthenticationState>, zum Beispiel den Blazor-Router:

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

Verwenden Sie in .NET 8 oder höher nicht die CascadingAuthenticationState-Komponente:

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

Fügen Sie stattdessen der Dienstauflistung in der Program-Datei kaskadierende Authentifizierungszustandsdienste hinzu:

builder.Services.AddCascadingAuthenticationState();

Die CascadingAuthenticationState-Komponente (.NET 7 oder früher) oder Dienste, die von AddCascadingAuthenticationState (.NET 8 oder höher) bereitgestellt werden, stellt den >Task<AuthenticationState-Kaskadierungsparameter bereit, der wiederum vom zugrunde liegenden AuthenticationStateProvider-Abhängigkeitserfassungsdienst empfangen wird.

Personenbezogene Informationen (Personally Identifiable Information, PII)

Microsoft verwendet die DSGVO-Definition für „personenbezogene Daten“ (DSGVO 4.1), wenn dokumentation informationen zu personenbezogenen Informationen (Personally Identifiable Information, PII) erläutert.

PII bezieht sich auf alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. Eine identifizierbare natürliche Person ist eine Person, die direkt oder indirekt mit einer der folgenden Identifiziert werden kann:

• Name
• Identifikationsnummer
• Standortkoordinaten
• Onlinebezeichner
• Andere spezifische Faktoren
  • Physisch
  • Physiologisch
  • Genetisch
  • Mental (psychologisch)
  • Wirtschaftlichen
  • Kultur
  • Soziale identity

Zusätzliche Ressourcen