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

  • Článek

Autor: Mike Rousos

Ověřování je proces určení uživatele identity. 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:

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:

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í:

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í:

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

  • Objekty AuthenticationTicket představující uživatele identity , pokud je ověřování úspěšné.
  • 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 ne, protože mohou přímo použít nosnou hlavičku a cookie ověřit. 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í odpovídá za vytvoření uživatele identity na základě kontextu požadavku. Vrátí indikující AuthenticateResult , jestli bylo ověření úspěšné, a pokud ano, znamená to, že uživatel je identity v ověřovacím lístku. Viz třída AuthenticateAsync. Mezi příklady ověřování patří:

  • cookie Schéma ověřování, které vytváří uživatele identity ze souborů cookie.
  • Nosné schéma JWT deserializace a ověření nosný token JWT pro vytvoření uživatele identity.

Ú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 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:

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

Autor: Mike Rousos

Ověřování je proces určení uživatele identity. 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:

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:

Automatické testování schémat není k dispozici. Pokud není zadané výchozí schéma, musí být schéma zadáno v atributu autorizace, jinak se vyvolá následující chyba:

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

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í:

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

  • Objekty AuthenticationTicket představující uživatele identity , pokud je ověřování úspěšné.
  • 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 ne, protože mohou přímo použít nosnou hlavičku a cookie ověřit. 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í odpovídá za vytvoření uživatele identity na základě kontextu požadavku. Vrátí indikující AuthenticateResult , jestli bylo ověření úspěšné, a pokud ano, znamená to, že uživatel je identity v ověřovacím lístku. Viz třída AuthenticateAsync. Mezi příklady ověřování patří:

  • cookie Schéma ověřování, které vytváří uživatele identity ze souborů cookie.
  • Nosné schéma JWT deserializace a ověření nosný token JWT pro vytvoření uživatele identity.

Ú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 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:

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

ASP.NET Core nemá integrované řešení pro víceklientské ověřování. I když je možné, aby si zákazníci takové řešení napsali sami pomocí vestavěných funkcí, doporučujeme zákazníkům, aby pro víceklientské ověřování zvážili použití řešení Orchard Core nebo ABP Framework .

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.

Další materiály

Autor: Mike Rousos

Ověřování je proces určení uživatele identity. 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 Startup.ConfigureServices:

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:

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(JwtBearerDefaults.AuthenticationScheme,
        options => Configuration.Bind("JwtSettings", options))
    .AddCookie(CookieAuthenticationDefaults.AuthenticationScheme,
        options => 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 Startup.Configure 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ů. Při použití směrování koncového bodu musí volání UseAuthentication:

  • Následovat po UseRouting, aby pro rozhodování o ověřování byly k dispozici informace o trasách.
  • Předcházet UseEndpoints, aby uživatelé byli ověřeni před přístupem ke koncovým bodům.

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:

Automatické testování schémat není k dispozici. Pokud není zadané výchozí schéma, musí být schéma zadáno v atributu autorizace, jinak se vyvolá následující chyba:

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

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í:

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

  • Objekty AuthenticationTicket představující uživatele identity , pokud je ověřování úspěšné.
  • 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 ne, protože mohou přímo použít nosnou hlavičku a cookie ověřit. 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í odpovídá za vytvoření uživatele identity na základě kontextu požadavku. Vrátí indikující AuthenticateResult , jestli bylo ověření úspěšné, a pokud ano, znamená to, že uživatel je identity v ověřovacím lístku. Viz třída AuthenticateAsync. Mezi příklady ověřování patří:

  • cookie Schéma ověřování, které vytváří uživatele identity ze souborů cookie.
  • Nosné schéma JWT deserializace a ověření nosný token JWT pro vytvoření uživatele identity.

Ú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 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:

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

Architektura ASP.NET Core nemá integrované řešení pro víceklientské ověřování. I když je možné, aby si zákazníci sami napsali aplikaci s víceklientským ověřováním, doporučujeme použít jednu z následujících aplikačních architektur ASP.NET Core, které podporují víceklientské ověřování:

Orchard Core

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

ABP Framework

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.

Další materiály