Jogkivonatok kezelése Teljes felügyelet

Az Teljes felügyelet alkalmazásfejlesztés során fontos pontosan meghatározni az alkalmazás szándékát és erőforrás-hozzáférési követelményeit. Az alkalmazásnak csak a kívánt módon való működéshez szükséges hozzáférést kell kérnie. Ez a cikk fejlesztőként segítséget nyújt az alkalmazások biztonságának kialakításában azonosító jogkivonatokkal, hozzáférési jogkivonatokkal és biztonsági jogkivonatokkal, amelyeket az alkalmazás a Microsoft Identitásplatform kaphat.

Győződjön meg arról, hogy az alkalmazás betartja a minimális jogosultság Teljes felügyelet elvét, és megakadályozza a használatot olyan módon, amely veszélyezteti a szándékát. Korlátozza a felhasználói hozzáférést a Just-In-Time és a Just-Enough-Access (JIT/JEA), a kockázatalapú adaptív szabályzatokkal és az adatvédelemmel. Különítse el az alkalmazás bizalmas és hatékony szakaszait, így csak jogosult felhasználók férhetnek hozzá ezekhez a területekhez. Korlátozza a felhasználókat, akik használhatják az alkalmazást és az alkalmazásban lévő képességeket.

Hozza létre a legkisebb jogosultságot az alkalmazás által a Microsoft Identitásplatform kapott azonosító jogkivonatok kezeléséhez. Az azonosító jogkivonatokban található információk segítségével ellenőrizheti, hogy egy felhasználó az, akinek állítja magát. A felhasználó vagy szervezete meghatározhat olyan hitelesítési feltételeket, mint például az MFA biztosítása, felügyelt eszköz használata, és a megfelelő helyen való elhelyezés.

Megkönnyítheti az ügyfelek számára az alkalmazáshoz tartozó engedélyek kezelését. Csökkentse a felhasználói kiépítési többletterhelést és a manuális folyamatok szükségességét. Az automatikus felhasználókiépítés lehetővé teszi, hogy az informatikai rendszergazdák automatizálják a felhasználói identitások létrehozását, karbantartását és eltávolítását a cél identitástárolókban. Az ügyfelek a Felhasználók és csoportok módosításaira alapozhatják az automatizálást alkalmazáskiépítéssel vagy HR-alapú kiépítéssel a Microsoft Entra ID-ban.

Jogkivonat-jogcímek használata az alkalmazásokban

Jogcímeket használhat az alkalmazáson belüli UX azonosító jogkivonataiban kulcsként az adatbázisban, és hozzáférést biztosít az ügyfélalkalmazáshoz. Az azonosító jogkivonat az OpenID Csatlakozás (OIDC) által az OAuth 2.0-hoz történő alapvető bővítmény. Az alkalmazás a hozzáférési jogkivonatok mellett vagy helyett is fogadhat azonosító jogkivonatokat.

A biztonsági jogkivonatok engedélyezésének szabványos mintájában a kiadott azonosító jogkivonat lehetővé teszi, hogy az alkalmazás információt kapjon a felhasználóról. Ne használja az azonosító jogkivonatot engedélyezési folyamatként az erőforrások eléréséhez. Az engedélyezési kiszolgáló az alábbi felhasználói adatokat tartalmazó jogcímeket tartalmazó azonosító jogkivonatokat ad ki.

  • A célközönség (aud) jogcím az alkalmazás ügyfélazonosítója. Csak jogkivonatokat fogadjon el az API-ügyfélazonosítóhoz.
  • A tid jogcím a jogkivonatot kiállító bérlő azonosítója. A oid jogcím egy nem módosítható érték, amely egyedileg azonosítja a felhasználót. Használja kulcsként a jogcímek és oid jogcímek tid egyedi kombinációját, ha adatokat kell társítania a felhasználóhoz. Ezekkel a jogcímértékekkel visszakapcsolhatja az adatokat a felhasználó Microsoft Entra-azonosítójában lévő azonosítójához.
  • A sub jogcím egy nem módosítható érték, amely egyedileg azonosítja a felhasználót. A tulajdonosi jogcím az alkalmazáshoz is egyedi. Ha a sub jogcím használatával társít adatokat a felhasználóhoz, lehetetlen az adatokból kiindulni, és összekapcsolni azokat egy Microsoft Entra-azonosítójú felhasználóval.

Az alkalmazások a openid hatókör használatával kérhetnek azonosító jogkivonatot a Microsoft Identitásplatform. Az OIDC szabvány szabályozza a openid hatókört az azonosító jogkivonat formátumával és tartalmával együtt. Az OIDC a következő hatóköröket adja meg:

  • openid A hatókör használatával jelentkezzen be a felhasználóba, és adjon hozzá jogcímet sub az azonosító jogkivonatához. Ezek a hatókörök olyan felhasználói azonosítót biztosítanak, amely egyedi az alkalmazás és a felhasználó számára, és meghívja a UserInfo végpontot.
  • A email hatókör hozzáad egy email jogcímet, amely a felhasználó e-mail-címét tartalmazza az azonosító jogkivonatához.
  • A profile hatókör a felhasználó alapvető profilattribútumaival (név, felhasználónév) rendelkező jogcímeket ad hozzá az azonosító jogkivonathoz.
  • A offline_access hatókör lehetővé teszi, hogy az alkalmazás akkor is hozzáférhessen a felhasználói adatokhoz, ha a felhasználó nincs jelen.

A Microsoft Authentication Library (MSAL) mindig hozzáadja a megnyitási azonosítót, az e-maileket és profile a hatóköröket minden jogkivonat-kéréshez. Ennek eredményeképpen az MSAL mindig egy azonosító jogkivonatot és egy hozzáférési jogkivonatot ad vissza minden híváshoz vagy AcquireTokenInteractive-hez AcquireTokenSilent . Az MSAL mindig a hatókört offline_access kéri. A Microsoft Identitásplatform mindig akkor is visszaadja a hatókörtoffline_access, ha a kérelmező alkalmazás nem adja meg a hatókörtoffline_access.

A Microsoft az OAuth2 szabványt használja hozzáférési jogkivonatok kiállításához. Az OAuth2 szabvány azt mondja, hogy jogkivonatot kap, de nem adja meg a jogkivonat formátumát, illetve azt, hogy minek kell lennie a jogkivonatban. Ha az alkalmazásnak hozzá kell férnie egy, a Microsoft Entra ID által védett erőforráshoz, az erőforrás által meghatározott hatókört kell használnia.

A Microsoft Graph például meghatározza a User.Read hatókört, amely engedélyezi az alkalmazás számára az aktuális felhasználó teljes felhasználói profiljának és a bérlő nevének elérését. A Microsoft Graph az ADOTT API-ban elérhető funkciók teljes skálájára vonatkozó engedélyeket határoz meg.

Engedélyezéskor a Microsoft Identitásplatform egy hozzáférési jogkivonatot ad vissza az alkalmazásnak. Amikor meghívja az erőforrást, az alkalmazás ezt a jogkivonatot a HTTP-kérés engedélyezési fejlécének részeként biztosítja az API-nak.

Jogkivonatok élettartamának kezelése

Az alkalmazások létrehozhatnak egy munkamenetet a felhasználó számára, miután a hitelesítés sikeresen befejeződött a Microsoft Entra-azonosítóval. A felhasználói munkamenet-kezelés határozza meg, hogy a felhasználónak milyen gyakran van szüksége újrahitelesítésre. Az a szerepe, hogy egy kifejezetten ellenőrzött felhasználót a megfelelő jogosultsággal és a megfelelő időtartamig az alkalmazás előtt tartson. A munkamenet élettartamának az exp azonosító jogkivonatában szereplő jogcímen kell alapulnia. A exp jogcím az az időpont, amikor az azonosító jogkivonata lejár, és az az idő, amely után már nem használhatja a jogkivonatot a felhasználó hitelesítéséhez.

Mindig tartsa tiszteletben a jogkivonat élettartamát a hozzáférési jogkivonatokra vagy az exp azonosító jogkivonatban található jogcímre adott jogkivonat válaszában megadottak szerint. A jogkivonat élettartamát szabályozó feltételek magukban foglalhatják a vállalat bejelentkezési gyakoriságát. Az alkalmazás nem tudja konfigurálni a jogkivonat élettartamát. A jogkivonat élettartama nem kérhető.

A jogkivonatoknak általában érvényesnek és nem használhatónak kell lenniük. A célközönség jogcímének (aud) meg kell egyeznie az ügyfél-azonosítójával. Győződjön meg arról, hogy a jogkivonat megbízható kiállítótól származik. Ha több-bérlős API-val rendelkezik, úgy is szűrhet, hogy csak bizonyos bérlők hívhassák meg az API-t. Győződjön meg arról, hogy érvényesíti a jogkivonat élettartamát. Ellenőrizze a nbf (nem korábbi) és a exp (lejárati) jogcímeket, hogy az aktuális idő a két jogcím értékein belül legyen.

Ne törekedjenek a kivételesen hosszú vagy rövid munkamenetek élettartamára. Hagyja, hogy a megadott azonosító-jogkivonat életre szóló döntés legyen. Ha az alkalmazás munkamenetei a jogkivonat érvényességén túl aktívak maradnak, azzal megsértik azokat a szabályokat, szabályzatokat és aggodalmakat, amelyek miatt a rendszergazda a jogkivonatok érvényességi időtartamának beállítására hajtotta a jogkivonatok érvényességének időtartamát a jogosulatlan hozzáférés megakadályozása érdekében. A rövid munkamenetek rontják a felhasználói élményt, és nem feltétlenül növelik a biztonsági helyzetet. Az olyan népszerű keretrendszerek, mint a ASP.NET lehetővé teszik munkamenetek és cookie-időkorlátok beállítását a Microsoft Entra ID azonosító jogkivonatának lejárati idejéből. Az identitásszolgáltató jogkivonatának lejárati idejének követése biztosítja, hogy a felhasználó munkamenetei soha ne legyenek hosszabbak az identitásszolgáltató által diktált szabályzatoknál.

Jogkivonatok gyorsítótárazása és frissítése

Ne felejtse el megfelelően gyorsítótárazza a jogkivonatokat. Az MSAL automatikusan gyorsítótárazza a jogkivonatokat, de a jogkivonatoknak élettartamuk van. Használjon jogkivonatokat az élettartamuk teljes hosszán keresztül, és megfelelően gyorsítótárazza őket. Ha ismételten ugyanazt a jogkivonatot kéri, a szabályozás miatt az alkalmazás kevésbé lesz válaszkész. Ha az alkalmazás visszaél a jogkivonat kiállításával, az új jogkivonatok alkalmazáshoz való kiállításához szükséges idő meghosszul.

Az MSAL-kódtárak kezelik az OAuth2 protokoll részleteit, beleértve a frissítési jogkivonatok mechanikát is. Ha nem MSAL-t használ, győződjön meg arról, hogy a választott kódtár hatékonyan használja a frissítési jogkivonatokat.

Amikor az ügyfél hozzáférési jogkivonatot szerez be egy védett erőforrás eléréséhez, egy frissítési jogkivonatot kap. A frissítési jogkivonat használatával új hozzáférési/frissítési jogkivonatpárokat szerezhet be az aktuális hozzáférési jogkivonat lejárata után. A frissítési jogkivonatokkal további hozzáférési jogkivonatokat szerezhet be más erőforrásokhoz. A frissítési jogkivonatok a felhasználó és az ügyfél kombinációjához vannak kötve (nem erőforráshoz vagy bérlőhöz). A frissítési jogkivonatokkal hozzáférési jogkivonatokat szerezhet be az erőforrások és bérlők bármely kombinációjában, ahol az alkalmazás rendelkezik engedélyekkel.

Jogkivonathibák és -hibák kezelése

Az alkalmazás soha nem kísérelheti meg ellenőrizni, dekódolni, megvizsgálni, értelmezni vagy megvizsgálni a hozzáférési jogkivonat tartalmát. Ezek a műveletek szigorúan az erőforrás API felelősségi körébe tartoznak. Ha az alkalmazás megpróbál megvizsgálni egy hozzáférési jogkivonat tartalmát, nagy valószínűséggel megszakad az alkalmazás, amikor a Microsoft Identitásplatform titkosított jogkivonatokat ad ki.

A jogkivonat lekérésére irányuló hívás ritkán meghiúsulhat olyan problémák miatt, mint a hálózat, az infrastruktúra vagy a hitelesítési szolgáltatás hibája vagy leállása. A következő ajánlott eljárások követésével növelheti a hitelesítési élmény rugalmasságát az alkalmazásban, ha jogkivonat-beszerzés meghiúsul:

  • Helyi gyorsítótár és biztonságos jogkivonatok titkosítással.
  • Ne adjon át biztonsági összetevőket, például jogkivonatokat a nem biztonságos csatornákon.
  • Az identitásszolgáltatótól érkező kivételek és szolgáltatásválaszok megismerése és kezelése.

A fejlesztőknek gyakran merülnek fel kérdések a jogkivonatok között a hibakereséshez, például 401-et kapnak az erőforrás meghívása során. Mivel a titkosítottabb jogkivonatok megakadályozzák a hozzáférési jogkivonatok keresését, alternatív megoldásokat kell találnia a hozzáférési jogkivonatokban való kereséshez. A hibakereséshez a hozzáférési jogkivonatot tartalmazó jogkivonat-válasz megadja a szükséges információkat.

A kódban az egyes hibaesetek helyett ellenőrizze a hibaosztályokat. Kezelje például a szükséges felhasználói beavatkozást, nem pedig azokat az egyéni hibákat, amelyek esetében a rendszer nem adott engedélyt. Mivel előfordulhat, hogy ezek az egyedi esetek hiányoznak, jobb, ha egy osztályozót, például a felhasználói interakciót keres, nem pedig az egyes hibakódokat.

Előfordulhat, hogy vissza kell esnie, AcquireTokenInteractive és meg kell adnia a jogcímekkel kapcsolatos kihívásokat, amelyeket a AcquireTokenSilent hívás igényel. Ez biztosítja az interaktív kérés hatékony kezelését.

Következő lépések