Masarykova univerzita Fakulta informatiky

Integrace Facebook Connect a OpenID/OAuth pro portál GateIn! Diplomová práca Bc. Matej Kobza Brno, 2014 Prehlásenie Prehlasujem, že táto práca je mojím pôvodným autorským dielom, ktoré som vypracoval samostatne. Všetky zdroje, pramene a literatúru, ktoré som pri vypracovávaní používal alebo z nich čerpal, v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj. V Brne, dňa 7.1.2014 Bc. Matej Kobza Vedúci práce: Mgr. Marek Grác, Ph.D. Poďakovanie Ďakujem vedúcemu mojej diplomovej práce Mgr. Marekovi Grácovi, Ph.D. za jeho ochotu, trpezlivosť, odborné vedenie a pomoc, ktorú mi pri práci poskytol. Ďalej by som rád poďakoval Mgr. Marekovi Posoldovi za odbornú pomoc a jednotlivé tipy, ako postupovať pri vypracovávaní portletov v tejto práci. Zhrnutie Diplomová práca sa zaoberá problematikou prihlasovania pomocou účtov sociálnych sietí ako sú Google+, Facebook či Twitter. Nájdením optimálneho riešenia, ktoré by bolo neskôr pridané do implementácie portálu GateIn. Na záver vytvorením základného mechanizmu prihlasovania a návrhom demo portletov, ktoré pristupujú k zabezpečeným zdrojom na strane Google alebo Facebook. Prvotným predpokladom mojej práce bolo štúdium danej problematiky a vybranie riešenia, ktoré by mohlo byť použité s portálom GateIn. Následne vytvorenie sady portletov, ktorých úlohou je demonštrovať celý proces prihlasovania a sprístupniť malú časť funkcionality služieb daného poskytovateľa identity. V diplomovej práci sa zaoberám technológiami ako OAuth, OpenID či OpenSocial, ktoré by mohli byť potenciálnymi riešeniami daného problému, ich porovnaním a vybraním ideálneho riešenia. Podstatná časť mojej práce je venovaná samotnej implementácii portletov, ktoré by komunikovali so službami Google a Facebook. Kľúčové slová GateIn, OAuth 2.0, OpenID, OpenSocial, Autentizácia, PortletBridge, Portlet Obsah Úvod...... 1 Možnosti poskytovania identity aplikáciám tretích strán...... 3 OpenID...... 4 Bezpečnostné riziká spojené s použitím OpenID 6 SAML...... 6 Bezpečnostné riziká spojené s používaním protokolu SAML 7 OAuth...... 8 Bezpečnostné riziká spojené s používaním OAuth 9 Federatívne identity...... 9 Google, Facebook a Twitter ako poskytovatelia identity...... 11 Google...... 12 Facebook...... 14 Twitter...... 15 Špecifikácia OAuth a možnosti využitia pre portál GateIn...... 16 História...... 16 Špecifikácia...... 18 Terminológia...... 18 2-Legged, 3-Legged, n-Legged...... 20 Prihlasovacie údaje a tokeny...... 20 Rozdiel medzi OpenID a OAuth...... 21 Jedná sa o nový koncept?...... 21 Implementácia OAuth do portálu GateIn...... 23 GateIn...... 23 PortletBridge...... 23 JavaServer Faces...... 24 Context and dependency injection...... 25 Štruktúra modulov...... 25 Implementácia protokolu OAuth od Google...... 27 Použitie OAuth 2.0 prvej verzie...... 28 Použitie OAuth 2.0 neskoršia verzia...... 29 Google Console...... 30 Získanie rozšíreného tokenu...... 31 Portlety...... 32 Implementácia protokolu OAuth od Facebook...... 34 Výber správnej knižnice...... 34 Implementácia OAuth 2.0...... 35 Facebook Apps...... 36 Portlety...... 37 Problémy, ktoré pri práci vznikli...... 38 Záver...... 41 Použitá Literatúra...... 43 Úvod

V dnešnej dobe sa veľmi často stretávame s možnosťou prihlasovania do rôznych webových stránok, elektronických obchodov a internetových služieb pomocou jediného kliknutia myšou na tlačidlo, ktoré hovorí: "Prihlásiť pomocou Google" alebo "Prihlásiť pomocou Facebooku". Tento prístup prináša značné výhody. Asi najväčšou z nich je odbúranie povinnosti vypĺňania zložitých formulárov pre získanie základných informácií o užívateľovi. Žijeme v čase sociálnych sietí. Facebook, Twitter, Google+, LinkedIn ... sa stali v posledných rokoch neoddeliteľnou súčasťou našich životov. Hovorí sa, že kto sa nenachádza ani na jednej z týchto sietí, akoby ani neexistoval. Vysoké percento mladých ľudí dnes vlastní inteligentný telefón. Takýto telefón ponúka rôzne možnosti prepojenia so sociálnymi sieťami. Stále častejšie vznikajú rôzne aplikácie od nezávislých vývojárov, ktorí sa predbiehajú v tom, kto prinesie lepšiu, atraktívnejšiu aplikáciu pre mobilné platformy. Rovnako začali vznikať aj portálové riešenia, ktorých úlohou je združovať komunikačné kanály týchto sietí. Ponúkajú užívateľovi lepšie možnosti pre prístup k svojim kontaktom, otvárajú nové možnosti v oblasti rozširovania virtuálneho života vo svete v internetu. Na základe tohoto precedensu prišla potreba poskytnúť vývojárom aplikácií tretích strán overený, zabezpečený prístup k API sociálnych sietí. Každá zo sietí sa tejto úlohy ujala svojím spôsobom a vytvorili veľké množstvo rôznych postupov. Cieľom mojej práce je preskúmať problematiku prihlasovania do sociálnych sietí. Hlavným bodom záujmu sú pri tom siete Google+, Facebook a Twitter. Vytvoriť súhrnnú analýzu a vybrať optimálne riešenie, ktoré by mohlo byť použité pre prepojenie s portálom spoločnosti Red Hat s názvom GateIn. Vybrané riešenie implementovať do malej sady portletov, ktoré budú používať java špecifikáciu Portlet JSR-286 a PortletBridge zloženú zo špecifikácií JSR-301 a JSR-329. V prvej kapitole sa venujem problematike poskytovania identity aplikáciám tretích strán. Nachádzajú sa tu rozobraté základné dostupné protokoly, pomocou ktorých je možné bežne overiť identitu užívateľa. Popis ich fungovania, silné a slabé stránky. V druhej kapitole píšem o možnostiach použitia týchto protokolov u konkrétnych poskytovateľov identity. Teda u Google, Facebook a Twitter. Na

1 záver na základe zhrnutia vyberám optimálne riešenie pre implementáciu do portálu GateIn. Špecifikácii protokolu OAuth venujem tretiu kapitolu, ktorá detailnejšie popisuje celé jeho fungovanie, históriu, terminológiu a špecifiká, ktoré u tohoto protokolu môžeme nájsť. V štvrtej kapitole analyzujem portál GateIn. Zhrnutie dostupných technológií, ktoré bolo potrebné použiť počas implementácie, a načrtávam spôsob rozčlenenia práce do jednotlivých modulov v implementačnej časti. V piatej a šiestej kapitole podávam detailný popis samotnej implementácie protokolu OAuth 2.0 podľa dokumentácie, ktorú je možné nájsť u jednotlivých poskytovateľov identity Facebook a Google. Posledná, siedma kapitola oboznamuje s problémami, ktoré sa objavili počas prieskumu a implementácie v diplomovej práci. Poskytuje lepší náhľad k ich vysvetleniu a pokusom o vyriešenie. Taktiež vyhodnocuje, ktoré z problémov sa podarilo viac či menej úspešne vyriešiť a ktoré naopak vyriešiť nebolo možné.

2 1. Možnosti poskytovania identity aplikáciám tretích strán

V čase, kedy som si vyberal diplomovú prácu, ma zaujala téma integrácie sociálnych sietí, nakoľko bola podobná tomu, na čom som pred nejakým časom pracoval v súkromnom sektore. Jednalo sa o problém, ako pristupovať zabezpečeným kanálom do aplikácie tretej strany z Gadgetov1 pre . Gadget je svojím spôsobom taktiež súčasť sociálnych sietí, pretože rozširuje služby o integráciu so sociálnymi sieťami. Tu som sa po prvýkrát stretol s protokolom OAuth [8], ktorý som hneď pri prvom stretnutí navrhol ako jedno z možných riešení pre portál GateIn. Z dokumentácie, ktorá bola v tom čase dostupná k tomuto protokolu, bolo už evidentné, že pôjde pravdepodobne o nový štandard, ktorý sa bude snažiť uplatniť aj Google. Bolo však potrebné spraviť rozsiahlejšiu analýzu, či je tento protokol použiteľný v požadovaných podmienkach, alebo použiť implementáciu napríklad už v tej dobe dobre zabehnutého protokolu OpenID, prípadne nejakého iného. Taktiež, ako veľké množstvo mladých ľudí vlastním inteligentný telefón. Rovnako navštevujem rôzne služby a používam veľké množstvo aplikácií, ktoré nejakým spôsobom komunikujú na internete medzi sebou. Vo väčšine z nich som si všimol, že obsahujú už skôr spomínané tlačítko prihlásiť pomocou Facebooku alebo prihlásiť pomocou Google. U väčšieho množstva z nich dokonca takúto možnosť využívam. Základným predpokladom však je, že musím ako užívateľ vlastniť svoj vlastný účet u niektorého z poskytovateľov identity, či už sa jedná o Google alebo o Facebook. Dôvodom používania je komfort, s akým môžem získať prístup k novým službám bez toho, aby som musel vypĺňať zložité formuláre pre registráciu. Začal som teda skúmať, čo sa ukrýva za týmto jednoduchým tlačidlom. Netrvalo dlho a našiel som niekoľko príspevkov, ktoré sa venovali tejto problematike [1][33]. Prihlasovanie pomocou jediného stisnutia tlačidla zakrývali za pojem federatívnych identít (Federated Identity), ako novodobého fenoménu v oblasti získavania prístupu. Do federatívnych identít spadajú hlavné komunikačné protokoly OpenID, SAML, OAuth a ich rôzne deriváty a modifikácie, ktorých počet neustále narastá. Pôvod pojmu vychádza z lepšie známeho "Single sign-on" [2][3], ktoré celý proces rozvoja federatívnych identít odštartovalo. Veľké spoločnosti v minulosti potrebovali zjednotiť prístup k svojim podnikovým systémom pre jednoduchšiu správu a vyššiu bezpečnosť.

1 https://developers.google.com/gadgets/docs/gs 3 Prišli teda s implementáciou "Single sign-on", ktorá prinášala jednotné úložisko pre prihlasovacie mená a heslá užívateľov. Tie tak mohli byť použité naprieč niekoľkými internými systémami danej spoločnosti. Servisne orientovaný softvér potom odštartoval úplne novú vlnu zmien. Mnohé organizácie vlastnili API, ktoré mohli používať partneri a nezávislí vývojári pre prístup k ich softvéru. Bolo teda potrebné spravovať takéto prístupy. Umožniť aplikáciám tretích strán pristupovať do softvérov spoločností bolo veľkou výzvou. Neskôr, ako sa stalo populárnym používanie sociálnych sietí, začalo vznikať veľmi veľké množstvo malých aplikácií, ktoré boli vybudované na vrchole širokého spektra rozličných platforiem. Tie boli rôznym spôsobom nalinkované na účty služieb Twitter, Facebook alebo LinkedIn. Nastal problém, ako spravovať prihlasovacie údaje užívateľa naprieč veľkým množstvom aplikácií a platforiem, zjednodušiť prihlasovanie a zvýšiť bezpečnosť. Odpoveďou na tento problém sa stali federatívne identity. Federatívna identita znamená prepojenie a použitie elektronickej identity, ktorú vlastní užívateľ naprieč niekoľkými správami identít (Identity Management System [4]). Jednoduchšie povedané, aplikácia, ktorá žiada od užívateľa overenie identity, už nepotrebuje mať vlastný súbor prihlasovacích mien a hesiel užívateľov na to, aby daného užívateľa vedela prihlásiť. Namiesto toho si vyžiada informácie o prihlasovanom užívateľovi od nejakého poskytovateľa identity, ktorý má svoj vlastný spôsob, ako ho autentizovať. Typicky pomocou prihlasovacieho mena a hesla. Jedným z predpokladov takéhoto postupu je, že daná aplikácia musí dôverovať poskytovateľovi identít. Inak by sa mohlo stať, že prihlási nepravého užívateľa. Tento prístup k danej problematike dovoľuje rozdeliť celý proces overenia identity na dve časti: proces overenia pravosti a proces prideľovania oprávnení. Taktiež zjednodušuje ich centralizáciu v podnikovej sfére, aby sme sa vedeli vyhnúť situácii, kedy každá aplikácia musí spravovať nejakým spôsobom prihlasovacie údaje každého užívateľa. Je to taktiež veľké zjednodušenie pre užívateľov, nakoľko si nemusia pamätať svoje prihlasovacie meno a heslo pre každú aplikáciu zvlášť.

1.1. OpenID

Jedná sa o decentralizovaný autentizačný protokol, ktorý zjednodušuje užívateľom možnosť prihlásenia a získania prístupu k rôznym službám na internete. Jeho korene siahajú niekde do doby služby LiveJournal2 , ktorá chcela dosiahnuť, aby bolo možné používať jedinú identitu pre zanechávanie

2 http://en.wikipedia.org/wiki/LiveJournal 4 komentárov v ľubovolnom blogu. Vývoj tohto otvoreného štandardu bol sponzorovaný spoločnosťami Facebook, Microsoft, Google, PayPal, Ping Identity, Symantec a Yahoo. Definuje štandard alebo lepšie povedané vzor, pomocou ktorého je možné preukázať, že sme skutočne tým, kým tvrdíme. Užívatelia používajúci túto službu si vyžiadajú unikátny identifikátor (typicky URL adresu) od poskytovateľa OpenID. O tomto identifikátore môžeme uvažovať ako o prihlasovacích údajoch užívateľa. Ak sa chceme autentizovať ako daný užívateľ (dokázať, ž e sme vlastníkom danej URL), prihlásime sa k svojmu OpenID poskytovateľovi namiesto toho, aby sme sa prihlasovali do aplikácie, ktorú sa snažíme použiť. Naviac, užívateľ si môže sám vybrať svojho preferovaného poskytovateľa OpenID, pomocou ktorého sa chce k danej službe prihlasovať. OpenID špecifikácia definuje tri typy rolí: • koncový užívateľ, ktorý sa snaží overiť svoju identitu, • Relying Party (RP), čo je služba, ktorá sa snaží overiť identitu koncového užívateľa, • OpenID poskytovateľ (OpenID Provider - OP), ktorý je entitou registrujúcou OpenID URL a taktiež dokáže overiť identitu koncového užívateľa. Pre lepšiu predstavu uvediem príklad, ako by prebiehalo prihlasovanie do služby StackOverflow pomocou OpenID: • na stránkach StackOverflow poskytneme OpenID URL ako prihlasovacie meno, • StackOverflow kontaktuje OpenID poskytovateľa (v tejto konkrétnej situácii slúži ako OpenID poskytovateľ Google), aby vytvoril zdieľaný kľúč [5], • prihlásime sa do Google a získame správu podpísanú zdieľaným tajným kľúčom (Obyčajne sa používa HMAC-SHA256), • túto správu poskytneme StackOverflow, aby sme dokázali, že sa nám podarilo úspešne prihlásiť. Toto je jeden zo spôsobov, ako použiť OpenID protokol. Požaduje, aby si naša aplikácia pamätala zdieľaný kľúč. Š tandard OpenID nám však dovoľuje použiť aj iný prístup: • poskytneme OpenID poskytovateľovi (opäť Google) našu OpenID URL, 5 • prihlásime sa do Google a budeme informovať StackOverflow o úspešnom prihlásení, • následne StackOverflow skontaktuje Google, aby si overilo, že sa prihlásenie skutočne úspešne podarilo.

Obr. 1: Postup pri prihlasovaní užívateľa pomocou protokolu OpenID

1.1.1. Bezpečnostné riziká spojené s použitím OpenID

OpenID má hneď niekoľko slabých miest, ktoré sa dajú potenciálne veľmi jednoducho zneužiť [17] [18]: • Phishing útoky - nakoľko celý proces overenia užívateľa je riadený stranou služby, ktorá sa dopytuje OpenID poskytovateľa, je veľmi jednoduché v procese overovania presmerovať užívateľa na podvodnú stránku OpenID poskytovateľa a nazhromaždiť jeho prihlasovacie údaje. • Zlyhanie overovania - v marci 2012 boli prezentované dva prípady, ako využiť zraniteľnosti protokolu OpenID. Každý z nich dovoľoval útočníkovi prevziať identitu akéhokoľvek užívateľa, ak daná služba neoverila, či odpoveď od OpenID poskytovateľa obsahuje overenú emailovú adresu.

1.2. SAML

Tento protokol vytvorila spoločnosť OASIS Security Services Technical Committee [6] v roku 2001. Jedná sa o otvorený štandard pre výmenu

6 autentizačných a autorizačných správ vo forme XML súborov medzi jednotlivými zložkami prostredia. Špecifikácia SAML definuje tri typy rolí: • Principal - obyčajne predstavuje užívateľa, ktorý sa snaží overiť svoju identitu. • Poskytovateľ identity (idP) - entita, ktorá je schopná overiť identitu koncového užívateľa. • Poskytovateľ služby (SP) - služba, pre ktorú sa snaží koncový používateľ overiť svoju identitu.

Obr. 2: Postup pri prihlasovaní užívateľa pomocou protokolu SAML Tento protokol je pomerne zastaralým riešením. Naviac narušenie bezpečnosti na strane poskytovateľa identity môže priniesť fatálne následky.

1.2.1. Bezpečnostné riziká spojené s používaním protokolu SAML

V roku 2011 skupina akademikov predstavila spôsob, kde pomocou chyby v zapuzdrení XML podpisu získali identitu ľubovoľného užívateľa [7].

7 1.3. OAuth

Otvorený protokol, ktorý dovoľuje jednoduchým a štandardizovaným spôsobom bezpečne overiť identitu užívateľa pre webové, mobilné a desktopové aplikácie. Tento protokol vznikol z úsilia spoločnosti Twitter so základnou myšlienkou poskytnúť užívateľom možnosť darovať alebo odobrať prístup aplikáciám tretích strán k ich vlastnému účtu [8]. Dôvodom pre vznik bola neexistencia otvoreného štandardu pre delegáciu prístupu k API webových služieb. Prvé diskusie k tomuto problému sa objavujú v novembri 2006. O takmer rok neskôr v októbri 2007 bol už predstavený koncept OAuth Core 1.0 (tiež známy ako RFC 5849 [9]). K jeho dokončeniu došlo až o niekoľko rokov neskôr po viacnásobnom prepísaní. V apríli 2010, bol považovaný za jednu z najrýchlejšie rastúcich otvorených webových špecifikácií. Priniesol veľmi potrebné riešenie bezpečnosti prístupu do webových API bez potreby žiadať od užívateľa prihlasovacie meno a heslo. Špecifikácia OAuth definuje nasledovné typy rolí: • Koncový užívateľ alebo entita, ktorá vlastní zdroje, ku ktorým sa snaží aplikácia získať prístup. • Server so zdrojmi (OAuth Provider). • Klient (OAuth Consumer), ktorý používa zdroje získané po úspešnom overení od koncového užívateľa. Podrobnejšiemu popisu tohoto protokolu sa budem venovať v 3. kapitole.

8 Obr. 3: Postup pri prihlasovaní užívateľa pomocou protokolu OAuth

1.3.1. Bezpečnostné riziká spojené s používaním OAuth

Vo verzii OAuth 1.0 bola nájdená chyba fixácie spojenia. Útočník môže zafixovať spojenie počas procesu overenia identity daného užívateľa. Následne potom používa zafixovaný token, pomocou ktorého kradne dáta užívateľa, prípadne používa jeho identitu [10]. OAuth 2.0 je popisovaný ako všeobecne nezabezpečený protokol, nakoľko nepodporuje podpisovanie, šifrovanie, viazanie kanálu ani overovanie klienta. Zabezpečenie jeho komunikácie tak spočíva na čiste transportnej sieťovej vrstve (SSL, TLS) pre zaručenie dôvernosti a integrity.

1.4. Federatívne identity

Vo virtuálnom svete rôznorodých webových aplikácií, systémov, protokolov a zariadení vidím veľký potenciál a využitie federatívnych identít. Na jednej strane komfort a pohodlie, ktoré poskytujú svojim užívateľom. Nemusia si už viac ku každej službe pamätať svoje prihlasovacie údaje a strácať čas premýšľaním, kde si zapísali svoje prihlasovacie meno a heslo. Na druhej strane sú tu však bezpečnostné riziká, ktoré použitím jednotného centrálneho úložiska osobných údajov môžu nastať. Čoraz viac sa vynára hrozba útokov, kedy útočník získa osobné dáta ľudí. Použitím federatívnych identít však môže získať ešte oveľa viac. Prístup k veľkému množstvu dát a účtov, ktoré užívateľ vlastní. Je

9 preto veľmi dôležité vybrať správne smerovanie, ktorým by sme sa mali ďalej vybrať, ohodnotiť riziká a v prípade, že sa rozhodneme pre implementáciu niektorého z protokolov federatívnych identít, vybrať ten, ktorý prináša čo najmenšie riziká a spĺňa všetky naše požiadavky. V tabuľke 1 vidíme jednoduché zrovnanie troch už spomínaných najrozšírenejších protokolov. Každý z nich bol vyvíjaný za iným účelom. OpenID OAuth SAML

Vznik 2005 2006 2001

Súčasná verzia OpenID 2.0 OAuth 2.0 SAML 2.0

Single sign-on pre získanie overeného Single sign-on užívateľov Účel prístupu k API medzi spotrebiteľov podnikových aplikácií aplikáciami a systémov

SAM, XML, HTTP, Použité technológie XRDS, HTTP JSON, HTTP SOAP

Vydanie poslednej 2007 2012 2005 verzie

Tabuľka 1: Dostupné protokoly pre implementáciu Federatívnych identít

10 2. Google, Facebook a Twitter ako poskytovatelia identity

Výberu optimálneho riešenia predchádzalo štúdium ponúkaných možností, ktoré poskytovatelia identít ponúkajú. V tabuľke 2 môžeme nájsť zhrnutie jednotlivých možností. Už na prvý pohľad je zrejmé, že ideálne riešenie, ktoré by bolo dostupné u každého poskytovateľa, nie je možné nájsť. Všeobecne však vieme nájsť akýsi náčrt, ako by to mohlo v ideálnom prípade vyzerať. Za základný kameň môžeme pokladať pravidlo - vždy udržiavať informáciu o prihlasovacom mene a hesle užívateľa iba na jednom mieste. Tým by mohol byť poskytovateľ identity. Je teda nevyhnutné vytvoriť nejaký komunikačný kanál, cez ktorý by naša aplikácia získala dočasné, obmedzené oprávnenia pre prístup k informáciám prihlasovaného užívateľa. Prihlasovanie by tak vždy prebiehalo na strane poskytovateľa identity a taktiež na tejto strane by užívateľ schvaľoval, k akým zdrojom bude aplikácia, ktorú autorizuje, mať prístup. Dovolím si uviesť jednoduché vysvetlenie, prečo je tento prístup správny na obraznom príklade: Predstavme si, že vlastníme drahý automobil. K tomuto automobilu sme pri jeho kúpe obdržali dva rôzne kľúče. Jeden originál a jeden takzvaný "peňaženkový". Jedného dňa sa vyberieme na spoločenskú udalosť. Pri vstupných dverách je obsluha, ktorá má za úlohu automobil zaparkovať na priľahlom parkovisku. Tomuto personálu však nedáme originálny kľúč, ale len takzvaný peňaženkový, s ktorým je možné odviezť automobil do vzdialenosti maximálne niekoľko kilometrov od originálneho kľuča. V prípade, že personál presiahne povolenú vzdialenosť, automobil vypne motor a zablokuje svoje ovládanie. Tento prístup je vhodný najmä preto, že potenciálne nedôveryhodnému zdroju poskytujeme len obmedzené oprávnenia a obmedzené množstvo informácií, ktoré nie je tak jednoduché zneužiť. Obdobne aj pri snahe aplikácie o získanie väčších oprávnení, ako dostala pri vytváraní komunikácie s poskytovateľom identity, bude tejto aplikácii odopretý prístup vždy, keď presiahne svoje kompetencie. Už v minulosti bola snaha o implementáciu tohoto vzoru, a tak bol vytvorený jednoduchý protokol poskytovania identity, všeobecne známy ako OpenID. V momente, kedy berieme sociálne siete ako poskytovateľov identity, musíme sa prispôsobiť ich vlastnej implementácii spomínaných protokolov uvedených v prvej kapitole. Preštudovať ich špecifikáciu a vybrať ten, ktorý by najlepšie zapadal do situácie, ktorú potrebujeme vyriešiť. Zároveň je veľmi dôležité odhadnúť smerovanie, akým sa jednotliví poskytovatelia môžu v

11 budúcnosti uberať. Bolo by nevýhodné ostať pri protokole, ktorý poskytovateľ identity už ďalej neplánuje rozvíjať, ale ho chce nahradiť novšou verziou, prípadne nejakým iným. Postupne som preskúmal jednotlivé možnosti u každého poskytovateľa.

Google Facebook Twitter

OAuth 1.0A ✘ ✘ ✓

OAuth 2.0 ✓ ✓ ✘

OpenID ✓ ✘ ✘

Facebook Connect ✘ ✓ ✘

OpenSocial ✓ ✘ ✘

Google Friend ✓ ✘ ✘ Connect

Tabuľka 2: Dostupné implementácie protokolov u poskytovateľov identity Google, Facebook a Twitter

2.1. Google

Google3 má svoju vlastnú sociálnu sieť zvanú plus4 . Tá sa teší čoraz väčšiemu množstvu návštevníkov a stáva sa stále viac populárnou. Je to spôsobené prevažne tým, že Google neustále pracuje na prepojení svojich služieb v čo najširšej miere. Nedávno pridal službu zvanú Hangouts, ktorá umožňuje užívateľom bezplatne vytvárať skupinové videohovory. To je v súčasnosti asi jediná bezplatná služba podobného charakteru, ktorá je dostupná celosvetovo. Takisto táto spoločnosť investovala nemalé financie do vývoja svojho vlastného operačného systému pre mobilné platformy. Stala sa tak gigantom tohoto segmentu trhu. Práve pri používaní mobilného operačného systému Android nás tento systém opakovane vyzýva k založeniu si svojho vlastného účtu u tejto spoločnosti. V opačnom prípade nebudeme môcť plne využívať všetky jeho väčšinou užitočné funkcie. Po tom, ako si takýto účet zriadime, obyčajne nasleduje agitácia pre pripojenie sa k sociálnej sieti plus. V čase prvotnej analýzy, ktorá prebiehala na prelome rokov 2012 a 2013, disponovala spoločnosť Google nasledujúcimi protokolmi, ktoré bolo možné použiť pre overenie identity užívateľa: • OAuth,

3 v práci budem používať pomenovanie Google namiesto Google+, pretože spôsob prihlasovania sa u tohto poskytovateľa identity nemení a je zhodný naprieč všetkými službami vrátane Google+

4 http://plus.google.com 12 • OpenID, • OpenSocial, • . Počas roku 2013 táto časť prechádzala neustálymi zmenami až nadobudla podobu, v akej sa nachádza dnes. Situácia je podstatne iná a značne jasnejšia. Všetky možnosti môžme nájsť v časti, ktorá je venovaná vývojárom [11]. Overovanie rozdeľuje do dvoch rozličných kategórií: • overenie identity, • autorizácia prístupu k API služieb. Vďaka týmto neustálym zmenám, ktorými spoločnosť Google prechádzala, bolo veľmi zložité nájsť cestu, ktorou by bolo možné prepojiť ich služby s portálom GateIn. Postupne sa objavovalo čoraz viac článkov, ktoré načrtali, akým spôsobom implementovať a použiť protokol OAuth. Na základe tohoto trendu som sa rozhodol vybrať cestou implementácie OAuth. Na komunitných stránkach protokolu už bola v tom čase verejne dostupná špecifikácia OAuth 2.0. Avšak na strane Google ešte ani zďaleka nebola pripravená pre implementáciu. Google používal svoju vlastnú implementáciu OAuth 1.0, ktorá umožňuje autorizáciu pomocou takzvaného 2-legged alebo 3-legged OAuth. Tomu, aký je v nich rozdiel, sa budem venovať v nasledujúcej kapitole. Google pre časť svojich služieb ešte dodnes plne neintegroval podporu protokolu OAuth 2.0, a tak sa môže stať, že pri snahe o prepojenie s niektorou z nich, narazíme na problém, kedy budeme musieť použiť protokol prvej generácie. Spoločnosť Google však aj naďalej ponúka iné možnosti, ako overiť identitu užívateľa. Nájdeme u nej implementáciu OpenID5 a rovnako SAML6 protokolu. No nie sú už naďalej štandardom, ktoré odporúča použiť pri snahe o overenie a získanie oprávnení pre užívateľa [11].

OpenSocial7 je štandardizovaným API pre sociálne siete vytvorené spoločnosťou Google. V skutočnosti sa jedná však o dve API. Jedno pre JavaScript a druhé pre REST. JavaScript API slúži pre aplikácie, ktoré sú takzvaného typu Web Gadgets písané v architektúre Google Gadgetov. REST API slúži pre všetky ostatné typy aplikácií ako desktop, mobilné či serverové. Na pozadí musí každá

5 https://developers.google.com/google-apps/sso/openid_reference_implementation

6 https://developers.google.com/google-apps/sso/saml_reference_implementation

7 https://developers.google.com/opensocial/ 13 sociálna sieť podporovať SPI8 (service provider interface), ktoré poskytuje možnosti ako: • pridávanie alebo odoberanie priateľov, • pridávanie alebo odoberanie aplikácií, ukladanie aktivít užívateľa a tak ďalej. •

Takzvané Gadgety sú vždy vytvorené pomocou API9 . Každá sociálna sieť, ktorá je schopná spustiť OpenSocial Gadgety, je jedným veľkým kontajnerom.

Apache Shinding 10 je typickou implementáciou kontajneru. V skutočnosti je Gadget JavaScript objekt, ktorý implementuje rozhranie OpenSocial. Autentizácia je mimo rozsahu OpenSocial špecifikácie gadgetov a očakáva sa, že bude prevedená v čase, kedy dôjde k inštanciácii gadgetu. Pri JavaScript gadgetoch ju zabezpečuje implementácia OpenSocial kontajneru a pri REST API je väčšinou použité OAuth. Použitie OpenSocial prezentuje Google vo svojom Gadgets API 11. Nakoľko tieto gadgety je možné použiť len pre služby Google Kalendár, Gmail a v jeho vlastnom tabuľkovom procesore, nemajú pre nás žiadny praktický význam. Google Friend connect [12] je poslednou možnosťou, ktorú Google v čase analýzy ponúkal. Dnes je tento štandard už zastaralou technológiou a nie je možné jeho implementáciu použiť. Jedná sa o voľnú sociálnu sieť. Bola v praxi veľmi podobná službám Facebook Platform12 a MySpaceID. Decentralizovaným prístupom umožňoval užívateľom vytvoriť svoj profil a zdielať informácie o sebe (správy, fotografie a videá) cez aplikácie tretích strán, ktoré sa potom správali ako úložisko pre profil a výmenu sociálnych informácií.

2.1. Facebook

Spoločnosť Facebook vlastní rovnomennú sociálnu sieť. Narozdiel od všetkých ostatných poskytovateľov identity ponúka len jedinú možnosť, ako overiť identitu užívateľa a pristúpiť k jeho osobným dátam. Touto možnosťou sa

8 http://en.wikipedia.org/wiki/Service_provider_interface

9 https://developers.google.com/gadgets/

10 http://shindig.apache.org

11 https://developers.google.com/gadgets/docs/overview

12 http://en.wikipedia.org/wiki/Facebook_Platform 14 stal OAuth 2.0 dňa 1. októbra 2011. V porovnaní s ostatnými poskytovateľmi identity to bolo pomerne dosť skoro. V minulosti existovala ešte služba Facebook Connect. Podľa blogu venovaného vývojárom [13], táto možnosť dovoľovala aplikáciám tretích strán zabezpečene pristupovať k užívateľským údajom. Neskôr bola nahradená práve štandardom OAuth 2.0.

2.1. Twitter

Táto spoločnosť stála pri zrode samotného OAuth. Je preto logické, že práve tu nájdeme túto možnosť ako jedinú dostupnú pre overenie identity užívateľa a pristupovanie k jeho účtu. Zvláštnosťou je fakt, ž e ako jediný poskytovateľ identity ešte stále používa OAuth 1.0 s malou modifikáciou, ktorá odstraňuje bezpečnostnú chybu [10] spomenutú v prvej kapitole. Túto verziu označujú ako

OAuth 1.0A13 .

13 http://oauth.net/core/1.0a/ 15 3. Špecifikácia OAuth a možnosti využitia pre portál GateIn

V tradičnom svete overovania identity klient-server obyčajne klient overuje svoju identitu naproti serveru, ku ktorému sa snaží pristupovať. OAuth nám predstavuje celkom nový spôsob, ako overovať identitu užívateľa. Vnáša do tohto modelu tretiu časť, ktorou je vlastník zdrojov. Klient, ktorý nie je majiteľom zdrojov, ale pôsobí v ich zastúpení, požiada o prístup k zdrojom, ktoré sú pod správou vlastníka zdrojov. K tomu, aby mohol klient pristupovať k týmto zdrojom, musí pri prihlasovaní požiadať o oprávnenie. Toto oprávnenie je reprezentované dvojicou hodnôt, ktoré nazývame token a shared-secret. Úlohou tokenu je odbúrať potrebu poskytovať prihlasovacie údaje užívateľa na strane vlastníka zdrojov. Na rozdiel od prihlasovacích údajov, ktoré by boli poskytnuté pre server, tokenu môže byť odobraté isté oprávnenie pre prístup k niektorému z osobných dát užívateľa alebo oprávnenia pre celkový prístup. Platnosť každého tokenu je časove obmedzená, vďaka čomu získava užívateľ ďalšiu úroveň ochrany.

Protokol OAuth je inšpirovaný zo značnej miery Mikroformátmi14 . Ľudia v komunite, ktorá tento protokol vyvíjala, sa rozhodli v jeho začiatkoch použiť overené postupy z danej oblasti. OAuth tak reprezentuje kombináciu viacero dobre známych protokolov, ktoré boli v minulosti používané veľkými spoločnosťami. Za typické príklady môžeme považovať Google AuthSub15 , Yahoo

BBAuth16 alebo Flickr API17 . Každý z týchto protokolov priniesol iný pohľad na to, ako narábať s prihlasovacími údajmi užívateľa. Niektoré používali istú formu tiketov, iné fungovali podobne na adresovaní tokenu. Špeciálnou oblasťou v ktorej protokol OAuth vedie, je oblasť mobilných platforiem. Poskytuje nám možnosť, ako overiť identitu užívateľa nielen vo webových aplikáciách, ale takisto v desktopových alebo mobilných.

3.1. História

Komunita, ktorá vznikla okolo OAuth, zo značnej miery vychádza z komunity protokolu OpenID. Okolo novembra 2006 Blaine Cook, zamestnanec

14 http://microformats.org

15 https://developers.google.com/accounts/docs/AuthSub

16 http://developer.yahoo.com/bbauth/

17 http://www.flickr.com/services/api/ 16 spoločnosti Twitter, hľadal možnosti, ako pridať podporu OpenID pre Twitter. Taktiež hľadal aj ďalšie možnosti autentizácie API k Twitteru. Také, ktoré by nevyžadovali od užívateľa zdieľanie prihlasovacieho mena a hesla. Jeho snahou bolo použiť protokoly, podobné tým, ktoré používali spoločnosti ako Flickr

(AuthSub) 18, Yahoo! (BB Auth)19 alebo Google s rozdielom, že by boli publikované ako voľne dostupný štandard. Problém, ktorý vzniká pri použití OpenID je, že už nepoznáte heslo prihlasovaného užívateľa, a teda nie je možné použiť štandardný spôsob autentizácie pre volanie API, pretože to vyžaduje poznať heslo. Približne v rovnakom čase Chris Messina spolu s Larrym Halfom pracovali na integrácii OpenID do služby Ma.gnolia20 . Blaine spoločne s Chrisom potom v decembri 2006 zorganizovali stretnutie, ktorého sa zúčastnil aj Dávid Recordon (spoluautor OpenID) a ďaľší ľudia v Citizen Space. Diskutovali spolu o možnostiach, ktoré existujú. Po prehodnotení možností, ktoré poskytuje protokol OpenID, celá skupina prišla k záveru, že je potrebné vytvoriť nový otvorený štandard pre autentizovaný prístup k API. Taký, ktorý nepožaduje zdieľanie užívateľského prístupového hesla a súčasne dovoľuje používať technológie ako OpenID pre prístup k API. Nový koncept pomenovali OpenAuth. V apríli 2007 bola vytvorená skupina inžinierov s názvom OpenAuth Google group, ktorých úlohou bolo vytvoriť takýto protokol. Ukázalo sa, že tento problém nie je jediným svojho druhu a s podobným obmedzením sa stretáva veľké množstvo vývojárov po celom svete. V tom istom mesiaci vydala spoločnosť AOL svoj vlastný protokol, ktorý pomenovala OpenAuth. Bolo preto potrebné premenovať pôvodne zvolené pomenovanie protokolu. Vzniklo pomenovanie OAuth, ktoré sa používa dodnes. V júni 2007 sa k projektu pridal DeWitt Clinton zo spoločnosti Google a priviedol so sebou ďaľších ľudí, ktorí sa venovali bezpečnosti: Bena Laurieho a Jonathana Sergenta. Postupne sa pripájalo väčšie množstvo vývojárov k úsiliu vytvoriť jednoduchý jednotný protokol. Poslednou významnou osobnosťou, ktorá sa pridala do skupiny vytvárajúcej protokol, bol v júli 2007 Eran Hammer. Postupne prevzal iniciatívu nad špecifikáciou a stal sa vedúcou osobnosťou celej komunity.

18 https://developers.google.com/accounts/docs/AuthSub

19 http://developer.yahoo.com/auth/

20 http://en.wikipedia.org/wiki/Gnolia 17 V decembri toho istého roku došlo k finálnej špecifikácia protokolu OAuth Core 1.0. 26. augusta 2008 bola vydaná oficiálna licencia deklarujúca voľnú dostupnosť tohoto štandardu aj v budúcnosti. Posledným stupňom v procese vydania nového protokolu bolo uvoľnenie nového autentizačného riešenia spoločnosťou Twitter dňa 15. apríla 2009. Toto riešenie sa nazývalo "Sign-in with Twitter" a používalo protokol OAuth. Neskôr sa špecifikácia OAuth rozdelila na dve rôzne vetvy. Jedna bola snahou komunity IETF. Druhá bola súborom RFC. Tu zozbieral Eran Hammer poznatky od vývojárov, ktorí túto knižnicu začali implementovať a vydal novú verziu s názvom OAuth Core 1.0 Editor's Cut. Neskôr však svoje úsilie presmeroval na IETF verziu, z ktorej neskôr vznikla verzia OAuth 2.0 zahrňujúca poznatky, ktoré zozbieral v RFC verzii.

3.2. Špecifikácia

Špecifikácia OAuth pozostáva z dvoch zložiek. Prvá definuje postup presmerovania užívateľa pre získanie klientského prístupu k jeho zdrojom uloženým u poskytovateľa zdrojov. Tento proces sa vykoná počas prihlásenia priamo na serveri, ktorý následne poskytne token. Takýto token sa potom používa v druhej časti pre prístup k zdrojom. Druhá zložka definuje postup, ktorým sa vytvárajú HTTP požiadavky na poskytovateľa zdrojov. Ku každej požiadavke je vždy priložená dvojica hodnôt. Jedna identifikujúca užívateľa a druhá, ktorá hovorí o vlastníkovi zdrojov, v ktorého zastúpení bola zaslaná požiadavka.

3.3. Terminológia

Protokol OAuth definuje tri typy rolí: klient, server a vlastník zdrojov. Každá z týchto rolí je vždy prítomná pri každej OAuth transakcii. V niektorých prípadoch môže byť klient zároveň vlastníkom zdrojov. Kedy k tomuto prípadu dochádza je vysvetlené v nasledujúcej podkapitole. Pôvodná verzia špecifikácie popisovala tieto role pomocou pojmov: klient (klient), poskytovateľ služby (server) a užívateľ (vlastník zdrojov). V tradičnom svete prihlasovania klient-server, klient obyčajne používa svoje prihlasovacie údaje na to, aby pristupoval k chráneným zdrojom uloženým na serveri. Server sa v skutočnosti nezaujíma o to, či pristupuje v zastúpení nejakej inej entity. Postačuje mu zabezpečený prenos, ktorý bol vytvorený počas procesu prihlasovania. Požiadavka je vždy vyhodnotená úspešne, pokiaľ zabezpečený prenos spĺňa požiadavky kladené serverom. 18 Obr. 4: Komunikácia medzi klientom a serverom pri bežnom procese overovania V praxi sa však mnohokrát stretávame s modelom, kedy sa klientom stáva nejaká iná entita. Takouto entitou môže byť stroj alebo iná osoba. V momente, keď sa dostane do modelu tretí činiteľ, užívateľ komunikuje s klientom a klient komunikuje so serverom v jeho zastúpení. V takomto prípade hovoríme, že klient nepristupuje k zdrojom, ktoré by mu patrili, ale k zdrojom, ktoré patria užívateľovi (vlastníkovi zdrojov). Namiesto toho, aby klient použil svoje prihlasovacie údaje, použije prihlasovacie údaje vlastníka zdrojov a bude predstierať, že je ich vlastníkom. Prihlasovacie údaje obyčajne pozostávajú z prihlasovacieho mena a hesla. Vlastníci zdrojov nemusia pozostávať iba z užívateľov. V reálnom svete sa môže jednať o akúkoľvek entitu, ktorá obsluhuje zdroje servera.

Obr. 5: Komunikácia klienta so serverom v zastúpení vlastníka zdrojov Celý model môžeme ešte viac rozobrať do detailov, ak za klienta pokladáme webovú aplikáciu. V takomto prípade je klient rozdelený na front-end časť, kde beží prehliadač na počítači vlastníka zdrojov a na back-end časť, kde beží lokálny server klienta. Vlastník zdrojov vtedy komunikuje s front-end časťou, zatiaľ čo v tom istom čase môže komunikovať back-end časť so serverom. Nech zvolíme akúkoľvek internú architektúru klienta, musí sa vždy chovať ako jediná entita a postupovať v zastúpení vlastníka zdrojov.

19 Obr. 6: Komunikácia klienta rozdelená na dve časti webovej aplikácie Posledným pojmom, ktorý je potrebné spomenúť pri terminológii, sú chránené zdroje. Chránené zdroje si môžme predstaviť ako dáta uložené na serveri alebo služby, ktoré daný server poskytuje. Pre pristupovanie k nim sa požaduje overenie. Obyčajne sa jedná o dáta alebo služby, ktoré patria vlastníkovi zdrojov a nie serveru. Každý, kto sa snaží pristupovať ku chráneným zdrojom, musí byť pre takúto operáciu autorizovaný vlastníkom zdrojov. K takejto autorizácii vždy vyzýva server. Nakoľko OAuth môže byť použitý so širokým spektrom rôznych transportných protokolov, definujeme ho len pre HTTP(S) zdroje.

3.4. 2-Legged, 3-Legged, n-Legged

V typickej OAuth požiadavke počet nôh (legs) obyčajne označuje počet strán, ktoré sú prítomné počas komunikácie. Ak je prítomný klient, server a vlastník zdrojov, obyčajne hovoríme o 3-legged OAuth. Ak zlúčime do jedinej entity klienta a vlastníka zdrojov, hovoríme o 2-legged OAuth. Pridávanie ďalších nôh obyčajne naberá pre rôznych ľudí rôzny význam. Všeobecne však platí, že pridanie ďalších nôh značí rozdelenie prístupu na strane klienta medzi viacerých menších klientov.

3.1. Prihlasovacie údaje a tokeny

OAuth používa tri typy prihlasovacích údajov: prihlasovacie údaje klienta, dočasné prihlasovacie údaje a prihlasovacie údaje typu token. Pôvodná dokumentácia používala rozdielne názvy pre tieto prihlasovacie údaje:

20 Consumer Key and Secret (prihlasovacie údaje klienta), Request Token and Secret (dočasné prihlasovacie údaje) a Access Token and Secret (prihlasovacie údaje typu token). Špecifikácia ešte stále používa parameter s názvom "oauth_consumer_key" kvôli spätnej kompatibilite. Prihlasovacie údaje klienta sa používajú pre overenie identity klienta naproti serveru. To dovoľuje serveru zhromažďovanie informácií o klientoch, ktorí používajú jeho služby, ponúkanie presnejšie definovaných služieb ako obmedzenie šírky pásma, alebo poskytnutie presnejších informácií vlastníkovi zdrojov o klientoch, ktorí pristupujú k jeho chráneným zdrojom. V niektorých prípadoch nie je možné overiť prihlasovacie údaje klienta a môžu byť použité len informačne. Typicky u mobilných aplikácií. Prihlasovacie údaje typu token nahrádzajú prihlasovacie údaje vlastníka zdrojov. Inak povedané užívateľské meno a heslo. Namiesto toho, aby vlastník zdrojov zdieľal svoje prihlasovacie údaje s klientom, overí svoju identitu na serveri, ktorý následne priradí klientovi špeciálnu triedu prihlasovacích údajov. Tie reprezentujú oprávnenie pristupovať k chráneným zdrojom bez nutnosti poznania prístupového hesla vlastníka zdrojov. Skladajú sa z reťazca, ktorý pozostáva z náhodne pospájaných písmen a čísiel. Vždy musí byť unikátny a dostatočne zložitý, aby nebolo jednoduché jeho odhalenie. Prihlasovacie údaje typu token sú obyčajne obmedzené na presný rozsah práv a čas, ktorý môžu byť použité. Vlastník zdrojov ich môže kedykoľvek zrušiť bez toho, aby to malo vplyv na prihlasovacie údaje typu token u ostatných klientov.

3.2. Rozdiel medzi OpenID a OAuth

Protokol OAuth vznikol neskôr ako protokol OpenID [14]. Oba slúžia pre overenie identity užívateľa. Avšak každý z nich je vhodné použiť za iných podmienok [15] [16]. Spočiatku by sa mohlo zdať, že fungujú veľmi podobne. Je to dané spoločnou architektúrou, kde presmerujú užívateľa, aby overil svoju identitu na serveri. Zásadným rozdielom však zostáva, že pomocou OAuth je možné nielen overiť identitu užívateľa, ale v skutočnosti aj pristupovať k jeho dátam, informáciám o jeho účte, ktoré sú uložené u poskytovateľa identity. Pomocou OpenID iba získavame informáciu o pravosti žiadateľa prístupu.

3.3. Jedná sa o nový koncept?

Štandardizáciou a spojením niekoľkých dobre známych postupov z protokolov, ktoré boli dostupné na internete, vznikol jeden nový, ktorý bol nazvaný OAuth. Nie je preto prekvapením, že sa podobá na také, ktoré boli už v

21 čase jeho vzniku používané najväčšími hráčmi na internete. Medzi príklady patrí Google AuthSub, AOL OpenAuth, Yahoo! BBAuth, Upcoming API, Flickr API, Amazon Web Services API a mnohé ďalšie. Protokol OAuth vznikol ako derivát podrobným študovaním každého z týchto protokolov, vytiahnutím najlepších skúseností a spoločných vlastností, aby priniesol nové centralizované riešenie a zároveň, aby prechod k nemu nebol zbytočne zdĺhavým a náročným u existujúcich poskytovateľov. Dá sa teda povedať, že sa nejedná o nový koncept, ale o sumarizáciu skúseností, spojenie najlepších prístupov, ktoré vytvorili pred jeho vznikom poskytovatelia služieb vo svojich API.

22 4. Implementácia OAuth do portálu GateIn

Po preskúmaní možností prepojenia sociálnych sietí s aplikáciami tretích strán som prešiel na oblasť preskúmania podnikového portálu spoločnosti Red Hat s názvom GateIn [19]. Podnikový portál je webová aplikácia, ktorá ponúka prostriedky ako zhrnúť a personalizovať informácie pomocou malých aplikácií uložených vedľa seba na jednej obrazovke. Tieto aplikácie nazývame portlety. Užívatelia a administrátori sú tak schopní integrovať informácie, ľudí a procesy naprieč veľkými organizáciami pomocou jednoduchého rozhrania webového prehliadača. Portlet je malá plne samostatná webová aplikácia. Portlet API popisuje java

štandard JSR-28621 . Existuje niekoľko spôsobov, ako napísať portlet. Asi najjednoduchším je implementácia rozhrania JSR-286 Portlet22 . Portál GateIn však ponúka možnosť použiť Portlet Bridge, pomocou ktorého je možné vytvárať portlety použitím technológie JavaServer Faces (JSF). Každý portlet je konfigurovaný tak, aby zobrazoval rozličný obsah.

4.1. GateIn

Podnikový portál od spoločnosti Red Hat s názvom GateIn vznikol spojením dvoch rôznych projektov. JBoss Portál23 a eXo Portál [20]. Novovzniknutý projekt berie z každej časti to najlepšie, čo ponúka a spája ich do jedného java archívu. Cieľom spojenia bolo poskytnúť užívateľsky prívetivý portál a framework, ktorý bude zodpovedať dnešným Web 2.0 štandard aplikáciám. Podnikový portál GateIn obsahuje sadu preddefinovaných portletov, ktoré môžu byť použité kedykoľvek po jeho spustení vo webovom prehliadači.

4.2. PortletBridge

Portlet Bridge je implementáciou java štandardov JSR-30124 a JSR-32925 . Prinášajú podporu JavaServer Faces pre portlet spolu s podporou iných webových

21 https://jcp.org/en/jsr/detail?id=286

22 https://docs.jboss.org/author/display/GTNPORTAL37/Standard+Portlet+Development+(JSR +286)

23 http://www.jboss.org/jbossportal/

24 https://www.jcp.org/en/jsr/detail?id=301

25 https://www.jcp.org/en/jsr/detail?id=329 23 frameworkov 26. Java Portlet špecifikácia je množina API, ktoré priamo implementujú rozhranie portletu. Portlet Bridge je technológia používaná na premostenie portletu s behovým prostredím pomocou rôznych typov abstrakcie pre zobrazenie HTML kódu alebo odpovedí na správanie užívateľa. Dobrým príkladom by mohli byť JavaServer Faces alebo Apache Struts27 . To dovoľuje vývojárom vytvárať plnohodnotné portlety aj bez toho, aby museli poznať špecifiká Portlet API a celý vývojový model. Jednoducho povedané, Portlet Bridge je technológia, ktorá dovoľuje vývojárovi spúštať zobrazenia vytvorené inými technológiami ako pomocou Portlet API bez toho, aby sa musel učiť štandardom vývoja portletov, ich konceptu alebo akýchkoľvek API. Portlet Bridge pre JavaServer Faces je špecifické premostenie potrebné pre podporu spúštania JSF v portletoch portálu GateIn. Podľa dokumentácie portálu GateIn je v portlete možné použiť Portlet Bridge, ktorý je dostupný už v portále GateIn po jeho štarte, alebo ho je možné zabaliť do balíka určeného pre deploy, ktorý predstavuje daný portlet, prípadne niekoľko portletov28 .

4.3. JavaServer Faces

JavaServer Faces (JSF) je nový štandardizovaný Java Framework, ktorý slúži na vytváranie webových aplikácií [21][22]. Zjednodušuje vytváranie užívateľského grafického rozhrania (GUI)29 , ktoré sa buduje pomocou komponentov ich vzájomným skladaním do väčších celkov tvoriacich webovú stránku. Výsledkom je kompletné grafické užívateľské rozhranie, pomocou ktorého komunikuje užívateľ so systémom. JSF takisto zaručuje, že aplikácia má správnu štruktúru, pretože núti vývojára uplatniť návrhový vzor zvaný Model-

View-Controller (MVC)30 . Vďaka tomu, že JavaServer Faces sa stalo dobre definovaným štandardom v špecifikácii Java EE 6, vývojári môžu poskytovať jeho rozšírenia ďalším vývojárom, ktorí budú používať ich komponenty. Poznáme viacero možných vetiev a implementácií JavaServer Faces. V tejto práci som

26 https://www.jboss.org/portletbridge

27 http://struts.apache.org

28 https://docs.jboss.org/author/display/PBR/Installing+Portlet+Bridge

29 http://en.wikipedia.org/wiki/Graphical_user_interface

30 http://en.wikipedia.org/wiki/Model–view–controller 24 použil implementáciu od spoločnosti Red Hat s názvom RichFaces a open source komunitnú implementáciu zvanú PrimeFaces.

4.4. Context and dependency injection

Jednou z požiadaviek od zadávateľa bolo použitie technológie zvanej CDI (Context and Dependency injection) [23]. Opäť ide o jeden zo štandardov, ktoré priniesla špecifikácia Java EE 6. Skladá sa zo špecifikácií JSR-29931 , JSR-33032 a

JSR-31633 . Jeho úlohou je prehľadnejšie a elegantnejšie prepojenie webovej vrstvy s transakčnou. CDI je množina služieb, ktoré dovoľujú vývojárovi používať CDI beany spolu s JavaServer Faces technológiou vo webových aplikáciách. Ako sa neskôr ukázalo, použitie tejto technológie sa stalo nevyhnutným pre funkčnosť celého projektu.

4.5. Štruktúra modulov

Mojou snahou bolo oddeliť časť kódu, ktorá komunikuje so službami Google a Facebook pre získanie tokenov do nezávislého modulu, ktorý som nazval GateIn OAuth 2.0 Core. Pristúpil som k tomuto kroku z dôvodu, aby bolo jednoduchšie pre vývojárov portálu GateIn jeho zakomponovanie. Rovnako takéto oddelenie služieb prináša výhody pre vývojárov portletov. Nemusia sa viac starať o získavanie tokenov, ale použijú už predom navrhnutý postup, ako ich získať a ďalej s nimi jednoducho pracovať. Tiež sa v tomto module nachádzajú interceptory, ktorých úlohe sa budem venovať v kapitolách 5 a 6. Zdrojový kód sa ďalej skladá ešte z troch iných modulov. Každý z nich má za úlohu prezentovať svojím spôsobom grafické užívateľské rozhranie. Toto prerozdelenie som zvolil z dôvodu snahy o rýchlejšie napredovanie pri práci. Moduly Google OAuth 2 demo a Facebook OAuth 2 demo sa navzájom veľmi podobajú. Každý z nich prezentuje spôsob komunikácie s rovnomennou službou Google alebo Facebook. Užívateľské grafické rozhranie je zložené z komponentov voľne dostupnej verzie JavaServer Faces zvanej PrimeFaces. Tieto moduly predstavujú jednoduchú webovú aplikáciu, ktorú je možné spustiť v ľubovoľnom Java EE serveri ako je Jetty, Tomcat či iné. Posledným a asi najzložitejším modulom, ktorý sa nachádza v práci je GateIn OAuth 2.0 web. Tento modul obsahuje samotné portlety, ktoré mali byť

31 https://www.jcp.org/en/jsr/detail?id=299

32 https://www.jcp.org/en/jsr/detail?id=330

33 https://www.jcp.org/en/jsr/detail?id=316 25 viditeľným výsledkom diplomovej práce. Jedná sa o štyri portlety. Dva komunikujúce so službami Google a dva komunikujúce so službami Facebook. Užívateľské grafické rozhranie je zložené z komponentov implementácie JavaServer Faces od spoločnosti Red Hat s názvom RichFaces. Tento modul som vypracovával ako posledný postupným prepisovaním modulov Google OAuth 2.0 demo a Facebook OAuth 2.0 demo. Bolo potrebné prepísať komponenty knižnice PrimeFaces do komponentov knižnice RichFaces. Dôvodom, prečo som v skorších fázach používal komponenty PrimeFaces, je hlavne jednoduchosť, s ktorou je ich možné používať. Na druhú stranu komponenty RichFaces sú pomerne slabo zdokumentované a ich použitie je časove náročnejšie a zložitejšie.

Obr. 7: Štruktúra modulov a postupnosť ich vypracovania

26 5. Implementácia protokolu OAuth od Google

V druhej kapitole opisujem stav, v ktorom sa nachádzala spoločnosť Google v čase, keď som začal pracovať na hľadaní optimálneho riešenia prepojenia ich služieb s portálom GateIn. Jej snahou bolo postupne migrovať všetky doposiaľ dostupné možnosti prihlasovania alebo overovania prístupu k API služieb do protokolu OAuth. Nastal problém vysporiadať sa s faktom nedostatočnej dokumentácie, ako tento protokol používať. Postupne som hľadal články a rady ľudí na komunitných serveroch ako je stackoverflow.com, kde bolo možné nájsť aspoň v skratke, ako so službami spoločnosti Google komunikovať pomocou daného protokolu. Väčšinou sa však jednalo o návody, ktoré fungovali len na nejaký čas. Po istom časovom úseku sa vždy na strane Google spôsob implementácie zmenil a do tej doby funkčný prístup zastaral. To sa opakovalo niekoľkokrát. Bolo vidieť, že spoločnosť Google ešte nemá jasne definovaný spôsob, ktorým by mal protokol OAuth fungovať. Dokumentácia sa počas roku 2013 menila. Spoločnosť Google ešte stále podporovala používanie protokolu OAuth 1.0 [24], odporúčala však prejsť k implementácii OAuth 2.0. Protokolu OAuth 2.0 bola venovaná len malá časť dokumentácie, ktorá slovne popisovala spôsob, ako vytvárať jednotlivé požiadavky a ako previesť celý proces overenia identity užívateľa [25]. Tu som sa po prvýkrát dozvedel o možnosti vyskúšať si celý proces získavania zdrojov už na strane Google v ich vlastnom predpripravenom prostredí s názvom OAuth 2.0 playground 34. Na tomto mieste bolo vždy vidieť aktuálny zoznam služieb, k zdrojom ktorých bolo možné získať prístup. K akým zdrojom sa snažíme získať prístup, vyjadruje takzvaný rozsah. Dostupné rozsahy vždy nájdeme u poskytovateľa služieb. Každý rozsah obsahuje vysvetlenie, k akej množine dát dokážeme pristupovať jeho použitím. Každá služba má aspoň jeden vlastný rozsah. Pomocou rozsahu vieme získať oprávnenie pristupovať k určitej č asti služby alebo pomocou jej prostriedkov získať dáta. Rozsah je veľmi dôležitou veličinou v celom procese overovania identity. Za bežných podmienok je potrebné poznať rozsah už počas overovania, inak neskôr nebudeme môcť získať širšie spektrum zdrojov, než k akým sme požiadali pri overovaní. Rozsahy u Google majú tvar URL adresy. Takáto URL adresa má tvar zložený z dvoch častí. V prvej časti je adresa služby, od ktorej sa snažíme získavať zdroje. Nasleduje lomítko a za ním slovný popis zdrojov, ku

34 https://developers.google.com/oauthplayground/ 27 ktorým žiadame prístup, čo predstavuje druhú časť. Jednotlivé slová sú oddelené bodkou. Na konci rozsahu sa nesmie nachádzať lomítko ani bodka.

Obr. 8: Štruktúra rozsahov u Google 5.1. Použitie OAuth 2.0 prvej verzie

Podľa dokumentácie [25] je potrebné v prvom kroku užívateľa presmerovať na adresu, kde prebieha overenie identity. Táto adresa je dostupná len za použitia SSL komunikačného protokolu. V prípade, že presmerovanie pôjde cez protokol HTTP, požiadavka bude zamietnutá. Nakoľko v tejto fáze nebolo možné použiť žiadnu oficiálnu knižnicu, bolo potrebné všetky požiadavky vytvárať ručne pomocou HTTP objektov v jave. K požiadavke presmerovania bolo potrebné priložiť aj niekoľko parametrov, ktoré plnili rôznu úlohu. Prvým z nich bol typ odpovede. Google podporuje dodnes dva typy odpovedí - kód alebo dočasný token. Ďalšími dvoma dôležitými parametrami boli Client Id a adresa presmerovania. Hodnoty týchto parametrov sa musia vždy zhodovať s hodnotami, ktoré nastavíme v Google Console. Spolu s požiadavkou musíme taktiež poslať už skôr spomínaný rozsah vo forme parametru a nakoniec máme možnosť použiť jeden voliteľný parameter zvaný stav. Ten nám pomáha previesť aplikáciu do nami požadovaného stavu po úspešnom overení identity a získaní zdrojov. Typickým príkladom môže byť presmerovanie na správnu adresu v našej aplikácii, zobrazenie požadovaných informácií alebo len nejaká správa, ktorú potrebujeme doručiť užívateľovi alebo aplikácii po dokončení procesu overenia identity. V momente, kedy bol užívateľ presmerovaný zo serveru po úspešnom overení identity a získaní prístupu k zdrojom, bol spolu s presmerovaním 28 zaslaný overovací kód, pomocou ktorého bolo možné získať daný token. Tu však nastal problém, pretože oficiálna dokumentácia nepopisovala, ako použiť obdržaný kód k získaniu tokenu pre užívateľa. Musel som teda opäť navštíviť komunitné fóra ako stackoverflow.com a vyhľadať riešenie tohoto problému. Po získaní tokenu máme akoby podpisový kľúč, ktorým podpisujeme jednotlivé požiadavky pri získavaní zdrojov. Formulovanie požiadaviek väčšinou nájdeme v dokumentácii služby, ktorú sa snažíme používať rovnako ako spôsob, ktorým požiadavky podpisovať. Spočiatku som sa snažil postupovať pomocou tohoto prístupu. Neskôr však vyšla nová verzia dokumentácie, ktorá celú situáciu okolo použitia protokolu OAuth zmenila.

5.2. Použitie OAuth 2.0 neskoršia verzia

Na začiatku leta 2013 vyšla novšia verzia dokumentácie k použitiu protokolu OAuth 2.0 [26]. S jej príchodom sa použitie protokolu značne zjednodušilo. Na konci bolo možné nájsť odkazy ku knižniciam pre prácu s protokolom v rôznych programovacích jazykoch. Ako už "bolo zvykom", Google knižnicu pre jazyk Java nedávno zmenil a vymenil obsah odkazu z OAuth klient 35 na API klient36 . Táto diplomová práca bola vypracovaná za pomoci knižnice OAuth klient. Stručný popis, ktorý sa nachádza na adrese, kde nájdeme java knižnice pre prácu s protokolom, sa snaží naviesť vývojára správnym smerom, ako celý tok previesť. Ja som však použil JavaDoc, ktorý je dostupný ku knižnici v kombinácii s vysvetleniami v popise pod nadpisom "Authorization code flow". Pre vytvorenie prvotného URL presmerovania slúži trieda AuthorizationCodeRequestUrl, ktorej stačí poskytnúť cieľovú adresu, Client Id a rozsah. Ďaľším voliteľným atribútom je stav, ktorý obsahuje adresu, z ktorej sa snažím získať oprávnenia pristupovať k zdrojom. Následne na túto adresu presmerujem užívateľa na server. Tu zadá svoje prihlasovacie údaje. Vzápätí ho server informuje o zdrojoch, ktoré sa chystá poskytnúť aplikácii. Po odsúhlasení prístupu je presmerovaný spať na adresu spätného volania. Na tomto mieste nám prináša knižnica od Google lepšie možnosti, ako tomu bolo pri predchádzajúcej verzii dokumentácie. Pomocou triedy AuthorizationCodeResponseUrl získame overovací kód. Tento kód vložíme do triedy AuthorizationCodeTokenRequest spoločne s parametrami adresy spätného volania, typu overenia identity, Client Id a Client Secret a taktiež s rozsahom. V prípade, že ktorýkoľvek z týchto

35 https://code.google.com/p/google-oauth-java-client/wiki/OAuth2

36 https://code.google.com/p/google-api-java-client/wiki/OAuth2 29 parametrov nebude korešpondovať s parametrami získanými v Google Console, príde ako odpoveď chyba. V opačnom prípade získame objekt TokenResponse. Tento objekt je už poslednou fázou overovania identity užívateľa. Pomocou neho získame inštanciu objektu Credential, ktorý už slúži ako získané oprávnenie. Môžeme ho použiť u každej služby spoločnosti Google, ktorá podporuje overenie prístupu k API pomocou protokolu OAuth 2.0. Každý prístupový token obsahuje č asový údaj svojej platnosti, po ktorej skončení je potrebné ho znovu načítať. Objekt triedy Credential sa o toto znovunačítanie postará sám, ak je to možné. V opačnom prípade je potrebné požiadať užívateľa o opätovné overenie prístupu. Jedná sa o bežnú časť

špecifikácie 37. Zvláštne však je, že jej implementáciu nenájdeme u spoločnosti Facebook.

5.3. Google Console

Google Console je webové rozhranie pre správu, zobrazenie návštevnosti, dát, prihlasovaní a faktúr pre všetky API od spoločnosti Google, ktoré používa náš projekt [27]. Projekt je pomenovaná kolekcia informácií o aplikácii, jej oprávneniach, členoch tímu, ktorý ju tvorí, všetkých API, ktoré používa a iné. Registrovaný vývojár môže vytvárať projekty, prezerať alebo editovať existujúce projekty, ktoré vytvoril alebo v ktorých sa nachádza ako člen tímu. Vo vrchnej časti konzoly je možné nájsť zoznam projektov, ku ktorým má prístup, rovnako ako príkazy pre správu projektov. Táto časť sa taktiež od začiatku mojej práce zmenila. Dnes môžme nájsť dve verzie tohoto rozhrania. Jedno, pôvodné, ktoré nesie označenie Google

Console38 a druhé, novšie, ktoré má pomenovanie Google Developers Console 39, avšak Google naň odkazuje ako Cloud Console. Z dôvodu zovšeobecnenia som preto zvolil pomenovanie Google Console. Na to, aby sa naša aplikácia dokázala dorozumieť so službami spoločnosti Google, je nevyhnutné na tomto mieste vytvoriť nový projekt, ktorý predstavuje našu aplikáciu. Informácie vyplnené v tejto časti sa potom budú zobrazovať užívateľovi v čase, kedy bude schvaľovať prístup našej aplikácie k jeho zdrojom. Ďalej je potrebné nastaviť prístup k službám, ku ktorým bude naša aplikácia pristupovať. To je možné spraviť pomocou jednoduchého prepínača v časti

37 http://tools.ietf.org/html/rfc6749#page-10

38 https://code.google.com/apis/console

39 https://cloud.google.com/console 30 venovanej službám. Posledným, čo je nevyhnutné v tejto časti nastaviť, je prístup k API. Môžeme vytvoriť hneď niekoľko prístupov pre rôzne typy klientov. Či už pre klienta typu server, prehliadač alebo mobilná aplikácia. Po vytvorení prístupu získame dve dôležité hodnoty zvané Client Id a Client Secret. Pomocou nich sa identifikuje naša aplikácia počas procesu overenia identity a získania prístupu k dátam užívateľa. Spomínal som ich už v predchádzajúcej kapitole. Poslednou dôležitou hodnotou je adresa spätného volania. Tá sa musí presne zhodovať s adresou, ktorú zašle naša aplikácia serveru pre overenie identity pri presmerovaní užívateľa. Jedná sa o návratová adresu, kam bude presmerovaný užívateľ po úspešnom overení identity. Obyčajne na nej nájdeme dokončenie získavania tokenu pre prístup k dátam užívateľa.

Obr. 9: Vytvorenie prístupu k API v Google Console 5.4. Získanie rozšíreného tokenu

Jedným z problémov, ktoré bolo potrebné vyriešiť, bolo získanie rozšírenia tokenu. Jednoducho povedané väčšej množiny oprávnení, než aké naša aplikácia žiadala pri overení identity užívateľa. Tento problém vznikol aplikovaním politiky minimálnych oprávnení. Jej pravidlom je žiadať iba takú množinu oprávnení, bez ktorej by nebol možný bezproblémový chod programu. Jedno oprávnenie môžeme v tomto kontexte chápať ako jeden rozsah. V situácii, kedy naša aplikácia komunikuje s viac ako jednou službou, musíme žiadať schválenie oprávnení pre každú zo služieb. Predstavme si situáciu, kedy máme dve JavaServer Faces stránky. Na každej zobrazujeme dáta zo zdrojov inej služby. Po príchode užívateľa na prvú z nich si vyžiadame overenie identity a prístup k istej časti zdrojov. Po návrate späť, prejde užívateľ na druhú stránku, kde chceme zobraziť iné zdroje a sprístupniť ich užívateľovi. Požiadavka na server bude však typicky neúspešná, pretože pri

31 prvom overení identity a žiadosti o prístup k zdrojom sme si dané oprávnenia nevyžiadali. Tento problém je možné vyriešiť vyžiadaním celej množiny oprávnení pri prvom overení identity. To je však v rozpore s už spomínanou politikou minimálnych oprávnení. Hľadal som teda možnosti, ako vyriešiť tento problém. Prvou vecou, ktorú som si všimol, bola skutočnosť, že zo servera dostávam odpoveď chyba číslo štyristotri - zamietnutý prístup. Zo školského kurzu PV243 - Pokročilé Java technologie: JBoss40 som už trochu poznal java technológiu CDI. Taktiež v pracovnom prostredí sme práve riešili istý problém ohľadom Java AOP41 v Spring frameworku42 . Jednalo sa o vytvorenie jednoduchého logu pre aplikáciu, ktorý by bol dostupný užívateľovi. Prišiel som k záveru, že by bolo vhodné použiť CDI Interceptor, ktorý bude zachytávať výnimku zamietnutého prístupu a spustí opätovný proces overovania identity spolu so žiadosťou o širšiu množinu oprávnení k prístupu. V prípade, že server obdrží rovnakú množinu rozsahov ako pri prvom overovacom procese, užívateľ nespozoruje žiadnu zmenu. V skôr spomínanom parametri stav som pritom zasielal vždy informáciu o tom, na akom mieste sa užívateľ nachádzal pred tým, než bol presmerovaný. To zabezpečovalo plynulý návrat na miesto, odkiaľ som užívateľa pri práci prerušil. Interceptor som nazval GoogleLogin a jeho mapovanie je určené na metódy, ktoré sa snažia získavať dáta alebo komunikovať so službami Google. Prípadne je možné mapovanie zaviesť na celú triedu, ak sa v triede nachádza viacero metód, ktoré so službami komunikujú.

5.5. Portlety

V mojej práci nájdeme dva portlety, ktoré prezentujú komunikáciu so službami Google. Jedným z nich je Google Plus portlet. Jeho úlohou je zobrazenie základných informácií o užívateľovi. V druhom portlete zvanom portlet je možné nájsť súbory a zložky, ktoré má užívateľ nahrané na svojom online disku od spoločnosti Google. Užívateľ môže prechádzať priečinkami, mazať súbory alebo pridávať k nim hviezdičku, čo značí obľúbené súbory a priečinky. Poslednou funkciou, ktorú môže užívateľ využiť je možnosť nahrať nový súbor. V prípade, že sa oba portlety nachádzajú na jednej stránke, oprávnenia k prístupu sa sčítavajú tak, aby pri overovaní identity získali oba

40 https://is.muni.cz/predmet/fi/jaro2014/PV243

41 http://stackoverflow.com/questions/4829088/java-aspect-oriented-programming-with- annotations

42 http://docs.spring.io/spring/docs/2.5.4/reference/aop. 32 portlety oprávnenia naraz. Teda po návrate užívateľ nemusí overovať svoju identitu pre každý z portletov zvlášť, ale overenie sa vykoná v jedinom kroku.

33 6. Implementácia protokolu OAuth od Facebook

Najrýchlejšou možnou cestou, ako implementovať protokol OAuth pre sprístupnenie zdrojov služieb Facebook, je použiť niektorý z postupov, ktoré sú opísané v oficiálnej dokumentácii43 . Nenájdeme tu však možnosť priamej implementácie pre jazyk java. Jedinou cestou, ktorú tu nájdeme spomenutú, je použitie knižnice Spring Social44 , ktorá je súčasťou webového frameworku Spring pre platformu Java EE. Nechcel som však pridávať žiadne knižnice, ktoré by mohli priniesť ďalšie zbytočné závislosti na knižnici Spring do projektu. Mojou snahou bolo ostať pri technológii CDI a JavaServer Faces. V dokumentácii sa ešte spomína vybudovanie vlastnej implementácie overovania identity jednoduchými HTTP požiadavkami [28]. Tento postup by sa mohol javiť správnou voľbou pre implementáciu protokolu. Následne som sa teda rozhodol vyhľadať nejaké iné knižnice, ktoré by bolo možné dobre použiť pri implementácii služieb spoločnosti Facebook. Takýchto knižníc je už možné nájsť dosť veľké množstvo.

6.1. Výber správnej knižnice

Počas svojho hľadania som sa sústredil na dve dôležité veci, ktoré som od knižnice požadoval. Jednoduchá použiteľnosť a podpora overovania identity pomocou protokolu OAuth. Hlavným dôvodom pre takéto rozhodnutie bolo nesnažiť sa opäť robiť prácu, ktorú už mohol niekto predo mnou elegantným spôsobom vyriešiť.

Prvou z knižníc, s ktorou som sa stretol, bola knižnica face4j45 . Implementácia niekoľkých Java objektov, ktoré umožňovali jednoducho overiť identitu užívateľa a získať prístup k jeho zdrojom. Aj keď spočiatku táto knižnica vyzerala veľmi sľubne, postupne som prišiel k záveru, že absencia pokročilej dokumentácie by mohla neskôr spôsobovať problémy pri tvorbe rozhraní pre portlety. V lepšom prípade by bolo potrebné použiť inú knižnicu, pomocou ktorej by som získaval zdroje. Neskôr sa ukázalo, že táto knižnica upadla do zabudnutia, podpora sa vytratila a spolu s ňou aj ľudia, ktorí by knižnicu vo svojich projektoch používali. Ďaľšou z knižníc, ktorú bolo možné použiť bola knižnica facebook4j 46. Tu som našiel splnené všetky požiadavky, ktoré som zadal.

43 https://developers.facebook.com

44 http://projects.spring.io/spring-social-facebook/

45 https://github.com/Codigami/face4j/

46 http://facebook4j.org/en/index.html 34 Knižnica sa pridávala do projektu pomocou jednoduchej maven závislosti. Je napísaná v čistom programovacom jazyku java a nenesie žiadne ďalšie závislosti. Takisto má zabudovanú podporu pre komunikáciu pomocou protokolu OAuth so službami spoločnosti Facebook. Obsahuje rozsiahlu dokumentáciu a dobre spracovaný JavaDoc. Problémom by mohli byť časti, ktoré nie sú implementované47 . Hlavne však podpora Open Graph API48 . Poslednou zo zaujímavých alternatív mohla byť knižnica RestFB49 . Má veľmi rozsiahlu dobre spracovanú dokumentáciu. Je jednoduchá pre použitie v java prostredí. Takisto prináša podporu historického REST API. Obsahuje však jeden veľký problém, ktorým je nemožnosť vyvolať proces overenia identity užívateľa a získania jeho zdrojov pomocou protokolu OAuth. Tento je nevyhnutné vytvoriť samostatne pomocou HTTP požiadaviek. Získaný užívateľský prístupový token je následne možné použiť pre prácu so zdrojmi. Na druhú stranu knižnica obsahuje podporu pre získanie tokenu pre aplikáciu (tzv. 2-legged OAuth). Nakoľko vytvorenie toku pre overenie identity užívateľa nemusí byť nevyriešiteľnou úlohou, môže byť použitie tejto knižnice zaujímavým riešením.

6.2. Implementácia OAuth 2.0

Rozhodol som sa pre použitie knižnice facebook4j. Hlavným dôvodom bola jej jednoduchosť a súčasne podpora protokolu OAuth 2.0 pre získanie užívateľského tokenu. Zároveň mi knižnica jednoduchým spôsobom poskytovala potrebné nástroje pre vytvorenie zadávateľom požadovaných portletov. Pri vytváraní procesu overenia užívateľa som použil veľmi podobný postup, ako pri tvorbe overovacieho procesu pre služby spoločnosti Google. Na stránkach knižnice facebook4j nájdeme v príkladoch jednoduchý popis, ako celý proces overenia previesť. V prvom kroku je však potrebné vytvoriť novú aplikáciu na strane Facebook Developers. Tento krok by sme mohli porovnať s vytvorením nového projektu v Google Console u Google. Jedná sa v podstate o úplne rovnakú záležitosť. Poskytnúť poskytovateľovi identity základné informácie o našej aplikácii a získať dve dôležité hodnoty: App ID a App Secret. Následne tieto dve hodnoty vložíme do našej aplikácie spolu so správne nastavenou adresou spätného volania. Celý proces overenia identity obsluhuje jediná trieda s názvom FacebookFactory. Pomocou tejto triedy získame na

47 http://facebook4j.org/en/not-supported.html

48 https://developers.facebook.com/docs/opengraph/

49 http://restfb.com/ 35 začiatku adresu presmerovania užívateľa, kde ho v prípade potreby overenia identity presmerujeme. Táto adresa obsahuje informáciu o rozsahoch, ktoré naša aplikácia požaduje, a taktiež adresu spätného volania. Následne užívateľ overí svoju identitu a po overení bude presmerovaný späť na adresu spätného volania, kde prebieha dokončenie overovacieho procesu a získanie užívateľského prístupového tokenu. Po jeho získaní sa tento token ďalej používa pre prístup k službám spoločnosti Facebook.

6.3. Facebook Apps

Facebook Apps je webové rozhranie umožňujúce vytvárať aplikácie, ktoré nájdeme na Facebooku [29]. Jednu takúto aplikáciu si môžme predstaviť ako pomenovanú množinu hodnôt. Nájdeme tu veľké množstvo rôznych nastavení, ktoré pomáhajú lepšie popísať našu aplikáciu. Vývojár po zaregistrovaní vývojárskeho účtu môže v tejto časti vytvárať a modifikovať neobmedzené množstvo aplikácií. Asi najdôležitejšou funkciou, ktorú tu nájdeme, je prepnutie aplikácie do módu, kedy je nedostupná verejnosti a môže ju používať len člen tímu, ktorý je uvedený v zozname členov. Po vytvorení novej aplikácie je nevyhnutné vyplniť jej názov a kategóriu, do ktorej spadá. Následne sa dostaneme na obrazovku so základnými nastaveniami danej aplikácie. Tu môžeme jednoducho nájsť hodnoty App ID a App Secret, ktoré potrebujeme poznať na to, aby sme mohli používať komunikáciu pomocou protokolu OAuth. V pokročilých nastaveniach je ešte potrebné nastaviť typ aplikácie. Môže sa jednať o webovú alebo natívnu aplikáciu. Poslednou hodnotou, ktorú je potrebné nastaviť, je adresa spätného volania. Samozrejme, nájdeme tu ešte veľké množstvo doplňujúcich nastavení ako vekové obmedzenia, nastavenia platieb a štatistiky používania aplikácie. Poznať ich však nie je nevyhnutné pre porozumenie chodu aplikácie v tejto práci.

36 Obr. 10: Vytvorená aplikácia vo Facebook Apps 6.4. Portlety

Diplomová práca obsahuje dva portlety komunikujúce so službami spoločnosti Facebook. Prvý portlet sa venuje práci s udalosťami užívateľa. Môže pomocou neho odpovedať či sa udalosti zúčastní, nezúčastní alebo ešte nevie. Takisto tu smie vytvoriť novú udalosť. V druhom portlete je možné nájsť schránku správ užívateľa. Na jednotlivé správy je možné odpovedať a prezerať si ich históriu.

37 7. Problémy, ktoré pri práci vznikli

V prvej časti mojej práce sa vyskytoval iba jediný problém. Dostatočne včas a dobre odhadnúť, aké bude smerovanie poskytovateľov identity a zaznamenať správny trend, ktorý bude preferovaným riešením pri tvorbe webových aplikácií nezávislými vývojármi. Počas posledných mesiacov sa však objavuje celkom nová oblasť problémov. Eran Hammer, vedúca osobnosť komunity pre tvorbu špecifikácie protokolu OAuth 2.0 a autor protokolu OAuth 1.0, vyhlásil vážne obavy z budúcnosti novej verzie protokolu [30]. Opustil OAuth komunitu a rovnako aj IETF komunitu. Vyškrtol svoje meno zo zoznamu autorov. V príspevku na blogu, ktorý venuje svojej práci, uvádza, že asi najväčší problém je v samotných vývojároch aplikácií, ich lenivosti podrobnému štúdiu a pochopeniu, ako protokol funguje. Výsledkom toho je nesprávna a nedostatočne zabezpečená implementácia protokolu. Cieľom protokolu OAuth bolo poskytnúť jednoduchú cestu a zároveň bezpečný prostriedok pre komunikáciu aplikácií tretích strán. Komunita sa však v posledných fázach starala viac o firemné prípady použitia ako o jednoduchosť a účelnosť implementácie. Vzniklo tak veľké množstvo špeciálnych drobných prípadov použitia, ako s protokolom pracovať. Jeho jednoduchosť sa postupne vytrácala. Na záver uvádza, že implementácia protokolu OAuth 2.0 v rukách bezpečnostných expertov obyčajne vedie k správnemu riešeniu. Ako príklady popisuje spoločnosti Facebook a Google, ktoré svojim vlastným spôsobom implementovali tento protokol. Mohli by preto v budúcnosti byť vzorom v oblasti implementácie. Pri práci na praktickej časti práce bolo niekoľko problémov, s ktorými som sa musel vysporiadať. Prvou asi najzložitejšou prekážkou boli neustále zmeny

API od spoločnosti Google50 51 . V priebehu minulého roka sa takmer každé dva mesiace špecifikácia menila a oficiálna dokumentácia uzrela svetlo sveta až v polovici roka. Ďaľším z problémov, na ktoré som narazil, bolo zvláštne správanie PertletBridge, ktorý má na starosti sprostredkovanie komunikácie medzi portálom GateIn a jednotlivými portletmi. Po volaniach vyvolaných správaním užívateľa sa mi vrátila len nešpecifikovaná výnimka a portlet vyhlásil chybu. Aj po dlhšom hľadaní, kde chyba nastala, som neprišiel k žiadnym reálnym výsledkom. Pravdepodobne sa problém nachádzal niekde v implementácii

50 https://code.google.com/p/google-api-java-client/downloads/list?can=1&q=&colspec=Filename +Summary+Uploaded+ReleaseDate+Size+DownloadCount

51 https://code.google.com/p/google-oauth-java-client/downloads/list? can=1&q=&colspec=Filename+Summary+Uploaded+ReleaseDate+Size+DownloadCount 38 PortletBridge, ktorá nevedela spracovať volania protokolu OAuth od spoločnosti Google. Situáciu som vyriešil novou implementáciou protokolu OAuth, ktorá vyšla o niekoľko mesiacov a problém zmizol. Poslednou ťažkosťou, ktorá výrazne komplikovala celú situáciu počas tvorby portletov bola technológia JavaServer Faces a snaha o spojenie s technológiou CDI. V aplikácii som sa snažil použiť jedinú inštanciu objektu, ktorý by uchovával získaný token pre komunikáciu s poskytovateľom identity. Jeden pre Facebook a jeden pre Google. Tento objekt som vkladal pomocou injektovania, ktoré je súčasťou technológie CDI do web kontrolérov. Keď som sa snažil o komunikáciu web kontrolérov s týmto objektom, po dlhom čase strávenom pri debugovaní projektu som zistil, že tento pôvodne určený ako jediný objekt uložený v session sa vytvára opätovne pri každom zavolaní webového kontroléra. Celá situácia spôsobovala neustále vyvolávanie požiadavky o overenie identity užívateľa a získania nových oprávnení pri každom načítaní stránky. Bolo zjavné, že proxy vytváralo vždy nový objekt a neinjektovalo existujúci52 objekt. Hľadal som dlhší čas riešenie, ako tento problém odstrániť. V skutočnosti však na internete neexistuje veľké množstvo zdrojov, ktoré by popisovali podobnú situáciu. Experimentovaním som však objavil možnosť, ako sa tejto chybe úspešne vyhnúť. Prepnutím webových kontrolérov z rozsahu ViewScoped do rozsahu SessionScoped začali veci fungovať správne [31]. Toto riešenie sa mi však nezdalo uspokojivým. Hľadal som ďalšie možnosti riešenia. Trochu svetla priniesla diskusia na komunitnom serveri stackoverflow.com53 . Nasmerovala ma presunúť všetky web kontroléry do technológie CDI a spraviť z nich CDI beany. Tie však neobsahujú požadovaný rozsah ViewScoped, ale len rozsah ConversationScoped, ktorý sa mi zdal príliš zložitý na to, aby som nútil iných vývojárov k jeho použitiu, v prípade že by nadväzovali na moju prácu. Na základe blogu Michaela Kurza [32] som objavil možnosť, ako pridať k CDI v kombinácii s JavaServer Faces rozsah ViewScope. Namiesto použitia knižnice JavaServer Faces vo verzii 2.0 bolo potrebné jej verziu nahradiť novšou s označením 2.2. Táto cesta bola však slepou uličkou, pretože aplikačný server JBoss AS 7.1.1, ktorý zabezpečuje chod portálu GateIn, nepodporuje JavaServer Faces 2.2. Môj pokus o násilné pridanie podpory podľa návodu 54 narušil chod serveru a už viac nebolo možné ho naštartovať.

52 http://stackoverflow.com/questions/14231044/injecting-one-view-scoped-bean-in-another-view- scoped-bean-causes-it-to-be-recre

53 http://stackoverflow.com/questions/18988276/viewscoped-jsf-and-cdi-bean

54 https://community.jboss.org/thread/203257 39 Technológie teda nedovoľovali použiť ViewScoped rozsah v mojej práci pre portlety vložené do portálu GateIn. Kontroléry komunikujúce s JavaServer Faces užívateľským rozhraním sú teda CDI beany, ktorých rozsah je definovaný ako SessionScoped. Jediným negatívom, ktoré prináša takáto implementácia je plytvanie pamäťou v prípade rozsiahlych projektov, akým portál GateIn určite je a zároveň možno zbytočné ukladanie stavu už navštívených stránok užívateľa.

40 Záver

Cieľom diplomovej práce bolo preskúmať problematiku prihlasovania do sociálnych sietí Google+, Facebook a Twitter z aplikácií tretích strán. Naštudovať java špecifikáciu Portlet JSR-286 a PortletBridge zloženého zo špecifikácií JSR-301 a JSR-329. Na základe získaných poznatkov navrhnúť riešenie prihlasovania pomocou účtov sociálnych sietí. V poslednom kroku vytvoriť sadu portletov, ktoré budú toto prepojenie prezentovať v užívateľsky prívetivej podobe. Na základe analýzy bol pre komunikáciu so sociálnymi sieťami zvolený protokol OAuth 2.0. Protokol vznikol ako vyplnenie medzery, ktorá sa objavila s príchodom sociálnych sietí v momente, keď sa snažili svoje API sprístupniť zabezpečeným kanálom aplikáciám tretích strán. Dokumentácia protokolu sa dostala na dobrú úroveň a je ho pomerne jednoduché implementovať do aplikácií. Následne bola vytvorená sada niekoľkých portletov, ktoré demonštrujú použitie protokolu pre prepojenie so sociálnymi sieťami Google+ a Facebook. Portlety prezentujú jednoduchým spôsobom fungovanie protokolu OAuth 2.0 a dovoľujú užívateľovi vykonávať základné aktivity typické pre sociálne siete. Súčasťou diplomovej práce je aj vypracovaná správa, ktorá obsahuje krátku analýzu súčasného stavu, v ktorom sa nachádzali sociálne siete na začiatku práce. Táto správa bola použitá spoločnosťou Red Hat pri rozhodovaní o smerovaní portálu GateIn v smere prepojenia sociálnych sietí. Ciele stanovené v práci boli splnené. Avšak v určitých fázach bolo nevyhnutné spraviť malé kompromisy ako použitie open source JavaServer Faces implementácie PrimeFaces a až neskôr prepis do Red Hat implementácie RichFaces alebo použitie SessionScoped CDI beanov namiesto ViewScoped JavaServer Faces kontrolérov, ktoré sú pre prácu s JavaServer Faces príznačnejšie. Testovanie funkčnej aplikácie prebiehalo v portáli GateIn verzie 3.6.0.Final. Portál beží na aplikačnom serveri spoločnosti Red Hat označovanom ako JBoss AS 7.1.1. Používal som prehliadače Safari 7.0.1 a Mozilla Firefox 26.0 v operačných systémoch OS X Mavericks 10.9.x a Mac OS X Lion 10.7.x. Počas testovania sa občas vyskytovali chyby s nedostatkom dostupnej operačnej pamäte. Tieto problémy bolo možné vyriešiť reštartom aplikačného serveru. Experimentálne testy čiastkových modulov prebiehali taktiež na aplikačných serveroch JBoss AS 7.1.1, JBoss AS 7.2.0, JBoss AS 8.0.0.beta1 tiež označovaným ako WildFly a Apache Tomcat 7.0.42.

41 Navrhnuté riešenie spĺňa všetky štandardy aplikácie, ktorú je možné spustiť na platforme Java EE. Je pripravené pre prenos do podnikového prostredia na prezentáciu zadávateľovi. Môže sa tak stať dobrým stavebným prvkom pre ďalšie nadväzujúce projekty, ktorých úlohou bude získavať zdroje alebo komunikovať so sociálnymi sieťami v prostredí podnikových portálov.

42 Použitá Literatúra [1] SOFTWARESECURED - APPLICATION SECURITY EXPERTS. Federated Identities: OpenID vs SAML vs OAuth [online]. [cit. 2013-12-04]. Dostupné z: http://www.softwaresecured.com/2013/07/16/federated-identities- openid-vs-saml-vs-oauth. [2] The Open Group: Leading the development of open, vendor-neutral IT standards and certifications. Introduction to Single Sign-On [online]. [cit. 2013-12-04]. Dostupné z: http://www.opengroup.org/security/sso/ sso_intro.htm. [3] Single Sign On Authentication. AUTHENTICATIONWORLD.COM - THE BUSINESS OF AUTHENTICATION. What Is Single Sign On? [online]. [cit. 2013-12-04]. Dostupné z: http://www.authenticationworld.com/Single- Sign-On-Authentication. [4] Wikipédia. Identity management system [online]. 2013, 27. November 2013 [cit. 2013-12-05]. Dostupné z: http://en.wikipedia.org/wiki/ Identity_management_system. [5] Wikipédia. Diffie–Hellman key exchange [online]. 2013 [cit. 2013-12-05]. Dostupné z: http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange [6] SAML XML.org: Online community for the Security Assertion Markup Language (SAML) OASIS Standard. Saml..org [online]. 1993 [cit. 2013-12-06]. Dostupné z: http://saml.xml.org. [7] Horst-Görtz Institute Ruhr-University of Bochum. How To Break XML Signature and XML Encryption [online]. 2011. Dostupné z: https:// www.owasp.org/images/5/5a/ 07A_Breaking_XML_Signature_and_Encryption_-_Juraj_Somorovsky.pdf. Presentation. Horst-Görtz Institute Ruhr-University of Bochum [8] Hueniverse: Technology blog of Eran Hammer. Explaining OAuth [online]. 2007, 5. september 2007 [cit. 2013-12-07]. Dostupné z: http:// hueniverse.com/2007/09/explaining-oauth/ [9] RFC 5849. The OAuth 1.0 Protocol. INFORMATIONAL: Internet Engineering Task Force (IETF), 2010. Dostupné z: http://tools.ietf.org/html/rfc5849 [10] OAuth. OAuth Security Advisory: 2009.1 [online]. 2009, 23. Apríl 2009 [cit. 2013-12-10]. Dostupné z: http://oauth.net/advisories/2009-1/

43 [11] Google Accounts Authentication and Authorization. Choosing an Auth Mechanism [online]. 2013, 6. august 2013 [cit. 2013-12-11]. Dostupné z: https://developers.google.com/accounts/docs/GettingStarted [12] Wikipédia. Google Friend Connect [online]. 2011 [cit. 2013-12-11]. Dostupné z: http://en.wikipedia.org/wiki/Google_Friend_Connect [13] Facebook developers. Announcing Facebook Connect [online]. 2008 [cit. 2013-12-11]. Dostupné z: https://developers.facebook.com/blog/post/ 2008/05/09/announcing-facebook-connect/ [14] StackOverflow.com. What's the difference between OpenID and OAuth? [online]. 2010 [cit. 2013-12-20]. Dostupné z: http://stackoverflow.com/ questions/1087031/whats-the-difference-between-openid-and-oauth [15] Cakebaker. OpenID versus OAuth from the user’s perspective [online]. 2008 [cit. 2013-12-20]. Dostupné z: http://cakebaker.42dh.com/2008/04/01/openid- versus-oauth-from-the-users-perspective/ [16] Software as she's developed. OAUTH-OPENID: YOU’RE BARKING UP THE WRONG TREE IF YOU THINK THEY’RE THE SAME THING [online]. 2007 [cit. 2013-12-20]. Dostupné z: http://softwareas.com/oauth-openid-youre- barking-up-the-wrong-tree-if-you-think-theyre-the-same-thing [17] SOVIS, Pavol, Florian KOHLAR a Jorg SCHWENK. Security Analysis of OpenID. Ruhr-University Bochum Bochum, Germany, 2010. Dostupné z: http://www.nds.rub.de/media/nds/veroeffentlichungen/2010/12/20/ CameraReady_SecurityofSingleSignOn.pdf. Publikácia. Ruhr-University Bochum Bochum, Germany. [18] Sites.google.com. OpenID Review: Security Issues [online]. [cit. 2013-12-20]. Dostupné z: https://sites.google.com/site/openidreview/issues [19] REDHAT. GateIn portal - Project documentation [online]. 2012 [cit. 2013-12-21]. Dostupné z: https://docs.jboss.org/author/display/GTNPORTALDOC/ Home [20] BOYE, Janus. EXo Portal and JBoss Portal join forces [online]. 2009 [cit. 2013-12-26]. Dostupné z: http://jboye.com/blogpost/exo-portal-and-jboss- portal-join-forces/ [21] ORACLE CORPORATION. Introduction to Javaserver Faces - What is JSF? [online]. 2005 [cit. 2013-12-27]. Dostupné z: http://www.oracle.com/ technetwork/topics/index-090910.html [22] ORACLE CORPORATION. The Java EE 6 Tutorial: JavaServer Faces Technology [online]. [cit. 2013-12-30]. Dostupné z: http://docs.oracle.com/javaee/6/ tutorial/doc/bnaph.html

44 [23] ORACLE CORPORATION. The Java EE 6 Tutorial: Introduction to Contexts and Dependency Injection for the Java EE Platform [online]. [cit. 2013-12-30]. Dostupné z: http://docs.oracle.com/javaee/6/tutorial/doc/giwhb.html [24] GOOGLE. Google Accounts Authentication and Authorization: OAuth 1.0 for Web Applications [online]. 2012 [cit. 2013-12-31]. Dostupné z: https:// developers.google.com/accounts/docs/OAuth [25] GOOGLE. Google Accounts Authentication and Authorization: Using OAuth 2.0 for Login (early version) [online]. 2012, 11.12.2013 [cit. 2013-12-31]. Dostupné z: https://developers.google.com/accounts/docs/OAuth2LoginV1 [26] GOOGLE. Google Accounts Authentication and Authorization: Using OAuth 2.0 for Web Server Applications [online]. 2013, 2013-12-11 [cit. 2014-01-02]. Dostupné z: https://developers.google.com/accounts/docs/ OAuth2WebServer [27] Google Developers. Google APIs Console Help [online]. 2013, 2013-10-18 [cit. 2014-01-02]. Dostupné z: https://developers.google.com/console/help/ [28] FACEBOOK. Manually Build a Login Flow [online]. 2013 [cit. 2014-01-04]. Dostupné z: https://developers.facebook.com/docs/facebook-login/ manually-build-a-login-flow/ [29] HYPERARTS. Tutorial: How to Create a Facebook Application to Get an App ID for your Website or Blog [online]. 2011, 2011-11-23 [cit. 2014-01-05]. Dostupné z: http://www.hyperarts.com/blog/how-to-create-facebook- application-to-get-an-app-id-for-your-website/ [30] HAMMER, Eran. OAuth 2.0 and the Road to Hell [online]. 2012, 2012-07-26 [cit. 2014-01-05]. Dostupné z: http://hueniverse.com/2012/07/oauth-2-0- and-the-road-to-hell/ [31] MARQUES, Gonçalo. BYTESLOUNGE. Java EE CDI bean scopes [online]. 2013 [cit. 2014-01-05]. Dostupné z: http://www.byteslounge.com/tutorials/ cdi-bean-scopes [32] KURZ, Michael. JSF 2.2: View Scope for CDI. In: JSFlive: Michael Kurz's JSF Weblog: Random thoughts about JavaServer Faces and related stuff [online]. 2013 [cit. 2014-01-05]. Dostupné z: http://jsflive.wordpress.com/2013/07/17/ jsf22-cdi-view-scope/ [33] MIESSLER. Federated ID, OpenID, and OAuth: A Web Authentication Primer [online]. 2009 [cit. 2014-01-08]. Dostupné z: http:// www.danielmiessler.com/blog/federated-id-openid-and-oauth-a-web- authentication-primer

45