SSO rendszerek

A Kir-Dev legutóbbi bejegyzésében olvashattatok róla, hogy néhány hónapon belül megszűnik a VIR SSO és a helyét egy a KSZK által üzemeltetett központi rendszer veszi át. Ebben a cikkben az OAuthról, mint technológiáról szeretnék kicsit mesélni, ugyanis az adatszolgáltatás ezen keresztül lesz megvalósítva az új rendszerben.

A probléma

A lakossági informatikai rendszerekbe alapvetően felhasználónév/jelszó párossal szokás bejelentkezni (hiszen nincs mindenkinek otthon ujjlenyomat olvasója vagy retina szkennere, de még ha lenne is akkor is egy eléggé személyes adatról beszélünk). Maga az internet is egy ilyen lakossági rendszer és ez a bejelentkezési módszer teljesen jól működik rajta, vagyis hát működött elég sokáig. A problémát az okozza, hogy az internet terjedésével és a rajta található tartalom mennyiségének robbanásszerű növekedésével megsokszorozódott azon oldalak száma, amely használatához regisztrálnunk kell. Ez önmagában még nem lenne probléma, de az emberek hajlamosak ugyanazt a felhasználónév/jelszó párost mindenhova megadni (hiszen kitől lenne elvárható, hogy n+1 jelszót megjegyezzen), azaz elég az egyik ilyen rendszert feltörnie egy támadónak és a benne található felhasználónevek és jelszavak segítségével jó eséllyel hozzáfér az adott felhasználó által használt más oldalakhoz is. A másik ilyen probléma az üzemeltetéssel van, azaz minden egyes oldalnak egyénileg kell a felhasználóit menedzselni, jelszavaikat és egyéb érzékeny adataikat megfelelően tárolni.

Van megoldás: SSO

Az SSO (Single sign-on, magyar fordításban kb. egyszeri bejelentkezés) rendszerek lényege, hogy a felhasználó adatait nem az adott rendszer tárolja, hanem egy harmadik fél és ez végzi ez az azonosítást. SSO rendszernek tekinthetőek a Kerberos alapú megoldások (linux és windows alapon is) vagy akár a Smart Card rendszerek is. Fontos kritérium az SSO-val szemben, hogy a felhasználónak csak egyszer kelljen bejelentkeznie. Szemléletes példával nem SSO rendszer az otthoni windows, ahova belépünk a jelszavunkkal, majd az e-mail fiókunkba (ami ugyanonnan authentikál, de újra bekéri a jelszavunkat). Ezzel szemben a céges, domainbe léptetett windowsos gép, ahol elég csak bejelentkezéskor megadnunk a jelszavunkat és onnantól elérjük az e-mailjeinket és a védett hálózati megosztásokat is a jelszó ismételt megadása nélkül, SSO rendszernek tekinthető.

Jelen cikkünk alanyai a webes SSO rendszerek, melyek közül 3 különböző megoldást fogunk tárgyalni, ezek a következők:

• OpenID
• OpenSSO, illetve a manapság használt változata, az OpenAM
• OAuth

Mielőtt továbbmennénk, tisztázzunk két fogalmat. Egyik az Identity Provider (IdP), azaz az azonosítást végző és a felhasználó adatait központilag tároló szolgáltatás (service), másik pedig maga az alkalmazás, amit Consumernek vagy Service Providernek (SP) hívnak.

OpenID

Az OpenID arra az elvre épül, hogy a felhasználónak egy személyazonossága legyen és azzal beléphessen bármely weboldalon. Maga a rendszer elvileg decentralizált, tehát bárki üzemeltethet IdP-t és bárki használhatja is az ezeket “igazolványként” az OpenID-t támogató weboldalakon. Azért elvileg, mert például anno amikor a Google bevezette az OpenID támogatást, ugyan lehetett használni a Google identitást külső weboldalakon, azonban visszafele ez már nem volt igaz, tehát pl. egy Yahoo-s identitással nem lehetett belépni a Google alkalmazásaiba. A belépéshez meg kellett adni az identitásunkat tároló IdP címét, majd a weboldal átirányított minket a megadott címre, ahol beléptünk és sikeresen azonosítás esetén visszakerültünk a megfelelő weboldalra. A protokoll az azonosítás mellett alkalmas bizonyos adatok átadására is az SP-nek, így például a weboldal megkaphatja az e-mail címünket. Az OpenID eredetileg 2005-ben került kifejlesztésre és viszonylag rövid idő alatt nagy népszerűségre tett szert (2009-ben több mint 1 milliárd OpenID account létezett szerte a világban és körülbelül 9 millió weboldal rendelkezett OpenID támogatással a belépéshez). Mára azonban a rivális technológiák és az időközben felmerülő biztonsági problémák miatt jelentősen veszített népszerűségéből, a nagy szolgáltatók pedig már vagy nem támogatják vagy korlátozott támogatási időt biztosítanak (a Google például 2015. április 20-ig biztosítja a szolgáltatás elérhetőségét).

OpenSSO / OpenAM

Az OpenSSO a Sun Java System Access Manager nevű termékén alapult és nyílt szabványokra építkezett. A rendszer számos funkcióval rendelkezett, többek között felhasználókezelés, autentikáció, autorizáció, federáció és a folyamatok naplózása. Előnyei közé tartozik, hogy a felek közti kommunikáció szerver szinten történik (a kliens szerepét az úgynevezett SSO agent látja el), az alkalmazásnak maximum az azonosítás elindításával és a kapott felhasználói adatok kezelésével kell foglalkoznia. A weboldal az adatokat a futtatókörnyezettől tudja lekérdezni (php-ban pl. a $_SERVER tömb tárolja), de akár az webszerver konfigurációs állományaiban is definiálhatunk a felhasználóra kritériumokat, amelyeknek meg kell felelnie, különben a szerver elutasítja a kapcsolódási kísérletet. Ilyen kritérium lehet, hogy rendelkezzen érvényes felhasználói fiókkal, de akár egy adott csoporttagságot is megkövetelhetünk. A megoldás másik nagy előnye, hogy OpenSSO-s használó és az ezzel kompatibilis rendszerek (pl. Shibboleth) összekapcsolhatók, azaz a federációban levő IdP-k közt átjárás biztosított (magyarán egy védett debreceni könyvtári oldalra be lehet lépni a BME-s azonosító segítségével).

Az OpenSSO halálát a Sun 2010-es Oracle általi felvásárlása okozta. Az Oracle rendelkezett egy rivális termékkel (Oracle Access Manager), így nem volt érdekelt egy ingyenes, nyílt forrású termék fenntartásában . Az OpenSSO-t használók szerencséjére azonban a ForgeRock felkarolta a projektet, átnevezték a terméket OpenAM-re és folytatták a fejlesztést az eredeti Sun-os ütemterv szerint.

A Schönherzes infrastruktúrából ugyan ki fogjuk iktatni ezt a fajta megoldást, Magyarországon és a világban továbbra is számos rendszer használja. BME-s hallgatók számára a legismertebb (a VIR mellett természetesen) az egyetemi címtár lehet (ez nem OpenAM-t, hanem Shibboleth-et használ). Emellett nagy banki rendszereknél (Erste), vagy telekommunikációs cégeknél (Magyar Telekom, Vodafone) is belefuthatunk.

A politikai korrektség érdekében megemlítendő, hogy az OpenAM tud mind OAuth kliensként, mind OAuth providerként is működni.

OAuth

Ezzel el is érkeztünk jelen bejegyzés fő témájához, az OAuth (az OpenAuth rövidítése) protokollhoz. Magának a protokollnak két verziója létezik az 1.0 (illetve annak javított változata, az 1.0a) és a 2.0.

1.0

Az OAuth 1.0 az OpenID mellékhajtásaként indult, mégpedig 2006-ban a Twitter fejlesztőinek közreműködésével. Szerették volna bevezetni az OpenID-t, azonban ez a megoldás nem biztosított megfelelő hozzáférhetőséget a Twitter API-jához. Olyan megoldásra volt tehát szükségük, ami nem csak a felhasználók autentikációját teszi lehetővé, de az erőforrásokhoz is kontrollált hozzáférést biztosít. A fejlesztői csoport 2007. áprilisában létrehozta a fejlesztést koordinálására az OAuth levelezőlistát, októberre pedig el is készültek a OAuth Core 1.0 final drafttal.

De hogy is működik?

Az OAuth-nál négy szereplőt különböztetünk meg. Ezek a következők:

• Resource owner: az erőforrás tulajdonosa, azaz a felhasználó.
• Resource server: az erőforrást (pl. egy API) tároló szerver.
• Authorization server: az azonosítást végző szerver, sok esetben azonos a Resource serverrel.
• 3rd party client vagy OAuth client: az oldal / alkalmazás, amely szeretne hozzáférni az adatokhoz.

Fontos, hogy OAuth esetén az Authorization servernek minden esetben tudnia kell a 3rdparty clientről ahhoz, hogy utóbbi autentikációs / autorizációs kérelmet indíthasson. Erre általában rendelkezésre szokott állni egy alkalmazás regisztrációs oldal, ahol különböző adatok megadása után kap a fejlesztő egy felhasználónév / jelszó párost, amivel az alkalmazás kapcsolódhat az Authorization serverhez.

A folyamat maga a következő lépésekből áll (lásd ábra):

1. Az OAuth kliens (azaz az alkalmazás) ideiglenes hitelesítési adatokat kér a hitelesítési folyamathoz. Ez megkülönbözteti az egyes OAuth ügyfélkéréseket.
2. Az OAuth szerver hitelesíti a kapott kérést és visszaküldi a szükséges adatokat.
3. A felhasználói jóváhagyáshoz a kliens átirányítja a felhasználót az OAuth szerver megfelelő oldalára, ahol megteheti ezt.
4. A jóváhagyás birtokában a felhasználó visszakerül a klienshez.
5. Megtörténik az access token kérelem kiállítása, majd ez átküldésre kerül a szervernek.
6. A szerver aláírja az access tokent, mely így érvényessé válik, majd visszaküldi a kliensnek.
7. A kliens az access token segítségével hozzáférést kap az erőforráshoz

Bonyolultnak tűnik? Annyira nem az, de a dolgot bonyolítja, hogy 1.0 esetén a kliensnek minden egyes kérést alá kell írnia egy halom olyan információ segítségével, amit csak ő ismerhet. Ez a kommunikáció biztonságát szavatolja, de egyben meg is nehezíti az implementálást. Persze ezen lépések nagy része az OpenSSO-nál is megtalálható, de ott a két szerver (IdP és SSO agent) között zajlik le, nem pedig az alkalmazás és az OAuth szerver között, azaz ebben az esetben a fejlesztőnek kell elvégeztetnie az alkalmazással a fenti lépéseket, míg OpenSSO-nál csak használnia kell a kapott adatokat.

A fenti folyamatot “3-legged OAuth” -nak nevezzük a résztvevők száma miatt (felhasználó, alkalmazás, szerver). Létezik “2-legged OAuth” is, amikor az alkalmazás már korábbról rendelkezik a felhasználói jóváhagyással, így anélkül tud “beszélni” a szerverrel, hogy ehhez ismételten a felhasználó engedélyét kérné.

Az Oauth 1.0 rövid idő alatt nagy népszerűségre tett szert, a nagyobb webes szolgáltatók (Facebook, Google, Twitter) mind átálltak erre és csak ennek segítségével lehetett hozzáférni az API-hoz.

2.0

Az OAuth népszerű volt, de voltak gyermekbetegségei:

• egy átlagos webfejlesztő számára problémát okozhatott az implementálása
• csak böngészőből volt használható, ami problémát jelentett az időközben robbanásszerűen elterjedő okostelefonok és a rajtuk futó alkalmazások számára

A fenti okok miatt a fejlesztők a 2.0-ás változat kifejlesztése mellett döntöttek, ez jó pár évig eltartott és nem kevés drámával járt.

A 2.0 a következő főbb területeken változott az 1.0-hoz képest:

• A https használata kötelezővé vált minden olyan kommunikáció során, ahol token kerül kiállításra. Erre azért volt szükség, hogy elhagyhassák a sok kényelmetlenséggel járó aláírást a tokenkezelésnél.
• Az API elérésnél sem szükséges a továbbiakban az a tokenek aláírása, itt a https használata is csak erősen javasolt.
• Miután a token kiállításra került, az OAuth 1.0-nál minden egyes API kéréshez két biztonsági tokent kellett küldeni, ráadásul ezeket alá is kellett írni. A 2.0-ás változatnál csak egy biztonsági tokenre van szükség és ezt sem kell aláírni.
• Sokkal jobban szétválasztásra kerültek a szerepkörök, így könnyebb a meglévő API-hoz illeszteni az OAuth autorizációt.
• Nem szükséges hozzá böngésző, így pl. mobilalkalmazások is használhatják.

Fontos, hogy a 2.0 semmilyen tekintetben nem kompatibilis az 1.0-ás változattal (többek közt az aláírás elhagyása miatt), így nem vegyíthető a két megoldás (persze támogatni mindkettőt lehet, de jól el kell különülnie a folyamatnak).

A változtatások szükségességét jelzi, hogy többen már fejlesztés közben váltottak, például a Facebook Graph API a kezdetektől a 2.0-ás változatot használta. Mára elkészült a végleges változat és sokan átálltak az új változatra, a korábbi 1.0-ás interfészeket pedig már lekapcsolták vagy adott határidőn belül le fogják kapcsolni. Ugyanakkor megjegyezendő, hogy ma is van aki az 1.0a-t (ez egy biztonsági javítás az 1.0-hoz) használja, illetve előfordul, hogy a túl hamar átállók (pl. a Facebook) nem a végleges változatot, hanem egy fejlesztés közbeni draftot használnak.

OpenID vs. pseudo-authentication OAuth segítségével

Mint írtam, az OAuth elsősorban autorizációs protokoll, de használható autentikációra is.

OpenID vs. OAuth

OpenID esetében az alkalmazás egy autentikációs kérést indít a felhasználó által megadott OpenID URI segítségével egy tetszőleges OpenID szolgáltató felé.

OAuth-nál ezzel szemben az alkalmazás kiállít egy kulcsot, melyet átad aláírásra a szervernek. A jóváhagyás után ezzel a kulccsal fér hozzá a felhasználói adatokhoz.

A fő különbség tehát abban áll, hogy az alkalmazás kiben bízik meg (OpenID-nél egy – akár – vadidegen providerben, OAuth-nál viszont a saját maga által kiállított kulcsban).

OAuth a Schönherzben

Az AuthSCH projekt keretében az OAuth 2.0-ás változatát fogjuk használni (mivel egyszerűbb implementálni és mobillal is használható). Két biztos felhasználója már van a szolgáltatásnak, az új AdminSCH (igen, készül új változat) már ezen keresztül fog belépést biztosítani, illetve a PÉK-be (Profil és Körök, alias VIR) is itt fogtok tudni belépni nyártól kezdve. A rendszer azonban nem lesz zárt, bárki csatlakoztathatja a weboldalát és használhatja az API-t. Ezen keresztül olyan adatokat is elérhettek majd (pl. naprakész szobaszám kollégisták esetén, természetesen csak a felhasználó jóváhagyásával), amelyekre eddig OpenSSO-n keresztül sem volt lehetőség. A rendszer már van olyan állapotban, hogy ha szeretnétek, el lehet kezdeni hozzá weboldalakat/alkalmazásokat fejleszteni. Aki így szeretne tenni, az jelezze alul a hozzászólásoknál és megbeszéljük a részleteket. Ugyanígy az esetleges kérdéseket is nyugodtan írjátok meg alul.