Share via

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

  • Článek

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 Připojení 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 potýkají s vyrovnáváním výzvy uživatelů s příliš častými faktory ověřování a dosažení odpovídajícího zabezpečení a dodržování zásad pro aplikace a služby, kde jejich části obsahují citlivá data a operace. Může to být volba mezi silnou zásadou, která ovlivňuje produktivitu uživatelů, když přistupují k většině dat a akcím nebo zásadám, které nejsou dostatečně silné pro citlivé prostředky.

Co když tedy aplikace dokázaly kombinovat obojí, kde můžou fungovat s relativně menším zabezpečením a méně častými výzvami pro většinu uživatelů a operací, a přesto podmíněně zkombinovat požadavky na zabezpečení, když uživatelé přistupovali k citlivějším částem?

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 Připojení/ 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 Připojení. 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 je vaše aplikace integrovaná pomocí podporovaných ověřovacích protokolů a zaregistrovaná v tenantovi Microsoft Entra, který má k dispozici funkci podmíněného přístupu, můžete zahájit proces integrace této funkce do aplikací, které přihlašují uživatele.

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í

Vytvořte nebo upravte zásady podmíněného přístupu tak, aby používaly kontexty ověřování 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, by měli úspěšně dokončit 2FA pro id kontextu ověřování C1.
  • Všichni uživatelé přihlášení k této webové aplikaci by měli úspěšně dokončit 2FA a také přistupovat k webové aplikaci z určité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í. Zásady podmíněného přístupu obvykle vytváří správci IT, protože mají lepší přehled o prostředcích, na kterých jsou k dispozici zásady. Například pro tenanta Microsoft Entra by správci IT měli znalosti o tom, kolik uživatelů tenanta je vybaveno 2FA pro vícefaktorové ověřování, a proto může zajistit, aby zásady podmíněného přístupu, které vyžadují 2FA, byly vymezeny na tyto vybavené uživatele. 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 a použijte kontext ověřování podmíněného přístupu k provedení podrobného ověřování , například jak se to dělá.

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. Funkce klientů pomáhají poskytovatelům prostředků (RP), jako je naše webové rozhraní API výše, zjistit, jestli volající 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 nebudou 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í ve svém kódu, najdete v ukázce kódu pomocí kontextu ověřování podmíněného přístupu k provedení podrobného ověřování , jak by aplikace měla dotazovat, nastavit a používat kontext ověřování v kódu.

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 se požaduje služba ACRS, podmíněný přístup umožní vydat token s požadovanou službou ACRS, pokud byly dokončeny všechny výzvy.

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í identity tokenu, když byly 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, může být deklarace stále vydána, protože všechny požadavky zásad byly splněny.

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
Yes Ne Ano Ano
Ano Ano No No
Ano Ano Ano Ano
Yes Žádné zásady nakonfigurované pomocí služby ACRS Ano Yes

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ě opted-in (token ID, přístupový token).

Pokud poskytovatel prostředků nemá výslovný souhlas s volitelnou deklarací identity acrs, jediným způsobem, jak v tokenu získat službu ACRS, bude ji explicitně požádat v žádosti o token. Nezíská výhody oportunistického vyhodnocení, proto pokaždé, když v deklarací identity tokenu chybí požadovaná služba ACRS, poskytovatel prostředků vyzve klienta k získání nového tokenu, který ho obsahuje v deklarací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 první okamžik ověření faktoru je zastaralý nebo pokud je k dispozici druhý faktor (MFA) a jeho okamžitá doba ověřování je zastaralá, frekvence přihlášení podle intervalu nebude splněna a ACRS se v tokenu nevydá oportunisticky.

Cloud App Security (CAS)

Podmíněný přístup bude považovat řízení relace CAS za splněné pro oportunistické vyhodnocení služby ACRS při vytvoření relace CAS během tohoto požadavku. Když například přijde požadavek a všechny zásady podmíněného přístupu se použijí a vynucují relaci CAS, a navíc existují zásady podmíněného přístupu, které také vyžadují relaci CAS, protože se vynutí relace CAS, která bude vyhovovat řízení relace CAS pro oportunistické vyhodnocení.

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 zobrazí všechny rohové případy, kdy se služba ACRS přidá do deklarací identity 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.

Tok 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 No 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