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

  • Cikk

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 Csatlakozás vagy az SAML használatával kell bejelentkezési kódot hozzáadnia, és be kell helyeznie a "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 fogja elvégezni:

  1. Az alkalmazásregisztráció frissítése több-bérlősre
  2. Frissítse a kódot, hogy kéréseket küldjön a /common végpontnak
  3. A kód frissítése több kiállí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 meg szeretné próbálni használni az egyik mintánkat, tekintse meg egy több-bérlős SaaS-webalkalmazást, amely Microsoft Graphot hív meg Microsoft Entra-azonosító és OpenID Csatlakozás

Előfeltételek

Több-bérlős regisztráció frissítése

Alapértelmezés szerint a Web App/API-regisztrációk a Microsoft Entra-azonosítóban egy-bérlősek 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 bármely szervezeti címtárBan lévő Fiókok értékre.

Ha egy bérlős alkalmazást hoz létre a Microsoft Entra felügyeleti központban, 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, ami biztosítja, hogy a Microsoft Entra ID minden bérlőben megtalálja az alkalmazást.

Ha például a bérlő neve egy contoso.onmicrosoft.com é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. Ez a végpont nem bérlő vagy kiállító. Amikor a Microsoft Identitásplatform kérést kap a /common végponton, bejelentkezteti a felhasználót, ezáltal felderíti, hogy melyik bérlőtől származik a felhasználó. Ez a végpont a Microsoft Entra ID által támogatott összes hitelesítési protokolllal működik (OpenID Csatlakozás, 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ő jogkivonatot 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 /common válasz a végpontról ad vissza, a jogkivonat kiállítói értéke a felhasználó bérlőjének felel meg.

Feljegyzé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 (pl. 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: Ezt azonban lecserélheti arra az esetre, organizations ha az alkalmazás nem támogatja a Microsoft személyes fiókjait.

A kód frissítése több kiállítói érték kezelésére

A webalkalmazások és webes API-k jogkivonatokat kapnak és érvényesítenek a Microsoft Identitásplatform. 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ásplatform, és így elküldik őket az API-knak, ahol a rendszer érvényesíti őket.

A több-bérlős alkalmazásoknak több ellenőrzést kell végrehajtaniuk egy jogkivonat érvényesítésekor. A több-bérlős alkalmazás úgy van konfigurálva, hogy a kulcsok metaadatait használja fel az URL-címekről vagy /common kulcsok URL-címéről/organizations. 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. Ez lehetővé teszi a szervezet számára, hogy egyedi szabályzatokat alkalmazzon, 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.

Ezt a hozzájárulási élményt az alkalmazás által kért engedélyek befolyásolják. A Microsoft Identitásplatform 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.

Bizonyos engedélyekhez egy normál felhasználó adhat hozzájárulást, míg másokhoz bérlői rendszergazdai hozzájárulás szükséges.

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. Azt, hogy egy engedélyhez rendszergazdai hozzájárulásra van-e szükség, az erőforrást közzétevő fejlesztő határozza meg, és megtalálható az erőforrás dokumentációjában. 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 Csatlakozás engedélyezési kérelem, amely a lekérdezési sztring paramétert prompt=consent is tartalmazza. Miután a rendszergazda hozzájárult, és a szolgáltatásnév létre lett hozva 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 úgy döntött, hogy a kért engedélyek elfogadhatóak, a bérlő többi felhasználója nem kér hozzájárulást ettől a ponttól kezdve.

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. Erre példa, 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.

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, akkor a rendszergazda sikeresen hozzájárul az alkalmazáshoz, az csak a felhasználói fiókra vonatkozik. A rendszeres felhasználók továbbra sem 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 hozzájáruljon az ügyfél bérlőihez, az összes olyan erőforrásnak, amelyhez engedélyt kér, már léteznie kell az ügyfél 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

Ez akkor lehet probléma, ha a logikai alkalmazás két vagy több alkalmazásregisztrációból áll, például egy külön ügyfélből és erőforrásból. Hogyan szerezheti be először az erőforrást a külső bérlőbe? 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 knownClientApplicationsaz alkalmazásjegyzékben. Példa:

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

Ezt egy több-bérlős alkalmazásmintában mutatjuk be. 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 később ahhoz, hogy a natív alkalmazás egy ügyfél bérlőjében fusson, az Exchange Online szolgáltatásnévnek jelen kell lennie. Ebben az esetben a fejlesztőnek és az ügyfélnek meg kell vásárolnia az Exchange Online-t, hogy a szolgáltatásnév létre legyen hozva a bérlőikben.

Ha egy, a Microsofttól eltérő szervezet által létrehozott API, az API fejlesztőjének módot kell biztosítania az ügyfelek számára, hogy hozzájáruljanak az alkalmazáshoz az ügyfeleik bérlőinek. 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. Megvalósítás:

  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ásnév és a hozzájárulás-delegálás hivatkozása a bérlőben, és a natív alkalmazás jogkivonatokat szerezhet be 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 a többrétegű többrétegű alkalmazásokhoz való hozzájárulást szemlélteti.

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

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, nem /commonaz MSAL gyorsítótárazza a jogkivonatot a bérlőtől. 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