it-swarm.com.de

ASP.NET Core 2.0-Authentifizierungs-Middleware

Mit Core 1.1 folgte @blowdarts Rat und implementierte eine benutzerdefinierte Middleware:

https://stackoverflow.com/a/31465227/29821

Es hat so funktioniert:

  1. Middleware lief. Habe ein Token aus den Anforderungsköpfen geholt.
  2. Verifizierte das Token und baute, falls gültig, eine Identität (ClaimsIdentity) auf, die mehrere Ansprüche enthielt, die dann über HttpContext.User.AddIdentity () hinzugefügt wurden;
  3. In ConfigureServices using services.AddAuthorization habe ich eine Richtlinie hinzugefügt, die den von der Middleware bereitgestellten Anspruch erfordert.
  4. In den Controllern/Aktionen würde ich dann [Authorize (Roles = "eine Rolle, die die Middleware hinzugefügt hat")] verwenden.

Dies funktioniert etwas mit 2.0, außer dass, wenn das Token nicht gültig ist (Schritt 2 oben) und die Behauptung nie hinzugefügt wird, "Es wurde kein authenticationScheme angegeben und es wurde kein DefaultChallengeScheme gefunden."

Jetzt lese ich also, dass sich die Authentifizierung in 2.0 geändert hat:

https://docs.Microsoft.com/en-us/aspnet/core/migration/1x-to-2x/identity-2x

Was ist der richtige Weg für mich, um das Gleiche in ASP.NET Core 2.0 zu tun? Ich sehe kein Beispiel für eine wirklich benutzerdefinierte Authentifizierung.

78
pbz

Nach einem langen Tag, in dem ich versucht habe, dieses Problem zu lösen, habe ich endlich herausgefunden, wie Microsoft benutzerdefinierte Authentifizierungshandler für das neue Single-Middleware-Setup in Core 2.0 erstellen soll.

Nachdem ich die Dokumentation zu MSDN durchgesehen hatte, fand ich eine Klasse mit dem Namen AuthenticationHandler<TOption>, Die die Schnittstelle IAuthenticationHandler implementiert.

Von dort fand ich eine ganze Codebasis mit den vorhandenen Authentifizierungsschemata unter https://github.com/aspnet/Security

In einem dieser Beispiele wird gezeigt, wie Microsoft das JwtBearer-Authentifizierungsschema implementiert. ( https://github.com/aspnet/Security/tree/master/src/Microsoft.AspNetCore.Authentication.JwtBearer )

Ich habe den größten Teil des Codes in einen neuen Ordner kopiert und alle Dinge gelöscht, die mit JwtBearer zu tun haben.

In der Klasse JwtBearerHandler (die AuthenticationHandler<> Erweitert) gibt es eine Überschreibung für Task<AuthenticateResult> HandleAuthenticateAsync()

Ich habe in unserer alten Middleware zum Einrichten von Ansprüchen über einen benutzerdefinierten Tokenserver hinzugefügt und es gab immer noch einige Probleme mit Berechtigungen. Ich habe nur einen 200 OK Anstelle eines 401 Unauthorized Ausgegeben, als ein Token ungültig war und Ansprüche wurden nicht geltend gemacht.

Ich stellte fest, dass ich Task HandleChallengeAsync(AuthenticationProperties properties) überschrieben hatte, mit dem aus irgendeinem Grund Berechtigungen über [Authorize(Roles="")] in einem Controller festgelegt werden.

Nach dem Entfernen dieser Überschreibung hat der Code funktioniert und erfolgreich ein 401 Ausgelöst, wenn die Berechtigungen nicht übereinstimmen.

Das Wichtigste dabei ist, dass Sie jetzt keine benutzerdefinierte Middleware verwenden können. Sie müssen sie über AuthenticationHandler<> Implementieren und bei der Verwendung die DefaultAuthenticateScheme und DefaultChallengeScheme festlegen services.AddAuthentication(...).

Hier ist ein Beispiel, wie das alles aussehen sollte:

Fügen Sie in Startup.cs/ConfigureServices () Folgendes hinzu:

services.AddAuthentication(options =>
{
    // the scheme name has to match the value we're going to use in AuthenticationBuilder.AddScheme(...)
    options.DefaultAuthenticateScheme = "Custom Scheme";
    options.DefaultChallengeScheme = "Custom Scheme";
})
.AddCustomAuth(o => { });

Fügen Sie in Startup.cs/Configure () Folgendes hinzu:

app.UseAuthentication();

Erstellen Sie eine neue Datei CustomAuthExtensions.cs

public static class CustomAuthExtensions
{
    public static AuthenticationBuilder AddCustomAuth(this AuthenticationBuilder builder, Action<CustomAuthOptions> configureOptions)
    {
        return builder.AddScheme<CustomAuthOptions, CustomAuthHandler>("Custom Scheme", "Custom Auth", configureOptions);
    }
}

Erstellen Sie eine neue Datei CustomAuthOptions.cs

public class CustomAuthOptions: AuthenticationSchemeOptions
{
    public CustomAuthOptions()
    {

    }
}

Erstellen Sie eine neue Datei CustomAuthHandler.cs

internal class CustomAuthHandler : AuthenticationHandler<CustomAuthOptions>
{
    public CustomAuthHandler(IOptionsMonitor<CustomAuthOptions> options, ILoggerFactory logger, UrlEncoder encoder, ISystemClock clock) : base(options, logger, encoder, clock)
    {
        // store custom services here...
    }
    protected override async Task<AuthenticateResult> HandleAuthenticateAsync()
    {
        // build the claims and put them in "Context"; you need to import the Microsoft.AspNetCore.Authentication package
        return AuthenticateResult.NoResult();
    }
}
174
Zac

Wie der Artikel, auf den Sie verweisen, zeigt, gibt es erhebliche Änderungen in der Identität von Core 1.x zu Core 2.0. Die wichtigste Änderung besteht darin, den Middleware-Ansatz zu verlassen und mithilfe der Abhängigkeitsinjektion benutzerdefinierte Dienste zu konfigurieren. Dies bietet viel mehr Flexibilität beim Anpassen von Identity für komplexere Implementierungen. Sie möchten also von dem oben erwähnten Middleware-Ansatz Abstand nehmen und sich den Diensten zuwenden. Befolgen Sie die Migrationsschritte in dem Artikel, auf den verwiesen wird, um dieses Ziel zu erreichen. Ersetzen Sie zunächst app.UseIdentity durch app.UseAuthentication . UseIdentity wird nicht mehr empfohlen und wird in zukünftigen Versionen nicht mehr unterstützt. Ein vollständiges Beispiel zum Einfügen einer benutzerdefinierten Anspruchsumwandlung und Ausführen der Berechtigung für den Anspruch diesen Blog-Beitrag anzeigen .

4
Kevin Junghans