Ověřování pomocí Azure AD a OpenID Připojení

Vzorek kódu

Aplikace Surveys používá protokol OpenID Připojení (OIDC) k ověřování uživatelů pomocí Azure Active Directory (Azure AD). Aplikace Surveys používá ASP.NET Core, který má integrovaný middleware pro OIDC. Následující diagram znázorňuje, co se stane, když se uživatel přihlásí na vysoké úrovni.

1. Uživatel v aplikaci klikne na tlačítko Přihlásit se. Tuto akci zpracovává kontroler MVC.
2. Kontroler MVC vrátí akci ChallengeResult.
3. Middleware zachytí hodnotu ChallengeResult a vytvoří odpověď 302, která uživatele přesměruje na přihlašovací stránku Služby Azure AD.
4. Uživatel se ověřuje ve službě Azure AD.
5. Azure AD odešle aplikaci token ID.
6. Middleware ověří token ID. V tomto okamžiku je teď uživatel ověřený v aplikaci.
7. Middleware přesměruje uživatele zpět do aplikace.

Registrace aplikace v Azure AD

Pokud chcete povolit Připojení OpenID, zprostředkovatel SaaS zaregistruje aplikaci ve svém vlastním tenantovi Azure AD.

Pokud chcete aplikaci zaregistrovat, postupujte podle kroků v části Rychlý start: Registrace aplikacev Microsoft identity platform .

Pokud chcete tuto funkci povolit v ukázkové aplikaci Surveys, přečtěte si GitHub readme. Poznačte si následující údaje:

• Pro vícetenantové aplikace je nutné nakonfigurovat možnost s více tenanty explicitně. To ostatním organizacím umožňuje přístup k aplikaci.

• Adresa URL odpovědi je adresa URL, kam Bude Azure AD odesílat odpovědi OAuth 2.0. Při použití ASP.NET Core musí odpovídat cestě, kterou nakonfigurujete v ověřovacím middlewaru (viz další část).

Konfigurace ověřovacího middlewaru

Tato část popisuje, jak nakonfigurovat ověřovací middleware v ASP.NET Core pro vícetenantové ověřování pomocí OpenID Připojení.

Do třídy startup přidejteopenid Připojení middleware:

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();

Všimněte si, že některá nastavení jsou k dispozici v souboru secrets.json. Soubor musí mít oddíl s názvem AzureAd s následujícím nastavením:

• Instance. U vícetenantové aplikace nastavte tuto hodnotu na https://login.microsoftonline.com . Toto je adresa URL pro běžný koncový bod Azure AD, která umožňuje přihlášení uživatelům z libovolného tenanta Azure AD.
• ClientId. ID klienta aplikace, které jste získali při registraci aplikace v Azure AD.
• TenantId. Identifikátor GUID pro přihlašování uživatelů ve vaší organizaci.

Ostatní možnosti middlewaru znamenají následující:

• SignInScheme. Nastavte tuto hodnotu na CookieAuthenticationDefaults.AuthenticationScheme . Toto nastavení znamená, že po ověření uživatele se deklarace identity uživatele ukládají místně do souboru cookie. Tento soubor cookie je způsob, jakým uživatel zůstane přihlášený během relace prohlížeče.
• Události. Zpětná volání událostí; viz Události ověřování.

Zahájení toku ověřování

Pokud chcete spustit tok ověřování ASP.NET MVC, vraťte z kontroleru hodnotu ChallengeResult:

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

To způsobí, že middleware vrátí odpověď 302 (Nalezeno), která se přesměruje na ověřovací koncový bod.

Relace přihlášení uživatele

Jak už bylo zmíněno, middleware ověřování souborů cookie při prvním přihlášení uživatele zapíše deklarace identity uživatele do souboru cookie. Potom se požadavky HTTP ověřují přečtením souboru cookie.

Middleware cookie ve výchozím nastavení zapíše soubor cookierelace , který se odstraní, jakmile uživatel zavře prohlížeč. Až příště uživatel web navštíví, bude se muset znovu přihlásit. Pokud ale nastavíte IsPersistent na hodnotu true v sadě ChallengeResult, middleware zapíše trvalý soubor cookie, takže uživatel zůstane přihlášený i po zavření prohlížeče. Můžete nakonfigurovat vypršení platnosti souborů cookie. viz Řízení možností souborů cookie. Trvalé soubory cookie jsou pro uživatele pohodlnější, ale potenciálně nemusí být vhodné pro některé aplikace (například bankovní aplikace), ve kterých chcete, aby se uživatel pokaždé přihlašovat.

Informace o Připojení OpenID

OpenID Připojení middleware v ASP.NET skrývá většinu podrobností protokolu. Tato část obsahuje několik poznámek k implementaci, které mohou být užitečné pro pochopení toku protokolu.

Nejprve se podívejme na tok ověřování z hlediska ASP.NET (ignorování podrobností o toku protokolu OIDC mezi aplikací a Azure AD). Následující diagram znázorňuje proces.

V tomto diagramu jsou dva kontrolery MVC. Kontroler účtů zpracovává žádosti o přihlášení a domovskou stránku obsluhuuje kontroler domovské stránky.

Tady je proces ověřování:

1. Uživatel klikne na tlačítko Přihlásit se a prohlížeč odešle požadavek GET. Příklad: GET /Account/SignIn/.
2. Kontroler účtu vrátí ChallengeResult .
3. Middleware OIDC vrátí odpověď HTTP 302 a přesměruje ji do Azure AD.
4. Prohlížeč odešle žádost o ověření do Azure AD.
5. Uživatel se přihlásí k Azure AD a Azure AD odešle zpět odpověď na ověření.
6. Middleware OIDC vytvoří objekt zabezpečení deklarací identity a předá ho middlewaru ověřování souborů cookie.
7. Middleware cookie serializuje objekt zabezpečení deklarací identity a nastaví soubor cookie.
8. Middleware OIDC se přesměruje na adresu URL zpětného volání aplikace.
9. Prohlížeč následuje přesměrování a v požadavku pošle soubor cookie.
10. Middleware cookie deserializuje soubor cookie do objektu zabezpečení deklarací identity a nastaví se na objekt HttpContext.User zabezpečení deklarací identity. Požadavek se směruje na kontroler MVC.

Ověřovací lístek

Pokud je ověření úspěšné, middleware OIDC vytvoří ověřovací lístek, který obsahuje objekt zabezpečení deklarací identity, který obsahuje deklarace identity uživatele.

Události ověřování

Během procesu ověřování vyvolá openID Připojení middleware řadu událostí:

• RedirectToIdentityProvider. Volá se těsně před přesměrováním middlewaru na ověřovací koncový bod. Tuto událost můžete použít k úpravě adresy URL přesměrování. Například pro přidání parametrů požadavku. Příklad najdete v tématu Přidání výzvy k udělení souhlasu správce.
• AuthorizationCodeReceived. Volá se s autorizačním kódem.
• TokenResponseReceived. Volá se po tom, co middleware získá přístupový token z zdůvěřovací služby, ale před ověřením. Platí pouze pro tok autorizačního kódu.
• TokenValidated (TokenValidated). Volá se po ověření tokenu ID middlewarem. V tomto okamžiku má aplikace sadu ověřených deklarací identity o uživateli. Tuto událost můžete použít k dalšímu ověření deklarací identity nebo k transformaci deklarací identity. Viz Práce s deklaracemi identity.
• UserInformationReceived : Volá se, pokud middleware získá profil uživatele z koncového bodu informací o uživateli. Platí pouze pro autorizační tok kódu a pouze v GetClaimsFromUserInfoEndpoint = true případě, že jsou v možnostech middlewaru.
• TicketReceived. Volá se po dokončení ověřování. Toto je poslední událost za předpokladu, že ověření proběhne úspěšně. Po zpracování této události je uživatel přihlášený k aplikaci.
• AuthenticationFailed. Volá se, pokud se ověření nezdaří. Tuto událost použijte ke zpracování selhání ověřování, například — přesměrováním na chybovou stránku.

Pokud chcete pro tyto události poskytovat zpětná volání, nastavte v middlewaru možnost Události. Existují dva různé způsoby deklarace obslužných rutin událostí: vložené pomocí výrazů lambda nebo ve třídě, která je odvozena z OpenIdConnectEvents. Druhý přístup se doporučuje v případě, že zpětná volání událostí mají značnou logiku, takže nezasáhnou vaši třídu po spuštění. Naše referenční implementace používá tento přístup.

Koncové body Připojení OpenID

Azure AD podporuje OpenID Připojení Discovery,kde zprostředkovatel identity (IDP) vrátí dokument metadat JSON ze známého koncového bodu. Dokument metadat obsahuje například tyto informace:

• Adresa URL koncového bodu autorizace. Tady aplikace přesměruje uživatele na ověření.
• Adresa URL koncového bodu "koncová relace", kde aplikace přejde k odhlášení uživatele.
• Adresa URL pro získání podpisových klíčů, které klient používá k ověření tokenů OIDC, které získá od zdůpisce ip adres.

Middleware OIDC ve výchozím nastavení umí tato metadata načíst. Nastavte možnost Authority (Autorita) v middlewaru a middleware vytvoří adresu URL metadat. (Adresu URL metadat můžete přepsat nastavením možnosti MetadataAddress.)

OpenID – Připojení toky

Middleware OIDC ve výchozím nastavení používá hybridní tok s režimem formuláře po odpovědi.

• Hybridní tok znamená, že klient může získat token ID a autorizační kód ve stejné zpáteční cestě na autorizační server.
• Režim odeslání formuláře po odpovědi znamená, že autorizační server k odeslání tokenu ID a autorizačního kódu do aplikace používá požadavek HTTP POST. Hodnoty jsou form-urlencoded (content type = "application/x-www-form-urlencoded").

Když middleware OIDC přesměruje na koncový bod autorizace, adresa URL pro přesměrování zahrnuje všechny parametry řetězce dotazu, které OIDC potřebuje. Pro hybridní tok:

• client_id. Tato hodnota je nastavená v možnosti ClientId.
• scope = "openid profile", což znamená, že se jedná o požadavek OIDC a chceme profil uživatele.
• response_type = "code id_token". Určuje hybridní tok.
• response_mode = "form_post". Určuje formulář po odpovědi.

Pokud chcete zadat jiný tok, nastavte u možností vlastnost ResponseType.

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

    // Other options
}

Další