Migrera ASP.NET Framework-autentisering till ASP.NET Core

Autentisering är en viktig komponent i webbprogram som hanterar verifiering av användaridentitet mellan HTTP-begäranden. När du migrerar från ASP.NET Framework till ASP.NET Core innebär autentisering unika utmaningar eftersom de två ramverken hanterar autentisering på ett helt annat sätt.

Allmän information om autentisering i ASP.NET Core finns i Översikt över ASP.NET Core-autentisering. Information om auktorisering finns i Introduktion till auktorisering i ASP.NET Core.

Varför autentiseringsmigrering är komplex

ASP.NET Framework och ASP.NET Core har fundamentalt olika autentiseringsmetoder:

• ASP.NET Framework tillhandahåller inbyggda autentiseringsmoduler med automatisk konfiguration och nära integrering med System.Web
• ASP.NET Core använder en mellanprogramsbaserad metod med explicit konfiguration och beroendeinmatning

Dessa skillnader innebär att du inte bara kan flytta din autentiseringskod från Framework till Core utan ändringar.

Autentiseringstyper och migreringsutmaningar

Olika autentiseringstyper har olika nivåer av migreringskomplexitet:

Cookie-baserad autentisering

• ASP.NET Framework: Använder Microsoft.Owincookie mellanprogram för autentisering
• ASP.NET Core: Använder CookieAuthentication mellanprogram med olika konfiguration
• Migreringsutmaning: Cookie format, krypteringsnycklar och konfigurationsskillnader

JWT-bärartoken

• ASP.NET Framework: Hanteras ofta via anpassade moduler eller OWIN-mellanprogram
• ASP.NET Core: Internt stöd via Microsoft.AspNetCore.Authentication.JwtBearer
• Migreringsutmaning: Skillnader i tokenvalideringsparametrar och registrering av mellanprogram

Windows-autentisering

• ASP.NET Framework: Inbyggd IIS-integrering
• ASP.NET Core: Kräver explicit konfiguration och kan behöva ändringar i värdmodellen
• Migreringsutmaning: Skillnader i serverkonfiguration och autentiseringsflöde

Formulärautentisering

• ASP.NET Framework: Inbyggd System.Web.Security.FormsAuthentication
• ASP.NET Core: Ingen direkt motsvarighet, kräver migrering till cookie autentisering
• Migreringsutmaning: Fullständig omskrivning av autentiseringssystemet krävs

Anpassad autentisering

• ASP.NET Framework: Anpassade moduler som implementerar IHttpModule
• ASP.NET Core: Anpassade mellanprogram eller autentiseringshanterare
• Migreringsutmaning: Fullständig arkitekturändring från moduler till mellanprogram

Översikt över migreringsstrategier

Du har tre huvudsakliga metoder för att hantera autentisering under migreringen:

1. Fullständig omskrivning – Skriv om all autentiseringskod för att använda ASP.NET Cores interna autentisering
2. Fjärrverifiering – Använd System.Web-adaptrar för att delegera verifiering till ASP.NET Framework-applikationen
3. Delad cookie autentisering – Dela autentiseringscookies mellan Framework- och Core-program (för OWIN-baserade scenarier)

För de flesta program ger migrering till intern ASP.NET Core-autentisering bästa prestanda och underhållsbarhet. Större program eller program med komplexa autentiseringskrav kan dock dra nytta av en inkrementell metod med hjälp av System.Web-adaptrarna.

Välj migreringsmetod

Du har tre huvudsakliga alternativ för att migrera autentisering från ASP.NET Framework till ASP.NET Core. Ditt val beror på din autentiseringstyp, tidslinje för migrering, om du behöver köra båda programmen samtidigt och hur mycket kod du är villig att skriva om.

Snabb beslutsguide

Besvara dessa frågor för att välja din metod:

1. Gör du en fullständig omskrivning eller inkrementell migrering?

   • Slutför omskrivningen → Slutför omskrivningen till ASP.NET Core-autentisering
   • Inkrementell migrering → Fortsätt till fråga 2

2. Vilken typ av autentisering använder din ASP.NET Framework-app?

   • OWIN-autentisering cookie → Fortsätt till fråga 3
   • Formulärautentisering, JWT-ägartoken, Windows-autentisering eller anpassad autentisering → fjärrautentisering

3. Behöver både dina ASP.NET Framework- och ASP.NET Core-appar komma åt samma autentiseringstillstånd?

   • Ja, delad autentisering krävs → Fortsätt till fråga 4
   • Nej, separat autentisering är bra → Fullständig omskrivning till ASP.NET Core-autentisering

4. Kan du konfigurera matchande dataskyddsinställningar mellan båda apparna?

   • Ja → delad cookie autentisering (se avsnittet Alternativ, bästa prestanda)
   • Ingen eller osäker → fjärrautentisering

Jämförelse av migreringstillvägagångssätt

Slutför omskrivningen till ASP.NET Core-autentisering

Välj den här metoden när du utför en fullständig migrering, har icke-OWIN-autentisering eller vill ha bästa möjliga prestanda och underhåll.

ASP.NET Core ger omfattande autentiseringsstöd med höga prestanda och omfattande anpassningsalternativ. Den här metoden kräver att du skriver om autentiseringskoden men erbjuder de flesta fördelarna på lång sikt.

Fördelar och nackdelar med fullständig omskrivning

Överväganden vid migrering

När du migrerar till intern ASP.NET Core-autentisering:

Välj baserat på din Framework-autentiseringstyp:

• Formulärautentisering → Migrera till Cookie autentisering
• JWT Bearer-token → Migrera till JWT Bearer-autentisering
• Windows-autentisering → Använda Windows-autentisering
• OWIN OAuth-leverantörer → Använda motsvarande ASP.NET Core OAuth-leverantörer
• Anpassad autentisering → Implementera anpassade autentiseringshanterare

Kodändringar krävs:

• Ersätt HttpContext.User åtkomstmönster (mestadels kompatibla)
• Uppdatera registrering av mellanprogram för autentisering i Program.cs
• Migrera anpassad autentiseringslogik till ASP.NET Core-mönster
• Uppdatera auktoriseringsattribut och principer

När du ska välja den här metoden:

• Du har råd att skriva om autentiseringsrelaterad kod
• Prestanda är högsta prioritet
• Du delar inte autentiseringstillstånd med äldre program
• Du vill eliminera System.Web-beroenden helt
• Framework-appen använder formulärautentisering, anpassade moduler eller JWT-token

Fjärrautentisering

Välj den här metoden när du behöver dela autentisering mellan dina ASP.NET Framework- och ASP.NET Core-program under inkrementell migrering, eller när du har komplex autentisering som är svår att migrera.

System.Web-adaptrarnas fjärrautentiseringsfunktion gör att en ASP.NET Core-app kan fastställa en användares identitet genom att delegeras till en ASP.NET-app. Detta möjliggör gradvis migrering samtidigt som ett enda autentiseringssystem upprätthålls.

Så här fungerar fjärrautentisering

1. När begäranden bearbetas av ASP.NET Core-appen, om fjärrappautentisering är standardschemat eller anges av begärans slutpunkt, försöker RemoteAuthenticationAuthHandler autentisera användaren.
2. Hanteraren gör en HTTP-begäran till ASP.NET-programmets autentiseringsslutpunkt och vidarebefordrar konfigurerade header-fält från den aktuella begäran (som standard Authorization och Cookie header-fält).
3. ASP.NET-appen bearbetar autentiseringen och returnerar antingen en serialiserad ClaimsPrincipal eller en HTTP-statuskod som indikerar fel.
4. ASP.NET Core-appen använder resultatet för att fastställa användarens identitet eller hantera autentiseringsutmaningar.

För- och nackdelar med fjärrautentisering

När du ska välja fjärrautentisering

Välj Fjärrautentisering när:

• Din ASP.NET app använder Microsoft.Owincookie inte autentisering
• Du vill ha en flexibel lösning som fungerar med olika autentiseringsmekanismer
• Du måste gradvis migrera autentiseringslogik till ASP.NET Core
• Du har komplex anpassad autentisering som är svår att skriva om
• Du utför en inkrementell migrering och behöver delat autentiseringstillstånd

Konfiguration av fjärrautentisering

Det finns bara några små kodändringar som krävs för att aktivera fjärrautentisering i en lösning som redan har konfigurerats enligt Komma igång.

Följ först anvisningarna för fjärrappkonfiguration för att ansluta ASP.NET Core- och ASP.NET-apparna. Sedan finns det bara några extra tilläggsmetoder att anropa för att aktivera fjärrappautentisering.

SystemWebAdapterConfiguration.AddSystemWebAdapters(this)
    .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);

...

Använda fjärrautentisering med specifika slutpunkter

När du anger standardschemat till falsekan du ange fjärrautentisering för specifika styrenheter eller åtgärder:

[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();
    }
}

Implementera anpassade autentiseringsresultatprocessorer

Du kan implementera anpassade processorer för att ändra autentiseringsresultat innan de används:

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>();

Om ASP.NET Core-appen inte tidigare innehöll mellanprogram för autentisering måste det aktiveras (efter routning av mellanprogram, men innan mellanprogram för auktorisering). Mer information om mellanprogramsbeställning finns i ASP.NET Core Middleware:

app.UseAuthentication();

Säkerhetshänsyn

När du implementerar fjärrautentisering bör du tänka på följande säkerhetsaspekter:

• API Key Security: API-nyckeln som används för kommunikation mellan ASP.NET Core och ASP.NET-appar bör lagras på ett säkert sätt med hjälp av konfigurationsproviders och inte hårdkodas.
• Nätverkssäkerhet: Kommunikationen mellan apparna ska ske via säkra kanaler (HTTPS) i produktionsmiljöer.
• Vidarebefordring av rubriker: Var försiktig med vilka rubriker du vidarebefordrar för att undvika att exponera känslig information. Vidarebefordra endast rubriker som krävs för autentisering.
• Endpoint Protection: Autentiseringsslutpunkten i ASP.NET-appen ska endast vara tillgänglig för ASP.NET Core-appen, inte externa klienter.

Felsökning

Vanliga problem vid konfiguration av fjärrautentisering:

• Autentiseringsfel: Kontrollera att API-nycklarna matchar mellan båda programmen och att autentiseringens slutpunktssökväg är korrekt konfigurerad.
• Omdirigeringsloopar: Kontrollera att RedirectUrlProcessor är korrekt konfigurerad för att omdirigera till ASP.NET Core-appen i stället för ASP.NET appen.
• Saknade anspråk: Verifiera att ASP.NET-applikationen korrekt serialiserar ClaimsPrincipal och att alla obligatoriska anspråk inkluderas.

Utformning

1. När begäranden bearbetas av ASP.NET Core-appen, om fjärrappautentisering är standardschemat eller anges av begärans slutpunkt, försöker RemoteAuthenticationAuthHandler autentisera användaren.
   1. Hanteraren skickar en HTTP-begäran till ASP.NET appens autentiserande slutpunkt. Den kopierar konfigurerade huvuden från den aktuella begäran till den nya för att vidarebefordra autentiseringsrelevanerande data. Som nämnts ovan är standardbeteendet att kopiera Authorization- och Cookie-rubrikerna. API-nyckelrubriken läggs också till i säkerhetssyfte.
2. Den ASP.NET appen hanterar begäranden som skickas till autentiseringsslutpunkten. Så länge API-nycklarna matchar kommer ASP.NET-appen antingen att returnera den aktuella användarens ClaimsPrincipal serialiserade i svarsmeddelandet, eller returnera en HTTP-statuskod (till exempel 401 eller 302) tillsammans med svarshuvuden som indikerar ett fel.
3. När ASP.NET Core-appens RemoteAuthenticationAuthHandler tar emot svaret från ASP.NET-appen:
   1. Om en ClaimsPrincipal returnerades lyckosamt, kommer autentiseringshanteraren att deserialisera den och använda den som den aktuella användarens identitet.
   2. Om en ClaimsPrincipal inte returnerades lagrar hanteraren resultatet och om autentiseringen utmanas (eftersom användaren till exempel har åtkomst till en skyddad resurs) uppdateras begärans svar med statuskoden och valda svarshuvuden från svaret från autentiseringsslutpunkten. Detta gör att utmaningssvar (till exempel omdirigeringar till en inloggningssida) kan spridas till slutanvändare.
      1. Eftersom resultatet från ASP.NET appens autentiserade slutpunkt kan innehålla data som är specifika för den slutpunkten, kan användarna registrera IRemoteAuthenticationResultProcessor implementeringar med ASP.NET Core-appen som körs på eventuella autentiseringsresultat innan de används. Till exempel är det inbyggda IRemoteAuthenticationResultProcessor, som är RedirectUrlProcessor, som letar efter Location-svarshuvuden som returneras från autentiseringsslutpunkten och säkerställer att omdirigeringen går tillbaka till värden för ASP.NET Core-appen och inte direkt till ASP.NET-appen.

Kända begränsningar

Den här fjärrautentiseringsmetoden har några kända begränsningar:

1. Windows-autentisering: Eftersom Windows-autentisering är beroende av hantering av en Windows-identitet stöds inte Windows-autentisering av den här funktionen. Framtida arbete planeras för att utforska hur delad Windows-autentisering kan fungera. Mer information finns under dotnet/systemweb-adapters#246. För Windows-autentiseringsscenarier bör du överväga att använda Konfigurera Windows-autentisering i ASP.NET Core i ditt ASP.NET Core-program i stället.
2. Användarhanteringsåtgärder: Med den här funktionen kan ASP.NET Core-appen använda en identitet som autentiseras av ASP.NET-appen, men alla åtgärder som är relaterade till användare (inloggning, loggning osv.) måste fortfarande dirigeras via ASP.NET-appen.
3. Prestandaöverväganden: Varje autentiseringsbegäran kräver ett HTTP-anrop till ASP.NET-appen, vilket kan påverka prestanda. Överväg att använda delad cookie autentisering (beskrivs i avsnittet Alternativ) om prestandan är kritisk.

Delad cookie autentisering

Om autentiseringen i den ASP.NET appen görs med Microsoft.OwinCookie autentiseringsmellanprogram är en alternativ lösning på fjärrautentisering att konfigurera ASP.NET- och ASP.NET Core-appar så att de kan dela en autentisering cookie.

Så här fungerar delade cookies

Delning av en autentisering cookie möjliggör:

• Båda apparna för att fastställa användaridentiteten från samma cookie.
• När du loggar in eller ut från en app loggas användaren in eller ut ur den andra appen.

Båda programmen är konfigurerade för att:

• Använd samma cookie namn och domäninställningar
• Dela dataskyddsnycklar för cookie kryptering/dekryptering
• Använda kompatibelt cookie mellanprogram för autentisering

På så sätt kan användare som autentiseras i en app autentiseras automatiskt i den andra appen när de gör begäranden.

För- och nackdelar med delad cookie autentisering

Autentiseringsbegränsningar med delade cookies

Observera att eftersom inloggning vanligtvis beror på en specifik databas fungerar inte alla autentiseringsfunktioner i båda apparna:

• Användare bör bara logga in via en av apparna, antingen ASP.NET eller ASP.NET Core-appen, beroende på vilken databas som ska användas.
• Båda apparna kan se användarnas identitet och anspråk.
• Båda apparna kan logga ut användaren.

Information om hur du konfigurerar delning av autentiseringscookies mellan ASP.NET och ASP.NET Core-appar finns i cookie delningsdokumentation. Mer information om cookie autentisering i ASP.NET Core finns i Använda cookie autentisering utan ASP.NET Core Identity.

Följande exempel på GitHub-lagringsplatsen System.Web-adaptrar visar fjärrappautentisering med delad cookie konfiguration som gör att båda apparna kan logga in och ut användare:

• ASP.NET-applikation
• ASP.NET Core-app

När du ska välja delad cookie autentisering

Välj Delad Cookie autentisering när:

• Din ASP.NET app använder Microsoft.Owincookie redan autentisering
• Du kan konfigurera matchande dataskyddsinställningar mellan båda apparna
• Prestanda är viktigt och du vill minimera HTTP-begäranden
• Du vill att båda apparna ska hantera inloggnings-/utloggningsåtgärder för användare
• Du är bekväm med att hantera delade krypteringsnycklar

Delningsautentisering är ett bra alternativ om båda följande är sanna:

• Appen ASP.NET använder redan Microsoft.Owincookie autentisering.
• Det går att uppdatera ASP.NET-appen och ASP.NET Core-appar så att de använder matchande dataskyddsinställningar. Matchande inställningar för delat dataskydd innehåller en delad filsökväg, Redis-cache eller Azure Blob Storage för lagring av dataskyddsnycklar. Mer information finns i ASP.NET Core dataskyddsöversikt.

I andra scenarier är den fjärrautentiseringsmetod som beskrivs tidigare i det här dokumentet mer flexibel och passar förmodligen bättre.

Se även

• Översikt över ASP.NET Core-autentisering
• Introduktion till auktorisering i ASP.NET Core
• Dela autentiseringscookies mellan ASP.NET appar
• Använda cookie autentisering utan ASP.NET Core Identity
• ASP.NET Core Middleware
• Migrera från ASP.NET Framework till ASP.NET Core
• Installation av fjärrapp