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

Egybérlős alkalmazás átalakítása több-bérlőssé a Microsoft Entra-azonosítón

Ha szolgáltatásként kínál szoftveralkalmazást (SaaS) számos szervezetnek, úgy konfigurálhatja az alkalmazást, hogy bármely Microsoft Entra-bérlőről fogadjon be bejelentkezéseket, ha több-bérlősre konvertálja azt. Bármely Microsoft Entra-bérlő felhasználói bejelentkezhetnek az alkalmazásba, miután hozzájárultak a fiókjuk alkalmazáshoz való használatához.

A saját fiókrendszerrel rendelkező meglévő alkalmazásokhoz (vagy más felhőszolgáltatóktól származó egyéb bejelentkezésekhez) az OAuth2, az OpenID Connect vagy a Security Assertion Markup Language (SAML) használatával kell bejelentkezési kódot hozzáadnia, és be kell helyeznie egy "Bejelentkezés a Microsofttal" gombot az alkalmazásban.

Ebben az útmutatóban az egyetlen bérlői alkalmazás Microsoft Entra több-bérlős alkalmazássá alakításához szükséges négy lépést hajt végre:

  1. Az alkalmazásregisztráció frissítése, hogy több bérlőt kiszolgáló legyen
  2. Frissítse a kódot, hogy kéréseket küldjön a /common végpontnak
  3. Frissítse a kódját több kibocsátói érték kezelésére
  4. A felhasználói és rendszergazdai hozzájárulás ismertetése és a megfelelő kódmódosítások végrehajtása

Ha ki szeretné próbálni az egyik mintánkat, tekintse meg a Microsoft Graph-ot a Microsoft Entra ID és OpenID Connect segítségével meghívó több-bérlős SaaS webalkalmazás építését.

Előfeltételek

A regisztráció frissítése több bérlősre

Alapértelmezés szerint a webalkalmazás/API-regisztrációk a Microsoft Entra ID-ben single-tenant módúak a létrehozáskor. Ha többtényezőssé szeretné tenni a regisztrációt, jelentkezzen be a Microsoft Entra felügyeleti központjába , és válassza ki a frissíteni kívánt alkalmazásregisztrációt. Ha meg van nyitva az alkalmazásregisztráció, válassza a Hitelesítés panelt, és lépjen a Támogatott fióktípusok szakaszra. Módosítsa a beállítást a bármely szervezeti címtárban lévő fiókok értékre.

Amikor egy egybérlős alkalmazást hoznak létre a Microsoft Entra adminisztrációs központjában, az Áttekintés lapon felsorolt elemek egyike az Alkalmazásazonosító URI-ja. Ez az egyik módja annak, hogy egy alkalmazás azonosítható a protokollüzenetekben, és bármikor hozzáadható. Az egybérlős alkalmazások alkalmazásazonosítójának URI-ja globálisan egyedi lehet az adott bérlőn belül. Ezzel szemben a több-bérlős alkalmazások esetében globálisan egyedinek kell lennie az összes bérlőben, biztosítva, hogy a Microsoft Entra ID minden bérlőben megtalálja az alkalmazást.

Például, ha a bérlő neve contoso.onmicrosoft.com, akkor egy érvényes alkalmazásazonosító URI lenne https://contoso.onmicrosoft.com/myapp. Ha az alkalmazásazonosító URI-ja nem követi ezt a mintát, az alkalmazás több-bérlősként való beállítása meghiúsul.

Frissítse a kódot, hogy kéréseket küldjön a /common

Több-bérlős alkalmazás esetén az alkalmazás nem tudja azonnal megállapítani, hogy a felhasználó melyik bérlőtől származik, így a kérelmek nem küldhetők el a bérlő végpontjára. Ehelyett a kéréseket egy közös végpontra (https://login.microsoftonline.com/common) küldi a rendszer, amely az összes Microsoft Entra-bérlőt kiszolgálja, és a kéréseket kezelő központi központként működik.

Nyissa meg az alkalmazást az IDE-ben, szerkessze a kódot, és módosítsa a bérlőazonosító /commonértékét. SAML-alkalmazások esetén ez konfigurálható az identitásszolgáltató XML-fájljában. Ez a végpont nem bérlő vagy kibocsátó. Amikor a Microsoft identitásplatform kérést kap a /common végponton, bejelentkezteti a felhasználót, és felderíti, hogy a felhasználó melyik bérlőtől származik. Ez a végpont a Microsoft Entra ID által támogatott összes hitelesítési protokolllal működik (OpenID Connect, OAuth 2.0, SAML 2.0, WS-Federation).

Az alkalmazásra adott bejelentkezési válasz ezután egy, a felhasználót jelképező tokent tartalmaz. A jogkivonat kiállítói értéke megmutatja az alkalmazásnak, hogy a felhasználó milyen bérlőből származik. Amikor egy válasz visszatér a /common végpontról, a token kiállítói értéke a felhasználó bérlőjének felel meg.

Megjegyzés:

A valóságban 2 hatóság létezik a több-bérlős alkalmazásokhoz:

  • https://login.microsoftonline.com/common bármely szervezeti címtárban (bármely Microsoft Entra címtárban) és személyes Microsoft-fiókban (például Skype, XBox) lévő fiókokat feldolgozó alkalmazásokhoz.
  • https://login.microsoftonline.com/organizations bármely szervezeti könyvtárban (bármely Microsoft Entra-címtárban) fiókokat feldolgozó alkalmazások esetén:

A dokumentumban található magyarázatok a következőt használják common: Azonban lecserélheti organizations-ra, ha az alkalmazás nem támogatja a Microsoft személyes fiókjait.

Frissítse a kódját, hogy több kiállító értéket tudjon kezelni

A webalkalmazások és a webes API-k jogkivonatokat fogadnak és érvényesítenek a Microsoft identitásplatformjáról. A natív ügyfélalkalmazások nem ellenőrzik a hozzáférési jogkivonatokat, és átlátszatlanként kell kezelniük őket. Ehelyett jogkivonatokat kérnek és fogadnak a Microsoft identitásplatformjáról, és ezt azért teszik, hogy elküldjék az API-knak, ahol azokat érvényesítik.

A több-bérlős alkalmazásoknak alaposabb ellenőrzéseket kell végrehajtaniuk egy token érvényesítésekor. A több-bérlős alkalmazás úgy van konfigurálva, hogy a kulcsok metaadatát az /organizations vagy /common kulcsok URL-címeiről fogyassza. Az alkalmazásnak ellenőriznie kell, hogy a issuer közzétett metaadatok tulajdonsága megegyezik-e a iss jogkivonatban szereplő jogcímekkel, valamint azt, hogy a iss jogkivonatban szereplő jogcím tartalmazza-e a bérlőazonosító (tid) jogcímet. További információ: Jogkivonatok érvényesítése.

Ahhoz, hogy egy felhasználó bejelentkezzen egy alkalmazásba a Microsoft Entra-azonosítóban, az alkalmazásnak a felhasználó bérlőjében kell lennie. A szervezet ezután olyan műveleteket hajthat végre, mint az egyedi szabályzatok alkalmazása, amikor a bérlői felhasználók bejelentkeznek az alkalmazásba. Egy bérlős alkalmazás esetén a regisztrációt a Microsoft Entra felügyeleti központon keresztül használhatja.

Több-bérlős alkalmazások esetén az alkalmazás kezdeti regisztrációja a fejlesztő által használt Microsoft Entra-bérlőben található. Amikor egy másik bérlő felhasználója először jelentkezik be az alkalmazásba, a Microsoft Entra-azonosító megkéri őket, hogy járuljanak hozzá az alkalmazás által kért engedélyekhez. Ha beleegyeznek, akkor létrejön egy szolgáltatásnévnek nevezett alkalmazás ábrázolása a felhasználó bérlőjében, és a bejelentkezés folytatódhat. A címtárban létrejön egy delegálás is, amely rögzíti a felhasználónak az alkalmazáshoz való hozzájárulását. Az alkalmazás és a ServicePrincipal objektumokkal, valamint az egymással való kapcsolatukkal kapcsolatos részletekért tekintse meg az alkalmazásobjektumokat és a szolgáltatásnév-objektumokat.

Egy felhasználó egyrétegű alkalmazáshoz való hozzájárulását szemléltető ábra.

Az alkalmazás által kért engedélyek hatással vannak a hozzájárulási felületre. A Microsoft identitásplatformja kétféle engedélyt támogat;

  • Delegált: Ez az engedély lehetővé teszi, hogy az alkalmazás bejelentkezett felhasználóként működjön a felhasználó által elvégezhető műveletek egy részhalmazában. Például delegált engedélyt adhat egy alkalmazásnak a bejelentkezett felhasználó naptárának olvasására.
  • Csak alkalmazás: Ezt az engedélyt közvetlenül az alkalmazás személyazonossága kapja meg. Megadhat például egy alkalmazás számára csak alkalmazásengedélyt a bérlői felhasználók listájának olvasására, függetlenül attól, hogy ki jelentkezett be az alkalmazásba.

A rendszeres felhasználók bizonyos engedélyekhez hozzájárulhatnak, míg más esetekben bérlői rendszergazda hozzájárulásra van szükség.

A felhasználói és rendszergazdai hozzájárulással kapcsolatos további információkért lásd a rendszergazdai hozzájárulási munkafolyamat konfigurálását ismertető témakört.

A csak alkalmazásra vonatkozó engedélyekhez mindig bérlői rendszergazdai hozzájárulás szükséges. Ha az alkalmazás csak alkalmazásengedélyt kér, és egy felhasználó megpróbál bejelentkezni az alkalmazásba, hibaüzenet jelenik meg, amely szerint a felhasználó nem tud hozzájárulni.

Bizonyos delegált engedélyekhez a bérlői rendszergazda hozzájárulása is szükséges. Például ahhoz, hogy a bejelentkezett felhasználóként vissza tudjon írni a Microsoft Entra-azonosítóba, bérlői rendszergazdai hozzájárulásra van szükség. A csak alkalmazásengedélyekhez hasonlóan, ha egy átlagos felhasználó megpróbál bejelentkezni egy olyan alkalmazásba, amely rendszergazdai hozzájárulást igénylő delegált engedélyt kér, az alkalmazás hibaüzenetet kap. Az erőforrást közzétevő fejlesztő határozza meg, hogy egy engedélyhez rendszergazdai hozzájárulás szükséges-e, és ezeket az információkat az erőforrás dokumentációjában találja. A Microsoft Graph API engedélydokumentációja jelzi, hogy mely engedélyek igényelnek rendszergazdai hozzájárulást.

Ha az alkalmazás rendszergazdai hozzájárulást igénylő engedélyeket használ, fontolja meg egy gomb vagy hivatkozás hozzáadását, ahol a rendszergazda kezdeményezheti a műveletet. Az alkalmazás által erre a műveletre küldött kérés a szokásos OAuth2/OpenID Connect engedélyezési kérelem, amely a lekérdezési sztring paramétert prompt=consent is tartalmazza. Miután a rendszergazda jóváhagyása megtörténik, és a szolgáltatási példány létrejön az ügyfél bérlőjében, a későbbi bejelentkezési kérelmeknek nincs szükségük a prompt=consent paraméterre. Mivel a rendszergazda jóváhagyta a kért engedélyeket, a rendszer nem kér jóváhagyást a bérlő többi felhasználójától.

A bérlői rendszergazda letilthatja, hogy a rendszeres felhasználók beleegyezhessenek az alkalmazásokba. Ha ez a funkció le van tiltva, a rendszergazdai hozzájárulásra mindig szükség van ahhoz, hogy az alkalmazás a bérlőben legyen használva. Az alkalmazást a Microsoft Entra felügyeleti központjában tesztelheti, ha a végfelhasználói hozzájárulás le van tiltva. A Nagyvállalati alkalmazások>beleegyezése és engedélyei területen ellenőrizze a Felhasználói hozzájárulás engedélyezése tiltása lehetőséget.

A prompt=consent paramétert olyan alkalmazások is használhatják, amelyek rendszergazdai hozzájárulást nem igénylő engedélyeket kérnek. Ilyen eset például, ha az alkalmazás olyan felhasználói felületet igényel, amelyben a bérlő rendszergazdája egyszer "regisztrál", és a rendszer nem kér más felhasználóktól hozzájárulást ettől a ponttól kezdve.

Ha egy alkalmazáshoz rendszergazdai hozzájárulásra van szükség, és a rendszergazda a prompt=consent paraméter elküldése nélkül jelentkezik be, amikor a rendszergazda sikeresen hozzájárul az alkalmazáshoz, az csak a felhasználói fiókjára vonatkozik. A rendszeres felhasználók nem tudnak bejelentkezni vagy hozzájárulni az alkalmazáshoz. Ez a funkció akkor hasznos, ha lehetővé szeretné tenni, hogy a bérlői rendszergazda megismerje az alkalmazást, mielőtt más felhasználók számára hozzáférést engedélyez.

Előfordulhat, hogy az alkalmazás több szinttel rendelkezik, és mindegyik saját regisztrációval jelenik meg a Microsoft Entra ID-ban. Például egy webes API-t hívó natív alkalmazás, vagy egy webes API-t hívó webalkalmazás. Mindkét esetben az ügyfél (natív alkalmazás vagy webalkalmazás) engedélyt kér az erőforrás (webes API) meghívására. Ahhoz, hogy az ügyfél sikeresen engedélyezést kapjon a vevő bérlőjébe való belépéshez, az összes erőforrásnak, amelyhez engedélyt kér, már léteznie kell a vevő bérlőjében. Ha ez a feltétel nem teljesül, a Microsoft Entra ID hibát ad vissza, amely szerint először hozzá kell adni az erőforrást.

Több szint egyetlen bérlőben

Ha a logikai alkalmazás két vagy több alkalmazásregisztrációból , például egy külön ügyfélből és erőforrásból áll, problémákat tapasztalhat. Hogyan juttatja el először az erőforrást a külső felhasználói környezetbe? A Microsoft Entra ID egyetlen lépésben engedélyezi az ügyfél és az erőforrás jóváhagyását. A felhasználó a hozzájárulási oldalon az ügyfél és az erőforrás által kért engedélyek összegét látja. A viselkedés engedélyezéséhez az erőforrás alkalmazásregisztrációjának tartalmaznia kell az ügyfél alkalmazásazonosítóját knownClientApplications az alkalmazásjegyzékben. Például:

"knownClientApplications": ["12ab34cd-56ef-78gh-90ij11kl12mn"]

A bemutatóhoz a több-bérlős alkalmazásmintára is hivatkozhat. Az alábbi ábra áttekintést nyújt az egyetlen bérlőben regisztrált többrétegű alkalmazások hozzájárulásáról.

Diagram, amely a többrétegű ismert ügyfélalkalmazáshoz való hozzájárulást szemlélteti.

Több szint több bérlőben

Hasonló eset akkor fordul elő, ha az alkalmazás különböző szintjei különböző bérlőkben vannak regisztrálva. Vegyük például az Exchange Online API-t meghívó natív ügyfélalkalmazások létrehozásának esetét. A natív alkalmazás fejlesztéséhez, és ahhoz, hogy később a natív alkalmazás fusson egy ügyfél bérlőjében, az Exchange Online szolgáltatási főnöknek jelen kell lennie. Itt a fejlesztőnek és az ügyfélnek meg kell vásárolnia az Exchange Online-t annak érdekében, hogy a szolgáltatás-főösszetevő létrejöjjön a bérlőknél.

Ha a Microsofttól eltérő szervezet által létrehozott API-ról van szó, akkor az API fejlesztőjének biztosítania kell egy módot, amely lehetővé teszi az ügyfelek számára, hogy hozzájáruljanak az alkalmazás elfogadásához ügyfeleik bérlőiben. Az ajánlott kialakítás a külső fejlesztők számára készült, hogy létrehozsák az API-t, hogy webes ügyfélként is működjenek a regisztráció implementálásához. Képes vagy;

  1. A korábbi szakaszokat követve győződjön meg arról, hogy az API implementálja a több-bérlős alkalmazásregisztrációs/kódkövetelményeket.
  2. Az API hatóköreinek/szerepköreinek felfedése mellett győződjön meg arról, hogy a regisztráció tartalmazza a "Bejelentkezési és olvasási felhasználói profil" engedélyt (alapértelmezés szerint).
  3. Implementáljon egy bejelentkezési/regisztrációs lapot a webes ügyfélalkalmazásban, és kövesse a rendszergazdai hozzájárulásra vonatkozó útmutatást.
  4. Miután a felhasználó hozzájárul az alkalmazáshoz, létrejön a szolgáltatási főazonosító és a hozzájárulás-delegálás hivatkozása a saját bérlőjükben, és a natív alkalmazás jogkivonatokat szerezhet az API-hoz.

Az alábbi ábra áttekintést nyújt a különböző bérlőkben regisztrált többrétegű alkalmazások hozzájárulásáról.

Diagram, amely szemlélteti a többrétegű és több résztvevős alkalmazásokhoz való hozzájárulást.

A felhasználók és a rendszergazdák bármikor visszavonhatják az alkalmazáshoz való hozzájárulást:

  • A felhasználók úgy vonják vissza az egyes alkalmazásokhoz való hozzáférést, hogy eltávolítják őket a Hozzáférési panel alkalmazáslistájából .
  • A rendszergazdák visszavonhatják az alkalmazásokhoz való hozzáférést a Microsoft Entra Felügyeleti központ Nagyvállalati alkalmazások szakaszával való eltávolításával. Válassza ki az alkalmazást, és lépjen az Engedélyek lapra a hozzáférés visszavonásához.

Ha a rendszergazda egy bérlő összes felhasználója számára hozzájárul egy alkalmazáshoz, a felhasználók nem vonhatják vissza egyenként a hozzáférést. Csak a rendszergazda vonhatja vissza a hozzáférést, és csak a teljes alkalmazáshoz.

Több-bérlős alkalmazások és hozzáférési jogkivonatok gyorsítótárazása

A több-bérlős alkalmazások hozzáférési jogkivonatokat is lekérhetnek a Microsoft Entra ID által védett API-k meghívásához. A Microsoft Authentication Library (MSAL) több-bérlős alkalmazással való használatakor gyakran előfordul, hogy először jogkivonatot kér egy felhasználótól /common, választ kap, majd egy további jogkivonatot kér ugyanarra a felhasználóra is /common. Mivel a Microsoft Entra azonosító válasza egy bérlőtől származik, és nem /common, az MSAL a jogkivonatot a bérlőtől gyorsítótárazza. A felhasználó hozzáférési jogkivonatának lekérésére irányuló későbbi hívás /common elmulasztja a gyorsítótár-bejegyzést, és a rendszer kéri a felhasználót, hogy jelentkezzen be újra. A gyorsítótár hiányának elkerülése érdekében győződjön meg arról, hogy egy már bejelentkezett felhasználó további hívásai a bérlő végpontjára kerülnek.

Lásd még

  • Last updated on