Lezen in het Engels

Delen via

Externe verificatie

  • Artikel

Met de externe verificatiefunctie van System.Web-adapters kan een ASP.NET Core-app de identiteit van een gebruiker bepalen (een HTTP-aanvraag verifiëren) door uit te stellen op een ASP.NET-app. Als u de functie inschakelt, wordt een eindpunt toegevoegd aan de ASP.NET-app die een geserialiseerde ClaimsPrincipal retourneert die de geverifieerde gebruiker vertegenwoordigt voor alle aanvragen die zijn ingediend bij het eindpunt. De ASP.NET Core-app registreert vervolgens een aangepaste verificatiehandler die (voor eindpunten waarvoor externe verificatie is ingeschakeld) de identiteit van een gebruiker bepaalt door dat eindpunt aan te roepen in de ASP.NET-app en geselecteerde headers en cookies door te geven van de oorspronkelijke aanvraag die is ontvangen door de ASP.NET Core-app.

Configuratie

Er zijn slechts enkele kleine codewijzigingen nodig om externe verificatie in te schakelen in een oplossing die al is ingesteld volgens de Aan de slag.

Volg eerst de externe app-installatie instructies om de ASP.NET Core- en ASP.NET-apps te verbinden. Vervolgens zijn er slechts een paar extra extensiemethoden die je kunt aanroepen om de externe app-authenticatie in te schakelen.

ASP.NET-appconfiguratie

De ASP.NET-app moet worden geconfigureerd om het verificatie-eindpunt toe te voegen. Het toevoegen van het verificatie-eindpunt wordt uitgevoerd door de AddAuthenticationServer-extensiemethode aan te roepen om de HTTP-module in te stellen die controleert op aanvragen naar het verificatie-eindpunt. Houd er rekening mee dat scenario's voor externe verificatie doorgaans ook proxyondersteuning willen toevoegen, zodat de omleidingen die met verificatie te maken hebben correct naar de ASP.NET Core-app in plaats van de ASP.NET-app worden gerouteerd.

C# 
SystemWebAdapterConfiguration.AddSystemWebAdapters(this)
    .AddProxySupport(options => options.UseForwardedHeaders = true)
    .AddRemoteAppServer(options =>
    {
        options.ApiKey = ConfigurationManager.AppSettings["RemoteAppApiKey"];
    })
    .AddAuthenticationServer();

configuratie van ASP.NET Core-app

Vervolgens moet de ASP.NET Core-app worden geconfigureerd om de verificatiehandler in te schakelen waarmee gebruikers worden geverifieerd door een HTTP-aanvraag naar de ASP.NET-app te verzenden. Nogmaals, dit wordt gedaan door AddAuthenticationClient aan te roepen bij het registreren van System.Web adapters services:

C# 
builder.Services.AddSystemWebAdapters()
    .AddRemoteAppClient(options =>
    {
        options.RemoteAppUrl = new Uri(builder.Configuration
            ["ReverseProxy:Clusters:fallbackCluster:Destinations:fallbackApp:Address"]);
        options.ApiKey = builder.Configuration["RemoteAppApiKey"];
    })
    .AddAuthenticationClient(true);

De Booleaanse waarde die wordt doorgegeven aan de AddAuthenticationClient-aanroep geeft aan of externe app-verificatie het standaardverificatieschema moet zijn. Als true wordt doorgegeven, wordt de gebruiker geverifieerd via externe app-verificatie voor alle aanvragen, terwijl het doorgeven van false betekent dat de gebruiker alleen wordt geverifieerd met externe app-verificatie als het externe app-schema specifiek wordt aangevraagd (bijvoorbeeld met [Authorize(AuthenticationSchemes = RemoteAppAuthenticationDefaults.AuthenticationScheme)] op een controller of actiemethode). Het doorgeven van false voor deze parameter heeft het voordeel dat alleen HTTP-aanvragen worden verzonden naar de oorspronkelijke ASP.NET-app voor verificatie voor eindpunten waarvoor externe app-verificatie is vereist, maar het nadeel heeft dat er aantekeningen moeten worden toegevoegd aan al deze eindpunten om aan te geven dat ze externe app-verificatie gebruiken.

Naast de vereiste booleaanse waarde kan een optionele callback worden doorgegeven aan AddAuthenticationClient om enkele andere aspecten van het gedrag van het externe verificatieproces te wijzigen:

  • RequestHeadersToForward: deze eigenschap bevat headers die moeten worden doorgestuurd vanuit een aanvraag bij het aanroepen van de verificatie-API. De enige headers die worden doorgestuurd, worden standaard Authorization en Cookie. Extra headers kunnen worden doorgestuurd door ze toe te voegen aan deze lijst. Als de lijst is gewist (zodat er geen kopteksten zijn opgegeven), worden alle headers ook doorgestuurd.
  • ResponseHeadersToForward: deze eigenschap bevat antwoordheaders die moeten worden doorgegeven vanuit de verificatieaanvraag naar de oorspronkelijke aanroep waarin verificatie is gevraagd in scenario's waarin identiteit wordt aangeroepen. Dit omvat standaard Location, Set-Cookieen WWW-Authenticate kopteksten.
  • AuthenticationEndpointPath: het eindpunt in de ASP.NET-app waar verificatieaanvragen moeten worden gedaan. Dit is standaard ingesteld op /systemweb-adapters/authenticate en moet overeenkomen met het eindpunt dat is opgegeven in de configuratie van het ASP.NET verificatie-eindpunt.

Als ten slotte de ASP.NET Core-app eerder geen middleware voor verificatie heeft opgenomen, moet deze worden ingeschakeld (na routering van middleware, maar vóór autorisatie-middleware):

C# 
app.UseAuthentication();

Ontwerpen

  1. Wanneer aanvragen worden verwerkt door de ASP.NET Core-app, als externe app-verificatie het standaardschema is of is opgegeven door het eindpunt van de aanvraag, probeert de RemoteAuthenticationAuthHandler de gebruiker te verifiëren.
    1. De handler doet een HTTP-aanvraag naar het verificatie-eindpunt van de ASP.NET-app. Er worden geconfigureerde headers van de huidige aanvraag naar deze nieuwe gekopieerd om verificatie-relevante gegevens door te sturen. Zoals hierboven vermeld, is het standaardgedrag het kopiëren van de Authorize en Cookie headers. De HEADER van de API-sleutel wordt ook toegevoegd voor beveiligingsdoeleinden.
  2. De ASP.NET-app verwerkt aanvragen die naar het verificatie-eindpunt worden verzonden. Zolang de API-sleutels overeenkomen, retourneert de ASP.NET-applicatie in het responslichaam de geserialiseerde ClaimsPrincipal van de huidige gebruiker, of retourneert deze een HTTP-statuscode (zoals 401 of 302) en antwoordheaders die een fout aangeven.
  3. Wanneer de RemoteAuthenticationAuthHandler van de ASP.NET Core-app het antwoord van de ASP.NET-app ontvangt:
    1. Als er met succes een ClaimsPrincipal is geretourneerd, wordt deze door de authenticatiehandler gedeserialiseerd en gebruikt als de identiteit van de huidige gebruiker.
    2. Als een ClaimsPrincipal niet is geretourneerd, slaat de handler het resultaat op en als verificatie wordt gevraagd (omdat de gebruiker bijvoorbeeld toegang heeft tot een beveiligde resource), wordt het antwoord van de aanvraag bijgewerkt met de statuscode en geselecteerde antwoordheaders uit het antwoord van het verificatie-eindpunt. Hierdoor kunnen vraagreacties (zoals omleidingen naar een aanmeldingspagina) worden doorgegeven aan eindgebruikers.
      1. Omdat resultaten van het authenticatie-eindpunt van de ASP.NET-app gegevens kunnen bevatten die specifiek zijn voor dat eindpunt, kunnen gebruikers IRemoteAuthenticationResultProcessor-implementaties registreren bij de ASP.NET Core-app, die worden uitgevoerd op alle authenticatieresultaten voordat ze worden gebruikt. Als voorbeeld is de ingebouwde IRemoteAuthenticationResultProcessorRedirectUrlProcessor die zoekt naar Location antwoordheaders die worden geretourneerd vanaf het verificatie-eindpunt en ervoor zorgt dat ze terugkeren naar de host van de ASP.NET Core-app en niet rechtstreeks naar de ASP.NET-app.

Bekende beperkingen

Deze benadering voor externe verificatie kent enkele bekende beperkingen:

  1. Omdat Windows-verificatie afhankelijk is van een ingang voor een Windows-identiteit, wordt Windows-verificatie niet ondersteund door deze functie. Toekomstig werk is gepland om te verkennen hoe gedeelde Windows-verificatie werkt. Zie dotnet/systemweb-adapters#246 voor meer informatie.
  2. Met deze functie kan de ASP.NET Core-app gebruikmaken van een identiteit die wordt geverifieerd door de ASP.NET-app, maar alle acties met betrekking tot gebruikers (aanmelden, afmelden, enzovoort) moeten nog steeds worden gerouteerd via de ASP.NET-app.

Alternatieven

Als authenticatie in de ASP.NET-app wordt uitgevoerd met Microsoft.OwinCookie Authentication Middleware, dan is een alternatief voor het delen van identiteit het zodanig configureren van de ASP.NET- en ASP.NET Core-apps dat ze dezelfde authenticatiemogelijkheden kunnen delen cookie. Door het delen van een verificatie cookie maakt u het volgende mogelijk:

  • Beide apps om de gebruikersidentiteit vanuit dezelfde cookiete bepalen.
  • Als u zich aanmeldt of afmeldt bij een app, wordt u automatisch ook aangemeld of afgemeld bij de andere app.

Houd er rekening mee dat omdat aanmelden doorgaans afhankelijk is van een specifieke database, niet alle verificatiefunctionaliteit in beide apps werkt:

  • Gebruikers moeten zich aanmelden via slechts één van de apps, ofwel de ASP.NET of ASP.NET Core-app, afhankelijk van de instellingen waarmee de database werkt.
  • Beide apps kunnen de identiteit en claims van de gebruikers zien.
  • Beide apps kunnen de gebruiker afmelden.

Details over hoe verificatiecookies te configureren voor het delen tussen ASP.NET en ASP.NET Core-apps zijn beschikbaar in de documentatie voor het delen cookie. De volgende voorbeelden in de System.Web-adapters GitHub-opslagplaats demonstreren authenticatie van externe apps met gedeelde cookie-configuratie, zodat beide apps gebruikers kunnen aanmelden en afmelden.

Delen van authenticatie is een goede optie als beide van de volgende waar zijn:

  • De ASP.NET-app maakt al gebruik van Microsoft.Owincookie verificatie.
  • Het is mogelijk om de ASP.NET-app en ASP.NET Core-apps bij te werken om overeenkomende instellingen voor gegevensbeveiliging te gebruiken. Overeenkomende instellingen voor gedeelde gegevensbeveiliging omvatten een gedeeld bestandspad, Redis-cache of Azure Blob Storage voor het opslaan van gegevensbeveiligingssleutels.

Voor andere scenario's is de benadering voor externe verificatie die eerder in dit document is beschreven flexibeler en is waarschijnlijk beter geschikt.