Přehled ověřování ASP.NET Core

Autor: Mike Rousos

Ověřování je proces určení identity uživatele. Autorizace je proces určení, jestli uživatel má přístup k prostředku. V ASP.NET Core se ověřování zpracovává ověřovací službou IAuthenticationService, kterou používá ověřovací middleware. Ověřovací služba používá k dokončení akcí souvisejících s ověřováním registrované obslužné rutiny ověřování. Mezi příklady akcí souvisejících s ověřováním patří:

• Ověření uživatele
• Reakce na pokus neověřeného uživatele o přístup k prostředku s omezeným přístupem

Registrované obslužné rutiny ověřování a jejich konfigurační možnosti se označují jako schémata.

Schémata ověřování jsou určena registrací ověřovacích služeb v Program.cs:

• Voláním rozšiřující metody specifické pro schéma po volání AddAuthentication, například AddJwtBearer nebo AddCookie. Tyto rozšiřující metody slouží AuthenticationBuilder.AddScheme k registraci schémat s odpovídajícím nastavením.
• Méně často přímým voláním AuthenticationBuilder.AddScheme.

Následující kód například registruje ověřovací služby a obslužné rutiny pro schémata ověřování nosných tokenů JWT a cookie:

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => builder.Configuration.Bind("CookieSettings", options));

Parametr AddAuthenticationJwtBearerDefaults.AuthenticationScheme je název schématu, které se má použít ve výchozím nastavení, pokud se nevyžádá konkrétní schéma.

Pokud se používá více schémat, mohou zásady autorizace (nebo atributy autorizace) určit schémata ověřování , na kterých závisí na ověření uživatele. Ve výše uvedeném příkladu je možné schéma ověřování cookie použít zadáním jeho názvu (CookieAuthenticationDefaults.AuthenticationScheme ve výchozím nastavení, při volání AddCookie ale může být zadaný jiný název).

V některých případech se volání AddAuthentication automaticky provádí jinými rozšiřujícími metodami. Například při použití ASP.NET Core Identityse AddAuthentication volá interně.

Middleware pro ověřování se do Program.cs přidá voláním UseAuthentication. Volání UseAuthentication zaregistruje middleware, který používá dříve registrovaná schémata ověřování. UseAuthentication je potřeba volat před jakýmkoli middlewarem, který závisí na ověření uživatelů.

Koncepty ověřování

Ověřování zodpovídá za poskytnutí ClaimsPrincipal pro autorizaci, aby bylo na základě čeho rozhodovat o oprávněních. Existuje více přístupů autentizačních schémat pro výběr toho, která obslužná rutina ověřování zodpovídá za generování správné sady deklarací identity:

• Schéma ověřování
• Výchozí schéma ověřování, které je popsáno v následujících dvou částech.
• Přímo nastavená vlastnost HttpContext.User

Pokud je zaregistrované pouze jedno schéma ověřování, stane se výchozím schématem. Pokud je zaregistrovaných více schémat a není zadáno výchozí schéma, musí být v atributu autorizace zadáno schéma, jinak dojde k následující chybě:

InvalidOperationException: Nebyl zadáno žádné schéma authenticationScheme a nebylo nalezeno žádné schéma DefaultAuthenticateScheme. Výchozí schémata lze nastavit buď pomocí AddAuthentication(string defaultScheme), nebo AddAuthentication(Action<AuthenticationOptions configureOptions> ).

DefaultScheme

Pokud je zaregistrované pouze jedno schéma ověřování, jediné schéma ověřování:

• Automaticky se používá jako DefaultScheme.
• Eliminuje potřebu zadat in DefaultScheme AddAuthentication(IServiceCollection) nebo AddAuthenticationCore(IServiceCollection).

Chcete-li zakázat automatické použití jediného schématu ověřování jako DefaultSchemevolání AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme").

Schéma ověřování

Schéma ověřování může vybrat, která obslužná rutina ověřování zodpovídá za generování správné sady deklarací identity. Další informace najdete v tématu Autorizace s konkrétním schématem.

Schéma ověřování je název, který odpovídá:

• Obslužné rutině ověřování
• Možnostem konfigurace konkrétní instance obslužné rutiny

Schémata jsou užitečná jako mechanismus pro odkazování na chování přidružené obslužné rutiny při ověřování, výzvě a zákazu. Zásady autorizace můžou například použít názvy schémat k určení schématu, která schémata ověřování se mají použít k ověření uživatele. Při konfiguraci ověřování je běžné zadat výchozí schéma ověřování. Výchozí schéma se použije, pokud prostředek nepožaduje konkrétní schéma. Je rovněž možné:

• Zadat různá výchozí schémata, která se mají použít pro akce ověřování, výzvy a zákazu.
• Zkombinovat několik schémat do jednoho pomocí schémat zásad.

Obslužná rutina ověřování

Obslužná rutina ověřování:

• Je typ, který implementuje chování schématu.
• Je odvozená z IAuthenticationHandler nebo AuthenticationHandler<TOptions>.
• Má primární odpovědnost za ověřování uživatelů.

Na základě konfigurace schématu ověřování a kontextu příchozího požadavku obslužné rutiny ověřování:

• Pokud je ověřování úspěšné, vytvoří objekty AuthenticationTicket reprezentující identitu uživatele.
• Pokud ověřování není úspěšné, vrátí hodnotu Žádný výsledek nebo Selhání.
• Mají metody pro výzvu a zakázat akce, pokud se uživatelé pokusí o přístup k prostředkům:
  • Ke kterým nemají oprávnění k přístupu (zákaz).
  • Pokud jsou neověřeni (výzva).

RemoteAuthenticationHandler<TOptions> versus AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> je třída pro ověřování, která vyžaduje krok vzdáleného ověřování. Po dokončení kroku vzdáleného ověřování obslužná rutina volá zpět vlastnost CallbackPath, kterou má nastavenou. Obslužná rutina dokončí krok ověřování pomocí informací předaných do cesty zpětného volání HandleRemoteAuthenticateAsync. Tento model používají OAuth 2.0 i OIDC. JWT a soubory cookie ho nepoužívají, protože mohou k ověření přímo použít hlavičku nosné tokenu a cookie. Vzdáleně hostovaný poskytovatel v tomto případě:

• Je zprostředkovatelem ověřování.
• Mezi příklady patří Facebook, Twitter, Google, Microsoft a jakýkoli jiný poskytovatel OIDC, který zpracovává ověřování uživatelů pomocí mechanismu obslužných rutin.

Ověření

Ověřovací akce schématu ověřování zodpovídá za vytvoření identity uživatele na základě kontextu požadavku. Vrací AuthenticateResult indikující, jestli bylo ověření úspěšné, a pokud ano, identita uživatele v ověřovacím lístku. Viz třída AuthenticateAsync. Mezi příklady ověřování patří:

• Schéma ověřování cookie, které vytváří identitu uživatele ze souborů cookie
• Schéma nosného tokenu JWT, které provádí deserializaci a ověření nosného tokenu JWT pro vytvoření identity uživatele

Výzva

Výzva ověřování se vyvolá autorizací, pokud neověřený uživatel požádá o koncový bod, který vyžaduje ověření. Ověřovací výzva se vydá například v případě, že anonymní uživatel požádá o prostředek s omezeným přístupem nebo použije odkaz pro přihlášení. Autorizace vyvolá výzvu pomocí zadaných schémat ověřování nebo pomocí výchozího schématu ověřování, pokud není zadané žádné schéma. Viz třída ChallengeAsync. Mezi příklady výzev ověřování patří:

• Schéma ověřování cookie, které uživatele přesměruje na přihlašovací stránku
• Schéma nosného tokenu JWT vracející výsledek 401 s hlavičkou www-authenticate: bearer

Akce výzvy by měla uživateli dát vědět, jaký mechanismus ověřování použít pro přístup k požadovanému prostředku.

Zákaz

Akce zákazu schématu se volá autorizací, pokud se ověřený uživatel pokusí o přístup k prostředku, ke kterému nemá povolený přístup. Viz třída ForbidAsync. Mezi příklady zákazu ověřování patří:

• Schéma ověřování cookie, které uživatele přesměruje na s indikací, že přístup byl zakázán
• Schéma nosného tokenu JWT vracející výsledek 403
• Vlastní schéma ověřování, které přesměruje na stránku, kde uživatel může požádat o přístup k prostředku

Akce zákazu může uživateli dát vědět:

• Že je ověřený.
• Že nemá povolený přístup k požadovanému prostředku.

Informace o rozdílech mezi výzvou a zákazem najdete pod následujícími odkazy:

• Výzva a zákaz s využitím obslužné rutiny provozních prostředků
• Rozdíly mezi výzvou a zákazem.

Zprostředkovatelé ověřování pro jednotlivé tenanty

ASP.NET Core nemá integrované řešení pro víceklientské ověřování. I když zákazníci můžou psát některé pomocí integrovaných funkcí, doporučujeme zákazníkům zvážit sadu Orchard Core, ABP Framework nebo Finbuckle.MultiTenant pro víceklientské ověřování.

Orchard Core je:

• Opensourcová, modulární a víceklientská architektura aplikací vytvořená s využitím ASP.NET Core.
• Systém správy obsahu (CMS) postavený na této architektuře.

Příklad zprostředkovatelů pro jednotlivé tenanty najdete ve zdroji informací Orchard Core.

ABP Framework podporuje různé vzory architektury, včetně modularity, mikroslužeb, návrhu řízeného doménou a víceklientské architektury. Projděte si zdroj informací o řešení ABP Framework na GitHubu.

Finbuckle.MultiTenant:

• Open source
• Poskytuje řešení tenanta.
• Lehký
• Poskytuje izolaci dat.
• Jedinečná konfigurace chování aplikací pro každého tenanta

Další materiály

• Autorizace s využitím konkrétního schématu v ASP.NET Core
• Schémata zásad v ASP.NET Core
• Vytvoření aplikace ASP.NET Core s uživatelskými daty chráněnými autorizací
• Globalní vyžadování ověřených uživatelů
• Problém na GitHubu věnovaný použití více schémat ověřování