Kormányablak, Ügyfélkapu, magyarorszag.hu, kormany.hu
KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT...
(nem hivatalos e-kormányzati témájú oldal)
  
BEMUTATKOZÁS 
E-KÖZIGAZGATÁS 
IT BIZTONSÁG 
  
































  Mottó:
Will things ever be
the same again?
It's the final countdown.
/Europe:
The final countdown/
2013. április 26.  
 Ó... IÓ... CIÓ... Authentikáció! 
   
Repül az idő: ismét itt van a nyakunkon a nyári szünet és eltelt a második év is az RSA SecurID adatszivárgás óta. Ennek alkalmából vettem elő az akkori Hogy alakul az OTP népszerűsége? bejegyzésemet és a HOTP-TOTP.PHP kódokat. A témának aktualitást ad, hogy azóta megszületett az OAuth protokoll v2.0 változata is, igaz - ahogy azt az OAuth protokoll atyja, Eran Hammer is kifejtette - ennek semmi köze ahhoz az egyszerű, interoperabilis leíráshoz, amit v1.0 (illetve a "sesson fixation" támadás javítása után v1.0a) változatként szabványosítottak.


Először azonban menjünk vissza egy kicsit az időben, nézzük meg az OAuth fejlődésének történetét, illetve hogy egyáltalán most hol kell elhelyezni a táplálékláncban!

Az OAuth v2.0 protokoll egy egyszeri, központi bejelentkezést biztosító, azaz "Single Sign-On" (SSO) keretrendszer, amely különböző engedélyezési formákat támogat.

A SSO protokollok közül talán a Kerberos (IETF RFC 4120) számít a legösszetettebbnek, nem véletlen, hogy többek közt a Microsoft Active Directory hátterében is Kerberos protokoll alapján zajlik a kommunikáció. Igény volt azonban egyszerűbb megoldásokra is, amelyek meg is jelentek a piacon. Jelenleg az egyik irányt, az SAML (Security Assertion Markup Language) keretrendszert az - XML-alapú szabványokat gyártó - OASIS képviseli, a másikat az OAuth protokollt gondozó IETF viszi.

A SAML v1.1, a Shibboleth v1.3 és a Liberty ID-FF v1.2 (Identity Federation Framework) egyesülésével 2005. márciusában létrejött a SAML v2.0 szabvány. A SAML v2.0 nagyobb rendszerek számára, illetve kormányzati megoldásokhoz is ajánlott, többek közt az Európai Unió által kiemelten támogatott STORK 2.0 (Secure idenTity acrOss boRders linKed) projekt is ezt a keretrendszert vette alapul és egészítette ki néhány kötelező és több opcionális elemmel. A STORK eredményeit a projektben résztvevő tagállamokban használják az e-közigazgatásban: Ausztria, Belgium, Észtország, Izland, Luxemburg, Németország, Olaszország, Portugália, Spanyolország, Svédország, Szlovénia, majd később csatlakozott a projekthez Finnország, Görögország, Litvánia, Norvégia, Szlovákia (a projektben megfigyelőként vett részt az Egyesült Királyság, Franciaország, Hollandia).

Az SAML keretrendszerhez képest még egyszerűbb megoldást nyújt az OAuth v1.0 protokoll, amely a WEB2.0 világában, a Twitter-nél született meg (Twitter OpenID), és gyakorlatilag egyenértékű a Kerberos rendszerekből ismert "Ticket Granting Service" (TGS) modullal. A protokoll v1.0 (2007. október) változatát egy biztonsági probléma miatt felülvizsgálták, majd a v1.0a (2009. június) változata az IETF szakemberei révén RFC specifikációként is napvilágot látott (IETF RFC 5849). Az IETF-nél azonban folytatódott a munka és elkezdték átdolgozni egy összetettebb, a SAML-hez hasonló keretrendszerré, aminek eredményeképpen az OAuth v2.0 változataként (2012. október) az új protokoll alapjait szintén kiadták RFC-ként (IETF RFC 6749). Bár, az eredeti céltól eltértek és így az OAuth v2.0 egy összetettebb, rugalmas, de emiatt kevésbé interoperabilis keretrendszerré vált, a WEB2.0 világában mégis többen áttértek rá. Mivel az OAuth v2.0 keretrendszer egyéb részei még kidolgozás alatt állnak, emiatt nincs is két olyan megvalósítás, amely ugyanúgy működne.

Jelenleg az alábbi OAuth változatot támogatják a felsorolt WEB2.0 rendszerek:


/forrás: http://en.wikipedia.org/wiki/OAuth /

Az OAuth v2.0 protokollra már van step-by-step útmutató pl. a Facebook oldalán, ami alapján össze is raktam egy kódot a HOTP-TOTP.PHP alkalmazásba. Találtam néhány eltérést a Facebook mintakód, illetve a szabványban (IETF RFC 6749) szereplő leírások között, ezeket módosítottam, javítottam (a rendszer így is működik).


/forrás: IETF RFC 6749 /

A modellben - a Facebook esetében - adott egy általunk írt pl. "képkezelő alkalmazás" (Client), ami hozzá akar férni egy Facebook "felhasználó" (Resource Owner) képeihez a Facebook "kép adatbázisban" (Resource Server). A hozzáférés engedélyezéséhez a "felhasználónak" (Resource Owner) sikeresen kell hitelesítenie magát, hogy meg tudja adni a kért hozzáférési jogosultságokat a Facebook "hitelesítő modulját" (Authorization Server) használva, illetve ugyanennél a modulnál kell a "képkezelő alkalmazásnak" (Client) is hitelesítenie magát.

Az "Authorization Request" kérésben a "képkezelő alkalmazás" (Client) elküldi a saját, korábban regisztrált azonosítóját (client_id), az igényelt jogosultságokat és a kért engedély típusát (response_type) a "felhasználó" (Resource Owner) felé. Ahogy a szabvány is írja, ezt megteheti közvetlen módon, de akár közvetve, magán a "hitelesítő modulon" (Authorization Server) keresztül is. A Facebook esetében is ez a közvetett mód került megvalósításra.

Az "Authorization Grant" válaszban a "képkezelő alkalmazás" (Client) megkapja a jogosultságokat a kért formában. A szabvány négy formát határoz meg: "authorization code", "implicit", "resource owner password credentials", "client credentials". A Facebook és a legtöbb megoldás, ami a "hitelesítő modulján" (Authorization Server) keresztül, azaz közvetve adja ki az engedélyt, az a - szabvány szerint - legfeljebb 10 percig érvényes és legfeljebb egyszer felhasználható "authorization code" típust alkalmazza. Fontos előnye ennek a többi típussal szemben (és egyben ez a típus valósítja meg az OAuth v1.0a elképzeléseit is), hogy a "felhasználónak" (Resource Owner) nem kell a tetszőleges harmadik fél által fejlesztett "képkezelő alkalmazásnak" (Client) kiadnia a Facebook jelszavát.

Az "Authorization Grant" kérésben a "képkezelő alkalmazás" (Client) elküldi az "authorization_code" értékét, illetve a saját, korábban regisztrált azonosítóját (client_id) a "hitelesítő modulnak" (Authorization Server). Ezután a "képkezelő alkalmazásnak" (Client) hitelesítenie kell magát, amit a Facebook úgy old meg, hogy a "képkezelő alkalmazás" (Client) az azonosítója mellett egyben a jelszavát (client_secret) is elküldi a paraméterezett URL-ben.

Az "Access Token" válaszban a "képkezelő alkalmazás" (Client) megkapja az engedélyt (access_token). Ezen engedély (access_token) előállításának módjára még kidolgozás alatt vannak a szabványok, az egyik lehetőség szerint "hmac-sha-256" algoritmust használva fogja kiszámítani értéküket a "hitelesítő modul" (Authorization Server).

Az "Access Token" kérésben a "képkezelő alkalmazás" (Client) elküldi az engedélyt (access_token) és a lekérendő adatok listáját (pl. képek azonosítóit) a "kép adatbázisnak" (Resource Server).

A "Protected Resource" válaszban a "képkezelő alkalmazás" (Client) megkapja a kívánt képeket a "kép adatbázistól" (Resource Server).

Próbáljuk ki ezt a gyakorlatban! Nem kell hozzá más, mint a HOTP-TOTP.PHP segédalkalmazás, egy PHP-t futtató kiszolgáló és egy Facebook fiók.

Először a Facebook oldalon be kell jegyezni az alkalmazást, hogy megkaphassa az azonosítót (client_id vagy App ID) és a jelszót (client_secret vagy App Secret). Be kell állítani a PHP kódot futtató kiszolgáló címét is (Canvas URL vagy Secure Canvas URL).


Be kell tölteni a böngészőbe a megadott kiszolgáló címét és a segédalkalmazás nevét.


A háttérben elküldésre kerülnek a szükséges üzenetek, majd a Facebook a felhasználó hitelesítését kezdeményezi. A jelen esetben az alkalmazás már felvételre került, ezért nem kell külön engedélyezni azt, hogy mihez férhet hozzá. A sikeres hitelesítés után a kért engedély kiadásra kerül.


A segédalkalmazás végül lekérdezi a személyes adatok közül a nevet és a felhasználóhoz tartozó Facebook azonosítókat.


Bár, a Facebook esetében ez az OAuth v2.0 működik, de látszik, hogy még sokminden kidolgozás alatt van. Az OAuth v1.0a esetében jól meghatározott kriptográfiai eljárások léteznek, pontos a kommunikáció folyamatának leírása. Az OAuth v2.0 egy keretrendszert akar adni, de számomra kérdéses, hogy tud-e versenyezni a már sokkal kiforrottabb SAML v2.0 protokollal. A SAML v2.0 egyelőre az e-közigazgatásban "erős", az OAuth v2.0 pedig inkább a WEB2 világában. Hogy mit hoz a jövő? Azt nem tudom, mindenesetre intő jel, hogy a Google App Engine az egyszerűbb protokollok közül az OAuth v1.0a, az összetettebbek közül pedig a SAML v2.0 támogatását vezette be az OAuth v2.0 helyett... Lehet, hogy ez lesz az általános felállás?

Kapcsolódó anyagok:
 vissza 
   
  info@kormanyablak.org
info@ugyfelkapu.info