Fejlesztői útmutató a Microsoft Entra feltételes hozzáféréshez

  • Cikk

A Microsoft Entra ID feltételes hozzáférési funkciója számos olyan módszer egyikét kínálja, amelyekkel biztonságossá teheti az alkalmazást és védelmet nyújthat egy szolgáltatásnak. A feltételes hozzáféréssel a fejlesztők és a vállalati ügyfelek számos módon védhetik a szolgáltatásokat, többek között az alábbiakat:

  • Többtényezős hitelesítés
  • Csak az Intune-ban regisztrált eszközök hozzáférésének engedélyezése adott szolgáltatásokhoz
  • Felhasználói helyek és IP-tartományok korlátozása

A feltételes hozzáférés teljes képességeiről további információt a feltételes hozzáférésről szóló cikkben talál.

A Microsoft Entra ID-hoz készült alkalmazásokat fejlesztő fejlesztők számára ez a cikk bemutatja, hogyan használhatja a feltételes hozzáférést, és azt is megtudhatja, hogy milyen hatással lehet az olyan erőforrások elérésére, amelyek felett nem rendelkezik vezérléssel, és amelyek feltételes hozzáférési szabályzatokat alkalmazhatnak. A cikk azt is ismerteti, hogy milyen következményekkel jár a feltételes hozzáférés a folyamat nevében, a webalkalmazásokban, a Microsoft Graph elérésében és az API-k meghívásában.

Az egy- és több-bérlős alkalmazások és a gyakori hitelesítési minták ismerete feltételezve van.

Feljegyzés

A funkció használatához Microsoft Entra ID P1 licenc szükséges. A követelményeinek leginkább megfelelő licenc kiválasztásáról lásd az ingyenes, alapszintű és prémium kiadások általánosan elérhető szolgáltatásait összehasonlító cikket. A Microsoft 365 Vállalati verziós licenccel rendelkező ügyfelek is hozzáférhetnek a feltételes hozzáférési funkciókhoz.

Hogyan befolyásolja a feltételes hozzáférés az alkalmazásokat?

Érintett alkalmazástípusok

A legtöbb esetben a feltételes hozzáférés nem változtatja meg az alkalmazások viselkedését, és nem igényel módosításokat a fejlesztőtől. Csak bizonyos esetekben, amikor egy alkalmazás közvetetten vagy csendesen kér jogkivonatot egy szolgáltatáshoz, az alkalmazások kódmódosításokat igényelnek a feltételes hozzáféréssel kapcsolatos kihívások kezeléséhez. Ez lehet olyan egyszerű, mint egy interaktív bejelentkezési kérés végrehajtása.

Az alábbi forgatókönyvekhez kód szükséges a feltételes hozzáféréssel kapcsolatos kihívások kezeléséhez:

  • A folyamat nevében végrehajtó alkalmazások
  • Több szolgáltatást/erőforrást elérő alkalmazások
  • Egyoldalas alkalmazások MSAL.js
  • Erőforrást hívó Web Apps

A feltételes hozzáférési szabályzatok alkalmazhatók az alkalmazásra, de az alkalmazás által elért webes API-kra is alkalmazhatók. A feltételes hozzáférési szabályzatok konfigurálásáról további információt a Microsoft Entra Feltételes hozzáféréssel rendelkező alkalmazások MFA-jának megkövetelése című rövid útmutatóban talál.

A forgatókönyvtől függően a vállalati ügyfelek bármikor alkalmazhatják és eltávolíthatják a feltételes hozzáférési szabályzatokat. Ahhoz, hogy az alkalmazás továbbra is működjön egy új szabályzat alkalmazásakor, valósítsa meg a kihívások kezelését. Az alábbi példák a kihívások kezelését szemléltetik.

Példák feltételes hozzáférésre

Egyes forgatókönyvek kódmódosításokat igényelnek a feltételes hozzáférés kezeléséhez, míg mások ugyanúgy működnek. Íme néhány olyan forgatókönyv, amely a feltételes hozzáféréssel végez többtényezős hitelesítést, amely némi betekintést nyújt a különbségbe.

  • Egy egybérlős iOS-alkalmazást hoz létre, és feltételes hozzáférési szabályzatot alkalmaz. Az alkalmazás bejelentkezik egy felhasználóba, és nem kér hozzáférést egy API-hoz. Amikor a felhasználó bejelentkezik, a rendszer automatikusan meghívja a szabályzatot, és a felhasználónak többtényezős hitelesítést (MFA) kell végrehajtania.
  • Egy natív alkalmazást hoz létre, amely egy középső rétegbeli szolgáltatást használ egy alsóbb rétegbeli API eléréséhez. Az alkalmazást használó vállalati ügyfél szabályzatot alkalmaz az alsóbb rétegbeli API-ra. Amikor egy végfelhasználó bejelentkezik, a natív alkalmazás hozzáférést kér a középső réteghez, és elküldi a jogkivonatot. A középső réteg a folyamat nevében végzi el a hozzáférést az alsóbb rétegbeli API-hoz való hozzáférés igényléséhez. Ezen a ponton egy jogcím "kihívás" jelenik meg a középső rétegben. A középső szint visszaküldi a feladatot a natív alkalmazásnak, amelynek meg kell felelnie a feltételes hozzáférési szabályzatnak.

Microsoft Graph

A Microsoft Graph speciális szempontokat is figyelembe vett az alkalmazások feltételes hozzáférési környezetekben való létrehozásakor. A feltételes hozzáférés mechanikája általában ugyanúgy működik, de a felhasználók által látott szabályzatok az alkalmazás által a gráfból kért alapul szolgáló adatokon alapulnak.

Konkrétan az összes Microsoft Graph-hatókör olyan adathalmazt jelöl, amely egyedileg alkalmazhat szabályzatokat. Mivel a feltételes hozzáférési szabályzatok adott adathalmazokhoz vannak rendelve, a Microsoft Entra ID a Graph mögötti adatok alapján kényszeríti ki a feltételes hozzáférési szabályzatokat, nem pedig magát a Graphot.

Ha például egy alkalmazás a következő Microsoft Graph-hatóköröket kéri,

scopes="ChannelMessages.Read.All Mail.Read"

Egy alkalmazás elvárhatja a felhasználóktól, hogy teljesítsék a Teamsben és az Exchange-ben beállított összes szabályzatot. Egyes hatókörök több adathalmazra is megfeleltethetők, ha hozzáférést biztosítanak.

Feltételes hozzáférési szabályzat betartása

Több különböző alkalmazástopológia esetén a rendszer kiértékel egy feltételes hozzáférési szabályzatot a munkamenet létrehozásakor. Mivel a feltételes hozzáférési szabályzat az alkalmazások és szolgáltatások részletességén alapul, a meghívási pont nagyban függ attól a forgatókönyvtől, amelyet el szeretne végezni.

Amikor az alkalmazás feltételes hozzáférési szabályzattal próbál hozzáférni egy szolgáltatáshoz, feltételes hozzáférési kihívásba ütközhet. Ez a feladat a claims Microsoft Entra ID válaszában szereplő paraméterben van kódolva. Íme egy példa erre a kihívásparaméterre:

claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

A fejlesztők elvégezhetik ezt a feladatot, és hozzáfűzhetik egy új kéréshez a Microsoft Entra-azonosítóhoz. Az állapot átadása arra kéri a végfelhasználót, hogy hajtsa végre a feltételes hozzáférési szabályzatnak való megfeleléshez szükséges műveleteket. Az alábbi forgatókönyvekben a hiba részletei és a paraméter kinyerésének menete ismertetendő.

Forgatókönyvek

Előfeltételek

A Microsoft Entra Feltételes hozzáférés a Microsoft Entra ID P1 vagy P2 szolgáltatás része. A Microsoft 365 Vállalati verziós licenccel rendelkező ügyfelek is hozzáférhetnek a feltételes hozzáférési funkciókhoz.

Adott forgatókönyvek megfontolandó szempontjai

A következő információk csak ezekben a feltételes hozzáférési forgatókönyvekben érvényesek:

  • A folyamat nevében végrehajtó alkalmazások
  • Több szolgáltatást/erőforrást elérő alkalmazások
  • Egyoldalas alkalmazások MSAL.js

Az alábbi szakaszok az összetettebb gyakori forgatókönyveket ismertetik. Az alapvető működési elv a feltételes hozzáférési szabályzatok kiértékelése a jogkivonat kérésének időpontjában a feltételes hozzáférési szabályzattal rendelkező szolgáltatás esetében.

Forgatókönyv: A meghatalmazásos folyamatot végrehajtó alkalmazás

Ebben a forgatókönyvben végigvezetjük azt az esetet, amikor egy natív alkalmazás webszolgáltatást/API-t hív meg. Ez a szolgáltatás viszont az "on-behalf-of" folyamatot hajtja létre egy downstream szolgáltatás meghívásához. Esetünkben a feltételes hozzáférési szabályzatot az alsóbb rétegbeli szolgáltatásra (Web API 2) alkalmaztuk, és nem kiszolgáló-/démonalkalmazást, hanem natív alkalmazást használunk.

App performing the on-behalf-of flow diagram

A Web API 1 kezdeti jogkivonat-kérése nem kéri a végfelhasználótól a többtényezős hitelesítést, mivel a Web API 1 nem mindig éri el az alsóbb rétegbeli API-t. Miután a Web API 1 megkísérel jogkivonatot kérni a felhasználó nevében a Web API 2-hez, a kérés meghiúsul, mivel a felhasználó nem jelentkezett be többtényezős hitelesítéssel.

A Microsoft Entra ID http-választ ad vissza néhány érdekes adattal:

Feljegyzés

Ebben a példában ez egy többtényezős hitelesítési hibaleírás, de interaction_required a feltételes hozzáféréshez számos lehetséges feltétel tartozik.

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API 2 App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

A Web API 1-ben elkapjuk a hibát error=interaction_required, és visszaküldjük a claims kihívást az asztali alkalmazásnak. Ekkor az asztali alkalmazás új acquireToken() hívást indíthat, és további lekérdezési sztringparaméterként hozzáfűzheti a claimsfeladatot. Az új kéréshez a felhasználónak többtényezős hitelesítést kell végeznie, majd vissza kell küldenie ezt az új jogkivonatot a Web API 1-nek, és végre kell hajtania a helyszíni folyamatot.

A forgatókönyv kipróbálásához tekintse meg a .NET-kódmintát. Bemutatja, hogyan továbbíthatja a jogcímekkel kapcsolatos kihívást a Web API 1-ből a natív alkalmazásba, és hogyan hozhat létre új kérést az ügyfélalkalmazáson belül.

Forgatókönyv: Több szolgáltatást elérő alkalmazás

Ebben a forgatókönyvben végigvezetjük azt az esetet, amikor egy webalkalmazás két olyan szolgáltatást ér el, amelyek közül az egyikhez feltételes hozzáférési szabályzat van hozzárendelve. Az alkalmazáslogikától függően előfordulhat, hogy az alkalmazás nem igényel hozzáférést mindkét webszolgáltatáshoz. Ebben a forgatókönyvben a jogkivonat kérésének sorrendje fontos szerepet játszik a végfelhasználói élményben.

Tegyük fel, hogy az A és A webszolgáltatás, a B webszolgáltatás pedig a feltételes hozzáférési szabályzatot alkalmazza. Bár a kezdeti interaktív hitelesítési kérelemhez mindkét szolgáltatáshoz hozzájárulás szükséges, a feltételes hozzáférési szabályzatra nem minden esetben van szükség. Ha az alkalmazás jogkivonatot kér a B webszolgáltatáshoz, a rendszer meghívja a szabályzatot, és az A webszolgáltatásra vonatkozó későbbi kérések is sikeresek lesznek az alábbiak szerint.

App accessing multiple-services flow diagram

Ha az alkalmazás kezdetben jogkivonatot kér az A webszolgáltatáshoz, a végfelhasználó nem hívja meg a feltételes hozzáférési szabályzatot. Ez lehetővé teszi, hogy az alkalmazás fejlesztője szabályozza a végfelhasználói élményt, és ne kényszerítse a feltételes hozzáférési szabályzat meghívását minden esetben. A trükkös eset az, ha az alkalmazás később jogkivonatot kér a B webszolgáltatáshoz. Ezen a ponton a végfelhasználónak meg kell felelnie a feltételes hozzáférési szabályzatnak. Amikor az alkalmazás megpróbálja acquireToken, az a következő hibát okozhatja (az alábbi ábrán látható):

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.
claims={"access_token":{"polids":{"essential":true,"Values":["<GUID>"]}}}

App accessing multiple services requesting a new token

Ha az alkalmazás az MSAL-kódtárat használja, a jogkivonat beszerzésének sikertelensége mindig interaktívan újrapróbálkozott. Ha ez az interaktív kérés megtörténik, a végfelhasználónak lehetősége van megfelelni a feltételes hozzáférésnek. Ez csak akkor igaz, ha a kérés egy AcquireTokenSilentAsync vagy PromptBehavior.Never ebben az esetben az alkalmazásnak interaktív AcquireToken kérést kell végrehajtania, hogy a végfelhasználónak lehetőséget adjon a szabályzatnak való megfelelésre.

Forgatókönyv: Egyoldalas alkalmazás (SPA) MSAL.js

Ebben a forgatókönyvben végigvezetjük az esetet, amikor egy egyoldalas alkalmazás (SPA) meghív egy feltételes hozzáféréssel védett webes API-t MSAL.js használatával. Ez egy egyszerű architektúra, de van néhány árnyalata, amelyeket figyelembe kell venni a feltételes hozzáférés fejlesztése során.

A MSAL.js néhány függvény a következő jogkivonatokat szerzi be: acquireTokenSilent(), acquireTokenPopup()és acquireTokenRedirect().

  • acquireTokenSilent() a hozzáférési jogkivonat csendes beszerzésére használható, ami azt jelenti, hogy semmilyen körülmények között nem jeleníti meg a felhasználói felületet.
  • acquireTokenPopup() és acquireTokenRedirect() mindkettő egy erőforrás jogkivonatának interaktív lekérésére szolgál, ami azt jelenti, hogy mindig a bejelentkezési felhasználói felületet jelenítik meg.

Ha egy alkalmazásnak hozzáférési jogkivonatra van szüksége egy webes API meghívásához, megpróbál egy acquireTokenSilent(). Ha a jogkivonat lejárt, vagy meg kell felelnünk egy feltételes hozzáférési szabályzatnak, akkor a acquireToken függvény meghiúsul, és az alkalmazás használja acquireTokenPopup() vagy acquireTokenRedirect().

Single-page app using MSAL flow diagram

Tekintsünk át egy példát a feltételes hozzáférési forgatókönyvünkkel. A végfelhasználó most szállt le a webhelyre, és nincs munkamenete. Hívás végrehajtása loginPopup() , azonosító jogkivonat lekérése többtényezős hitelesítés nélkül. Ezután a felhasználó egy olyan gombra kattint, amely megköveteli, hogy az alkalmazás adatokat kérjen egy webes API-ból. Az alkalmazás megpróbál hívást kezdeményezni acquireTokenSilent() , de sikertelen, mivel a felhasználó még nem hajtott végre többtényezős hitelesítést, és meg kell felelnie a feltételes hozzáférési szabályzatnak.

A Microsoft Entra ID a következő HTTP-választ küldi vissza:

HTTP 400; Bad Request
error=interaction_required
error_description=AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must use multi-factor authentication to access '<Web API App/Client ID>'.

Az alkalmazásnak el kell kapnia a error=interaction_required. Az alkalmazás ezután használhatja vagy acquireTokenPopup()acquireTokenRedirect() ugyanazon az erőforráson. A felhasználónak többtényezős hitelesítést kell végeznie. Miután a felhasználó elvégezte a többtényezős hitelesítést, az alkalmazás új hozzáférési jogkivonatot ad ki a kért erőforráshoz.

A forgatókönyv kipróbálásához tekintse meg a React SPA-t, amely Node.js webes API-t hív meg a folyamatkód-minta nevében. Ez a kódminta a React SPA-val korábban regisztrált feltételes hozzáférési szabályzatot és webes API-t használja a forgatókönyv bemutatásához. Bemutatja, hogyan kezelheti megfelelően a jogcímekkel kapcsolatos kihívásokat, és hogyan szerezhet be egy hozzáférési jogkivonatot, amely használható a webes API-hoz.

Lásd még