Migrieren ASP.NET Frameworkauthentifizierung zu ASP.NET Core

Die Authentifizierung ist eine wichtige Komponente von Webanwendungen, die die Überprüfung der Benutzeridentität über HTTP-Anforderungen hinweg verarbeitet. Bei der Migration von ASP.NET Framework zu ASP.NET Core stellt die Authentifizierung eindeutige Herausforderungen dar, da die beiden Frameworks die Authentifizierung sehr unterschiedlich behandeln.

Allgemeine Informationen zur Authentifizierung in ASP.NET Core finden Sie in der Übersicht über ASP.NET Core Authentication. Informationen zur Autorisierung finden Sie unter Einführung in die Autorisierung in ASP.NET Core.

Warum die Authentifizierungsmigration komplex ist

ASP.NET Framework und ASP.NET Core haben grundsätzlich unterschiedliche Ansätze für die Authentifizierung:

• ASP.NET Framework bietet integrierte Authentifizierungsmodule mit automatischer Konfiguration und enger Integration in System.Web
• ASP.NET Core verwendet einen Middleware-basierten Ansatz mit expliziter Konfiguration und Abhängigkeitsinjektion

Diese Unterschiede bedeuten, dass Sie Ihren Authentifizierungscode nicht einfach von Framework zu Core verschieben können, ohne dass Änderungen vorgenommen werden.

Authentifizierungstypen und Migrationsprobleme

Verschiedene Authentifizierungstypen stellen unterschiedliche Migrationskomplexitätsstufen dar:

Cookie-basierte Authentifizierung

• ASP.NET Framework: Verwendet Microsoft.Owincookie Authentifizierungs-Middleware
• ASP.NET Core: Verwendet CookieAuthentication Middleware mit unterschiedlicher Konfiguration
• Migrationsaufgabe: Cookie Format, Verschlüsselungsschlüssel und Konfigurationsunterschiede

JWT-Bearertoken

• ASP.NET Framework: Häufig über benutzerdefinierte Module oder OWIN-Middleware verarbeitet
• ASP.NET Core: Native Unterstützung durch Microsoft.AspNetCore.Authentication.JwtBearer
• Migrationsherausforderung: Unterschiede zwischen Tokenvalidierungsparametern und Middleware-Registrierung

Windows-Authentifizierung

• ASP.NET Framework: Integrierte IIS-Integration
• ASP.NET Core: Erfordert explizite Konfiguration und kann Hostingmodelländerungen erfordern
• Migrationsherausforderung: Unterschiede in der Serverkonfiguration und dem Authentifizierungsablauf

Formularauthentifizierung

• ASP.NET Framework: Eingebauter Bestandteil
• ASP.NET Core: Keine direkte Entsprechung, erfordert eine Migration zur cookie Authentifizierung.
• Migrationsherausforderung: Vollständiges Umschreiben des Authentifizierungssystems erforderlich

Benutzerdefinierte Authentifizierung

• ASP.NET Framework: Implementierung von benutzerdefinierten Modulen IHttpModule
• ASP.NET Core: Benutzerdefinierte Middleware- oder Authentifizierungshandler
• Migrationshergeforderung: Vollständige Architekturänderung von Modulen zu Middleware

Übersicht über Migrationsstrategien

Sie haben drei Hauptansätze für die Behandlung der Authentifizierung während der Migration:

1. Vollständige Neuschreibung : Schreiben Sie den gesamten Authentifizierungscode neu, um die systemeigene Authentifizierung von ASP.NET Core zu verwenden.
2. Remoteauthentifizierung: Verwenden von System.Web-Adaptern zum Delegieren der Authentifizierung an die ASP.NET Framework-App
3. Gemeinsame cookie Authentifizierung – Teilen von Authentifizierungscookies zwischen Framework und Core-Anwendungen (für OWIN-basierte Szenarien)

Für die meisten Anwendungen bietet die Migration zur nativen ASP.NET Core-Authentifizierung die beste Leistung und Wartung. Größere Anwendungen oder solche mit komplexen Authentifizierungsanforderungen können jedoch von einem inkrementellen Ansatz mit den System.Web-Adaptern profitieren.

Auswählen Ihres Migrationsansatzes

Sie haben drei Hauptoptionen für die Migration der Authentifizierung von ASP.NET Framework zu ASP.NET Core. Ihre Wahl hängt von Ihrem Authentifizierungstyp, der Migrationszeitachse, davon ab, ob Sie beide Anwendungen gleichzeitig ausführen müssen und wie viel Code Sie neu schreiben möchten.

Schnellentscheidungsleitfaden

Beantworten Sie diese Fragen, um Ihren Ansatz auszuwählen:

1. Führen Sie eine vollständige Neuschreibung oder inkrementelle Migration durch?

   • Vollständig neu schreiben →. Vollständige Umstellung auf ASP.NET Core-Authentifizierung
   • Inkrementelle Migration → Frage 2 fortsetzen

2. Welchen Authentifizierungstyp verwendet Ihre ASP.NET Framework-App?

   • OWIN-Authentifizierung cookie → Weiterhin Frage 3
   • Formularauthentifizierung, JWT Bearer-Token, Windows-Authentifizierung oder benutzerdefinierte Authentifizierung → Remoteauthentifizierung

3. Müssen sowohl Ihr ASP.NET Framework als auch ASP.NET Core-Apps auf denselben Authentifizierungsstatus zugreifen?

   • Ja, gemeinsame Authentifizierung erforderlich → Mit Frage 4 fortfahren
   • Nein, separate Authentifizierung ist in Ordnung → Vollständiges Umschreiben auf ASP.NET Core-Authentifizierung

4. Können Sie übereinstimmende Datenschutzeinstellungen zwischen beiden Apps konfigurieren?

   • Ja → Freigegebene cookie Authentifizierung (siehe Abschnitt "Alternativen", beste Leistung)
   • Keine oder nicht sicher → Remoteauthentifizierung

Vergleich der Migrationsansätze

Vollständige Umstellung auf ASP.NET Core-Authentifizierung

Wählen Sie diesen Ansatz aus, wenn Sie eine vollständige Migration durchführen, nicht OWIN-Authentifizierung haben oder die beste Leistung und Wartung wünschen.

ASP.NET Core bietet umfassende Authentifizierungsunterstützung mit leistungsstarken und umfangreichen Anpassungsoptionen. Dieser Ansatz erfordert das Umschreiben von Authentifizierungscode, bietet aber langfristig die meisten Vorteile.

Vollständige Überarbeitung: Vor- und Nachteile

Überlegungen zur Migration

Beim Migrieren zur systemeigenen ASP.NET Core-Authentifizierung:

Wählen Sie basierend auf Ihrem Framework-Authentifizierungstyp aus:

• Formularauthentifizierung → Zur Authentifizierung migrierenCookie
• JWT Bearer-Token → Migrieren zur JWT Bearer-Authentifizierung
• Windows-Authentifizierung → Windows-Authentifizierung verwenden
• OWIN OAuth-Anbieter → Verwenden entsprechender ASP.NET Core OAuth-Anbieter
• Benutzerdefinierte Authentifizierung → Implementieren von benutzerdefinierten Authentifizierungshandlern

Codeänderungen erforderlich:

• Ersetzen HttpContext.User Zugriffsmuster (weitgehend kompatibel)
• Aktualisieren der Authentifizierungs-Middleware-Registrierung in Program.cs
• Migrieren von benutzerdefinierter Authentifizierungslogik zu ASP.NET Kernmustern
• Aktualisieren von Autorisierungsattributen und -richtlinien

Wann Sie diesen Ansatz auswählen möchten:

• Sie können es sich leisten, Authentifizierungsbezogener Code neu zu schreiben
• Die Leistung ist eine oberste Priorität.
• Sie teilen den Authentifizierungsstatus nicht mit älteren Anwendungen
• Sie möchten System.Web-Abhängigkeiten vollständig beseitigen
• Ihre Framework-App verwendet Forms-Authentifizierung, benutzerdefinierte Module oder JWT-Token.

Remoteauthentifizierung

Wählen Sie diesen Ansatz aus, wenn Sie die Authentifizierung zwischen Ihrem ASP.NET Framework und ASP.NET Core-Anwendungen während der inkrementellen Migration freigeben müssen oder wenn Sie eine komplexe Authentifizierung haben, die schwierig zu migrieren ist.

Das Remoteauthentifizierungsfeature von System.Web adapters ermöglicht es einer ASP.NET Core-App, die Identität eines Benutzers zu ermitteln, indem sie sich an eine ASP.NET-App anlehnt. Dies ermöglicht eine schrittweise Migration, während ein einzelnes Authentifizierungssystem beibehalten wird.

Funktionsweise der Remoteauthentifizierung

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.
2. Der Handler sendet eine HTTP-Anforderung an den Authentifizierungsendpunkt der ASP.NET App, leitet konfigurierte Header aus der aktuellen Anforderung weiter (standardmäßig Authorization und Cookie Header).
3. Die ASP.NET App verarbeitet die Authentifizierung und gibt entweder einen serialisierten ClaimsPrincipal oder einen HTTP-Statuscode zurück, der den Fehler angibt.
4. Die ASP.NET Core-App verwendet das Ergebnis, um die Identität des Benutzers festzulegen oder Authentifizierungsproblemen zu bewältigen.

Remoteauthentifizierungs-Vor- und Nachteile

Wann die Remoteauthentifizierung ausgewählt werden soll

Wählen Sie die Remoteauthentifizierung aus, wenn:

• Ihre ASP.NET-App verwendet Microsoft.Owincookie keine Authentifizierung.
• Sie möchten eine flexible Lösung, die mit verschiedenen Authentifizierungsmechanismen funktioniert
• Sie müssen die Authentifizierungslogik schrittweise zu ASP.NET Core migrieren.
• Sie haben eine komplexe benutzerdefinierte Authentifizierung, die schwierig umzuschreiben ist.
• Sie führen eine schrittweise Migration durch und benötigen einen gemeinsamen Authentifizierungsstatus.

Remoteauthentifizierungskonfiguration

Es sind nur einige kleine Codeänderungen erforderlich, um die Remoteauthentifizierung in einer Lösung zu aktivieren, die bereits gemäß den Ersten Schritten eingerichtet ist.

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

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

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

...

var coreApp = builder.AddProject<Projects.AuthRemoteIdentityCore>("core")
    .WithHttpHealthCheck()
    .WaitFor(frameworkApp)
    .WithIncrementalMigrationFallback(frameworkApp, options => options.RemoteAuthentication = RemoteAuthentication.DefaultScheme);

...

Remoteauthentifizierung mit YARP-Fallback

Stellen Sie bei der Verwendung der Remoteauthentifizierung mit einem YARP-basierten Fallback zur ASP.NET Framework-App sicher, dass Fallback-Anforderungen keine Remoteauthentifizierung auslösen. Wenn die Remoteauthentifizierung während des Fallbacks ausgeführt wird, macht die App unnötige zusätzliche Aufrufe an die Framework-App, was verwirrendes Verhalten zur Folge haben kann.

Verwenden Sie eine der folgenden Ansätze, um die Remoteauthentifizierung für Fallbackanforderungen zu vermeiden:

• Verwenden Sie Routing-Kurzschlussmetadaten auf der YARP-Fallbackroute, sodass die Route den Rest der Middleware-Pipeline umgeht. Rufen Sie z. B. ShortCircuit auf dem Fallback-Endpunkt an, wie in der Anleitung zur Einrichtung der Remote-App und in der Short-Circuit-Middleware nach der Weiterleitung gezeigt.
• Verwenden Sie die Remoteauthentifizierung nicht als Standardauthentifizierungsschema. Konfigurieren Sie stattdessen die Remoteauthentifizierung nur für die Endpunkte, die sie benötigen. Bereiten Sie false auf AddAuthenticationClient vor und legen Sie dann beispielsweise explizit das Remote-Authentifizierungsschema für diese Endpunkte fest.

Verwenden der Remoteauthentifizierung mit bestimmten Endpunkten

Wenn Sie das Standardschema auf false festlegen, können Sie die Remoteauthentifizierung für bestimmte Controller oder Aktionen spezifizieren.

[Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)]
public class SecureController : Controller
{
    // This controller uses remote authentication
    public IActionResult Index()
    {
        return View();
    }
}

// Or on specific actions
public class HomeController : Controller
{
    [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)]
    public IActionResult SecureAction()
    {
        return View();
    }
}

Implementieren von benutzerdefinierten Authentifizierungsergebnisprozessoren

Sie können benutzerdefinierte Prozessoren implementieren, um die Authentifizierungsergebnisse zu ändern, bevor sie verwendet werden:

public class CustomAuthResultProcessor : IRemoteAuthenticationResultProcessor
{
    public Task ProcessAsync(RemoteAuthenticationResult result, HttpContext context)
    {
        // Custom logic to process authentication results
        if (result.Headers.ContainsKey("Location"))
        {
            // Modify redirect URLs or other logic
        }
        
        return Task.CompletedTask;
    }
}

// Register the custom processor
builder.Services.AddScoped<IRemoteAuthenticationResultProcessor, CustomAuthResultProcessor>();

Wenn die ASP.NET Core-App zuvor keine Authentifizierungs-Middleware enthält, muss dies aktiviert werden (nach dem Routing von Middleware, aber vor Autorisierungs-Middleware). Weitere Informationen zur Middleware-Sortierung finden Sie unter ASP.NET Core Middleware:

app.UseAuthentication();

Sicherheitsüberlegungen

Berücksichtigen Sie bei der Implementierung der Remoteauthentifizierung die folgenden Sicherheitsaspekte:

• API-Schlüsselsicherheit: Der FÜR die Kommunikation zwischen dem ASP.NET Core und ASP.NET Apps verwendete API-Schlüssel sollte sicher mithilfe von Konfigurationsanbietern gespeichert und nicht hartcodiert werden.
• Netzwerksicherheit: Die Kommunikation zwischen den Apps sollte über sichere Kanäle (HTTPS) in Produktionsumgebungen erfolgen.
• Headerweiterleitung: Achten Sie darauf, welche Header Sie weiterleiten, um eine Offenlegung von vertraulichen Informationen zu vermeiden. Nur die für die Authentifizierung erforderlichen Header weiterleiten.
• Endpunktschutz: Der Authentifizierungsendpunkt der ASP.NET-App sollte nur für die ASP.NET Core-App und nicht für externe Clients zugänglich sein.

Problembehandlung

Häufige Probleme beim Konfigurieren der Remoteauthentifizierung:

• Authentifizierungsfehler: Überprüfen Sie, ob die API-Schlüssel zwischen beiden Anwendungen übereinstimmen und dass der Authentifizierungsendpunktpfad ordnungsgemäß konfiguriert ist.
• Umleitungsschleifen: Stellen Sie sicher, dass die RedirectUrlProcessor Umleitung ordnungsgemäß für die ASP.NET Core-App und nicht für die ASP.NET-App konfiguriert ist.
• Fehlende Ansprüche: Stellen Sie sicher, dass die ASP.NET-App ordnungsgemäß ClaimsPrincipal serialisiert und alle erforderlichen Ansprüche enthalten sind.

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. Sie kopiert konfigurierte Header aus der aktuellen Anforderung in diese neue Anforderung, um Authentifizierungsrelevante Daten weiterzuleiten. Wie bereits erwähnt, besteht das Standardverhalten darin, die Kopfzeilen Authorization und Cookie zu kopieren. Der API-Schlüsselheader wird auch zu Sicherheitszwecken hinzugefügt.
2. Die ASP.NET-App bedient 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 ASP.NET Core-App RemoteAuthenticationAuthHandler die Antwort von der ASP.NET-App empfängt:
   1. Wenn ein ClaimsPrincipal erfolgreich zurückgegeben wurde, wird er vom Authentifizierungshandler deserialisiert und als Identität des aktuellen Benutzers verwendet.
   2. Wenn ein ClaimsPrincipal nicht erfolgreich zurückgegeben wurde, speichert der Handler das Ergebnis und wenn die Authentifizierung angefordert wird (da der Benutzer z. B. auf eine geschützte Ressource zugreift), wird die Antwort der Anforderung mit dem Statuscode und den ausgewählten Antwortheadern aus der Antwort vom authentifizierten Endpunkt aktualisiert. Dadurch können Abfrageantworten (z. B. Umleitungen zu einer Anmeldeseite) an Endbenutzer weitergegeben werden.
      1. Da die Ergebnisse des Authentifizieren-Endpunkts der ASP.NET-App möglicherweise endpoint-spezifische Daten enthalten, können Benutzer Implementierungen mit der ASP.NET Core-App registrieren IRemoteAuthenticationResultProcessor, die auf alle Authentifizierungsergebnisse angewendet 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 hat einige bekannte Einschränkungen:

1. Windows-Authentifizierung: Da die Windows-Authentifizierung von einem Handle zu einer Windows-Identität abhängt, wird die Windows-Authentifizierung von diesem Feature nicht unterstützt. Zukünftige Forschungen sind geplant, um zu untersuchen, wie die gemeinsame Windows-Authentifizierung funktionieren könnte. Weitere Informationen finden Sie unter dotnet/systemweb-adapters#246 . Für Windows-Authentifizierungsszenarien sollten Sie stattdessen die Windows-Authentifizierung in ASP.NET Core in Ihrer ASP.NET Core-Anwendung konfigurieren.
2. Benutzerverwaltungsaktionen: Mit diesem Feature kann die ASP.NET Core-App eine von der ASP.NET App authentifizierte Identität nutzen, aber alle Aktionen im Zusammenhang mit Benutzern (Anmelden, Abmelden usw.) müssen weiterhin über die ASP.NET-App weitergeleitet werden.
3. Leistungsüberlegungen: Für jede Authentifizierungsanforderung ist ein HTTP-Aufruf der ASP.NET-App erforderlich, was sich auf die Leistung auswirken kann. Erwägen Sie die Verwendung der gemeinsamen cookie Authentifizierung (wie im Abschnitt "Alternativen" beschrieben), wenn die Leistung von entscheidender Bedeutung ist.

Gemeinsame cookie Authentifizierung

Wenn die Authentifizierung in der ASP.NET-App mit Microsoft.OwinCookie der Authentifizierungs-Middleware erfolgt, besteht eine alternative Lösung zur Remoteauthentifizierung darin, die ASP.NET und ASP.NET Core-Apps so zu konfigurieren, dass sie eine Authentifizierung cookiefreigeben können.

Funktionsweise von freigegebenen Cookies

Die Freigabe einer Authentifizierung cookie ermöglicht Folgendes:

• Beide Apps können die Benutzeridentität aus demselben „cookie“ bestimmen.
• Das An- oder Abmelden von einer App meldet den Benutzer bei der anderen App an oder ab.

Beide Anwendungen sind für Folgendes konfiguriert:

• Verwenden sie denselben Namen und die gleichen cookie Domäneneinstellungen.
• Teilen von Datenschlüsseln für cookie Verschlüsselung/Entschlüsselung
• Verwenden von kompatibler cookie Authentifizierungs-Middleware

Dadurch können Benutzer, die sich in einer App authentifiziert haben, automatisch in der anderen App authentifiziert werden, wenn sie Anforderungen stellen.

Vor- und Nachteile der geteilten cookie Authentifizierung

Authentifizierungseinschränkungen bei freigegebenen Cookies

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

• Benutzer sollten sich nur über eine der Apps anmelden, entweder die ASP.NET oder ASP.NET Core-App, mit der die Datenbank eingerichtet ist.
• Beide Apps können die Identität und ansprüche der Benutzer sehen.
• Beide Apps können den Benutzer abmelden.

Details zum Konfigurieren der Freigabe von Authentifizierungscookies zwischen ASP.NET und ASP.NET Core-Apps finden Sie in der cookie Freigabedokumentation. Weitere Informationen zur cookie Authentifizierung in ASP.NET Core finden Sie unter Verwenden cookie der Authentifizierung ohne ASP.NET Core Identity. Anleitungen zur Konfiguration von <machineKey> und zum Datenschutz beim Freigeben geschützter Werte zwischen Framework- und Core-Apps finden Sie unter ASP.NET machineKey zu ASP.NET Core Migration.

Die folgenden Beispiele im GitHub-Repository "System.Web adapters " veranschaulicht die Remote-App-Authentifizierung mit freigegebener cookie Konfiguration, mit der sowohl Apps Benutzer anmelden als auch abmelden können:

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

Wann die freigegebene cookie Authentifizierung ausgewählt werden soll

Wählen Sie "Freigegebene Cookie Authentifizierung" aus, wenn:

• Ihre ASP.NET-App verwendet bereits die Authentifizierung.Microsoft.Owincookie
• Sie können übereinstimmende Datenschutzeinstellungen zwischen beiden Apps konfigurieren.
• Die Leistung ist wichtig, und Sie möchten HTTP-Anforderungen minimieren.
• Sie möchten, dass beide Apps Benutzeranmeldungs-/Abmeldevorgänge verarbeiten.
• Sie sind mit der Verwaltung von gemeinsam genutzten Verschlüsselungsschlüsseln vertraut

Die gemeinsame Nutzung der Authentifizierung ist eine gute Option, wenn beides zutrifft:

• Die ASP.NET-App verwendet Microsoft.Owincookie bereits die Authentifizierung.
• Es ist möglich, die ASP.NET-App und ASP.NET Core-Apps zu aktualisieren, um übereinstimmende Datenschutzeinstellungen zu verwenden. Abgestimmte Einstellungen zum Datenschutz bei gemeinsam genutzten Daten umfassen einen gemeinsamen Dateipfad, Redis-Cache oder Azure Blob Storage zum Speichern der Datenschlüssel. Weitere Informationen finden Sie unter ASP.NET Core-Datenschutz: Übersicht.

In anderen Szenarien ist der zuvor in diesem Dokument beschriebene Ansatz für die Remoteauthentifizierung flexibler und eignet sich wahrscheinlich besser.

Siehe auch

• Übersicht über ASP.NET Core Authentication
• Einführung in die Autorisierung in ASP.NET Core
• Teilen von Authentifizierungscookies zwischen ASP.NET Apps
• Verwenden der cookie Authentifizierung ohne ASP.NET Core Identity
• ASP.NET Core-Middleware
• Migrieren von ASP.NET Framework zu ASP.NET Core
• Remote-App-Setup