Sdílet prostřednictvím

Příručka pro vývojáře k kontextu ověřování podmíněného přístupu

Platí pro: Zelený kruh se symbolem bílé značky zaškrtnutí, který označuje následující obsah platí pro tenanty pracovních sil. Tenanti pracovních sil zelený kruh se symbolem bílé značky zaškrtnutí, který označuje následující obsah platí pro externí tenanty. Externí tenanti (další informace)

Podmíněný přístup je řídicí rovina nulová důvěra (Zero Trust), která umožňuje cílit zásady pro přístup ke všem vašim aplikacím – starým, novým, soukromým nebo veřejným, místním nebo multicloudovým. V kontextu ověřování podmíněného přístupu můžete v těchto aplikacích použít různé zásady.

Kontext ověřování podmíněného přístupu (kontext ověřování) umožňuje použít podrobné zásady na citlivá data a akce místo jenom na úrovni aplikace. Zásady nulová důvěra (Zero Trust) můžete upřesnit pro nejméně privilegovaný přístup a zároveň minimalizovat uživatelské třecí plochy a zajistit vyšší produktivitu uživatelů a zabezpečení vašich prostředků. Dnes ji používají aplikace používající OpenId Connect k ověřování vyvinuté vaší společností k ochraně citlivých prostředků, jako jsou transakce s vysokou hodnotou nebo zobrazení osobních údajů zaměstnanců.

Pokud chcete aktivovat podrobné ověřování z vašich aplikací a služeb, použijte funkci kontextu ověřování modulu podmíněného přístupu Microsoft Entra. Vývojáři teď mají sílu požadovat silnější ověřování, selektivně, jako je MFA od koncových uživatelů v rámci svých aplikací. Tato funkce pomáhá vývojářům vytvářet plynulejší uživatelské prostředí pro většinu částí aplikace, zatímco přístup k bezpečnějším operacím a datům zůstává za silnějšími ovládacími prvky ověřování.

Popis problému

Správci IT a regulační orgány se často snaží vyvážit výzvy uživatelů s dalšími faktory ověřování a dosažení odpovídajícího zabezpečení a dodržování zásad pro aplikace. Může to být volba mezi silnou zásadou, která ovlivňuje produktivitu uživatelů nebo zásadu, která není dostatečně silná pro citlivé prostředky.

Co když tedy aplikace dokázaly kombinovat obojí? Funguje s nižší úrovní zabezpečení a méně výzev pro většinu scénářů. Pak podmíněně zvýšíte požadavky na zabezpečení, když je přistupováno k citlivějším datům?

Obvyklé scénáře

Když se například uživatelé můžou přihlásit k SharePointu pomocí vícefaktorového ověřování, přístup ke kolekci webů v SharePointu obsahující citlivé dokumenty může vyžadovat vyhovující zařízení a být přístupné jenom z důvěryhodných rozsahů IP adres.

Požadavky

Nejprve by vaše aplikace měla být integrovaná s platformou Microsoft Identity Platform pomocí protokolů OpenID Connect/ OAuth 2.0 pro ověřování a autorizaci. K integraci a zabezpečení aplikace pomocí Microsoft Entra ID doporučujeme použít knihovny ověřování Microsoft Identity Platform. Dokumentace k platformě Microsoft Identity Platform je dobrým místem, kde se můžete naučit integrovat aplikace s platformou Microsoft Identity Platform. Podpora funkce Auth Context podmíněného přístupu je založená na rozšířeních protokolu poskytovaných standardním standardním protokolem OpenID Connect . Vývojáři používají referenčníhodnotu kontextu podmíněného přístupu s parametrem Žádosti o deklarace identity, aby aplikace získaly způsob aktivace a splnění zásad.

Za druhé podmíněný přístup vyžaduje licencování Microsoft Entra ID P1. Další informace o licencování najdete na stránce s cenami Microsoft Entra.

Za třetí, dnes je k dispozici pouze pro aplikace, které přihlašují uživatele. Aplikace, které se ověřují jako samy, se nepodporují. Pomocí průvodce toky ověřování a scénáři aplikací se dozvíte o podporovaných typech a tocích ověřovacích aplikací na platformě Microsoft Identity Platform.

Kroky integrace

Jakmile tuto funkci integrujete do svých aplikací, můžete ji začít integrovat pomocí podporovaných ověřovacích protokolů a zaregistrovat ji v tenantovi Microsoft Entra, který má k dispozici funkci podmíněného přístupu.

Poznámka:

Podrobný názorný postup této funkce je také k dispozici jako zaznamenaná relace v kontextu ověřování podmíněného přístupu v aplikaci pro účely podrobného ověřování.

Nejprve deklarujte a zpřístupněte kontexty ověřování ve vašem tenantovi. Další informace najdete v tématu Konfigurace kontextů ověřování.

Hodnoty C1-C99 jsou k dispozici jako ID kontextu ověřování v tenantovi. Příklady kontextu ověřování můžou být:

  • C1 – Vyžadování silného ověřování
  • C2 – Vyžadování kompatibilních zařízení
  • C3 – Vyžadování důvěryhodných umístění

Pokud chcete použít kontexty ověřování podmíněného přístupu, vytvořte nebo upravte zásady podmíněného přístupu. Příklady zásad můžou být:

  • Všichni uživatelé, kteří se přihlašují k této webové aplikaci, musí úspěšně dokončit 2FA pro id kontextu ověřování C1.
  • Všichni uživatelé, kteří se k této webové aplikaci přihlašují, musí úspěšně dokončit 2FA a také přistupovat k aplikaci z definovaného rozsahu IP adres pro ID kontextu ověřování C3.

Poznámka:

Kontextové hodnoty ověřování podmíněného přístupu se deklarují a spravují odděleně od aplikací. Nedoporučuje se, aby aplikace byly pevně závislé na ID kontextu ověřování. Správci IT obvykle vytvoří zásady podmíněného přístupu, protože lépe chápou dostupné prostředky. Podobně platí, že pokud se aplikace používá ve více tenantech, můžou se id kontextu ověřování lišit a v některých případech vůbec není k dispozici.

Druhé: Vývojáři aplikace, kteří plánují používat kontext ověřování podmíněného přístupu, se doporučuje nejprve poskytnout správcům aplikací nebo správcům IT prostředek k mapování potenciálních citlivých akcí na ID kontextu ověřování. Tento postup je zhruba následující:

  1. Akce identity v kódu, které je možné zpřístupnit pro mapování na id kontextu ověřování.
  2. Vytvořte obrazovku na portálu pro správu aplikace (nebo ekvivalentní funkce), kterou můžou správci IT použít k mapování citlivých akcí na dostupné ID kontextu ověřování.
  3. Podívejte se na ukázku kódu: Použijte kontext podmíněného přístupu pro zvýšenou úroveň ověřování jako příklad.

Tyto kroky jsou změny, které potřebujete přenést do základu kódu. Kroky, které se široce skládají z

  • Dotazem MS Graph zobrazíte seznam všech dostupných kontextů ověřování.
  • Umožňuje správcům IT vybrat citlivé nebo vysoce privilegované operace a přiřadit je k dostupným kontextům ověřování pomocí zásad podmíněného přístupu.
  • Uložte tyto informace mapování do databáze nebo místního úložiště.

Nastavení toku pro vytvoření kontextu ověřování

Třetí: Vaše aplikace a v tomto příkladu bychom předpokládali, že se jedná o webové rozhraní API, pak musí vyhodnotit volání proti uloženému mapování a odpovídajícím způsobem vyvolat výzvy k deklaraci identity pro své klientské aplikace. Při přípravě na tuto akci je třeba provést následující kroky:

  1. V citlivé a chráněné operací kontextu ověřování vyhodnoťte hodnoty v deklarací identity acrs na mapování ID kontextu ověřování uložené dříve a vytvořte výzvu deklarací identity, jak je uvedeno v následujícím fragmentu kódu.

  2. Následující diagram znázorňuje interakci mezi uživatelem, klientskou aplikací a webovým rozhraním API.

    Diagram znázorňující interakci uživatele, webové aplikace, rozhraní API a ID Microsoft Entra

    Následující fragment kódu pochází z ukázky kódu. K provedení podrobného ověřování použijte kontext ověřování podmíněného přístupu. První metoda CheckForRequiredAuthContext() v rozhraní API

    • Zkontroluje, jestli akce aplikace, která se volá, vyžaduje podrobné ověřování. Provede to tak, že v databázi vyhledá uložené mapování pro tuto metodu.
    • Pokud tato akce skutečně vyžaduje kontext ověřování se zvýšenými oprávněními, zkontroluje deklaraci identity acrs u existujícího odpovídajícího ID kontextu ověřování.
    • Pokud se nenajde odpovídající ID kontextu ověřování, vyvolá výzvu deklarace identity.
    public void CheckForRequiredAuthContext(string method)
{
    string authType = _commonDBContext.AuthContext.FirstOrDefault(x => x.Operation == method
                && x.TenantId == _configuration["AzureAD:TenantId"])?.AuthContextId;

    if (!string.IsNullOrEmpty(authType))
    {
        HttpContext context = this.HttpContext;
        string authenticationContextClassReferencesClaim = "acrs";

        if (context == null || context.User == null || context.User.Claims == null
            || !context.User.Claims.Any())
        {
            throw new ArgumentNullException("No Usercontext is available to pick claims from");
        }

        Claim acrsClaim = context.User.FindAll(authenticationContextClassReferencesClaim).FirstOrDefault(x
            => x.Value == authType);

        if (acrsClaim == null || acrsClaim.Value != authType)
        {
            if (IsClientCapableofClaimsChallenge(context))
            {
                string clientId = _configuration.GetSection("AzureAd").GetSection("ClientId").Value;
                var base64str = Convert.ToBase64String(Encoding.UTF8.GetBytes("{\"access_token\":{\"acrs\":{\"essential\":true,\"value\":\"" + authType + "\"}}}"));

                context.Response.Headers.Append("WWW-Authenticate", $"Bearer realm=\"\", authorization_uri=\"https://login.microsoftonline.com/common/oauth2/authorize\", client_id=\"" + clientId + "\", error=\"insufficient_claims\", claims=\"" + base64str + "\", cc_type=\"authcontext\"");
                context.Response.StatusCode = (int)HttpStatusCode.Unauthorized;
                string message = string.Format(CultureInfo.InvariantCulture, "The presented access tokens had insufficient claims. Please request for claims requested in the WWW-Authentication header and try again.");
                context.Response.WriteAsync(message);
                context.Response.CompleteAsync();
                throw new UnauthorizedAccessException(message);
            }
            else
            {
                throw new UnauthorizedAccessException("The caller does not meet the authentication  bar to carry our this operation. The service cannot allow this operation");
            }
        }
    }
}

    Poznámka:

    Formát výzvy deklarací identity je popsaný v článku Výzva deklarací identity na platformě Microsoft Identity Platform.

  3. V klientské aplikaci zachycujte výzvu deklarací identity a přesměrujte uživatele zpět na ID Microsoft Entra pro další vyhodnocení zásad. Následující fragment kódu pochází z ukázky kódu. K provedení podrobného ověřování použijte kontext ověřování podmíněného přístupu.

    internal static string ExtractHeaderValues(WebApiMsalUiRequiredException response)
{
    if (response.StatusCode == System.Net.HttpStatusCode.Unauthorized && response.Headers.WwwAuthenticate.Any())
    {
        AuthenticationHeaderValue bearer = response.Headers.WwwAuthenticate.First(v => v.Scheme == "Bearer");
        IEnumerable<string> parameters = bearer.Parameter.Split(',').Select(v => v.Trim()).ToList();
        var errorValue = GetParameterValue(parameters, "error");

        try
        {
            // read the header and checks if it contains error with insufficient_claims value.
            if (null != errorValue && "insufficient_claims" == errorValue)
            {
                var claimChallengeParameter = GetParameterValue(parameters, "claims");
                if (null != claimChallengeParameter)
                {
                    var claimChallenge = ConvertBase64String(claimChallengeParameter);

                    return claimChallenge;
                }
            }
        }
        catch (Exception ex)
        {
            throw ex;
        }
    }
    return null;
}

    Při volání webového rozhraní API zachytí výjimku, pokud se zobrazí výzva deklarace identity, přesměruje uživatele zpět na ID Microsoft Entra pro další zpracování.

    try
{
    // Call the API
    await _todoListService.AddAsync(todo);
}
catch (WebApiMsalUiRequiredException hex)
{
    // Challenges the user if exception is thrown from Web API.
    try
    {
        var claimChallenge =ExtractHeaderValues(hex);
        _consentHandler.ChallengeUser(new string[] { "user.read" }, claimChallenge);

        return new EmptyResult();
    }
    catch (Exception ex)
    {
        _consentHandler.HandleException(ex);
    }

    Console.WriteLine(hex.Message);
}
return RedirectToAction("Index");

  4. (Volitelné) Deklarujte možnosti klienta. Možnosti klientů pomáhají poskytovatelům prostředků (RP), jako je naše webové rozhraní API, zjistit, jestli klientská aplikace rozumí výzvě deklarací identity, a pak může odpovídajícím způsobem přizpůsobit svou odpověď. Tato funkce může být užitečná, pokud ne všichni klienti rozhraní API dokážou řešit problémy s deklaracemi identity a některé starší klienty stále očekávají jinou reakci. Další informace najdete v části Možnosti klienta.

Upozornění a doporučení

Nezakódujte hodnoty kontextu ověřování ve vaší aplikaci. Aplikace by měly číst a používat kontext ověřování pomocí volání MS Graphu. Tento postup je pro aplikace s více tenanty zásadní. Hodnoty kontextu ověřování se liší mezi tenanty Microsoft Entra a nejsou k dispozici v edici Microsoft Entra ID Free. Další informace o tom, jak by aplikace měla dotazovat, nastavit a používat kontext ověřování v kódu, najdete v příkladu kódu Využití kontextu ověřování pro podmíněný přístup k provedení podrobného ověřování.

Nepoužívejte kontext ověřování, kde samotná aplikace bude cílem zásad podmíněného přístupu. Funkce funguje nejlépe, když části aplikace vyžadují, aby uživatel splňoval vyšší pruh ověřování.

Ukázky kódu

Kontext ověřování [ACL] v očekávaném chování podmíněného přístupu

Explicitní spokojenost kontextu ověřování v požadavcích

Klient může explicitně požádat o token s kontextem ověřování (ACRS) prostřednictvím deklarací identity v těle požadavku. Pokud byl požadován ACRS, podmíněný přístup umožňuje vystavit token s požadovaným ACRS, pokud jsou všechny výzvy splněny.

Očekávané chování v případech, kdy kontext ověřování není chráněný podmíněným přístupem v tenantovi

Podmíněný přístup může vystavit ACRS v deklaracích tokenu, když jsou splněny všechny zásady podmíněného přístupu přiřazené k hodnotě ACRS. Pokud není k hodnotě služby ACRS přiřazena žádná zásada podmíněného přístupu, nárok může být stále vydán, protože jsou splněny všechny požadavky zásad.

Souhrnná tabulka očekávaného chování při explicitní žádosti ACRS

Požadováno ACRS Použité zásady Řízení bylo splněno. Přidání služby ACRS do deklarací identity
Ano Ne Ano Ano
Ano Ano Ne Ne
Ano Ano Ano Ano
Ano Žádné zásady nakonfigurované pomocí služby ACRS Ano Ano

Implicitní spokojenost kontextu ověřování podle oportunistického vyhodnocení

Poskytovatel prostředků se může přihlásit k volitelné deklaraci identity acrs. Podmíněný přístup se pokusí přidat ACRS do deklarací identity tokenu oportunisticky, aby se zabránilo zaokrouhlení na získání nových tokenů do Microsoft Entra ID. V tomto vyhodnocení podmíněný přístup zkontroluje, jestli už jsou splněné zásady ochrany kontextu ověřování, a pokud ano, přidá služba ACRS do deklarací identity tokenu.

Poznámka:

Každý typ tokenu musí být individuálně přihlášený (token ID, přístupový token).

Pokud se poskytovatel prostředků nepřihlásí k volitelné deklaraci identity acrs, jediným způsobem, jak v tokenu získat službu ACRS, je explicitně ji požádat v žádosti o token. Nezíská výhody náhodného vyhodnocování, a proto pokaždé, když v nárocích tokenu chybí požadované ACRS, poskytovatel prostředků vyzve klienta k získání nového tokenu, který je obsahuje v nárocích.

Očekávané chování s kontextem ověřování a ovládacími prvky relace pro implicitní oportunistické vyhodnocení ACRS

Frekvence přihlášení podle intervalu

Podmíněný přístup považuje za splněnou "frekvenci přihlašování podle intervalu" pro oportunistické vyhodnocení služby ACRS, pokud jsou všechny aktuální ověřovací faktory v intervalu frekvence přihlašování. V případě, že je některý z ověřovacích faktorů zastaralý, frekvence přihlašování podle stanovených intervalů nebude splněna a ACRS nebude do tokenu vydán oportunisticky.

Cloud App Security (CAS)

Podmíněný přístup považuje řízení CAS relace za splněné pro oportunistické vyhodnocení ACRS, pokud byla relace CAS vytvořena během tohoto požadavku. Například když přijde požadavek a jakákoliv zásada podmíněného přístupu se použije a vynutí relaci CAS. Pokud navíc existuje další zásada podmíněného přístupu vyžadující relaci CAS, vynucením relace CAS je splněna kontrola relace CAS pro hodnocení podle pravidel šance.

Očekávané chování v případech, kdy tenant obsahuje zásady podmíněného přístupu, které chrání kontext ověřování

Následující tabulka ukazuje všechny rohové případy, kdy se ACRS přidá do nároků tokenu oportunistickým vyhodnocením.

Zásada A: Vyžadovat vícefaktorové ověřování od všech uživatelů, s výjimkou uživatele "Ariel", při žádosti o "c1" acrs. Zásada B: Zablokujte všechny uživatele s výjimkou uživatele Jay, když žádáte o c2 nebo c3.

Flow Požadováno ACRS Použité zásady Řízení bylo splněno. Přidání služby ACRS do deklarací identity
Žádosti Ariel o přístupový token c1 Nic Ano pro "c1". Ne pro "c2" a "c3" "c1" (požadováno)
Žádosti Ariel o přístupový token c2 Zásady B Blokováno zásadami B Nic
Žádosti Ariel o přístupový token Nic Nic Ano pro "c1". Ne pro "c2" a "c3" "c1" (oportunisticky přidáno ze zásad A)
Jay žádá o přístupový token (bez vícefaktorového ověřování) c1 Zásada A Ne Nic
Jay žádá o přístupový token (s vícefaktorovým ověřováním) c1 Zásada A Ano "c1" (požadováno), "c2" (oportunisticky přidáno ze zásad B), "c3" (oportunisticky přidáno ze zásad B)
Jay žádá o přístupový token (bez vícefaktorového ověřování) c2 Nic Ano pro "c2" a "c3". Ne pro "c1" "c2" (požadováno), "c3" (oportunisticky přidáno ze zásad B)
Jay žádá o přístupový token (s vícefaktorovým ověřováním) c2 Nic Ano pro "c1", "c2" a "c3" "c1" (nejlepší úsilí od A), "c2" (požadováno), "c3" (oportunisticky přidáno ze zásad B)
Jay žádá o přístupový token (s vícefaktorovým ověřováním) Nic Nic Ano pro "c1", "c2" a "c3" "c1", "c2", "c3" všechny oportunisticky přidané
Jay žádá o přístupový token (bez vícefaktorového ověřování) Nic Nic Ano pro "c2" a "c3". Ne pro "c1" "c2", "c3" všechny oportunisticky přidané

Další kroky

  • Last updated on