Windows Azure lépésről lépésre, 12. fejezet – interjú és részlet

A tervek szerint március 12-én megjelenik a „Windows Azure lépésről lépésre”, az első magyar nyelvű szakkönyv a Microsoft felhőplatformjáról. Mostantól kezdve egészen a megjelenés napjáig minden munkanapon foglalkozunk a könyvvel: rövid interjúkat készítünk az egyes fejezetek szerzőivel, és egy-egy részletet is közzéteszünk a könyvből.

Ezúttal Kovács Gáborral beszélgetünk munkájáról, az Azure-ral való kapcsolatáról és a könyvben vállalt szerepéről.

Ne feledkezzetek el nyereményjátékunkról:
Ossz meg egy fejezetet, hívd meg a főnöködet, nyerj Azure-könyvet!


Az előző bejegyzések:

Kérlek, mesélj magadról néhány mondatot, mivel foglalkozol és hol?

A MatroIT Systems Kft.-nél foglalkozom Line-Of-Business rendszerek fejlesztésével. A jellemzően HTTP fölött működő elosztott architektúrák számára hasznos szolgálatot tesz a számítási felhő, mint masszív infrastrukturális háttér. .NET orientáltságú fejlesztők lévén kézenfekvő választásként az Azure-t használjuk erre a célra.

Mi a kapcsolatod a Windows Azure-ral?

A Windows Azure 2010-es magyarországi bevezetése óta figyelemmel kísérem a platform változásait, a megjelenő új feature-öket. A hétköznapi munkám során jelenleg is egy, a felhőszolgáltatásokat intenzíven használó nagyválallati rendszer fejlesztésével foglalkozom, így mondhatni a frontvonalból követem az Azure fejlődését.

Mivel ismerteti meg az általad írt fejezet az olvasót?

A fejezet három nagyobb témakört érint.
Elsőként a felhőbeli federált autentikációért felelős Access Control Service nevű komponensről esik szó. A témakör bemutatja a federált identitáskezelés általános modelljét, majd egy gyakorlati példán keresztül részletesen ismerteti, hogyan lehet az ACS-t integrálni egy meglévő webalkalmazásba a teljes user autentikáció workflow-jának kiszervezésére. Az egész témakör legfontosabb üzenete az alkalmazásfejlesztőknek szól: mindenféle kriptográfiai varázslat nélkül, gyakorlatilag next-next-finish módszerrel, percek alatt integrálható a federált hitelesítés az alkalmazásunkba.
A fejezet következő része az Azure Caching szolgáltatásról szól. Ez egy kevésbé izgalmas témakör, de mindenképp érdemes vele megismerkedni, hiszen ha a felhőben futó szoftvereket írunk, akkor kell egy kis szemléletbeli váltás a klasszikus cache-elési megoldásokhoz képest. A kötelező konfiguráció- és API ismertetések mellett a témakör egy érdekesebb része egy olyan gyakorlati problémára fókuszál, ami mindenkivel előfordul előbb vagy utóbb, aki egynél több példányban futtat web role-okat a felhőben: a virtuális gépek közti session információk megosztásáról. Erre több megoldás létezik az Azure-on belül is – én itt a gyakorlatban eddig legjobban bevált módszerrel, a Caching alapú session state provider-rel foglalkozom.
Végül az Azure Connect szolgáltatásról lehet olvasni. Ezzel megoldható, hogy a felhőben futó VM-eket és a telephelyünkön lévő gépeket virtuális hálózatba kapcsoljuk.

Milyen újdonságokat látsz a saját területeden?

Ha szigorúan az Azure-ra koncentrálunk, akkor elsőként azt emelném ki, hogy a felhőszolgáltatások egyre hatékonyabban integrálódnak a fejlesztői munkafolyamatba. Az idő múlásával egyre átgondoltabb grafikus felületeket, API-kat, konfigurációs- és infrastrukturális lehetőségeket kínál a platform. Ez pedig nélkülözhetetlen a produktív fejlesztői munkához.

Hogy ne csak általánosságokról essen szó, főként backend építéssel foglalkozó fejlesztőként két, viszonylag új Azure-os feature-t neveznék meg: Az egyik a Mobile Services, amivel a könyv egy másik fejezete is részletesen foglalkozik. A másik pedig az utóbbi időben egyre növekvő népszerűségű “big data” megoldások egyike, a még CTP fázisban lévő, jelenleg Hadoop on Windows Azure néven futó szolgáltatás.

Részlet a 12. fejezetből:

Az Access Control Service mint Federation Provider

A Windows Azure-ban a federált authentikációért felelős szolgáltatás (Federation Provider) neve Access Control Service (ACS). Az ACS amellett, hogy megvalósítja az FP-ktől általánosan elvárt funkciókat, további hasznos képességekkel is bír.
Az Azure-on keresztüli federált authentikáció számos IDP-vel kulcsrakészen működik. A Microsoft Account, a Facebook, a Google és a Yahoo! mellett bármely ADFS 2.0-t használó AD is egyszerűen felvehető IDP-nek. Az itt felsoroltakon kívül az ACS konfigurációja során tetszőleges SWT, illetve SAML 2.0 tokeneket kibocsátó szolgáltató felvehető a megbízható IDP-k listájára.

Az ACS az IDP-től kapott tokeneken nemcsak egyszerű „fogadd-és-továbbítsd” jellegű műveleteket képes végrehajtani, a beépített szabályértelmezőjének (rule engine) köszönhetően összetettebb token-transzformációs szabályok halmazát is megadhatjuk. Ez a képesség akkor bizonyul hasznosnak, ha az RP alkalmazásunkban az ACS-től kapott tokenben hordozott információk (claim) alapján szeretnénk authorizációs döntéseket hozni. Képzeljünk el egy olyan esetet, amikor több különböző nyelvű országból származó IDP-ket kell kezelni! Minden IDP elküldi a felhasználó csoport-információját egy claimben, de gyakran előfordul, hogy ezek lokalizált formában érkeznek meg az ACS-hez. Az ACS-en beállítható, hogy az eltérő nyelvi lokalizációval érkező, de azonos jelentésű claimek nevét azonos (leginkább angol) nyelvre transzformálja, és az RP alkalmazás felé már ilyen egységes formában továbbítsa. Hasonló, az authorizációt segítő szabályok állíthatók be például akkor, ha a felhasználónak igazolnia kell, hogy betöltött-e egy adott életkort az RP alkalmazás meglátogatásakor. Ilyenkor sok esetben követelményként merülhet fel, hogy az RP alkalmazás ne kapjon pontos információt a felhasználó koráról, csak annyi jusson el hozzá, hogy teljesíti-e a felhasználó az életkori limitációt. Egy ehhez hasonló szűrés is megoldható az ACS szabályértelmezőjével. Az IDP-ktől kapott bemenő tokenekben az ACS ellenőrzi az „életkor” claim értékét, és ha ez nagyobb, mint egy határérték, akkor a kimenő tokenben egy „életkor OK” nevű, Boolean típusú claimet igaz értékűre állít. Számos hasonló példát lehetne még felhozni a token-transzformációs szabályok hasznosságának érzékeltetésére. Általánosságban elmondható, hogy az ACS ezzel a képességével az RP-hez eljutó claimeken egyfajta előfeldolgozást hajt végre. Így az RP oldalán ezek kezeléséhez már kevesebb további feldolgozásra van szükség. Ennek köszönhetően az alkalmazásfejlesztő hatékonyabban tud tényleges feladatára koncentrálni, nem kell az ACS-től beérkező tokenek feldolgozásával foglalkoznia.

Az ACS további hasznos tulajdonsága, hogy az ACS és a beépítetten támogatott IDP-k (Microsoft Account, Facebook, Google, Yahoo!) közti hitelesítési protokollok menedzselése a Windows Azure hatáskörébe esik. Ez azért jó hír az alkalmazásfejlesztők számára, mert ha valamilyen változás történik az említett IDP-k által használt authentikációs eljárásban, akkor nem nekik kell gondoskodni az általuk fejlesztett alkalmazás oldalán a legfrissebb SDK telepítéséről. Az ACS ezt a feladatot leveszi a vállukról, gondoskodik róla, hogy mindig az éppen aktuális authentikációs mechanizmust használja az IDP-k felé.

Holnap a 13. fejezettel folytatjuk!

6 thoughts on “Windows Azure lépésről lépésre, 12. fejezet – interjú és részlet

  1. Visszajelzés: Windows Azure lépésről lépésre, 13. fejezet – interjú és részlet | Felhők között

  2. Visszajelzés: Windows Azure lépésről lépésre, 13. fejezet – interjú és részlet - A magyar Windows Azure közösség blogja - devPortal

  3. Visszajelzés: Windows Azure lépésről lépésre, 14. fejezet – interjú és részlet | Felhők között

  4. Visszajelzés: Windows Azure lépésről lépésre, 15. fejezet – interjú és részlet | Felhők között

  5. Visszajelzés: Windows Azure lépésről lépésre, 16-17. fejezet – interjú és részlet | Felhők között

  6. Visszajelzés: Windows Azure lépésről lépésre, 17. fejezet – interjú és részlet | Felhők között

Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s