A hitelesítést delegálhatja egy külső identitásszolgáltatónak. Ezzel leegyszerűsítheti a fejlesztést, minimalizálhatja a szükséges felhasználói adminisztrációt és javíthatja az alkalmazás felhasználói élményét.
Kontextus és probléma
A felhasználóknak általában több, különböző üzleti partner által biztosított és üzemeltetett alkalmazást kell használniuk. Előfordulhat, hogy ezeknek a felhasználóknak mindegyikhez adott (eltérő) hitelesítő adatokat kell használniuk. Mindez:
Nem egységes felhasználói élményt okozhat. A felhasználók gyakran elfelejtik a bejelentkezési hitelesítő adataikat, ha sok különböző adatot kell kezelniük.
Biztonsági réseket idézhet elő. Ha egy felhasználó kilép a cégtől, a fiókját azonnal meg kell szüntetni. Nagy cégeknél erről könnyű megfeledkezni.
Bonyolítja a felhasználókezelést. A rendszergazdáknak kell kezelniük az összes felhasználó hitelesítő adatait, és pluszfeladatokat (például jelszó-emlékeztetők küldését) kell elvégezniük.
A felhasználók általában jobban szeretnék ugyanazokat a hitelesítő adatokat használni az összes alkalmazáshoz.
Megoldás
Használjon összevont identitás használatára képes hitelesítési mechanizmust. Különítse el a felhasználói hitelesítést az alkalmazáskódtól, és delegálja a hitelesítést egy megbízható identitásszolgáltatóra. Ezzel leegyszerűsítheti a fejlesztést, és lehetővé teheti, hogy a felhasználók szélesebb palettáról válasszanak identitásszolgáltatót a hitelesítéshez, és közben a lehető legkisebbre csökkentsék az adminisztratív terhelést. Azt is lehetővé teszi, hogy egyértelműen elválassza a hitelesítést az engedélyezéstől.
A megbízható identitásszolgáltatók között vannak céges címtárak, helyszíni összevonási szolgáltatások, külső üzleti partnerek által biztosított biztonsági jegykiadó szolgáltatások (STS), vagy éppen közösségi identitásszolgáltatók, amelyek képesek kezelni például a Microsoft-, Google-, Yahoo!- vagy Facebook-fiókkal rendelkező felhasználók hitelesítését.
Az ábra az összevont identitás mintáját mutatja be, amikor egy ügyfélnek épp egy hitelesítést igénylő szolgáltatáshoz kell hozzáférnie. A hitelesítést egy STS-sel együttműködő identitásszolgáltató hajtja végre. Az identitásszolgáltató a hitelesített felhasználóról információt szolgáltató biztonsági jogkivonatokat ad ki. Ezek az jogcímekként ismert információk magukban foglalják a felhasználó identitását, és egyéb információkat is tartalmazhatnak, például a szerepkör-tagságot és a részletesebb hozzáférési jogosultságokat.
Ezt a modellt gyakran nevezik jogcímalapú hozzáférés-vezérlésnek. Az alkalmazások és a szolgáltatások a jogkivonatban található jogcímek alapján engednek hozzáférést a szolgáltatásokhoz és funkciókhoz. A hitelesítést igénylő szolgáltatásnak meg kell bíznia az identitásszolgáltatóban. Az ügyfélalkalmazás kapcsolatba lép a hitelesítést elvégző identitásszolgáltatóval. Ha a hitelesítés sikeres, az identitásszolgáltató a felhasználót azonosító jogcímeket tartalmazó jogkivonatot ad vissza az STS-nek (tartsa szem előtt, hogy az identitásszolgáltató és az STS lehet ugyanaz a szolgáltatás is). Az STS az ügyfélnek való visszaadás előtt előre meghatározott szabályok alapján átalakíthatja és kiegészítheti a jogcímeket. Az ügyfélalkalmazás ezután továbbíthatja ezt a jogkivonatot a szolgáltatásnak az identitása bizonyítékaként.
A megbízhatósági láncban további biztonsági jogkivonat-szolgáltatások is lehetnek. A később ismertetett forgatókönyvben például egy helyszíni STS megbízik egy másik, a felhasználó hitelesítése céljából egy identitásszolgáltatóhoz való hozzáférésért felelős STS-ben. Ez a megközelítés gyakori nagyvállalati forgatókönyvekben, ahol van helyszíni STS és címtár is.
Az összevont hitelesítés szabványalapú megoldást nyújt a különböző tartományokban található identitásokba fektetett bizalom problémájára, és képes az egyszeri bejelentkezés támogatására. Ez a hitelesítési típus egyre gyakoribb minden típusú alkalmazásban, különösen a felhőalapú alkalmazásokban, mivel az egyszeri bejelentkezést támogatja anélkül, hogy közvetlen hálózati kapcsolatot kellene létesítenie az identitásszolgáltatókkal. A felhasználónak nem kell minden alkalmazáshoz megadnia a hitelesítő adatait. Ez növeli a biztonságot, mivel megakadályozza a számos különböző alkalmazás eléréséhez szükséges hitelesítő adatok létrehozását, és elrejti a felhasználó hitelesítő adatait az eredeti identitásszolgáltatón kívül mindenki elől. Az alkalmazások csak a jogkivonatban található hitelesített identitásadatokat látják.
Az összevont identitásnak az is nagy előnye, hogy az identitás és a hitelesítő adatok kezelése az identitásszolgáltató felelőssége. Az alkalmazásnak vagy szolgáltatásnak nem kell identitáskezelési funkciókat biztosítania. Ezenfelül céges forgatókönyvekben a céges címtárnak nem kell tudnia a felhasználóról, ha megbízik az identitásszolgáltatóban. Ezzel megszűnik a felhasználók identitásának címtáron belül való kezelésének adminisztratív terhe.
Problémák és megfontolandó szempontok
Összevont hitelesítést megvalósító alkalmazások tervezésekor vegye figyelembe az alábbiakat:
A hitelesítés kritikus hibapont lehet a rendszeren belül. Ha több adatközpontba telepíti az alkalmazását, érdemes lehet az identitáskezelő mechanizmust is telepíteni ugyanazokba az adatközpontokba, hogy megmaradjon az alkalmazás megbízhatósága és rendelkezésre állása.
A hitelesítési eszközök segítségével konfigurálható a hitelesítési jogkivonatban található szerepkörjogcímeken alapuló hozzáférés-vezérlés. Ezt gyakran nevezik szerepköralapú hozzáférés-vezérlésnek (RBAC), és részletesebb szintű hozzáférés-vezérlést tesz lehetővé a szolgáltatások és erőforrások vonatkozásában.
A céges címtáraktól eltérően a közösségi identitásszolgáltatókat használó jogcímalapú hitelesítés az e-mail-címen és esetleg a néven kívül általában nem ad meg más adatot a hitelesített felhasználóról. Néhány közösségi identitásszolgáltató – például egy Microsoft-fiók – csak egy egyedi azonosítót biztosít. Az alkalmazásnak általában kezelnie kell néhány adatot a regisztrált felhasználókról, és képesnek kell lennie megfeleltetni ezt az információt a jogkivonat jogcímeiben tárolt azonosítóval. Ezt általában a regisztráció során szerzi be, amikor a felhasználó először használja az alkalmazást, majd az adatok további jogcímekként kerülnek be a jogkivonatba az egyes hitelesítések után.
Ha az STS-hez több identitásszolgáltató van konfigurálva, az STS-nek meg kell határoznia, hogy melyik identitásszolgáltatóhoz kell átirányítani a felhasználót hitelesítés céljából. Ennek a folyamatnak a kezdőtartomány felderítése a neve. Előfordulhat, hogy az STS automatikusan meg tudja ezt tenni a felhasználó által megadott e-mail-cím vagy felhasználónév, a felhasználó által elért alkalmazás altartománya, a felhasználó IP-címtartománya vagy a felhasználó böngészőjében tárolt cookie tartalma alapján. Ha például a felhasználó egy Microsoft-tartományba eső e-mail-címet adott meg (pl.: user@live.com), az STS a felhasználót a Microsoft-fiók bejelentkezési oldalára irányítja át. A későbbi látogatások alkalmával az STS egy cookie segítségével jelezheti, hogy az utolsó bejelentkezés egy Microsoft-fiók segítségével történt. Ha az automatikus észlelés nem tudja meghatározni a kezdőtartományt, az STS megjelenít egy kezdőtartomány-felderítő oldalt, amely kilistázza a megbízható identitásszolgáltatókat, és a felhasználónak kell kiválasztania, melyiket szeretné igénybe venni.
Mikor érdemes ezt a mintát használni?
Ez a minta például az alábbi forgatókönyvek esetében lehet hasznos:
Egyszeri bejelentkezés a vállalatban. Ebben a forgatókönyvben az alkalmazottakat hitelesíteni kell a felhőben üzemeltetett, vállalati biztonsági határon kívül eső céges alkalmazásokhoz, de nem kell minden alkalommal bejelentkezniük, amikor használnak egy alkalmazást. A felhasználói élmény ugyanaz, mint a helyszíni alkalmazások használatakor, azaz a hitelesítés egy vállalati hálózatra való bejelentkezéskor történik, és onnantól bejelentkezés nélkül használható az összes releváns alkalmazás.
Összevont identitás több partnerrel. Ebben a forgatókönyvben a céges alkalmazottakat és a céges címtárban fiókkal nem rendelkező üzleti partnereket is hitelesítenie kell. Ez a gyakori a cégek közötti alkalmazások és a külső szolgáltatást integráló alkalmazások esetében, valamint olyan helyzetben, amely során különböző informatikai rendszert alkalmazó vállalatok egyesülnek vagy megosztják az erőforrásaikat.
Összevont identitás SaaS-alkalmazásokban. Ebben a forgatókönyvben független szoftvergyártók biztosítanak használatra kész szolgáltatást több ügyfélnek vagy bérlőnek. Mindegyik bérlő egy megfelelő identitásszolgáltató használatával végzi el a hitelesítést. Az üzleti felhasználók például a céges hitelesítő adatokat fogják használni, a bérlő felhasználói és ügyfelei pedig a közösségi identitásuk hitelesítő adatait.
Nem érdemes ezt a mintát használni a következő helyzetekben:
Az alkalmazás összes felhasználója hitelesíthető egy identitásszolgáltatóval, és nincs szükség más identitásszolgáltatóval való hitelesítésre. Ez olyan üzleti alkalmazásoknál gyakori, amelyek az alkalmazásból elérhető céges címtárat használnak hitelesítéshez VPN- vagy (felhőben futtatott forgatókönyvek esetében) a helyszíni címtár és az alkalmazás közötti kapcsolatot biztosító virtuális hálózati kapcsolaton keresztül.
Az alkalmazás eredetileg egy másik hitelesítési mechanizmussal készült, esetleg egyéni felhasználói tárolókkal, vagy nem képes kezelni a jogcímalapú technológiák által használt egyeztetési szabványokat. A jogcímalapú hitelesítés és hozzáférés-vezérlés meglévő alkalmazásokra történő alkalmazása összetett feladat, és valószínűleg nem túl költséghatékony.
Számítási feladatok tervezése
Az építészeknek értékelniük kell, hogyan használható az összevont identitásminta a számítási feladat kialakításában az Azure Well-Architected Framework pilléreiben foglalt célok és alapelvek kezelésére. Példa:
| Pillér | Hogyan támogatja ez a minta a pillércélokat? |
|---|---|
| A megbízhatósági tervezési döntések segítenek a számítási feladatnak ellenállóvá válni a hibás működéssel szemben, és biztosítani, hogy a hiba bekövetkezése után teljesen működőképes állapotba kerüljön. | A felhasználók felügyeletének és hitelesítésének kiszervezése az összetevők megbízhatóságát az identitásszolgáltatóra váltódik, amely általában magas SLO-t tartalmaz. Emellett a számítási feladatok vészhelyreállítása során a hitelesítési összetevőket valószínűleg nem kell kezelni a számítási feladatok helyreállítási tervének részeként. - RE:02 Kritikus folyamatok - RE:09 Vészhelyreállítás |
| A biztonsági tervezési döntések segítenek biztosítani a számítási feladatok adatainak és rendszereinek titkosságát, integritását és rendelkezésre állását. | A felhasználók felügyeletének és hitelesítésének külsősítésével fejlesztheti az identitásalapú fenyegetésészlelés és -megelőzés képességeit anélkül, hogy ezeket a képességeket implementálnia kellene a számítási feladatban. A külső identitásszolgáltatók pedig modern, interoperábilis hitelesítési protokollokat használnak. - Standard kiadás:02 Biztonságos fejlesztési életciklus - Standard kiadás:10 Monitorozás és fenyegetésészlelés |
| A teljesítményhatékonyság a skálázás, az adatok és a kód optimalizálásával segíti a számítási feladatok hatékony kielégítését . | A felhasználók felügyeletének és hitelesítésének kiszervezésekor az alkalmazás erőforrásait más prioritásoknak is szentelheti. - PE:03 Szolgáltatások kiválasztása |
Mint minden tervezési döntésnél, fontolja meg az ezzel a mintával bevezethető többi pillér céljaival szembeni kompromisszumokat.
Példa
A szervezetek több-bérlős szoftvereket üzemeltetnek szolgáltatásként (SaaS) a Microsoft Azure-ban. Az alkalmazás tartalmaz egy webhelyet, amelyet a bérlők használhatnak az alkalmazás a saját felhasználóik számára történő kezeléséhez. Az alkalmazás lehetővé teszi a bérlők számára a webhely elérését egy összevont identitás használatával, amelyet Active Directory összevonási szolgáltatások (AD FS) (AD FS) hoz létre, amikor a felhasználót a szervezet saját Active Directoryja hitelesíti.
Az ábra bemutatja, hogyan hitelesítik a bérlők a saját identitásszolgáltatójukat (1. lépés), ebben az esetben az AD FS-t. A bérlő sikeres hitelesítése után az AD FS jogkivonatot ad ki. Az ügyfélböngésző továbbítja ezt a jogkivonatot az SaaS-alkalmazás összevonási szolgáltatójának, amely megbízik a bérlő AD FS-je által kibocsátott jogkivonatokban, hogy vissza lehessen szerezni egy, az SaaS összevonási szolgáltatóra érvényes jogkivonatot (2. lépés). Ha szükséges, a SaaS összevonási szolgáltató a jogkivonatban található jogcímeket az új jogkivonat ügyfélböngészőnek való visszaadása előtt olyan jogcímekké alakítja, amelyeket az alkalmazás felismer (3. lépés). Az alkalmazás megbízik az SaaS összevonási szolgáltató által kiállított jogkivonatokban, és a jogkivonat jogcímeivel alkalmazza az engedélyezési szabályokat (4. lépés).
A bérlőknek nem kell külön hitelesítő adatokat megjegyeznie az alkalmazás eléréséhez, és a bérlő vállalatának rendszergazdája saját AD FS-ben konfigurálhatja az alkalmazáshoz hozzáférő felhasználók listáját.
Következő lépések
- Microsoft Entra ID
- Active Directory Domain Services
- Active Directory összevonási szolgáltatások
- Több-bérlős alkalmazások az Azure-ban