2017-10-04

September 2017

Band 32, Nummer 9

Dieser Artikel wurde maschinell übersetzt.

Cutting Edge: Cookies, Ansprüche und Authentifizierung in ASP.NET Core

Durch Dino Esposito | September 2017

Dino Esposito Ein Großteil der Dokumentation über das Design der Authentifizierung in ASP.NET Core konzentriert sich auf die Verwendung von ASP.NET Identity Framework. In diesem Kontext scheinbar Dinge geändert haben, viele oder, genauer gesagt, alles, was die Änderungen, die in der Infrastruktur aufgetreten sind in den Folds Framework verborgen wurde verfügen, damit es nahezu gleich auf der Oberfläche dargestellt.

Bei Betrachtung von Benutzerauthentifizierung in ASP.NET Core außerhalb der vertraut Territory von ASP.NET Identity vielleicht Sie finden es völlig anders, was sie in früheren Versionen war. ASP.NET Identity ist ein vollwertige, umfassende, big-Framework, das Ausgangsstruktur ist alles, was Sie benötigen zum Authentifizieren von Benutzern über einfache Anmeldeinformationen aus einer einfachen Datenbanktabelle. In diesem Fall sehen Sie, dass der allgemeine Ansatz für die Authentifizierung weiterhin auf vertrauten Konzepten wie Prinzipal, Anmeldeformular, herausforderungs- und Autorisierung Attribute basierend mit dem Unterschied, dass die Möglichkeit, die Sie implementiert grundlegend anders ist. In diesem Monat-Spalte werde ich die Cookie-Authentifizierung-API untersuchen, wie in ASP.NET Core, einschließlich der Fakten Core externe Authentifizierung zur Verfügung gestellt.

Grundlage für die Authentifizierung in ASP.NET

In ASP.NET umfasst eine Benutzerauthentifizierung für die Verwendung von Cookies. Alle Benutzer, die versuchen, eine private-Seite besuchen werden einer Anmeldeseite umgeleitet, wenn sie ein gültige Authentifizierungscookie transportieren. Die Anmeldeseite, nachdem Creden-Tials, wenn Sie überprüft haben bereitgestellt werden. das Cookie, das dann werden nachfolgenden Anforderungen von diesem Benutzer über den gleichen Browser nachrichtenkörperinhalts bis zu deren Ablauf ausgibt. Dies ist der gleiche grundlegende Workflow, die möglicherweise von früheren Versionen von ASP.NET bekannt sind. In ASP.NET Core sieht er nur anders aufgrund der verschiedenen Middleware und die andere Konfiguration von der Common Language Runtime-Umgebung.

Es gibt zwei wichtige Änderungen in ASP.NET Core für diejenigen aus einer ASP.NET Web Forms- und ASP.NET MVC-Umfeld stammen. Zunächst ist es nicht mehr eine Datei "Web.config", d. h. diese Konfiguration von den Anmeldepfad Cookienamen und Ablauf anders abgerufen wird. Zweitens IPrincipal-Objekt – das Objekt, mit dem Modell Benutzeridentität – basiert nun auf Ansprüche statt der einfachen Benutzername. Zum Aktivieren der Cookieauthentifizierung in einer ganz neuen ASP.NET Core 1.x-Anwendung zuerst verweisen, das Microsoft.AspNetCore.Authentication.Cookies-Paket, und fügen Sie dann den Codeausschnitt im Abbildung 1.

Abbildung 1 Middleware für Cookieauthentifizierung registrieren

// This code is for ASP.NET Core 1.x
public void Configure(IApplicationBuilder app)
{
  app.UseCookieAuthentication(new CookieAuthenticationOptions
  {
    AutomaticAuthenticate = true,
    AutomaticChallenge = true,
    AuthenticationScheme = "Cookies",
    CookieName = "YourAppCookieName",
    LoginPath = new PathString("/Account/Login"),
    ExpireTimeSpan = TimeSpan.FromMinutes(60),
    SlidingExpiration = true,
    ReturnUrlParameter = "original",
    AccessDeniedPath = new PathString("/Account/Denied")
  });
}

Die meisten Informationen, die klassische ASP.NET MVC-Anwendungen, die im Abschnitt < Authentication > der Datei "Web.config" gespeichert als middlewareoptionen konfiguriert sind. Der Codeausschnitt in Abbildung 1 Softwaresystem erfassen kann kanonische Optionen, die Sie auswählen möchten. Abbildung 2 werden alle im Detail beschrieben.

Abbildung 2 Cookie-Authentifizierungsoptionen.

Eigenschaft	Beschreibung
AccessDeniedPath	Gibt den Pfad, in dem ein authentifizierter Benutzer umgeleitet wird, wenn die bereitgestellte Identität über die Berechtigung zum Anzeigen der angeforderten Ressource verfügt. Identisch mit der einen Statuscode "HTTP 403" abrufen.
AutomaticAuthenticate	Gibt an, die Middleware für jede Anforderung ausgeführt wird und versucht, Cookie überprüfen und erstellen eine Identity-Objekts aus dem Inhalt.
AutomaticChallenge	Gibt an, dass die Middleware den Browser zu einer Anmeldeseite um umleitet, wenn der Benutzer nicht authentifiziert oder der Zugriff verweigert Seite, wenn der Benutzer authentifiziert ist, aber nicht für die angeforderte Ressource autorisiert.
AuthenticationScheme	Der Name der Middleware. Diese Eigenschaft funktioniert in Verbindung mit AutomaticChallenge, um die authentifizierungsmiddleware auf eine Anforderungsbasis selektiv zu übernehmen.
CookieName	Der Name des Authentifizierungscookies erstellt wird.
ExpireTimeSpan	Legt die Ablaufzeit des Authentifizierungscookies fest. Ob die Zeit hat, als absolute oder relative bestimmt ist, wird durch den Wert der Eigenschaft SlidingExpiration bestimmt.
LoginPath	Gibt den Pfad, in dem ein anonymer Benutzer umgeleitet wird, sich mit eigenen Anmeldeinformationen anmelden.
ReturnUrlParameter	Der Name des Parameters verwendet wird, um die ursprünglich angeforderte URL zu übergeben, die die Umleitung zu der Anmeldeseite bei anonymen Benutzern verursacht hat.
SlidingExpiration	Gibt an, ob der ExpireTimeSpan absolut oder relativ ist. Im letzteren Fall wird der Wert als ein Intervall angesehen, und die Middleware wird das Cookie wiederholen, wenn mehr als die Hälfte der Intervall verstrichen ist.

Beachten Sie, dass Pfadeigenschaften nicht vom Typzeichenfolge sind. LoginPath und AccessDeniedPath sind vom Typ PathString-Wert, der, die im Vergleich zu den einfachen Zeichenfolgentyp Schalfläche ordnungsgemäßen Escapezeichen beim Erstellen einer Anforderungs-URLs.

Der Gesamtentwurf der benutzerworkflow für die Authentifizierung in ASP.NET Core erhalten Sie eine unvergleichlich hohe Menge an flexibler rüfen. Jeden Aspekt des Zertifikats kann werden angepasst werden. Beispielsweise sehen wir, wie Sie die Authentifizierung Arbeitsabläufe auf eine Anforderungsbasis verwendete steuern können.

Umgang mit mehreren Authentifizierungsschemen

AutomaticChallenge auf "false" festlegen, weisen Sie die Middleware nicht, die für die [Authorize] Herausforderungen, die durch pro bilden, z. B. eine Umleitung zu reagieren. Wenn keine Middleware die Herausforderung behandelt wird, wird eine Ausnahme ausgelöst. Automatische Herausforderung wurde von der Norm in früheren Versionen von ASP.NET und gab es fast nichts darüber ausführen konnte.

In ASP.NET Core, können Sie mehrere registrieren und verschiedene Teile des authentifizierungsmiddleware bestimmen algorithmisch oder über die Konfiguration, welche Middleware muss für jede Anforderung verwendet werden. Wenn mehrere authentifizierungsmiddleware verwendet wird, kann die automatische Authentifizierung auf mehrere Middleware "true" sein. AutomaticChallenge, sollte stattdessen nur auf 0 (null) oder eine Middleware aktiviert werden. Weitere Informationen finden Sie unter bit.ly/2tS07Sm.

Allgemeine Beispiele für das authentifizierungsmiddleware werden Cookie-basierte Authentifizierung, trägerauthentifizierung, Authentifizierung, die über soziale Netzwerke oder eine Identity-Server und was Sie jemals vorstellen können, implementieren. Nehmen wir an, dass Sie den folgenden Code in der Methode Konfigurieren Ihrer Startklasse haben:

app.UseCookieAuthentication(new CookieAuthenticationOptions()
{
  AuthenticationScheme = "Cookies",
  LoginPath = new PathString("/Account/Login/"),
  AutomaticAuthenticate = true
});
app.UseIdentityServerAuthentication(new IdentityServerAuthenticationOptions
{
  AuthenticationScheme = "Bearer",
  AutomaticAuthenticate = true 
}

Denken Sie daran, dass es Konstanten sind, mit denen anstelle von Magic Zeichenfolgen wie "Cookies" verwendet werden, nur um Tippfehler zu beschränken. Insbesondere kann die Zeichenfolge "Cookies" wie folgt ersetzt werden:

AuthenticationScheme = CookieAuthenticationDefaults.AuthenticationScheme

Beachten Sie, dass UseIdentityServerAuthentication gehört zu den Identity Server-Framework ist nicht Teil des ASP.NET Core-Framework (siehe github.com/IdentityServer). Um das Authentifizierungsschema für einzelne Anforderungen auszuwählen, verwenden Sie ein neues Attribut in der Authorize-Attribut, das in ASP.NET MVC Aktionen als unterliegen Authentifizierung und Autorisierung markiert:

[Authorize(ActiveAuthenticationSchemes = "Bearer")]
public class ApiController : Controller
{
  // Your API action methods here
  ...
}

Im Endeffekt des Codeausschnitts ist, dass die Identität des Benutzers alle öffentlichen Endpunkte der Beispielklasse ApiController unterliegen, wie durch das Bearer-Token authentifiziert.

Modellieren die Identität des Benutzers

In ASP.NET definiert die IPrincipal-Schnittstelle der Softwarevertrag, der den Kern der Identität des Benutzers definiert. Der angemeldete Benutzer wird durch die Benutzer-Eigenschaft der HttpContext Controller Eigenschaft verfügbar gemacht. IPrincipal hat dieselbe Implementierung in ASP.NET 4.x (einschließlich ASP.NET-MVC) und ASP.NET Core. Ist jedoch nicht in ASP.NET Core das standardprinzipalobjekt GenericPrincipal, aber die neue ClaimsPrincipal-Typ. Der Unterschied ist relevant.

GenericPrincipal schließt eine der wichtigsten Benutzerinformationen: der Benutzername –, obwohl das Authentifizierungsticket im Cookie verschlüsselte benutzerdefinierte Benutzerdaten hinzugefügt werden können. Im Laufe der Jahre ist der einzige Benutzername für die Anforderungen der moderne Anwendungen zu wenig geworden. Die Rolle des Benutzers, ebenso wie eine andere Blöcke von Informationen, die meisten deutlich Bild und des Anzeigenamens, angezeigt werden absolut erforderlich heute jede realistische Anwendung zum Erstellen von eigenen benutzerdefinierten Prinzipal Typ oder die Abfrage-Benutzerinformationen für jede und jede erzwingen die Anforderung mit dem Benutzernamen als Schlüssel. ClaimsPrincipal kann nur brilliantly das Problem gelöst.

Ein Anspruch ist ein Schlüssel/Wert-Paar, eine Eigenschaft des angemeldeten Benutzers beschreibt. Die Liste der Eigenschaften hängt von der Anwendung ist, aber Name und die Rolle mindestens enthält. Ansprüche werden in anderen Worten: der ASP.NET Core zur Modell Identitätsinformationen. Ansprüche können aus beliebigen Quellen gelesen werden, ob die Datenbanken, Cloud- oder lokalen Speicher hartcodiert selbst. Die Claim-Klasse ist so einfach wie diese:

public class Claim
{
  public string Type { get; }
  public string Value { get; }
  
  // More properties ...
}

Der Anmeldevorgang in ASP.NET Core durchläuft drei Klassen: Anspruch, ClaimIdentity und ClaimsPrincipal.
Erfassen der Liste der Ansprüche ist für das Auffüllen eines Arrays von Objekten Anspruch müssen lediglich:

public Claims[] LoadClaims(User user)
{
  var claims = new[]
  {
    new Claim(ClaimTypes.Name, user.UserName),
    new Claim(ClaimTypes.Role, user.Role),
    new Claim("Picture", user.Picture)
  };
  return claims;
}

Der Name des Anspruchs handelt es sich um eine einfache beschreibenden Namen als Zeichenfolge dargestellt. Am häufigsten verwendete Anspruchstypen haben jedoch in der ClaimTypes-Klasse als Konstanten gruppiert wurden. Vor dem Erstellen des Prinzipals, der erforderlich ist, rufen Sie die authentifizierungsworkflow abgeschlossen wurde, müssen Sie halten der Identity-Objekts abrufen:

var identity = new ClaimsIdentity(claims, "Password");

Das erste Argument ist selbsterklärend: die Liste der Ansprüche im Zusammenhang mit der erstellt wird. Das zweite Argument ist eine Zeichenfolge, die auf das Authentifizierungsschema zum Überprüfen der Identität erforderlich verweist. Die Zeichenfolge "Password" ist die planebene angegeben, was vom System für einen Benutzer ihre Identität nachweisen benötigt wird. Die Zeichenfolge "Password" dient nur zu Informationszwecken, und keine syntaxelementtypen an.

Ein weiterer interessanter Aspekt der im vorherigen Beispiel ist, dass ein ausdrücklicher Benutzername nicht unbedingt erforderlich ist. Name des Benutzers, kann jeder Anspruch, unabhängig von den deklarierten Typ verwendet werden. Der folgende Codeausschnitt zeigt eine andere entsprechende Möglichkeit, ein neues Identitätsobjekt haben:

var identity = new ClaimsIdentity(claims,
  CookieAuthenticationDefaults.AuthenticationScheme,
  "Nickname",
  ClaimTypes.Role);

Die neue Identität "Cookies" wie das Authentifizierungsschema und Spitzname ist der Name des Anspruchs in der Liste, der verwendet werden, um den Namen des Benutzers bereitzustellen. Rolle wird stattdessen der Name des Anspruchs in derselben Liste Festlegen der Rolle. Wenn nicht angegeben ist, standardmäßig die letzten beiden Parameter ClaimTypes.Name gespeichert wird und ClaimTypes.Role. Schließlich erstellen Sie den Prinzipal aus der Identität. Es ist Folgendes zu beachten jedoch, dass ein Prinzipal mehrere Identitäten aufweisen kann. Wenn seltsames klingt vorstellen Sie, dass unterschiedliche Bereiche der gleichen Anwendung möglicherweise unterschiedliche Informationen zum Authentifizieren des Benutzers im großen und ganzen genauso, dass eine ID zur Identifikation an einige Hotel Schreibtisch und einem elektronischen Schlüssel zu erhalten, die in der Vorteile erforderlich ist. Der ClaimsPrincipal-Klasse verfügt über eine Identitäten-Eigenschaft (eine Sammlung) und einer Identity-Eigenschaft. Letzteres ist lediglich einen Verweis auf das erste Element in der Auflistung.

Externe Authentifizierung

ASP.NET Core unterstützt externe Authentifizierung über Identitätsanbieter von Grund auf neu einrichten. Die meisten Fällen müssen Sie lediglich installieren Sie das entsprechende NuGet-Paket für den Task. Um Twitter benötigen zum Authentifizieren von Benutzern, im Paket Microsoft.AspNetCore.Authentication.Twitter schalten und die verwandte Middleware installieren:

app.UseTwitterAuthentication(new TwitterOptions()
{
  AuthenticationScheme = "Twitter",
  SignInScheme = "Cookies",
  ConsumerKey = "...",
  ConsumerSecret = "..."
});

Die Eigenschaft SignInScheme ist der Bezeichner der authentifizierungsmiddleware, die zum dauerhaften Speichern der resultierenden Identität verwendet werden. Im Beispiel wird ein Authentifizierungscookie verwendet werden. Um die Auswirkungen anzuzeigen, fügen Sie zuerst eine Controllermethode Twitter aufgerufen:

public async Task TwitterAuth()
{
  var props = new AuthenticationProperties
  {
    RedirectUri = "/"  
  };
  await HttpContext.Authentication.ChallengeAsync("Twitter", props);
}

Als Nächstes nach Twitter der Benutzer erfolgreich authentifiziert wurde, weist die SignInScheme-Eigenschaft, die Anwendung auf, was Sie als Nächstes tun. Ein Wert von "Cookies" ist akzeptabel, wenn einen Cookie aus der Ansprüche, die vom externen Anbieter (im Beispiel Twitter) zurückgegeben werden soll. Wenn Sie überprüfen möchten und die Informationen über diesen Bericht z. B. ein intermediate Format, müssen Sie den Prozess in zwei, Einführung in ein Schema für die temporäre anmelden zu unterbrechen. Zusätzlich zu den standard-Cookie-Middleware bewirken, haben Sie die folgenden:

app.UseCookieAuthentication(new CookieAuthenticationOptions
{
  AuthenticationScheme = "ExternalCookie",
  AutomaticAuthenticate = false
});
app.UseTwitterAuthentication(new TwitterOptions
{
  AuthenticationScheme = "Twitter",
  SignInScheme = "ExternalCookie"
});

Rückkehr des externen Anbieters wird ein temporäres Cookie mithilfe des Schemas ExternalCookie erstellt. Legen Sie den Umleitungspfad entsprechend müssen, haben Sie die Möglichkeit, die den Prinzipal, der von Twitter zurückgegebenen überprüfen und weiter zu bearbeiten:

var props = new AuthenticationProperties
  RedirectUri = "/account/external"  
};

Zum Abschließen des Workflows müssen Sie auch melden Sie sich auf das Schema Cookies und melden Sie sich temporäre Schema (ExternalCookie):

public async Task<IActionResult> External()
  var principal = await HttpContext
    .Authentication
    .AuthenticateAsync("ExternalCookie");
  // Edit the principal
  ...

  await HttpContext.Authentication.SignInAsync("Cookies", principal);
  await HttpContext.Authentication.SignOutAsync("ExternalCookie ");
}

ExternalCookie als auch Cookies gespeichert werden, sind nur interne Bezeichner, und können umbenannt werden, solange sie in der gesamten Anwendung konsistent bleiben.

Zusammenfassung

In ASP.NET Core, die viele Dinge große zu sein scheinen, unverändert jedoch am Ende, die meisten die Konzepte, die möglicherweise von ASP.NET bekannt sind verbleiben. Müssen Sie immer noch ein Authentifizierungscookie erstellt haben, und Sie können immer noch den Namen des Cookies und das Ablaufdatum steuern. Externe Authentifizierung wird unterstützt und Anmeldeseiten dieselbe Struktur auf wie vor. Allerdings unterscheiden sich Konfigurations- und zugrunde liegende arbeiten, die von der Authentifizierungsinfrastruktur, Beibehaltung ihrer vorherigen Flexibilität.

Alles, was in diesem Artikel erwähnt bezieht sich auf ASP.NET Core 1.x. Es gibt einige Dinge, die in ASP.NET Core 2.0 anders funktionieren werden. Insbesondere authentifizierungsmiddleware wird jetzt als Dienste verfügbar gemacht und muss auf dem Konfigurieren von Diensten konfiguriert werden:

services.AddCookieAuthentication(options =>
{
  Options.LoginPath = new PathString("/Account/Login"),
    options.AutomaticAuthenticate = true,
    options.AutomaticChallenge = true,
    options.AuthenticationScheme = "Cookies", 
    ...
});

In der Methode konfigurieren die Startklasse von ASP.NET Core 2.0-Anwendungen deklarieren Sie einfach Ihre Absicht Authentifizierungsdienste ohne weitere Optionen verwenden:

app.UseAuthentication();

Beachten Sie, dass die SignInAsync-Methode, die Sie in Ihrem Code verwenden, um das Authentifizierungscookie erstellen auch aus dem Objekt HttpContext direkt verfügbar gemacht wird anstelle einer intermediate Authentifizierungseigenschaft übergeben, wie in der letzten Codeausschnitt für ASP.NET Core gezeigt 1.x.

Dino Esposito ist Autor von „Microsoft .NET: Architecting Applications for the Enterprise“ (Microsoft Press, 2014) und „Modern Web Applications with ASP.NET“ (Microsoft Press, 2016). Esposito ist Technical Evangelist für die .NET- und Android-Plattformen bei JetBrains und spricht häufig auf Branchenveranstaltungen weltweit. Auf software2cents.wordpress.com und auf Twitter unter twitter.com/despos lässt er uns wissen, welche Softwarevision er verfolgt.

Unser Dank gilt dem folgenden technischen Experten bei Microsoft für die Durchsicht dieses Artikels: Chris Ross

Diesen Artikel im MSDN Magazine-Forum diskutieren

Freigeben über