(nem hivatalos e-kormányzati témájú oldal)
| Mottó: Csak egészség legyen, meg térerő! /Emil.RuleZ!: Térerő/ | ||
| 2016. június 8. | ||
| GSMA: mobil-login | ||
| Egyre gyakrabban hangzik el a felhasználó-hitelesítési technológiák kapcsán, hogy a jelszavak (legalábbis a kizárólag jelszavakkal működő rendszerek) ideje lejárt, de kérdés, hogy mi lesz helyettük? Lehet aszimmetrikus kriptográfiára épülő PKI chipkártyákat használni, de bizonyos helyzetekben nem jó az, hogy szükség van valamilyen olvasóra. Lehet szimmetrikus kriptográfiát alkalmazó egyszeri jelszavas megoldásokat használni, de ott meg problémát jelenthet, hogy macerás a kulcsmenedzsment. Lehet használni más jellegű megoldásokat is, de azoknak meg a biztonsági szintje, pontossága, körülményessége jelenthet problémát. (A biometriára most nem térnék ki, mert arról már írtam részletesen a Biometria: Tényleg minden jó, ami bio? bejegyzésemben.) A mobil operátorokat összefogó szervezet, a GSMA (Global Systems for Mobile Association) sem akar új dolgot elővenni, viszont a meglevő technológiákat ügyesen alkalmazza a Mobile Connect megoldásban. Nézzük meg, hogy mit is csináltak! Az OIDC (OpenID Connect) protokoll az OAuth v2.0 protokollt bővíti ki olyan módon, hogy önleíró adathalmazokat és felhasználói adatokat, attribútumokat is vissza tudjon adni kriptográfiailag védett módon, JSON Web Token formátumban. A GSMA (Global Systems for Mobile Association) megoldása, a Mobile Connect ehhez toldott hozzá még egy előtét réteget, amely a felhasználó telefonszáma alapján kikövetkeztetett mobil operátorhoz kapcsolódó adatokat (jellemzően web service URL-eket) kérdezi le a GSMA Discovery API felületen keresztül egy adatbázisból. OpenID Connect implements authentication as an extension to the OAuth 2.0 authorization process. [...] Information about the authentication performed is returned in a JSON Web Token (JWT) [JWT] called an ID Token [...].A folyamat kipróbálásához a fejlesztőnek először is regisztrálnia kell az alkalmazását a GSMA portálján (a nevet a "Description" mezőben, az URL értékét a "Redirect URI" mezőben megadva), majd a portál létrehozza az ehhez tartozó nyilvános azonosítókat ("Sandbox key", "Integration key") és titkos kulcsokat ("Sandbox secret", "Integration secret"). A fejlesztőnek be kell állítania, hogy mely mobil operátor adatbázisát használja (pl. "Sandbox operator" lehet az "Operator 1"), illetve - tényleges adatbázis híján - meg kell adnia legfeljebb öt telefonszámot ("MSISDN 1", "MSISDN 5"), amelyen majd pl. az SMS-eket lehet fogadni a beléptetés során. Az alkalmazás (pl. webshop) regisztrációja után az "Operator 1" szolgáltatóhoz tartozó felhasználó már meg is nyithatja a böngészőben és megkezdheti a használatát. A bejelentkezési folyamat első lépéseként az alkalmazás a háttérben lekér egy munkamenet-azonosítót ("session_id") a GSMA Discovery API felületétől. Ehhez a kérésben végre kell hajtani egy sikeres, alkalmazásszintű hitelesítést, amiből a felhasználó semmit sem lát (HTTP Basic Access Authentication Scheme révén végrehajtva, "Sandbox key" és "Sandbox secret" értékeket megadva). Az alkalmazás bekéri (pl. böngészőben) vagy betölti (pl. adatbázisból) a felhasználó telefonszámát ("MSISDN") és ezt elküldi a GSMA Discovery API felület felé az előbb lekért munkamenet-azonosító ("session_id") értékével együtt. Az ezen kérésre kapott válasz tartalmazza az adott felhasználó telefonszámához tartozó MCC (Mobile Country Codes) és MNC (Mobile Network Codes) értékeit, amik a mobil operátorokat egyértelműen azonosítják (a teljes lista itt tekinthető meg: http://www.mcc-mnc.com/ vagy https://en.wikipedia.org/wiki/Mobile_country_code), illetve adott szolgáltatónál az előfizető egyedi azonosítóját ("subscriber_id"). Az MCC és MNC körüli helyzet a számhordozás esetében bonyolódik, hiszen akkor a telefonszámban szereplő - Magyarországon a "36" országkód (CC - Country Code) után következő - hálózatkijelölő szám eltérhet a tényleges szolgáltató azonosítójától (pl. az eredetileg Vodafone előfizető telefonszámában a "70" szerepel, de számhordozás miatt az valójában már Pannon/Telenor operátorhoz tartozik). Szintén érdekesség, hogy ez a telefonszámban szereplő hálózatkijelölő szám eltérhet a tényleges MNC értéktől is (pl. Pannon/Telenor esetében "20" szerepel a telefonszámban, de az ehhez tartozó MNC érték "01" a táblázat szerint).
A folyamat következő része már az OAuth v2.0 protokollból ismert lépéseket tartalmazza. Először az adathozzáférési igényt kell összeállítani és elküldeni a felhasználó-hitelesítésre vonatkozó egyéb feltételekkel (pl. "acr_values" paraméterben az erősség szintjével) együtt az Authorization Endpoint felületre, amire egy egyedi tranzakciós azonosító ("authorization_code") kerül visszaadásra, ha a felhasználó jóváhagyja az adathozzáférést (az elvárt erősségi szinten végrehajtott sikeres felhasználó-hitelesítés után). A felhasználó-hitelesítés külön csatornán történik a mobil szolgáltató és a felhasználó eszköze között (SMS tárhely, böngésző, SIM applet segítségével - ld. a képeket alább). A visszaadott egyedi tranzakciós azonosító ("authorization_code") kerül leképezésre egy egyedi hozzáférési azonosítóra ("access_token") a Token Endpoint felületen, ha az alkalmazás is sikeresen hitelesítette magát a számára kiosztott adatokkal (HTTP Basic Access Authentication Scheme révén végrehajtva, "Sandbox key" és "Sandbox secret" értékeket megadva). A Token Endpoint felületről érkezik vissza egy másik adathalmaz is ("id_token"), ami többek közt tartalmazza a felhasználó azonosítóját (PCR - Pseudonymous Customer Reference), aki számára a hozzáférési engedély ("ticket") kiállításra kerül, ezen engedély érvényességi idejét, a felhasználó-hitelesítés biztonsági szintjét (LoA - Level of Assurance értéke, pl. "2" érték az "acr" elemben) és pontos módját (pl. "SIM_PIN" érték az "amr" elemben). Az egyedi hozzáférési azonosító ("access_token") birtokában lekérhetővé válik a jóváhagyott adathalmaz a UserInfo Endpoint felületről. A válaszban kerülnek visszaadásra a felhasználó törzsadatai (viselt név, e-mail cím, arckép, lakcím). A teszt rendszerben a két alacsonyabb szintű felhasználó-hitelesítés érhető el. Az "SMS+URL" és "USSD" (Unstructured Supplementary Service Data) megoldásnál egy egyedi azonosítót tartalmazó URL érkezik SMS üzenetben a felhasználó telefonjára, amelyre kattintva a szerver oldal érzékeli a megerősítést és továbbengedi a folyamatot. Az utóbbi, "USSD" megoldásnál az egyszerű kattintás nem elég, szükség van még egy PIN kód (pl. 1111) megadására is a webes felületen. A teszt rendszerben a legmagasabb szintű felhasználó-hitelesítés nem érhető el. A "SIM Applet" megoldás esetében a SIM kártyán tárolt - azaz legmagasabb védelmi szintű - applet alkalmazások számolják ki a kihívásra ("challenge") adandó válasz ("response") értékét PIN kód megadása után attól függően, hogy melyik applet vesz részt a megerősítésben (pl. egyszeri jelszó létrehozása szimmetrikus kriptográfiával vagy elektronikus aláírás létrehozása aszimmetrikus kriptográfiával).
Kapcsolódó anyagok: | ||
| vissza | ||
info@ugyfelkapu.info
