Ahhoz, hogy az ADFS és az Exchange Server 2013 kombinációjáról beszéljünk, először tisztáznunk kell az ADFS szerepét. Exchange blog lévén, feltételezem, hogy az Exchange az ismert. :)

Mi hát az ADFS?

Mélyen él az emlékeimben az amikor 2003-ban először láttam és hallottam az ADFS-ről. Egy belső bizalmas konferenciánk volt. Ahol Bill Gates mondott egy érdekes beszédet. Ebben a beszédben rengeteg jövőbeli szolgáltatás, termék jelen volt. Nem mellesleg említés szinten volt egy olyan példa is, hogy A vállalatnál működő SharePoint Portál szolgáltatásait B vállalat felhasználói tudják használni úgy, hogy: a két vállalat között nincs hagyományos trust kapcsolat, a két vállalat között csak HTTPS kommunikáció lehetséges és B vállalat felhasználója SSO (single-sign-on) segítségével éri el a szolgáltatást. Ez utóbbi az igazán fontos. Tehát B vállalat felhasználója, reggel beér a céghez. Bekapcsolja a gépét, belép a B vállalat Active Directory címtárába, majd elindítja a böngészőjét és A vállalat SharePoint portálját böngészi úgy, hogy nem kellett újra azonosítania magát. Nem mellesleg nincs az A vállalat címtárában sem felhasználói azonosítója. Felhasználónk csak a B vállalat címtárában szerepel.

Ez a beszéd és ez a példa annyira megragadta a figyelmemet és elindította a képzeletemet, hogy utána sokáig nem tudtam ettől szabadulni. Fogalmam sincs, hogy pontosan hogyan működik és mi az a csoda ami ezt megvalósítja. De az biztos, hogy a hét további részében, amikor a hotelbe visszaértem, akkor csak ezen merengtem, hogy vajon, hogy fog ez működni. Biztos voltam benne, hogy nekem ezt meg kell értenem és foglalkoznom kell vele, mert annyira egyedi és Bill is beszél róla. Majd később megérkezett a Windows Server 2003 R2 beta verziója benne az ADFS komponenssel és azonnal lecsaptam rá. Validálni szerettem volna, hogy amiről Bill beszélt az működik-e. És tényleg. Működik. Azóta eltelt több mint 10 év és jól látjuk, hogy az ADFS alapú azonosítás és authorizáció napjaink fontos épitőköve. No nem azért mert olyan sok az A és B vállalat kapcsolata ami ezt kikénszeríti. Nem. Sajnos még ma is botladoznak, bukdácsolnak az ügyfelek a saját maguk által kötött békjókban, ha cross-org elérést kell biztosítani a szolgáltatásokhoz. Az IT, IT szemmel nézi és a legegyszerűbb megközelítést alkalmazza: vegyünk fel az AD-ba új júzert. Az IT biztonság berzenkedik, ezért csinálnak egy új forestet, amit aztán trustolnak össze-vissza. Ááá. Az IT szempontjából is rossz és a végfelhasználók szempontjából is az. Majd időről-időre aztán újrakezdik az egészet. Szóval nem, az ADFS használatát nem a vállalatok közti kommunikáció egyszerüsítésére kezdte el a világ használni. Helyette az alapja lett a felhőszolgáltatásoknak. Hiszen helyettesítsük be az A és B vállalatokat. A vállalat a Microsoft és a nálunk levő Exchange, Sharepoint stb. szolgáltatásokat biztosítjuk a felhasználók millióinak. B vállalat pedig a Te céged. Hogy fogják a Te céged felhasználói az általunk biztosított szolgáltatásokat elérni úgy, hogy nem mi csináljuk az azonosítókezelést (jelszó, jelszólejárat stb.)?

Egyszerű a válasz az előző kérdésre. Hát erre való az ADFS. Nem kell Windows NT alapú trustot kiépíteni, nincs RPC forgalom csak HTTPS és van SSO. Minden szép, minden jó.

Az azonosítási kérdések esetén mindig van egy dilemma. Ha adott Alice és Bob és Bob arra kíváncsi, hogy Alice valóban az akinek mondja magát, akkor kell egy harmadik fél, akiben Alice és Bob is kölcsönösen megbízik. A harmadik, egyben megbízható fél jelenléte az authentikációs folyamatban azt biztosítja, hogy egyszerűbben meggyőződhetünk arról, hogy Alice, valóban Alice. Ugyanis a harmadik fél látja el az azonosítási feladatot és a folyamat végén ad "valamit" Alice-nek, amit Alice nem tud elolvasni, csak Bob. Alice ezt a "valamit" átadja Bob-nak, aki eltudja olvasni azt.

Az Active Directory esetében ha ezt lebontjuk a résztvevők szintjéra akkor:

• Az egyik résztvevő fél egy felhasználó
• A másik résztvevő fél egy szolgáltatás mondjuk egy Web szerver
• A harmadik fél, akiben a szolgáltatás és a felhasználó is megbízik, a tartományvezérlő

A felhasználó ha szeretné elérni a Web szervert, akkor nem a Web szerver azonosítja őt. A felhasználót azonosítja a tartományvezérlő, majd a tartományvezérlő kiállít egy Kerberos jegyet (ez a valami), amivel a felhasználó nem tud semmit sem csinálni, csak átküldeni a Web szervernek. A Web szerver képes ezt a Kerberos jegyet elolvasni és abból megtudja állapítani, hogy a felhasználó elérheti-e a szolgáltatást vagy sem.

Honnan tudja a Web szerver azt, hogy a felhasználó elérheti-e a szolgáltatást? Hát onnan, hogy a Kerberos jegyben a felhasználó SID-jei és a csoporttagsága alapján megkapott SID-ek vannak. A Web szervert ezeket a SID-eket az adott elérni kívánt erőforrás hozzáférési listáján szereplő SID-ek listájával összehasonlítja. Ebből már talán érthető, hogy miként működik. A folyamatot itt leegyszerüsítettem, nem beszélek most az Access Token generálásról.

A lényeg tehát a Kerberos esetében az, hogy a Kerberos jegyben ott vannak a SID-ek, amikből aztán az erőforrás kiszolgáló képes eldönteni azt, hogy a felhasználónak van-e jogosultsága vagy sem. Az a folyamat, amikor az erőforrás kiszolgáló eldönti azt, hogy van-e joga az adott felhasználónak azt Authorization (Authz) folyamatnak hívjuk.

Az ADFS alapú azonosítás esetében a harmadik fél az ADFS kiszolgáló. Az ADFS kiszolgálóban bízik meg mindenki. Azonban két vállalat esetében nem egy, hanem legalább két ADFS rendszerről beszélhetünk. Ugyanis A és B vállalatnak is van egy-egy ADFS rendszere. A vállalat a saját ADFS szerverében bízik meg és B vállalat is csak a saját ADFS szerverében bízik meg. Azonban a két ADFS rendszert kölcsönösen megbízhatóvá tehetjük. Ezzel a lépéssel az biztosítható, hogy A vállalat ADFS szervere által kiadott ADFS tokent, B vállalat ADFS szervere elfogadja.

Mielőtt a teljes folyamatot áttekintjük, előtte bontsuk ki egy kicsit az ADFS tokent "a valamit". Talán még emlékeztek rá, a Kerberos jegyben vagy tokenben SID-ek szerepelnek (leegyszerüsítve a képet). Az ADFS tokenben azonban elsősorban nem SID-ek vannak. Úgynevezett claim-ek szerepelnek az ADFS tokenben. Claim lehet a felhasználó bármilyen tulajdonsága. Például a telefonszámát, email címét, nevét, beosztását, főnökét stb. betehetjük 1-1 claim-be. Az ADFS tokenben aztán ezek a claim-ek szerepelnek. Természetesen a felhasználó SID-je, vagy csoporttagsága is lehet egy claim, így aztán a Kerberos jegyben szerepelő információ is betehető az ADFS tokenbe. A claim-ek használata rengeteg előnyt jelent, példák:

• Nem kell mindenhez csoportot használni
• Egyszerűbb hozzáférési szabályok fogalmazhatóak meg. Pl.: ha a beosztása X akkor hozzáférhet; ha a főnöke Y és a beosztás X akkor hozzáférhet stb.
• A SID-ek csak egy AD erdőben értelmezhetőek, a claim információk viszont különböző rendszerekben is értelmezhetőek

Képzeljük el a következő architektúrát:

Ha a vállat B kliense szeretné elérni a vállalat A web szerverét és van ADFS, akkor a folyamat a következő:

• B vállalat felhasználója megnyitja a böngészőjében a Web alkalmazást
• A vállalatnál levő Web szerver tudja, hogy azonosítás kell az eléréséhez, azt is tudja, hogy ADFS azonosítás kell és azt is tudja, hogy B vállalatnál van ADFS szerver és annak mi a neve. Ezért aztán, egy HTTP redirect üzenettel válaszol B vállalat felhasználójának és átirányítja a B vállalat ADFS szerveréhez.
• B vállalat ADFS szervere, Active Directory alapú azonosítással azonosítja a felhasználót. Ezt megtudja tenni egyszerűen, hiszen tartományi tag az ADFS szerver. Ez az azonosítás lehet Kerberos vagy ADFS ürlap alapú, vagy Basic azonosítás. A lényeg, hogy ezen a ponton megtörténik az azonosítása a felhasználónak.
• B vállalat ADFS szerveréhez amikor a klienst átirányítja A vállalat web szervere, akkor az átirányításkor az is szerepel az üzenetben, hogy egyébként a felhasználó milyen alkalmazást akart elérni. Tehát amikor B vállalat ADFS szerveréhez megy a kliens, akkor azt is elmondja, hogy milyen alkalmazást akart megnyitni. Ez azért fontos, mert a B vállalat ADFS szervere, nem fog ADFS tokent minden kérésre kiállítani. Csak azoknak az alkalmazásoknak az eléréshez ad ki tokent, amit ismer. Ez azért is fontos, mert minden alkalmazásnak más és más claim-re lehet szüksége. Tehát tudnia kell azt, hogy milyen alkalmazáshoz állítja ki a tokent, mert a tokenbe azokat és csak azokat a claim-eket kell betenni, ami az alkalmazáshoz okvetlen fontos. Ezen a ponton az ADFS kiállítja a tokent és visszaküldi a kliensnek.
• A kliens a tokent elküldi a .... na minek is? A Web szervernek? Nem. A vállalat ADFS szerverének küldi el, ami képes arra, hogy azt elolvassa. Elolvassa, kibontja és ez a token alapján kiállít egy új tokent amit visszaküld a kliensnek. Ennek két főbb oka van. Az egyik ok az, hogy az A vállalat erőforrásai például a Web szerver, csak a saját ADFS szerverében bízik meg és a többi kapcsolódó vállalat ADFS architektúrájában nem bízik. A bizalmi kapcsolat az ADFS rendszerek szintjén van. A másik ok pedig az, hogy ez a folyamat lehetőséget teremt arra, hogy A vállalat az ADFS tokenben levő claim-eket manipulálja. Képzeljük el azt, hogy B vállalatnál levő AD-ben az atuhorization folyamathoz szükséges információt X tulajdonságban tároljuk. A claim neve X lesz. Viszont az A vállalatnál az X nevű claim már foglalt. Mi ilyenkor a teendő? Hát az A vállalat ADFS-e képes arra, hogy az X claim-et "átnevezze" Y claim-re, amit a web szerver már érteni fog. Summa: ebben a lépésben az A vállalat ADFS-e kiállítja az új ADFS tokent és azt átküldi a kliensnek.
• A kliens az új ADFS tokent átküldi a web szervernek, ami megbízik abban, hiszen a saját ADFS rendszere adta ki. Kibontja és a claim-ek alapján elvégzi az Authorization folyamatot.

A folyamat jó komplikáltnak tűnik. És úgy tűnik, hogy lassú is. A gyakorlatban azonban ha megértjük és alaposan átgondoljuk a fentieket, akkor elég nyilvánvaló a folyamat. A gyakorlatban pedig mindez nagyon gyors. Nem lassítja az elérési folyamatot a legkevésbé sem. Ami még feltűnő lehet és következik a fentiekből:

• Az erőforrás kiszolgálónak, esetünkben a web szervernek, ismernie kell az ADFS azonosítási módszert. Hiszen már az elején tudnia kell, hogy az ADFS-hez át kell irányítani a felhasználót, valamint a folyamat végén az ADFS token formátumat ismernie kell.
• A kliensnek értenie kell a HTTP redirectet és támogatnia kell az egész folyamatot. A gyakorlatban megkülönböztetünk Active és Passzív klienst és a folyamat más az egyes klienstípusoknál. Ennek a részleteibe most nem megyek bele.

Az ADFS témában írt szerintem egyik legjobb könyv amit a kezdéshez bátran ajánlok az itt érhető el ingyen: http://www.microsoft.com/en-us/download/details.aspx?id=28362 Az ADFS alapos ismertetését nem vállalom blog formában, csak személyes oktatásban. Ezért ezen a ponton elégedjünk meg a koncepció szintű megértéssel és a bővebb információkért javaslom a könyv elolvasását.

Miért érdekes ez az Exchange esetében?

Az Exchange Server temékünk eddig nem támogatta az ADFS alapú azonosítást. Igen így-úgy nem támogatott módon bekapcsolható az ADFS alapú azonosítás, de azok nem működnek megfelelően, nem teszteltük őket alaposan és ezért nem is támogatott megoldások. Kiváló példa erre az, hogy ami ment Exchange 2010 SP1 esetében az már SP2 és SP3 esetében nem működik. Az Exchange Server 2013 SP1 esetében azonban ez változott. Ettől a verziótól kezdődően az ADFS alapú azonosítás használható, támogatott. Tehát a hagyományos NTLM vagy Kerberos vagy űrlap alapú azonosítás mellett lehetőségünk van arra, hogy ADFS alapú azonosítást használjunk. Ennek előnyei a következők lehetnek:

• Több AD forest esetén trust nélkül is tudunk SSO-t biztosítani
• Az Authorization során a csoporttagság helyett, gazdagabb információkat használhatunk a hozzéférés eldöntéséhez

Jelenleg csak az Exchange Server 2013 SP1 esetében támogatott az ADFS azonosítás használata.

Hogyan kezdjek hozzá egy tesztkörnyezetben?

Kezdésnek a következő elérési úton található dokumentációnkat javaslom: http://technet.microsoft.com/en-us/library/dn635116(v=exchg.150).aspx

A legfontosabb információk és tudnivalók:

• három claim-et kell használni: user SID, group SID és UPN
• csak az OWA és csak az ECP elérésnél támogatott és használható az ADFS azonosítás
• ha ADFS azonosítást használunk, akkor minden más azonosítást ki kell kapcsolni, tehát az ADFS azonosítással együtt nem mehet Integrált, Basic vagy űrlap alapú azonosítás
• az ADFS azonosítást per szerver, per virtual directory szinten kell beállítani a set-owavirtualdirectory parancs segítségével
• Orgnaizációs szinten be kell állítani azt, hogy mi az ADFS szerver elérési útja (innen tudja az Exchange, hogy hova kell átirányítani) és meg kell adni azt, hogy mi az ADFS token signing tanúsítvány.