Remoteauthentifizierung

Die Remoteauthentifizierungsfunktion von System.Web-Adaptern ermöglicht es einer ASP.NET Core-App, eine Benutzeridentität zu bestimmen (eine HTTP-Anforderung zu authentifizieren), indem sie auf eine ASP.NET-App verschoben wird. Durch das Aktivieren des Features wird der ASP.NET-App ein Endpunkt hinzugefügt, der einen serialisierten ClaimsPrincipal zurückgibt, der den authentifizierten Benutzer für sämtliche Anforderungen an den Endpunkt darstellt. Die ASP.NET Core-App registriert dann einen benutzerdefinierten Authentifizierungshandler, der (für Endpunkte mit aktivierter Remoteauthentifizierung) die Identität eines Benutzers bestimmt, indem dieser Endpunkt auf der ASP.NET-App aufgerufen und ausgewählte Header und identity aus der ursprünglichen Anforderung übergeben werden, die von der ASP.NET Core-App empfangen wurden.

Konfiguration

Es sind nur einige kleine Codeänderungen erforderlich, um die Remoteauthentifizierung in einer Lösung zu aktivieren, die bereits gemäß dem unter Erste Schritte beschriebenen Vorgehen eingerichtet ist.

Befolgen Sie zunächst die Anweisungen zum Einrichten der Remote-App, um eine Verbindung zwischen der ASP.NET Core-App und der ASP.NET-App herzustellen. Dann müssen nur noch ein paar zusätzliche Erweiterungsmethoden aufgerufen werden, um die Remote-App-Authentifizierung zu aktivieren.

Konfiguration der ASP.NET-App

Die ASP.NET-App muss konfiguriert werden, um den Authentifizierungsendpunkt hinzuzufügen. Dazu wird die AddAuthenticationServer-Erweiterungsmethode aufgerufen, um das HTTP-Modul einzurichten, das Anforderungen an den Authentifizierungsendpunkt überwacht. Beachten Sie, dass in Remoteauthentifizierungsszenarien in der Regel auch Proxyunterstützung hinzugefügt wird, sodass alle authentifizierungsbezogenen Umleitungen ordnungsgemäß an die ASP.NET Core- und nicht an die ASP.NET-App weitergeleitet werden.

SystemWebAdapterConfiguration.AddSystemWebAdapters(this)
    .AddProxySupport(options => options.UseForwardedHeaders = true)
    .AddRemoteAppServer(options =>
    {
        options.ApiKey = ConfigurationManager.AppSettings["RemoteAppApiKey"];
    })
    .AddAuthenticationServer();

Konfiguration der ASP.NET Core-App

Als Nächstes muss die ASP.NET Core-App konfiguriert werden, um den Authentifizierungshandler zu aktivieren, der zukünftig Benutzer authentifiziert, indem er eine HTTP-Anforderung an die ASP.NET-App sendet. Auch dies geschieht durch Aufrufen von „AddAuthenticationClient“ beim Registrieren von System.Web-Adapterdiensten:

builder.Services.AddSystemWebAdapters()
    .AddRemoteAppClient(options =>
    {
        options.RemoteAppUrl = new Uri(builder.Configuration
            ["ReverseProxy:Clusters:fallbackCluster:Destinations:fallbackApp:Address"]);
        options.ApiKey = builder.Configuration["RemoteAppApiKey"];
    })
    .AddAuthenticationClient(true);

Der boolesche Wert, der an den „AddAuthenticationClient“-Aufruf übergeben wird, gibt an, ob die Remote-App-Authentifizierung das Standardauthentifizierungsschema sein soll. Das Übergeben von „true“ führt dazu, dass der Benutzer über die Remote-App-Authentifizierung für alle Anforderungen authentifiziert wird, während das Übergeben von „false“ bedeutet, dass der Benutzer nur dann mit der Remote-App-Authentifizierung authentifiziert wird, wenn das Remote-App-Schema ausdrücklich angefordert wird (z. B. mit „[Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)]“ auf einem Controller oder einer Aktionsmethode). Die Übergabe von false für diesen Parameter hat den Vorteil, dass nur HTTP-Anforderungen an die ursprüngliche ASP.NET-App zur Authentifizierung für Endpunkte gesendet werden, die eine Remote-App-Authentifizierung erfordern, aber der Nachteil ist, dass alle diese Endpunkte kommentiert werden müssen, um anzugeben, dass sie die Remote-App-Authentifizierung verwenden.

Zusätzlich zur booleschen Anforderung kann ein optionaler Rückruf an „AddAuthenticationClient“ übergeben werden, um einige andere Aspekte des Verhaltens des Remoteauthentifizierungsprozesses zu ändern:

• RequestHeadersToForward: Diese Eigenschaft enthält Header, die von einer Anforderung weitergeleitet werden sollen, wenn die Authentifizierungs-API aufgerufen wird. Standardmäßig werden die nur Header „Authorization“ und „Cookie“ weitergeleitet. Zusätzliche Header können weitergeleitet werden, indem sie dieser Liste hinzugefügt werden. Wenn Sie alternativ die Liste löschen (sodass keine Header angegeben sind), werden alle Header weitergeleitet.
• ResponseHeadersToForward: Diese Eigenschaft listet Antwortheader auf, die von der Authentifizierungsanforderung an den ursprünglichen Aufruf zurückgegeben werden sollen, der in Szenarien mit identitysaufforderungen eine Authentifizierung gefordert hat. Standardmäßig umfasst dies „Location“-, „Set-Cookie“- und „WWW-Authenticate“-Header.
• AuthenticationEndpointPath: Der Endpunkt auf der ASP.NET-App, in der Authentifizierungsanforderungen gestellt werden sollen. Dies ist standardmäßig „/systemweb-adapters/authenticate“ und muss mit dem Endpunkt übereinstimmen, der bei der Konfiguration des ASP.NET-Authentifizierungsendpunkts angegeben wird.

Wenn die ASP.NET Core-App zuvor keine Authentifizierungs-Middleware enthalten hat, muss diese aktiviert werden (nach dem Routing der Middleware, jedoch vor ihrer Autorisierung):

app.UseAuthentication();

Entwurf

1. Wenn Anforderungen von der ASP.NET Core-App verarbeitet werden, wenn die Remote-App-Authentifizierung das Standardschema ist oder vom Endpunkt der Anforderung angegeben wird, versucht „RemoteAuthenticationAuthHandler“, den Benutzer zu authentifizieren.
   1. Der Handler sendet eine HTTP-Anforderung an den Authentifizierungsendpunkt der ASP.NET-App. Er kopiert konfigurierte Header aus der aktuellen in diese neue Anforderung, um authentifizierungsrelevante Daten weiterzuleiten. Wie oben erwähnt, besteht das Standardverhalten darin, die „Authorize“- und „Cookie“-Header zu kopieren. Der API-Schlüsselheader wird aus Sicherheitsgründen ebenfalls hinzugefügt.
2. Die ASP.NET-App verarbeitet Anforderungen, die an den Authentifizierungsendpunkt gesendet werden. Solange die API-Schlüssel übereinstimmen, gibt die ASP.NET-App entweder die serialisierte ClaimsPrincipal des aktuellen Benutzers in den Antworttext oder einen HTTP-Statuscode (z. B. 401 oder 302) und die Antwortheader zurück, die einen Fehler anzeigen.
3. Wenn die „RemoteAuthenticationAuthHandler“ der ASP.NET Core-App die Antwort von der ASP.NET-App empfängt:
   1. Wenn eine ClaimsPrincipal-Klasse erfolgreich zurückgegeben wurde, wird sie vom Authentifizierungshandler deserialisiert und als identity des aktuellen Benutzers verwendet.
   2. Wenn keine ClaimsPrincipal-Klasse erfolgreich zurückgegeben wurde, speichert der Handler das Ergebnis. Wenn die Authentifizierung gefordert wird (z. B. weil der Benutzer auf eine geschützte Ressource zugreift), wird die Antwort der Anforderung mit dem Statuscode und ausgewählten Antwortheadern aus der Antwort vom authentifizierten Endpunkt aktualisiert. Dadurch können Abfragerückmeldungen (z. B. Umleitungen zu einer Anmeldeseite) an Endbenutzer weitergegeben werden.
      1. Da die Ergebnisse des Authentifizierungsendpunkts der ASP.NET-App spezifische Daten für diesen Endpunkt enthalten können, können Benutzer „IRemoteAuthenticationResultProcessor“-Implementierungen bei der ASP.NET Core-App registrieren, die für alle Authentifizierungsergebnisse ausgeführt werden, bevor sie verwendet werden. Die in „IRemoteAuthenticationResultProcessor“ integrierte ist beispielsweise „RedirectUrlProcessor“. Sie sucht nach „Location“-Antwortheadern, die vom Authentifizierendpunkt zurückgegeben werden, und stellt sicher, dass sie zurück an den Host der ASP.NET Core-App und nicht direkt an die ASP.NET-App weitergeleitet werden.

Bekannte Einschränkungen

Dieser Remoteauthentifizierungsansatz weist einige bekannte Einschränkungen auf:

1. Da die Windows-Authentifizierung von einem Handle zu einer Windows-identity abhängt, wird die Windows-Authentifizierung von diesem Feature nicht unterstützt. In Zukunft soll untersucht werden, wie eine gemeinsame Windows-Authentifizierung funktionieren könnte. Weitere Informationen finden Sie unter dotnet/systemweb-adapters#246.
2. Dieses Feature ermöglicht es der ASP.NET Core-App, eine per identity authentifizierte ASP.NET-App zu verwenden. Alle Aktionen im Zusammenhang mit Benutzern (Anmelden, Abmelden usw.) müssen aber weiterhin über die ASP.NET-App geroutet werden.

Alternativen

Wenn die Authentifizierung in der ASP.NET-App mithilfe der Microsoft.OwinCookie-Authentifizierungs-Middleware erfolgt, besteht eine alternative Lösung zur Freigabe der identity darin, die ASP.NET- und ASP.NET Core-Apps so zu konfigurieren, dass sie eine cookie-Authentifizierung freigeben können. Die Freigabe einer „cookie“-Authentifizierung ermöglicht Folgendes:

• Beide Apps können die identity des Benutzers aus demselben cookie bestimmen.
• Beim Anmelden bei oder Abmelden von einer App wird der Benutzer bei der anderen App an- oder abgemeldet.

Beachten Sie, dass nicht alle Authentifizierungsfunktionen in beiden Apps funktionieren, da die Anmeldung in der Regel von einer bestimmten Datenbank abhängt:

• Benutzer sollten sich nur über eine der Apps anmelden, entweder über die ASP.NET- oder ASP.NET Core-App, je nachdem, welche Datenbank für sie eingerichtet ist.
• Beide Apps können die identity und Ansprüche der Benutzer sehen.
• Beide Apps können den Benutzer abmelden.

Details zum Konfigurieren von „“-Authentifizierungsfreigaben zwischen ASP.NET- und ASP.NET Core-Apps finden Sie in der cookie-Freigabedokumentation. Die folgenden Beispiele im GitHub-Repository System.Web-Adapter veranschaulichen die Remote-App-Authentifizierung mit freigegebener „cookie“-Konfiguration, die es beiden Apps ermöglicht, Benutzer an- und abzumelden:

• ASP.NET-App
• ASP.NET Core-App

Die Freigabeauthentifizierung ist eine gute Option, wenn die beiden folgenden Punkte zutreffen:

• Die ASP.NET-App verwendet bereits die Microsoft.Owincookie-Authentifizierung.
• Es ist möglich, die ASP.NET- und ASP.NET Core App so zu aktualisieren, dass sie übereinstimmende Datenschutzeinstellungen verwenden. Übereinstimmende Einstellungen für den Schutz freigegebener Daten umfassen einen freigegebenen Dateipfad und einen Redis-Cache oder Azure Blob Storage zum Speichern von Datenschutzschlüsseln.

Für andere Szenarien ist der in dieser Dokumentation weiter oben beschriebene Ansatz der Remoteauthentifizierung aber flexibler und wahrscheinlich besser geeignet.