Sicherheit: Authentifizierung und Autorisierung in ASP.NET Web Forms und Blazor
Tipp
Diese Inhalte sind ein Auszug aus dem eBook „Blazor for ASP NET Web Forms Developers for Azure“, verfügbar unter .NET Docs oder als kostenlos herunterladbare PDF-Datei, die offline gelesen werden kann.
Bei der Migration einer ASP.NET Web Forms-Anwendung zu Blazor müssen mit großer Wahrscheinlichkeit die Methoden zur Authentifizierung und Autorisierung aktualisiert werden – vorausgesetzt, für die Anwendung ist eine Authentifizierung konfiguriert. In diesem Kapitel geht es um die Migration vom Modell eines universellen ASP.NET Web Forms-Anbieters (für Mitgliedschaft, Rollen und Benutzerprofile) und um die Arbeit mit ASP.NET Core Identity aus Blazor-Apps. Dieses Kapitel behandelt allgemeine Schritte und Überlegungen, detaillierte Schrittanleitungen und Skripts finden Sie in der referenzierten Dokumentation.
Universelle ASP.NET-Anbieter
Seit ASP.NET 2.0 unterstützt die ASP.NET Web Forms-Plattform ein Anbietermodell für eine Vielzahl von Features, einschließlich der Mitgliedschaft. Der universelle Mitgliedschaftsanbieter wird, zusammen mit dem optionalen Rollenanbieter, im Allgemeinen mit den ASP.NET Web Forms-Anwendungen bereitgestellt. Er bietet eine stabile und sichere Möglichkeit zum Verwalten der Authentifizierung und Autorisierung, die beide noch heute einwandfrei funktionieren. Das neueste Angebot dieser universellen Anbieter ist als NuGet-Paket verfügbar: Microsoft.AspNet.Providers.
Die universellen Anbieter arbeiten mit einem SQL-Datenbankschema, das Tabellen wie aspnet_Applications, aspnet_Membership, aspnet_Roles und aspnet_Users enthält. Während der Konfiguration mit dem Befehl aspnet_regsql.exe installieren die Anbieter Tabellen und gespeicherte Prozeduren, die sämtliche für die Arbeit mit den zugrunde liegenden Daten erforderlichen Abfragen und Befehle bereitstellen. Das Datenbankschema und diese gespeicherten Prozeduren sind nicht mit den neueren ASP.NET Identity- und ASP.NET Core Identity-Systemen kompatibel. Vorhandene Daten müssen daher in das neue System migriert werden. Abbildung 1 zeigt ein Beispieltabellenschema, das für universelle Anbieter konfiguriert wurde.
Der universelle Anbieter verarbeitet Benutzer, Mitgliedschaft, Rollen und Profile. Benutzern werden global eindeutige Bezeichner (Globally Unique Identifiers, GUIDs) zugewiesen, und grundlegende Informationen wie Benutzer-ID, Benutzername usw. werden in der Tabelle aspnet_Users gespeichert. Authentifizierungsinformationen wie Kennwort, Kennwortformat, Kennwortsalt, Indikatoren und Details zu Sperren usw. werden in der Tabelle aspnet_Membership gespeichert. Rollen bestehen einfach aus Namen und eindeutigen Bezeichnern, die Benutzern über die Zuordnungstabelle aspnet_UsersInRoles zugewiesen werden und eine m:n-Beziehung bereitstellen.
Wenn Ihr vorhandenes System zusätzlich zur Mitgliedschaft Rollen verwendet, müssen Sie die Benutzerkonten, die zugehörigen Kennwörter, die Rollen und die Rollenmitgliedschaft zu ASP.NET Core Identity migrieren. Sie werden höchstwahrscheinlich auch Ihren Code, in dem Sie derzeit Rollenprüfungen mit if-Anweisungen ausführen, so aktualisieren müssen, dass stattdessen deklarative Filter, Attribute und/oder Taghilfsprogramme verwendet werden. Wir werden uns die Überlegungen zur Migration am Ende dieses Kapitels genauer ansehen.
Konfiguration der Autorisierung in Web Forms
Um den autorisierten Zugriff auf bestimmte Seiten in einer ASP.NET Web Forms-Anwendung zu konfigurieren, geben Sie in der Regel an, dass anonyme Benutzer auf bestimmte Seiten oder Ordner nicht zugreifen dürfen. Diese Konfiguration erfolgt in der web.config-Datei:
<?xml version="1.0"?>
<configuration>
<system.web>
<authentication mode="Forms">
<forms defaultUrl="~/home.aspx" loginUrl="~/login.aspx"
slidingExpiration="true" timeout="2880"></forms>
</authentication>
<authorization>
<deny users="?" />
</authorization>
</system.web>
</configuration>
Der Konfigurationsabschnitt authentication richtet die Formularauthentifizierung für die Anwendung ein. Im Abschnitt authorization wird der Zugriff anonymer Benutzer auf die gesamte Anwendung gesperrt. Sie können jedoch differenziertere Autorisierungsregeln basierend auf dem Standort bereitstellen sowie rollenbasierte Autorisierungsprüfungen anwenden.
<location path="login.aspx">
<system.web>
<authorization>
<allow users="*" />
</authorization>
</system.web>
</location>
Die obige Konfiguration würde in Kombination mit der ersten Konfiguration anonymen Benutzer Zugriff auf die Anmeldeseite gewähren, wodurch die standortweite Beschränkung nicht authentifizierter Benutzer außer Kraft gesetzt würde.
<location path="/admin">
<system.web>
<authorization>
<allow roles="Administrators" />
<deny users="*" />
</authorization>
</system.web>
</location>
In Kombination mit den anderen Konfigurationen beschränkt die obige Konfiguration den Zugriff auf den /admin-Ordner und alle darin befindlichen Ressourcen auf Mitglieder der Rolle „Administratoren“. Diese Beschränkung könnte auch durch Einfügen einer separaten web.config-Datei innerhalb des Stamms des /admin-Ordners angewendet werden.
Autorisierungscode in Web Forms
Zusätzlich zum Konfigurieren des Zugriffs mithilfe von web.config können Sie Zugriff und Verhalten in Ihre Web Forms-Anwendung auch programmgesteuert konfigurieren. Sie können beispielsweise anhand der Benutzerrolle die Möglichkeit einschränken, bestimmte Vorgänge auszuführen oder bestimmte Daten anzuzeigen.
Dieser Code kann sowohl in der CodeBehind-Logik als auch in der Seite selbst verwendet werden:
<% if (HttpContext.Current.User.IsInRole("Administrators")) { %>
<a href="/admin">Go To Admin</a>
<% } %>
Zusätzlich zum Überprüfen der Rollenmitgliedschaft von Benutzern können Sie auch ermitteln, ob Benutzer authentifiziert sind (allerdings lässt sich dies häufig besser mithilfe der oben beschriebenen standortbasierten Konfiguration bewerkstelligen). Im Folgenden sehen Sie ein Beispiel für diesen Ansatz.
protected void Page_Load(object sender, EventArgs e)
{
if (!User.Identity.IsAuthenticated)
{
FormsAuthentication.RedirectToLoginPage();
}
if (!Roles.IsUserInRole(User.Identity.Name, "Administrators"))
{
MessageLabel.Text = "Only administrators can view this.";
SecretPanel.Visible = false;
}
}
Im obigen Code wird die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) verwendet, um zu ermitteln, ob bestimmte Elemente der Seite – z. B. ein SecretPanel – je nach Rolle des aktuellen Benutzers sichtbar sind.
In der Regel wird die Sicherheit in ASP.NET Web Forms-Anwendungen in der web.config-Datei konfiguriert. Zusätzlich werden Überprüfungen bei Bedarf in .aspx-Seiten und den zugehörigen .aspx.cs-CodeBehind-Dateien hinzugefügt. Die meisten Anwendungen nutzen den universellen Mitgliedschaftsanbieter, häufig in Zusammenhang mit den zusätzlichen Rollenanbieter.
ASP.NET Core-Identität
ASP.NET Core Identity führt weiterhin Authentifizierungs- und Autorisierungsaufgaben aus, verwendet aber andere Abstraktionen und Annahmen als die universellen Anbietern. Ein Beispiel: Das neue Identity-Modell unterstützt die Authentifizierung über Drittanbieter, sodass Benutzer sich mit einem Social Media-Konto oder einem anderen vertrauenswürdigen Authentifizierungsanbieter authentifizieren können. ASP.NET Core Identity unterstützt eine Benutzeroberfläche für häufig benötigte Seiten wie Anmeldung, Abmeldung und Registrierung. Dabei wird EF Core für den Datenzugriff verwendet, und EF Core-Migrationen dienen zum Generieren des erforderlichen Schemas zur Unterstützung des zugehörigen Datenmodells. Die Einführung in Identity in ASP.NET Core bietet eine gute Übersicht über die Funktionen von ASP.NET Core Identity sowie deren Verwendung. Wenn Sie ASP.NET Core Identity noch nicht in Ihrer Anwendung und Datenbank eingerichtet haben, hilft diese Einführung Ihnen beim Einstieg.
Rollen, Ansprüche und Richtlinien
Sowohl die universellen Anbieter als auch ASP.NET Core Identity unterstützen das Konzept „Rollen“. Sie können Rollen für Benutzer erstellen und Benutzern Rollen zuweisen. Benutzer können einer beliebigen Anzahl von Rollen angehören, und Sie können die Rollenmitgliedschaft im Rahmen Ihrer Implementierung der Autorisierung überprüfen.
Zusätzlich zu Rollen unterstützt ASP.NET Core Identity die Konzepte „Ansprüche“ und „Richtlinien“. Während eine Rolle speziell einer Gruppe von Ressourcen entsprechen muss, auf die ein Benutzer mit dieser Rolle zugreifen darf, ist ein Anspruch einfach ein Teil der Identität eines Benutzers. Ein Anspruch ist ein Name-Wert-Paar, das den Antragsteller repräsentiert, nicht jedoch die Aufgaben, die dieser ausführen kann.
Es ist möglich, die Ansprüche eines Benutzers direkt zu untersuchen und basierend auf diesen Werten zu bestimmen, ob diesem Benutzer Zugriff auf eine Ressource gewährt werden soll. Solche Überprüfungen erfolgen jedoch häufig repetitiv und im gesamten System verstreut. Ein besserer Ansatz ist hier die Definition einer Richtlinie.
Eine Autorisierungsrichtlinie besteht aus mindestens einer Anforderung. Richtlinien werden im Rahmen der Konfiguration des Autorisierungsdiensts in der ConfigureServices-Methode vonStartup.cs registriert. Der folgende Codeausschnitt beispielsweise konfiguriert eine Richtlinie namens „CanadiansOnly“, für die die Anforderung gilt, dass der Benutzer einen Anspruch für „Country“ mit dem Wert „Canada“ besitzt.
services.AddAuthorization(options =>
{
options.AddPolicy("CanadiansOnly", policy => policy.RequireClaim(ClaimTypes.Country, "Canada"));
});
Erfahren Sie mehr dazu in dieser Dokumentation zum Erstellen von benutzerdefinierten Richtlinien.
Unabhängig davon, ob Sie Richtlinien oder Rollen verwenden, können Sie angeben, dass eine bestimmte Seite in Ihrer Blazor-Anwendung eine bestimmte Richtlinie oder Rolle mit dem Attribut [Authorize] erfordert, das mit der @attribute-Anweisung angewendet wird.
So legen Sie eine Rolle als erforderlich fest:
@attribute [Authorize(Roles ="administrators")]
So legen Sie fest, dass eine Richtlinie erfüllt sein muss:
@attribute [Authorize(Policy ="CanadiansOnly")]
Wenn Sie Zugriff auf den Authentifizierungsstatus, die Rollen oder die Ansprüche eines Benutzers in Ihrem Code benötigen, gibt es im Wesentlichen zwei Möglichkeiten, dies zu erreichen. Die erste besteht darin, den Authentifizierungsstatus als kaskadierenden Parameter zu empfangen. Die zweite ist der Zugriff auf den Status mithilfe eines eingefügten AuthenticationStateProvider. Einzelheiten zu diesen Ansätzen sind in der Dokumentation zur Sicherheit in Blazor beschrieben.
Der folgende Code zeigt, wie der AuthenticationState als kaskadierender Parameter empfangen wird:
[CascadingParameter]
private Task<AuthenticationState> authenticationStateTask { get; set; }
Wenn dieser Parameter eingerichtet ist, können Sie den Benutzer mit dem folgenden Code abrufen:
var authState = await authenticationStateTask;
var user = authState.User;
Der folgende Code zeigt das Einfügen von AuthenticationStateProvider:
@using Microsoft.AspNetCore.Components.Authorization
@inject AuthenticationStateProvider AuthenticationStateProvider
Wenn der Anbieter eingerichtet ist, können Sie mit dem folgenden Code Zugriff auf den Benutzer erhalten:
AuthenticationState authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
ClaimsPrincipal user = authState.User;
if (user.Identity.IsAuthenticated)
{
// work with user.Claims and/or user.Roles
}
Hinweis: Die Komponente AuthorizeView – die weiter unten in diesem Kapitel behandelt wird – bietet eine deklarative Methode, mit der Sie steuern können, was ein Benutzer auf einer Seite oder in einer Komponente sehen kann.
Für die Arbeit mit Benutzern und Ansprüchen (in Blazor Server-Anwendungen) müssen Sie möglicherweise einen UserManager<T> einfügen (verwenden Sie IdentityUser als Standardwert). Damit können Sie Ansprüche für einen Benutzer aufzählen und ändern. Fügen Sie zunächst den Typ ein, und weisen Sie ihn einer Eigenschaft zu:
@inject UserManager<IdentityUser> MyUserManager
Verwenden Sie den Typ dann für die Arbeit mit den Ansprüchen eines Benutzers. Das folgende Beispiel zeigt, wie Sie einen Anspruch für einen Benutzer hinzufügen und dauerhaft speichern:
private async Task AddCountryClaim()
{
var authState = await AuthenticationStateProvider.GetAuthenticationStateAsync();
var user = authState.User;
var identityUser = await MyUserManager.FindByNameAsync(user.Identity.Name);
if (!user.HasClaim(c => c.Type == ClaimTypes.Country))
{
// stores the claim in the cookie
ClaimsIdentity id = new ClaimsIdentity();
id.AddClaim(new Claim(ClaimTypes.Country, "Canada"));
user.AddIdentity(id);
// save the claim in the database
await MyUserManager.AddClaimAsync(identityUser, new Claim(ClaimTypes.Country, "Canada"));
}
}
Wenn Sie mit Rollen arbeiten müssen, verfolgen Sie denselben Ansatz. Möglicherweise müssen Sie einen RoleManager<T> einfügen (verwenden Sie IdentityRole als Standardtyp), um die Rollen selbst aufzulisten und zu verwalten.
Hinweis: In Blazor-WebAssembly-Projekten müssen Sie Server-APIs bereitstellen, um diese Vorgänge auszuführen (anstatt UserManager<T> oder RoleManager<T> direkt zu verwenden). Eine Blazor-WebAssembly-Clientanwendung verwaltet Ansprüche und/oder Rollen durch sicheren Aufruf von API-Endpunkten, die für diesen Zweck verfügbar gemacht wurden.
Migrationsleitfaden
Für die Migration von ASP.NET Web Forms und universellen Anbietern zu ASP.NET Core Identity ist eine ganze Reihe von Schritten erforderlich:
- Erstellen eines ASP.NET Core Identity-Datenbankschemas in der Zieldatenbank
- Migrieren von Daten vom Schema für universelle Anbieter zum ASP.NET Core Identity-Schema
- Migrieren der Konfiguration von
web.configzu Middleware und Diensten, in der Regel in Program.cs (oder einerStartup-Klasse) - Aktualisieren einzelner Seiten mithilfe von Steuerelementen und Bedingungen zur Verwendung von Taghilfsprogrammen und neuen Identitäts-APIs
Jeder dieser Schritte wird in den folgenden Abschnitten ausführlich erläutert.
Erstellen des ASP.NET Core Identity-Schemas
Es gibt verschiedene Möglichkeiten, die erforderliche Tabellenstruktur zu erstellen, die für ASP.NET Core Identity verwendet wird. Die einfachste Möglichkeit ist die Erstellung einer neuen ASP.NET Core-Webanwendung. Wählen Sie „Webanwendung“ aus, und ändern Sie dann den Authentifizierungstyp, um einzelne Konten zu verwenden.
In der Befehlszeile können Sie dasselbe erreichen, indem Sie dotnet new webapp -au Individual ausführen. Nachdem die App erstellt wurde, führen Sie sie aus und registrieren sie in der Website. Damit sollten Sie eine Seite wie die folgende auslösen:
Klicken Sie auf die Schaltfläche „Migrationen anwenden“. Die erforderlichen Datenbanktabellen werden für Sie erstellt. Darüber hinaus sollten die Migrationsdateien wie hier gezeigt in Ihr Projekt eingefügt werden:
Mithilfe des folgenden Befehlszeilentools können Sie die Migration selbst ausführen, ohne die Webanwendung ausführen zu müssen:
dotnet ef database update
Wenn Sie lieber ein Skript ausführen möchten, um das neue Schema auf eine vorhandene Datenbank anzuwenden, können Sie dieses Migrationsskript über die Befehlszeile erstellen. Führen Sie den folgenden Befehl aus, um das Skript zu generieren:
dotnet ef migrations script -o auth.sql
Der oben stehende Befehl erzeugt ein SQL-Skript in der Ausgabedatei auth.sql, das dann für jede beliebige Datenbank ausgeführt werden kann. Wenn beim Ausführen von dotnet ef-Befehlen Probleme auftreten, stellen Sie sicher, dass die EF Core-Tools in Ihrem System installiert sind.
Falls Ihre Quelltabellen zusätzliche Spalten enthalten, müssen Sie den besten Speicherort für diese Spalten im neuen Schema ermitteln. Im Allgemeinen sollten Spalten, die sich in der Tabelle aspnet_Membership befinden, der Tabelle AspNetUsers zugeordnet werden. Spalten in aspnet_Roles sollten AspNetRoles zugeordnet werden. Alle zusätzlichen Spalten in der Tabelle aspnet_UsersInRoles würden der Tabelle AspNetUserRoles hinzugefügt.
Sie sollten auch erwägen, zusätzliche Spalten in separate Tabellen einzufügen. Solche Anpassungen des Standardidentitätsschemas würden von zukünftigen Migrationen nicht berücksichtigt.
Migrieren von Daten von universellen Anbietern zu ASP.NET Core Identity
Sobald das Schema für die Zieltabelle eingerichtet ist, ist der nächste Schritt die Migration Ihre Benutzer- und Rollendatensätze zum neuen Schema. Eine vollständige Liste der Schemaunterschiede einschließlich der Zuordnung zwischen alten und neuen Spalten finden Sie hier.
Zum Migrieren der Benutzer vom Konzept der Mitgliedschaft zu den neuen Identitätstabellen führen Sie die in der Dokumentation beschriebenen Schritte aus. Nachdem Sie diese Schritte und das bereitgestellte Skript ausgeführt haben, müssen die Benutzer bei der nächsten Anmeldung ihre Kennwörter ändern.
Es ist möglich, Benutzerkennwörter zu migrieren, aber dieser Prozess ist sehr komplex. Indem Sie die Benutzer auffordern, im Rahmen des Migrationsprozesses ihre Kennwörter zu aktualisieren und neue, eindeutige Kennwörter zu verwenden, können Sie die Sicherheit der Anwendung insgesamt erhöhen.
Migrieren von Sicherheitseinstellungen von web.config zum App-Startup
Wie oben bereits erwähnt, sind die Anbieter von ASP.NET-Mitgliedschaft und -Rollen in der Datei web.config der Anwendung konfiguriert. Da ASP.NET Core-Apps nicht an die Internetinformationsdienste gebunden sind und ein separates System für die Konfiguration verwenden, müssen diese Einstellungen an anderer Stelle konfiguriert werden. ASP.NET Core Identity wird größtenteils in der Datei Program.cs konfiguriert. Öffnen Sie das Webprojekt, das zuvor erstellt wurde (um das Schema der Identitätstabelle zu generieren), und überprüfen Sie dessen Datei Program.cs (oder Startup.cs).
Dieser Code fügt Unterstützung für EF Core und Identity hinzu:
// Add services to the container.
var connectionString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(connectionString));
builder.Services.AddDatabaseDeveloperPageExceptionFilter();
builder.Services.AddDefaultIdentity<IdentityUser>(options =>
options.SignIn.RequireConfirmedAccount = true)
.AddEntityFrameworkStores<ApplicationDbContext>();
Die AddDefaultIdentity-Erweiterungsmethode wird verwendet, um Identity zur Verwendung des Standardwerts für ApplicationDbContext und des IdentityUser-Typs des Frameworks zu konfigurieren. Wenn Sie einen benutzerdefinierten IdentityUser verwenden, stellen Sie sicher, dass Sie den Typ hier angeben. Wenn diese Erweiterungsmethoden in Ihrer Anwendung nicht funktionieren, überprüfen Sie, ob Sie über die geeigneten using-Anweisungen und die erforderlichen NuGet-Paketverweise verfügen. In Ihrem Projekt sollte beispielsweise auf irgendeine Version der Microsoft.AspNetCore.Identity.EntityFrameworkCore- und Microsoft.AspNetCore.Identity.UI-Pakete verwiesen werden.
In Program.cs sollte die erforderliche Middleware für die Website konfiguriert sein. Insbesondere müssen UseAuthentication und UseAuthorization für den richtigen Standort eingerichtet werden.
// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
app.UseMigrationsEndPoint();
}
else
{
app.UseExceptionHandler("/Error");
// The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
app.UseHsts();
}
app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.UseAuthentication();
app.UseAuthorization();
//app.MapControllers();
app.MapBlazorHub();
app.MapFallbackToPage("/_Host");
ASP.NET Identity konfiguriert in Program.cs keinen anonymen oder rollenbasierten Zugriff auf Speicherorte. Sie müssen sämtliche Konfigurationsdaten zur standortspezifischen Autorisierung in Filter in ASP.NET Core migrieren. Notieren Sie sich die Ordner und Seiten, für die solche Aktualisierungen erforderlich sind. Sie nehmen diese Änderungen im nächsten Abschnitt vor.
Aktualisieren einzelner Seiten für die Verwendung von ASP.NET Core Identity-Abstraktionen
Wenn Sie in Ihrer ASP.NET Web Forms-Anwendung web.config-Einstellungen zum Verweigern des Zugriffs durch anonyme Benutzer auf bestimmte Seiten oder Ordner eingerichtet haben, müssen Sie diese Änderungen durch Hinzufügen des [Authorize]-Attributs zu den entsprechenden Seiten migrieren:
@attribute [Authorize]
Wenn Sie darüber hinaus den Zugriff für alle Benutzer außer solchen mit einer bestimmten Rolle verweigert haben, müssen Sie dieses Verhalten durch Hinzufügen eines Attributs migrieren, das eine Rolle angibt:
@attribute [Authorize(Roles ="administrators")]
Das [Authorize]-Attribut funktioniert nur für @page-Komponenten, auf die über den Blazor-Router zugegriffen wird. Das Attribut funktioniert nicht für untergeordnete Komponenten. Für diese sollte stattdessen AuthorizeView verwendet werden.
Wenn Sie im Seitenmarkup Logik eingerichtet haben, mit der ermittelt wird, ob bestimmter Code einem bestimmten Benutzer angezeigt werden soll, können Sie diese Logik durch die Komponente AuthorizeView ersetzen. Die AuthorizeView-Komponente zeigt Benutzeroberflächenelemente selektiv an, abhängig davon, ob der Benutzer berechtigt ist, diese zu sehen. Sie macht auch eine context-Variable verfügbar, mit der auf Benutzerinformationen zugegriffen werden kann.
<AuthorizeView>
<Authorized>
<h1>Hello, @context.User.Identity.Name!</h1>
<p>You can only see this content if you are authenticated.</p>
</Authorized>
<NotAuthorized>
<h1>Authentication Failure!</h1>
<p>You are not signed in.</p>
</NotAuthorized>
</AuthorizeView>
Sie können in der Verfahrenslogik auf den Authentifizierungsstatus zugreifen, indem Sie aus einem mit dem [CascadingParameter]-Attribut konfigurierten Task<AuthenticationState auf den Benutzer zugreifen. Mit dieser Konfiguration erhalten Sie Zugriff auf den Benutzer, sodass Sie ermitteln können, ob dieser authentifiziert ist und zu einer bestimmten Rolle gehört. Wenn Sie eine Richtlinie prozedurbasiert auswerten müssen, können Sie eine Instanz des IAuthorizationService einfügen und dafür die AuthorizeAsync-Methode aufrufen. Der folgende Beispielcode zeigt, wie Sie Benutzerinformationen abrufen und einem autorisierten Benutzer ermöglichen, eine durch die content-editor-Richtlinie eingeschränkte Aufgabe auszuführen.
@using Microsoft.AspNetCore.Authorization
@inject IAuthorizationService AuthorizationService
<button @onclick="@DoSomething">Do something important</button>
@code {
[CascadingParameter]
private Task<AuthenticationState> authenticationStateTask { get; set; }
private async Task DoSomething()
{
var user = (await authenticationStateTask).User;
if (user.Identity.IsAuthenticated)
{
// Perform an action only available to authenticated (signed-in) users.
}
if (user.IsInRole("admin"))
{
// Perform an action only available to users in the 'admin' role.
}
if ((await AuthorizationService.AuthorizeAsync(user, "content-editor"))
.Succeeded)
{
// Perform an action only available to users satisfying the
// 'content-editor' policy.
}
}
}
Der AuthenticationState muss zunächst als kaskadierender Wert eingerichtet werden, bevor er auf diese Weise an einen kaskadierenden Parameter gebunden werden kann. Dies erfolgt üblicherweise mithilfe der CascadingAuthenticationState-Komponente. Diese Konfiguration wird in der Regel in App.razor eingerichtet:
<CascadingAuthenticationState>
<Router AppAssembly="@typeof(Program).Assembly">
<Found Context="routeData">
<AuthorizeRouteView RouteData="@routeData"
DefaultLayout="@typeof(MainLayout)" />
</Found>
<NotFound>
<LayoutView Layout="@typeof(MainLayout)">
<p>Sorry, there's nothing at this address.</p>
</LayoutView>
</NotFound>
</Router>
</CascadingAuthenticationState>
Zusammenfassung
Blazor verwendet dasselbe Sicherheitsmodell wie ASP.NET Core: ASP.NET Core Identity. Die Migration von universellen Anbietern zu ASP.NET Core Identity ist relativ unkompliziert, vorausgesetzt, dass nicht zu viele Anpassungen auf das ursprüngliche Datenschema angewendet wurden. Die Arbeit mit der Authentifizierung und Autorisierung der migrierten Daten in Blazor-Apps ist gut dokumentiert, mit konfigurierbarer und programmgesteuerter Unterstützung für die meisten Sicherheitsanforderungen.
Referenzen
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für