Delen via

Overzicht van ASP.NET Core-verificatie

Door Mike Rousos

Verificatie is het proces van het bepalen van de identiteit van een gebruiker. Authorization is het proces om te bepalen of een gebruiker access aan een resource heeft. In ASP.NET Core wordt verificatie verwerkt door de IAuthenticationService verificatieservice, die wordt gebruikt door de verificatie-middleware. De verificatieservice maakt gebruik van geregistreerde verificatiehandlers om verificatiegerelateerde acties te voltooien. Voorbeelden van verificatiegerelateerde acties zijn:

  • Een gebruiker verifiëren.
  • Reageren wanneer een niet-geverifieerde gebruiker probeert een beperkte resource te access.

De geregistreerde verificatiehandlers en hun configuratieopties worden schema's genoemd.

Verificatieschema's worden opgegeven door verificatieservices te registreren in :

  • Door een schemaspecifieke uitbreidingsmethode aan te roepen na een aanroep naar , zoals of . Deze uitbreidingsmethoden gebruiken voor het registreren van schema's met de juiste instellingen.
  • Minder vaak gebeurt dit door rechtstreeks te bellen.

Met de volgende code worden bijvoorbeeld verificatieservices en handlers geregistreerd voor en JWT Bearer-verificatieschema's:

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

De parameter is de naam van het schema dat standaard moet worden gebruikt wanneer er geen specifiek schema wordt aangevraagd.

Als er meerdere schema's worden gebruikt, kunnen autorisatiebeleidsregels (of autorisatiekenmerken) het verificatieschema (of schema's) opgeven waarop ze afhankelijk zijn om de gebruiker te verifiëren. In het bovenstaande voorbeeld kan het verificatieschema worden gebruikt door de naam ervan op te geven () standaard, hoewel een andere naam kan worden opgegeven wanneer wordt aangeroepen.

In sommige gevallen wordt de oproep naar automatisch uitgevoerd door andere extensiemethoden. Wanneer u bijvoorbeeld ASP.NET Core Identity gebruikt, wordt AddAuthentication intern aangeroepen.

De authenticatiemiddleware wordt toegevoegd in door aan te roepen. Bij het aanroepen wordt de middleware geregistreerd die gebruikmaakt van de eerder geregistreerde verificatieschema's. Roep aan vóór middleware die afhankelijk is van gebruikers die geauthenticeerd zijn.

Verificatieconcepten

Verificatie is verantwoordelijk voor het verlenen van toestemming om beslissingen te nemen over machtigingen. Er zijn meerdere verificatieschemamethoden om te selecteren welke verificatie-handler verantwoordelijk is voor het genereren van de juiste set claims:

  • Verificatieschema
  • Het standaardverificatieschema, besproken in de volgende twee secties.
  • direct instellen.

Wanneer er slechts één verificatieschema is geregistreerd, wordt dit het standaardschema. Als er meerdere schema's zijn geregistreerd en het standaardschema niet is opgegeven, moet een schema worden opgegeven in het kenmerk Autoriseren, anders wordt de volgende fout gegenereerd:

InvalidOperationException: Er is geen authenticationScheme opgegeven en er is geen DefaultAuthenticateScheme gevonden. De standaardschema's kunnen worden ingesteld met AddAuthentication(string defaultScheme) of AddAuthentication(ActionAuthenticationOptions configureOptions).

DefaultScheme

Wanneer er slechts één verificatieschema is geregistreerd, wordt het enkele verificatieschema gebruikt:

  • Wordt automatisch gebruikt als de .
  • Elimineert de noodzaak om in of op te nemen.

Als u automatisch wilt uitschakelen met behulp van het enkele verificatieschema als de aanroep .

Verificatieschema

Het verificatieschema kan selecteren welke verificatiehandler verantwoordelijk is voor het genereren van de juiste set claims. Zie Autoriseren met een specifiek schema voor meer informatie.

Een verificatieschema is een naam die overeenkomt met:

  • Een verificatiehandler.
  • Opties voor het configureren van dat specifieke exemplaar van de handler.

Schema's zijn handig als mechanisme voor het verwijzen naar de verificatie, uitdaging en verbieden van gedrag van de bijbehorende handler. Een autorisatiebeleid kan bijvoorbeeld schemanamen gebruiken om op te geven welk verificatieschema (of schema's) moet worden gebruikt om de gebruiker te verifiëren. Bij het configureren van verificatie is het gebruikelijk om het standaardverificatieschema op te geven. Het standaardschema wordt gebruikt, tenzij een resource een specifiek schema aanvraagt. Het is ook mogelijk om:

  • Geef verschillende standaardschema's op die moeten worden gebruikt voor verificatie, uitdaging en verbieden van acties.
  • Combineer meerdere schema's in één met behulp van beleidsschema's.

Verificatiehandler

Een verificatiehandler:

  • Is een type waarmee het gedrag van een schema wordt geïmplementeerd.
  • Is afgeleid van of .
  • Heeft de primaire verantwoordelijkheid om gebruikers te verifiëren.

Op basis van de configuratie van het verificatieschema en de context van de binnenkomende aanvraag, zijn verificatiehandlers:

  • Maak objecten die de identiteit van de gebruiker vertegenwoordigen als de verificatie is geslaagd.
  • Retourneert 'geen resultaat' of 'fout' als verificatie mislukt.
  • Methoden hebben om acties te blokkeren en te verbieden wanneer gebruikers proberen toegang te krijgen tot resources.
    • Ze zijn niet gemachtigd om toegang te krijgen (verboden).
    • Wanneer ze niet zijn geverifieerd (uitdaging).

versus

is de klasse voor verificatie waarvoor een externe verificatiestap is vereist. Wanneer de stap voor externe verificatie is voltooid, roept de handler terug naar de set door de handler. De handler voltooit de verificatiestap met behulp van de informatie die wordt doorgegeven aan het callback-pad. OAuth 2.0 en OIDC beide gebruiken dit patroon. JWT en cookies hebben dat niet nodig aangezien ze de bearer-header rechtstreeks kunnen gebruiken en om te authenticeren. De extern gehoste provider in dit geval:

  • Is de verificatieprovider.
  • Voorbeelden hiervan zijn Facebook, Twitter, Google, Microsoft en een andere OIDC-provider die verificatie van gebruikers afhandelt met behulp van het handlersmechanisme.

Authenticate

De verificatieactie van een verificatieschema is verantwoordelijk voor het samenstellen van de identiteit van de gebruiker op basis van de aanvraagcontext. Het retourneert een vermelding die aangeeft of de verificatie is geslaagd en, als dat het zo is, de identiteit van de gebruiker in een verificatieticket. Zie . Voorbeelden van authenticatie zijn:

  • Een verificatieschema waarmee de identiteit van de gebruiker wordt samengesteld uit cookies.
  • Een JWT bearer-schema dat een JWT bearer-token deserialiseert en valideert om de identiteit van de gebruiker op te bouwen.

Uitdaging

Een verificatievraag wordt aangeroepen door autorisatie wanneer een niet-geverifieerde gebruiker een eindpunt aanvraagt waarvoor verificatie is vereist. Er wordt bijvoorbeeld een verificatievraag uitgevoerd wanneer een anonieme gebruiker een beperkte resource aanvraagt of een aanmeldingskoppeling volgt. Autorisatie roept een uitdaging aan met behulp van de opgegeven verificatieschema's of de standaardinstelling als er geen is opgegeven. Zie . Voorbeelden van verificatievragen zijn:

  • Een verificatieschema waarmee de gebruiker wordt omgeleid naar een aanmeldingspagina.
  • Een JWT bearer-schema retourneert een 401-resultaat met een header.

Een uitdagingsactie moet de gebruiker laten weten welk verificatiemechanisme moet worden gebruikt om de aangevraagde resource te access.

Verbieden

De verbodsactie van een verificatieschema wordt aangeroepen door de autorisatie wanneer een geverifieerde gebruiker probeert toegang te krijgen tot een resource waar de toegang niet is toegestaan. Zie . Verboden voorbeelden van authenticatie zijn:

  • Een cookie verificatieschema waarmee de gebruiker wordt omgeleid naar een pagina die aangeeft dat access verboden was.
  • Een JWT bearer-schema retourneert een 403-resultaat.
  • Een aangepast verificatieschema dat wordt omgeleid naar een pagina waar de gebruiker access aan de resource kan aanvragen.

Een verbodshandeling kan de gebruiker informeren.

  • Ze worden geverifieerd.
  • Het is hen niet toegestaan om toegang te krijgen tot de aangevraagde bron.

Zie de volgende koppelingen voor verschillen tussen uitdaging en verbieden:

  • Uitdagen en blokkeren met een operationele resource-handler.
  • Verschillen tussen uitdaging en verbieden.

Verificatieproviders per tenant

ASP.NET Core heeft geen ingebouwde oplossing voor verificatie met meerdere tenants. Hoewel het mogelijk is voor klanten om er een te schrijven met behulp van de ingebouwde functies, raden we klanten aan om te overwegen Orchard Core, ABP Framework of Finbuckle.MultiTenant voor verificatie met meerdere tenants.

Orchard Core is:

  • Een opensource-, modulaire en multitenant-app-framework dat is gebouwd met ASP.NET Core.
  • Een cms (content management system) dat is gebouwd op basis van dat app-framework.

Zie de bron Orsight Core voor een voorbeeld van verificatieproviders per tenant.

ABP Framework ondersteunt verschillende architectuurpatronen, waaronder modulariteit, microservices, domeingestuurd ontwerp en multitenancy. Zie ABP Framework-bron op GitHub.

Finbuckle.MultiTenant:

  • open source
  • Biedt tenantomzetting
  • Lichtgewicht
  • Biedt gegevensisolatie
  • App-gedrag uniek configureren voor elke tenant

Aanvullende bronnen

Door Mike Rousos

Verificatie is het proces van het bepalen van de identiteit van een gebruiker. Authorization is het proces om te bepalen of een gebruiker access aan een resource heeft. In ASP.NET Core wordt verificatie verwerkt door de IAuthenticationService verificatieservice, die wordt gebruikt door de verificatie-middleware. De verificatieservice maakt gebruik van geregistreerde verificatiehandlers om verificatiegerelateerde acties te voltooien. Voorbeelden van verificatiegerelateerde acties zijn:

  • Een gebruiker verifiëren.
  • Reageren wanneer een niet-geverifieerde gebruiker probeert een beperkte resource te access.

De geregistreerde verificatiehandlers en hun configuratieopties worden schema's genoemd.

Verificatieschema's worden opgegeven door verificatieservices te registreren in :

  • Door een schemaspecifieke uitbreidingsmethode aan te roepen na een aanroep naar , zoals of . Deze uitbreidingsmethoden gebruiken voor het registreren van schema's met de juiste instellingen.
  • Minder vaak gebeurt dit door rechtstreeks te bellen.

Met de volgende code worden bijvoorbeeld verificatieservices en handlers geregistreerd voor en JWT Bearer-verificatieschema's:

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

De parameter is de naam van het schema dat standaard moet worden gebruikt wanneer er geen specifiek schema wordt aangevraagd.

Als er meerdere schema's worden gebruikt, kunnen autorisatiebeleidsregels (of autorisatiekenmerken) het verificatieschema (of schema's) opgeven waarop ze afhankelijk zijn om de gebruiker te verifiëren. In het bovenstaande voorbeeld kan het verificatieschema worden gebruikt door de naam ervan op te geven () standaard, hoewel een andere naam kan worden opgegeven wanneer wordt aangeroepen.

In sommige gevallen wordt de oproep naar automatisch uitgevoerd door andere extensiemethoden. Wanneer u bijvoorbeeld ASP.NET Core Identity gebruikt, wordt AddAuthentication intern aangeroepen.

De authenticatiemiddleware wordt toegevoegd in door aan te roepen. Bij het aanroepen wordt de middleware geregistreerd die gebruikmaakt van de eerder geregistreerde verificatieschema's. Roep aan vóór middleware die afhankelijk is van gebruikers die geauthenticeerd zijn.

Verificatieconcepten

Verificatie is verantwoordelijk voor het verlenen van toestemming om beslissingen te nemen over machtigingen. Er zijn meerdere verificatieschemamethoden om te selecteren welke verificatie-handler verantwoordelijk is voor het genereren van de juiste set claims:

  • Verificatieschema
  • Het standaardverificatieschema, besproken in de volgende sectie.
  • direct instellen.

Er is geen automatische peiling van schema's. Als het standaardschema niet is opgegeven, moet het schema worden opgegeven in het kenmerk Autoriseren, anders wordt de volgende fout gegenereerd:

InvalidOperationException: Er is geen authenticationScheme opgegeven en er is geen DefaultAuthenticateScheme gevonden. De standaardschema's kunnen worden ingesteld met AddAuthentication(string defaultScheme) of AddAuthentication(ActionAuthenticationOptions configureOptions).

Verificatieschema

Het verificatieschema kan selecteren welke verificatiehandler verantwoordelijk is voor het genereren van de juiste set claims. Zie Autoriseren met een specifiek schema voor meer informatie.

Een verificatieschema is een naam die overeenkomt met:

  • Een verificatiehandler.
  • Opties voor het configureren van dat specifieke exemplaar van de handler.

Schema's zijn handig als mechanisme voor het verwijzen naar de verificatie, uitdaging en verbieden van gedrag van de bijbehorende handler. Een autorisatiebeleid kan bijvoorbeeld schemanamen gebruiken om op te geven welk verificatieschema (of schema's) moet worden gebruikt om de gebruiker te verifiëren. Bij het configureren van verificatie is het gebruikelijk om het standaardverificatieschema op te geven. Het standaardschema wordt gebruikt, tenzij een resource een specifiek schema aanvraagt. Het is ook mogelijk om:

  • Geef verschillende standaardschema's op die moeten worden gebruikt voor verificatie, uitdaging en verbieden van acties.
  • Combineer meerdere schema's in één met behulp van beleidsschema's.

Verificatiehandler

Een verificatiehandler:

  • Is een type waarmee het gedrag van een schema wordt geïmplementeerd.
  • Is afgeleid van of .
  • Heeft de primaire verantwoordelijkheid om gebruikers te verifiëren.

Op basis van de configuratie van het verificatieschema en de context van de binnenkomende aanvraag, zijn verificatiehandlers:

  • Maak objecten die de identiteit van de gebruiker vertegenwoordigen als de verificatie is geslaagd.
  • Retourneert 'geen resultaat' of 'fout' als verificatie mislukt.
  • Zorg voor methoden om uitdagingen aan te bieden en acties te verbieden wanneer gebruikers proberen toegang te krijgen tot bronnen.
    • Ze hebben geen toestemming om toegang te hebben.
    • Wanneer ze niet zijn geverifieerd (uitdaging).

versus

is de klasse voor verificatie waarvoor een externe verificatiestap is vereist. Wanneer de stap voor externe verificatie is voltooid, roept de handler terug naar de set door de handler. De handler voltooit de verificatiestap met behulp van de informatie die wordt doorgegeven aan het callback-pad. OAuth 2.0 en OIDC beide gebruiken dit patroon. JWT en cookies hebben dat niet nodig aangezien ze de bearer-header rechtstreeks kunnen gebruiken en om te authenticeren. De extern gehoste provider in dit geval:

  • Is de verificatieprovider.
  • Voorbeelden hiervan zijn Facebook, Twitter, Google, Microsoft en een andere OIDC-provider die verificatie van gebruikers afhandelt met behulp van het handlersmechanisme.

Authenticate

De verificatieactie van een verificatieschema is verantwoordelijk voor het samenstellen van de identiteit van de gebruiker op basis van de aanvraagcontext. Het retourneert een vermelding die aangeeft of de verificatie is geslaagd en, als dat het zo is, de identiteit van de gebruiker in een verificatieticket. Zie . Voorbeelden van authenticatie zijn:

  • Een verificatieschema waarmee de identiteit van de gebruiker wordt samengesteld uit cookies.
  • Een JWT bearer-schema dat een JWT bearer-token deserialiseert en valideert om de identiteit van de gebruiker op te bouwen.

Uitdaging

Een verificatievraag wordt aangeroepen door autorisatie wanneer een niet-geverifieerde gebruiker een eindpunt aanvraagt waarvoor verificatie is vereist. Er wordt bijvoorbeeld een verificatievraag uitgevoerd wanneer een anonieme gebruiker een beperkte resource aanvraagt of een aanmeldingskoppeling volgt. Autorisatie roept een uitdaging aan met behulp van de opgegeven verificatieschema's of de standaardinstelling als er geen is opgegeven. Zie . Voorbeelden van verificatievragen zijn:

  • Een verificatieschema waarmee de gebruiker wordt omgeleid naar een aanmeldingspagina.
  • Een JWT bearer-schema retourneert een 401-resultaat met een header.

Een uitdagingsactie moet de gebruiker laten weten welk verificatiemechanisme moet worden gebruikt om de aangevraagde resource te access.

Verbieden

De verbodsactie van een authenticatieschema wordt door Autorisatie aangeroepen wanneer een geverifieerde gebruiker probeert toegang te krijgen tot een bron waartoe hij geen toegang heeft. Zie . Verboden voorbeelden van authenticatie zijn:

  • Een cookie verificatieschema waarmee de gebruiker wordt omgeleid naar een pagina die aangeeft dat access verboden was.
  • Een JWT bearer-schema retourneert een 403-resultaat.
  • Een aangepast verificatieschema dat wordt omgeleid naar een pagina waar de gebruiker access aan de resource kan aanvragen.

Een verbodshandeling kan de gebruiker informeren.

  • Ze worden geverifieerd.
  • Ze hebben geen toestemming om de aangevraagde bron te benaderen.

Zie de volgende koppelingen voor verschillen tussen uitdaging en verbieden:

  • Uitdagen en blokkeren met een operationele resource-handler.
  • Verschillen tussen uitdaging en verbieden.

Verificatieproviders per tenant

ASP.NET Core heeft geen ingebouwde oplossing voor verificatie met meerdere tenants. Hoewel het mogelijk is voor klanten om er een te schrijven met behulp van de ingebouwde functies, raden we klanten aan om te overwegen Orsight Core of ABP Framework voor verificatie met meerdere tenants.

Orchard Core is:

  • Een opensource-, modulaire en multitenant-app-framework dat is gebouwd met ASP.NET Core.
  • Een cms (content management system) dat is gebouwd op basis van dat app-framework.

Zie de bron Orsight Core voor een voorbeeld van verificatieproviders per tenant.

ABP Framework ondersteunt verschillende architectuurpatronen, waaronder modulariteit, microservices, domeingestuurd ontwerp en multitenancy. Zie ABP Framework-bron op GitHub.

Aanvullende bronnen

Door Mike Rousos

Verificatie is het proces van het bepalen van de identiteit van een gebruiker. Authorization is het proces om te bepalen of een gebruiker access aan een resource heeft. In ASP.NET Core wordt verificatie verwerkt door de IAuthenticationService verificatieservice, die wordt gebruikt door de verificatie-middleware. De verificatieservice maakt gebruik van geregistreerde verificatiehandlers om verificatiegerelateerde acties te voltooien. Voorbeelden van verificatiegerelateerde acties zijn:

  • Een gebruiker verifiëren.
  • Reageren wanneer een niet-geverifieerde gebruiker probeert een beperkte resource te access.

De geregistreerde verificatiehandlers en hun configuratieopties worden schema's genoemd.

Verificatieschema's worden opgegeven door verificatieservices te registreren in :

  • Door een schemaspecifieke extensiemethode aan te roepen na een aanroep naar (bijvoorbeeld of ). Deze uitbreidingsmethoden gebruiken voor het registreren van schema's met de juiste instellingen.
  • Minder vaak gebeurt dit door rechtstreeks te bellen.

Met de volgende code worden bijvoorbeeld verificatieservices en handlers geregistreerd voor en JWT Bearer-verificatieschema's:

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

De parameter is de naam van het schema dat standaard moet worden gebruikt wanneer er geen specifiek schema wordt aangevraagd.

Als er meerdere schema's worden gebruikt, kunnen autorisatiebeleidsregels (of autorisatiekenmerken) het verificatieschema (of schema's) opgeven waarop ze afhankelijk zijn om de gebruiker te verifiëren. In het bovenstaande voorbeeld kan het verificatieschema worden gebruikt door de naam ervan op te geven () standaard, hoewel een andere naam kan worden opgegeven wanneer wordt aangeroepen.

In sommige gevallen wordt de oproep naar automatisch uitgevoerd door andere extensiemethoden. Wanneer u bijvoorbeeld ASP.NET Core Identity gebruikt, wordt AddAuthentication intern aangeroepen.

De authenticatiemiddleware wordt toegevoegd in door aan te roepen. Bij het aanroepen wordt de middleware geregistreerd die gebruikmaakt van de eerder geregistreerde verificatieschema's. Roep aan vóór middleware die afhankelijk is van gebruikers die geauthenticeerd zijn. Wanneer u eindpuntroutering gebruikt, moet de aanroep naar gaan.

  • Na , zodat route-informatie beschikbaar is voor verificatiebeslissingen.
  • Vóór , zodat gebruikers worden geverifieerd voordat ze toegang krijgen tot de eindpunten.

Verificatieconcepten

Verificatie is verantwoordelijk voor het verlenen van toestemming om beslissingen te nemen over machtigingen. Er zijn meerdere verificatieschemamethoden om te selecteren welke verificatie-handler verantwoordelijk is voor het genereren van de juiste set claims:

  • Verificatieschema
  • Het standaardverificatieschema, besproken in de volgende sectie.
  • direct instellen.

Er is geen automatische peiling van schema's. Als het standaardschema niet is opgegeven, moet het schema worden opgegeven in het kenmerk Autoriseren, anders wordt de volgende fout gegenereerd:

InvalidOperationException: Er is geen authenticationScheme opgegeven en er is geen DefaultAuthenticateScheme gevonden. De standaardschema's kunnen worden ingesteld met AddAuthentication(string defaultScheme) of AddAuthentication(ActionAuthenticationOptions configureOptions).

Verificatieschema

Het verificatieschema kan selecteren welke verificatiehandler verantwoordelijk is voor het genereren van de juiste set claims. Zie Autoriseren met een specifiek schema voor meer informatie.

Een verificatieschema is een naam die overeenkomt met:

  • Een verificatiehandler.
  • Opties voor het configureren van dat specifieke exemplaar van de handler.

Schema's zijn handig als mechanisme voor het verwijzen naar de verificatie, uitdaging en verbieden van gedrag van de bijbehorende handler. Een autorisatiebeleid kan bijvoorbeeld schemanamen gebruiken om op te geven welk verificatieschema (of schema's) moet worden gebruikt om de gebruiker te verifiëren. Bij het configureren van verificatie is het gebruikelijk om het standaardverificatieschema op te geven. Het standaardschema wordt gebruikt, tenzij een resource een specifiek schema aanvraagt. Het is ook mogelijk om:

  • Geef verschillende standaardschema's op die moeten worden gebruikt voor verificatie, uitdaging en verbieden van acties.
  • Combineer meerdere schema's in één met behulp van beleidsschema's.

Verificatiehandler

Een verificatiehandler:

  • Is een type waarmee het gedrag van een schema wordt geïmplementeerd.
  • Is afgeleid van of .
  • Heeft de primaire verantwoordelijkheid om gebruikers te verifiëren.

Op basis van de configuratie van het verificatieschema en de context van de binnenkomende aanvraag, zijn verificatiehandlers:

  • Maak objecten die de identiteit van de gebruiker vertegenwoordigen als de verificatie is geslaagd.
  • Retourneert 'geen resultaat' of 'fout' als verificatie mislukt.
  • Zorg voor methoden om uitdagingen aan te bieden en acties te verbieden wanneer gebruikers proberen toegang te krijgen tot bronnen.
    • Ze hebben geen toestemming om toegang te hebben.
    • Wanneer ze niet zijn geverifieerd (uitdaging).

versus

is de klasse voor verificatie waarvoor een externe verificatiestap is vereist. Wanneer de stap voor externe verificatie is voltooid, roept de handler terug naar de set door de handler. De handler voltooit de verificatiestap met behulp van de informatie die wordt doorgegeven aan het callback-pad. OAuth 2.0 en OIDC beide gebruiken dit patroon. JWT en cookies hebben dat niet nodig aangezien ze de bearer-header rechtstreeks kunnen gebruiken en om te authenticeren. De extern gehoste provider in dit geval:

  • Is de verificatieprovider.
  • Voorbeelden hiervan zijn Facebook, Twitter, Google, Microsoft en een andere OIDC-provider die verificatie van gebruikers afhandelt met behulp van het handlersmechanisme.

Authenticate

De verificatieactie van een verificatieschema is verantwoordelijk voor het samenstellen van de identiteit van de gebruiker op basis van de aanvraagcontext. Het retourneert een vermelding die aangeeft of de verificatie is geslaagd en, als dat het zo is, de identiteit van de gebruiker in een verificatieticket. Zie . Voorbeelden van authenticatie zijn:

  • Een verificatieschema waarmee de identiteit van de gebruiker wordt samengesteld uit cookies.
  • Een JWT bearer-schema dat een JWT bearer-token deserialiseert en valideert om de identiteit van de gebruiker op te bouwen.

Uitdaging

Een verificatievraag wordt aangeroepen door autorisatie wanneer een niet-geverifieerde gebruiker een eindpunt aanvraagt waarvoor verificatie is vereist. Er wordt bijvoorbeeld een verificatievraag uitgevoerd wanneer een anonieme gebruiker een beperkte resource aanvraagt of een aanmeldingskoppeling volgt. Autorisatie roept een uitdaging aan met behulp van de opgegeven verificatieschema's of de standaardinstelling als er geen is opgegeven. Zie . Voorbeelden van verificatievragen zijn:

  • Een verificatieschema waarmee de gebruiker wordt omgeleid naar een aanmeldingspagina.
  • Een JWT bearer-schema retourneert een 401-resultaat met een header.

Een uitdagingsactie moet de gebruiker laten weten welk verificatiemechanisme moet worden gebruikt om de aangevraagde resource te access.

Verbieden

De verbodsactie van een authenticatieschema wordt door Autorisatie aangeroepen wanneer een geverifieerde gebruiker probeert toegang te krijgen tot een bron waartoe hij geen toegang heeft. Zie . Verboden voorbeelden van authenticatie zijn:

  • Een cookie verificatieschema waarmee de gebruiker wordt omgeleid naar een pagina die aangeeft dat access verboden was.
  • Een JWT bearer-schema retourneert een 403-resultaat.
  • Een aangepast verificatieschema dat wordt omgeleid naar een pagina waar de gebruiker access aan de resource kan aanvragen.

Een verbodshandeling kan de gebruiker informeren.

  • Ze worden geverifieerd.
  • Ze hebben geen toestemming om de aangevraagde bron te benaderen.

Zie de volgende koppelingen voor verschillen tussen uitdaging en verbieden:

  • Uitdagen en blokkeren met een operationele resource-handler.
  • Verschillen tussen uitdaging en verbieden.

Verificatieproviders per tenant

ASP.NET Core framework heeft geen ingebouwde oplossing voor verificatie met meerdere tenants. Hoewel het mogelijk is dat klanten een app schrijven met verificatie met meerdere tenants, raden we u aan een van de volgende ASP.NET Core toepassingsframeworks te gebruiken die ondersteuning bieden voor verificatie met meerdere tenants.

Orworks Core is een opensource-, modulair en multitenant app-framework dat is gebouwd met ASP.NET Core dat ook een CMS (Content Management System) biedt. Zie de bron Orsight Core voor een voorbeeld van verificatieproviders per tenant.

ABP Framework ondersteunt verschillende architectuurpatronen, waaronder modulariteit, microservices, domeingestuurd ontwerp en multitenancy. Zie ABP Framework-bron op GitHub.

Aanvullende bronnen

  • Last updated on