Fejlesztői útmutató a feltételes hozzáférés hitelesítési kontextusához

A következőkre vonatkozik: Zöld kör fehér pipa jellel a munkaerő bérlőkre vonatkozó tartalom jelölésére. A munkaerő bérlők zöld kör fehér pipa jellel a külső bérlőkre vonatkozó tartalom jelölésére. Külső bérlők (további információ)

Feltételes hozzáférés a Teljes felügyelet felügyeleti rétege, amellyel szabályzatokat alkalmazhat az összes alkalmazásához való hozzáféréshez – régiekhez és újakhoz, privátakhoz és nyilvánosakhoz, helyszíniekhez és többfelhősekhez. A Feltételes hozzáférés hitelesítési környezetével ezeken az alkalmazásokon belül különböző szabályzatokat alkalmazhat.

A feltételes hozzáférés hitelesítési környezete (hitelesítési környezet) lehetővé teszi részletes szabályzatok alkalmazását a bizalmas adatokra és műveletekre, nem csak az alkalmazás szintjén. Finomíthatja a Teljes felügyelet-szabályzatait a minimális jogosultságú hozzáférés érdekében, miközben minimalizálja a felhasználók terheit, növeli a felhasználók hatékonyságát, és biztonságosabbá teszi az erőforrásait. Ma már az Ön vállalata által fejlesztett, a hitelesítéshez OpenId Connect használó alkalmazások használják bizalmas erőforrások, például nagy értékű tranzakciók vagy az alkalmazottak személyes adatainak megtekintésének védelmére.

Ha az alkalmazásokon és szolgáltatásokon belülről szeretne aktiválni egy további hitelesítést, használja a Microsoft Entra feltételes hozzáférési motor hitelesítési kontextus funkcióját. A fejlesztők mostantól szelektíven, közvetlenül az alkalmazásaikon belül is lehetőségük van erősebb hitelesítést, például MFA-t megkövetelni a végfelhasználóiktól. Ez a funkció segíti a fejlesztőket abban, hogy zökkenőmentesebb felhasználói élményt alakíthassanak ki az alkalmazásuk legtöbb részén, miközben a biztonságosabb műveletekhez és adatokhoz való hozzáférés erősebb hitelesítési vezérlők mögött marad.

Probléma megfogalmazása

Az informatikai rendszergazdák és a szabályozók gyakran küzdenek azzal, hogy egyensúlyt teremtsenek a felhasználók további hitelesítési tényezőkkel való ösztönzése és az alkalmazások megfelelő biztonságának és szabályzatoknak való megfelelésének elérése között. Választás lehet olyan erős szabályzatok között, amelyek hatással vannak a felhasználók termelékenységére, vagy olyan szabályzatok, amelyek nem elég erősek a bizalmas erőforrásokhoz.

Mi a teendő, ha az alkalmazások képesek lennének mindkettőt összekeverni? Alacsonyabb szintű biztonsággal és kevesebb kéréssel működik a legtöbb forgatókönyv esetében. Ezután feltételesen fokozza a biztonsági követelményeket a bizalmasabb adatok elérésekor?

Gyakori helyzetek

Ha például a felhasználók többtényezős hitelesítéssel jelentkeznek be a SharePointba, a bizalmas dokumentumokat tartalmazó SharePoint-webhelycsoport elérése megfelelő eszközt igényelhet, és csak megbízható IP-tartományokból érhető el.

Előfeltételek

Először az alkalmazást integrálni kell a Microsoft identitásplatformmal az OpenID Connectés a OAuth 2.0 protokollok használatával a hitelesítéshez és az engedélyezéshez. Javasoljuk, hogy Microsoft Identitásplatform hitelesítési kódtárakkal integrálja és biztonságossá tegye az alkalmazást a Microsoft Entra ID-vel. A Microsoft Identitásplatform dokumentációja jó kiindulópont ahhoz, hogy megtanulja, hogyan integrálhatja az alkalmazásait a Microsoft Identitásplatformmal. A feltételes hozzáférési hitelesítési kontextus funkció támogatása az iparági szabvány OpenID Connect protokoll által biztosított protokollbővítményekre épül. A fejlesztők a feltételes hozzáférési hitelesítési környezeti referenciához tartozóértéket használják a Claims Request paraméterrel, hogy lehetővé tegyék az alkalmazások számára a szabályzatok aktiválását és teljesítését.

Másodszor, a feltételes hozzáféréshez Microsoft Entra ID P1 licenc szükséges. A licenceléssel kapcsolatos további információk a Microsoft Entra díjszabási oldalán találhatók.

Harmadik, ma csak azoknak az alkalmazásoknak érhető el, amelyek bejelentkeztetik a felhasználókat. Azok az alkalmazások, amelyek saját magukként hitelesítik magukat, nem támogatott. A Hitelesítési folyamatok és alkalmazás-forgatókönyvek útmutatója segítségével megismerheti a Microsoft identitásplatform támogatott hitelesítési alkalmazástípusait és folyamatait.

Integrációs lépések

Ezt a funkciót integrálhatja az alkalmazásokba, miután a támogatott hitelesítési protokollokkal integrálva lett, és regisztrálva lett egy Olyan Microsoft Entra-bérlőben, amely rendelkezik elérhető feltételes hozzáférési funkcióval.

Feljegyzés

A funkció részletes útmutatója felvételként is elérhető a következő rögzített előadásban: Use Conditional Access Auth Context in your app for step-up authentication.

Először deklarálja és tegye elérhetővé a hitelesítési környezeteket a bérlőben. További információ: Hitelesítési környezetek konfigurálása.

A C1-C99 értékek hitelesítési környezetazonosítókként használhatók egy bérlőben. A hitelesítési környezet például a következő lehet:

  • C1 – Erős hitelesítés megkövetelése
  • C2 – Előírásoknak megfelelő eszközök megkövetelése
  • C3 – Megbízható helyek megkövetelése

A feltételes hozzáférési hitelesítési környezetek használatához hozza létre vagy módosítsa a feltételes hozzáférési szabályzatokat. Példák a szabályokra:

  • A webalkalmazásba bejelentkező összes felhasználónak sikeresen el kell végeznie a 2FA-t a C1 hitelesítési környezeti azonosítóhoz.
  • A webalkalmazásba bejelentkező összes felhasználónak sikeresen el kell végeznie a 2FA-t, és egy meghatározott IP-címtartományból kell hozzáférnie az alkalmazáshoz a C3 hitelesítési környezeti azonosítóhoz.

Feljegyzés

A feltételes hozzáférés hitelesítési környezeti értékeit a rendszer az alkalmazásoktól elkülönítve deklarálja és tartja karban. Nem ajánlott, hogy az alkalmazások fix függőséget alakítsanak ki a hitelesítési környezet azonosítóira. A rendszergazdák általában feltételes hozzáférési szabályzatokat alkotnak, mivel jobban ismerik a rendelkezésre álló erőforrásokat. Hasonlóképpen, ha az alkalmazást több bérlőben is használják, a használatban lévő auth context ID-k eltérőek lehetnek, és bizonyos esetekben egyáltalán nem érhetők el.

Másodszor: A Feltételes hozzáférés hitelesítési környezetének használatát tervező alkalmazások fejlesztőinek javasoljuk, hogy először biztosítsanak az alkalmazásgazdáknak vagy az informatikai rendszergazdáknak egy olyan eszközt, amely a lehetséges bizalmas műveleteket a hitelesítési környezet azonosítóihoz rendeli. A lépések nagyjából a következőek:

  1. A kód azon identitásműveletei, amelyek elérhetővé tehetők az auth context ID-khoz való hozzárendeléshez.
  2. Hozzon létre egy képernyőt az alkalmazás felügyeleti portálján (vagy egy ezzel egyenértékű funkciót), amellyel az IT-rendszergazdák bizalmas műveleteket képezhetnek le egy elérhető auth context ID-hoz.
  3. Tekintse meg a kódmintát, amely a feltételes hozzáférési hitelesítési környezet használatával végez felfelé irányuló hitelesítést egy példához.

Ezek a lépések azok a módosítások, amelyeket a kódbázisában kell elvégeznie. A lépések nagyjából a következőkből állnak

  • Az MS Graph lekérdezése az összes elérhető hitelesítési kontextus listázásához.
  • Lehetővé teszi a rendszergazdák számára, hogy bizalmas vagy magas jogosultságú műveleteket válasszanak ki, és feltételes hozzáférési szabályzatok használatával rendeljék hozzá őket a rendelkezésre álló Auth Contexts elemekhez.
  • Mentse ezeket a leképezési adatokat az adatbázisban/helyi tárolóban.

Hitelesítési kontextus létrehozásához szükséges beállítási folyamat

Harmadszor: Az alkalmazásnak, és ebben a példában feltételezzük, hogy ez egy webes API, ezután ki kell értékelnie a hívásokat a mentett leképezés alapján, és ennek megfelelően claims-kihívásokat kell kezdeményeznie az ügyfélalkalmazásai számára. A művelet előkészítéséhez a következő lépéseket kell végrehajtani:

  1. Bizalmas és hitelesítési környezet által védett műveletben értékelje ki az acrs-jogcím értékeit a korábban mentett hitelesítési környezetazonosító-leképezésekkel szemben, és az alábbi kódrészletben megadottak szerint adjon vissza egy Claims Challenge kérelmet.

  2. Az alábbi ábra a felhasználó, az ügyfélalkalmazás és a webes API közötti interakciót mutatja be.

    A felhasználó, a webalkalmazás, az API és a Microsoft Entra ID interakcióját bemutató ábra

    Az alábbi kódrészlet a kódmintából származik, A feltételes hozzáférés hitelesítési környezetének használata a lépcsőzetes hitelesítés végrehajtásához. Az első módszer, CheckForRequiredAuthContext(), az API-ban

    • Ellenőrzi, hogy az alkalmazásban meghívott művelethez szükség van-e lépcsőzetes hitelesítésre. Ezt úgy teszi, hogy ellenőrzi az adatbázisában, hogy van-e az ehhez a metódushoz mentett leképezés
    • Ha ez a művelet valóban emelt szintű hitelesítési környezetet igényel, ellenőrzi az acrs jogcímet egy meglévő, egyező hitelesítési környezeti azonosítóhoz.
    • Ha nem található egyező hitelesítési környezeti azonosító, az claims-kihívást vált ki.
    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");
            }
        }
    }
}

    Feljegyzés

    A jogcímkihívás formátumát a Jogcímkihívás a Microsoft identitásplatformon című cikk ismerteti.

  3. Az ügyfélalkalmazásban elfogja a claims challenge-et, és átirányítja a felhasználót a Microsoft Entra ID-hoz további szabályzatértékelés céljából. Az alábbi kódrészlet a következő kódmintából származik: A feltételes hozzáférés hitelesítési környezetének használata a fokozott hitelesítés végrehajtásához.

    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;
}

    Kezelje a Web API-hívás során fellépő kivételt, és ha claims challenge jelenik meg, irányítsa vissza a felhasználót a Microsoft Entra ID-hoz további feldolgozás céljából.

    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. (Nem kötelező) A kliens képességének deklarálása. Az ügyfélképességek segítségével a webes API-hoz hasonló erőforrás-szolgáltatók (RP) észlelhetik, hogy az ügyfélalkalmazás megérti-e a jogcímekkel kapcsolatos kihívást, majd ennek megfelelően testre szabhatja a választ. Ez a képesség akkor lehet hasznos, ha nem minden API-ügyfél képes kezelni a jogcímkéréseket, és néhány régebbi még mindig eltérő választ vár. További információkért tekintse meg a Ügyfél képességei című szakaszt.

Figyelmeztetések és javaslatok

Ne kódozza be az auth context értékeket az alkalmazásban. Az alkalmazásoknak MS Graph-hívások használatával kell olvasniuk és alkalmazniuk kell a hitelesítési környezetet. Ez a gyakorlat kritikus fontosságú a több-bérlős alkalmazások esetében. A hitelesítési környezet értékei a különböző Microsoft Entra-bérlők között eltérőek, és nem érhetők el a Microsoft Entra ID Free változatban. Ha többet szeretne tudni arról, hogy az alkalmazásnak hogyan kell lekérdeznie, beállítania és használnia a hitelesítést a kódjában, tekintse meg a kódmintát, amely a feltételes hozzáférés hitelesítési környezetének használata a lépésenkénti hitelesítés végrehajtásához.

Ne használjon auth contextust, ahol maga az alkalmazás lesz a feltételes hozzáférési szabályzatok célja. A funkció akkor működik a legjobban, ha az alkalmazás egyes részei megkövetelik, hogy a felhasználó magasabb szintű hitelesítésnek feleljen meg.

Kódminták

Hitelesítési kontextus [ACRs] a feltételes hozzáférés várt viselkedésében

Explicit hitelesítési környezet teljesülése a kérésekben

Az ügyfél a kérelem törzsében található claimeken keresztül explicit módon kérhet tokent hitelesítési környezettel (ACRS). Ha ACRS-t kértek, a feltételes hozzáférés lehetővé teszi a kért ACRS-sel a token kiállítását, ha az összes kihívás befejeződött.

Elvárt viselkedés, ha egy hitelesítési környezetet nem véd a feltételes hozzáférés a bérlőben

A Conditional Access kibocsáthat egy ACRS-t egy token állításaiban, ha az ACRS-értékhez rendelt összes feltételes hozzáférési házirend teljesül. Ha nincs feltételes hozzáférési szabályzat hozzárendelve egy ACRS-értékhez, a jogcím továbbra is kibocsátható, mert minden szabályzatkövetelmények teljesülnek.

Az ACRS explicit kérése esetén várható viselkedés összefoglaló táblázata

ACRS kérése folyamatban Házirend alkalmazva Ellenőrzés sikeres ACRS hozzáadva az igényekhez
Igen Nem Igen Igen
Igen Igen Nem Nem
Igen Igen Igen Igen
Igen Nincsenek konfigurálva szabályzatok az ACRS-hez Igen Igen

Implicit engedélyezési kontextus kielégítése opportunista értékeléssel

Az erőforrás-szolgáltató dönthet úgy, hogy használja az opcionális „acrs” claimet. A feltételes hozzáférés opportunista módon próbálja hozzáadni az ACRS-t a jogkivonat jogcímeihez, hogy elkerülje új jogkivonatok Microsoft Entra ID-hoz történő beszerzését. Ebben az értékelésben a feltételes hozzáférés ellenőrzi, hogy az Auth Context-kihívásokat védő szabályzatok már teljesülnek-e, és ha igen, hozzáadja az ACRS-t a token jogcímeihez.

Feljegyzés

Minden jogkivonattípust külön kell megadni (azonosító jogkivonat, Hozzáférési jogkivonat).

Ha egy erőforrás-szolgáltató nem engedélyezi az opcionális "acrs" jogcímet, az ACRS-t csak úgy szerezheti be a jogkivonatban, ha explicit módon kéri azt egy jogkivonat-kérelemben. Nem fogja az opportunisztikus kiértékelés előnyeit kihasználni, ezért minden alkalommal, amikor a szükséges ACRS hiányzik a jogkivonat igényeiből, az erőforrás-szolgáltató felszólítja az ügyfelet, hogy szerezzen be egy új jogkivonatot, amely azt tartalmazza az igényekben.

Várt viselkedés hitelesítési környezettel és munkamenet-vezérlőkkel az implicit ACRS opportunista kiértékeléshez

Bejelentkezési gyakoriság intervallum szerint

A feltételes hozzáférés a „bejelentkezés gyakorisága intervallum szerint” feltételt teljesültnek tekinti az ACRS opportunista kiértékelése szempontjából, ha az összes jelen lévő hitelesítési tényező auth instantja a bejelentkezési gyakorisági intervallumon belül van. Ha bármelyik hitelesítési tényező elavult, a bejelentkezési gyakoriság intervallumonként nem lesz kielégítve, és az ACRS nem lesz a jogkivonatban opportunista módon kibocsátva.

Felhőappbiztonság (CAS)

A feltételes hozzáférés a CAS-munkamenet-vezérlést elégedettnek tekinti az ACRS-kiértékeléshez, amikor a kérés során CAS-munkamenetet hoztak létre. Ha például beérkezik egy kérés, és bármilyen feltételes hozzáférési szabályzat kerül alkalmazásra, amely CAS-munkamenet létrehozását igényli, valamint van egy másik feltételes hozzáférési szabályzat, amely szintén CAS-munkamenetet követel meg, akkor a CAS-munkamenet be lesz kényszerítve, amely megfelel az alkalmi értékelés CAS-munkamenet-vezérlésének.

Elvárt viselkedés, ha egy bérlőben a hitelesítési környezetet védő feltételes hozzáférési szabályzatok vannak

Az alábbi táblázat az összes olyan sarokesetet mutatja be, ahol az ACRS az opportunista kiértékelés során hozzáadódik a token igényeihez.

A szabályzat: Az MFA megkövetelése az összes felhasználótól, kivéve az "Ariel" felhasználót, a „c1” acrs kérésekor. Házirend B: Tiltsa le az összes felhasználót, kivéve a "Jay" felhasználót, amikor "c2" vagy "c3" acrs kérésére.

Flow ACRS kérve A házirend alkalmazva lett Ellenőrzés teljesült ACRS hozzáadva az igényekhez
Az Ariel hozzáférési tokent kér c1 Egyik sem Igen a(z) "c1" számára. Nem a(z) „c2” és a(z) „c3” esetén "c1" (kért)
Az Ariel hozzáférési tokent kér. c2 B irányelv A(z) B szabályzat blokkolja Egyik sem
Az Ariel hozzáférési tokent kér Nincs Egyik sem Igen a(z) "c1"-re. Nem a(z) „c2” és „c3” elemhez „c1” (opportunista módon hozzáadva az A szabályzathoz képest)
Jay hozzáférési tokent kér (MFA nélkül) c1 A szabály Nem Egyik sem
Jay hozzáférési tokent kér (MFA-val) c1 A szabályzat Igen "c1" (kért), "c2" (alkalomszerűen hozzáadva a B szabályzatból), "c3" (alkalomszerűen hozzáadva a B szabályzatból)
Jay hozzáférési tokent kér (MFA nélkül) c2 Egyik sem Igen a "c2" és a "c3" esetében. Nem ehhez: "c1" "c2" (kért), "c3" (opportunista módon hozzáadva a B szabályzatból)
Jay hozzáférési tokent kér (MFA-val) c2 Egyik sem Igen a következőhöz: "c1", "c2" és "c3" "c1" (A legjobb szándéka szerint), "c2" (kért), "c3" (a B szabályzatból esetileg hozzáadva)
Jay hozzáférési tokent kér (MFA-val) Egyik sem Nincs Igen a következőhöz: "c1", "c2" és "c3" "c1", "c2", "c3" mind opportunista módon lettek hozzáadva
Jay hozzáférési tokent kér (MFA nélkül) Nincs Egyik sem Igen a "c2" és a "c3" esetében. Nem a(z) "c1" értékre „c2”, „c3” mind opportunisztikusan lettek hozzáadva

Következő lépések

  • Utolsó frissítés időpontja: