Fejlesztői útmutató a feltételes hozzáférés Azure AD funkcióhoz

  • Cikk

Figyelmeztetés

Ez a tartalom a régebbi Azure AD 1.0-s verziójú végponthoz tartozik. Használja a Microsoft Identitásplatform új projektekhez.

Megjegyzés

A cikk Microsoft Identitásplatform verziójáért lásd: Fejlesztői útmutató a feltételes hozzáférés Microsoft Entra.

Az Microsoft Entra-azonosító feltételes hozzáférés funkciója számos olyan módszer egyikét kínálja, amellyel biztonságossá teheti az alkalmazást és megvédheti a szolgáltatást. A feltételes hozzáféréssel a fejlesztők és a nagyvá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
  • Annak engedélyezése, hogy csak az Intune-ban regisztrált eszközök férhessenek hozzá bizonyos 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 Mi a feltételes hozzáférés? című témakörben talál.

A Azure AD alkalmazásokat készítő 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 van a feltételes hozzáférési szabályzatokkal nem rendelkező erőforrások elérésére. 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.

Feltételezzük az egy- és több-bérlős alkalmazások és a gyakori hitelesítési minták ismeretét .

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önyvek kódot igényelnek a feltételes hozzáférés "kihívásainak" kezeléséhez:

  • A megbízási folyamatot végrehajtó alkalmazások
  • Több szolgáltatást/erőforrást elérő alkalmazások
  • Egyoldalas alkalmazások ADAL.js
  • erőforrás meghívása 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-ra is alkalmazhatók. A feltételes hozzáférési szabályzatok konfigurálásával kapcsolatos további információkért lásd: Gyakori feltételes hozzáférési szabályzatok.

A forgatókönyvtől függően a vállalati ügyfelek bármikor alkalmazhatnak és eltávolíthatnak feltételes hozzáférési szabályzatokat. Ahhoz, hogy az alkalmazás továbbra is működőképes legyen egy új szabályzat alkalmazásakor, implementálnia kell a "kihívás" 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 a feltételes hozzáférés kezeléséhez kódmódosítást igényelnek, míg mások a szokásos módon működnek. Íme néhány olyan forgatókönyv, amely a feltételes hozzáférést használja a többtényezős hitelesítéshez, 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ő szinthez, és elküldi a jogkivonatot. A középső réteg a nevében hajtja végre a folyamatot, hogy hozzáférést kérjen az alsóbb rétegbeli API-hoz. 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 mögöttes 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, Azure AD 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="Bookings.Read.All Mail.Read"

Az alkalmazások elvárhatják a felhasználóktól, hogy teljesítsenek minden, a Bookingsban és az Exchange-ben beállított 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 nagymértékben függ az elérni kívánt forgatókönyvtől.

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 az claims Azure AD válaszában kapott paraméterben van kódolva. Íme egy példa erre a kihívási paraméterre:

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

A fejlesztők átvehetik ezt a feladatot, és hozzáfűzhetik egy új kéréshez, amely Azure AD. 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. A következő forgatókönyvekben a hiba részleteinek és a paraméter kinyerésének módját ismertetjük.

Forgatókönyvek

Előfeltételek

Microsoft Entra feltételes hozzáférés Microsoft Entra P1 vagy P2 azonosítójú szolgáltatás. A licencelési követelményekről a licenccel nem licencelt használati jelentésből tudhat meg többet. A fejlesztők csatlakozhatnak a Microsoft Developer Networkhez, amely a Nagyvállalati mobilitási csomag ingyenes előfizetését tartalmazza, amely tartalmazza Microsoft Entra P1 vagy P2 azonosítót.

Megfontolandó szempontok adott forgatókönyvekhez

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

  • A megbízási folyamatot végrehajtó alkalmazások
  • Több szolgáltatást/erőforrást elérő alkalmazások
  • Egyoldalas alkalmazások ADAL.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 abban az időpontban, amikor a jogkivonatot lekérte a feltételes hozzáférési szabályzattal rendelkező szolgáltatáshoz.

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 a "nevében" folyamatot hajtja létre egy alárendelt szolgáltatás meghívásához. A mi 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.

A meghatalmazáson alapuló folyamatábrákat végrehajtó alkalmazás

A Webes 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 előfordulhat, hogy a Webes 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.

Azure AD http-választ ad vissza néhány érdekes adattal:

Megjegyzés

Ebben az esetben ez egy többtényezős hitelesítési hiba leírása, de a feltételes hozzáféréshez számos interaction_required lehetőség áll rendelkezésre.

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 Webes API 1-ben elkapjuk a hibát error=interaction_required, és visszaküldjük a feladványt claims az asztali alkalmazásnak. Ekkor az asztali alkalmazás új acquireToken() hívást kezdeményezhet, és további lekérdezési sztringparaméterként hozzáfűzheti a claimskihívást. Ehhez 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 Webes API 1-nek, és végre kell hajtania a nevében történő folyamatot.

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

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 B webszolgáltatás van alkalmazva, a B webszolgáltatásra pedig a feltételes hozzáférési szabályzat vonatkozik. Bár a kezdeti interaktív hitelesítési kérelemhez mindkét szolgáltatáshoz hozzájárulásra van szükség, 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, akkor 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.

Többszolgáltatásos folyamatábra elérése az alkalmazás számára

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 minden esetben történő meghívását. 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, acquireTokenaz 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>"]}}}

Új jogkivonatot kérő több szolgáltatáshoz hozzáférő alkalmazás

Ha az alkalmazás az ADAL-kódtárat használja, a jogkivonat beszerzésének sikertelenségét a rendszer mindig interaktív módon újrapróbálja. Ha ez az interaktív kérés bekövetkezik, 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 AcquireTokenSilentAsync vagy PromptBehavior.Never ebben az esetben az alkalmazásnak interaktív AcquireToken kérést kell végrehajtania, hogy lehetőséget biztosítson a végfelhasználónak a szabályzat betartására.

Forgatókönyv: Egyoldalas alkalmazás (SPA) ADAL.js használatával

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

A ADAL.js-ben van néhány függvény, amely jogkivonatokat szerez be: login(), acquireToken(...), acquireTokenPopup(…)és acquireTokenRedirect(…).

  • login() egy interaktív bejelentkezési kérésen keresztül szerez be egy azonosító jogkivonatot, de nem szerez be hozzáférési jogkivonatokat egyetlen szolgáltatáshoz sem (beleértve a feltételes hozzáféréssel védett webes API-t).
  • acquireToken(…) ezután 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ő arra szolgál, hogy interaktív módon kérjen jogkivonatot egy erőforráshoz, ami azt jelenti, hogy mindig bejelentkezési felhasználói felületet jelenít 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 acquireToken(…). Ha a jogkivonat-munkamenet lejárt, vagy meg kell felelnie egy feltételes hozzáférési szabályzatnak, akkor a acquireToken függvény meghiúsul, és az alkalmazás a vagy acquireTokenRedirect()értéket használjaacquireTokenPopup().

Egyoldalas alkalmazás ADAL-folyamatábra használatával

Tekintsünk át egy példát a feltételes hozzáférési forgatókönyvünkhöz. A végfelhasználó éppen most landolt a webhelyen, és nincs munkamenete. Hívást hajtunk végre login() , és egy azonosító jogkivonatot kérünk le 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-tól. Az alkalmazás megpróbál hívást kezdeményezni acquireToken() , 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.

Azure AD 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 érnie a következőt 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ó befejezte 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 JS SPA Nevében kódmintát. Ez a kódminta a JS 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ást, és hogyan kérhet le egy hozzáférési jogkivonatot, amely használható a webes API-hoz. Másik lehetőségként tekintse meg az általános Angular.js kódmintát, amely útmutatást nyújt egy Angular SPA-hoz

Lásd még