Verifiëren met behulp van Azure AD en OpenID Verbinding maken

Artikel
10/11/2021
7 minuten om te lezen

De toepassing Surveys maakt gebruik van het OIDC-protocol (OpenID Verbinding maken) om gebruikers te verifiëren met Azure Active Directory (Azure AD). De toepassing Surveys maakt gebruik ASP.NET Core, die ingebouwde middleware voor OIDC heeft. In het volgende diagram ziet u wat er gebeurt wanneer de gebruiker zich op hoog niveau meldt.

Verificatiestroom

De gebruiker klikt op de knop Aanmelden in de app. Deze actie wordt afgehandeld door een MVC-controller.
De MVC-controller retourneert een ChallengeResult-actie.
De middleware onderschept de ChallengeResult en maakt een 302-antwoord, waarmee de gebruiker wordt omgeleid naar de aanmeldingspagina van Azure AD.
De gebruiker wordt geverifieerd met Azure AD.
Azure AD verzendt een id-token naar de toepassing.
De middleware valideert het id-token. Op dit moment wordt de gebruiker nu geverifieerd in de toepassing.
De middleware leidt de gebruiker terug naar de toepassing.

De app registreren bij Azure AD

Als u OpenID-Verbinding maken, registreert de SaaS-provider de toepassing in zijn eigen Azure AD-tenant.

Als u de toepassing wilt registreren, volgt u de stappen in Quickstart: Een toepassing registreren met de Microsoft identity platform.

Als u deze functionaliteit wilt inschakelen in de voorbeeldtoepassing Surveys, zie GitHub readme. Houd rekening met het volgende:

Voor een multitenant-toepassing moet u de optie met meerderetenant expliciet configureren. Hierdoor hebben andere organisaties toegang tot de toepassing.
De antwoord-URL is de URL waar Azure AD OAuth 2.0-antwoorden verzendt. Wanneer u de ASP.NET Core, moet dit overeenkomen met het pad dat u configureert in de verificatie-middleware (zie de volgende sectie).

De auth middleware configureren

In deze sectie wordt beschreven hoe u de verificatie-middleware in ASP.NET Core voor multitenant-verificatie met OpenID-Verbinding maken.

Voeg in uw opstartklassede OpenID-Verbinding maken middleware toe:

services.AddAuthentication(OpenIdConnectDefaults.AuthenticationScheme)
  .AddMicrosoftIdentityWebApp(
    options =>
    {
        Configuration.Bind("AzureAd", options);
        options.Events = new SurveyAuthenticationEvents(loggerFactory);
        options.SignInScheme = CookieAuthenticationDefaults.AuthenticationScheme;
        options.Events.OnTokenValidated += options.Events.TokenValidated;
    })
    .EnableTokenAcquisitionToCallDownstreamApi()
    .AddDownstreamWebApi(configOptions.SurveyApi.Name, Configuration.GetSection("SurveyApi"))
    .AddDistributedTokenCaches();

U ziet dat sommige instellingen worden opgegeven in het bestand secrets.json. Het bestand moet een sectie met de naam AzureAd hebben met de volgende instellingen:

Instantie. Voor een multitenant-toepassing stelt u deze in op https://login.microsoftonline.com . Dit is de URL voor het algemene Azure AD-eindpunt, waarmee gebruikers van elke Azure AD-tenant zich kunnen aanmelden.
ClientId. De client-id van de toepassing, die u hebt toen u de toepassing in Azure AD registreerde.
TenantId. GUID voor het aanmelden van gebruikers in uw organisatie.

Dit is wat de andere middleware-opties betekenen:

SignInScheme. Stel deze in op CookieAuthenticationDefaults.AuthenticationScheme . Deze instelling betekent dat nadat de gebruiker is geverifieerd, de gebruikersclaims lokaal in een cookie worden opgeslagen. Met deze cookie blijft de gebruiker aangemeld tijdens de browsersessie.
Gebeurtenissen. Gebeurtenis callbacks; zie Verificatiegebeurtenissen.

De verificatiestroom initiëren

Als u de verificatiestroom wilt starten in ASP.NET MVC, moet u een ChallengeResult van de controller retourneren:

[AllowAnonymous]
public IActionResult SignIn()
{
    return new ChallengeResult(
        OpenIdConnectDefaults.AuthenticationScheme,
        new AuthenticationProperties
        {
            IsPersistent = true,
            RedirectUri = Url.Action("SignInCallback", "Account")
        });
}

Dit zorgt ervoor dat de middleware een 302(Found)-antwoord retourneert dat wordt omgeleid naar het verificatie-eindpunt.

Zoals vermeld, schrijft de cookieverificatie-middleware de gebruiker claims naar een cookie wanneer de gebruiker zich voor het eerst aanmeldt. Daarna worden HTTP-aanvragen geverifieerd door de cookie te lezen.

Standaard schrijft de cookie-middleware een sessiecookie, die wordt verwijderd zodra de gebruiker de browser sluit. De volgende keer dat de gebruiker de site opnieuw bezoekt, moet deze zich opnieuw aanmelden. Als u IsPersistent echter in de ChallengeResult in stelt op true, schrijft de middleware een permanente cookie, zodat de gebruiker aangemeld blijft nadat de browser is gesloten. U kunt de cookieverloopdatum configureren; Zie Cookieopties beheren. Permanente cookies zijn handiger voor de gebruiker, maar zijn mogelijk niet geschikt voor sommige toepassingen (bijvoorbeeld een banktoepassing) waarbij u wilt dat de gebruiker zich telkens moet aanmelden.

Over de OpenID Verbinding maken middleware

De OpenID Verbinding maken middleware in ASP.NET de meeste protocoldetails verborgen. Deze sectie bevat enkele opmerkingen over de implementatie, die nuttig kunnen zijn voor inzicht in de protocolstroom.

Laten we eerst de verificatiestroom bekijken in termen van ASP.NET (waarbij we de details van de OIDC-protocolstroom tussen de app en Azure AD negeren). In het volgende diagram wordt het proces weergegeven.

Aanmeldingsstroom

In dit diagram zijn er twee MVC-controllers. De accountcontroller verwerkt aanmeldingsaanvragen en de startpagina wordt door de startcontroller verwerkt.

Dit is het verificatieproces:

De gebruiker klikt op de knop 'Aanmelden' en de browser verzendt een GET-aanvraag. Bijvoorbeeld: GET /Account/SignIn/.
De accountcontroller retourneert een ChallengeResult .
De OIDC-middleware retourneert een HTTP 302-antwoord dat wordt omgeleid naar Azure AD.
De browser verzendt de verificatieaanvraag naar Azure AD
De gebruiker meldt zich aan bij Azure AD en Azure AD stuurt een verificatiereactie terug.
De OIDC-middleware maakt een claimprincipaal en geeft deze door aan de cookieverificatie-middleware.
De cookie-middleware serialiseert de claimprincipal en stelt een cookie in.
De OIDC-middleware wordt omgeleid naar de callback-URL van de toepassing.
De browser volgt de omleiding en stuurt de cookie in de aanvraag.
De cookie-middleware deserialiseert de cookie naar een claimprincipal en stelt HttpContext.User gelijk aan de claimprincipal in. De aanvraag wordt doorgeleid naar een MVC-controller.

Verificatieticket

Als de verificatie slaagt, maakt de OIDC-middleware een verificatieticket, dat een claim-principal bevat die de claims van de gebruiker bevat.

Notitie

Totdat de volledige verificatiestroom is voltooid, bevat HttpContext.User nog steeds een anonieme principal, niet de geverifieerde gebruiker. De anonieme principal heeft een lege claimverzameling. Nadat de verificatie is voltooid en de app omgeleid, deserialiseert de cookie-middleware de verificatiecookie en stelt deze in op een claimprincipal die de geverifieerde HttpContext.User gebruiker vertegenwoordigt.

Verificatiegebeurtenissen

Tijdens het verificatieproces wordt met de OpenID-Verbinding maken middleware een reeks gebeurtenissen geopend:

RedirectToIdentityProvider. Wordt aangeroepen voordat de middleware wordt omgeleid naar het verificatie-eindpunt. U kunt deze gebeurtenis gebruiken om de omleidings-URL te wijzigen; bijvoorbeeld om aanvraagparameters toe te voegen. Zie De toestemmingsprompt van de beheerder toevoegen voor een voorbeeld.
AuthorizationCodeReceived. Aangeroepen met de autorisatiecode.
TokenResponseReceived. Aangeroepen nadat de middleware een toegangs token van de IDP krijgt, maar voordat het wordt gevalideerd. Is alleen van toepassing op de autorisatiecodestroom.
TokenValidated. Aangeroepen nadat de middleware het id-token valideert. Op dit moment heeft de toepassing een set gevalideerde claims over de gebruiker. U kunt deze gebeurtenis gebruiken om extra validatie uit te voeren op de claims of om claims te transformeren. Zie Werken met claims.
UserInformationReceived. Wordt aangeroepen als de middleware het gebruikersprofiel van het eindpunt van de gebruikersgegevens op haalt. Is alleen van toepassing op de autorisatiecodestroom en alleen GetClaimsFromUserInfoEndpoint = true in de middleware-opties.
TicketReceived. Wordt aangeroepen wanneer de verificatie is voltooid. Dit is de laatste gebeurtenis, ervan uitgaande dat de verificatie slaagt. Nadat deze gebeurtenis is verwerkt, wordt de gebruiker aangemeld bij de app.
AuthenticationFailed. Aangeroepen als verificatie mislukt. Gebruik deze gebeurtenis om verificatiefouten af te handelen, bijvoorbeeld door — om te leiden naar een foutpagina.

Als u callbacks wilt bieden voor deze gebeurtenissen, stelt u de optie Gebeurtenissen in op de middleware. Er zijn twee verschillende manieren om de gebeurtenis-handlers te declareren: Inline met lambda's of in een klasse die is afgeleid van OpenIdConnectEvents. De tweede aanpak wordt aanbevolen als uw gebeurtenisaanroepbacks aanzienlijke logica hebben, zodat uw opstartklasse niet onoverzichtelijk wordt. Onze referentie-implementatie maakt gebruik van deze benadering.

OpenID Verbinding maken eindpunten

Azure AD ondersteunt OpenID Verbinding maken Discovery,waarbij de id-provider(IDP) een JSON-metagegevensdocument retourneert van een bekend eindpunt . Het document met metagegevens bevat informatie zoals:

De URL van het autorisatie-eindpunt. Hier wordt de app omgeleid om de gebruiker te verifiëren.
De URL van het eindpunt 'sessie beëindigen', waar de app de gebruiker afmeldt.
De URL voor het ophalen van de ondertekeningssleutels, die de client gebruikt om de OIDC-tokens te valideren die deze van de IDP ophalen.

Standaard weet de OIDC-middleware hoe deze metagegevens moeten worden opgehaald. Stel de optie Instantie in de middleware in en de middleware bouwt de URL voor de metagegevens. (U kunt de metagegevens-URL overschrijven door de optie MetadataAddress in te stellen.)

OpenID Verbinding maken stromen

De OIDC-middleware maakt standaard gebruik van een hybride stroom met de modus voor formulierreacties.

Hybride stroom betekent dat de client een id-token en een autorisatiecode kan verkrijgen in dezelfde retour naar de autorisatieserver.
Formulier post-antwoordmodus betekent dat de autorisatieserver een HTTP POST-aanvraag gebruikt om het id-token en de autorisatiecode naar de app te verzenden. De waarden zijn form-urlencoded (inhoudstype = "application/x-www-form-urlencoded").

Wanneer de OIDC-middleware wordt omgeleid naar het autorisatie-eindpunt, bevat de omleidings-URL alle queryreeksparameters die nodig zijn voor OIDC. Voor hybride stroom:

Client_id. Deze waarde wordt ingesteld in de optie ClientId.
scope = 'openid profile', wat betekent dat het een OIDC-aanvraag is en we het profiel van de gebruiker willen.
response_type = 'code id_token'. Hiermee geeft u een hybride stroom op.
response_mode = 'form_post'. Hiermee geeft u het antwoord formulier post.

Als u een andere stroom wilt opgeven, stelt u de eigenschap ResponseType in op de opties.

app.AddAuthentication().AddOpenIdConnect(options =>
{
    options.ResponseType = "code"; // Authorization code flow

    // Other options
}

Volgende