Tokenek testreszabása

Fejlesztőként a Microsoft Entra ID-val való fő interakció token kérése a felhasználó azonosításához. Emellett kér egy jogkivonatot, hogy engedélyt kapjon egy webes API meghívásához. A webes API-jogkivonat határozza meg, hogy az API mit tehet, ha egy adott kérést nyújt. Ebben a cikkben megismerheti a jogkivonatokban kapott információkat, valamint a jogkivonatok testreszabásának módját. Ezek a Zero Trust fejlesztői ajánlott eljárások növelik a rugalmasságot és a vezérlést, miközben a legkisebb jogosultsággal növelik az alkalmazásbiztonságot.

Az alkalmazásjogkivonatok testreszabásának okai az alkalmazásokban és API-kban történő részletesebb engedélyezéshez használt folyamattól függenek. Előfordulhat például, hogy az alkalmazásban különböző felhasználói szerepkörök, hozzáférési szintek és funkciók találhatók, amelyek jogkivonatokból származó információkra támaszkodnak.

A Microsoft Graph API megbízható címtárinformációkat és adatokat biztosít a Microsoft 365-ben. A Microsoft Graph adataira támaszkodva részletes és gazdag engedélyezési rendszert fejleszthet. Hozzáférhet például a felhasználó csoporttagságából, a részletes profiladatokból, a SharePointból és az Outlookból származó információkhoz, amelyek felhasználhatók az engedélyezési döntésekben. A Microsoft Entra ID-ből belefoglalhatja az engedélyezési adatokat a jogkivonatba.

Alkalmazásszintű engedélyezés

Az informatikai szakemberek alkalmazásszintű engedélyezést adhatnak hozzá token módosítás vagy kód hozzáadása nélkül.

Az informatikai szakemberek megakadályozhatják, hogy jogkivonatokat adjanak ki a bérlő bármely alkalmazásának a felhasználói hozzárendelés szükséges jelzővel. Ez a módszer biztosítja, hogy csak a felhasználók egy halmaza tud bejelentkezni az alkalmazásba. E jelző nélkül a bérlő összes felhasználója hozzáférhet az alkalmazáshoz. Ezzel a jelzővel csak a hozzárendelt felhasználók és csoportok férhetnek hozzá az alkalmazáshoz. Amikor egy hozzárendelt felhasználó hozzáfér az alkalmazáshoz, az alkalmazás kap egy tokent. Ha a felhasználónak nincs hozzárendelése, az alkalmazás nem kap tokent. Ne felejtse el, hogy mindig elegánsan kezelje azokat a token-kérelmeket, amelyek nem kapnak tokent.

Token testreszabási módszerei

A tokenek testreszabására két mód van: opcionális igények és igények leképezése.

Választható jogcímek

Az opcionális attribútumok meghatározzák, hogy a Microsoft Entra ID milyen attribútumokat küldjön az alkalmazásnak tokenekben. Használhatja a nem kötelező jogcímeket:

• Válasszon ki több jogcímet, hogy szerepeljenek az alkalmazás tokenek között.
• Módosítsa a Microsoft identitásplatform által jogkivonatokban visszaadott jogcímek viselkedését.
• Hozzáad egyéni jogcímeket az alkalmazáshoz, és hozzáférhet azokhoz.

Az opcionális jogcímek egy meghatározott sémával kapcsolódnak az alkalmazásregisztrációs objektumhoz. Ezek az alkalmazásra vonatkoznak, függetlenül attól, hogy hol fut. Több-bérlős alkalmazás írásakor az opcionális jogcímek jól működnek, mivel a Microsoft Entra ID minden bérlőjében konzisztensek. Az IP-címek például nem bérlőspecifikusak, míg egy alkalmazás IP-címmel rendelkezik.

Alapértelmezés szerint a bérlő vendégfelhasználói is bejelentkezhetnek az alkalmazásba. Ha meg szeretné tiltani a vendégfelhasználók használatát, jelentkezzen be az opcionális jogcímre (acct). Ha így van 1, akkor a felhasználó vendégbesorolással rendelkezik. Ha le szeretné tiltani a vendégeket, akkor tiltsa le a jogkivonatokat a következővel: acct==1.

Jogcímleképezési szabályzatok

A Microsoft Entra ID-ban a szabályzatobjektumok szabálykészleteket jelölnek az egyes alkalmazásokra vagy a szervezet összes alkalmazására. A jogcímleképezési szabályzat módosítja azokat a jogcímeket, amelyeket a Microsoft Entra ID adott alkalmazások jogkivonataiban állít ki.

Jogcímleképezést használ olyan bérlőspecifikus információkhoz, amelyek nem tartalmaznak sémát (például EmployeeID, DivisionName). A jogcímek leképezése a bérlői rendszergazda által vezérelt szolgáltatási főszereplő szintjén érvényes. A jogcímek leképezése az adott alkalmazás vállalati alkalmazásának vagy annak szolgáltatási főszereplőjének felel meg. Minden bérlőnek lehet saját jogosultságleképezése.

Üzletági alkalmazás fejlesztésekor különösen vizsgálja meg, hogy mit tesz a fogadó (milyen konkrét jogosultságokkal rendelkezik a fogadó, amelyeket felhasználhat a hozzáférési tokenjében). Ha például egy szervezetnek van egy felhasználói részlegnév tulajdonsága (nem a Microsoft Entra ID standard mezője) a helyszíni Active Directoryban, a Microsoft Entra Connect használatával szinkronizálhatja azt a Microsoft Entra-azonosítóval.

Ezen információk megadásához használja az egyik szabványos bővítményattribútumot. Határozza meg a jogkivonatot egy részlegnév jogcímével, amelyet a megfelelő bővítményből hozhat létre (még akkor is, ha az nem minden bérlőre vonatkozik). Például egy szervezet az osztálynevét a kiterjesztett attribútum 13-ba helyezi.

Jogcímleképezéssel egy másik bérlő számára is használhatóvá teheti, amely a 7. attribútumba helyezi az osztásnevét.

Azonosítójel testreszabásának megtervezése

Az, hogy melyik jogkivonatot szabja testre, az alkalmazás típusától függ: ügyfélalkalmazás vagy API. Nincs különbség abban, amit tehet a token testreszabásához. Ami a tokenbe kerülhet, az mindegyiknél ugyanaz. A testre szabni kívánt jogkivonat attól függ, hogy az alkalmazás melyik jogkivonatot használja fel.

ID-tokén testreszabása

Ha ügyfélalkalmazást fejleszt, testre szabhatja az azonosító jogkivonatot , mert a felhasználó azonosításához ezt a jogkivonatot kéri. Egy jogkivonat akkor tartozik az alkalmazáshoz, ha a jogkivonat célközönsége (aud) egyezik az alkalmazás ügyfélazonosítójával. Olyan ügyfélalkalmazások esetében, amelyek API-kat hívnak meg, de nem implementálják őket, győződjön meg arról, hogy csak az alkalmazás azonosító jogkivonatát szabja testre.

Az Azure Portal és a Microsoft Graph API lehetővé teszi az alkalmazás hozzáférési jogkivonatának testreszabását is, de ezeknek a testreszabásoknak nincs hatása. Nem szabhat testre hozzáférési jogkivonatot olyan API-khoz, amelyek nem saját tulajdonúak. Ne feledje, hogy az alkalmazás nem kísérelheti meg dekódolni vagy megvizsgálni az ügyfélalkalmazás által api meghívására kapott hozzáférési jogkivonatot.

Hozzáférési jogkivonatok testreszabása

API fejlesztésekor testre szabhatja a hozzáférési jogkivonatot , mivel az API az ügyfél API-ra irányuló hívásának részeként hozzáférési jogkivonatokat kap.

Az ügyfélalkalmazások mindig testre szabják a felhasználó azonosítására kapott azonosító jogkivonatot. Az API-k testre szabják a hozzáférési jogkivonatokat, amelyeket az API az API-hívás részeként fogad.

Csoportok és alkalmazásszerepkörök

Az egyik leggyakoribb engedélyezési módszer a hozzáférés alapja egy felhasználó csoporttagsága vagy hozzárendelt szerepkörei. A csoportjogcímek és alkalmazásszerepkörök tokenekben való konfigurálása bemutatja, hogyan konfigurálhatja alkalmazásait alkalmazásszerepkör-definíciókkal, és hogyan rendelhet biztonsági csoportokat alkalmazásszerepkörökhöz. Ezek a módszerek segítenek a rugalmasság és az ellenőrzés javításában, miközben a minimális jogosultsággal rendelkező alkalmazásmegbízhatósági biztonságot növelik.

Következő lépések

• A B2B együttműködési felhasználói jogcímek leképezése a Microsoft Entra ID támogatását ismerteti a B2B együttműködési felhasználók számára a Security Assertion Markup Language (SAML) jogkivonatban kibocsátott jogcímek testreszabásához.
• Az alkalmazás SAML-jogkivonat-jogcímeinek testreszabása, ha egy felhasználó a SAML 2.0 protokoll használatával egy alkalmazást hitelesít a Microsoft identitásplatformon keresztül.
• API védelem ismerteti az API regisztrációval, az engedélyek és hozzájárulások meghatározásával, valamint a hozzáférés szigorításával kapcsolatos legjobb gyakorlatokat a Zero Trust célok elérése érdekében.
• Az ajánlott engedélyezési eljárások segítségével implementálhatja a legjobb engedélyezési, engedély- és hozzájárulási modelleket az alkalmazásokhoz.
• Biztonságos alkalmazások létrehozásához használja a Zero Trust identitás- és hozzáférés-kezelési fejlesztési ajánlott eljárásait az alkalmazásfejlesztési életciklusban.