Megosztás a következőn keresztül:

Fejlesztői útmutató a feltételes hozzáférés hitelesítési környezetéhez

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ó)

A feltételes hozzáférés a Teljes felügyelet vezérlősík, amellyel szabályzatokat célozhat meg az összes alkalmazáshoz való hozzáféréshez – régi vagy új, privát vagy nyilvános, helyszíni vagy többfelhős – hozzáféréshez. A feltételes hozzáférés hitelesítési környezetében különböző szabályzatokat alkalmazhat ezeken az alkalmazásokon belül.

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 Teljes felügyelet szabályzatait a minimális jogosultsági hozzáférés érdekében, miközben minimalizálja a felhasználói súrlódást, és hatékonyabbá teszi a felhasználókat és az erőforrásokat. Ma már az OpenId Connectet használó alkalmazások használják a vállalat által kifejlesztett hitelesítéshez a bizalmas erőforrások, például a nagy értékű tranzakciók vagy az alkalmazottak személyes adatainak megtekintése érdekében.

Ha az alkalmazásokon és szolgáltatásokon belülről szeretne aktiválni egy lépésenkénti hitelesítést, használja a Microsoft Entra feltételes hozzáférési motor hitelesítési környezet funkcióját. A fejlesztők mostantól nagyobb teljesítményű hitelesítést igényelnek, szelektíven, például az alkalmazásukból származó végfelhasználóktól származó MFA-t. 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 leírása

Az informatikai rendszergazdák és a szabályozók gyakran küzdenek azzal, hogy egyensúlyba hozsák a felhasználókat a hitelesítés további tényezőivel, és megfelelő biztonságot és szabályzatmegtartást érjenek el az alkalmazásokhoz. 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 forgatókönyvek

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 is integrálva kell lennie az alkalmazásnak a Microsoft Identitásplatform az OpenID Connecta hitelesítéshez és 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-azonosítóval. Microsoft Identitásplatform dokumentáció jó kiindulópont ahhoz, hogy megtanulja, hogyan integrálhatja az alkalmazásait a Microsoft Identitásplatform. A feltételes hozzáférési környezet funkció támogatása az iparági szabvány openID Connect protokoll által biztosított protokollbővítményekre épül. A fejlesztők egy feltételes hozzáférési hitelesítési környezeti referenciaértékethasználnak a Jogcímkérelem paraméterrel, hogy az alkalmazások módot adjanak a szabályzat aktiválására és teljesítésére.

Másodszor, a feltételes hozzáféréshez p1 Microsoft Entra-azonosítójú licencelés szükséges. A licenceléssel kapcsolatos további információk a Microsoft Entra díjszabási oldalán találhatók.

Harmadszor, ma csak a bejelentkező felhasználók számára érhető el. Azok az alkalmazások, amelyek önmagukban hitelesítik magukat, nem támogatottak. A hitelesítési folyamatok és az alkalmazásforgatókönyvek 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 rögzített munkamenetként is elérhető az alkalmazás feltételes hozzáférési hitelesítési környezetének használata a lépésenkénti hitelesítéshez.

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örnyezeti azonosítóké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 – 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éldaszabályzatok lehetnek:

  • 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 szigorúan függjenek a hitelesítési környezet azonosítóitól. 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ő hitelesítési környezeti azonosítók eltérőek lehetnek, és bizonyos esetekben egyáltalán nem érhetők el.

Másodszor: A feltételes hozzáférési hitelesítési környezet 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 a hitelesítési környezet azonosítóinak megfeleltetéséhez.
  2. Hozzon létre egy képernyőt az alkalmazás felügyeleti portálján (vagy egy ezzel egyenértékű funkcióval), amellyel a rendszergazdák bizalmas műveleteket képezhetnek le egy elérhető hitelesítési környezeti azonosító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ázisban kell végrehajtania. 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 környezet 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ó hitelesítési környezetekhez.
  • Mentse ezeket a leképezési adatokat az adatbázisba vagy a helyi tárolóba.

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

Harmadszor: Az alkalmazás, és ebben a példában feltételezzük, hogy ez egy webes API, majd ki kell értékelnie a mentett leképezéssel kapcsolatos hívásokat, és ennek megfelelően jogcímekkel kapcsolatos kihívásokat kell felvetnie 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 megadott jogcímekkel kapcsolatos kihívást jelent.

  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, amely a feltételes hozzáférés hitelesítési környezetének használatával hajtja végre a lépésenkénti hitelesítést. Az első módszer az CheckForRequiredAuthContext() API-ban

    • Ellenőrzi, hogy az alkalmazás hívásához szükség van-e további hitelesítésre. Ezt úgy teszi, hogy ellenőrzi az adatbázist, hogy van-e mentett leképezése ehhez a módszerhez
    • 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ó esetében.
    • Ha nem található egyező hitelesítési környezeti azonosító, az jogcímekkel kapcsolatos kihívást jelent.
    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ímekkel kapcsolatos kihívás formátumát a jogcímekkel kapcsolatos kihívás a Microsoft Identitásplatform című cikkben ismertetjük.

  3. Az ügyfélalkalmazásban elfogja a jogcímekkel kapcsolatos kihívást, és átirányítja a felhasználót a Microsoft Entra-azonosítóra további szabályzatértékelés céljából. Az alábbi kódrészlet a kódmintából származik, amely a feltételes hozzáférés hitelesítési környezetének használatával hajtja végre a lépésenkénti hitelesítést.

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

    A Webes API-hívás kivételének kezelése, ha jogcímekkel kapcsolatos kihívás jelenik meg, a felhasználó átirányítása a Microsoft Entra-azonosítóra 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ő) Ügyfélképesség 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ímekkel kapcsolatos kihívásokat, és néhány régebbi még mindig eltérő választ vár. További információkért tekintse meg az Ü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 hitelesítési környezetet, 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 hitelesítési sávnak feleljen meg.

Kódminták

Hitelesítési környezet [ACL-ek] a feltételes hozzáférés várt viselkedésében

Explicit hitelesítési környezet elégedettsége a kérésekben

Az ügyfél a kérelem törzsében található jogcímeken keresztül explicit módon kérhet jogkivonatot 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

Az ACRS kért Szabályzat alkalmazva A vezérlés elégedett ACRS hozzáadva a jogcímekhez
Igen Nem Igen Igen
Igen Igen Nem Nem
Igen Igen Igen Igen
Igen Nincs konfigurálva szabályzat az ACRS-sel Igen Igen

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

Az erőforrás-szolgáltató választhatja az opcionális "acrs" jogcímet. A feltételes hozzáférés opportunista módon próbálja hozzáadni az ACRS-t a jogkivonat-jogcímekhez, hogy elkerülje az új jogkivonatok Microsoft Entra-azonosítóba való beolvasását. Ebben az értékelésben a feltételes hozzáférés ellenőrzi, hogy a hitelesítési környezet kihívásait védő szabályzatok már teljesülnek-e, és ha igen, hozzáadja az ACRS-t a jogkivonat-jogcímekhez.

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 úgy véli, hogy a "bejelentkezés gyakorisága intervallum szerint" megfelel az ACRS opportunista kiértékelése szempontjából, ha az összes jelenlegi hitelesítési tényező hitelesítése 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ő feltételes hozzáférési szabályzatokat tartalmaz, amelyek védik a hitelesítési környezetet

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, amikor "c1" acrs-t kér. B házirend: Tiltsa le az összes felhasználót, kivéve a "Jay" felhasználót, amikor "c2" vagy "c3" acrs-t kér.

Flow Az ACRS kért Szabályzat alkalmazva A vezérlés elégedett ACRS hozzáadva a jogcímekhez
Hozzáférési jogkivonatra vonatkozó Ariel-kérések c1 Egyik sem Igen a "c1"-hez. Nem a "c2" és a "c3" "c1" (kért)
Hozzáférési jogkivonatra vonatkozó Ariel-kérések c2 B szabályzat A B szabályzat letiltja Egyik sem
Hozzáférési jogkivonatra vonatkozó Ariel-kérések Egyik sem Egyik sem Igen a "c1"-hez. Nem a "c2" és a "c3" "c1" (opportunista módon hozzáadva az A szabályzatból)
Jay hozzáférési jogkivonatot kér (MFA nélkül) c1 "A" szabályzat Nem Egyik sem
Jay hozzáférési jogkivonatot kér (MFA-val) c1 "A" szabályzat Igen "c1" (kért), "c2" (opportunista módon hozzáadva a B szabályzatból), "c3" (opportunista módon hozzáadva a B szabályzatból)
Jay hozzáférési jogkivonatot kér (MFA nélkül) c2 Egyik sem Igen a "c2" és a "c3" esetében. Nem a "c1" kifejezéshez "c2" (kért), "c3" (opportunista módon hozzáadva a B szabályzatból)
Jay hozzáférési jogkivonatot kér (MFA-val) c2 Egyik sem Igen a következőhöz: "c1", "c2" és "c3" "c1" (az A legjobb erőfeszítése), "c2" (kért), "c3" (a B szabályzatból opportunista módon hozzáadva)
Jay hozzáférési jogkivonatot kér (MFA-val) Egyik sem Egyik sem Igen a következőhöz: "c1", "c2" és "c3" "c1", "c2", "c3" mind opportunista módon hozzáadva
Jay hozzáférési jogkivonatot kér (MFA nélkül) Egyik sem Egyik sem Igen a "c2" és a "c3" esetében. Nem a "c1" kifejezéshez "c2", "c3" mind opportunista módon hozzáadva

Következő lépések

  • Last updated on