Übersicht über die ASP.NET Core-Authentifizierung

Von Mike Rousos

Als Authentifizierung wird der Vorgang bezeichnet, mit dem die Identität einer Benutzerin oder eines Benutzers festgestellt wird. Autorisierung ist der Vorgang, mit dem ermittelt wird, ob ein Benutzer Zugriff auf eine Ressource hat. In ASP.NET Core wird die Authentifizierung vom Authentifizierungsdienst IAuthenticationService abgewickelt, der von der Authentifizierungsmiddleware verwendet wird. Der Authentifizierungsdienst verwendet registrierte Authentifizierungshandler, um Aktionen im Zusammenhang mit der Authentifizierung auszuführen. Beispiele für Aktionen im Zusammenhang mit der Authentifizierung:

• Die Authentifizierung eines Benutzers.
• Reagieren auf den Versuch eines nicht authentifizierten Benutzers, auf eine eingeschränkte Ressource zuzugreifen.

Die registrierten Authentifizierungshandler und ihre Konfigurationsoptionen werden als „Schemas“ bezeichnet.

Authentifizierungsschemas werden festgelegt, indem die Authentifizierungsdienste bei Program.cs registriert werden:

• Durch Aufrufen einer schemaspezifischen Erweiterungsmethode nach einem Aufruf von AddAuthentication, z. B. AddJwtBearer oder AddCookie. Diese Erweiterungsmethoden verwenden AuthenticationBuilder.AddScheme, um Schemas mit den geeigneten Einstellungen zu registrieren.
• Weniger häufig wird AuthenticationBuilder.AddScheme direkt aufgerufen.

Im folgenden Code werden beispielsweise die Authentifizierungsdienste und -handler für cookie- und JWT-Bearer-Authentifizierungsschemas registriert:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

Der AddAuthentication-Parameter JwtBearerDefaults.AuthenticationScheme ist der Name des Schemas, das standardmäßig verwendet werden soll, wenn kein bestimmtes Schema angefordert wird.

Wenn mehrere Schemas verwendet werden, können Autorisierungsrichtlinien (oder Autorisierungsattribute) das Authentifizierungsschema (oder die Authentifizierungsschemas) angeben, von denen sie zur Authentifizierung des Benutzers abhängig sind. Im Beispiel oben kann das cookieauthentifizierungsschema verwendet werden, indem der Name angegeben wird (standardmäßig CookieAuthenticationDefaults.AuthenticationScheme, obwohl beim Aufruf von AddCookie ein anderer Name angegeben werden kann).

In bestimmten Fällen erfolgt der Aufruf von AddAuthentication automatisch durch andere Erweiterungsmethoden. Wenn Sie z. B. ASP.NET Core Identity verwenden, wird AddAuthentication intern aufgerufen.

Die Authentifizierungsmiddleware wird in Program.cs durch Aufrufen von UseAuthentication hinzugefügt. Durch Aufrufen von UseAuthentication wird die Middleware registriert, die die zuvor registrierten Authentifizierungsschemas verwendet. Rufen Sie UseAuthentication vor jeder Middleware auf, die voraussetzt, dass Benutzer authentifiziert sind.

Authentifizierungskonzepte

Die Authentifizierung ist verantwortlich für die Bereitstellung der ClaimsPrincipal-Klasse für die Autorisierung, um Berechtigungsentscheidungen zu treffen. Es gibt mehrere Ansätze zum Thema Authentifizierungsschema, um auszuwählen, welcher Authentifizierungshandler für die Erstellung der richtigen Ansprüche zuständig ist:

• Authentifizierungsschema
• Das Standardauthentifizierungsschema, das in den nächsten zwei Abschnitten erläutert wird
• Legen Sie HttpContext.User direkt fest.

Wenn nur ein einziges Authentifizierungsschema registriert ist, wird es zum Standardschema. Wenn mehrere Schemas registriert sind und das Standardschema nicht angegeben wird, muss das Schema im Autorisierungsattribut angegeben werden. Andernfalls wird der folgende Fehler ausgelöst:

InvalidOperationException: Es wurde kein „authenticationScheme“ angegeben und kein „DefaultChallengeScheme“ gefunden. The default schemes can be set using either AddAuthentication(string defaultScheme) or AddAuthentication(Action<AuthenticationOptions> configureOptions) (Es wurde kein authenticationScheme angegeben, und DefaultAuthenticateScheme wurde nicht gefunden. Die Standardschemas können entweder mit AddAuthentication(Zeichenfolge defaultScheme) oder AddAuthentication(Aktion configureOptions) festgelegt werden.)

DefaultScheme

Wenn nur ein einziges Authentifizierungsschema registriert ist, gilt für dieses einzelne Authentifizierungsschema Folgendes:

• Es wird automatisch als DefaultScheme verwendet.
• Es besteht dadurch nicht die Notwendigkeit, das DefaultScheme In AddAuthentication(IServiceCollection) oder AddAuthenticationCore(IServiceCollection) anzugeben.

Damit das einzelne Authentifizierungsschemas nicht automatisch als DefaultScheme verwendet wird, rufen Sie AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme") auf.

Authentifizierungsschema

Das Authentifizierungsschema kann auswählen, welcher Authentifizierungshandler zum Generieren der richtigen Ansprüche verantwortlich ist. Weitere Informationen finden Sie unter Autorisieren mit einem bestimmten Schema.

Ein Authentifizierungsschema ist ein Name, der Folgendem entspricht:

• Einem Authentifizierungshandler.
• Optionen zum Konfigurieren dieser bestimmten Instanz des Handlers.

Schemas sind als Mechanismus nützlich, um auf die Authentifizierungs-, Aufforderungs- und Unterbindungsverhalten des zugeordneten Handlers zu verweisen. Eine Autorisierungsrichtlinie kann beispielsweise anhand von Schemanamen angeben, welche Authentifizierungsschemas zum Authentifizieren des Benutzers verwendet werden sollen. Beim Konfigurieren der Authentifizierung ist es üblich, das Standardauthentifizierungsschema anzugeben. Das Standardschema wird verwendet, sofern eine Ressource kein bestimmtes Schema anfordert. Weitere Möglichkeiten:

• Angeben unterschiedlicher Standardschemas für Authentifizierungs-, Aufforderungs- und Unterbindungsaktionen.
• Kombinieren mehrerer Schemas mithilfe von Richtlinienschemas.

Authentifizierungshandler

Für einen Authentifizierungshandler gilt Folgendes:

• Es handelt sich um einen Typ, der das Verhalten eines Schemas implementiert.
• Er wird von IAuthenticationHandler oder AuthenticationHandler<TOptions> abgeleitet.
• Er trägt die Hauptverantwortung für die Authentifizierung von Benutzern.

In Abhängigkeit von der Konfiguration des Authentifizierungsschemas und vom Kontext der eingehenden Anforderung führen Authentifizierungshandler folgende Aktionen aus:

• Sie erstellen AuthenticationTicket-Objekte, die die Identität der Person darstellen, wenn die Authentifizierung erfolgreich ist.
• Sie geben „kein Ergebnis“ oder „Fehler“ zurück, wenn die Authentifizierung nicht erfolgreich ist.
• Sie verfügen über Methoden für Aufforderungs- und Unterbindungsaktionen, wenn Benutzer versuchen, auf Ressourcen zuzugreifen:
  • Sie sind für den Zugriff nicht autorisiert (Unterbindung).
  • Sie sind nicht authentifiziert (Aufforderung).

RemoteAuthenticationHandler<TOptions> vs AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> ist die Klasse für eine Authentifizierung, bei der ein Remoteauthentifizierungsschritt erforderlich ist. Nachdem der Remoteauthentifizierungsschritt beendet wurde, ruft der Handler den vom Handler festgelegten CallbackPath zurück. Der Handler beendet den Authentifizierungsschritt unter Verwendung der Informationen, die an den HandleRemoteAuthenticateAsync-Rückrufpfad übergeben werden. OAuth 2.0 und OIDC verwenden dieses Muster. JWT und Cookies verwenden dieses Muster nicht, da sie den Bearer-Header und cookie direkt für die Authentifizierung verwenden können. In diesem Fall gilt für den remote gehostete Anbieter:

• Er ist der Authentifizierungsanbieter.
• Beispiele hierfür sind Facebook, Twitter, Google, Microsoft und jeder andere OIDC-Anbieter, der die Authentifizierung von Benutzern mithilfe des Handlermechanismus übernimmt.

Authenticate

Die Authentifizierungsaktion eines Authentifizierungsschemas ist für das Erstellen der Identität der Person basierend auf dem Anforderungskontext verantwortlich. Sie gibt ein AuthenticateResult zurück, das angibt, ob die Authentifizierung erfolgreich war, und in diesem Fall außerdem die Identität der Person in einem Authentifizierungsticket zurück. Siehe AuthenticateAsync. Beispiele für die Authentifizierung:

• Ein cookie-Authentifizierungsschema, bei dem die Identität der Person aus Cookies erstellt wird.
• Ein JWT-Bearer-Schema, das ein JWT-Bearertoken zum Erstellen der Identität der Person deserialisiert und überprüft.

Herausforderung

Eine Authentifizierungsaufforderung wird durch die Autorisierung aufgerufen, wenn ein nicht authentifizierter Benutzer einen Endpunkt anfordert, für den eine Authentifizierung erforderlich ist. Eine Authentifizierungsaufforderung wird z. B. ausgegeben, wenn ein anonymer Benutzer eine eingeschränkte Ressource anfordert oder einem Anmeldelink folgt. Die Autorisierung ruft eine Aufforderung mithilfe des/der angegebenen Authentifizierungsschema(s) oder, wenn keines angegeben ist, des Standardschemas auf. Siehe ChallengeAsync. Beispiele für Authentifizierungsaufforderungen:

• Ein cookieauthentifizierungsschema, das den Benutzer auf eine Anmeldeseite umleitet.
• Ein JWT-Bearer-Schema, das ein 401-Ergebnis mit einem www-authenticate: bearer-Header zurückgibt.

Eine Aufforderungsaktion sollte dem Benutzer mitteilen können, welcher Authentifizierungsmechanismus für den Zugriff auf die angeforderte Ressource verwendet werden soll.

Unterbindung

Die Unterbindungsaktion eines Authentifizierungsschemas wird von der Autorisierung aufgerufen, wenn ein authentifizierter Benutzer versucht, auf eine Ressource zuzugreifen, für die er keine Berechtigung besitzt. Siehe ForbidAsync. Beispiele für Authentifizierungsunterbindungen:

• Ein cookieauthentifizierungsschema, das den Benutzer auf eine Seite umleitet, die anzeigt, dass der Zugriff unzulässig war.
• Ein JWT-Bearer-Schema, das ein 403-Ergebnis zurückgibt.
• Ein benutzerdefiniertes Authentifizierungsschema, das den Benutzer auf eine Seite umleitet, auf der er den Zugriff auf die Ressource anfordern kann.

Eine Unterbindungsaktion kann den Benutzer über Folgendes informieren:

• Er wird authentifiziert.
• Er ist nicht berechtigt, auf die angeforderte Ressource zuzugreifen.

Unter den folgenden Links finden Sie Informationen zu den Unterschieden zwischen Aufforderung und Unterbindung:

• Aufforderung und Unterbindung mit einem funktionsfähigen Ressourcenhandler
• Unterschiede zwischen Aufforderung und Unterbindung

Authentifizierungsanbieter pro Mandant

ASP.NET Core verfügt nicht über eine integrierte Lösung für eine mehrinstanzenfähige Authentifizierung. Obwohl Kunden mithilfe der integrierten Features eine Lösung schreiben können, sollten sie für eine mehrinstanzenfähige Authentifizierung Orchard Core, ABP Framework oder Finbuckle.MultiTenant wählen.

Orchard Core ist:

• ein mit ASP.NET Core erstelltes modulares und mehrinstanzenfähiges Open-Source-App-Framework.
• ein Content Management System (CMS), das auf Grundlage dieses App-Frameworks erstellt wurde.

Im Quellcode von Orchard Core finden Sie ein Beispiel für Authentifizierungsanbieter pro Mandant.

ABP Framework unterstützt verschiedene architekturbezogene Muster wie Modularität, Microservices, domänengesteuertes Design und Mehrinstanzenfähigkeit. Siehe ABP Framework-Quelle auf GitHub.

Finbuckle.MultiTenant:

• Quelle öffnen
• Bietet Mandantenauflösung
• Einfache
• Bietet Datenisolation
• Konfigurieren des eindeutigen App-Verhaltens für jeden Mandanten

Zusätzliche Ressourcen

• Autorisieren mit einem bestimmten Schema in ASP.NET Core
• Richtlinienschemas in ASP.NET Core
• Erstellen einer ASP.NET Core-App mit Benutzerdaten, die durch Autorisierung geschützt sind
• Globales Anfordern authentifizierter Benutzer
• Issue auf GitHub zum Verwenden mehrerer Authentifizierungsschemas

Von Mike Rousos

Als Authentifizierung wird der Vorgang bezeichnet, mit dem die Identität einer Benutzerin oder eines Benutzers festgestellt wird. Autorisierung ist der Vorgang, mit dem ermittelt wird, ob ein Benutzer Zugriff auf eine Ressource hat. In ASP.NET Core wird die Authentifizierung vom Authentifizierungsdienst IAuthenticationService abgewickelt, der von der Authentifizierungsmiddleware verwendet wird. Der Authentifizierungsdienst verwendet registrierte Authentifizierungshandler, um Aktionen im Zusammenhang mit der Authentifizierung auszuführen. Beispiele für Aktionen im Zusammenhang mit der Authentifizierung:

• Die Authentifizierung eines Benutzers.
• Reagieren auf den Versuch eines nicht authentifizierten Benutzers, auf eine eingeschränkte Ressource zuzugreifen.

Die registrierten Authentifizierungshandler und ihre Konfigurationsoptionen werden als „Schemas“ bezeichnet.

Authentifizierungsschemas werden festgelegt, indem die Authentifizierungsdienste bei Program.cs registriert werden:

• Durch Aufrufen einer schemaspezifischen Erweiterungsmethode nach einem Aufruf von AddAuthentication, z. B. AddJwtBearer oder AddCookie. Diese Erweiterungsmethoden verwenden AuthenticationBuilder.AddScheme, um Schemas mit den geeigneten Einstellungen zu registrieren.
• Weniger häufig wird AuthenticationBuilder.AddScheme direkt aufgerufen.

Im folgenden Code werden beispielsweise die Authentifizierungsdienste und -handler für cookie- und JWT-Bearer-Authentifizierungsschemas registriert:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

Der AddAuthentication-Parameter JwtBearerDefaults.AuthenticationScheme ist der Name des Schemas, das standardmäßig verwendet werden soll, wenn kein bestimmtes Schema angefordert wird.

Wenn mehrere Schemas verwendet werden, können Autorisierungsrichtlinien (oder Autorisierungsattribute) das Authentifizierungsschema (oder die Authentifizierungsschemas) angeben, von denen sie zur Authentifizierung des Benutzers abhängig sind. Im Beispiel oben kann das cookieauthentifizierungsschema verwendet werden, indem der Name angegeben wird (standardmäßig CookieAuthenticationDefaults.AuthenticationScheme, obwohl beim Aufruf von AddCookie ein anderer Name angegeben werden kann).

In bestimmten Fällen erfolgt der Aufruf von AddAuthentication automatisch durch andere Erweiterungsmethoden. Wenn Sie z. B. ASP.NET Core Identity verwenden, wird AddAuthentication intern aufgerufen.

Die Authentifizierungsmiddleware wird in Program.cs durch Aufrufen von UseAuthentication hinzugefügt. Durch Aufrufen von UseAuthentication wird die Middleware registriert, die die zuvor registrierten Authentifizierungsschemas verwendet. Rufen Sie UseAuthentication vor jeder Middleware auf, die voraussetzt, dass Benutzer authentifiziert sind.

Authentifizierungskonzepte

Die Authentifizierung ist verantwortlich für die Bereitstellung der ClaimsPrincipal-Klasse für die Autorisierung, um Berechtigungsentscheidungen zu treffen. Es gibt mehrere Ansätze zum Thema Authentifizierungsschema, um auszuwählen, welcher Authentifizierungshandler für die Erstellung der richtigen Ansprüche zuständig ist:

• Authentifizierungsschema
• Das Standardauthentifizierungsschema, das im nächsten Abschnitt erläutert wird
• Legen Sie HttpContext.User direkt fest.

Es gibt keine automatische Überprüfung von Schemas. Wenn das Standardschema nicht angegeben wird, muss das Schema im Autorisierungsattribut angegeben werden. andernfalls wird der folgende Fehler ausgelöst:

InvalidOperationException: Es wurde kein „authenticationScheme“ angegeben und kein „DefaultChallengeScheme“ gefunden. The default schemes can be set using either AddAuthentication(string defaultScheme) or AddAuthentication(Action<AuthenticationOptions> configureOptions) (Es wurde kein authenticationScheme angegeben, und DefaultAuthenticateScheme wurde nicht gefunden. Die Standardschemas können entweder mit AddAuthentication(Zeichenfolge defaultScheme) oder AddAuthentication(Aktion configureOptions) festgelegt werden.)

Authentifizierungsschema

Das Authentifizierungsschema kann auswählen, welcher Authentifizierungshandler zum Generieren der richtigen Ansprüche verantwortlich ist. Weitere Informationen finden Sie unter Autorisieren mit einem bestimmten Schema.

Ein Authentifizierungsschema ist ein Name, der Folgendem entspricht:

• Einem Authentifizierungshandler.
• Optionen zum Konfigurieren dieser bestimmten Instanz des Handlers.

Schemas sind als Mechanismus nützlich, um auf die Authentifizierungs-, Aufforderungs- und Unterbindungsverhalten des zugeordneten Handlers zu verweisen. Eine Autorisierungsrichtlinie kann beispielsweise anhand von Schemanamen angeben, welche Authentifizierungsschemas zum Authentifizieren des Benutzers verwendet werden sollen. Beim Konfigurieren der Authentifizierung ist es üblich, das Standardauthentifizierungsschema anzugeben. Das Standardschema wird verwendet, sofern eine Ressource kein bestimmtes Schema anfordert. Weitere Möglichkeiten:

• Angeben unterschiedlicher Standardschemas für Authentifizierungs-, Aufforderungs- und Unterbindungsaktionen.
• Kombinieren mehrerer Schemas mithilfe von Richtlinienschemas.

Authentifizierungshandler

Für einen Authentifizierungshandler gilt Folgendes:

• Es handelt sich um einen Typ, der das Verhalten eines Schemas implementiert.
• Er wird von IAuthenticationHandler oder AuthenticationHandler<TOptions> abgeleitet.
• Er trägt die Hauptverantwortung für die Authentifizierung von Benutzern.

In Abhängigkeit von der Konfiguration des Authentifizierungsschemas und vom Kontext der eingehenden Anforderung führen Authentifizierungshandler folgende Aktionen aus:

• Sie erstellen AuthenticationTicket-Objekte, die die Identität der Person darstellen, wenn die Authentifizierung erfolgreich ist.
• Sie geben „kein Ergebnis“ oder „Fehler“ zurück, wenn die Authentifizierung nicht erfolgreich ist.
• Sie verfügen über Methoden für Aufforderungs- und Unterbindungsaktionen, wenn Benutzer versuchen, auf Ressourcen zuzugreifen:
  • Sie sind für den Zugriff nicht autorisiert (Unterbindung).
  • Sie sind nicht authentifiziert (Aufforderung).

RemoteAuthenticationHandler<TOptions> vs AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> ist die Klasse für eine Authentifizierung, bei der ein Remoteauthentifizierungsschritt erforderlich ist. Nachdem der Remoteauthentifizierungsschritt beendet wurde, ruft der Handler den vom Handler festgelegten CallbackPath zurück. Der Handler beendet den Authentifizierungsschritt unter Verwendung der Informationen, die an den HandleRemoteAuthenticateAsync-Rückrufpfad übergeben werden. OAuth 2.0 und OIDC verwenden dieses Muster. JWT und Cookies verwenden dieses Muster nicht, da sie den Bearer-Header und cookie direkt für die Authentifizierung verwenden können. In diesem Fall gilt für den remote gehostete Anbieter:

• Er ist der Authentifizierungsanbieter.
• Beispiele hierfür sind Facebook, Twitter, Google, Microsoft und jeder andere OIDC-Anbieter, der die Authentifizierung von Benutzern mithilfe des Handlermechanismus übernimmt.

Authenticate

Die Authentifizierungsaktion eines Authentifizierungsschemas ist für das Erstellen der Identität der Person basierend auf dem Anforderungskontext verantwortlich. Sie gibt ein AuthenticateResult zurück, das angibt, ob die Authentifizierung erfolgreich war, und in diesem Fall außerdem die Identität der Person in einem Authentifizierungsticket zurück. Siehe AuthenticateAsync. Beispiele für die Authentifizierung:

• Ein cookie-Authentifizierungsschema, bei dem die Identität der Person aus Cookies erstellt wird.
• Ein JWT-Bearer-Schema, das ein JWT-Bearertoken zum Erstellen der Identität der Person deserialisiert und überprüft.

Herausforderung

Eine Authentifizierungsaufforderung wird durch die Autorisierung aufgerufen, wenn ein nicht authentifizierter Benutzer einen Endpunkt anfordert, für den eine Authentifizierung erforderlich ist. Eine Authentifizierungsaufforderung wird z. B. ausgegeben, wenn ein anonymer Benutzer eine eingeschränkte Ressource anfordert oder einem Anmeldelink folgt. Die Autorisierung ruft eine Aufforderung mithilfe des/der angegebenen Authentifizierungsschema(s) oder, wenn keines angegeben ist, des Standardschemas auf. Siehe ChallengeAsync. Beispiele für Authentifizierungsaufforderungen:

• Ein cookieauthentifizierungsschema, das den Benutzer auf eine Anmeldeseite umleitet.
• Ein JWT-Bearer-Schema, das ein 401-Ergebnis mit einem www-authenticate: bearer-Header zurückgibt.

Eine Aufforderungsaktion sollte dem Benutzer mitteilen können, welcher Authentifizierungsmechanismus für den Zugriff auf die angeforderte Ressource verwendet werden soll.

Unterbindung

Die Unterbindungsaktion eines Authentifizierungsschemas wird von der Autorisierung aufgerufen, wenn ein authentifizierter Benutzer versucht, auf eine Ressource zuzugreifen, für die er keine Berechtigung besitzt. Siehe ForbidAsync. Beispiele für Authentifizierungsunterbindungen:

• Ein cookieauthentifizierungsschema, das den Benutzer auf eine Seite umleitet, die anzeigt, dass der Zugriff unzulässig war.
• Ein JWT-Bearer-Schema, das ein 403-Ergebnis zurückgibt.
• Ein benutzerdefiniertes Authentifizierungsschema, das den Benutzer auf eine Seite umleitet, auf der er den Zugriff auf die Ressource anfordern kann.

Eine Unterbindungsaktion kann den Benutzer über Folgendes informieren:

• Er wird authentifiziert.
• Er ist nicht berechtigt, auf die angeforderte Ressource zuzugreifen.

Unter den folgenden Links finden Sie Informationen zu den Unterschieden zwischen Aufforderung und Unterbindung:

• Aufforderung und Unterbindung mit einem funktionsfähigen Ressourcenhandler
• Unterschiede zwischen Aufforderung und Unterbindung

Authentifizierungsanbieter pro Mandant

ASP.NET Core verfügt nicht über eine integrierte Lösung für eine mehrinstanzenfähige Authentifizierung. Obwohl Kunden mithilfe der integrierten Features eine Lösung schreiben können, sollten sie für eine mehrinstanzenfähige Authentifizierung Orchard Core oder ABP Framework wählen.

Orchard Core ist:

• ein mit ASP.NET Core erstelltes modulares und mehrinstanzenfähiges Open-Source-App-Framework.
• ein Content Management System (CMS), das auf Grundlage dieses App-Frameworks erstellt wurde.

Im Quellcode von Orchard Core finden Sie ein Beispiel für Authentifizierungsanbieter pro Mandant.

ABP Framework unterstützt verschiedene architekturbezogene Muster wie Modularität, Microservices, domänengesteuertes Design und Mehrinstanzenfähigkeit. Siehe ABP Framework-Quelle auf GitHub.

Zusätzliche Ressourcen

• Autorisieren mit einem bestimmten Schema in ASP.NET Core
• Richtlinienschemas in ASP.NET Core
• Erstellen einer ASP.NET Core-App mit Benutzerdaten, die durch Autorisierung geschützt sind
• Globales Anfordern authentifizierter Benutzer
• Issue auf GitHub zum Verwenden mehrerer Authentifizierungsschemas

Von Mike Rousos

Als Authentifizierung wird der Vorgang bezeichnet, mit dem die Identität einer Benutzerin oder eines Benutzers festgestellt wird. Autorisierung ist der Vorgang, mit dem ermittelt wird, ob ein Benutzer Zugriff auf eine Ressource hat. In ASP.NET Core wird die Authentifizierung vom Authentifizierungsdienst IAuthenticationService abgewickelt, der von der Authentifizierungsmiddleware verwendet wird. Der Authentifizierungsdienst verwendet registrierte Authentifizierungshandler, um Aktionen im Zusammenhang mit der Authentifizierung auszuführen. Beispiele für Aktionen im Zusammenhang mit der Authentifizierung:

• Die Authentifizierung eines Benutzers.
• Reagieren auf den Versuch eines nicht authentifizierten Benutzers, auf eine eingeschränkte Ressource zuzugreifen.

Die registrierten Authentifizierungshandler und ihre Konfigurationsoptionen werden als „Schemas“ bezeichnet.

Authentifizierungsschemas werden festgelegt, indem die Authentifizierungsdienste bei Startup.ConfigureServices registriert werden:

• Durch Aufrufen einer schemaspezifischen Erweiterungsmethode nach einem Aufruf von AddAuthentication (z. B. AddJwtBearer oder AddCookie). Diese Erweiterungsmethoden verwenden AuthenticationBuilder.AddScheme, um Schemas mit den geeigneten Einstellungen zu registrieren.
• Weniger häufig wird AuthenticationBuilder.AddScheme direkt aufgerufen.

Im folgenden Code werden beispielsweise die Authentifizierungsdienste und -handler für cookie- und JWT-Bearer-Authentifizierungsschemas registriert:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => Configuration.Bind("CookieSettings", options));

Der AddAuthentication-Parameter JwtBearerDefaults.AuthenticationScheme ist der Name des Schemas, das standardmäßig verwendet werden soll, wenn kein bestimmtes Schema angefordert wird.

Wenn mehrere Schemas verwendet werden, können Autorisierungsrichtlinien (oder Autorisierungsattribute) das Authentifizierungsschema (oder die Authentifizierungsschemas) angeben, von denen sie zur Authentifizierung des Benutzers abhängig sind. Im Beispiel oben kann das cookieauthentifizierungsschema verwendet werden, indem der Name angegeben wird (standardmäßig CookieAuthenticationDefaults.AuthenticationScheme, obwohl beim Aufruf von AddCookie ein anderer Name angegeben werden kann).

In bestimmten Fällen erfolgt der Aufruf von AddAuthentication automatisch durch andere Erweiterungsmethoden. Wenn Sie z. B. ASP.NET Core Identity verwenden, wird AddAuthentication intern aufgerufen.

Die Authentifizierungsmiddleware wird in Startup.Configure durch Aufrufen von UseAuthentication hinzugefügt. Durch Aufrufen von UseAuthentication wird die Middleware registriert, die die zuvor registrierten Authentifizierungsschemas verwendet. Rufen Sie UseAuthentication vor jeder Middleware auf, die voraussetzt, dass Benutzer authentifiziert sind. Wenn Sie das Endpunktrouting verwenden, muss der Aufruf von UseAuthentication:

• nach UseRouting stehen, damit die Routeninformationen für Authentifizierungsentscheidungen verfügbar sind.
• vor UseEndpoints stehen, damit Benutzer vor dem Zugriff auf die Endpunkte authentifiziert werden.

Authentifizierungskonzepte

Die Authentifizierung ist verantwortlich für die Bereitstellung der ClaimsPrincipal-Klasse für die Autorisierung, um Berechtigungsentscheidungen zu treffen. Es gibt mehrere Ansätze zum Thema Authentifizierungsschema, um auszuwählen, welcher Authentifizierungshandler für die Erstellung der richtigen Ansprüche zuständig ist:

• Authentifizierungsschema
• Das Standardauthentifizierungsschema, das im nächsten Abschnitt erläutert wird
• Legen Sie HttpContext.User direkt fest.

Es gibt keine automatische Überprüfung von Schemas. Wenn das Standardschema nicht angegeben wird, muss das Schema im Autorisierungsattribut angegeben werden. andernfalls wird der folgende Fehler ausgelöst:

InvalidOperationException: Es wurde kein „authenticationScheme“ angegeben und kein „DefaultChallengeScheme“ gefunden. The default schemes can be set using either AddAuthentication(string defaultScheme) or AddAuthentication(Action<AuthenticationOptions> configureOptions) (Es wurde kein authenticationScheme angegeben, und DefaultAuthenticateScheme wurde nicht gefunden. Die Standardschemas können entweder mit AddAuthentication(Zeichenfolge defaultScheme) oder AddAuthentication(Aktion configureOptions) festgelegt werden.)

Authentifizierungsschema

Das Authentifizierungsschema kann auswählen, welcher Authentifizierungshandler zum Generieren der richtigen Ansprüche verantwortlich ist. Weitere Informationen finden Sie unter Autorisieren mit einem bestimmten Schema.

Ein Authentifizierungsschema ist ein Name, der Folgendem entspricht:

• Einem Authentifizierungshandler.
• Optionen zum Konfigurieren dieser bestimmten Instanz des Handlers.

Schemas sind als Mechanismus nützlich, um auf die Authentifizierungs-, Aufforderungs- und Unterbindungsverhalten des zugeordneten Handlers zu verweisen. Eine Autorisierungsrichtlinie kann beispielsweise anhand von Schemanamen angeben, welche Authentifizierungsschemas zum Authentifizieren des Benutzers verwendet werden sollen. Beim Konfigurieren der Authentifizierung ist es üblich, das Standardauthentifizierungsschema anzugeben. Das Standardschema wird verwendet, sofern eine Ressource kein bestimmtes Schema anfordert. Weitere Möglichkeiten:

• Angeben unterschiedlicher Standardschemas für Authentifizierungs-, Aufforderungs- und Unterbindungsaktionen.
• Kombinieren mehrerer Schemas mithilfe von Richtlinienschemas.

Authentifizierungshandler

Für einen Authentifizierungshandler gilt Folgendes:

• Es handelt sich um einen Typ, der das Verhalten eines Schemas implementiert.
• Er wird von IAuthenticationHandler oder AuthenticationHandler<TOptions> abgeleitet.
• Er trägt die Hauptverantwortung für die Authentifizierung von Benutzern.

In Abhängigkeit von der Konfiguration des Authentifizierungsschemas und vom Kontext der eingehenden Anforderung führen Authentifizierungshandler folgende Aktionen aus:

• Sie erstellen AuthenticationTicket-Objekte, die die Identität der Person darstellen, wenn die Authentifizierung erfolgreich ist.
• Sie geben „kein Ergebnis“ oder „Fehler“ zurück, wenn die Authentifizierung nicht erfolgreich ist.
• Sie verfügen über Methoden für Aufforderungs- und Unterbindungsaktionen, wenn Benutzer versuchen, auf Ressourcen zuzugreifen:
  • Sie sind für den Zugriff nicht autorisiert (Unterbindung).
  • Sie sind nicht authentifiziert (Aufforderung).

RemoteAuthenticationHandler<TOptions> vs AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> ist die Klasse für eine Authentifizierung, bei der ein Remoteauthentifizierungsschritt erforderlich ist. Nachdem der Remoteauthentifizierungsschritt beendet wurde, ruft der Handler den vom Handler festgelegten CallbackPath zurück. Der Handler beendet den Authentifizierungsschritt unter Verwendung der Informationen, die an den HandleRemoteAuthenticateAsync-Rückrufpfad übergeben werden. OAuth 2.0 und OIDC verwenden dieses Muster. JWT und Cookies verwenden dieses Muster nicht, da sie den Bearer-Header und cookie direkt für die Authentifizierung verwenden können. In diesem Fall gilt für den remote gehostete Anbieter:

• Er ist der Authentifizierungsanbieter.
• Beispiele hierfür sind Facebook, Twitter, Google, Microsoft und jeder andere OIDC-Anbieter, der die Authentifizierung von Benutzern mithilfe des Handlermechanismus übernimmt.

Authenticate

Die Authentifizierungsaktion eines Authentifizierungsschemas ist für das Erstellen der Identität der Person basierend auf dem Anforderungskontext verantwortlich. Sie gibt ein AuthenticateResult zurück, das angibt, ob die Authentifizierung erfolgreich war, und in diesem Fall außerdem die Identität der Person in einem Authentifizierungsticket zurück. Siehe AuthenticateAsync. Beispiele für die Authentifizierung:

• Ein cookie-Authentifizierungsschema, bei dem die Identität der Person aus Cookies erstellt wird.
• Ein JWT-Bearer-Schema, das ein JWT-Bearertoken zum Erstellen der Identität der Person deserialisiert und überprüft.

Herausforderung

Eine Authentifizierungsaufforderung wird durch die Autorisierung aufgerufen, wenn ein nicht authentifizierter Benutzer einen Endpunkt anfordert, für den eine Authentifizierung erforderlich ist. Eine Authentifizierungsaufforderung wird z. B. ausgegeben, wenn ein anonymer Benutzer eine eingeschränkte Ressource anfordert oder einem Anmeldelink folgt. Die Autorisierung ruft eine Aufforderung mithilfe des/der angegebenen Authentifizierungsschema(s) oder, wenn keines angegeben ist, des Standardschemas auf. Siehe ChallengeAsync. Beispiele für Authentifizierungsaufforderungen:

• Ein cookieauthentifizierungsschema, das den Benutzer auf eine Anmeldeseite umleitet.
• Ein JWT-Bearer-Schema, das ein 401-Ergebnis mit einem www-authenticate: bearer-Header zurückgibt.

Eine Aufforderungsaktion sollte dem Benutzer mitteilen können, welcher Authentifizierungsmechanismus für den Zugriff auf die angeforderte Ressource verwendet werden soll.

Unterbindung

Die Unterbindungsaktion eines Authentifizierungsschemas wird von der Autorisierung aufgerufen, wenn ein authentifizierter Benutzer versucht, auf eine Ressource zuzugreifen, für die er keine Berechtigung besitzt. Siehe ForbidAsync. Beispiele für Authentifizierungsunterbindungen:

• Ein cookieauthentifizierungsschema, das den Benutzer auf eine Seite umleitet, die anzeigt, dass der Zugriff unzulässig war.
• Ein JWT-Bearer-Schema, das ein 403-Ergebnis zurückgibt.
• Ein benutzerdefiniertes Authentifizierungsschema, das den Benutzer auf eine Seite umleitet, auf der er den Zugriff auf die Ressource anfordern kann.

Eine Unterbindungsaktion kann den Benutzer über Folgendes informieren:

• Er wird authentifiziert.
• Er ist nicht berechtigt, auf die angeforderte Ressource zuzugreifen.

Unter den folgenden Links finden Sie Informationen zu den Unterschieden zwischen Aufforderung und Unterbindung:

• Aufforderung und Unterbindung mit einem funktionsfähigen Ressourcenhandler
• Unterschiede zwischen Aufforderung und Unterbindung

Authentifizierungsanbieter pro Mandant

Das ASP.NET Core-Framework verfügt nicht über eine integrierte Lösung für eine mehrinstanzenfähige Authentifizierung. Kunden können zwar eine App mit mehrinstanzenfähiger Authentifizierung schreiben, sollten jedoch eines der folgenden ASP.NET Core-Anwendungsframeworks verwenden, die die mehrinstanzenfähige Authentifizierung unterstützen:

Orchard Core

Orchard Core. Im Quellcode von Orchard Core finden Sie ein Beispiel für Authentifizierungsanbieter pro Mandant.

ABP Framework

ABP Framework unterstützt verschiedene architekturbezogene Muster wie Modularität, Microservices, domänengesteuertes Design und Mehrinstanzenfähigkeit. Siehe ABP Framework-Quelle auf GitHub.

Zusätzliche Ressourcen

• Autorisieren mit einem bestimmten Schema in ASP.NET Core
• Richtlinienschemas in ASP.NET Core
• Erstellen einer ASP.NET Core-App mit Benutzerdaten, die durch Autorisierung geschützt sind
• Globales Anfordern authentifizierter Benutzer
• Issue auf GitHub zum Verwenden mehrerer Authentifizierungsschemas