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 zu ermitteln. 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 sich nur auf serverseitiges Rendering (SSR) für Autorisierungsprüfungen und die Durchsetzung von Regeln verlässt.

Razor Die Autorisierungskonventionen für Seiten gelten nicht für routingfähige Razor Komponenten. Wenn eine nicht routingfähige Komponente in eine Seite einer Pages-Appeingebettet ist, wirken sich die Autorisierungskonventionen der Seite indirekt auf die Komponente zusammen mit dem restlichen Inhalt der Seite aus.

Hinweis

Die Codebeispiele in diesem Artikel übernehmen nullable Referenztypen (NRTs) und .NET Compiler null-state static analysis, die in ASP.NET Core in .NET 6 oder höher unterstützt werden. Entfernen Sie bei der Zielbestimmung von .NET 5 oder einer früheren Version die Null-Typbezeichnung (?) aus Beispielen in diesem Artikel.

Sichere Verwaltung vertraulicher Daten und Anmeldeinformationen

Speichern Sie keine geheimen App-Schlüssel, Verbindungszeichenfolgen, 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 Authentifizierungsabläufe verwenden, die darauf abzielen, das Speichern von Zugangsdaten innerhalb von Projektcode oder Konfigurationsdateien zu 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 verwalteter 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
  • So verwenden Sie verwaltete Identitäten für App Service und Azure Functions

Unterstützung des Schutzes vor Fälschung

Die Blazor-Vorlage:

• Fügt Fälschungsschutzdienste automatisch hinzu, wenn AddRazorComponents in der Datei Program aufgerufen wird.
• Fügt Antiforgery-Middleware hinzu, indem UseAntiforgery in seiner Anforderungsverarbeitungspipeline in der Program-Datei aufgerufen wird, und erfordert Endpunkt-Antiforgery-Schutz, um die Bedrohungen von Cross-Site Request Forgery (CSRF/XSRF) zu mindern. UseAntiforgery wird nach UseHttpsRedirectionaufgerufen. Ein Aufruf von UseAntiforgery muss nach den Aufrufen von UseAuthentication und UseAuthorization erfolgen, falls vorhanden.

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 ASP.NET Übersicht über KernformulareBlazor.

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 aus einer ASP.NET Core-AppBlazor.

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

Antifälschungsschutz ist nur erforderlich, wenn Formulardaten in einem der Formate , application/x-www-form-urlencoded oder multipart/form-data an den Server übermittelt werden, da dies die einzigen gültigen Formular-Enctypes sind.

Weitere Informationen finden Sie in den folgenden Ressourcen:

• Verhindern von Cross-Site Request Forgery (XSRF/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 Blazor die Integration mit MVC/Razor Pages gilt.
• ASP.NET Core-Übersicht über FormulareBlazor: Der Abschnitt Antiforgery-Unterstützung des Artikels bezieht sich auf Blazor Formulare zur Antiforgery-Unterstützung.

Serverseitige Blazor-Authentifizierung

Serverseitige Blazor-Apps werden genauso wie ASP.NET Core-Apps für Sicherheit konfiguriert. Weitere Informationen finden Sie in den Artikeln unter ASP.NET Core-Sicherheitsthemen.

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, die Authentifizierung wird jedoch über den SignalR Hub und vollständig innerhalb des Schaltkreises 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 Benutzeraktualisierungen reagieren muss, lesen Sie Blazor Web App.

Blazor unterscheidet sich von herkömmlichen vom Server gerenderten Web-Apps, die neue HTTP-Anforderungen mit Cookies auf jeder Seitennavigation vornehmen. 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 des Blazor Schaltkreises überprüft, den Sie jederzeit mithilfe der RevalidatingAuthenticationStateProvider Abstraktion 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 eine benutzerdefinierte Logik für den Authentifizierungsstatus ausführen muss, verwenden Sie eine benutzerdefinierte AuthenticationStateProvider.

Hinweis

Die Codebeispiele in diesem Artikel übernehmen nullable Referenztypen (NRTs) und .NET Compiler null-state static analysis, die in ASP.NET Core in .NET 6 oder höher unterstützt werden. Wenn Sie auf .NET 5 oder früher abzielen, entfernen Sie 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.

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

Wir empfehlen nicht, dass Apps auf demselben Server einen Zustand über Singleton-Dienste teilen, es sei denn, es wird mit großer Vorsicht vorgegangen, da dies zu Sicherheitsrisiken führen kann, wie z. B. den Benutzerzustand über Verbindungskreise hinweg preiszugeben.

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.

Allgemeine Anleitungen zur Zustandsverwaltung finden Sie unter ASP.NET Core Blazor State Management.

Serverseitige Sicherheit vertraulicher Daten und Anmeldeinformationen

In Test-/Staging- und Produktionsumgebungen sollten serverseitiger Blazor Code und Web-APIs sichere Authentifizierungsabläufe verwenden, die darauf abzielen, das Speichern von Zugangsdaten innerhalb von Projektcode oder Konfigurationsdateien zu 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 den Anweisungen in der Toolerstellung für ASP.NET Core Blazorfolgen.

Visual Studio

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

• Keine (Standard): Keine Authentifizierung.
• Einzelne Konten: Benutzerkonten werden in der App mit ASP.NET Core Identitygespeichert.

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 Tooling for 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	Benutzer, die in der App mit ASP.NET Core gespeichert sind 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 Tooling for 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	Benutzer, die in der App mit ASP.NET Core gespeichert sind 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.

Blazor Identity UI (individuelle Konten)

Blazor unterstützt das Generieren einer vollständigen BlazorIdentity-basierten 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 routinebasierte Authentifizierungsaufgaben hinzu, z. B. das Anmelden und Abmelden von Benutzern. Die Identity Komponenten unterstützen auch erweiterte Identity Features, z. B. Kontobestätigung und Kennwortwiederherstellung und mehrstufige 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 Komponenten des Blazor Frameworks zu prüfen, greifen Sie in den Identity Ordnern und Pages Ordnern SharedAccount.

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 benutzerdefinierten AuthenticationStateProvider sowohl im Server- als auch im Client-Projekt (.Client) bereit, um den Authentifizierungsstatus 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 für beständigen Komponentenstatus (PersistentComponentState), um den Authentifizierungsstatus in HTML-Kommentare zu serialisieren und 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 um eine serverseitige Funktion IdentityRevalidatingAuthenticationStateProvider, die den Sicherheitsstempel für den verbundenen Benutzer alle 30 Minuten erneuert, während eine interaktive Verbindung besteht.

Blazor Identity DbContext hängt absichtlich von Instanzen ab, die nicht von einer Factory erstellt wurden, da DbContext ausreicht, damit die Komponenten der Projektvorlage Identity statisch rendern, ohne Interaktivität zu unterstützen.

Eine Beschreibung, wie globale interaktive Rendermodi auf NichtkomponentenIdentity angewendet werden und gleichzeitig statische SSR für die Identity Komponenten erzwingen, finden Sie unter ASP.NET Core-RendermodiBlazor.

Weitere Informationen zum Beibehalten des voreingestellten Zustands finden Sie unter Prerender ASP.NET Core-KomponentenRazor.

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 eine bestimmte Version auszuwählen, verwenden Sie die Dropdownliste "Switch Branches" oder "Tags ". Weitere Informationen finden Sie unter Auswählen eines Versionstags ASP.NET Core-Quellcodes (dotnet/AspNetCore.Docs #26205).For more information, see How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205).

Verwalten des Authentifizierungsstatus in Blazor Web App

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

• 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 Program-Datei des Serverprojekts AddAuthenticationStateSerialization auf, wodurch das vom serverseitigen AuthenticationState zurückgegebene AuthenticationStateProvider mit dem Dienst für beständigen Komponentenstatus (PersistentComponentState) serialisiert wird.

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 im serverseitigen Aufruf zu AddAuthenticationStateSerialization fest.

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

Rufen Sie im Projekt-.Client-Dokument des Clients (Program) AddAuthenticationStateDeserialization auf, was eine AuthenticationStateProvider hinzufügt, bei der das AuthenticationState mit Hilfe von AuthenticationStateData vom Server deserialisiert und der Dienst für beständigen Komponentenstatus (PersistentComponentState) verwendet wird. Es sollte ein entsprechender Aufruf von AddAuthenticationStateSerialization im Serverprojekt vorhanden sein.

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

Zusätzliche Forderungen und Token von externen Anbietern

Informationen zum Speichern zusätzlicher Ansprüche von externen Anbietern finden Sie unter Persist additional claims and tokens from external providers 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 Identity zum Sichern eines Web-API-Back-Ends für SPAs".

Verwenden 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 die AuthenticationStateProvider innerhalb eines Diensts zuzugreifen, der auf eine Komponente festgelegt ist, fügen Sie die AuthenticationStateProvider in die Komponente ein, und übergeben Sie sie 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 weisen bereichsbezogene Dienste eine Lebensdauer auf, die der Dauer der Clientverbindungsschaltung 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 OwningComponentBase zu ASP.NET Core-AbhängigkeitsinjektionBlazor.

Anzeige nicht autorisierter Inhalte beim Vorabendern mit einem benutzerdefinierten AuthenticationStateProvider

Um zu vermeiden, dass nicht autorisierte Inhalte angezeigt werden, z. B. Inhalte in einer AuthorizeView Komponente, während sie mit einer benutzerdefinierten AuthenticationStateProviderVoreinstellung dargestellt werden, führen Sie einen der folgenden Ansätze aus:

• Implementieren Sie IHostEnvironmentAuthenticationStateProvider für das benutzerdefinierte AuthenticationStateProvider, um Vorab-Rendering zu unterstützen: Für eine Beispielimplementierung von IHostEnvironmentAuthenticationStateProvider siehe die Blazor-Implementierung des ServerAuthenticationStateProvider Frameworks in 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 eine bestimmte Version auszuwählen, verwenden Sie die Dropdownliste "Switch Branches" oder "Tags ". Weitere Informationen finden Sie unter Auswählen eines Versionstags ASP.NET Core-Quellcodes (dotnet/AspNetCore.Docs #26205).For more information, see How to select a version tag of ASP.NET Core source code (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 das Prerendering nicht direkt von der App-Komponente deaktiviert werden.

  Bei Apps, die auf der Blazor Web App-Projektvorlage basieren, ist das Vorabrendering normalerweise 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. Beispielsweise siehe ASP.NET Core-RendermodiBlazor.

• 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 benutzergeschützten Benutzerdaten. Nach der Authentifizierung werden nicht autorisierte Inhalte in vorab gerenderten Razor-Komponenten nur angezeigt, wenn der Benutzer wirklich nicht berechtigt ist, den Inhalt anzuzeigen.

Benutzerzustandsverwaltung

Trotz des Worts "Zustand" im Namen AuthenticationStateProvider ist es nicht für das Speichern des allgemeinen Benutzerzustands vorgesehen. 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 Identityfinden Sie unter ASP.NET Core Blazor State Management.

Zusätzliche Sicherheitsabstraktionen

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

• ServerAuthenticationStateProvider (Referenzquelle): Ein AuthenticationStateProvider, das 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 aus der Hostumgebung zu erhalten und sie in regelmäßigen Abständen zu aktualisieren.

  Das Standardmäßige 30-Minuten-Revalidierungsintervall kann in RevalidatingIdentityAuthenticationStateProvider (Referenzquelle) 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 eine bestimmte Version auszuwählen, verwenden Sie die Dropdownliste "Switch Branches" oder "Tags ". Weitere Informationen finden Sie unter Auswählen eines Versionstags ASP.NET Core-Quellcodes (dotnet/AspNetCore.Docs #26205).For more information, see How to select a version tag of ASP.NET Core source code (dotnet/AspNetCore.Docs #26205).

Verwaltung des Authentifizierungsstatus beim Abmelden

Serverseitig Blazor bleibt der Authentifizierungsstatus des Benutzers während der gesamten Lebensdauer des Circuits erhalten, auch über Browser-Registerkarten hinweg. Um einen Benutzer proaktiv über Browserregisterkarten abzumelden, wenn sich der Benutzer auf einer Registerkarte abmeldet, müssen Sie eine RevalidatingServerAuthenticationStateProvider (Referenzquelle) mit einer kurzen Datei RevalidationIntervalimplementieren.

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 eine bestimmte Version auszuwählen, verwenden Sie die Dropdownliste "Switch Branches" oder "Tags ". Weitere Informationen finden Sie unter Auswählen eines Versionstags ASP.NET Core-Quellcodes (dotnet/AspNetCore.Docs #26205).For more information, see How to select a version tag of ASP.NET Core source code (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 Uhrenabweichungen zwischen Servern 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:

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

  Hinweis

  Anleitungen zum Hinzufügen von Paketen zu .NET-Apps finden Sie in den Artikeln unter "Installieren und Verwalten von Paketen" im Workflow "Paketverbrauch" (NuGet-Dokumentation). Bestätigen Sie die richtigen Paketversionen bei NuGet.org.

• 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 Secure ASP.NET Core Blazor WebAssembly.

Sichern Sie Daten in Blazor Web Apps mit Interactive Auto Rendering

Wenn Blazor Web App serverseitiges Rendering (SSR) und clientseitiges Rendering (CSR) für Komponenten oder eine gesamte App verwendet werden, die den interaktiven automatischen Rendermodus festlegt, wird die Autorisierung für den Zugriff auf Komponenten und Daten an zwei Stellen angewendet. Die Komponente schränkt den Zugriff auf sich selbst (und alle daten, die sie abruft) ein, wenn sie aufgrund eines Autorisierungsattributs in der Definitionsdatei der Komponente (@attribute [Authorize]) auf dem Server gerendert werden. Wenn die Komponente auf dem Client gerendert wird, wird der Zugriff auf Daten über die Serverweb-API-Endpunkte eingeschränkt, die vom Client aufgerufen werden. Achten Sie darauf, dass bei der Sicherung des Datenzugriffs an beiden Standorten kein unberechtigter Zugriff erfolgt.

Betrachten Sie das folgende Szenario, in dem sichere Wetterdaten von einer Komponente angezeigt werden. Demonstrationen einiger der folgenden Ansätze können mithilfe BlazorWebAppEntra/BlazorWebAppEntraBffder Beispiele (.NET 9 oder höher) oder derBlazorWebAppOidc/BlazorWebAppOidcBffBeispiele (.NET 8 oder höher) im Blazor GitHub-Repository (dotnet/blazor-samples) der Beispiele () (zum Herunterladen) ausgewertet und getestet werden.

Das Clientprojekt verwaltet eine WeatherForecast Klasse zum Halten von Wetterdaten:

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

Die IWeatherForecaster Schnittstelle des Clientprojekts definiert eine GetWeatherForecastAsync Methode zum Abrufen von Wetterdaten:

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

Der ClientWeatherForecaster-Dienst des Clientprojekts implementiert IWeatherForecaster. Die GetWeatherForecastAsync-Methode ruft eine Web-API im Serverprojekt am /weather-forecast-Endpunkt für Wetterdaten auf:

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

Das Client-Projekt unterhält eine Weather Komponente, die:

• Erzwingt die Autorisierung mit einem [Authorize] Attribut.
• Verwendet den Dienst für beständigen Komponentenstatus (PersistentComponentState), um Wettervorhersagedaten beizubehalten, wenn die Komponente von statisch zu interaktivem SSR auf dem Server wechselt. Weitere Informationen finden Sie unter Prerender ASP.NET Core-KomponentenRazor.

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

<PageTitle>Weather</PageTitle>

<h1>Weather</h1>

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

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

@code {
    private IEnumerable<WeatherForecast>? forecasts;
    private PersistingComponentStateSubscription persistingSubscription;

    protected override async Task OnInitializedAsync()
    {
        if (!ApplicationState.TryTakeFromJson<IEnumerable<WeatherForecast>>(
            nameof(forecasts), out var restoredData))
        {
            forecasts = await WeatherForecaster.GetWeatherForecastAsync();
        }
        else
        {
            forecasts = restoredData!;
        }

        // Call at the end to avoid a potential race condition at app shutdown
        persistingSubscription = ApplicationState.RegisterOnPersisting(PersistData);
    }

    private Task PersistData()
    {
        ApplicationState.PersistAsJson(nameof(forecasts), forecasts);

        return Task.CompletedTask;
    }

    void IDisposable.Dispose() => persistingSubscription.Dispose();
}

Das Serverprojekt implementiert IWeatherForecaster als ServerWeatherForecaster, das Wetterdaten über seine GetWeatherForecastAsync Methode generiert und zurückgibt:

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

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

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

Wenn die App eine externe Web-API aufrufen muss, um die Wetterdaten abzurufen, können Sie einen HTTP-Client (HttpClient) einfügen, um die Daten anzufordern:

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

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

In einem weiteren Ansatz können Sie eine HTTP-Clientfactory (IHttpClientFactory) in die ServerWeatherForecaster einfügen und eine externe Web-API mit einem benannten HTTP-Client und einem Tokenhandler aufrufen. Weitere Informationen finden Sie unter Aufrufen einer Web-API aus einer ASP.NET Core-AppBlazor.

Wenn die App Microsoft Identity Platform mit Microsoft Identity Webpaketen für Microsoft Entra ID verwendet (siehe Aufrufen einer Web-API aus einer ASP.NET Core-AppBlazor), veranschaulicht die folgende ServerWeatherForecaster Erstellung eines externen Web-API-Aufrufs. Das Zugriffstoken wird automatisch an die Anforderung angefügt.

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

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

Unabhängig vom ServerWeatherForecaster Ansatz zum Abrufen der Daten verwaltet das Serverprojekt einen sicheren Web-API-Endpunkt für Client-Wetterdatenaufrufe. Dieser Endpunkt führt zu einem ServerWeatherForecaster.GetWeatherForecastAsync Aufruf auf dem Server:

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

Bei Verwendung des vorherigen Ansatzes gibt es zwei Systeme, um dem Benutzer sichere Wetterdaten zur Verfügung zu stellen:

• Wenn die Weather Komponente auf dem Server gerendert wird, wird die ServerWeatherForecaster Methode des Diensts GetWeatherForecastAsync direkt verwendet, um die Wetterdaten abzurufen. Die Sicherheit der Daten wird durch das Attribut der Komponente [Authorize]erzwungen. Zusammenfassend wird die Sicherheit der Wetterdaten durch die Komponente erzwungen.
• Wenn die Weather Komponente auf dem Client-gerendert wird, wird der ClientWeatherForecaster Dienst verwendet, um einen Web-API-Aufruf an den sicheren /weather-forecast Endpunkt zu erstellen, der die RequireAuthorization Erweiterungsmethode anwendet. Wenn der Benutzer über die Berechtigung zum Zugreifen auf Wetterdaten verfügt, verwendet der Endpunkt den ServerWeatherForecaster Dienst, um GetWeatherForecastAsyncaufzurufen. Die Daten werden an den Client zurückgegeben. Zusammenfassend wird die Sicherheit der Wetterdaten vom Web-API-Endpunkt der Server-App erzwungen.

Der vorherige Ansatz funktioniert gut, wenn die Sicherheitsanforderungen der Web-API den Sicherheitsanforderungen der Komponente entsprechen. Beispielsweise kann dieselbe Autorisierungsrichtlinie sowohl auf den Web-API-Endpunkt als auch auf die Komponente angewendet werden.

Komplexe Szenarien erfordern zusätzliche Planung und Implementierung. Beispielsweise erfordert eine Serverweb-API mit mehreren Aufrufen mit unterschiedlichen Zugriffsberechtigungen entweder eine komplexere Autorisierungsrichtlinie, eine oder mehrere zusätzliche Richtlinien oder zusätzliche Endpunkte mit unterschiedlichen Zugriffsanforderungen.

Wenn Sie Sicherheit in Apps einbauen, die interaktives Autorendering einführen, beachten Sie, dass die für die Web-API-Endpunkte des Servers implementierte Sicherheit nicht die Dienstimplementierung sichert, die verwendet wird, wenn eine Komponente auf dem Server gerendert wird und über den Dienst auf Daten zugreift. Wägen Sie sorgfältig den Unterschied zwischen dem Zugriff auf Daten auf dem Server während des SSR im Vergleich zum Zugriff auf die Daten in einer Clientweb-API-Anforderung während der CSR. Die Sicherheit wird strategisch angewendet, um unsachgemäßen Zugriff auf Daten zu vermeiden.

Beispiele im Blazor GitHub-Repository (Beispiele) (dotnet/blazor-samplesherunterladen), die den in diesem Abschnitt beschriebenen Ansatz veranschaulichen:

• BlazorWebAppOidc
• BlazorWebAppOidcBff
• BlazorWebAppEntra
• BlazorWebAppEntraBff

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 AuthorizeViewKomponenten oder die Task<AuthenticationState>Ansätze, die später in diesem Artikel beschrieben werden. 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 zum Implementieren eines benutzerdefinierten AuthenticationStateProvider finden Sie unter ASP.NET Core Blazor Authentifizierungsstatus, wo Sie auch Anleitungen zum Implementieren von Benachrichtigungen über Änderungen des Benutzer-Authentifizierungsstatus finden.

Abrufen der Prinzipal-Daten eines Benutzers

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 (DI) und Diensten finden Sie unter ASP.NET Core Dependency Injection Blazor und Abhängigkeitsinjektion in ASP.NET Core. Informationen zum Implementieren eines benutzerdefinierten Authentifizierungsstatus AuthenticationStateProviderfinden Sie unter ASP.NET Core Blazor authentication state.

Verfügbar machen des Authentifizierungsstatus als kaskadierender Parameter

Wenn Authentifizierungsstatusdaten für prozedurale Logik erforderlich sind, z. B. beim Ausführen einer vom Benutzer ausgelösten Aktion, rufen Sie die Authentifizierungsstatusdaten ab, indem Sie einen Cascading-Parameter vom Typ Task<AuthenticationState>definieren, wie im folgenden Beispiel veranschaulicht.

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 kaskadierenden 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. Zusätzliche Informationen werden im Abschnitt Anpassen nicht autorisierter Inhalte mit der Router-Komponente angezeigt.

<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 Blazor-Datei in einer clientseitigen Program-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, was der Benutzer tun kann.

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

• Ein Benutzer ist authentifiziert (angemeldet).
• Ein Benutzer befindet sich in einer Rolle.
• Ein Benutzer hat einen Anspruch.
• Eine Richtlinie wurde erfüllt.

Jedes dieser Konzepte entspricht dem einer ASP.NET Core MVC- oder Razor Pages-App. Weitere Informationen zu ASP.NET Core Security finden Sie in den Artikeln unter ASP.NET Core Security und Identity.

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 nur Daten für den Benutzer anzeigen müssen und die Identität des Benutzers nicht in verfahrenstechnischer 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 für autorisierte Benutzer sichtbar ist, aber nichts verhindert, dass diese Methode von anderen Stellen aus aufgerufen 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 App zeigen niemals <NotAuthorized>-Inhalte an, wenn die Autorisierung serverseitig während des statischen serverseitigen Renderings ("statisches SSR") 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-RendermodiBlazor.

Warnung

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

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

Autorisierungsbedingungen, z. B. Rollen oder Richtlinien, die UI-Optionen 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 AuthorizeView Komponente kann in der NavMenu Komponente () verwendet werden, um eine Shared/NavMenu.razor anzuzeigenNavLink (), 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 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.

Um den Fall zu behandeln, in dem der Benutzer mehrere Richtlinien gleichzeitig erfüllen muss, führen Sie eine der folgenden Ansätze aus:

• 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 beide Roles Bedingungen festgelegt sind und Policy festgelegt sind, ist die Autorisierung nur erfolgreich, wenn beide Bedingungen erfüllt sind. Das heißt, der Benutzer muss mindestens einer der angegebenen Rollen angehören und die von der Richtlinie definierten Anforderungen erfüllen.

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 auch bei der Zuordnung von Rollen- und Richtliniennamen 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

Blazor ermöglicht die asynchrone Ermittlung des Authentifizierungsstatus. 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 ausgefü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 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 der Benutzer nicht autorisiert ist und, falls die App nicht nicht autorisierte Inhalte mit der Router Komponente anpasst, 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 prozeduraler Logik verwendet werden, finden Sie im Abschnitt "Verfügbarmachen des Authentifizierungszustands 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 EditUser eine AuthorizationOptions-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 id in einer Variablen mit dem Namen value als Zeichenfolge, oder legen Sie einen leeren Zeichenfolgenwert fest (string.Empty).
• Bestätigen Sie, dass die Richtlinie erfüllt ist (geben Sie id zurück), wenn true 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).

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

• 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 Router-Komponente ermöglicht die AuthorizeRouteView-Komponente der App, benutzerdefinierten Inhalt anzugeben, wenn:

• Der Benutzer erfüllt eine für die Komponente angewendete [Authorize]-Bedingung nicht. Das Markup des <NotAuthorized>-Elements wird angezeigt. Das [Authorize] Attribut wird im [Authorize] Attributabschnitt 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 Routerfunktionen, die <NotAuthorized>- und <NotFound>-Inhalte anzeigen, sind während des statischen serverseitigen Renderings (statisches SSR) nicht betriebsbereit, da die Anforderungsverarbeitung vollständig durch die ASP.NET Core Middleware-Pipeline abgewickelt wird und Razor-Komponenten für nicht autorisierte oder fehlerhafte Anfragen überhaupt nicht 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-RendermodiBlazor.

<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

Bei dem Vorhergehenden ist die Registrierung von kaskadierten 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. Der Benutzer 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.

• null der Wert wird empfangen für authenticationStateTask

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 in der Dokumentation Informationen zu personenbezogenen Informationen (PII) erläutert werden.

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
• Online-Kennung
• Andere spezifische Faktoren
  • Physisch
  • Physiologisch
  • Genetisch
  • Mental (psychologisch)
  • Wirtschaft
  • Kultur
  • Soziale Identität

Zusätzliche Ressourcen

• Serverseitige und Blazor Web App-Ressourcen
  • Schnellstart: Hinzufügen der Anmeldung mit Microsoft zu einer ASP.NET Core Web App
  • Schnellstart: Schützen einer ASP.NET Core-Web-API mit Microsoft Identity Platform
  • Konfigurieren sie ASP.NET Core für die Arbeit mit Proxyservern und Lastenausgleichsmodulen: Enthält Anleitungen 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 zu Microsoft Identity Platform
  • Überblick
  • OAuth 2.0- und OpenID Connect-Protokolle auf der Microsoft Identity Platform
  • Microsoft Identity Platform und OAuth 2.0-Autorisierungscodefluss
  • Microsoft Identity Platform-ID-Token
  • Zugriffstoken der Microsoft Identity Platform
• ASP.NET Kernthemen zur Sicherheit
• Konfigurieren der Windows-Authentifizierung in ASP.NET Core
• IHttpContextAccessor/HttpContext in ASP.NET Core-Apps Blazor
• Erstellen einer benutzerdefinierten Version der Authentication.MSAL JavaScript-Bibliothek
• GroßartigBlazor: Links zu Beispielen der Authentifizierungs-Gemeinschaft
• ASP.NET Kernauthentifizierung Blazor Hybrid und Autorisierung