Active Directory Federation Services (AD FS): A szolgáltatás jelentése és szerepe az egyszeri bejelentkezés (SSO) megvalósításában

A modern digitális világban a felhasználók és az alkalmazások közötti interakciók száma exponenciálisan növekszik. Egy átlagos vállalat ma már nem csupán helyben futó, hagyományos alkalmazásokat használ, hanem felhőalapú szolgáltatások, SaaS (Software as a Service) megoldások és partnerek rendszereinek tucatjaival dolgozik. Ez a diverzifikált környezet, bár rendkívüli rugalmasságot és hatékonyságot kínál, komoly kihívásokat is támaszt, különösen az identitáskezelés és a hozzáférés-szabályozás terén. A felhasználóknak gyakran több tucat különböző jelszót és felhasználónevet kell megjegyezniük, ami frusztráló és egyben jelentős biztonsági kockázatot is jelent. Itt lép be a képbe az egyszeri bejelentkezés (SSO), amely forradalmasítja a felhasználói élményt és a biztonságot, és amelynek egyik kulcsfontosságú megvalósítási eszköze az Active Directory Federation Services (AD FS).

Az AD FS nem csupán egy egyszerű hitelesítési mechanizmus, hanem egy komplex, jogcím alapú identitáskezelési rendszer, amely hidat épít a belső vállalati identitás-tárolók és a külső, felhőalapú vagy partneri alkalmazások között. Lehetővé teszi, hogy a felhasználók egyszeri bejelentkezéssel hozzáférjenek a legkülönfélébb erőforrásokhoz, függetlenül attól, hogy azok hol helyezkednek el: a helyi hálózaton, egy másik vállalat infrastruktúrájában, vagy a felhőben. Ezáltal az AD FS kulcsszerepet játszik a modern, hibrid és multicloud IT-környezetek biztonságos és zökkenőmentes működésében.

Az AD FS nem csupán egy technológia, hanem egy stratégiai eszköz, amely lehetővé teszi a vállalatok számára, hogy kiterjesszék meglévő Active Directory identitásukat a felhőre és a partneri ökoszisztémákra, miközben fenntartják a központi irányítást és a biztonságot.

Mi az Active Directory Federation Services (AD FS)?

Az Active Directory Federation Services (AD FS) a Microsoft Windows Server operációs rendszer része, és egy olyan szolgáltatás, amely a jogcím alapú hitelesítést (claims-based authentication) valósítja meg. Lényegében lehetővé teszi, hogy a felhasználók egyetlen hitelesítési folyamat után hozzáférjenek több, egymástól független rendszerhez vagy alkalmazáshoz, anélkül, hogy minden egyes szolgáltatásnál újra be kellene jelentkezniük. Ez a képesség kulcsfontosságú az egyszeri bejelentkezés (SSO) megvalósításában, különösen olyan forgatókönyvekben, ahol a felhasználók identitásai egy helyi Active Directory Domain Services (AD DS) környezetben vannak tárolva, de hozzáférést igényelnek külső, felhőalapú vagy partneri alkalmazásokhoz.

Az AD FS alapvető célja, hogy megkönnyítse az identitás-összevonást (identity federation). Ez azt jelenti, hogy két vagy több szervezet (vagy egy szervezet különböző rendszerei) közötti bizalmi kapcsolatot hoz létre, amely lehetővé teszi a felhasználói identitások és attribútumok biztonságos cseréjét. Ennek eredményeként egy felhasználó, aki már hitelesítette magát az egyik szervezet rendszerében (az identitásszolgáltatóban), hozzáférhet a másik szervezet (a szolgáltató) erőforrásaihoz anélkül, hogy ott is újra hitelesítenie kellene magát.

Az AD FS működése a jogcímek koncepcióján alapul. A hagyományos hitelesítés során a felhasználó egy felhasználónevet és jelszót ad meg, amelyet a rendszer ellenőriz. A jogcím alapú hitelesítésnél az identitásszolgáltató (például az AD FS) a felhasználó sikeres hitelesítése után egy vagy több jogcímből álló biztonsági tokent (security token) állít ki. Ezek a jogcímek olyan kijelentések a felhasználóról, mint például a felhasználónév, e-mail cím, csoporttagság, szerepkörök, vagy bármilyen más attribútum, amely a hozzáférés szabályozásához szükséges. A szolgáltató (az alkalmazás, amelyhez a felhasználó hozzáférni szeretne) ezután ezt a tokent ellenőrzi, és a benne lévő jogcímek alapján dönti el, hogy engedélyezi-e a hozzáférést, és milyen jogosultságokkal.

Ez a megközelítés számos előnnyel jár. Először is, a szolgáltató alkalmazásnak nem kell közvetlenül hozzáférnie a felhasználók jelszavaihoz vagy a belső identitás-tárolóhoz, ami jelentősen növeli a biztonságot. Másodszor, a jogcímek rugalmasságot biztosítanak a hozzáférés-szabályozásban, lehetővé téve a részletes jogosultságok definiálását a felhasználói attribútumok alapján. Harmadszor, az AD FS támogatja a szabványos protokollokat, mint például a SAML 2.0 (Security Assertion Markup Language), a WS-Federation, az OAuth 2.0 és az OpenID Connect, biztosítva az interoperabilitást a különböző rendszerek között.

Az egyszeri bejelentkezés (SSO) kihívásai és az AD FS válasza

Az egyszeri bejelentkezés (SSO) az a képesség, hogy egy felhasználó egyszer hitelesíti magát egy rendszerben, és ezt követően anélkül férhet hozzá több, egymástól független alkalmazáshoz vagy szolgáltatáshoz, hogy újra be kellene jelentkeznie. Bár ez a koncepció egyszerűnek tűnik, a megvalósítása a modern, heterogén IT-környezetekben komoly kihívásokat rejt magában. Az AD FS pontosan ezekre a kihívásokra kínál robusztus és skálázható megoldást.

Az SSO hiánya számos problémát okozhat egy szervezet számára. A legnyilvánvalóbb a felhasználói frusztráció és a termelékenység csökkenése. A felhasználóknak gyakran több tucat különböző felhasználónevet és jelszót kell megjegyezniük, ami folyamatos jelszó-visszaállítási kérésekhez vezet, terhelve az IT-támogatást. Emellett a felhasználók hajlamosak gyenge jelszavakat választani, vagy ugyanazt a jelszót használni több szolgáltatáshoz, ami jelentős biztonsági kockázatot jelent. Ha egy jelszó kompromittálódik, az összes hozzáférhető szolgáltatás veszélybe kerül.

A biztonsági kockázatok mellett a komplexitás is növekszik. Az IT-adminisztrátoroknak minden egyes alkalmazáshoz külön felhasználókezelési rendszert kell fenntartaniuk, ami hibalehetőségeket rejt magában, és nehezíti a felhasználói fiókok életciklus-kezelését (létrehozás, módosítás, törlés). Az auditálás és a megfelelőség biztosítása is sokkal bonyolultabbá válik, ha nincs központi identitáskezelési pont.

Az AD FS ezekre a kihívásokra ad választ azáltal, hogy egy központosított, szabványokon alapuló hitelesítési brókert biztosít. Ahelyett, hogy minden alkalmazás külön hitelesítené a felhasználót, az összes alkalmazás az AD FS-hez irányítja a felhasználót hitelesítés céljából. Amikor a felhasználó sikeresen hitelesíti magát az AD FS-nél (például az Active Directory hitelesítő adataival), az AD FS egy biztonsági tokent állít ki. Ez a token tartalmazza azokat a jogcímeket, amelyek az alkalmazások számára szükségesek a felhasználó azonosításához és a hozzáférés engedélyezéséhez.

Ez a mechanizmus a következő előnyökkel jár:

• Fokozott felhasználói élmény: A felhasználóknak csak egyszer kell bejelentkezniük, ami egyszerűsíti a hozzáférést és növeli a termelékenységet.
• Javított biztonság: A jelszavak száma csökken, a felhasználók erősebb jelszavakat használhatnak, és a központi hitelesítés lehetővé teszi a fejlett biztonsági funkciók, például a többfaktoros hitelesítés (MFA) egységes alkalmazását. Az alkalmazásoknak nem kell tárolniuk a felhasználók jelszavait.
• Egyszerűsített adminisztráció: Az identitáskezelés központosítottá válik, csökkentve az adminisztrációs terheket és a hibalehetőségeket.
• Rugalmasság és skálázhatóság: Az AD FS képes kezelni a nagyszámú felhasználót és alkalmazást, és könnyen integrálható a legkülönfélébb rendszerekkel a szabványos protokolloknak köszönhetően.
• Megfelelőség: A központosított naplózás és auditálás megkönnyíti a szabályozási követelmények teljesítését.

Az AD FS tehát nem csupán technikai megoldás, hanem stratégiai eszköz is, amely alapjaiban változtatja meg a vállalatok identitás- és hozzáférés-kezelési stratégiáját, elősegítve a biztonságos és hatékony digitális transzformációt.

Az AD FS architektúrájának alapkövei és komponensei

Az Active Directory Federation Services (AD FS) egy kifinomult architektúrával rendelkezik, amely több komponensből áll, és együttműködve biztosítja az identitás-összevonást és az egyszeri bejelentkezést. Az AD FS működésének megértéséhez kulcsfontosságú, hogy tisztában legyünk ezekkel az alapkövekkel és komponensekkel.

Identitásszolgáltató (Identity Provider – IdP) és szolgáltató (Service Provider – SP)

Az AD FS alapvető paradigmája az identitásszolgáltató (IdP) és a szolgáltató (Service Provider – SP) közötti interakción alapul. Az IdP az a fél, amely hitelesíti a felhasználót és kiállítja a felhasználóra vonatkozó jogcímeket tartalmazó biztonsági tokent. Az AD FS ebben a modellben az identitásszolgáltató szerepét tölti be, mivel az Active Directoryban tárolt felhasználói identitásokat használja a hitelesítéshez. A szolgáltató (SP) az az alkalmazás vagy erőforrás, amelyhez a felhasználó hozzáférni szeretne, és amely a jogcímek alapján dönti el a hozzáférés engedélyezését.

A bizalmi kapcsolat (trust relationship)

Az IdP és az SP közötti kommunikáció alapja egy bizalmi kapcsolat (trust relationship). Ez a bizalom azt jelenti, hogy az SP megbízik az IdP által kiállított biztonsági tokenek érvényességében. Ezt a bizalmat tanúsítványok segítségével hozzák létre és tartják fenn, amelyek biztosítják a tokenek integritását és hitelességét. Az AD FS konfigurálásakor létrehozunk egy Relying Party Trustot minden olyan alkalmazáshoz (SP), amellyel SSO-t szeretnénk megvalósítani. Ez a trust definiálja, hogy az AD FS milyen jogcímeket ad át az adott alkalmazásnak.

AD FS szerverek

Az AD FS központi elemei az AD FS szerverek. Ezek a szerverek futtatják az AD FS szolgáltatást, és felelősek a felhasználói hitelesítésért, a jogcímek generálásáért és a biztonsági tokenek kiállításáért. A skálázhatóság és a magas rendelkezésre állás érdekében általában több AD FS szervert telepítenek egy AD FS farmba, amely egy terheléselosztó (load balancer) mögött működik. Ez biztosítja, hogy ha egy szerver meghibásodik, a többi szerver továbbra is képes legyen kiszolgálni a kéréseket.

AD FS adatbázis

Az AD FS farm konfigurációs adatait (pl. relying party trusts, jogcím-szabályok, tanúsítványok) egy adatbázis tárolja. Két fő opció létezik:

• Windows Internal Database (WID): Ez egy beépített adatbázis, amely ideális kisebb környezetekhez (legfeljebb 30 relying party trust és 1000 felhasználó). Könnyen telepíthető, de korlátozott skálázhatósággal és magas rendelkezésre állási képességekkel rendelkezik (nem támogatja az automatikus failovert).
• Microsoft SQL Server: Nagyobb és komplexebb környezetekhez ajánlott, ahol magas rendelkezésre állásra, skálázhatóságra és robusztusabb adatbázis-kezelési funkciókra van szükség. A SQL Server alapú farmok támogatják az automatikus failovert és több AD FS szervert is.

Web Application Proxy (WAP) vagy AD FS proxy

A Web Application Proxy (WAP), korábbi nevén AD FS proxy, egy opcionális, de erősen ajánlott komponens, amelyet a szervezet demilitarizált zónájában (DMZ) helyeznek el. Fő feladata, hogy reverse proxyként szolgáljon az internetről érkező hitelesítési kérések számára. Ez azt jelenti, hogy a külső felhasználók kérései először a WAP-hoz érkeznek, amely továbbítja azokat a belső AD FS szervereknek. A WAP biztosítja, hogy a belső AD FS szerverek soha ne legyenek közvetlenül kitéve az internetnek, jelentősen növelve a biztonságot. Emellett a WAP előhitelesítést is végezhet, és képes közzétenni más belső webalkalmazásokat is.

A jogcímek (claims) és a jogcím-motor (claims engine)

A jogcímek a felhasználóra vonatkozó kijelentések, attribútumok, amelyek a biztonsági tokenben utaznak. Ezek lehetnek például a felhasználó UPN-je, e-mail címe, csoporttagsága, szerepköre vagy bármilyen más adat, amely az Active Directory Domain Services (AD DS)-ből származik. Az AD FS jogcím-motorja (claims engine) felelős ezen jogcímek generálásáért és átalakításáért a jogcím-szabályok (claim rules) alapján. Ezek a szabályok rendkívül rugalmasak, és lehetővé teszik az adminisztrátorok számára, hogy pontosan meghatározzák, milyen jogcímeket és milyen formában adjanak át az egyes szolgáltató alkalmazásoknak.

Protokollok

Az AD FS számos szabványos hitelesítési és engedélyezési protokollt támogat, biztosítva a széles körű interoperabilitást:

• SAML 2.0 (Security Assertion Markup Language): A leggyakrabban használt protokoll a webes SSO és a federáció megvalósítására.
• WS-Federation: A Microsoft által fejlesztett protokoll, amelyet gyakran használnak a .NET alapú alkalmazásokkal és a SharePointtal.
• OAuth 2.0 és OpenID Connect (OIDC): Ezek a protokollok a modern webes és mobil alkalmazásokhoz, valamint az API-khoz való biztonságos hozzáférésre optimalizáltak.

Ezen komponensek együttműködése teszi lehetővé az AD FS számára, hogy robusztus és biztonságos keretrendszert biztosítson az identitás-összevonáshoz és az egyszeri bejelentkezéshez a mai komplex IT-környezetekben.

Az AD FS szerepe a hibrid és multicloud környezetekben

A mai vállalati IT-infrastruktúrák ritkán korlátozódnak egyetlen helyszínre vagy platformra. A legtöbb szervezet hibrid környezetben működik, ahol a hagyományos, helyben telepített (on-premises) alkalmazások és adatok keverednek a felhőalapú szolgáltatásokkal. Ezen túlmenően egyre gyakoribb a multicloud stratégia, ahol több felhőszolgáltató (pl. Azure, AWS, Google Cloud) szolgáltatásait is igénybe veszik. Ebben a komplex ökoszisztémában az Active Directory Federation Services (AD FS) kulcsszerepet játszik az identitáskezelés és az egyszeri bejelentkezés (SSO) biztosításában.

Hagyományos on-premises alkalmazások és az AD FS

Bár az AD FS főleg a külső alkalmazásokkal való federációra fókuszál, képes az on-premises webalkalmazások SSO-ját is biztosítani, különösen, ha azok nem integrálhatók közvetlenül az Active Directoryval. A Web Application Proxy (WAP) segítségével az AD FS képes közzétenni és előhitelesíteni belső webalkalmazásokat, lehetővé téve a külső hozzáférést és az SSO-t anélkül, hogy az alkalmazásoknak direkt internetre kéne kerülniük.

Felhőalapú SaaS alkalmazások integrációja

Az AD FS egyik legerősebb felhasználási területe a felhőalapú SaaS (Software as a Service) alkalmazások integrációja. Gondoljunk olyan népszerű szolgáltatásokra, mint az Office 365 (beleértve a SharePoint Online-t, Exchange Online-t), Salesforce, ServiceNow, Workday, Box, Dropbox és még sok más. Ezek a szolgáltatások általában támogatják a szabványos federációs protokollokat (különösen a SAML 2.0-t), amelyek lehetővé teszik az AD FS számára, hogy identitásszolgáltatóként működjön számukra.

Amikor egy felhasználó megpróbál bejelentkezni egy SaaS alkalmazásba, a kérés átirányítódik az AD FS-hez. Az AD FS hitelesíti a felhasználót a helyi Active Directory ellenében, majd egy biztonsági tokent állít ki, amely tartalmazza a felhasználóra vonatkozó szükséges jogcímeket. Ez a token ezután visszakerül az SaaS alkalmazáshoz, amely elfogadja azt, és bejelentkezteti a felhasználót. Ez a folyamat teljesen transzparens a felhasználó számára, és biztosítja az egyszeri bejelentkezést.

Azure AD Connect és az identitások szinkronizálása

A Microsoft Azure Active Directory (Azure AD) térnyerésével az AD FS szerepe tovább differenciálódott. Az Azure AD egy felhőalapú identitás- és hozzáférés-kezelési szolgáltatás, amely számos felhőalkalmazás (beleértve az Office 365-öt is) natív identitásszolgáltatója. A hibrid környezetekben az Azure AD Connect eszköz felelős a helyi Active Directory Domain Services (AD DS) felhasználói fiókjainak és csoportjainak szinkronizálásáért az Azure AD-vel.

Az Azure AD Connect konfigurálható úgy, hogy különböző hitelesítési módszereket támogasson:

• Jelszó-hash szinkronizálás (Password Hash Synchronization – PHS): A felhasználói jelszavak hash-eit szinkronizálja az Azure AD-be. Az Azure AD végzi a hitelesítést.
• Átmenő hitelesítés (Pass-through Authentication – PTA): Az Azure AD továbbítja a hitelesítési kéréseket a helyi Active Directorynak, anélkül, hogy a jelszavakat szinkronizálná.
• Federáció az AD FS-sel: Ebben az esetben az Azure AD Connect konfigurálja az Azure AD-t úgy, hogy az AD FS-t használja identitásszolgáltatóként. Amikor egy felhasználó megpróbál bejelentkezni egy Azure AD-hez kapcsolt alkalmazásba (pl. Office 365), az Azure AD átirányítja a kérést a helyi AD FS-hez hitelesítésre. Ez biztosítja, hogy a felhasználó a helyi Active Directory hitelesítő adataival jelentkezzen be, és az AD FS által biztosított egyéni jogcím-szabályok és feltételes hozzáférési szabályok érvényesüljenek.

Az AD FS federációs modellje különösen hasznos, ha a szervezetnek komplex hitelesítési szabályokra, többfaktoros hitelesítési (MFA) megoldásokra van szüksége, amelyek a helyi infrastruktúrában futnak, vagy ha speciális jogcímeket kell átadni az Azure AD-nek és az ahhoz kapcsolt alkalmazásoknak. Emellett lehetővé teszi a zökkenőmentes SSO-t mind az on-premises, mind a felhőalapú alkalmazásokhoz, egységes felhasználói élményt biztosítva.

Multicloud környezetek és az AD FS

A multicloud stratégiák esetében, ahol a vállalatok több felhőszolgáltatót (pl. Azure, AWS, Google Cloud) használnak, az AD FS továbbra is releváns lehet. Bár minden felhőszolgáltatónak van saját identitáskezelési szolgáltatása (pl. AWS IAM, Google Cloud Identity), az AD FS képes központi identitásszolgáltatóként működni, amely federálódik ezekkel a felhőplatformokkal. Ez azt jelenti, hogy a felhasználók továbbra is a helyi Active Directory identitásukkal jelentkezhetnek be az összes felhőszolgáltatásba, egyszerűsítve az adminisztrációt és egységesítve a biztonsági politikákat az összes felhőn keresztül. Az AD FS így egy központi identitásközpontot biztosít a teljes hibrid és multicloud ökoszisztémában.

Összességében az AD FS kritikus szerepet játszik abban, hogy a szervezetek biztonságosan és hatékonyan kezelhessék felhasználóik hozzáférését a szétszórt, heterogén IT-környezetekben, hidat képezve a hagyományos infrastruktúra és a modern felhőalapú szolgáltatások között.

Jogcímek, attribútumok és a személyazonosság dinamikus kezelése

Az Active Directory Federation Services (AD FS) alapvető működése a jogcímek (claims) koncepcióján nyugszik. Ahhoz, hogy megértsük az AD FS erejét és rugalmasságát, kulcsfontosságú, hogy mélyebben megvizsgáljuk, mi is az a jogcím, hogyan kapcsolódik az Active Directory attribútumokhoz, és miként teszi lehetővé a személyazonosság dinamikus és részletes kezelését.

Mi is az a jogcím pontosan?

Egy jogcím lényegében egy olyan kijelentés vagy állítás, amelyet egy identitásszolgáltató (például az AD FS) tesz egy felhasználóról. Ezek a kijelentések lehetnek a felhasználó nevére, e-mail címére, csoporttagságára, szerepkörére, vagy bármilyen más attribútumára vonatkozó információk. Például, a „név” jogcím értéke lehet „Kiss Péter”, az „email” jogcím értéke „kiss.peter@example.com”, a „szerepkör” jogcím értéke pedig „Adminisztrátor”.

A jogcímek nem csupán egyszerű adatdarabok; egy biztonsági tokenbe vannak csomagolva, amelyet az identitásszolgáltató digitálisan aláír. Ez az aláírás biztosítja a jogcímek integritását és hitelességét, garantálva, hogy azok nem módosultak a továbbítás során, és valóban az identitásszolgáltatótól származnak. Amikor egy szolgáltató (alkalmazás) megkapja ezt a tokent, megbízhat az abban lévő jogcímekben, feltéve, hogy bízik az identitásszolgáltatóban.

Hogyan alakulnak át az AD attribútumok jogcímekké?

Az AD FS fő adatforrása a helyi Active Directory Domain Services (AD DS). Amikor egy felhasználó bejelentkezik az AD FS-hez, az AD FS hitelesíti őt az AD DS ellenében. A sikeres hitelesítés után az AD FS hozzáfér a felhasználó Active Directorybeli objektumához és annak attribútumaihoz (pl. sAMAccountName, mail, memberOf, employeeID). Ezek az attribútumok önmagukban nem jogcímek, de az AD FS jogcím-motorja képes átalakítani őket szabványos vagy egyéni jogcímekké.

Jogcím-szabályok (claim rules) jelentősége és testreszabása

Az AD FS-ben a jogcím-szabályok (claim rules) határozzák meg, hogy mely Active Directory attribútumokat kell kinyerni, hogyan kell feldolgozni és milyen jogcímként kell kiadni a biztonsági tokenben. Ezek a szabályok rendkívül rugalmasak, és lehetővé teszik az adminisztrátorok számára, hogy finoman hangolják a kiadott jogcímeket az egyes relying party trusts (szolgáltató alkalmazások) igényei szerint. Minden szolgáltatóhoz külön jogcím-kiállítási szabálykészlet (claim issuance policy) definiálható.

A jogcím-szabályok típusai lehetnek:

• Pass Through or Filter an Incoming Claim: Egyszerűen továbbít egy bejövő jogcímet, vagy szűr bizonyos értékeket.
• Transform an Incoming Claim: Átalakít egy bejövő jogcímet egy másik típusú vagy értékű jogcímmé. Például egy UPN-ből kinyerhető az e-mail cím.
• Send Claims Using a Custom Rule: Lehetővé teszi komplex logikájú egyéni szabályok írását az AD FS jogcím-nyelvével (Claim Rule Language). Ez a legrugalmasabb, és lehetővé teszi több attribútum kombinálását, feltételes logikát és egyéb fejlett műveleteket.
• Send LDAP Attributes as Claims: Közvetlenül kinyer LDAP attribútumokat az Active Directoryból, és jogcímként adja ki azokat.
• Send Group Membership as a Claim: A felhasználó csoporttagságait jogcímként adja ki.

Például, egy SaaS alkalmazásnak szüksége lehet a felhasználó e-mail címére és a „Sales” csoporttagságára. Az AD FS-ben beállíthatunk egy szabályt, amely az Active Directory mail attribútumát „Email Address” jogcímként adja ki, és egy másik szabályt, amely a „Sales” csoport tagságát „Role” jogcímként adja ki, ha a felhasználó tagja ennek a csoportnak.

Rugalmasság és granularitás a hozzáférés-kezelésben

A jogcímek és a jogcím-szabályok biztosítják az AD FS számára a rendkívüli rugalmasságot és granularitást a hozzáférés-kezelésben. Az alkalmazások nem csupán „igen” vagy „nem” választ kapnak a hitelesítésre, hanem részletes információkat kapnak a felhasználóról, amelyek alapján saját, finomhangolt engedélyezési döntéseket hozhatnak.

Ez lehetővé teszi például:

• Szerepköralapú hozzáférés-szabályozást (RBAC): A jogcímek tartalmazhatják a felhasználó szerepköreit (pl. „Admin”, „User”, „Manager”), amelyek alapján az alkalmazás különböző funkciókat vagy adatokat tehet elérhetővé.
• Attribútumalapú hozzáférés-szabályozást (ABAC): A jogcímek bármilyen Active Directory attribútumot tartalmazhatnak, lehetővé téve a hozzáférés-szabályozást a felhasználó osztálya, telephelye, beosztása vagy bármilyen más dinamikus attribútum alapján.
• Feltételes hozzáférést: Az AD FS maga is képes komplex szabályokat alkalmazni a jogcímek kiadása előtt, például figyelembe véve a felhasználó hálózati helyét, az eszköz állapotát, vagy a többfaktoros hitelesítés meglétét.

A jogcímek használata elválasztja a hitelesítési logikát az engedélyezési logikától. Az AD FS felel a felhasználó identitásának megerősítéséért és a releváns információk (jogcímek) kiadásáért, míg az alkalmazás felelős a jogcímek értelmezéséért és a hozzáférés-szabályozási döntések meghozataláért. Ez a szétválasztás növeli a biztonságot, egyszerűsíti az alkalmazások fejlesztését, és biztosítja a skálázhatóságot egy dinamikusan változó IT-környezetben.

Az AD FS biztonsági megfontolásai és legjobb gyakorlatai

Az Active Directory Federation Services (AD FS) központi szerepet játszik a felhasználói identitások kezelésében és a hozzáférés biztosításában, ezért a biztonsági megfontolások kiemelten fontosak a tervezés, telepítés és üzemeltetés során. Egy rosszul konfigurált AD FS implementáció komoly biztonsági réseket nyithat a szervezet számára. A következőkben áttekintjük a legfontosabb biztonsági aspektusokat és a legjobb gyakorlatokat.

A megbízható identitásszolgáltató szerepe

Az AD FS, mint identitásszolgáltató, a bizalom alapköve. Az összes hozzá kapcsolódó szolgáltató (relying party) megbízik abban, hogy az AD FS pontosan és biztonságosan hitelesíti a felhasználókat, és hiteles jogcímeket ad ki róluk. Ezért az AD FS infrastruktúrájának integritása és biztonsága kritikus. Bármilyen kompromittálódás az AD FS szervereken azonnali és széles körű hozzáférés-engedélyezési problémákhoz vezethet.

Transport Layer Security (TLS/SSL) használata

Minden kommunikációnak az AD FS szerverek és a kliensek, valamint az AD FS és a szolgáltató alkalmazások között Transport Layer Security (TLS/SSL) protokollon keresztül kell történnie. Ehhez megbízható, nyilvános hitelesítésszolgáltató (CA) által kiadott SSL/TLS tanúsítványokra van szükség. Ezek a tanúsítványok biztosítják az adatforgalom titkosítását és a szerverek hitelességét. Különösen fontos a WAP (Web Application Proxy) és az AD FS szerverek közötti, valamint a WAP és az internetes kliensek közötti kommunikáció titkosítása.

Többfaktoros hitelesítés (MFA) integrációja

Az MFA (Multi-Factor Authentication) bevezetése az egyik leghatékonyabb módszer a hitelesítés biztonságának növelésére. Az AD FS natívan támogatja az MFA-t, és integrálható különböző MFA szolgáltatókkal (pl. Azure MFA, harmadik féltől származó megoldások). Az AD FS lehetővé teszi az adaptív MFA beállítását is, ahol az MFA csak bizonyos feltételek (pl. ismeretlen eszköz, nem megbízható hálózat, érzékeny alkalmazás) esetén kérhető, növelve a biztonságot anélkül, hogy feleslegesen terhelné a felhasználókat.

Denial-of-Service (DoS) védelem

Az AD FS szerverek potenciális célpontjai lehetnek a DoS támadásoknak, amelyek célja a szolgáltatás elérhetetlenné tétele. Fontos a megfelelő hálózati védelem (tűzfalak, IDS/IPS rendszerek), valamint az AD FS beépített védelmi funkcióinak konfigurálása, mint például a soft lockouts, amely megakadályozza a brute-force jelszótámadásokat. Az AD FS 2016-tól és újabb verzióiban a beépített extranet lockout funkció segít megvédeni a jelszó-spray támadásoktól.

Auditálás és naplózás

A részletes naplózás és auditálás elengedhetetlen a biztonsági incidensek felderítéséhez és a megfelelőség biztosításához. Az AD FS kiterjedt naplókat generál a hitelesítési kísérletekről, a token kiállításokról, a konfigurációs változásokról és a hibákról. Ezeket a naplókat rendszeresen gyűjteni, elemezni és archiválni kell egy központosított naplókezelő rendszerrel (pl. SIEM) a potenciális fenyegetések időben történő azonosítása érdekében.

A Web Application Proxy (WAP) szerepe a hálózati biztonságban

A Web Application Proxy (WAP) telepítése a DMZ-be a legjobb gyakorlat. Ez a komponens biztosítja, hogy a belső AD FS szerverek soha ne legyenek közvetlenül elérhetők az internetről. A WAP előhitelesíti a külső kéréseket, és csak a sikeresen hitelesített kéréseket továbbítja a belső AD FS szervereknek. Ez egy további védelmi réteget biztosít, elrejtve a belső infrastruktúrát a külső támadók elől. Fontos a WAP szerverek biztonságos konfigurálása is, beleértve a tűzfal szabályokat és a rendszeres frissítéseket.

Rendszeres frissítések és javítások

Mint minden szoftver esetében, az AD FS szervereket és az alapul szolgáló Windows Server operációs rendszert is rendszeresen frissíteni kell a legújabb biztonsági javításokkal és kumulatív frissítésekkel. Ez segít megvédeni az ismert sebezhetőségek kihasználása ellen.

Principle of Least Privilege (a legkevesebb jogosultság elve)

Alkalmazni kell a legkevesebb jogosultság elvét az AD FS szerverek és a szolgáltatásfiókok konfigurálásakor. Az AD FS szolgáltatásfióknak csak a működéséhez feltétlenül szükséges jogosultságokkal kell rendelkeznie. Az adminisztrátoroknak is csak a feladataik ellátásához szükséges minimális jogosultságokat kell biztosítani.

Tanúsítványkezelés

Az AD FS nagymértékben támaszkodik a tanúsítványokra (SSL/TLS, token aláíró, token titkosító). Fontos a tanúsítványok megfelelő kezelése: biztonságos tárolás, időben történő megújítás és a lejárt tanúsítványok azonnali cseréje, hogy elkerülhetők legyenek a szolgáltatáskiesések és a biztonsági rések.

Az AD FS biztonságos implementációja gondos tervezést, folyamatos monitorozást és a legjobb gyakorlatok követését igényli. A proaktív megközelítés kulcsfontosságú az identitáskezelő infrastruktúra védelmében.

Az AD FS üzembe helyezése és konfigurálása: lépések és szempontok

Az Active Directory Federation Services (AD FS) üzembe helyezése és konfigurálása egy komplex folyamat, amely gondos tervezést és a részletekre való odafigyelést igényel. A sikeres implementáció biztosítja a zökkenőmentes egyszeri bejelentkezést (SSO) és a biztonságos identitás-összevonást. Íme a legfontosabb lépések és szempontok.

Előfeltételek

Mielőtt hozzákezdenénk az AD FS telepítéséhez, számos előfeltételnek kell teljesülnie:

• Active Directory Domain Services (AD DS): Egy működő AD DS tartományra van szükség, amelyben a felhasználói fiókok találhatók. Az AD FS szervernek tartománytagként kell működnie.
• DNS konfiguráció: Megfelelő DNS rekordokat kell létrehozni az AD FS szolgáltatáshoz. Ez magában foglalja az AD FS szolgáltatásnév (pl. sts.contoso.com) és a WAP szolgáltatásnév (ha használunk WAP-ot) A rekordjait.
• Tanúsítványok: Két fő tanúsítványra van szükség:
  • SSL/TLS szolgáltatás-kommunikációs tanúsítvány: Ezt a tanúsítványt az AD FS szerverek és a WAP használja a biztonságos HTTPS kommunikációhoz. Nyilvános CA által kiadott, megbízható tanúsítványra van szükség, amelynek Subject Alternate Name (SAN) mezőjében szerepel az AD FS szolgáltatásnév (pl. sts.contoso.com).
  • Token aláíró tanúsítvány: Ezt az AD FS automatikusan generálja, és a biztonsági tokenek digitális aláírására szolgál. Fontos, hogy ezt a tanúsítványt a szolgáltató alkalmazások is megbízhatónak tartsák.
  • Token titkosító tanúsítvány (opcionális): Ha titkosítani szeretnénk a jogcímeket a tokenben, akkor egy titkosító tanúsítványra is szükség van.
• Szolgáltatásfiók: Egy tartományi szolgáltatásfiók, amelynek jogosultsága van az AD DS-hez való hozzáférésre.

Topológiai lehetőségek

Az AD FS farm tervezésekor figyelembe kell venni a skálázhatóságot és a magas rendelkezésre állást:

• Egyetlen AD FS szerver WID-vel: Kisebb környezetekhez, teszteléshez. Nincs magas rendelkezésre állás.
• Több AD FS szerver WID-vel: Legfeljebb 5 szerver támogatott, de nincs automatikus failover. Manuális beavatkozás szükséges hiba esetén.
• Több AD FS szerver SQL Serverrel: Ajánlott nagyobb, éles környezetekhez. Lehetővé teszi a magas rendelkezésre állást (SQL AlwaysOn) és a jobb skálázhatóságot.

Minden AD FS farmhoz erősen ajánlott egy Web Application Proxy (WAP) telepítése a DMZ-be, hogy védelmet nyújtson a belső AD FS szervereknek.

AD FS szerver telepítése és konfigurálása

1. Szerepkör telepítése: A Windows Serveren telepítsük az „Active Directory Federation Services” szerepkört a Server Manager segítségével.
2. AD FS szolgáltatás konfigurálása: A telepítés után futtassuk az AD FS konfigurációs varázslót. Itt válasszuk ki az elsődleges AD FS szerver konfigurálását egy új AD FS farmban.
3. Szolgáltatásfiók megadása: Adjuk meg a tartományi szolgáltatásfiókot, amelyet az AD FS szolgáltatás fog használni.
4. Tanúsítvány kiválasztása: Válasszuk ki a korábban előkészített SSL/TLS szolgáltatás-kommunikációs tanúsítványt.
5. Adatbázis konfiguráció: Válasszuk ki, hogy Windows Internal Database (WID) vagy SQL Server adatbázist szeretnénk használni. SQL Server esetén adjuk meg az adatbázis szerver adatait.
6. Farm csomópontok hozzáadása: Ha több AD FS szervert telepítünk, a további szervereken is telepítsük a szerepkört, majd a konfigurációs varázslóban válasszuk az „Add a federation server to a federation server farm” opciót.

Web Application Proxy (WAP) üzembe helyezése

1. Szerepkör telepítése: Egy külön szerverre (DMZ-ben) telepítsük a „Remote Access” szerepkör „Web Application Proxy” al-szolgáltatását.
2. WAP konfigurálása: Futtassuk a WAP konfigurációs varázslót. Meg kell adni az AD FS farm nevét (pl. sts.contoso.com) és egy AD FS adminisztrátori fiók hitelesítő adatait. A WAP lekéri az AD FS tanúsítványait.
3. Külső DNS konfiguráció: Biztosítsuk, hogy a külső DNS az AD FS szolgáltatásnév (pl. sts.contoso.com) kéréseit a WAP nyilvános IP címére irányítsa.

Alkalmazások hozzáadása (Relying Party Trusts)

Miután az AD FS infrastruktúra működőképes, hozzáadhatjuk a szolgáltató alkalmazásokat (relying parties). Ez általában a következő lépéseket foglalja magában:

1. Relying Party Trust hozzáadása: Az AD FS Management konzolban válasszuk a „Relying Party Trusts” lehetőséget, majd „Add Relying Party Trust”.
2. Metaadatok importálása: Sok SaaS alkalmazás biztosít metaadat URL-t vagy fájlt, amely tartalmazza a szükséges konfigurációs információkat (pl. tanúsítványok, végpontok). Ez leegyszerűsíti a beállítást. Manuális konfiguráció is lehetséges.
3. Jogcím-kiállítási szabályok (Claim Issuance Policy) konfigurálása: Ez a legfontosabb lépés. Itt definiáljuk, hogy milyen jogcímeket (pl. felhasználónév, e-mail, csoporttagság) adjon át az AD FS az adott alkalmazásnak az Active Directoryból. Használjuk a „Send LDAP Attributes as Claims” vagy „Send Group Membership as a Claim” sablonokat, vagy írjunk egyéni szabályokat.

Tesztelés és monitorozás

Az üzembe helyezés után alapos tesztelésre van szükség. Próbáljunk meg bejelentkezni az összes konfigurált szolgáltató alkalmazásba különböző felhasználói fiókokkal. Ellenőrizzük az AD FS eseménynaplókat (Event Viewer) a hibák vagy figyelmeztetések után. A folyamatos monitorozás (pl. teljesítményfigyelők, naplógyűjtés SIEM rendszerbe) kulcsfontosságú az AD FS környezet stabilitásának és biztonságának fenntartásához.

Terheléselosztás és magas rendelkezésre állás (HA)

Nagyobb környezetekben elengedhetetlen a terheléselosztás (load balancing) alkalmazása az AD FS szerverek előtt. Ez eloszlatja a bejövő kéréseket a farm tagjai között, és biztosítja a szolgáltatás folyamatos működését, még akkor is, ha egy szerver meghibásodik. Hardveres terheléselosztók (HLB) vagy szoftveres megoldások (pl. Windows Network Load Balancing – NLB) egyaránt használhatók.

Az AD FS üzembe helyezése egy jelentős projekt, amely alapos tervezést, a hálózati és identitáskezelési ismereteket, valamint a biztonsági protokollok ismeretét igényli. A gondos megvalósítás azonban hosszú távon megtérül a javított felhasználói élmény, a fokozott biztonság és az egyszerűsített adminisztráció révén.

AD FS vs. Azure AD: Mikor melyiket válasszuk?

A Microsoft identitáskezelési ökoszisztémájában két kulcsfontosságú szereplő van, amelyek gyakran egymás mellett vagy egymást kiegészítve működnek: az Active Directory Federation Services (AD FS) és az Azure Active Directory (Azure AD). Bár mindkettő célja az identitáskezelés és az egyszeri bejelentkezés (SSO) biztosítása, alapvető különbségek vannak működésükben és abban, hogy mely forgatókönyvekhez a legalkalmasabbak. A helyes választás kritikus a vállalat IT-stratégiája szempontjából.

Hasonlóságok és különbségek

Mind az AD FS, mind az Azure AD célja a felhasználók hitelesítése és az alkalmazásokhoz való hozzáférés engedélyezése. Mindkettő támogatja a szabványos protokollokat (SAML, OAuth, OpenID Connect) a federáció és az SSO megvalósításához, és mindkettő integrálható a többfaktoros hitelesítéssel (MFA).

A fő különbség a telepítési modellben és az elsődleges felhasználási esetekben rejlik:

• AD FS: Helyben telepített (on-premises) szolgáltatás, amely a helyi Active Directory Domain Services (AD DS) identitásait használja. Teljes ellenőrzést biztosít a hitelesítési folyamat felett, és rendkívül rugalmas a jogcímek és szabályok tekintetében. Ideális hibrid környezetekhez, ahol a legtöbb alkalmazás még mindig helyben fut, vagy ahol nagyon specifikus, komplex hitelesítési és engedélyezési igények vannak.
• Azure AD: Felhőalapú identitás- és hozzáférés-kezelési szolgáltatás (Identity as a Service – IDaaS). Nincs szükség helyi infrastruktúrára, a Microsoft kezeli a skálázhatóságot és a rendelkezésre állást. Natívan integrálódik a Microsoft felhőszolgáltatásaival (Office 365, Azure), és több ezer SaaS alkalmazással. Ideális a felhőalapú, mobil-first stratégiával rendelkező szervezetek számára.

Mikor válasszuk az Azure AD-t?

Az Azure AD a preferált választás az alábbi esetekben:

• Felhőalapú identitáskezelés: Ha a vállalat elsősorban felhőalapú alkalmazásokat használ, és minimalizálni szeretné a helyi infrastruktúrát.
• Office 365 és Microsoft 365: Az Azure AD az Office 365 és Microsoft 365 natív identitásszolgáltatója. A legegyszerűbb és leggyorsabb integrációt kínálja ezekkel a szolgáltatásokkal.
• Egyszerűsített adminisztráció: Az Azure AD menedzselése általában egyszerűbb, mivel a Microsoft gondoskodik a mögöttes infrastruktúráról, a frissítésekről és a magas rendelkezésre állásról.
• Kisebb helyi infrastruktúra: Ha a helyi Active Directoryt csak korlátozottan használják, vagy ha a felhasználók és alkalmazások többsége felhőben van.
• Költséghatékonyság: Nincs szükség dedikált szerverekre, licencelésre és üzemeltetésre az AD FS számára.
• B2B és B2C forgatókönyvek: Az Azure AD B2B (Business-to-Business) és B2C (Business-to-Consumer) képességei robusztus megoldásokat kínálnak a külső felhasználók és ügyfelek identitáskezelésére.

Az Azure AD Connect használatával a helyi AD DS identitásokat szinkronizálhatjuk az Azure AD-vel, és választhatunk a Jelszó-hash szinkronizálás (PHS) vagy az Átmenő hitelesítés (PTA) közül, amelyek mindkettő felhőalapú hitelesítést biztosítanak, anélkül, hogy AD FS-re lenne szükség.

Mikor marad mégis releváns az AD FS?

Bár az Azure AD egyre több forgatókönyvet fed le, az AD FS továbbra is releváns és előnyös lehet bizonyos specifikus helyzetekben:

• Komplex on-premises integrációk: Ha a vállalat számos régi, helyben futó alkalmazással rendelkezik, amelyek nem támogatják a modern hitelesítési protokollokat, vagy amelyekhez egyedi integrációra van szükség. Az AD FS és a WAP képes ezeket az alkalmazásokat közzétenni és SSO-t biztosítani számukra.
• Speciális jogcímkezelés és feltételes hozzáférés: Ha rendkívül részletes, komplex jogcímátalakítási szabályokra van szükség, amelyek nem valósíthatók meg az Azure AD natív képességeivel, az AD FS nagyobb rugalmasságot kínál.
• Harmadik féltől származó IdP integrációk: Ha a vállalatnak más külső identitásszolgáltatókkal (pl. partneri szervezetek, más SAML IdP-k) kell federálódnia, és az AD FS már be van állítva erre a célra.
• Szigorú biztonsági és megfelelőségi követelmények: Bizonyos iparágakban vagy szabályozási környezetekben a vállalatoknak teljes ellenőrzésre van szükségük az identitáskezelési infrastruktúra felett, beleértve a hitelesítési adatok tárolását és feldolgozását. Az AD FS teljes mértékben helyben fut, így a vállalat ellenőrzése alatt marad.
• Már meglévő, jól bevált AD FS infrastruktúra: Ha egy vállalat már jelentős befektetést eszközölt egy robusztus AD FS infrastruktúrába, és az jól működik a jelenlegi igényeiknek megfelelően.
• Helyi MFA megoldások: Ha egy szervezet egy speciális, helyben telepített MFA megoldást használ, és azt szeretné integrálni az összes alkalmazásához.

A hibrid identitáskezelés jövője

A legtöbb vállalat számára a valóság a hibrid identitáskezelés, ahol az Azure AD és az AD FS (vagy az Azure AD Connect PHS/PTA) együttműködik. Az Azure AD Connect kulcsfontosságú ebben a modellben, mivel összeköti a helyi Active Directoryt az Azure AD-vel. A Microsoft erősen ösztönzi az ügyfeleket, hogy lehetőség szerint használják az Azure AD-t elsődleges identitásszolgáltatóként, még a helyi Active Directoryval való szinkronizálás esetén is (PHS vagy PTA használatával), mivel ez egyszerűsíti a menedzsmentet és maximalizálja a felhőalapú előnyöket.

Az AD FS továbbra is értékes eszköz marad a specifikus, komplex, on-premises vagy federációs igényekkel rendelkező szervezetek számára. Ugyanakkor az Azure AD a modern identitáskezelés jövője, és egyre inkább ez lesz az alapértelmezett választás a legtöbb felhőalapú és hibrid forgatókönyv esetén.

Az AD FS jövője és az identitáskezelés evolúciója

Az Active Directory Federation Services (AD FS) több mint egy évtizede alapvető pillére a Microsoft identitáskezelési stratégiájának, különösen a hibrid környezetekben. Azonban az IT-világ folyamatosan fejlődik, a felhőtechnológiák térnyerése és az identitás-központú biztonsági modellek előretörése új kihívásokat és lehetőségeket teremt. Ennek fényében fontos megvizsgálni az AD FS jövőjét és azt, hogyan illeszkedik az identitáskezelés evolúciójába.

A felhő térnyerése és az Azure AD központosítása

A legjelentősebb trend az identitáskezelésben a felhőalapú megoldások dominanciája. Az Azure Active Directory (Azure AD) a Microsoft válasza erre a trendre, és egyre inkább az elsődleges identitásszolgáltatóvá válik a Microsoft ökoszisztémájában és azon kívül is. Az Azure AD natív képességei, mint a feltételes hozzáférés, az identitásvédelem, a B2B és B2C funkciók, valamint a zökkenőmentes integráció több ezer SaaS alkalmazással, sok esetben felülmúlják az AD FS helyi képességeit.

A Microsoft stratégiája egyértelműen az, hogy az ügyfeleket az Azure AD felé terelje, amennyire csak lehetséges. Az Azure AD Connect eszköz, amely a helyi Active Directoryt köti össze az Azure AD-vel, már számos hitelesítési módot kínál, amelyek nem igényelnek AD FS-t (Jelszó-hash szinkronizálás, Átmenő hitelesítés). Ezek az opciók egyszerűbbek a telepítésben és az üzemeltetésben, és a Microsoft gondoskodik a mögöttes infrastruktúráról.

Az identitás mint perimeter (Identity as a Perimeter)

A hagyományos hálózati peremvédelem (firewallok, DMZ-k) a felhő és a mobil munkaerő térnyerésével egyre kevésbé hatékony. Ezt váltja fel az „identitás mint perimeter” (Identity as a Perimeter) vagy a Zero Trust modell, ahol a bizalom nem a hálózati helyzeten, hanem a felhasználó, az eszköz és az alkalmazás identitásán alapul. Ebben a modellben az identitásszolgáltató (például az Azure AD vagy az AD FS) kulcsszerepet játszik a hozzáférés-engedélyezési döntések meghozatalában, figyelembe véve a kontextust és a kockázati tényezőket.

Az AD FS továbbra is támogathatja ezt a modellt a fejlett jogcím-szabályaival és az MFA integrációjával, de az Azure AD beépített feltételes hozzáférési politikái és az Identity Protection funkciói sok esetben kifinomultabb és könnyebben kezelhető megoldást kínálnak.

Folyamatos hozzáférés-értékelés (Continuous Access Evaluation – CAE)

A hagyományos token alapú hitelesítésnél a token érvényessége rögzített időtartamra szól. Ha ez idő alatt a felhasználó jogosultságai megváltoznak (pl. kirúgják, vagy megváltozik a szerepköre), a token továbbra is érvényes maradhat, amíg le nem jár. A folyamatos hozzáférés-értékelés (CAE) egy újabb fejlemény, amely lehetővé teszi, hogy az identitásszolgáltató (jelenleg elsősorban az Azure AD) valós időben visszavonja a tokeneket, ha a felhasználói állapot vagy a biztonsági feltételek megváltoznak. Ez jelentősen növeli a biztonságot, és az AD FS-nek is alkalmazkodnia kell ehhez a paradigmához a jövőben, vagy az Azure AD-vel való szorosabb integráció révén.

Az AD FS szerepe a modern identitás-ökoszisztémában

Bár az Azure AD egyre inkább a preferált megoldás, az AD FS nem tűnik el teljesen. Továbbra is lesznek olyan forgatókönyvek, ahol az AD FS a legmegfelelőbb vagy akár az egyetlen életképes megoldás:

• Rendkívül komplex, egyedi on-premises alkalmazásintegrációk: Azok a szervezetek, amelyeknek nagy számú, egyedi fejlesztésű, régi vagy speciális hitelesítési igényű helyi alkalmazásuk van, továbbra is támaszkodhatnak az AD FS rugalmasságára.
• Szigorú megfelelőségi és szabályozási követelmények: Bizonyos iparágakban a vállalatoknak teljes ellenőrzésre van szükségük az összes identitás- és hitelesítési adat felett, és nem engedélyezhetik azok felhőbe való áthelyezését.
• Partneri federációk: Az AD FS továbbra is erős megoldás marad a B2B federációkhoz, ahol más szervezetekkel kell bizalmi kapcsolatokat kiépíteni.

Az AD FS tehát valószínűleg egy nichebb, de továbbra is fontos szerepet fog betölteni a hibrid identitáskezelési környezetekben. A Microsoft valószínűleg folytatja az AD FS fejlesztését, de a hangsúly egyértelműen az Azure AD-n és a felhőalapú identitáskezelésen van. A szervezeteknek alaposan fel kell mérniük igényeiket, és mérlegelniük kell, hogy az Azure AD natív képességei elegendőek-e, vagy szükség van-e az AD FS által kínált mélyebb testreszabhatóságra és helyi ellenőrzésre.

Az identitáskezelés jövője a rugalmasság, a felhőalapú szolgáltatások, a Zero Trust elvek és a folyamatosan fejlődő biztonsági mechanizmusok körül forog. Az AD FS-nek is alkalmazkodnia kell ehhez, vagy az Azure AD-vel való szorosabb integráció révén, vagy speciális, helyi identitáskezelési igények kielégítésével.