Web Application Proxy és ami körülötte van

Írásom célja az, hogy tisztázzuk, hogy mi ez a technológia, mert a félreértések melegágya. A Web Application Proxy (továbbiakban WAP) egy kiváló reverse proxy megoldás ami a Windows Server 2012 R2-ben jelenik meg. A release preview verzióban bent van.

A WAP a távelérési technológiánkat egészíti ki és a kép így most platform oldalról tökéletesen kerek (pár év múlva úgy is azt mondjuk majd, hogy hiányzik innen még pár építőkocka). Most ezek vannak:

• A Windows Server RDS Gateway -- segítségével VDI és Session host (aka terminal server) erőforrásokat tehetünk elérhetővé a felhasználóknak.
• Windows Remote Access --  segítségével VPN kiszolgálót és / vagy Direct Access kiszolgálót alakíthatunk ki, amivel a belső hálózatot tehetjük elérhetővé a felhasználóknak.
• WAP --  segítségével pedig a belső hálózatról tehetünk elérhetővé Web alkalmazásokat a felhasználóknak.

Kiválóan összefoglalták ezt már helyettem a következő dián:

A WAP architektúrát “200km magasból” szemlélve, helyesen így ábrázolhatjuk:

Lelkesen ezen a ponton csattanhatunk fel, hogy jéé hát ez kb. olyan mint a TMG. Közben pedig NEM. De még csak nem is UAG ez. Nem kísért itt semmiféle szellem, ez IT.

Lássuk be, hogy a WAP valóban alkalmas web alkalmazások publikációjára, de nem úgy mint a korábbi TMG / UAG páros bármelyike.

A WAP (jelenleg még) egy speciális eszköz ami a BYOD trendet támogatja. Biztosan mindenki találkozott már azzal az igénnyel, hogy a főnöke szeretné az új “retinaégető” eszközéről elérni a vállalati csoportmunka webhelyet, vagy böngészni a belső Intranet oldalt. A legkülönbözőbb válaszreakciók születnek erre az egyébként tökéletesen jogos igényre:

• OK, publikáljuk ki. – de ekkor nem csak a főnök fogja azt elérni és nem csak arról az eszközéről
• Nem, nem tesszük elérhetővé.– a főnök mérges lesz és azt fogja mondani, hogy nem vagyunk elég modernek
• Csináljunk VPN-t.– a főnöknek nem tetszik, kényelmetlen, nem tudja bedugni a smart-card-t stb.
• Használjunk DA-t.– a főnök ragaszkodik az eszközhöz, tehát nem lehet. Az IT közben jót szórakozik a DA-val és imádják.
• Csináljunk egy virtuális gépet a főnöknek és publikáljuk ki, RDP csak van az eszközén.– jó, de itt kolompot akasztottunk a pingvinek nyakába, vagy ha úgy tetszik akkor fából vaskarikát csináltunk, végül csak Windows-on köt ki a felhasználó. Ne feledjük, a főnöknek is van főnöke és kollegája és és és…szóval ez nem mehet a végtelenségig, vagy ha igen akkor az drága lesz, mert sok virtuális gépet kell majd futtatnunk.

Ha kicsit jobban belegondolunk, akkor észrevehetjük, hogy az alapvető probléma itt a következő (általában): nem akarunk a hálózatra csak úgy beengedni bármilyen nem menedzselt gépet. Ez egy nagyon régi probléma amire a történelem során már sok megoldást kiötlöttünk. A legújabb a WAP és nem ez az utolsó ebben biztos vagyok. Csak pár példa a múltból:

Nagyon NAP szagú a megoldáskészlet. Ami jó, mert egy csodálatos technológia. De vajon hány hazai vagy külföldi ügyfélnél van NAP? Két nagyobb hazairól tudok és ha a nagy ügyfelek nem vezették be tömegesen, akkor a kicsik sem. További hátrányai a NAP-nak:

• csak Microsoft platformon érhető el, a kezdeti Cisco együttműködés hamar elsüllyedt
• nincs lényegi reportolási lehetőség
• beépített ellenőrzési képességek nagyon nehezen egészíthetőek ki egyedi ellenőrzésekkel

Mindezt figyelembe véve már nem is annyira meglepő, hogy a NAP deprecated státuszba került a Windows Server 2012 R2 preview bejelentésével egyidőben. A Windows Server 2012 R2-ben és Windows 8.1-ben még bent van / lesz. Az újabb Windows verziókban azonban a jelenlegi információk szerint nem lesz többet. Bejelentés itt (több egyéb funkcióval): Features Removed or Deprecated in Windows Server 2012 R2 Preview

A fenti táblázatban levő technológiák amúgy is jó 5-10 évesek. 5-10 évvel ezelőtt a végfelhasználói eszközkészlet egészen másként nézett ki, mint napjainkban. Az akkori technológiákat hiába is forgatjuk, a mai eszközökkel és a mai felhasználókkal (igazából az elvárásaikkal, az igényeikkel) nem állnak össze egységgé. Valami más kell. Itt jön be a képbe a BYOD és a WAP. A BYOD és az alapvető probléma (nem akarunk a hálózatra csak úgy beengedni bármilyen nem menedzselt gépet) nagyon nehezen egyeztethető össze. De fúrjunk kicsit mélyebbre.

Mi számít menedzselt gépnek? Egyszerű megfogalmazás, de talán működik: az amiről az IT tud és amin az IT tud futtatni programokat. A menedzselt gépek általában kivételes helyzetben vannak, nekik szabad azt is, amit másnak nem, vagyis hozzáférhetnek olyan szolgáltatásokhoz is, amit más gépekről nem lehet elérni. Így hát a megoldás adott. Rendeljük hozzá egy felhasználóhoz az ilyen gépeket, akkor az IT már tud róla, bekerül a megfelelő technológiai rendszerekbe és máris tudunk ez alapján döntést hozni a hozzáférési kérelmek kiértékelése során. Natív Microsoft környezetben ez a legegyszerűbb dolog a világon. Be kell léptetni a számítógépeket a tartományba. De mi a helyzet az otthoni Windows géppel vagy a nem Windows alapú eszközökkel? Azokat nem tudjuk egyszerűen beléptetni a tartományba. Helyette valami más, lazább kapcsolat szükséges. Az új elképzelt világunkban ez az úgynevezett Wokrplace Join. A Workplace Join egy laza kapcsolat: a számítógép a vállalati környezet és felhasználó között.

A WAP pedig a Workplace Join egyik fontos pillére. A Workplace Join funkció segítségével regisztrálhatják a felhasználók a saját gépeiket az IT technológiai környezetében és így menedzseltté válik. Regisztrálni lehet a belső védett hálózaton keresztül, vagy az Interneten keresztül is. Ezt a regisztrációs az Internetre a WAP segítségével publikálhatjuk.

A WAP segítségével összességében publikálhatjuk:

• Workplace Join szolgáltatást
• A SyncFolder szolgáltatást
• Egyéb webes szolgáltatásainkat

A WAP egy nagyon egyszerű alkalmazás proxy kiszolgáló. Annyira egyszerű, hogy még Authentication (AuthN) és Authorization (AuthZ) szolgáltatást sem tartalmaz. Ezek a funkciók teljesen outsource jellegű kiszervezésben vannak. AuthN és AuthZ szolgáltatást ADFS biztosítja. Egy aránypárral tudom ezt az összefüggést a legjobban leírni:

• A RADIUS szerver úgy aránylik az ISA-hoz, ahogy az ADFS aránylik a WAP szerverhez

Tehát ha ismered a RADIUS és ISA kapcsolatát, akkor részben ismered az ADFS és a WAP viszonyát is.

A WAP szerver nem dönti el, hogy van-e hozzáférésed vagy sem. Egyszerűen továbbítja a kérést az ADFS szervereknek és majd azok döntenek a szabályrendszer alapján. Azonban tudni érdemes, hogy a WAP szerver nem játssza el a színjátékot a kliens felé. A kliens valójában egy ADFS azonosítással és annak végeredményével (ADFS cookie) találkozik.

Nézzünk egy egyszerű példát. Adott egy Web Application Proxy, egy ADFS környezet és egy fontos üzleti alkalmazás (LOB). A LOB alkalmazás a https://lob.fabrikam.com címen van publikálva, az ADFS pedig a https://sts.fabrikam.com elérési úton. Az architektúra így néz ki:

Az azonosítási folyamat a következő (nagyvonalakban):

• A user csatlakozik a WAP szerverhez és szeretné elérni a https://lob.fabrikam.com címen az alkalmazást
• A WAP szerver ellenőrzi a konfigurációját, hogy ilyen alkalmazás publikálva van-e, ha igen, akkor a kliensnek visszaküld egy HTTP 302-es üzenetet (redirect) és átirányítja azt az ADFS szerverhez. Ebben a redirectben azt mondja a kliensnek válaszként, hogy a https://sts.fabrikam.com–hoz csatlakozz.
• Az ADFS szervert a WAP publikálja, tehát a kliens visszajut a WAP szerverhez, de ezúttal a kérése az, hogy az ADFS szerver adjon neki egy ADFS sütit. A WAP szerver a felhasználó nevében egyeztet az ADFS szerverrel. A kliens által küldött ADFS auth kérésben szerepel az is, hogy melyik szolgáltatáshoz szeretne hozzáférni, ami esetünkban a https://lob.fabrikam.com.
• Az ADFS szerver megvizsgálja a kérést, egyeztet az Active Directory-val és dönt, hogy a felhasználó az adott alkalmazást elérheti-e vagy sem. Technikailag ezen a ponton van lehetőség arra is, hogy megvizsgálja, hogy az adott kliens gépről is elérheti-e a felhasználó az adott alkalmazást (aka végpont azonosítás, a cél azonos mint a NAP esetében). Ha a felhasználó elérheti, akkor a WAP-on keresztül egy ADFS sütit visszaküld a felhasználónak, amit a gépén tárolunk.
• A felhasználó az ADFS sütivel együtt újra megpróbálja elérni a https://lob.fabrikam.com alkalmazást. Az ADFS sütit a WAP szerver elfogadja és Kerberos Constrain Delegation (KCD) segítségével a felhasználót megszemélyesítve továbbítja a kérést a LOB alkalmazásnak. A LOB alkalmazás azt látja, hogy bejövő kérés a felhasználó nevében (user security context) érkezik. Méghozzá Kerberos azonosítással.
• ahhoz, hogy a KCD működjön, a WAP szervert fel kell jogosítani arra, hogy Kerberos Delegation-t használhasson, méghozzá KCD-t. Ez röviden annyit tesz, hogy az általa bármilyen azonosítási protokollal, de azonosított felhasználók nevében Kerberos ticket-et igényeljen és azzal érje el az alkalmazásokat.

Most már nagyjából látjuk és értjük, hogy mire való a WAP szerver és hogy egy azonosítási folyamat miként megy végbe. Egy fontos témakört azonban még nem hoztam elő. A WAP szerver segítségével nem csak ADFS azonosítást használva publikálhatunk alkalmazásokat.

Összesen két módszer van a publikálásra:

• ADFS – a korábban ismertetett működési móddal. A publikált alkalmazásnak támogatnia kell a Kerberos azonosítást. A kliens oldali alkalmazásnak támogatnia kell az ADFS azonosítást.
• Pass-through– ebben az esetben nem történik a WAP szerveren azonosítás. Egyszerűen pre-auth nélkül publikálhatjuk a webes alkalmazásainkat az Internetre. Az alkalmazásnak nem kell ismernie a Kerberos azonosítást, a klienssel szemben nincs semmilyen követelményünk.

A WAP szerver igazi előnye a TMG / UAG párossal és a NAP integrációval szemben az ADFS alapú azonosítás használatával élvezhető. Pass-through módban publikált alkalmazások esetében nincs semmi lényegi előnye. És ezen a ponton kell, hogy összeálljon a kép minden Exchange és Lync adminisztrátornak. Amennyiben még nem teljesen tiszta, akkor az alábbi kérdéseket próbáljuk megválaszolni:

• Az Exchange / Lync támogatja a Kerberos azonosítást?– részben. HA környezetben alapértelmezett módban nem működik a Kerberos azonosítás. Extra konfigurációt igényel amit nagyon-nagyon kevesen végeznek el. Az Exchange Server 2013 esetében pedig extra komplikált ez a beállítás és a pre-Vista klienseket részben kizárjuk.
• Az Outlook / Exchange ActiveSync / Lync kliens támogatja az ADFS azonosítást?– Nem. Nincs sok magyaráznivaló. Nem és kész.

A fentiek okán Exchange és Lync esetében a legtöbb amiben szakmailag gondolkodhatunk az egy Pass-Through módban történő publikálás a WAP-al. De miért tennénk ezt? Ha most UAG / TMG segítségével publikáljuk, akkor nincs ok amiért a WAP-ra kellene váltanunk. Csak veszíthetünk vele. Pre-authentikálni nem tudjuk a kéréseket és látható, érthető – legalábbis remélem az előző sorok alapján –, hogy a WAP a BYOD iniciatíva mentén egy szép új modern világra készült. A legacy szolgáltatások publikációjának kiváltása nem cél.

A WAP, a BYOD, a Workplace Join, a végfelhasználói eszköz azonosítása stratégiailag fontos irány számunkra a publikációban. A TMG és az UAG nem romlott el az elmúlt 1 évben, szóval lecserélése még nem indokolt. A végfelhasználói eszközök és az alkalmazott programok számára az ADFS azonosítás egyre nagyobb teret fog kapni a következő időszakban. De ma még nem ez a helyzet. Ha mindezt most összefőzzük, akkor a végszámlán az szerepel, hogy a WAP-al ne akard publikálni az Exchange és a Lync alkalmazást. Még ha esetleg azt is mondjuk, hogy pass-through módban támogatott lesz. Használd bátran tovább a TMG / UAG páros neked tetsző változatát, ahogy tetszik. A WAP-al ma még nem ez a célunk. Azonban a BYOD, a Workplace Join, a böngésző alapú alkalmazások esetében az irány tiszta. Itt az idő ezzel a szép új világgal megismerkedni és kialakítani, mert a trend nyílvánvaló, a haszon az IT és a végfelhasználó számára szintén könnyen belátható és értelmezhető.

u.i.: igen a képeket a korábbi konferencia előadásainkból ollóztam össze.