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

Autor: Mike Rousos

Ověřování je proces určení identity uživatele. Authorization je proces určení, jestli má uživatel access k prostředku. V ASP.NET Core je ověřování zpracováno pomocí služby pro ověření, , kterou využívá middleware pro ověření . Ověřovací služba používá registrované ověřovací procesory k provedení úkonů souvisejících s ověřováním. Mezi příklady akcí souvisejících s ověřováním patří:

• Ověření uživatele
• Reagování na pokus neověřeného uživatele o přístup k omezenému prostředku.

Konfigurace ověřování automaticky neomezuje přístup ke koncovým bodům. Pokud chcete ve výchozím nastavení vyžadovat ověřené uživatele v aplikaci na straně serveru, nakonfigurujte záložní zásady autorizace.

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 používají AuthenticationBuilder.AddScheme k registraci schémat s odpovídajícím nastavením.
• Méně často přímým voláním AuthenticationBuilder.AddScheme.

Například následující kód registruje služby ověřování a handlery pro schémata ověřování Bearer cookie a JWT:

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 Identity se 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í. Je potřeba volat UseAuthentication 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 nastavte 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: Nebylo zadáno žádné authenticationScheme a nebylo nalezeno žádné 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 specifikovat DefaultScheme v AddAuthentication(IServiceCollection) nebo AddAuthenticationCore(IServiceCollection).

Chcete-li zakázat automatické použití jediného schématu ověřování jako DefaultScheme, použijte 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á:

• Zpracovatel ověřování
• Možnosti pro konfiguraci konkrétní instance obslužné rutiny

Schémata jsou užitečná jako mechanismus pro odkazování na ověřování, výzvy a zakázání chování spojené s obslužnou rutinou. Zásady autorizace mohou například použít názvy schémat ke specifikaci, která schémata ověřování by měla být použita 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.

Modul 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í fungují tak, že:

• Vytvořte AuthenticationTicket objekty představující identitu uživatele, pokud je ověřování úspěšné.
• Pokud ověřování není úspěšné, vrátí hodnotu Žádný výsledek nebo Selhání.
• Mějte metody pro vyzývání a zakazování akcí, pokud se uživatelé pokusí přistupovat k prostředkům:
  • Nemají oprávnění k přístupu (zakázáno).
  • 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. Obsluha dokončí krok ověřování pomocí informací předaných do zpětné cesty volání HandleRemoteAuthenticateAsync. OAuth 2.0 a OIDC oba používají tento vzor. JWT a cookies ne, protože k ověření mohou přímo používat hlavičku Bearer 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.

Autentizace

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

• Schéma ověřování cookie, které vytváří identitu uživatele ze souborů cookie.
• JWT Schéma Bearer, které deserializuje a ověřuje token JWT Bearer za účelem vytvoření identity uživatele.

Úkol

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 výchozího schéma, pokud žádné není specifikováno. Viz 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 JWT Bearer, které vrací stavový kód 401 s hlavičkou www-authenticate: bearer.

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

Zákaz

Pokud se ověřený uživatel pokusí získat přístup k prostředku, ke kterému nemá povolený přístup, autorizace vyvolá akci zakázání schématu ověřování. Viz ForbidAsync. Mezi příklady, kdy je ověřování zakázáno, patří:

• Schéma ověřování cookie přesměruje uživatele na stránku indikující, že přístup byl zakázán.
• Schéma JWT Bearer vracející stavový kód 403.
• Vlastní schéma ověřování přesměrovávající na stránku, kde si uživatel může vyžádat přístup k prostředku.

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

• Jsou autentizovaní.
• Nemají oprávnění k přístupu k požadovanému prostředku.

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

• Autorizace založená na zdrojích.
• Rozdíly mezi výzvou a zákazem.

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

ASP.NET Core nemá integrované řešení pro ověřování s více tenanty. Ačkoli mohou zákazníci napsat vlastní řešení pomocí vestavěných funkcí, doporučujeme zvážit Orchard Core, ABP Framework nebo Finbuckle.MultiTenant pro multitenantní ověřování.

Orchard Core je:

• Opensourcová, modulární a víceklientština aplikační architektura vytvořená pomocí ASP.NET Core.
• Systém správy obsahu (CMS) vytvořený nad tím aplikačním frameworkem.

Příklad zprostředkovatelů ověřování na tenanta najdete ve zdroji Orchard Core.

ABP Framework podporuje různé vzory architektury, včetně modularity, mikroslužeb, návrhu řízeného doménou a víceklientské architektury. Viz zdroj ABP Framework na GitHub.

Finbuckle.MultiTenant:

• Otevřený zdrojový kód
• Poskytuje vyřešení nájemce.
• Lehký
• Poskytuje izolaci dat.
• Jedinečná konfigurace chování aplikací pro každého tenanta

Další materiály

• Autorizace s konkrétním schématem v ASP.NET Core
• Policy schémata 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ů
• GitHub problém s používáním více schémat ověřování