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.

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 :

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

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 :

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

Parametr 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í použít zadáním jeho názvu ( ve výchozím nastavení, při volání ale může být zadaný jiný název).

V některých případech se volání 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 přidá voláním . Volání zaregistruje middleware, který používá dříve registrovaná schémata ověřování. 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í 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 .

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(ActionAuthenticationOptions configureOptions).

DefaultScheme

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

• Automaticky se používá jako .
• Eliminuje potřebu specifikovat v nebo .

Chcete-li zakázat automatické použití jediného schématu ověřování jako , použijte .

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 nebo .
• 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 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).

versus

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 , kterou má nastavenou. Obsluha dokončí krok ověřování pomocí informací předaných do zpětné cesty volání . OAuth 2.0 a OIDC oba používají tento vzor. JWT a soubory cookie nemohou, protože mohou přímo použít nosnou hlavičku a k ověření. 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í označující, jestli ověřování proběhlo úspěšně, a pokud ano, identita uživatele v ověřovacím lístku. Viz . Mezi příklady ověřování patří:

• Schéma ověřování , které vytváří identitu uživatele ze souborů cookie.
• Schéma nosného tokenu JWT, které deserializuje a ověřuje nosný token JWT pro 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 . Mezi příklady výzev ověřování patří:

• Schéma ověřování , 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

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 . 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 nosného tokenu JWT vracející výsledek 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:

• Vyvolání a zakázání pomocí zpracovače provozních zdrojů
• 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:

• open source
• 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í