Hogyan biztosíthatja fejlesztőként, hogy Teljes felügyelet, ha van egy API, amelyet egy másik API-nak kell meghívnia? Ebben a cikkben megtudhatja, hogyan fejlesztheti biztonságosan az alkalmazást, amikor az egy felhasználó nevében dolgozik.
Amikor egy felhasználó egy alkalmazás felhasználói felületét használja, az alkalmazás delegált engedélyt használhat, hogy az API tudja, melyik felhasználó nevében dolgozik az alkalmazás. Megvizsgálná a tulajdonosi (al)jogcímet vagy objektumazonosítót (oid) és bérlőazonosítót (tid) a hozzáférési jogkivonatban, amelyet az alkalmazás az API meghívásakor biztosít. Az API nem támaszkodna a nem megbízható alkalmazásra, ami csak egy hívás, amely a hálózaton belülről érkezik. Ehelyett érvényesítené a jogkivonatot, hogy az API csak annak az alkalmazásfelhasználónak a nevében működjön, amelyet a Microsoft Entra ID ellenőrzött.
Amikor egy API (az Eredeti API-ként hivatkozunk rá) meghív egy másikat, létfontosságú, hogy a meghívni kívánt API (a downstream API-ként hivatkozunk rá) kövesse a fent leírt ellenőrzési folyamatot. A Downstream API nem támaszkodhat nem megbízható hálózati forrásra. A felhasználói identitást megfelelően érvényesített hozzáférési jogkivonatból kell lekérnie.
Ha a Downstream API nem követi a megfelelő érvényesítési folyamatot, a Downstream API-nak az Eredeti API-ra kell támaszkodnia, hogy más módon biztosítsa a felhasználó identitását. Előfordulhat, hogy a Downstream API helytelenül használ alkalmazásengedélyt a művelet végrehajtásához. Ezután az Eredeti API lesz az egyetlen hatóság, amely felett a felhasználók elérnék a downstream API-val szembeni eredményeket. Az eredeti API szándékosan (vagy akaratlanul) lehetővé teheti a felhasználó számára egy olyan feladat elvégzését, amelyet a felhasználó egyébként nem tudott elvégezni. Az egyik felhasználó módosíthatja például egy másik felhasználó adatait, vagy elolvashatja és frissítheti azokat a dokumentumokat, amelyekhez a felhasználó nem rendelkezik hozzáférési engedéllyel. A nem megfelelő ellenőrzés súlyos biztonsági problémákat okozhat.
A nagyobb biztonság érdekében az Eredeti API egy delegált jogosultsági hozzáférési jogkivonatot szerez be a Downstream API számára a hívás során. Nézzük meg, hogyan működik ez.
Az ügyfélalkalmazás hozzáférési jogkivonatot szerez be az Eredeti API meghívásához
Az alábbi ábra a bal oldali Ügyfélalkalmazást és a jobb oldalon az Eredeti API-t mutatja.
Az ügyfélalkalmazás beszerzett egy delegált engedélyhozzáférés-jogkivonatot (amelyet a pentagon alakzat "A" címkével jelöl) az Eredeti API-hoz. A delegált engedélyhozzáférési jogkivonat lehetővé teszi, hogy a felhasználó nevében működve meghívja az engedélyezést igénylő eredeti API-t.
Az ügyfélalkalmazás hozzáférési jogkivonatot biztosít az Eredeti API-hoz
Az alábbi animáció azt mutatja be, hogy az ügyfélalkalmazás megadja a hozzáférési jogkivonatot az Eredeti API-nak. Az Eredeti API teljes mértékben ellenőrzi és megvizsgálja a hozzáférési jogkivonatot az ügyfélalkalmazás felhasználójának identitásának meghatározásához.
Az eredeti API jogkivonat-érvényesítési és -kényszerítési műveleteket hajt végre
A következő animáció azt mutatja be, hogy miután az Ügyfélalkalmazás megadta a hozzáférési jogkivonatot az Eredeti API-nak, az Eredeti API jogkivonat-érvényesítést és kényszerítést hajt végre. Ha minden rendben van, az API folytatja és kiszolgálja az ügyfélalkalmazásra vonatkozó kérést.
Az eredeti API nem tud hozzáférési jogkivonatot használni a Downstream API meghívásához
Az alábbi animáció azt mutatja be, hogy az Eredeti API most egy downstream API-t szeretne meghívni. Az Eredeti API azonban nem tudja használni a hozzáférési jogkivonatot a Downstream API meghívásához.
Az eredeti API visszatér a Microsoft Entra-azonosítóhoz
Az alábbi animációban az Eredeti API-nak vissza kell lépnie a Microsoft Entra-azonosítóhoz. Hozzáférési jogkivonatra van szüksége ahhoz, hogy meghívja a Downstream API-t a felhasználó nevében.
A következő animáció az Eredeti API-t mutatja be, amely az eredeti API által az ügyfélalkalmazástól kapott jogkivonatot és az eredeti API ügyfél-hitelesítő adatait tartalmazza.
A Microsoft Entra ID ellenőrzi az olyan dolgokat, mint a hozzájárulás vagy a feltételes hozzáférés érvényesítése. Előfordulhat, hogy vissza kell mennie a hívó ügyfélhez, és meg kell adnia annak okát, hogy nem tudja lekérni a jogkivonatot. Általában egy jogcím-kihívási folyamatot használva visszatérhet a hívó alkalmazáshoz a nem fogadott hozzájárulásra vonatkozó információkkal (például feltételes hozzáférési szabályzatokkal).
A Microsoft Entra ID ellenőrzéseket végez
Az alábbi animációban a Microsoft Entra ID elvégzi az ellenőrzéseket. Ha minden rendben van, a Microsoft Entra ID egy hozzáférési jogkivonatot ad ki az eredeti API-hoz, hogy meghívja a Downstream API-t a felhasználó nevében.
Az eredeti API felhasználói környezettel rendelkezik a folyamat nevében
Az alábbi animáció bemutatja a folyamat nevében ( OBO) folyamatot, amely lehetővé teszi, hogy az API továbbra is a felhasználói környezettel rendelkezzen a Downstream API meghívása során.
A következő animációban a Downstream API-t hívjuk meg. A Downstream API által kapott jogkivonat rendelkezik a megfelelő célközönségi (aud) jogcímvel, amely a Downstream API-t jelzi.
A jogkivonat tartalmazza a megadott hozzájárulás hatóköreit és az alkalmazás eredeti felhasználói identitását. A Downstream API megfelelően képes érvényes engedélyeket implementálni annak biztosítása érdekében, hogy az azonosított felhasználó rendelkezik engedéllyel a kért feladat végrehajtásához. A folyamat nevében érdemes jogkivonatokat beszerezni egy API-hoz, hogy meghívjon egy másik API-t, hogy a felhasználói környezet minden alárendelt API-nak át legyen kapcsolva.
Legjobb lehetőség: Az eredeti API a folyamat nevében hajtja végre a folyamatot
Ez az utolsó animáció azt mutatja be, hogy a legjobb megoldás az eredeti API-nak az on-behalf-of flow (OBO) végrehajtása. Ha a Downstream API megkapja a megfelelő jogkivonatot, képes lesz megfelelően válaszolni.
Ha egy API egy felhasználó nevében jár el, és egy másik API-t kell meghívnia, az API-nak az OBO használatával kell beszereznie egy delegált jogosultsági hozzáférési jogkivonatot a downstream API felhasználó nevében történő meghívásához. Az API-k soha nem használhatnak alkalmazásengedélyeket a downstream API-k meghívására, amikor az API egy felhasználó nevében jár el.
Az API Protection ismerteti az API regisztrációval, engedélyek és hozzájárulások meghatározásával, valamint a hozzáférés kényszerítésével kapcsolatos ajánlott eljárásokat a Teljes felügyelet célok elérése érdekében.
A jogkivonatok testreszabása ismerteti a Microsoft Entra-jogkivonatokban kapott információkat, valamint azt, hogy hogyan szabhatja testre a jogkivonatokat a rugalmasság és a szabályozás javítása érdekében, miközben a minimális jogosultsággal rendelkező, az alkalmazás zéró megbízhatósági biztonságát növeli.
Az alkalmazástulajdonságok biztonsági ajánlott eljárásai az átirányítási URI-t, a hozzáférési jogkivonatokat (implicit folyamatokhoz), a tanúsítványokat és titkos kulcsokat, az alkalmazásazonosító URI-t és az alkalmazás tulajdonjogát ismertetik.
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: