Nasazení OAuth 2.0 pro systém Perun

Transkript

1 Masarykova univerzita Fakulta informatiky Nasazení OAuth 2.0 pro systém Perun Bakalářská práce Ondřej Velíšek Brno, jaro 2016

2 Místo tohoto listu vložte kopie oficiálního podepsaného zadání práce a prohlášení autora školního díla.

3 Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Ondřej Velíšek Vedoucí práce: RNDr. Michal Procházka, Ph.D. i

4 Poděkování Děkuji všem, kteří mi s prací pomohli. Jmenovitě prof. Ing. Adamu Heroutovi, Ph.D. za pomoc s odborným textem, vedoucímu práce RNDr. Michalu Procházkovi, Ph.D. za užitečné rady a odbornou pomoc a nakonec svým rodičům za jejich trpělivost a toleranci. Moc si toho vážím. ii

5 Shrnutí Perun je systém, který využívají organizace na správu uživatelů, služeb a řízení přístupu uživatelů ke službám. Tato bakalářská práce má za cíl navrhnout architekturu autentizace a autorizace pomocí protokolu OAuth 2.0, která umožní aplikacím třetích stran bezpečně využívat funkcionalitu Peruna. Dále architekturu implementovat a její funkčnost demonstrovat na ukázkové aplikaci. Architekturu využijí například aplikace organizací, které umožní uživatelům spravovat svoje osobní údaje. Ukázková aplikace pro ně může posloužit jako předloha. V textu popisuji původní architekturu a vysvětluji její nedostatky. Dále v práci navrhuji novou architekturu. Nakonec se věnuji výběru vhodných nástrojů a implementaci nové architektury a ukázkové aplikace. Součástí práce jsou popisy použitých technologií. iii

6 Klíčová slova OAuth 2.0, Perun, delegace práv, webová aplikace, autentizace, autorizace, CORS iv

7 Obsah 1 Úvod Systém Perun Původní architektura autentizace a autorizace Webové aplikace Serverové aplikace Ajax aplikace Autentizace uživatele Autorizace uživatele Nedostatky architektury Autentizační a autorizační technologie SAML OAuth Koncept Způsoby získávání přístupového tokenu Použitelnost protokolu OpenID Connect Cross-Origin Resource Sharing Návrh nové architektury autentizace a autorizace Autentizace uživatele Autorizace uživatele Delegace uživatelských práv Požadavek aplikace na Peruna Implementace nové architektury autentizace a autorizace Výběr autorizačního serveru Spring security OAuth Apache Oltu OpenConext authorization server MITREid Connect APIs Secure Konfigurace autorizačního serveru Ověření přístupového tokenu Perunem Apache modul Openidc Konfigurace webového serveru Apache Zpracování nové identity v Perun RPC Ukázková webová aplikace v

8 7.1 Výběr nástrojů pro serverovou aplikaci Apache Oltu Spring security OAuth Nimbus OAuth Serverová aplikace Výběr nástrojů pro ajax aplikaci Simple OAuth OAuth2 client js Hello JS JSO Ajax aplikace Závěr Bibliografie A Obsah přiloženého CD vi

9 Seznam obrázků 2.1 Vztahy základních entit v systému Perun Sekvenční diagram neúspěšného přidání článku na službu Wiki Sekvenční diagram přidání administrátora na službu Wiki pomocí systému Perun Sekvenční diagram úspěšného přidání článku na službu Wiki Abstraktní diagram komunikace uživatele s Perunem Komunikace uživatele s Perunem přes serverovou aplikaci Komunikace uživatele s Perunem přes ajax aplikaci Komunikační diagram zpracování požadavku uživatele na funkcionalitu Peruna v původní architektuře Sekvenční diagram autentizace a autorizace uživatele v původní architektuře Sekvenční diagram komunikace protokolem SAML Proces získání přístupového tokenu pomocí autorizačního kódu Proces získání přístupového tokenu implicitně Příklad komunikace mechanizmem CORS Diagram autentizace uživatele v navržené architektuře Sekvenční diagram komunikace ajax aplikace s Perunem v navržené architektuře 1 (získání přístupového tokenu) Sekvenční diagram komunikace ajax aplikace s Perunem v navržené architektuře 2 (odeslání požadavku na Peruna) Formulář s žádostí o udělení souhlasu s přístupem k Perunovi Ukázková webová aplikace Správce skupin 33 vii

10 7.2 Implementovaná architektura ukázkové serverové aplikace Implementovaná architektura ukázkové ajax aplikace 37 viii

11 1 Úvod Služby na síti obecně nevystavují veškerou svoji funkcionalitu veřejně, ale definují politiku uživatelských práv. Například uživatel má právo přidat upomínku jen do svého kalendáře, nikoli do kalendáře jiného uživatele. Proces získávání práv k přístupu se nazývá autorizace. Aby služba rozhodla o autorizaci uživatele, potřebuje znát jeho identitu. Proces ověřování identity se nazývá autentizace. Postupným vývojem webových služeb se dospělo do bodu, kdy je žádoucí, aby funkcionalitu webových služeb mohly využívat aplikace třetích stran. Například aplikace se seznamem nadcházejících sportovních zápasů může chtít vložit upomínku do uživatelova kalendáře. Služba kalendáře ale potřebuje autentizovat uživatele. Tím vznikl problém, jak autentizovat uživatele ke službě, aniž by musel poskytnout svoje přístupové údaje nedůvěryhodné aplikaci třetí strany. Dal by jí tím neomezený přístup pracovat se službou uživatelovou identitou. Například sportovní aplikace, tvářící se že jen přidá upomínku na zápas, bude tajně shromažďovat obsah celého kalendáře. Vznikla nová potřeba bezpečně delegovat práva uživatele na aplikace třetích stran. Přitom uživatele informovat a dát mu možnost delegaci práv na aplikaci zamítnout. Možným způsobem jak delegaci uživatelských práv bezpečně řešit, je protokol OAuth 2.0. Perun je systém, který využívají organizace na řízení přístupu uživatelů ke službám. Jeho vývoj zaštiťuje CESNET 1 a Masarykova univerzita. Hlavním komunikačním nástrojem s Perunem je aplikace grafického rozhraní. Protože je Perun komplexní systém s rozsáhlou funkcionalitou, toto rozhraní je složité. Každá organizace má na funkcionalitu jiné požadavky a její uživatelé často využívají jen její zlomek. Proto organizace chtějí vytvořit a udržovat svoje vlastní specifické grafické rozhraní. To je motivací zavedení protokolu OAuth 2.0, protože z pohledu Peruna jde o nedůvěryhodné aplikace třetích stran. Proto je potřeba řešit problém delegace uživatelských práv. Tato bakalářská práce má tři hlavní cíle. Vhodně navrhnout novou architekturu autentizace a autorizace systému, aby umožnila aplikacím organizací bezpečně komunikovat s Perunem. Dále vybrat 1. Sdružení, které provozuje národní e-infrastrukturu pro vědu, výzkum a vzdělávání, 1

12 1. Úvod vhodné nástroje na implementaci a implementovat protokol OAuth 2.0 do systému. A nakonec funkčnost architektury demonstrovat na ukázkové aplikaci, která pak může sloužit jako předloha pro aplikace třetích stran. Strukturu práce můžeme logicky rozdělit na tři celky, analýzu problému, návrh řešení a implementaci. Druhá, třetí a čtvrtá kapitola se věnuje analýze. Popisuji zde, k čemu slouží systém Perun, jeho původní architekturu autentizace a autorizace a proč není vhodná pro využívání aplikacemi třetích stran. Ve čtvrté kapitole rozebírám známé autentizační a autorizační protokoly s důrazem na jejich použitelnost při řešení problému delegace uživatelských práv a jiné použité technologie. Pátá kapitola se zabývá návrhem řešení pomocí protokolu OAuth 2.0. V šesté a sedmé kapitole se věnuji výběru vhodných nástrojů, jejich konfiguraci a implementaci ukázkové aplikace. 2

13 2 Systém Perun V této kapitole popisuji, k čemu systém Perun slouží [1]. Popis uvádím kvůli pochopení kontextu práce a motivace. Pro práci je podsatné jak uživatelé přistupují k funkcionalitě Peruna. Samotná funkcionalita důležitá není. Proto se zaměřuji pouze na obecný koncept. Perun je systém, který využívají organizace pro správu uživatelů, jejich identit, služeb a řídí přístup uživatelů k těmto službám. Jako službu si v tomto kontextu představme správu článků na wiki, počítání v gridové infrastruktuře, přístup k intranetu, cloudové služby,... Vztahy entit v Perunovi popisuje diagram na obrázku 2.1. Skupina 0..* 0..* Služba 0..* 0..* Uživatel 1 1..* Identita Obrázek 2.1: Vztahy základních entit v systému Perun Uživatel může mít přiřazeno více identit. Uživatelé často pracují na několika projektech současně a u každého mají své přístupové údaje. Je žádoucí, aby po ověření jedněch přístupových údajů měli možnost přistoupit ke všem službám, k nimž mají mít jako osoba přístup. Perun distribuuje zodpovědnost mezi organizaci a poskytovatele služeb. Organizace rozděluje uživatele do skupin a určuje k jakým službám mají mít její členové přístup. Poskytovatelé služeb zodpovídají za správu služeb. Perun pak poskytuje identity členů skupiny službě, která typicky těmto členům umožní přístup ke své funkcionalitě. Příklad funkcionality Peruna Pro lepší pochopení uvedu konkrétní příklad základní funkcionality systému Perun. Příklad ilustruje situaci, kde organizace Masarykova univerzita udržuje informace o uživatelích a nabízí jim nějaké služby. K tomu používá systém Perun. Jednou ze nich je služba Wiki, která 3

14 2. Systém Perun uživatelům zobrazuje články. Upravovat je dovoluje pouze administrátorům, jejichž identity má uloženy. Uživatel Kuba je správcem na Masarykově univerzitě a je v Perunovi evidován jako administrátor, který má právo spravovat její skupiny. Pro službu Wiki má vytvořenou skupinu wiki, jejichž členové mají být administrátory služby. Uživatel Petr není v žádné skupině a chce přidat článek na Wiki. Petr Wiki Admini - Perun Admini Kuba Kuba Přidej článek Zamítnuto Obrázek 2.2: Sekvenční diagram neúspěšného přidání článku na službu Wiki Na obrázku 2.2 vidíme sekvenční diagram, kde Petr žádá službu Wiki o přidání článku. Wiki ověří identitu Petra a požadavek zamítne. Petr není na Wiki evidován jako administrátor a přidávat články je povoleno pouze administrátorům. Admini Admini Petr Wiki Petr Perun Kuba Kuba Aktualizuj si seznam adminů Přidej Petra do wiki Přidáno Aktualizováno Obrázek 2.3: Sekvenční diagram přidání administrátora na službu Wiki pomocí systému Perun Na obrázku 2.3 vidíme sekvenční diagram, kde chce Kuba přidat Petra jako administrátora na službu Wiki. Požádá Peruna o přidání Petra do skupiny wiki. Perun ověří Kubovu identitu (autentizace uživatele) a zkontroluje jestli na to má Kuba právo tj. jestli je administrátorem skupiny wiki (autorizace uživatele). Pak Petra přidá do skupiny. Protože je skupina napojena na službu a došlo ke změně 4

15 2. Systém Perun ve skupině, Perun předá službě Wiki seznam identit, které mají být jejími administrátory. Služba Wiki si seznam uloží. Petr Wiki Admini Petr Perun Admini Kuba Kuba Přidej článek Přidáno Obrázek 2.4: Sekvenční diagram úspěšného přidání článku na službu Wiki Obrázek 2.4 Je velmi podobný obrázku 2.2 s tím rozdílem, že tentokrát služba wiki Petra zná a má ho uloženého jako administrátora a proto článek přidá. 5

16 3 Původní architektura autentizace a autorizace Systém Perun je již několik let v provozu a je potřeba navrhnout novou architekturu, která by byla kompatibilní s původní architekturou. Proto je důležité ji pochopit. Nejdříve popisuji jak uživatatel se systémem Perun komunikuje. Poté vysvětluji autentizaci a autorizaci uživatele. V závěru kapitoly se zaměřuji na nedostatky této architektury ve vztahu k problému delegace uživatelských práv vysvětleného v úvodu práce. V této kapitole a dále v práci používám terminilogoii a znalosti protokolu HTTP [2] a předpokládám jeho elementární znalost. V předchozí kapitole bylo pro zjednodušení uvažováno, že uživatel komunikuje s Perunem přímo. On samozřejmě požadavek na Peruna neposílá sám, ale pomocí nějaké aplikace (např. grafické rozhraní Peruna). Na obrázku 3.1 je komunikační diagram, který vztah ilustruje. Tento diagram dále v kapitole rozšiřuji. Uživatel Aplikace Perun Obrázek 3.1: Abstraktní diagram komunikace uživatele s Perunem 3.1 Webové aplikace Aplikace můžeme rozdělit na webové, desktopové, mobilní, na příkazovém řádku,... V práci se věnuji pouze webovým aplikacím, protože se dá předpokládat, že organizace chtějí implementovat právě webové aplikace. Obecně existují dva přístupy, jak může být webová aplikace koncipována, klasický serverový a ajax [3]. V této sekci se věnuji jejich rozílům. Je důležité je pochopit, protože protokol OAuth 2.0 se k nim chová odlišně. 6

17 3.1.1 Serverové aplikace 3. Původní architektura autentizace a autorizace Fungování serverové aplikace vysvětluji pomocí obrázku 3.2, na kterém je diagram komunikace uživatele s Perunem. Když se uživatel dostane na web aplikace (např. z vyhledávače Google), prohlížeč pošle HTTP požadavek na hostující server (1). Host požadavek zpracuje (např. PHP skriptem) a jako odpověď odešle HTML stránku (2), kterou prohlížeč zobrazí. Host Aplikace 4 5 Perun HTML 6 HTML Uživatel Prohlížeč Obrázek 3.2: Komunikace uživatele s Perunem přes serverovou aplikaci Pokud uživatel se stránkou interaguje (např. klikne na tlačítko v navigaci), prohlížeč znovu odešle požadavek na server (1) s rozdílnou URL specifikující stránku, kterou chce uživatel navštívit. Server požadavek zpracuje, provede případnou akci a vygeneruje novou HTML stránku s požadovaným obsahem. Stránku odešle jako odpověď (2), kterou prohlížeč zobrazí. Pokud chce uživatel komunikovat s Perunem (např. klikne na tlačítko Přidat Petra do wiki ), prohlížeč pošle požadavek na hostující server (3). Serverová aplikace požadavek zpracuje a zjistí, že potřebuje kontaktovat Peruna. Proto na něj pošle požadavek (4). Ten provede požadovanou akci a vrátí odpověď (5). Aplikace pak vygenereuje novou stránku (např. s informací, že Petr byl do skupiny úspěšně přidán) a odešle ji jako odpověď prohlížeči, který ji zobrazí (6). 7

18 3.1.2 Ajax aplikace 3. Původní architektura autentizace a autorizace Fungování ajax aplikace vysvětluji pomocí obrázku 3.3, na kterém je diagram komunikace uživatele s Perunem. Když se uživatel dostane na web aplikace (např. z vyhledávače Google), prohlížeč pošle HTTP požadavek na hostující server (1). Ten mu jako odpověď vrátí webovou stránku spolu se skriptem, který stránku ovládá (2). Host Perun HTML+JS JSON Uživatel Prohlížeč Aplikace 5 6 Obrázek 3.3: Komunikace uživatele s Perunem přes ajax aplikaci Pokud uživatel interaguje se stránkou (např. klikne na tlačítko v navigaci), prohlížeč spustí přidružený skript, který požádá prohlížeč, aby poslal požadavek na hostující server (3). Ten požadavek zpracuje a odešle zpět žádaná data (např. ve formátu JSON [4]). Skript je zpracuje a překreslí stránku (4). Pokud chce uživatel komunikovat s Perunem (např. klikne na tlačítko Přidat Petra do wiki ), prohlížeč spustí přidružený skript. Ten ho požádá o poslání požadavku na server Peruna. Prohlížeč ale odeslání z bezpečnostních důvodů zamítne kvůli tzv. same-origin policy [5][6]. Prohlížeče nedovolují skriptu poslat požadavek na jiný server než, ze kterého byl skript stažen. Pokud by to bylo dovoleno, jakákoliv ajax aplikace by mohla odeslat požadavek na známý server (např. server Peruna) a předpokládat, že je uživatel k serveru autentizovaný a prohlížeč má uloženy jeho přístupové údaje. Prohlížeč by údaje serveru poskytl a aplikace by tak mohla tajně komunikovat se serverem identitou uživatele. Požadavek ajax aplikace na Peruna (5) prohlížeč zablokuje. 8

19 3.2 Autentizace uživatele 3. Původní architektura autentizace a autorizace Systém Perun je rozdělen na několik komponent. Komponenta zodpovědná za přijímání HTTP požadavků se nazývá Perun RPC a komponenta vykonávající požadovanou funkcionalitu se nazývá Perun API 1. Architektura je zobrazena na obrázku 3.4. Každý požadavek na Peruna prochází přes webový server, který vynutí uživatelovu autentizaci a pak požadavek přeposílá spolu s identitou uživatele. Webový server ověřuje identity uživatele jednou z několika autentizačních metod, které podporuje. Kterou metodou se uživatel autentizuje, záleží na požadavku aplikace. Ta v URL požadavku specifikuje, kterou metodu chce použít. Pro představu jednou z metod je typ ověření Basic authentication [7], kdy webový server v HTTP hlavičce očekává jméno a heslo uživatele. Pokud ho dostane, ověří ho u určené autentizační autority. Když chce aplikace využít metodu Basic authentication, pošle požadavek na URL rpc/. Pro práci není podstatné,jak jednotlivé metody fungují, proto je zde nebudu popisovat. Perun Uživatel Aplikace Webový server Identita RPC Principal API Obrázek 3.4: Komunikační diagram zpracování požadavku uživatele na funkcionalitu Peruna v původní architektuře Je důležité pochopit, ať už se k webovému serveru uživatel autentizuje jakoukoliv metodou, server posílá Perunovi uživatelovu ověřenou identitu. Perun již uživatele neautentizuje. Udržuje si seznam identit a uživatelů, jak popisuje diagram vztahů na obrázku 2.1 a jen vyhledá uživatele, kterému identita patří. 1. Aplikační programové rozhraní (Application Programming Interface) 9

20 3.3 Autorizace uživatele 3. Původní architektura autentizace a autorizace Po obdržení identity si Perun RPC sestaví tzv. objekt principal. Ten obsahuje informace o uživateli, který právě se systémem komunikuje. Dále z požadavku zjistí, jakou funkcionalitu uživatel požaduje a zavolá příslušnou metodu v komponentě Perun API. Objekt principal mimo jiné obsahuje uživatelovy role s objekty, které spravuje. Např. každý správce skupin má u své role seznam skupin, které řídí. Každá metoda v Perun API ověřuje, zda principal, který k systému přistupuje, obsahuje roli potřebnou k vykonání metody. Příklad fungování původní architektury Rozšířím příklad, kde administrátor Kuba chce přidat uživatele Petr do skupiny wiki. Komunikaci ilustruje sekvenční diagram na obrázku 3.5. Kuba Správce skupin Web server Perun Admini Kuba Klikne na tlačítko Zobrazí formulář Jméno a heslo Přidej Petra do wiki Zadej jméno a heslo Přidej Petra do wiki + jméno a heslo Ověří jméno a heslo Identita Kuba chce přidat Pepu do wiki Přidáno Přidáno Sestaví objekt principal Ověří role Kuby Přidá pepu do skupiny wiki Přidáno Obrázek 3.5: Sekvenční diagram autentizace a autorizace uživatele v původní architektuře 10

21 3. Původní architektura autentizace a autorizace Kuba přistoupí na ajax aplikaci Správce skupin, která je hostována na serveru Peruna. Klikne na tlačítko Přidat Petra do wiki. Správce skupin pošle požadavek na server Peruna na URL basic/rpc/createmember. Prohlížeč požadavek nezablokuje, protože skript ajax aplikace byl stažen ze stejného serveru. /basic v URL značí, že Kuba chce ověřit svoji identitu pomocí Basic authentication. Proto webový server vyžaduje spolu s požadavkem jméno a heslo. Kubův prohlížeč mu zobrazí formulář, kde přístupové údaje vyplní. Webový server údaje ověří u autentizační autority. Ověřenou identitu pošle na Perun RPC spolu s požadavkem na volání metody z URL (/createmember). Perun RPC podle identity vyhledá uživatele, jeho role a sestaví z nich objekt principal. S ním zavolá metodu createmember v Perun API, která nejdříve zkontroluje zda principal obsahuje roli administrátora skupiny wiki a poté přidá Petra do skupiny. Nakonec Perun RPC odešle odpověď s informací o úspěšném přidání. 3.4 Nedostatky architektury V této sekci popisuji, proč je původní architektura nevhodná pro delegaci uživatelských práv na oba druhy webových aplikací. Serverová aplikace pošle požadavek na Perun RPC. Webový server ale vyžaduje autentizaci uživatele. Proto mu požadavek vrátí s žádostí o přístupové údaje. Je zřejmé, že serverová aplikace by musela znát uživatelovy přístupové údaje v otevřené podobě, aby je mohla připojit k požadavku. To je velmi nežádoucí. Organizace si chtějí svoje aplikace udržovat na svých serverech. Ajax aplikace resp. její skripty by byli staženy z jejich hostujícího serveru. Pokud by taková aplikace poslala požadavek na server Peruna, prohlížeč ho podle pravidla same-origin policy zablokuje. Aby ajax aplikace obešla pravidlo same-origin policy, mohla by poslat požadavek na svůj hostující server, který by ho přeposlal na Peruna. Tím však vzniká stejný bezpečnostní problém jako u serverové aplikace. Pro oba druhy webových aplikací je tedy nevhodné s původní architekturou komunikovat. Uživatelé v původní architektuře nemohou bezpečně delegovat práva na aplikace organizací. 11

22 4 Autentizační a autorizační technologie Cílem práce bylo implementovat protokol OAuth 2.0, nicméně v této kapitole uvádím i jiné relevantní technologie, které by mohly být zvažovány při řešení problému delegace uživatelských práv. U každého z nich v závěru hodnotím jeho použitelnost. Dále popisuji mechanizmus Cross-Origin Resource Sharing 1, kterým obcházím pravidlo same-origin policy prohlížeče zmiňované jako problém v sekci SAML 2.0 V této sekci popisuji koncept protokolu SAML 2 2.0, na kterém vysvětluji, proč neřeší problém delegace uživatelských práv. Pro detailnější popis doporučuji článek [8] nebo specifikaci [9]. S rostoucím počtem služeb na internetu, rostl i počet uživatelových digitálních identit. Pro uživatele bylo nepříjemné, že si musí zapamatovat mnoho přístupových údajů. Poskytovatelům služeb nevyhovovalo, že musí identity udržovat. Navíc nejde jen o přístupové údaje, ale i dodatečné údaje o uživateli (jméno, , organizace,... ). To vedlo k potřebě zavedení centralizované správy uživatelských účtů. SAML 2.0 specifikuje, jakým způsobem poskytovatel služby získá údaje o uživateli od centrální autentizační autority, poskytovatele identit. Na sekvenčním diagramu na obrázku 4.1 je vidět proces komunikace uživatele, poskytovatele služeb a poskytovatele identit. Uživatel chce využít službu nabízenou poskytovatelem služeb. Jeho údaje spravuje poskytovatel identit. Služba potřebuje ke své činnosti znát uživatelovu identitu a jeho dodatečné údaje. Poskytovatel služeb věří, že mu poskytovatel identit dodá korektní informace a poskytovatel identit naopak věří poskytovateli služeb, že s nimi bude zacházet zodpovědně. Navíc navzájem znají URL, na kterých jsou dostupní. Uživatel přistoupí na službu a poskytovatel služby zahájí proces autentizace. Přesměruje prohlížeč na poskytovatele identit. Spolu s 1. Cross-Origin Resource Sharing 2. Security Assertion Markup Language 12

23 4. Autentizační a autorizační technologie Uživatel Prohlížeč Poskytovatel služby Poskytovatel identit Požadavek na službu redirect Identifikátor služby Autentizace uživatele Identita uživatele + dodatečné informace Odpověď služby Obrázek 4.1: Sekvenční diagram komunikace protokolem SAML 2.0 požadavkem na přesměrování přepošle mimo jiné svůj identifikátor. Poskytovatel identit požadavek zpracuje, autentizuje uživatele a dohledá jeho dodatečné údaje, které si udržuje. Nakonec poskytovatel identit přesměruje prohlížeč zpět na poskytovatele služeb. K požadavku na přesměrování připojí uživatelovu ověřenou identitu a dodatečné údaje o něm. Poskytovatel služeb tím získá potřebné informace. Protokol SAML 2.0 se zabývá problémem centralizované autentizace uživatele. Perun by protokolem mohl poskytnout aplikaci údaje o uživateli. Ale SAML 2.0 nespecifikuje způsob, jakým by aplikace požádala o operaci v systému Perun (např. přidání uživatele do skupiny). Řeší tedy odlišný problém. Proto SAML 2.0 nemohl být použit. 4.2 OAuth 2.0 V této sekci nejdříve vysvětluji myšlenku protokolu 2.0 a poté rozebírám, jak protokol funguje. V závěru sekce hodnotím, jak řeší problém delegace uživatelských práv. Pro podrobnější popis doporučuji specifikaci [10] nebo sborník z konference [11]. Zde se budu věnovat jen jeho částem relevantním k mé práci. Ve specifikaci je uvedeno, že OAuth 2.0 je autorizační framework. Nejspíš proto, že dává velkou volnost implementaci. Je však běžnou praxí nazývat jej protokolem. 13

24 4. Autentizační a autorizační technologie Celá specifikace používá pojem zdroj (resource), který se v češtině významově odchyluje od anglické verze, ale z důvodu konzistence ho budu používat. Jako zdroj si představme například příspěvky na zdi Facebooku, osobní kalendář nebo skupiny v systému Perun. Specifikace uvádí čtyři základní role. V práci je dále používám, proto je vhodné je zde definovat. Vlastník zdroje (resource owner) Entita (duševně) vlastnící žádaný zdroj. Má právo k němu například přistoupit, modifikovat nebo jej smazat. Typicky fyzická osoba (uživatel), která skrz klienta chce manipulovat se zdrojem. Server zdrojů (resource server) Server, na kterém je přístupný zdroj. Typicky poskytuje nějakou službu jako např. správu příspěvků na zdi Facebooku, správu osobního kalendáře, nebo správu skupin v Perunovi. Klient (client) Aplikace třetí strany, kterou nespravuje provozovatel serveru zdrojů. Žádá server zdrojů o manipulaci se zdrojem, požadovanou vlastníkem zdroje. Autorizační server (authorization server) Server spravující, vydávající a ověřující přístupové tokeny. Často spravovaný stejným provozovatelem jako server zdrojů Koncept OAuth 2.0 je autorizační protokol. Specifikuje způsob, jak7m vlastník zdroje udělí souhlas s přístupem klienta k jeho zdrojům. Dále definuje jak klient ke zdroji přistoupí bez toho, aby mu vlastník musel poskytnout svoje přístupové údaje. Provozovatel klienta nejdříve musí zaregistrovat klienta na autorizačním serveru. Typicky má provozovatel serveru veřejně vystavený formulář, ve kterém vyplní provozovatel klienta důvod, proč potřebuje přístup ke zdrojům vlastníka a redirection URI, na které bude klient dostupný. Po registraci provozovatel klienta obdrží identifikátor a heslo, které dále používá k autentizaci klienta. Když chce klient přístoupit ke zdrojům vlastníka potřebuje získat tzv. přístupový token (access token). Token je tajný, typicky náhodný 14

25 4. Autentizační a autorizační technologie řetězec znaků. Když se jakýkoliv klient při požadavku prokáže na serveru zdrojů platným tokenem, opravňuje ho to přistoupit ke zdrojům vlastníka. Proces získávání tokenu se liší podle aplikace s jakou autorizační server komunikuje. Způsoby rozebírám dále v sekci Jako výsledek procesu klient obdrží přístupový token. Když klient token má, může přistoupit ke zdrojům vlastníka na serveru. Odešle požadavek spolu s tokenem na server zdrojů, který potřebuje ověřit, zda je token platný. Jeho platnost je časově omezena, nebo může být vlastníkem nebo provozovatelem serveru zdrojů zrušena. Server zdrojů ověřuje typicky token na autorizačním serveru. Pošle na něj požadavek a ten mu v odpovědi vrátí informace o platnosti tokenu, pro jakého klienta byl vydán a identitu vlastníka zdroje. Server zdrojů už neprovádí autentizaci vlastníka, protože jeho identitu obdrží od autorizačního serveru Způsoby získávání přístupového tokenu OAuth 2.0 definuje celkem čtyři způsoby (flow) jak token získat. Věnuji se pouze flow určeným pro serverové aplikace (Authorization code flow) a ajax aplikace (Implicit flow), které jsou pro práci podstatné. Authorization code flow Flow ilustruje obrázek 4.2. Když chce klient získat přístupový token, přesměruje prohlížeč na autorizační server. Spolu s ním mu předá svůj identifikátor, který obdržel při registraci. Autorizační server nejdříve autentizuje vlastníka. Poté mu zobrazí formulář, kde udělí souhlas s přístupem klienta k jeho zdrojům. Server vygeneruje autorizační kód (authorization code). To je tajný náhodný řetězec znaků, který reprezentuje uživatelův souhlas. Poté přesměruje prohlížeč zpět na klienta na redirection URI, kterou zná z registrační fáze. Přitom klientovi kód předá. Autorizační kód neopravňuje klienta k přístupu ke zdrojům vlastníka. Klient musí vyměnit autorizační kód za přístupový token tím, že se autentizuje. Pošle požadavek na autorizační server spolu s kódem, svým identifikátorem a heslem, které získal při registraci. 15

26 4. Autentizační a autorizační technologie Autorizační server ověří přístupové údaje klienta a vygeneruje přístupový token. Ten vrátí jako odpověď klientovi. Vlastník zdroje Prohlížeč Klient AuthZ server redirect Identifikator klienta Autentizace vlastníka Udělení souhlasu vlastníka Autorizační kód redirect Autentizace klienta + autorizační kód Token Obrázek 4.2: Proces získání přístupového tokenu pomocí autorizačního kódu Implicit flow Nevýhodou ajax aplikací oproti serverovým je jejich otevřený kód. Skript je stažen do uživatelova počítače, který k němu má přístup. Proto ajax aplikace nemají možnost bezpečně uchovat přístupové údaje klienta. Proto využívají jiný proces získávání tokenu, který ilustruje obrázek 4.3. Stejně jako při procesu s autorizačním kódem, pokud chce klient získat přístupový token, přesměruje prohlížeč na autorizační server. Spolu s tím mu předá svůj identifikátor, který obdržel při registraci. Autorizační server autentizuje vlastníka zdroje. Poté mu zobrazí formulář, ve kterém uživatel udělí souhlas klientovi s přístupem na server zdrojů. Autorizační server negeneruje autorizační kód, ale přímo přístupový token. Poté přesměruje prohlížeč zpět na klienta na redirection URI, kterou zná z registrační fáze a token mu předá. Všiměme si, že se klient neautentizoval (nepoužil přístupové údaje z registrace). Může se zdát, že by se jakýkoliv falešný klient mohl za takového klienta vydávat a získat od uživatele souhlas a 16

27 4. Autentizační a autorizační technologie Vlastník zdroje Prohlížeč Klient Host AuthZ server redirect Identifikátor klienta Autentizace vlastníka Udělení souhlasu vlastníka Token ve fragmentu Žádost o skript bez fragmentu redirect Spuštění skriptu s tokenem ve fragmentu Skript Obrázek 4.3: Proces získání přístupového tokenu implicitně následně token. Ale autorizační server přesměruje prohlížeč na pravou redirection URI z registrace. Proto se token k falešnému klientovi nedostane. Předpokládá se, že klient poběží v prohlížeči a hostující server, ze kterého je klient stažen, nepotřebuje znát přístupový token. Proto je token předán ve fragmentu 3 URI. Narozdíl od zbytku URI ho prohlížeč neodesílá na server. To je potenciálně bezpečnější, protože token neputuje přes síť Použitelnost protokolu Protokol OAuth 2.0 řeší problém delegace uživatelských práv vysvětlený v úvodů práce. Uživatel (vlastník) se neautentizuje k Perunovi (serveru zdrojů) skrz aplikaci (klienta), ale přímo k autorizačnímu serveru. Aplikace třetí strany tak nepřijde do styku s přístupovými údaji uživatele. Místo nich používá token, který je vygenerován výslovně pro ni. Uživatel deleguje svoje práva na aplikaci odsouhlasením formuláře z autorizačního serveru. Je zároveň informován o 3. Část URI za znakem # 17

28 4. Autentizační a autorizační technologie přístupu aplikace k jeho zdrojům na Perunovi a má možnost přístup zamítnout. Z konceptu dále plyne, že autorizační server může určit, jak dlouho bude přístupový token platný. Tím si po určitém čase znovu vynutí autentizaci uživatele a schválení aplikace. Další výhodou je, že uživatel může požádat autorizační server o zrušení platnosti tokenu. Tím aplikace okamžitě ztratí oprávnění k přístupu ke zdrojům. 4.3 OpenID Connect 1.0 V této sekci vysvětluji koncept protokolu OpenID Connect 1.0 (Dále jen OpenID) a hodnotím jeho použitelnost při řešení problému delegace uživatelských práv vysvětleného v úvodu práce. Pro podrobnější popis doporučuji specifikaci [12]. OpenID je jednoduchá autentizační vrstva nad protokolem OAuth 2.0. Specifikuje jaké zdroje server poskytuje a v jakém formátu. Definuje, že server zdrojů je centrální autorita, která spravuje uživatele a jejich dodatečné údaje. Klienti mohou server požádat o vydání těchto údajů. OpenID je tedy alternativou protokolu SAML 2.0. V jeho terminologii je server zdrojů poskytovatel identit a klient poskytovatel služeb. Protokol OAuth 2.0 se zaměřuje především na autorizaci klienta a nespecifikuje, jaká data a jakým způsobem informace o uživateli předat. Když se OAuth 2.0 začal používat ve smyslu autentizačního protokolu, každý poskytovatel identit si vyvinul rozdílné rozhraní. Pokud s nimi chtěli klienti komunikovat, museli rozdílná rozhraní znát. To bylo špatně udržovatelné. Proto vznikl standard OpenID. Protože OpenID jen doplňuje specifikaci OAuth 2.0, je stejně vhodným řešením problému delegace uživatelských práv. Perun ho v budoucnu plánuje implementovat, ale pro jednoduchost bylo vhodné začít s OAuth Cross-Origin Resource Sharing V této sekci popisuji koncept mechanizmu Cross-Origin Resource Sharing (Dále jen CORS), který řeší bezpečnostní omezení prohlížečů same-origin policy, který zmiňuji v sekci Prohlížeč blokuje 18

29 4. Autentizační a autorizační technologie požadavky skriptů, které míří na jiné domény než je doména, ze které byl skript stažen. Pro podrobnější popis odkazuji na doporučení W3C 4 [13]. Prohlížeč se dohodne se serverem na povolených doménách. Pokud je skript stažen z jedné z těchto domén, prohlížeč neblokuje jeho požadavky na server. Myšlenkou CORS je, že server na sebe přebírá zodpovědnost, že skripty z těchto domén jsou důvěryhodné nebo informuje uživatele o jejich komunikaci (např. OAuth 2.0 schvalovacím formulářem). Ke komunikaci CORS využívá HTTP hlavičky. Prohlížeč ještě před samotným požadavkem pošle tzv. preflight požadavek. Tím se ptá serveru, kterým doménám důvěřuje. Server mu odešle odpověď s hlavičkou Access-Control-Allow-Origin, ve které je seznam domén nebo znak *, který znamená, že důvěřuje všem doménám. Prohlížeče musí mechanizmus CORS podporovat. Protože organizace chtějí hostovat ajax aplikace na svých serverech, je nutné obejít pravidlo same-origin policy v prohlížečích uživatelů. Protože je CORS v prohlížečích široce podporován 5, je vhodným řešením. Příklad fungování mechanizmu CORS Pro lepší pochopení uvedu příklad fungování CORS na ilustračním příkladu, kde administrátor Kuba chce přidat uživatele Petr do skupiny wiki. Komunikaci ilustruje obrázek 4.4. Mějme ajax aplikaci Správce skupin, která pochází ze serveru na doméně host.cz. Systém Perun je dostupný na doméně perun.cz. Uživatel Kuba přistoupí na doménu host.cz, ze které se stáhne Správce skupin do jeho prohlížeče. Kuba klikne na tlačítko Přidat Petra do wiki. Prohlížeč spustí přidružený skript, který požádá prohlížeč o odeslání požadavku na perun.cz. Prohlížeč má poznamenáno, že skript Správce skupin pozchází z domény host.cz. Ta se neshoduje s doménou perun.cz. Proto by měl prohlížeč požadavek zamítnout. Pokud prohlížeč podporuje mechanizmus CORS, ještě před zamítnutím pošle preflight požadavek na server Peruna. Pokud by Perun podporoval 4. World Wide Web Consortium,

30 4. Autentizační a autorizační technologie Kuba Správce skupin Prohlížeč Perun Kline na tlačítko Odešli požadavek Porovná domény Preflight požadavek Allow-...-Origin hlavička Odpověď Porovná doménu s hlavičkou Původní požadavek Odpověď Odpověď Obrázek 4.4: Příklad komunikace mechanizmem CORS CORS, tak odešle zpět odpověď s vyplněnou HTTP hlavičkou Access-Control-Allow-Origin, která bude obsahovat hodnotu *. Tím dává Perun prohlížeči najevo, že si je vědom bezpečnostního rizika a prohlížeč může odeslat původní požadavek na přidání Petra do skupiny. 20

31 5 Návrh nové architektury autentizace a autorizace V této kapitole popisuji, jak jsem navrhnul architekturu autentizace a autorizace založenou na protokolu OAuth 2.0 a využívající mechanizmus CORS. Navazuji na kapitolu 3 o původní architektuře. Popisuji, jak je řešena autentizace a autorizace uživatele a delegace uživatelských práv na aplikaci. Zaměřuji se na to, jak architektura řeší nedostatky původní architektury. V závěru kapitoly rozebírám, jak je nová architektura zakomponována do původní, aby byla kompatibilní. 5.1 Autentizace uživatele V případě protokolu OAuth 2.0 autentizace uživatele neprobíhá na serveru zdrojů, ale na autorizačním serveru. V původní architektuře každý požadavek na Peruna prochází přes webový server, který autentizaci provádí. Protože jsem potřeboval uživatele na autorizačním serveru autentizovat stejně jako v původní architektuře, použil jsem k tomu stejný webový server. Vztah komponent je naznačen na diagramu na obrázku 5.1. Autorizační server tedy obdrží už ověřenou identitu, stejně jako Perun. Autentizace Uživatel Klient Webový server AuthZ server Perun Obrázek 5.1: Diagram autentizace uživatele v navržené architektuře Tato struktura mi ušetřila konfiguraci stejných autentizačních metod pro autorizační server a hlavně je řešení lépe udržovatelné. Nastavení autentizace je pro celou architekturu na jednom místě. Pokud v budoucnu přibude, změní se nebo odstraní nějaká autentizační metoda, stačí provést změnu na jednom místě. 21

32 5. Návrh nové architektury autentizace a autorizace Protokol OAuth 2.0 nabízí nový způsob autentizace uživatele. Proto bylo koncepčně vhodné přidat novou metodu autentizace OAuthem na webový server. Nejdříve jsem měl navrženou architekturu tak, že webový server jen přepošle přístupový token Perunovi a ten si ho ověří u autorizačního serveru, jak popisuji v sekci 4.2. Toto řešení by bylo v pořádku, ale nakonec jsem našel modul Openidc do webového serveru, který dokáže vzít a ověřit token u autorizačního serveru. Ten modulu vrátí identitu uživatele a identifikátor klienta. Modul pak přepošle získané informace na Peruna. Toto řešení mi ušetřilo zásah do kódu Peruna a hlavně zachovává koncept tím, že Perun od webového serveru dostává ověřenou identitu. Proto je řešení návrhově čistší. Modul Openidc popisuji detailněji dále v sekci Autorizace uživatele Protože modul webového serveru posílá ověřenou identitu stejně jako při ostatních autentizačních metodách, nebylo potřeba do autorizačního mechanizmu téměř vůbec zasahovat. Jediná změna je ve formátu dat, který nový modul posílá. Po zpracování nového formátu identity se sestaví objekt principal a v procesu autorizace se pokračuje stejně jako v původní architektuře. 5.3 Delegace uživatelských práv Proces delegace uživatelských práv na aplikace třetích stran přímo vychází z protokolu OAuth 2.0, který popisuji v sekci 4.2. Proto navržený proces jen stručně shrnu. Provozovatel aplikace požádá o registraci provozovatele Peruna. Ten ho zaregistruje na autorizačním serveru a předá mu jeho přístupové údaje. Když chce aplikace přistoupit k funkcionalitě Peruna, předá řízení autorizačnímu serveru, který autentizuje uživatele a informuje ho o tom. Jedním z procesů popsaných v sekci získá přístupový token. Přístupovým tokenem tak uživatel deleguje svoje práva. Ten kdo vlastní token má v Perunovi stejná práva jako uživatel, který vydání tokenu schválil. 22

33 5. Návrh nové architektury autentizace a autorizace 5.4 Požadavek aplikace na Peruna Pro ajax aplikace třetích stran je potřeba mechanizmus CORS. Webový server může být nakonfigurován způsobem, aby při obdržení preflight požadavku na nastavené URL vložil do odpovědi definovanou hlavičku. Pokud přijde preflight požadavek na webový server na URL chráněnou protokolem OAuth 2.0, vloží do odpovědi hlavičku Access-Control-Allow-Origin s hodnotou *. Tím říká prohlížeči, že požadavek může odeslat a on za něj přebírá zodpovědnost. Perun je již několik let v provozu a na Perun RPC je navázáno několik produkčních aplikací (např. grafické rozhraní Peruna). Proto bylo nutné navrhnout novou architekturu, aby byl kompatibilní. Všiměme si, že se všechny změny v návrhu odehrávájí na nové URL. Chování architektury na původních URL zůstalo nezměněno. Proto architektura zůstala kompatibilní a stávající aplikace mohou komunikovat s Perunem beze změny. Komplexní příklad fungování nové architektury Pro lepší pochopení uvedu komplexní příklad, kde administrátor Kuba chce přidat Petra do skupiny wiki. K tomu použije ajax aplikaci Správce skupin. Komunikaci vysvětluji pomocí diagramů na obrázcích 5.2 a 5.3. Příklad slouží jako shrnutí návrhu nové architektury. Kuba přistoupí na hostující server Správce skupin a do prohlížeče se mu stáhne skript ajax aplikace. Kuba klikne na tlačítko Přidat Petra do wiki. Prohlížeč spustí přidružený skript. Ten zjistí, že při prvním volání nemá přístupový token a zahájí proces získávání tokenu pomocí Implicit flow. Přesměruje prohlížeč na autorizační server na URL perun.cz/basic/authz/. Požadavek prochází přes webový server, který vynutí autentizaci uživatele. Kuba zadá do prohlížeče svoje přístupové údaje a prohlížeč je odešle zpět webovému serveru. Ten přepošle požadavek na autorizační server spolu s Kubovou identitou. Autorizační server odešlě formulář, kde se uživatele ptá zda souhlasí s přístupem Správce skupin k Perunovi jeho identitou. Prohlížeč formulář zobrazí a Kuba klikne na tlačítko Souhlasím. Prohlížeč o tom informuje autorizační server. Ten vygeneruje přístupový token, uloží si ho a spáruje ho s uživatelem Kuba a aplikací Správce skupin. 23

34 5. Návrh nové architektury autentizace a autorizace Kuba Prohlížeč Správce skupin Web server AuthZ server Klikne na tlačítko Uživatel kliknul na tlačítklo vyplní jméno a heslo Ověří, že token ještě nemá redirect ID klienta Autentizace uživatele Formulář se souhlasem ID klienta + Kubova identita Zobrazí formulář Kline na tlačítko Uživatel udělil souhlas Token ve fragmentu Vygeneruje a uloží token redirect Uloží si token Obrázek 5.2: Sekvenční diagram komunikace ajax aplikace s Perunem v navržené architektuře 1 (získání přístupového tokenu) Autorizační server pak přesměruje prohlížeč spolu s tokenem ve fragmentu zpět na hostující server. Odtud se stáhne ajax aplikace Správce skupin, která má ve fragmentu přístupový token. Ten si uloží pro další použití. Když chce ajax aplikace přistoupit k Perunovi, požádá prohlížeč o odeslání požadavku spolu s tokenem na URL oauth/rpc/createmember. Prohlížeč zjistí, že skript, který byl stažen z hostujícího serveru, chce poslat požadavek na server Peruna. Protože podporuje CORS odešle preflight požadavek na oauth/rpc/createmember. Webový server do odpovědi přidá hlavičku Access-Control-Allow-Origin s hodnotou *. Tím prohlížeči říká, že si je vědom bezpečnostního rizika a požadavek mu může poslat. Prohlížeč odešle původní požadavek s tokenem na Peruna. Webový server ho ověří na autorizačním serveru. Ten mu vrátí Kubovu identitu, kterou přepošle spolu s požadavkem na přidání na Perun RPC. Perun z identity sestaví objekt principal a zavolá metodu v Perun API. Metoda ověří zda Kubův principal obsahuje roli 24

35 5. Návrh nové architektury autentizace a autorizace správce skupiny wiki. Pak provede samotné přidání Petra do skupiny a v odpovědi vrátí potvrzení o přidání. Správce skupin potvrzení zpracuje a zobrazí Kubovi hlášku o úspěchu. Správce skupin Prohlížeč Web server AuthZ server Perun Přidej Petra do wiki + token Ověří původ Správce sk. Preflight požadavek Allow-...-Origin hlavička Ověří hlavičku Přidej Petra do wiki + token Ověř token Token je validní a patří Kubovi Přidej Petra do wiki + identita Kuby Zkontroluje role Kuby Přidáno Přidáno Přidáno Přidá Petra do wiki Obrázek 5.3: Sekvenční diagram komunikace ajax aplikace s Perunem v navržené architektuře 2 (odeslání požadavku na Peruna) 25

36 6 Implementace nové architektury autentizace a autorizace V této kapitole popisuji jak jsem implementoval navrženou architekturu založenou na protokolu OAuth 2.0, využívající mechanizmus CORS. Nejdříve se věnuji výběru vhodného autorizačního serveru a jeho konfiguraci. Dále popisuji modul webového serveru na ověření přístupového tokenu a poté jeho konfiguraci. 6.1 Výběr autorizačního serveru Důležitou komponentou nové architektury je autorizační server, proto jsem jeho výběru věnoval velkou pozornost. Nechtěl jsem programovat vlastní server, protože existuje několik hotových vyzkoušených řešení. První podmínkou při výběru byla implementace v jazyce Java kvůli údržbě, protože Perun je v něm také napsán. Bylo nutné vybrat takový autorizační server, který mi dovolí přeprogramovat komponentu pro autentizaci uživatele, aby dokázala přijímat ověřenou identitu od webového serveru. Dalšími kritérii byla kvalita dokumentace a jednoduchost použití. Při výběru jsem vycházel ze seznamu na oficiálních stránkách komunity OAuth Spring security OAuth Spring security OAuth 2 je jedna z nejrošířenějších implementací protokolu OAuth 2.0. Nicméně je to knihovna, nikoliv hotový autorizační server. To byl hlavní důvod proč jsem se rozhodl Spring security OAuth nepoužít. Jeho klady jsou robustnost a kvalita dokumentace se spoustou návodů a silnou podporou komunity. Jde o komplexní knihovnu, která řeší persistování veškerých potřebných dat. Proto by implementace serveru nebyla příliš náročná. Na druhou stranu je těžké s knihovnou začít pracovat, obzvlášť pokud vývojář nezná Spring security 3, na jehož základě je knihovna postavena

37 6. Implementace nové architektury autentizace a autorizace Apache Oltu Apache Oltu 4 je také pouze knihovna, nikoliv hotový autorizační server. To byl hlavní důvod proč jsem ho nepoužil. Je jednodušší než Spring security OAuth. Znamenalo by to pro mě více práce při implementaci serveru. Zvláště napsat si vlastní mechanizmus persistování dat. Na druhou stranu bylo rychlé s ní začít pracovat, protože je jednoduchá a přímočaře následuje specifikaci. Má krátkou ale dostačující dokumentaci OpenConext authorization server OpenConext authorization server 5 je hotový server. Je postaven na knihovně Spring security OAuth. Má velice špatnou a krátkou dokumentaci. Je navržen pro konkrétní použití (OpenConext 6 platfomu), proto do něj nelze jednoduše doprogramovat vlastní modul pro autentizaci uživatele. To byl hlavní důvod proč jsem ho nepoužil MITREid Connect MITREid Connect 7 je hotový autorizační server. Jde o certifikovanou implementaci OpenID Connect. Proto má veškěrou funkcionalitu, kterou potřebuji. Má dobrou dokumentaci a je nachýstán pro obecné použití. Rozhodně je dobře použitelný APIs Secure APIs Secure 8 je hotový autorizační server. Je to jednoduchá a přímočará implementace OAuth 2.0. Pro práci je dostačující. Je nachystán na dopsání vlastní autentizace uživatele. Je krátce, ale dostatečně zdokumentován. Vybral jsem si ho právě pro jeho jednoduchost. Později jsem zjistil, že jeho vývoj a podpora byla ukončena, proto bych teď doporučil použití MITREid Connect

38 6. Implementace nové architektury autentizace a autorizace 6.2 Konfigurace autorizačního serveru APIs Secure se konfiguruje pomocí textového souboru, který obsahuje řádky s klíčem a hodnotou konfigurované vlastnosti. Následuje ilustrační ukázka konfiguračního souboru. 1 jdbc. driverclassname = com. mysql. jdbc. Driver 2 jdbc. url = jdbc : mysql :// localhost :3306/ apis 3 jdbc. username = root 4 jdbc. password = 5 6 authenticatorclass = cz. metacentrum. perun. oauth. PerunAuthenticator 7 userconsenthandlerclass =cz. metacentrum. perun. oauth. PerunConsentHandler Oproti původní konfiguraci jsem měnil nastavení databáze. Stačilo nastavit třídu JDBC 9 ovladače, cestu a přístupové údaje k databázi (1 4). APIs Secure se o vytvoření schématu postaral sám. Dále jsem nastavil jména tříd, které jsou zodpovědné za autentizaci uživatele (6) a zobrazení formuláře se souhlasem k přístupu (7). Autentizační třída Kvůli specifickým požadavkům na autentizaci uživatele bylo nutné doprogramovat autentizační třídu autorizačního serveru, aby přijímala ověřenou identitu od webového serveru. Třída obsahuje metodu, která je zavolána při autentizaci uživatele a má za úkol získat a předat informace o uživateli. V našem případě metoda autentizaci provádět nemusí, protože identitu vždy dostane od webového serveru. Proto stačilo zpracovat identitu stejně jako v Perun RPC. Protože je kód serveru APIs i Peruna v jazyce Java, stačilo jen zkopírovat kód, který sestavuje objekt principal a lehce ho upravit, aby sestavil podobný objekt, který APIs očekává. 9. Java DataBase Connectivity, javase/jdbc/index.html 28

39 6. Implementace nové architektury autentizace a autorizace Třída souhlasu uživatele Kromě autentizační třídy APIs dovoluje doprogramovat i třídu, která se dotazuje uživatele na souhlas s přístupem aplikace k Perunovi. Toho jsem využil a změnil vzhled formuláře tak aby byl responzivní 10 a zjednodušil ho. Formulář je vidět na obrázku 6.1. Nastavuje se v konfiguračním souboru stejně jako autentizační komponenta. Obrázek 6.1: Formulář s žádostí o udělení souhlasu s přístupem k Perunovi Nevýhodou implementace tříd bylo, že jsem musel přepsat část kódu. Pokud by vyšla nová verze APIs Secure serveru, musely by se třídy znovu přepsat. Nicméně podpora APIs byla ukončena a žádné nové verze nejsou vydávány. 6.3 Ověření přístupového tokenu Perunem Serverem zdrojů je v našem případě Perun, který podle návrhu architektury ověřuje přístupové tokeny u autorizačního serveru. První možnost implemetace byla doprogramovat do Peruna mechanizmus, 10. Přizpůsobivý velikostem obrazovky 29