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

Felhasználók hitelesítése Teljes felügyelet

  • Cikk

Ez a cikk fejlesztőként segít elsajátítani az alkalmazás felhasználóinak hitelesítésével kapcsolatos ajánlott eljárásokat Teljes felügyelet alkalmazásfejlesztés során. Mindig növelje az alkalmazás biztonságát a minimális jogosultság Teljes felügyelet alapelveivel, és ellenőrizze explicit módon.

Azonosító jogkivonatok a felhasználói hitelesítésben

Ha szüksége van egy felhasználóra, hogy hitelesítést végezzen az alkalmazáson a felhasználónév és a jelszó gyűjtése helyett, az alkalmazás kérheti az identitás (ID) jogkivonatot. A felhasználók Microsoft Identitásplatform keresztüli hitelesítése elkerüli azokat a biztonsági kockázatokat, amelyek akkor merülnek fel, amikor az alkalmazás megőrzi a felhasználói hitelesítő adatokat. Ha azonosító jogkivonatokat kér, ha egy hibás szereplő megsérti vagy megsérti az alkalmazást, az alkalmazásban nincsenek felhasználónevek és a hozzájuk tartozó jelszavak.

Az Microsoft Identitásplatform azonosító jogkivonat az OpenID Connect (OIDC) szabvány része, amely JSON-webjogkivonatként (JWT) adja meg az azonosító jogkivonatokat. A JWT hosszú sztring három összetevőből áll:

  1. Fejléc jogcímek. Az azonosító jogkivonatokban található fejlécjogcímek közé tartozik typ a (típusjogkivonat), alg (a jogkivonat aláírására szolgáló algoritmus) és kid (a nyilvános kulcs ujjlenyomata a jogkivonat aláírásának ellenőrzéséhez).
  2. Hasznos adat jogcímek. A hasznos adat vagy törzs (egy JSON-webes jogkivonat középső része) névattribútum-párok sorozatát tartalmazza. A szabvány megköveteli, hogy a jogkivonatot kibocsátó alkalmazáshoz (a iss kiállító nevéhez) tartozó jogcím (a audcélközönség jogcíme) legyen.
  3. Aláírás. A Microsoft Entra ID létrehozza azt a jogkivonat-aláírást, amellyel az alkalmazások ellenőrizhetik, hogy a jogkivonat nincs-e módosítva, és ön megbízhat benne.

Az alábbi példa egy azonosító jogkivonatra a felhasználó adatait mutatja be, és megerősíti az alkalmazás használatához szükséges hitelesítést.

{
  "typ": "JWT",
  "alg": "RS256",
  "kid": "1LTMzakihiRla_8z2BEJVXeWMqo"
}.
{
  "ver": "2.0",
  "iss": "https://login.microsoftonline.com/3338040d-6c67-4c5b-b112-36a304b66dad/v2.0",
  "aud": "00001111-aaaa-2222-bbbb-3333cccc4444",
  "exp": 1536361411,
  "iat": 1536274711,
  "nbf": 1536274711,
  "sub": "AAAAAAAAAAAAAAAAAAAAAIkzqFVrSaSaFHy782bbtaQ",
  "name": "Abe Lincoln",
  "preferred_username": "AbeLi@microsoft.com",
  "oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
  "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee",
}.
.[Signature]

Azonosító jogkivonatok a hozzáférés-kezelésben

Az alkalmazás (ügyfél) azonosítójának fogadásához regisztrálja az alkalmazást a Microsoft Identitásplatform. Amikor olyan célközönség-jogcímet (aud) kap, amely megfelel az alkalmazás ügyfélazonosítójának, a jogkivonat azonosított felhasználója hitelesítve lesz az alkalmazás számára. A rendszergazdák engedélyezhetik, hogy a bérlő összes felhasználója használja az alkalmazást. Engedélyezhetik, hogy egy olyan csoport, amelynek a felhasználó tagja, használja az alkalmazást.

Ha olyan jogkivonatot kap, amelynek célközönség-jogcíme eltér az alkalmazás ügyfélazonosítójától, azonnal utasítsa el a jogkivonatot. A felhasználót nem hitelesíti az alkalmazás, mert bejelentkezett egy másik alkalmazásba. Mindig győződjön meg arról, hogy a felhasználó rendelkezik engedéllyel az alkalmazás használatára.

Ezek a jogcímadatok fontosak a felhasználói hitelesítésben:

  • A JSON webes jogkivonat érvényes, amíg el nem jár. A exp (lejárati) jogcím jelzi, hogy mikor jár le a jogkivonat. Ha az aktuális idő a jogcímben szereplő exp idő előtt van, a jogkivonat érvényes.
  • Ne tekintse a felhasználót hitelesítettnek a (nem idő előtti) jogcímben nbf megadott időpont előtt. A nbf jogkivonat és exp az időpontok határozzák meg a jogkivonat érvényes élettartamát. Ha a lejárati idő közelgő, győződjön meg arról, hogy új azonosító jogkivonatot kap.
  • A sub (tulajdonosi jogcím) egy alkalmazásfelhasználó egyedi azonosítója. Ugyanaz a felhasználó más sub jogcímekkel rendelkezik más alkalmazásokhoz. Ha olyan adatokat szeretne tárolni, amelyek vissza lesznek rendelve egy felhasználóhoz, és megakadályozzák a támadók számára a társítás létrejöttét, használja a tulajdonosi jogcímet. Mivel nem teszi elérhetővé a felhasználó Microsoft Entra-identitását, ez a legszemélyesebb módja az adatok felhasználóhoz való társításának. A sub jogcím nem módosítható.
  • Ha több alkalmazás adatait szeretné megosztani, használja a bérlőazonosító (tid) és az objektumazonosító (oid) jogcímek kombinációját, amelyek egyediek a felhasználó számára. A kombinált bérlőazonosító és objektumazonosító nem módosítható.
  • Nem számít, mi történik az egyén identitásával, a sub, oidés tid a jogcímek nem módosíthatók. A felhasználóval kapcsolatos bármi megváltozhat, és továbbra is lekulccsal azonosíthatja a felhasználót a tárgy vagy az egyesített tid jogcímek alapján oid .

Hitelesítés OIDC-vel

A felhasználói hitelesítés bemutatásához tekintsük át azokat az alkalmazásokat, amelyek OIDC-t használnak a felhasználó hitelesítéséhez. Ugyanezek az elvek vonatkoznak a Security Assertion Markup Language (SAML) vagy a WS-Federation nyelvet használó alkalmazásokra is.

Az alkalmazás hitelesíti a felhasználót, amikor az alkalmazás egy azonosító jogkivonatot kér a Microsoft Identitásplatform. Ezt a lépést kihagyják a számítási feladatok (olyan alkalmazások, amelyekben nincsenek felhasználók, hanem inkább szolgáltatásokként, háttérfolyamatokként, démonokként futnak).

Először mindig csendesen kérje ezt a jogkivonatot. Ha csendesen szeretne jogkivonatot beszerezni a Microsoft Authentication Librariesben (MSAL), az alkalmazás a metódussal AcquireTokenSilent kezdhet. Ha az alkalmazás anélkül tud hitelesíteni, hogy megzavarná a felhasználót, megkapja a kért azonosító jogkivonatot.

Ha a Microsoft Identitásplatform nem tudja befejezni a kérést a felhasználóval való interakció nélkül, akkor az alkalmazásnak vissza kell esnie az MSAL AcquireTokenInteractive metódusra. A jogkivonat interaktív beszerzéséhez hajtsa végre a kérést úgy, hogy megnyit egy webes felületet a https://login.microsoftonline.com tartomány egy címére.

Ezen a webes felületen a felhasználó privát beszélgetést folytatott a Microsoft Identitásplatform. Az alkalmazás nem tekinti meg ezt a beszélgetést, és nem is rendelkezik a beszélgetés irányításával. A Microsoft Identitásplatform kérhet felhasználói azonosítót és jelszót, többtényezős hitelesítést (MFA), jelszó nélküli hitelesítést vagy más hitelesítési beavatkozást, amelyet a rendszergazda vagy a felhasználó konfigurált.

Az alkalmazás egy azonosító jogkivonatot kap, miután a felhasználó végrehajtotta a szükséges hitelesítési lépéseket. Amikor az alkalmazás megkapja a jogkivonatot, biztos lehet abban, hogy a Microsoft Identitásplatform hitelesítette a felhasználót. Ha az alkalmazás nem kap azonosító jogkivonatot, a Microsoft Identitásplatform nem hitelesítette a felhasználót. Ne engedélyezze a hitelesítés nélküli felhasználók számára, hogy az alkalmazás biztonságos területeire lépjenek.

Ajánlott, hogy az alkalmazások munkamenetet hozzanak létre egy felhasználó számára, miután megkapta az azonosító jogkivonatát a Microsoft Entra-azonosítótól. Az alkalmazás által kapott azonosító jogkivonatban egy lejárati (exp) jogcím unix-időbélyeggel. Ez az időbélyeg azt a lejárati időt adja meg, amelyre az alkalmazásnak nem szabad elfogadnia a JWT-t feldolgozásra. Használja ezt a jogkivonat lejárati idejét a felhasználói munkamenetek élettartamának meghajtásához. A exp jogcím kulcsfontosságú szerepet játszik abban, hogy egy kifejezetten ellenőrzött felhasználó a megfelelő jogosultsággal és a megfelelő ideig legyen az alkalmazás előtt.

Egyszeri bejelentkezés támogatás

Az egyszeri bejelentkezési (SSO) hitelesítés lehetővé teszi a felhasználók számára, hogy egy hitelesítő adatokkal jelentkezzenek be több független szoftverrendszerbe. Az egyszeri bejelentkezés lehetővé teszi, hogy az alkalmazásfejlesztők ne követelik meg, hogy egy felhasználó külön-külön és ismétlődően jelentkezzen be minden alkalmazásba. Az egyszeri bejelentkezés lényege, hogy a fejlesztők biztosítják, hogy a felhasználó eszközén található összes alkalmazás megossza a felhasználót hitelesíteni hivatott webes felületet. A webes felületen található összetevők (például munkamenet-állapot és cookie-k) a sikeres hitelesítési meghajtó egyszeri bejelentkezése után.

Az alábbi ábrán látható módon a megosztott webes felületek legegyszerűbb használati esete egy webböngészőben futó alkalmazás (például Microsoft Edge, Google Chrome, Firefox, Safari). A böngészőlapok megosztják az egyszeri bejelentkezés állapotát.

Az ábra azt a megosztott webes felületet mutatja be, amelyben egy alkalmazás böngészőben fut.

A Microsoft Identitásplatform egy adott böngészőben kezeli az egyszeri bejelentkezés állapotát, kivéve, ha a felhasználó különböző böngészőket nyit meg ugyanazon az eszközön. Windows 10 és újabb rendszereken a Microsoft Identitásplatform natív módon támogatja a microsoft edge böngészős egyszeri bejelentkezést. Amikor a felhasználó bejelentkezett a Windowsba, a Google Chrome-ban (a Windows 10-fiókbővítményen keresztül) és a Mozilla Firefox v91+ böngészőben (böngészőbeállításon keresztül) lévő szállások lehetővé teszik, hogy minden böngésző megossza a Windows SSO-állapotát.

Az alábbi ábrán látható módon a natív alkalmazáshasználati eset bonyolultabb.

Az ábrán az SSO nélküli beágyazott böngészők bonyolult natív alkalmazáshasználati esete látható.

Hitelesítési közvetítő megközelítése

Gyakori példa, hogy minden natív alkalmazásnak saját beágyazott WebView-jával kell rendelkeznie, amely megakadályozza, hogy részt vegyen az egyszeri bejelentkezésben. Ennek a forgatókönyvnek a megoldásához a Microsoft Entra ID hitelesítési közvetítőt (hitelesítésközvetítőt) használ natív alkalmazásokhoz az alábbi ábrán látható módon.

Az ábra a hitelesítési közvetítők natív alkalmazásokhoz való használatát mutatja be.

Ha egy hitelesítési közvetítő van érvényben, az alkalmazások hitelesítési kéréseket küldenek a közvetítőnek, nem pedig közvetlenül a Microsoft Identitásplatform. Ily módon a közvetítő lesz az eszköz összes hitelesítésének megosztott felülete.

A megosztott felület biztosítása mellett a hitelesítési közvetítő más előnyöket is biztosít. A Teljes felügyelet bevezetésekor előfordulhat, hogy a vállalatok csak vállalati felügyelt eszközökről szeretnének alkalmazásokat futtatni. A nagyvállalati eszközök felügyeletére példa a teljes mobil Eszközkezelés (MDM) és az olyan forgatókönyvek, amelyekben a felhasználók a mobilalkalmazás-kezelésben (MAM) részt vevő saját eszközeiket használják.

A mögöttes operációs rendszerek (OS) kialakításuk szerint elkülönítik a böngészőket. A fejlesztőknek szorosabb kapcsolatra van szükségük az operációs rendszerrel az eszköz részleteihez való teljes hozzáféréshez. A Windowsban a hitelesítési közvetítő a Windows Web Account Manager (WAM). Más eszközökön a hitelesítési közvetítő a Microsoft Authenticator alkalmazás (iOS vagy Android rendszerű eszközök esetén) vagy a Céges portál alkalmazás (Android rendszerű eszközök esetén). Az alkalmazások az MSAL használatával férnek hozzá a hitelesítési közvetítőhöz. Windows rendszerben az alkalmazások MSAL nélkül is hozzáférhetnek a WAM-hez. Az MSAL azonban a legegyszerűbb módja annak, hogy az alkalmazások elérhessék a hitelesítési közvetítőt (különösen azokat az alkalmazásokat, amelyek nem Univerzális Windows-platform alkalmazásokat).

A hitelesítésszervezők a Microsoft Entra-azonosítóval kombinálva használják az elsődleges frissítési jogkivonatokat (PRT), amelyek csökkentik a felhasználók számára a többszöri hitelesítés szükségességét. A PRT-k meg tudják állapítani, hogy a felhasználó felügyelt eszközön van-e. A Microsoft Entra ID-hoz hitelesítésszervezőkre van szükség, mivel a használat igazolása jogkivonatokat vezet be, ami biztonságosabb megoldás a ma elterjedt tulajdonosi jogkivonatokkal szemben.

Következő lépések