Overzicht van ASP.NET Core-verificatie

Door Mike Rousos

Verificatie is het proces van het bepalen van de identiteit van een gebruiker. Autorisatie is het proces om te bepalen of een gebruiker toegang heeft tot een resource. In ASP.NET Core wordt verificatie verwerkt door de verificatieservice, IAuthenticationServicedie wordt gebruikt door middleware voor verificatie. 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 toegang probeert te krijgen tot een beperkte resource.

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

Verificatieschema's worden opgegeven door verificatieservices te registreren in Program.cs:

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

Met de volgende code worden bijvoorbeeld verificatieservices en handlers geregistreerd voor cookie 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 AddAuthentication parameter JwtBearerDefaults.AuthenticationScheme 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 cookie verificatieschema worden gebruikt door de naam ervan op te geven (CookieAuthenticationDefaults.AuthenticationScheme) standaard, hoewel een andere naam kan worden opgegeven wanneer AddCookie wordt aangeroepen.

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

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

Verificatieconcepten

Verificatie is verantwoordelijk voor het verlenen van toestemming ClaimsPrincipal 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.
• HttpContext.User 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(Action<AuthenticationOptions> configureOptions).

DefaultScheme

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

• Wordt automatisch gebruikt als de DefaultScheme.
• Elimineert de noodzaak om DefaultScheme in AddAuthentication(IServiceCollection) of AddAuthenticationCore(IServiceCollection) op te nemen.

Als u automatisch wilt uitschakelen met behulp van het enkele verificatieschema als de DefaultSchemeaanroep AppContext.SetSwitch("Microsoft.AspNetCore.Authentication.SuppressAutoDefaultScheme").

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 IAuthenticationHandler of AuthenticationHandler<TOptions>.
• 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 AuthenticationTicket 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 uit te dagen en te verbieden wanneer gebruikers toegang proberen te krijgen tot resources:
  • Ze zijn niet gemachtigd om toegang te krijgen (verbieden).
  • Wanneer ze niet zijn geverifieerd (uitdaging).

RemoteAuthenticationHandler<TOptions> vs. AuthenticationHandler<TOptions>

RemoteAuthenticationHandler<TOptions> 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 CallbackPath set door de handler. De handler voltooit de verificatiestap met behulp van de informatie die wordt doorgegeven aan het HandleRemoteAuthenticateAsync callback-pad. OAuth 2.0 en OIDC gebruiken beide dit patroon. JWT en cookies hebben dat niet nodig aangezien ze de bearer-header rechtstreeks kunnen gebruiken en cookie 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 AuthenticateResult vermelding die aangeeft of de verificatie is geslaagd en, als dat het zo is, de identiteit van de gebruiker in een verificatieticket. Zie AuthenticateAsync. Voorbeelden van authenticatie zijn:

• Een cookie 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 ChallengeAsync. Voorbeelden van verificatievragen zijn:

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

Een uitdagingsactie moet de gebruiker laten weten welk verificatiemechanisme moet worden gebruikt voor toegang tot de aangevraagde resource.

Verbieden

De verboden actie van een verificatieschema wordt aangeroepen door Autorisatie wanneer een geverifieerde gebruiker probeert toegang te krijgen tot een resource die ze niet mogen openen. Zie ForbidAsync. Verboden voorbeelden van authenticatie zijn:

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

Een verbodshandeling kan de gebruiker informeren.

• Ze worden geverifieerd.
• Ze mogen geen toegang krijgen tot de aangevraagde resource.

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 Boomgaard Core, ABP Framework of Finbuckle.MultiTenant te gebruiken 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 Boomgaard Core-bron voor een voorbeeld van verificatieproviders per tenant.

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

Finbuckle.MultiTenant:

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

Aanvullende bronnen

• Autoriseren met een specifiek schema in ASP.NET Core
• Beleidsschema's in ASP.NET Core
• Een ASP.NET Core-app maken met gebruikersgegevens die worden beveiligd door autorisatie
• Globaal geverifieerde gebruikers vereisen
• GitHub-probleem met het gebruik van meerdere verificatieschema's