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.

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.

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.

Wenn die Erzwingung von Autorisierungsregelen gewährleistet sein muss, implementieren Sie keine Autorisierungsprüfungen im clientseitigen Code. Erstellen Sie eine Blazor Web App, die nur auf serverseitigem Rendering (SSR) für Autorisierungsprüfungen und die Regelerzwingung basiert.

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.

Hinweis

Die Codebeispiele in diesem Artikel verwenden Nullwerte zulassende Verweistypen (Nullable Reference Types, NRTs) und die statische Analyse des NULL-Zustands des .NET-Compilers, die in ASP.NET Core in .NET 6 oder höher unterstützt werden. Entfernen Sie bei ASP.NET Core 5.0 oder früher die NULL-Typbezeichnung (?) aus den Beispielen in diesem Artikel.

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

Unterstützung des Schutzes vor Fälschung

Die Blazor-Vorlage:

• Fügt Antiforgerydienste automatisch hinzu, wenn AddRazorComponents in der Program-Datei aufgerufen wird.
• Fügt Middleware für Fälschungsschutz durch den Aufruf von UseAntiforgery in seiner Anforderungsverarbeitungspipeline in der Program-Datei hinzu und erfordert einen Fäschlungsschutz am Endpunkt, um die Bedrohungen durch websiteübergreifende Anforderungsfälschung (CSRF/XSRF) abzuschwächen. UseAntiforgery wird nach UseHttpsRedirectionaufgerufen. Ein Anruf muss UseAntiforgery nach anrufen, sofern vorhanden, an UseAuthentication und UseAuthorization.

Die AntiforgeryToken-Komponente rendert ein Token zum Schutz gegen Fälschungen als ausgeblendetes Feld. Diese Komponente wird automatisch hinzugefügt, um Instanzen (EditForm) zu bilden. Weitere Informationen finden Sie unter Übersicht über ASP.NET Core Blazor Formulare.

Der AntiforgeryStateProvider-Dienst bietet Zugriff auf ein Token zum Schutz vor Fälschungen, das der aktuellen Sitzung zugeordnet ist. Fügen Sie den Dienst ein, und rufen Sie die GetAntiforgeryToken()-Methode auf, um die aktuelle AntiforgeryRequestToken abzurufen. Weitere Informationen finden Sie unter Aufrufen einer Web-API über eine ASP.NET Core Blazor-App.

Blazor speichert Anforderungstoken im Komponentenstatus, wodurch sichergestellt wird, dass Token zum Schutz vor Fälschungen für interaktive Komponenten verfügbar sind, auch wenn sie keinen Zugriff auf die Anforderung haben.

Hinweis

Antiforgery-Entschärfung ist nur erforderlich, wenn Formulardaten an den Server übermittelt werden, die als application/x-www-form-urlencoded, multipart/form-dataoder text/plain da dies die einzigen gültigen Formularenctypessind.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Verhindern von CSRF-Angriffen in ASP.NET Core: Dieser Artikel ist der primäre ASP.NET Core-Artikel zum Thema, der für serverseitige Blazor Server, das Serverprojekt von Blazor Web Apps und die Blazor-Integration mit MVC/Razor-Seiten gilt.
• Übersicht über ASP.NET Core Blazor-Formulare: Im Abschnitt Antiforgeryunterstützung dieses Artikels werden Blazor-Formulare für Antiforgeryunterstützung behandelt.

Serverseitige Blazor-Authentifizierung

Das Schützen von serverseitigen Blazor-Apps funktioniert genau wie bei ASP.NET Core-Apps. Weitere Informationen finden Sie in den Artikeln unter Sicherheitsaspekte für ASP.NET Core.

Der Authentifizierungskontext wird nur beim Starten der App eingerichtet. Dies ist der Zeitpunkt, an dem die App zuerst eine Verbindung mit dem WebSocket über eine SignalR Verbindung mit dem Client herstellt. 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 Authentifizierungskontext wird für die Lebensdauer der Verbindung beibehalten. Apps überprüfen den Authentifizierungsstatus der Benutzenden regelmäßig alle 30 Minuten.

Wenn die App Benutzer für benutzerdefinierte Dienste erfassen oder auf Updates für den Benutzer reagieren muss, lesen Sie ASP.NET core serverseitigen und Blazor Web App zusätzlichen Sicherheitsszenarien.

Blazor unterscheidet sich von herkömmlichen, servergerenderten Webanwendungen, die bei jeder Seitennavigation neue HTTP-Anfragen mit Cookies stellen. Die Authentifizierung wird bei Navigationsereignissen überprüft. Cookies sind jedoch nicht beteiligt. Cookies werden nur gesendet, wenn eine HTTP-Anforderung an einen Server erfolgt, was nicht der Fall ist, wenn die Person in einer Blazor-App navigiert. Während der Navigation wird der Authentifizierungsstatus des Benutzers innerhalb der Blazor-Verbindung überprüft, den Sie mithilfe der RevalidatingAuthenticationStateProvider-Abstraktion jederzeit auf dem Server aktualisieren können.

Wichtig

Das Implementieren eines benutzerdefinierten NavigationManager zum Erzielen der Authentifizierungsvalidierung während der Navigation wird nicht empfohlen. Wenn die App während der Navigation benutzerdefinierte Authentifizierungsstatuslogik ausführen muss, verwenden Sie einen benutzerdefinierten AuthenticationStateProvider.

Hinweis

Die Codebeispiele in diesem Artikel verwenden Nullwerte zulassende Verweistypen (Nullable Reference Types, NRTs) und die statische Analyse des NULL-Zustands des .NET-Compilers, die in ASP.NET Core in .NET 6 oder höher unterstützt werden. Entfernen Sie bei ASP.NET Core 5.0 oder früher die NULL-Typbezeichnung (?) aus den Beispielen in diesem Artikel.

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 zur serverseitigen Authentifizierung finden Sie unter ASP.NET Kernauthentifizierung Blazor und Autorisierung.

IHttpContextAccessor/HttpContext in Razor-Komponenten

IHttpContextAccessor muss mit interaktivem Rendering vermieden werden, da kein gültiger HttpContext verfügbar ist.

IHttpContextAccessor kann für Komponenten verwendet werden, die auf dem Server statisch gerendert werden. Es wird jedoch empfohlen, dies nach Möglichkeit zu vermeiden.

HttpContext kann nur in statisch gerenderten Stammkomponenten für allgemeine Aufgaben als kaskadierender Parameter verwendet werden, z. B. beim Überprüfen und Ändern von Headern oder anderen Eigenschaften in der App-Komponente (Components/App.razor). Der Wert lautet immer null zum interaktiven Rendern.

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

Für Szenarios, in denen HttpContext in interaktiven Komponenten erforderlich ist, empfehlen wir, die Daten über den permanenten Komponentenstatus vom Server zu übertragen. Weitere Informationen finden Sie unter ASP.NET core serverseitigen und Blazor Web App zusätzlichen Sicherheitsszenarien.

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.

Warnung

Es wird nicht empfohlen, dass Apps auf demselben Server sich einen Zustand mithilfe von Singletondiensten teilen, es sei denn, es wird mit äußerster Vorsicht vorgegangen, da dies zu Sicherheitsrisiken führen kann, wie z. B. verbindungsübergreifende Preisgabe des Benutzerzustands.

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.

Serverseitige Sicherheit vertraulicher Daten und Anmeldeinformationen

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 (Blazor Dokumentation)

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

Projektvorlage

Erstellen Sie eine neue serverseitige Blazor-App, indem Sie die Anleitung unter Tools für ASP.NET Core Blazor befolgen.

Visual Studio

Nachdem Sie die Vorlage für serverseitige Apps ausgewählt und das Projekt konfiguriert haben, wählen Sie unter Authentifizierungstyp die Authentifizierung der App aus:

• Keine (Standardwert): Keine Authentifizierung.
• Einzelne Konten: Benutzerkonten werden mithilfe von ASP.NET Core Identity in der App gespeichert.

Visual Studio Code

Geben Sie im .NET CLI-Befehl zum Erstellen und Konfigurieren der serverseitigen Blazor-App den Authentifizierungsmechanismus mit der Option -au|--auth an:

-au {AUTHENTICATION}

Hinweis

Den vollständigen Befehl finden Sie unter Tools für ASP.NET Core Blazor.

Zulässige Authentifizierungswerte für den Platzhalter {AUTHENTICATION} werden in der folgenden Tabelle angezeigt.

Authentifizierungsmechanismus	Beschreibung
None (Standardwert)	Keine Authentifizierung
Individual	In der App mit ASP.NET Core-Identität gespeicherte Benutzer Identity

Weitere Informationen finden Sie im Befehl dotnet new im Leitfaden für .NET Core.

.NET CLI

Geben Sie im .NET CLI-Befehl zum Erstellen und Konfigurieren der serverseitigen Blazor-App den Authentifizierungsmechanismus mit der Option -au|--auth an:

-au {AUTHENTICATION}

Hinweis

Den vollständigen Befehl finden Sie unter Tools für ASP.NET Core Blazor.

Zulässige Authentifizierungswerte für den Platzhalter {AUTHENTICATION} werden in der folgenden Tabelle angezeigt.

Authentifizierungsmechanismus	Beschreibung
None (Standardwert)	Keine Authentifizierung
Individual	In der App mit ASP.NET Core-Identität gespeicherte Benutzer Identity

Weitere Informationen finden Sie unter:

• Lesen Sie im Leitfaden für .NET Core die Informationen zum Befehl dotnet new.

• Führen Sie in einer Befehlsshell den Hilfebefehl für die Vorlage aus:

  dotnet new {PROJECT TEMPLATE} --help
  

  Im vorherigen Befehl steht der Platzhalter {PROJECT TEMPLATE} für die Projektvorlage.

BlazorIdentity-Benutzeroberfläche (einzelne Konten)

Blazor unterstützt das Generieren einer vollständigen Blazor-basierten Identity-Benutzeroberfläche, wenn Sie die Authentifizierungsoption für einzelne Konten auswählen.

Die Blazor Web App-Vorlage erstellt ein Identity-Codegerüst für eine SQL Server-Datenbank. Die Befehlszeilenversion verwendet SQLite und enthält eine SQLite-Datenbank für Identity.

Die -Vorlage:

• Unterstützt Szenarien für interaktives serverseitiges Rendering (interactive SSR) und clientseitiges Rendering (CSR) mit authentifizierten Benutzenden.
• Fügt IdentityRazor-Komponenten und zugehörige Logik für routinemäßige Authentifizierungsaufgaben hinzu, wie z. B. das An- und Abmelden von Benutzenden. Die Identity-Komponenten unterstützen auch erweiterte Identity-Funktionen, wie z. B. Kontobestätigung und Kennwortwiederherstellung und Multi-Faktor-Authentifizierung mithilfe einer Drittanbieter-App. Beachten Sie, dass die Identity-Komponenten selbst keine Interaktivität unterstützen.
• Fügt die zu Identity zugehörigen Pakete und Abhängigkeiten hinzu
• Verweist auf die Identity-Pakete in _Imports.razor
• Erstellt eine benutzerdefinierte Identity-Klasse für Benutzer*innen (ApplicationUser).
• Erstellt und registriert einen EF Core-Datenbankkontext (ApplicationDbContext).
• Konfiguriert das Routing für die integrierten Identity-Endpunkte.
• Umfasst die Validierungs- und Geschäftslogik von Identity

Um die Identity-Komponenten des Blazor-Frameworks zu untersuchen, greifen Sie darauf in den Ordnern Pages und Shared des Ordners Account in der Blazor Web App-Projektvorlage (Verweisquelle) zu.

Wenn Sie die interaktiven WebAssembly- oder interaktiven Auto-Rendermodi auswählen, verarbeitet der Server alle Authentifizierungs- und Autorisierungsanforderungen und die Identity-Komponenten werden statisch auf dem Server im Hauptprojekt der Blazor Web App gerendert.

Das Framework stellt einen benutzerdefiniertenAuthenticationStateProvider sowohl im Server- als auch im Clientprojekt (.Client) bereit, um den Authentifizierungsstatus des der Benutzerin oder des Benutzers an den Browser zu übertragen. Das Serverprojekt ruft AddAuthenticationStateSerialization auf, während das Clientprojekt AddAuthenticationStateDeserialization aufruft. Die Authentifizierung auf dem Server statt auf dem Client ermöglicht der Anwendung den Zugriff auf den Authentifizierungsstatus während des Prerenderings und vor der Initialisierung der .NET WebAssembly-Laufzeit. Die benutzerdefinierten AuthenticationStateProvider-Implementierungen verwenden den Dienst Persistent Component State (PersistentComponentState), um den Authentifizierungsstatus in HTML-Kommentare zu serialisieren und ihn dann von WebAssembly zurückzulesen, um eine neue AuthenticationState-Instanz zu erstellen. Weitere Informationen finden Sie im Abschnitt Verwalten des Authentifizierungsstatus in Blazor Web Apps.

Nur für Interactive Server-Lösungen handelt es sich bei IdentityRevalidatingAuthenticationStateProvider (Referenzquelle) um einen serverseitigen AuthenticationStateProvider, der alle 30 Minuten den Sicherheitsstempel für das verbundene Benutzerkonto revalidiert, solange eine interaktive Verbindung besteht.

BlazorIdentity hängt von DbContext Instanzen ab, die nicht von einer Factoryerstellt wurden, was beabsichtigt ist, da DbContext die Komponenten der Projektvorlage Identity ausreichen, um statisch zu rendern, ohne Interaktivität zu unterstützen.

Eine Beschreibung, wie globale interaktive Rendermodi auf Nicht-Identity-Komponenten angewandt werden und gleichzeitig statisches SSR für die Identity-Komponenten erzwungen wird, finden Sie unter ASP.NET Core-Rendermodi Blazor.

Weitere Informationen zum Speichern des vorab gerenderten Status finden Sie unter Vorabrendern von ASP.NET Core Razor-Komponenten.

Weitere Informationen zur BlazorIdentity-Benutzeroberfläche und Anleitungen zum Integrieren externer Anmeldungen über soziale Websites finden Sie unter Neuerungen bei identity in .NET 8.

Hinweis

Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

Verwalten des Authentifizierungsstatus in Blazor Web Apps

Dieser Abschnitt gilt für Blazor Web Apps, die Folgendes nutzen:

• Individuelle Konten
• Clientseitiges Rendering (CSR, WebAssembly-basierte Interaktivität).

Ein clientseitiger Authentifizierungsstatusanbieter wird nur in Blazor verwendet und nicht in das ASP.NET Core-Authentifizierungssystem integriert. Beim Vorabrendering berücksichtigt Blazor die auf der Seite definierten Metadaten und verwendet das ASP.NET Core-Authentifizierungssystem, um zu ermitteln, ob der/die Benutzer*in authentifiziert ist. Wenn Benutzer*innen von einer Seite zu einer anderen navigieren, wird ein clientseitiger Authentifizierungsanbieter verwendet. Wenn Benutzer*innen die Seite aktualisieren (Neuladen der ganzen Seite), ist der clientseitige Authentifizierungsstatusanbieter nicht an der Authentifizierungsentscheidung auf dem Server beteiligt. Da der Status der Benutzer*innen vom Server nicht beibehalten wird, gehen alle clientseitig verwalteten Authentifizierungsstatus verloren.

Um dies zu beheben sollten Sie am besten die Authentifizierung im ASP.NET Core-Authentifizierungssystem durchzuführen. Der clientseitige Authentifizierungsstatusanbieter hat dann nur noch die Aufgabe, den Authentifizierungsstatus der Benutzer*innen anzuzeigen. Beispiele dafür, wie Sie dies mit verschiedenen Authentifizierungsstatusanbietern erreichen, finden Sie in der Projektvorlage für Blazor Web App und in der Beschreibung unten.

Rufen Sie in der Datei Program des Serverprojekts AddAuthenticationStateSerialization auf. Dadurch wird die AuthenticationState serialisiert, die vom Server AuthenticationStateProvider zurückgegeben wird. Dies geschieht mithilfe des Diensts Persistent Component State (PersistentComponentState):

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

Die API serialisiert nur die serverseitigen Namens- und Rollenansprüche für den Zugriff im Browser. Um alle Ansprüche einzuschließen, legen Sie SerializeAllClaims auf true fest (im serverseitigen Aufruf AddAuthenticationStateSerialization):

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

Rufen Sie im Client (.Client) in der Projektdatei Program AddAuthenticationStateDeserialization auf, das einen AuthenticationStateProvider hinzufügt, wo der AuthenticationState deserialisiert wird. Dies geschieht mit AuthenticationStateData und dem Dienst Persistent Component State (PersistentComponentState). Es sollte ein entsprechender Aufruf von AddAuthenticationStateSerialization im Serverprojekt vorhanden sein.

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

Zusätzliche Ansprüche und Token von externen Anbietern

Informationen zum Speichern zusätzlicher Ansprüche von externen Anbietern finden Sie unter Beibehalten zusätzlicher Ansprüche und Token von externen Anbietern in ASP.NET Core.

Azure App Service für Linux mit Identity Server

Geben Sie den Zertifikataussteller explizit an, wenn Sie eine Bereitstellung auf Azure App Service für Linux mit Identity Server durchführen. Weitere Informationen finden Sie unter Verwenden von Identity zum Sichern eines Web-API-Back-Ends für SPAs.

Injizieren Sie AuthenticationStateProvider für Dienste, die einer Komponente zugeordnet sind.

Versuchen Sie nicht, AuthenticationStateProvider innerhalb eines benutzerdefinierten Bereichs aufzulösen, da dies zur Erstellung einer neuen Instanz von AuthenticationStateProvider führt, die nicht ordnungsgemäß initialisiert wird.

Um auf AuthenticationStateProvider innerhalb eines Diensts zuzugreifen, der einer Komponente zugeordnet ist, injizieren Sie AuthenticationStateProvider mit der @inject-Direktive oder dem [Inject]-Attribut und übergeben den Wert als Parameter an den Dienst. Dieser Ansatz stellt sicher, dass die richtige, initialisierte Instanz von AuthenticationStateProvider für jede Benutzer-App-Instanz verwendet wird.

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

Registrieren Sie den Dienst als bereichsbezogen. In einer serverseitigen Blazor-App verfügen bereichsbezogene Dienste über eine Lebensdauer, die der Dauer der Clientverbindung entspricht.

Gehen Sie in der Program-Datei folgendermaßen vor:

builder.Services.AddScoped<ExampleService>();

In der folgenden InjectAuthStateProvider-Komponente:

• Die Komponente erbt OwningComponentBase.
• AuthenticationStateProvider wird injiziert und an ExampleService.ExampleMethod übergeben.
• ExampleService wird mit OwningComponentBase.ScopedServices und GetRequiredServiceaufgelöst, wodurch die richtige, initialisierte Instanz von ExampleService zurückgegeben wird, die für die Lebensdauer der Verbindung des Benutzers vorhanden ist.

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

Weitere Informationen finden Sie in den Anleitungen zu OwningComponentBase unter ASP.NET Core Blazor-Abhängigkeitsinjektion.

Anzeige nicht autorisierter Inhalte beim Vorabendern mit einem benutzerdefinierten AuthenticationStateProvider

Um zu verhindern, dass unzulässige Inhalte, z.B. Inhalte in einer AuthorizeViewKomponente, während des Prerenderings mit einer benutzerdefinierten AuthenticationStateProvider Anwendung angezeigt werden, wählen Sie einen der folgenden Ansätze:

• Implementieren von IHostEnvironmentAuthenticationStateProvider für den benutzerdefinierten AuthenticationStateProvider zur Unterstützung des Vorabrenderings: Eine Beispielimplementierung von IHostEnvironmentAuthenticationStateProvider finden Sie in der BlazorServerAuthenticationStateProvider-Implementierung des Frameworks unter ServerAuthenticationStateProvider.cs (Referenzquelle).

  Hinweis

  Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

• Vorabrendering deaktivieren: Geben Sie den Rendermodus der Komponente auf der höchsten Ebene in der App-Hierarchie an, die keine Stammkomponente ist. Legen Sie den Parameter prerender dabei auf false fest.

  Hinweis

  Die Interaktivität einer Stammkomponente, wie z. B. der App-Komponente, wird nicht unterstützt. Daher kann die Voreinstellung nicht direkt von der App-Komponente deaktiviert werden.

  Bei Apps, die auf der Blazor Web App-Projektvorlage basieren, ist das Voarabrendering in der Regel deaktiviert, wenn die Routes-Komponente in der App-Komponente (Components/App.razor) verwendet wird:

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

  Deaktivieren Sie außerdem das Vorabrendering für die HeadOutlet-Komponente:

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

  Sie können den auf die Routes-Komponenteninstanz angewendeten Rendermodus auch selektiv steuern. Siehe z. B. ASP.NET Core Blazor Rendermodi.

• Authentifizieren des Benutzers auf dem Server, bevor die App gestartet wird: Bei diesem Ansatz muss die App mit der Identity-basierten Anmeldeseite oder -ansicht auf die anfängliche Anforderung eines Benutzers reagieren und alle Anforderungen an Blazor-Endpunkte verhindern, bis sie authentifiziert werden. Weitere Informationen finden Sie unter Erstellen einer ASP.NET Core-App mit Benutzerdaten, die durch Autorisierung geschützt sind. Nach der Authentifizierung werden nicht autorisierte Inhalte in vorab gerenderten Razor-Komponenten nur angezeigt, wenn der Benutzer wirklich nicht berechtigt ist, den Inhalt anzuzeigen.

User State management

Trotz des Worts „State“ (Zustand) im Namen dient AuthenticationStateProvider nicht zum Speichern des allgemeinen Benutzerzustands. AuthenticationStateProvider gibt nur den Authentifizierungsstatus des Benutzers für die App an, ob er bei der App angemeldet ist und in welchem Namen er angemeldet ist.

Die Authentifizierung verwendet dieselbe ASP.NET Core IdentityAuthentifizierung wie Razor Pages- und MVC-Apps. Der für ASP.NET Core Identity gespeicherte Benutzerzustand wird an Blazor übermittelt, ohne der App zusätzlichen Code hinzuzufügen. Befolgen Sie die Anleitungen in den ASP.NET Core Identity-Artikeln und den Tutorials für die Identity-Features, die in den Blazor-Teilen der App wirksam werden sollen.

Anleitungen zur allgemeinen Zustandsverwaltung außerhalb von ASP.NET Core Identity finden Sie unter ASP.NET Core Blazor-Zustandsverwaltung.

Zusätzliche Sicherheitsabstraktionen

Zwei zusätzliche Abstraktionen sind an der Verwaltung des Authentifizierungsstatus beteiligt:

• ServerAuthenticationStateProvider (Referenzquelle): Ein AuthenticationStateProvider, der vom Blazor-Framework verwendet wird, um den Authentifizierungsstatus vom Server abzurufen.

• RevalidatingServerAuthenticationStateProvider (Referenzquelle): Eine Basisklasse für AuthenticationStateProvider-Dienste, die vom Blazor-Framework verwendet werden, um einen Authentifizierungsstatus von der Hostumgebung zu empfangen und in regelmäßigen Abständen neu zu aktualisieren.

  Das Standardintervall von 30 Minuten für die Neuvalidierung kann in RevalidatingIdentityAuthenticationStateProvider (Areas/Identity/RevalidatingIdentityAuthenticationStateProvider.cs) angepasst werden. Im folgenden Beispiel wird das Intervall auf 20 Minuten verkürzt:

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

Hinweis

Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

Verwaltung des Authentifizierungsstatus beim Abmelden

Der serverseitige Blazor speichert den Authentifizierungsstatus der Benutzenden für die gesamte Lebensdauer des Schaltkreises, auch über Browser-Registerkarten hinweg. Um Benutzende automatisch von allen Browser-Registerkarten abzumelden, wenn sie sich auf einer Registerkarte abmelden, müssen Sie RevalidatingServerAuthenticationStateProvider (Referenzquelle) und ein kurzes RevalidationInterval implementieren.

Hinweis

Dokumentationslinks zur .NET-Referenzquelle laden in der Regel den Standardbranch des Repositorys, der die aktuelle Entwicklung für das nächste Release von .NET darstellt. Um ein Tag für ein bestimmtes Release auszuwählen, wählen Sie diesen mit der Dropdownliste Switch branches or tags (Branches oder Tags wechseln) aus. Weitere Informationen finden Sie unter How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205) (Auswählen eines Versionstags von ASP.NET Core-Quellcode (dotnet/AspNetCore.Docs #26205)).

Gültigkeitsdauer der temporären Umleitungs-URL

Dieser Abschnitt gilt für Blazor Web Apps.

Verwenden Sie die Option RazorComponentsServiceOptions.TemporaryRedirectionUrlValidityDuration, um die Gültigkeitsdauer des ASP.NET Core Data Protection für temporäre Umleitungs-URLs festzulegen, die durch das Blazor-serverseitige Rendering ausgegeben werden. Diese werden nur vorübergehend verwendet, sodass die Lebensdauer nur lang genug sein muss, damit ein Client die URL empfängt und mit der Navigation zu dieser beginnt. Sie sollte jedoch auch lang genug sein, um eine serverübergreifende Zeitdehnung zu ermöglichen. Der Standardwert beträgt 5 Minuten.

Im folgenden Beispiel wird der Wert auf sieben Minuten verlängert:

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

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 ist der zugrunde liegende Dienst, der von der AuthorizeView-Komponente und kaskadierenden Authentifizierungsdiensten verwendet wird, um den Authentifizierungsstatus für Benutzer*innen abzurufen.

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

Im vorherigen Beispiel:

• ClaimsPrincipal.Claims gibt die Benutzeransprüche (claims) zurück, die auf der Benutzeroberfläche angezeigt werden sollen.
• Die Zeile, die den Nachnamen des Benutzers oder der Benutzerin (surname) abruft, ruft ClaimsPrincipal.FindAll mit einem Prädikat auf, um die Benutzeransprüche zu filtern.

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

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

Richten Sie den Task<AuthenticationState>-Kaskadierungsparameter mithilfe der AuthorizeRouteView und kaskadierender Authentifizierungsstatusdienste ein.

Wenn Sie eine Blazor-App aus einer der Blazor-Projektvorlagen mit aktivierter Authentifizierung erstellen, enthält die App die AuthorizeRouteView und den Aufruf an AddCascadingAuthenticationState, der im folgenden Beispiel gezeigt wird. Eine clientseitige Blazor-App umfasst auch die erforderlichen Dienstregistrierungen. Weitere Informationen finden Sie im Abschnitt Anpassen von nicht autorisierten Inhalten mit der Router-Komponente.

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

Registrieren Sie in der Program-Datei kaskadierende Authentifizierungsstatusdienste:

builder.Services.AddCascadingAuthenticationState();

Fügen Sie der Program-Datei in einer clientseitigen Blazor-App Autorisierungsdienste hinzu:

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.

Razor Komponenten von Blazor Web Apps zeigen niemals <NotAuthorized>-Inhalte an, wenn die Autorisierung während des statischen serverseitigen Renderings (statischer SSR) serverseitig fehlschlägt. Die serverseitige ASP.NET Core-Pipeline verarbeitet die Autorisierung auf dem Server. Verwenden Sie serverseitige Techniken, um nicht autorisierte Anforderungen zu verarbeiten. Weitere Informationen finden Sie unter ASP.NET Core Blazor-Rendermodi.

Warnung

Clientseitiges Markup und Methoden, die einer AuthorizeView zugeordnet sind, werden nur in der gerenderten Benutzeroberfläche in clientseitigen Blazor-Apps vor Ansicht und Ausführung geschützt. Um autorisierte Inhalte und sichere Methoden für clientseitige Blazor zu schützen, werden die Inhalte in der Regel durch einen sicheren, autorisierten Web-API-Aufruf einer Server-API bereitgestellt und nie in der App gespeichert. Weitere Informationen finden Sie unter Aufrufen einer Web-API aus einer ASP.NET Core-Blazor-App und unter Zusätzliche Sicherheitsszenarios für ASP.NET Core Blazor WebAssembly.

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.

Wichtig

Verwenden Sie nur [Authorize] für @page-Komponenten, die über den Blazor-Router angesteuert werden. Die Autorisierung wird nur als Aspekt des Routings und nicht für untergeordnete Komponenten durchgeführt, die innerhalb einer Seite gerendert werden. Um die Anzeige von bestimmten Teilen innerhalb einer Seite zu autorisieren, verwenden Sie stattdessen AuthorizeView.

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.

Ressourcenautorisierung

Wenn Sie Benutzer*innen für Ressourcen autorisieren möchten, übergeben Sie die Routendaten der Anforderung an den Resource-Parameter von AuthorizeRouteView.

Im Router.Found-Inhalt für eine angeforderte Route:

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

Weitere Informationen dazu, wie Autorisierungsstatusdaten übergeben und in der prozeduralen Logik verwendet werden, finden Sie im Abschnitt Verfügbar machen des Authentifizierungsstatus als kaskadierender Parameter.

Wenn AuthorizeRouteView die Routendaten für die Ressource empfängt, haben Autorisierungsrichtlinien Zugriff auf RouteData.PageType und RouteData.RouteValues, die es benutzerdefinierter Logik ermöglichen, Autorisierungsentscheidungen zu treffen.

Im folgenden Beispiel wird in AuthorizationOptions eine EditUser-Richtlinie für die Konfiguration des Autorisierungsdiensts der App (AddAuthorizationCore) mit der folgenden Logik erstellt:

• Ermitteln Sie, ob ein Routenwert mit dem Schlüssel id vorhanden ist. Wenn der Schlüssel vorhanden ist, wird der Routenwert in value gespeichert.
• Speichern Sie value in einer Variablen mit dem Namen id als Zeichenfolge, oder legen Sie einen leeren Zeichenfolgenwert fest (string.Empty).
• Bestätigen Sie, dass die Richtlinie erfüllt ist (geben Sie true zurück), wenn id keine leere Zeichenfolge ist und der Wert der Zeichenfolge mit EMP beginnt. Andernfalls bestätigen Sie, dass die Richtlinie fehlschlägt (geben Sie false zurück).

In der Program-Datei:

• Fügen Sie für Microsoft.AspNetCore.Components und System.Linq Namespaces hinzu:

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

• Fügen Sie die Richtlinie hinzu:

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

Beim obigen Beispiel handelt es sich um eine stark vereinfachte Autorisierungsrichtlinie, die lediglich verwendet wird, um das Konzept anhand eines funktionierenden Beispiels zu veranschaulichen. Weitere Informationen zum Erstellen und Konfigurieren von Autorisierungsrichtlinien finden Sie unter Richtlinienbasierte Autorisierung in ASP.NET Core.

In der folgenden EditUser-Komponente verfügt die Ressource unter /users/{id}/edit über einen Routenparameter für den Bezeichner des Benutzers ({id}). Die Komponente verwendet die vorstehende EditUser-Autorisierungsrichtlinie, um zu ermitteln, ob der Routenwert für id mit EMP beginnt. Wenn id mit EMP beginnt, ist die Richtlinie erfolgreich, und der Zugriff auf die Komponente ist autorisiert. Wenn id mit einem anderen Wert als EMP beginnt, oder wenn id eine leere Zeichenfolge ist, schlägt die Richtlinie fehl, und die Komponente wird nicht geladen.

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

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.

Wichtig

Blazor Routerfeatures, die <NotAuthorized>- und <NotFound>-Inhalte anzeigen während des statischen serverseitigen Renderings (statischer SSR) nicht betriebsbereit sind, da die Anforderungsverarbeitung vollständig von ASP.NET Core Middleware-Pipelineanforderungsverarbeitung verarbeitet wird und Razor Komponenten nicht für nicht autorisierte oder fehlerhafte Anforderungen gerendert werden. Verwenden Sie serverseitige Techniken, um nicht autorisierte und fehlerhafte Anforderungen während statischer SSR zu verarbeiten. Weitere Informationen finden Sie unter ASP.NET Core Blazor-Rendermodi.

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

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

Hinweis

Im Vorherigen ist die Registrierung von Authentifizierungsstatusdiensten in der Program-Datei der App erforderlich:

builder.Services.AddCascadingAuthenticationState();

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

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

• Serverseitige und Blazor Web App Ressourcen
  • Schnellstart: Hinzufügen von „Bei Microsoft anmelden“ zu einer ASP.NET Core-Web-App
  • Schnellstart: Schützen einer ASP.NET Core-Web-API mit der Microsoft-Identitätsplattform
  • Konfigurieren von ASP.NET Core zur Verwendung mit Proxyservern und Lastenausgleich: Umfasst Hinweise zu:
    • der Verwendung der Middleware für weitergeleitete Header, um HTTPS-Schemainformationen für Proxyserver und interne Netzwerke zu schützen
    • zusätzlichen Szenarios und Anwendungsfällen, einschließlich der manuellen Schemakonfiguration, Änderungen von Anforderungspfaden für fehlerfreies Routing von Anforderungen und der Weiterleitung des Anforderungsschemas für Linux- und Nicht-IIS-Reverseproxys.
• Dokumentation zur Microsoft identity-Plattform
  • Übersicht
  • OAuth 2.0- und OpenID Connect-Protokolle auf der Microsoft identity-Plattform
  • Microsoft identity-Plattform und der OAuth 2.0-Autorisierungscodeflow
  • ID-Token der Microsoft identity-Plattform
  • Zugriffstoken der Microsoft identity-Plattform
• Sicherheitsaspekte für ASP.NET Core
• Konfigurieren der Windows-Authentifizierung in ASP.NET Core
• Erstellen einer benutzerdefinierten Version der Authentication.MSAL-JavaScript-Bibliothek
• Nützliche Ressourcen für Blazor: Authentifizierung – Beispiellinks für die Community
• Authentifizierung und Autorisierung in ASP.NET Core Blazor Hybrid