Migrace ověřování z ASP.NET na ASP.NET Core

Ověřování je důležitou součástí webových aplikací, která zpracovává ověřování identit uživatelů napříč požadavky HTTP. Při migraci z ASP.NET Framework na ASP.NET Core představuje ověřování jedinečné výzvy, protože obě architektury zpracovávají ověřování velmi odlišně.

Obecné informace o ověřování v ASP.NET Core najdete v tématu Přehled ověřování ASP.NET Core. Informace o autorizaci najdete v tématu Úvod k autorizaci v ASP.NET Core.

Proč je migrace ověřování složitá

ASP.NET Framework a ASP.NET Core mají základní různé přístupy k ověřování:

ASP.NET Framework poskytuje integrované ověřovací moduly s automatickou konfigurací a úzkou integrací se systémem System.Web.
ASP.NET Core používá přístup založený na middlewaru s explicitní konfigurací a injektáží závislostí.

Tyto rozdíly znamenají, že beze změn nemůžete jednoduše přesunout ověřovací kód z architektury na Jádro.

Problémy s typy ověřování a migrací

Různé typy ověřování představují různé úrovně složitosti migrace:

ASP.NET Framework: Používá Microsoft.Owincookie middleware pro ověřování
ASP.NET Core: Používá CookieAuthentication middleware s jinou konfigurací
Problém s migrací: Cookie rozdíly ve formátu, šifrovacích klíčích a konfiguraci

Nosné tokeny JWT

ASP.NET Framework: Často se zpracovává prostřednictvím vlastních modulů nebo middlewaru OWIN
ASP.NET Core: Nativní podpora prostřednictvím Microsoft.AspNetCore.Authentication.JwtBearer
Problém s migrací: Rozdíly parametrů ověřování tokenů a registrace middlewaru

Ověřování systému Windows

ASP.NET Framework: Integrovaná integrace služby IIS
ASP.NET Core: Vyžaduje explicitní konfiguraci a může vyžadovat změny modelu hostování.
Problém s migrací: Rozdíly v konfiguraci serveru a toku ověřování

Ověřování pomocí formulářů

ASP.NET Framework: Integrovaná System.Web.Security.FormsAuthentication
ASP.NET Core: Bez přímého ekvivalentu, vyžaduje migraci na cookie autentizaci.
Výzva k migraci: Dokončení potřebného přepsání ověřovacího systému

Vlastní ověřování

ASP.NET Framework: Implementace vlastních modulů IHttpModule
ASP.NET Core: Vlastní middleware nebo obslužné rutiny ověřování
Úloha migrace: Úplná změna architektury z modulů na middleware

Přehled strategií migrace

Během migrace máte tři hlavní přístupy pro zpracování ověřování:

Úplné přepsání – Přepište veškerý ověřovací kód tak, aby používal nativní ověřování ASP.NET Core.
Vzdálené ověřování – Delegování ověřování do aplikace ASP.NET Framework pomocí adaptérů System.Web
Sdílené cookie ověřování – Sdílení souborů cookie ověřování mezi rozhraním a základními aplikacemi (pro scénáře založené na OWIN)

U většiny aplikací poskytuje migrace na nativní ověřování ASP.NET Core nejlepší výkon a udržovatelnost. Větší aplikace nebo aplikace s složitými požadavky na ověřování však mohou těžit z přírůstkového přístupu pomocí adaptérů System.Web.

Volba přístupu k migraci

Pro migraci ověřování z architektury ASP.NET na ASP.NET Core máte tři hlavní možnosti. Vaše volba závisí na typu ověřování, časové ose migrace, na tom, jestli potřebujete současně spouštět obě aplikace a kolik kódu jste ochotni přepsat.

Průvodce rychlým rozhodováním

Odpovězte na tyto otázky a zvolte svůj přístup:

Provádíte úplný přepis nebo přírůstkovou migraci?
- Dokončení přepsání → Dokončení přepsání na ověřování ASP.NET Core
- Přírůstková migrace → Pokračovat na otázku 2
Jaký typ ověřování používá aplikace ASP.NET Framework?
- Ověřování OWIN cookie → Pokračovat v otázce 3
- Ověřování pomocí formulářů, nosné tokeny JWT, ověřování systému Windows nebo vlastní ověřování → vzdálené ověřování
Potřebují aplikace ASP.NET Framework i aplikace ASP.NET Core přístup ke stejnému stavu ověřování?
- Ano, sdílené ověřování potřeba → Pokračovat na otázku 4
- Ne, samostatné ověřování je v pořádku → Kompletní přepis na ověřování ASP.NET Core
Můžete nakonfigurovat odpovídající nastavení ochrany dat mezi oběma aplikacemi?
- Ano → sdílené cookie ověřování (viz část Alternativy, nejlepší výkon)
- Ne nebo si nejste jisti, → vzdálené ověřování

Porovnání přístupů k migraci

Přístup	Změny kódu	Výkon	Sdílení autentizace	Kdy použít
Dokončení přepsání	Vysoká – Přepsat veškerý ověřovací kód	Nejlepší	Žádné	Kompletní přepracování, výkonově kritické aplikace, autentizace bez OWIN
Vzdálené ověřování	Nízká – zachování existujících vzorů	Spravedlivý	Úplný	Přírůstkové migrace, komplexní ověřování, ověřování systému Windows
Sdílené soubory cookie	Střední – konfigurace aktualizace	Dobré	Úplný	Autentizace OWIN cookie, sdílená autentizace kritická pro výkon (viz Alternativy)

Dokončení přepsání na ověřování ASP.NET Core

Tento přístup zvolte, když provádíte úplnou migraci, nemáte ověřování OWIN nebo chcete dosáhnout nejlepšího výkonu a udržovatelnosti.

ASP.NET Core poskytuje komplexní podporu ověřování s vysokým výkonem a rozsáhlými možnostmi přizpůsobení. Tento přístup vyžaduje přepis ověřovacího kódu, ale v dlouhodobém horizontu nabízí největší výhody.

Kompletní přepracování: výhody a nevýhody

Výhody	Nevýhody
Nejlepší výkon a zabezpečení	Vyžaduje přepsání veškerého ověřovacího kódu.
Nativní implementace ASP.NET Core	Žádná automatická cesta migrace
Úplná kontrola nad tokem ověřování	Křivka učení pro nové vzory ověřování
Žádné další závislosti	Zásadní změna v rámci vzorového prostředí
Přístup k nejnovějším funkcím ověřování ASP.NET Core	Potenciální výpadek během migrace

Úvahy o migraci

Při migraci na integrované ověřování ASP.NET Core:

Zvolte na základě typu ověřování frameworku:

Ověřování pomocí formulářů → Migrace na Cookie ověřování
Nosné tokeny JWT → migrovat na ověřování nositele JWT
Ověřování systému Windows → Použít ověřování systému Windows
Poskytovatelé OAUTH OWIN → Použít odpovídající poskytovatele ASP.NET Core OAuth
Vlastní ověřování → Implementace vlastních obslužných rutin ověřování

Požadované změny kódu:

Nahrazení HttpContext.User vzorů přístupu (většinou kompatibilních)
Aktualizace registrace middlewaru ověřování v Program.cs
Migrace vlastní logiky ověřování na vzory ASP.NET Core
Aktualizace atributů autorizace a zásad

Kdy zvolit tento přístup:

Můžete si dovolit přepisovat kód související s ověřováním.
Výkon je nejvyšší prioritou
Nesdílíte stav ověřování se staršími aplikacemi.
Chcete zcela eliminovat závislosti System.Web
Aplikace Framework používá ověřování pomocí formulářů, vlastní moduly nebo tokeny JWT.

Vzdálené ověřování

Poznámka:

Díky tomu se používají adaptéry System.Web Adapters ke zjednodušení migrace.

Tento přístup vyberte, když potřebujete sdílet ověřování mezi aplikacemi ASP.NET Framework a ASP.NET Core během přírůstkové migrace nebo pokud máte složité ověřování, které je obtížné migrovat.

Funkce vzdáleného ověřování adaptérů System.Web umožňuje aplikaci ASP.NET Core určit identitu uživatele využitím aplikace ASP.NET. To umožňuje postupnou migraci při zachování jednoho systému ověřování.

Jak funguje vzdálené ověřování

Pokud žádosti zpracovává aplikace ASP.NET Core, pokud je výchozí schéma vzdáleného ověřování aplikace nebo zadané koncovým bodem požadavku, RemoteAuthenticationAuthHandler pokusí se ověřit uživatele.
Obslužná rutina vytvoří požadavek HTTP na koncový bod ověřování aplikace ASP.NET a předá nakonfigurované hlavičky z aktuálního požadavku (ve výchozím nastavení Authorization a Cookie hlavičky).
Aplikace ASP.NET zpracuje ověřování a vrátí serializovaný ClaimsPrincipal nebo stavový kód HTTP označující selhání.
Aplikace ASP.NET Core používá výsledek k vytvoření identity uživatele nebo zpracování problémů s ověřováním.

Výhody a nevýhody vzdáleného ověřování

Výhody	Nevýhody
Vyžaduje se minimální změny kódu.	Dodatečné náklady požadavků HTTP
Funguje s libovolným typem ověřování frameworku.	Síťová závislost mezi aplikacemi
Možnost postupné migrace	Složitější ladění
Zachovává existující logiku ověřování.	Vyžaduje, aby obě aplikace běžely.
Řeší složité scénáře autentizace.	Omezená podpora ověřování Systému Windows

Kdy zvolit vzdálené ověřování

Zvolte vzdálené ověřování, když:

Vaše aplikace ASP.NET nepoužívá Microsoft.Owincookie ověřování
Chcete flexibilní řešení, které funguje s různými mechanismy ověřování.
Na ASP.NET Core je potřeba postupně migrovat logiku ověřování.
Máte složité ověřování na míru, které je obtížné přepsat
Provádíte postupnou migraci a potřebujete sdílený ověřovací stav.

Konfigurace vzdáleného ověřování

K povolení vzdáleného ověřování v řešení, které je už nastavené podle začínáme, je potřeba jen pár malých změn kódu.

Nejprve postupujte podle pokynů pro nastavení vzdálené aplikace a připojte aplikace ASP.NET Core a ASP.NET. Pak existuje jen několik dalších rozšiřujících metod volání pro povolení vzdáleného ověřování aplikací.

konfigurace aplikace ASP.NET

Aplikaci ASP.NET je potřeba nakonfigurovat tak, aby přidala koncový bod ověřování. Přidání koncového bodu ověřování se provádí voláním AddAuthenticationServer metody rozšíření pro nastavení modulu HTTP, který sleduje požadavky na koncový bod ověřování. Mějte na paměti, že scénáře vzdáleného ověřování obvykle chtějí přidat také podporu proxy serveru, aby všechny související ověřování přesměrovávají správně trasu do aplikace ASP.NET Core, nikoli do ASP.NET.

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

konfigurace aplikace ASP.NET Core

Dále musí být aplikace ASP.NET Core nakonfigurovaná tak, aby povolovala obslužnou rutinu ověřování, která bude ověřovat uživatele provedením požadavku HTTP do aplikace ASP.NET. Opět se to provádí voláním AddAuthenticationClient při registraci služeb System.Web Adapters:

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

Logická hodnota, která se předá AddAuthenticationClient volání, určuje, jestli by vzdálené ověřování aplikací mělo být výchozím schématem ověřování. Předání true způsobí, že se uživatel ověří prostřednictvím vzdáleného ověřování aplikací pro všechny požadavky, zatímco předání false znamená, že se uživatel ověří jenom pomocí vzdáleného ověřování aplikací, pokud je schéma vzdálené aplikace výslovně požadováno (například s [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)] kontrolerem nebo metodou akce). Předání nepravda pro tento parametr má výhodu pouze vytváření požadavků HTTP na původní aplikaci ASP.NET pro ověřování koncových bodů, které vyžadují vzdálené ověřování aplikací, ale má nevýhodu vyžadování poznámek ke všem těmto koncovým bodům, aby bylo možné indikovat, že budou používat vzdálené ověřování aplikací.

Při použití Aspirese konfigurace provede prostřednictvím proměnných prostředí a nastaví ji AppHost. Pokud chcete povolit vzdálenou relaci, musí být tato možnost povolená:

...

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

...

Jakmile to uděláte, automaticky se připojí jak v rozhraní, tak v základních aplikacích.

Použití vzdáleného ověřování s konkrétními koncovými body

Když nastavíte výchozí schéma na false, můžete zadat vzdálené ověřování pro konkrétní kontrolery nebo akce:

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

Implementace vlastních procesorů výsledků ověřování

Než se použijí, můžete implementovat vlastní procesory pro úpravu výsledků ověřování:

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

A konečně, pokud aplikace ASP.NET Core předtím neobsahovala middleware pro ověřování, je potřeba jej povolit (po middleware pro směrování, ale před middlewarem pro autorizaci). Další informace o řazení middlewaru najdete v tématu ASP.NET Core Middleware:

app.UseAuthentication();

Aspekty zabezpečení

Při implementaci vzdáleného ověřování zvažte následující aspekty zabezpečení:

Zabezpečení klíče rozhraní API: Klíč rozhraní API používaný ke komunikaci mezi aplikacemi ASP.NET Core a ASP.NET by se měl bezpečně ukládat pomocí zprostředkovatelů konfigurace a neměl by být pevně zakódovaný.
Zabezpečení sítě: Komunikace mezi aplikacemi by měla probíhat přes zabezpečené kanály (HTTPS) v produkčních prostředích.
Přeposílání hlaviček: Buďte opatrní, abyste se vyhnuli zveřejnění citlivých informací. Předávejte pouze hlavičky, které jsou nezbytné pro ověření.
Endpoint Protection: Koncový bod ověřování v aplikaci ASP.NET by měl být přístupný jenom pro aplikaci ASP.NET Core, ne pro externí klienty.

Řešení problémů

Běžné problémy při konfiguraci vzdáleného ověřování:

Selhání ověřování: Ověřte, že se klíče rozhraní API shodují mezi aplikacemi a že je správně nakonfigurovaná cesta koncového bodu ověřování.
Smyčky přesměrování: Ujistěte se, že RedirectUrlProcessor je správně nakonfigurován tak, aby se přesměroval na aplikaci ASP.NET Core spíše než na aplikaci ASP.NET.
Chybějící deklarace identity: Ověřte, že aplikace ASP.NET správně serializuje ClaimsPrincipal a zda jsou zahrnuty všechny požadované deklarace identity.

Design

Pokud žádosti zpracovává aplikace ASP.NET Core, pokud je výchozí schéma vzdáleného ověřování aplikace nebo zadané koncovým bodem požadavku, RemoteAuthenticationAuthHandler pokusí se ověřit uživatele.
1. Obslužná rutina provede požadavek HTTP na koncový bod ověřování aplikace ASP.NET. Zkopíruje nakonfigurované hlavičky z aktuálního požadavku do tohoto nového, aby bylo možné předávat data relevantní pro ověřování. Jak už bylo zmíněno výše, výchozí chování je zkopírování Authorization a Cookie záhlaví. Hlavička klíče rozhraní API se také přidá pro účely zabezpečení.
Aplikace ASP.NET bude obsluhovat požadavky odeslané do ověřeného koncového bodu. Dokud se klíče rozhraní API shodují, aplikace ASP.NET vrátí buď serializovaný aktuální uživatel ClaimsPrincipal do textu odpovědi, nebo vrátí stavový kód HTTP (například 401 nebo 302) a hlavičky odpovědi označující selhání.
Když aplikace RemoteAuthenticationAuthHandler ASP.NET Core obdrží odpověď z aplikace ASP.NET:
1. Pokud byl ClaimsPrincipal úspěšně vrácen, autentizační obslužná rutina jej deserializuje a použije jako identitu aktuálního uživatele.
2. Pokud se deklarace IdentityPrincipal úspěšně nevrátila, obslužná rutina uloží výsledek a pokud je ověření vyzváno (protože uživatel například přistupuje k chráněnému prostředku), odpověď požadavku se aktualizuje stavovým kódem a vybranými hlavičkami odpovědi z odpovědi z ověřovacího koncového bodu. To umožňuje rozšířit odpovědi na výzvy (například přesměrování na přihlašovací stránku) koncovým uživatelům.
  1. Vzhledem k tomu, že výsledky koncového bodu ověření aplikace ASP.NET můžou zahrnovat data specifická pro tento koncový bod, můžou uživatelé zaregistrovat IRemoteAuthenticationResultProcessor implementace v aplikaci ASP.NET Core, která se bude spouštět na všech výsledcích ověřování, než se použijí. Například integrovaný IRemoteAuthenticationResultProcessor objekt RedirectUrlProcessor vyhledá Location hlavičky odpovědi vrácené z ověřeného koncového bodu a zajistí, že se přesměrují zpět na hostitele aplikace ASP.NET Core, a ne přímo ASP.NET aplikaci.

Známá omezení

Tento přístup vzdáleného ověřování má několik známých omezení:

Ověřování systému Windows: Vzhledem k tomu, že ověřování systému Windows závisí na popisovači identity systému Windows, tato funkce nepodporuje ověřování systému Windows. Budoucí práce se plánuje prozkoumat, jak může fungovat sdílené ověřování systému Windows. Další informace najdete v tématu dotnet/systemweb-adapters#246 . V případě scénářů ověřování systému Windows zvažte použití konfigurace ověřování systému Windows v ASP.NET Core v aplikaci ASP.NET Core.
Akce správy uživatelů: Tato funkce umožňuje aplikaci ASP.NET Core používat identitu ověřenou aplikací ASP.NET, ale všechny akce související s uživateli (přihlášení, odhlášení atd.) se stále musí směrovat prostřednictvím aplikace ASP.NET.
Důležité informace o výkonu: Každý požadavek na ověření vyžaduje volání HTTP do ASP.NET aplikace, což může mít vliv na výkon. Pokud je výkon kritický, zvažte použití sdíleného cookie ověřování (popsaného v části Alternativy).

Pokud se ověřování v aplikaci ASP.NET provádí pomocí Microsoft.OwinCookie middlewaru ověřování, je alternativním řešením vzdáleného ověřování nakonfigurovat ASP.NET a ASP.NET core aplikace tak, aby mohly sdílet ověřování cookie.

Jak sdílené soubory cookie fungují

Sdílení ověřování cookie umožňuje:

Obě aplikace pro určení totožnosti uživatele pomocí stejného cookie.
Přihlášení nebo odhlášení z jedné aplikace uživatele přihlásí nebo odhlásí z druhé aplikace.

Obě aplikace jsou nakonfigurované na:

Použít stejný cookie název a nastavení domény
Sdílení klíčů ochrany dat pro cookie šifrování/dešifrování
Použití kompatibilního cookie ověřovacího middlewaru

To uživatelům ověřeným v jedné aplikaci umožňuje automatické ověření v druhé aplikaci při provádění žádostí.

Výhody	Nevýhody
Nejlepší výkon pro sdílené autentizace	Funguje jenom s autentizací OWIN cookie.
Žádné další požadavky HTTP	Vyžaduje odpovídající nastavení ochrany dat.
Obě aplikace můžou zpracovávat přihlášení nebo odhlášení.	Složitější počáteční konfigurace
Bezproblémové uživatelské prostředí	Omezeno na ověření založené na cookie
Nižší režijní náklady na síť	Vyžaduje koordinaci nasazení.

Omezení ověřování u sdílených souborů cookie

Upozorňujeme, že vzhledem k tomu, že přihlášení obvykle závisí na konkrétní databázi, nebudou v obou aplikacích fungovat všechny funkce ověřování:

Uživatelé by se měli přihlásit jenom prostřednictvím jedné z aplikací, ať už ASP.NET, nebo ASP.NET core, podle toho, s jakou databází se má pracovat.
Obě aplikace vidí identitu a nároky uživatelů.
Obě aplikace můžou uživatele odhlásit.

Podrobnosti o konfiguraci souborů cookie pro ověřování sdílení mezi aplikacemi ASP.NET a ASP.NET Core jsou k dispozici v cookie dokumentaci ke sdílení. Další informace o cookie ověřování v ASP.NET Core naleznete v tématu Použití cookie ověřování bez ASP.NET Core Identity.

Následující ukázky v úložišti System.Web Adapters Na GitHubu demonstrují vzdálené ověřování aplikací se sdílenou cookie konfigurací, která umožňuje oběma aplikacím přihlašovat uživatele a odhlašovat se:

aplikace ASP.NET
aplikace ASP.NET Core

Zvolte sdílené Cookie ověřování, když:

Vaše aplikace ASP.NET už používá Microsoft.Owincookie ověřování
Můžete nakonfigurovat odpovídající nastavení ochrany dat mezi oběma aplikacemi.
Výkon je kritický a chcete minimalizovat požadavky HTTP.
Chcete, aby obě aplikace zpracovávaly operace přihlašování a odhlášení uživatelů.
Jste spokojení se správou sdílených šifrovacích klíčů

Ověřování sdílením je dobrou volbou, pokud platí obě tyto možnosti:

Aplikace ASP.NET už používá Microsoft.Owincookie ověřování.
Aplikaci ASP.NET a aplikace ASP.NET Core je možné aktualizovat tak, aby používaly odpovídající nastavení ochrany dat. Odpovídající nastavení sdílené ochrany dat zahrnuje sdílenou cestu k souboru, mezipaměť Redis nebo Azure Blob Storage pro ukládání klíčů ochrany dat. Další informace najdete v tématu Přehled ochrany dat ASP.NET Core.

V jiných scénářích je přístup vzdáleného ověřování popsaný dříve v tomto dokumentu flexibilnější a pravděpodobně je vhodnější.

Viz také

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-09-24