Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. v EEG/ERP portálu

Transkript

1 Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky Diplomová práce Systém oprávnění v EEG/ERP portálu Plzeň, 2011 Jiří Vlašimský

2 Prohlášení Prohlašuji, že jsem diplomovou práci vypracoval samostatně a výhradně s použitím citovaných pramenů. V Plzni dne 18. května 2011 Jiří Vlašimský

3 Abstract This diploma thesis deals with security and legal analysis of the EEG/ERP Portal web application which is used to store neuroinformatic data. It also provides multiple additional features like content-management system of EEG experiments, articles, measuring scenarios, system of user roles etc. As a part of this thesis is the analysis of neuroinformatic data storage legal aspects and subsequent access control to them. The next part of this work is focused to technical and security analysis of authentication and authorisation used in the current application which leads to better uderstanding of those aspects and identification of security weaknesses. The last part of this thesis describes implementation of new mechanisms and repairment of current ones. Better security for all data and more secure access to the whole application of EEG/ERP Portal is ensured.

4 Obsah 1 Úvod 1 2 Autentizace a autorizace v internetových aplikacích Formulářová autentizace Externí autentizační poskytovatel OAuth OpenID Právní aspekty uchovávání neuroinformatických dat Uchovávání osobních údajů Souhlas s uchováním osobních údajů Technologie použité při řešení autentizace a autorizace v EE- G/ERP portálu Spring Framework Dependency Injection (Inversion of Control) Spring Security Hibernate Message-Digest Algorithm - MD Bezpečnost internetových aplikací Rizika v roce 2010 podle OWASP Mechanismy použité při řešení autentizace a autorizace v EE- G/ERP portálu Úrovně uživatelských oprávnění Autorizace nového uživatele Testování zabezpečení portálu Druhy útoků a jejich testování na aplikaci Injection (HQL Injection) Cross-Site Scripting (XSS)

5 7.1.3 Broken Authentication and Session Management Insecure Direct Object References Cross Site Request Forgery Security Misconfiguration Insecure Cryptographic Storage Failure to Restrict URL Access Insufficient Transport Layer Protection Unvalidated Redirects and Forwards Úpravy autentizačních a autorizačních mechanismů Externí autentizační poskytovatel Facebook Connect Aplikace na Facebook.com Úprava databáze Ověřovací mechanismus s využitím OAuth Použité knihovny Propojení se Spring Security Opravy bezpečnostních chyb Další možná vylepšení bezpečnosti SSL Úprava uložení hesla Inovace technologií stávajícího řešení Ochrana proti CSRF Závěr 51 A Podmínky účasti v projektu s názvem Měření mozkové aktivity 56 A.1 Popis projektu A.2 Průběh měření A.3 Podmínky účasti v projektu A.4 Prohlášení A.5 Souhlas se zpracováním osobních údajů B EEG Metadata 59 B.1 Informace o měřené osobě B.2 Informace o měřící osobě B.3 Podmínky měření B.4 Informace o scénáři C Konfigurace aplikace 61

6 1 Úvod EEG/ERP portál je webová aplikace sloužící ke správě neuroinformatických dat získaných měřením mozkové aktivity. Tato aplikace také poskytuje některé další funkcionality jako např. redakční systém, administraci EEG experimentů, scénářů měření, uživatelů atd., ke kterým je potřeba zajistit přístup s dostatečnou úrovní zabezpečení. Cílem této práce byla analýza právních aspektů ukládání neuroinformatických dat v EEG/ERP portálu s ohledem na legislativu České republiky. Při zpracování dat jsou ukládána také osobní data, která jsou zákonem klasifikována jako citlivá, proto je nutné, aby dokumenty, které měřená osoba podepisuje odpovídaly těmto zákonům a obsahovaly předepsané náležitosti. V práci je tomuto problému věnována kapitola 3. Dále je v dokumentu zmíněno, jaké jsou současné trendy při řešení autentizace a autorizace u webových aplikací. Zejména se pak jedná o využití moderních autentizačních mechanismů jako jsou OAuth a OpenID, které využívá mnoho velkých internetových portálů. V dokumentu je popsáno jaké výhody tato řešení přináší a zda jsou vhodné pro využití v aplikaci. Bezpečnost EEG/ERP portálu je kvůli charakteru uchovávaných dat velmi důležitá. V práci je popsáno současné řešení autentizačních a autorizačních mechanismů, jejichž analýza a testování byly provedeny podle žebříčku deseti nejrozšířenějších bezpečnostních rizik roku 2010, sestavenému organizací OWASP Foundation. Jelikož vývoj aplikace byl započat před několika lety, kdy nebylo na internetu běžné využití externích autentizačních poskytovatelů, je v dokumentu popsáno jakým způsobem byly tyto mechanismy implementovány, jak bylo rozšířeno stávající řešení a opraveny nalezené nedostatky. Po přečtení práce získá čtenář představu nejen o tom, jaké jsou právní aspekty uchovávání neuroinformatických dat, ale i jakým způsobem byly analyzovány a rozšířeny současné autentizační a autorizační mechanismy společně s jejich důsledným otestováním. 1

7 2 Autentizace a autorizace v internetových aplikacích Autentizace je proces ověření identity uživatele nebo jiného subjektu. Proběhneli úspěšně proces autentizace, dochází k autorizaci, tedy ke schválení a umožnění přístupu k chráněným zdrojům. Obvykle je autentizace uživatele provedena některou z následujících metod: Podle znalostí uživatele - zpravidla jméno a heslo nebo PIN. Podle prostředků uživatele - obvykle technický prostředek, který uživatel vlastní - certifikát, hardwarový klíč. Podle biometrických vlastností - např. otisk prstu, sítnice, hlasový vzor. Podle schopností uživatele - odpověd na nějakou otázku, kterou znají pouze uživatelé, kteří by k danému zdroji měli mít přístup. Tento způsob se využívá např. při přístupu k sekcím webových stránek patřících pouze některé skupině, která by odpověd na otázku měla znát (viz zabezpečovací mechanismus třídních stránek na spoluzaci.cz). K autentizaci dochází u webových aplikací po splnění jedné z následujících metod. V případě úspěšného přihlášení je obvykle vygenerován k uživatelským sessions 1 unikátní klíč, který je uchováván v cookies 2 prohlížeče nebo předáván pomocí parametrů při komunikaci. Na programátorovi je rozhodnutí, jaký způsob autentizace využije. V poslední době se ve webových aplikacích využívají tyto mechanismy: 1. Formulářová autentizace - vlastní autentizační mechanismus 1 Sessions v HTTP dává serveru možnost uložit si omezené množství informací o uživateli, který k němu přistupuje. Obvykle se tento mechanismus používá k udržení kontextu o uživatelích jako může být např. udržení přihlášení uživatele. 2 Cookies umožňují serveru uložit malé množství dat do prohlížeče klienta. Při každé návštěvě téhož serveru pak prohlížeč posílá zpět data serveru až do doby expirace dané cookie. 2

8 Formulářová autentizace 2. Autentizace pomocí externího poskytovatele 3. Kombinace dvou výše uvedených řešení 2.1 Formulářová autentizace Formulářová autentizace je velmi používaný způsob autentizace. V případě potřeby ověření přístupu k chráněným zdrojům je uživatel požádán o přístupové informace, které zadá pomocí HTML formuláře. Aplikace tyto údaje ověří a na základě jejich korektnosti přidělí uživateli unikátní identifikátor, zpravidla uložený v session. Poté již není potřeba v aplikaci dále kontrolovat jméno a heslo, ale pouze kód uložený v session, který je platný po celou dobu práce v aplikaci nebo po serverem nastaveném časovém intervalu nečinnosti. Po vypršení platnosti session automaticky dochází k odhlášení uživatele. Výhody formulářové autentizace jsou zřejmé: Správa uživatelských účtů může být přizpůsobena přesně podle potřeb konkrétní služby, která má nad svými uživateli kontrolu. Pro přihlášení se doporučuje [7] pole pro zadávání hesla zvolit typu password, jelikož prohlížeče text uložený v tomto poli maskují, a tak jej případný útočník nemůže přečíst pouhým pohledem. Formulář by měl být vždy odeslán pomocí HTTP metody POST. V případě použití GET se všechna data vyplněná do formuláře odesílají jako parametr na adresní řádce prohlížeče. Tím pádem tento řádek zůstává také v historii prohlížeče nebo v logovacích souborech serveru. Nevýhodou formulářové autentizace je požadavek na uživatele, který si musí pamatovat přístupové údaje k několika službám, které využívá. S postupem času těchto služeb stále přibývá a tím také přihlašovacích údajů. 2.2 Externí autentizační poskytovatel Jednou z nevýhod formulářové autentizace je nepřenositelnost identity a její nejednoznačnost. Jedna identita je unikátní pouze v rámci jedné služby nebo 3

9 Externí autentizační poskytovatel skupiny služeb. V současné době se velmi rozšiřují distribuované webové služby (web services) a cloud computing 3. Uživatelé mají v těchto službách uložená svá data a pravidelně je používají. Služby jsou obvykle chráněny standardním mechanismem, tedy jménem a heslem. Existují však takové, které ověřují uživatele např. pomocí čipových karet, certifikátů apod. Poskytovatelů služeb je velké množství a mnozí z nich požadují od uživatele tolik informací při registraci a uživatelé je natolik využívají, že uživatel v nich registrovaný se dá prohlásit za dostatečně autorizovaného. Zároveň s tímto faktem je tedy velmi často spojeno propojování aplikací třetích stran s těmito službami. Těmto aplikacím je pak poskytnuta např. možnost přenést ověření nových i stávajících uživatelů s využitím faktu, že uživatel má již registrovaný účet na některé ze služeb na internetu. Správa identit pomocí autentizačního poskytovatele přináší tedy několik výhod Uživatel nepotřebuje nové přihlašovací údaje ke každé službě. Stačí mu znát pouze heslo k účtu u správce identity. Tato identita slouží jako přihlašovací klíč k různým službám. Identita, pokud je správně vyplněna, jednoznačně identifikuje konkrétního člověka. Programátor aplikace se nemusí starat o autentizaci a problémy s ní spojené (zabezpečený přenos citlivých údajů, obnova hesel apod.) Toto řešení sebou také přináší několik nevýhod. Pro uživatele je to zejména problém v případě kompromitace jeho identity uložené u autentizační autority (např. prozrazení přihlašovacích údajů). Poté je tato identita kompromitována na všech službách, které ji využívají. Správci aplikace, která na tato data spoléhá, ztrácí část kontroly nad informacemi o uživatelích a v důsledku se mohou dostat do stavu, kdy o uživateli znají pouze jeho číselný identifikátor. Mezi velké autentizační autority patří zejména: 3 Cloud computing je model vývoje založený na využívání zdrojů uložených v Internetu. Uživatel pak k těmto zdrojům může přistupovat např. pomocí webového prohlížeče, programátor pak pomocí webových služeb nebo API. 4

10 Externí autentizační poskytovatel Google.com Facebook.com Twitter.com LinkedIn.com Live.microsoft.com Vimeo.com Tyto služby disponují rozsáhlou databází uživatelů a obvykle neposkytují pouze autentizační mechanismy, ale také možnost získat další informace o uživateli, pomocí kterých je poté možné jej zaregistrovat do vlastní aplikace s potřebnými údaji. Většina těchto služeb poskytuje autentizační mechanismus pomocí OpenID, LiveID nebo OAuth, zejména ve verzi 2.0, která rozšiřuje OAuth 1.0 o další funkčnosti OAuth Dříve bylo v aplikaci běžné, že pro načítání dat z jiné služby, kterou uživatel využívá, bylo nutné znát jméno a heslo k jeho účtu. Aplikace se pak připojila přes API požadované služby a poté docházelo k výměně dat mezi aplikacemi. Tento způsob sebou nesl značnou míru nedůvěry z formulářů na internetových stránkách a uživatelé se bránili zadávání svých přístupových dat do jiných internetových aplikací, než do té, ke které tyto údaje primárně patří. Přihlašovací údaje k některým službám jsou pro uživatele mnohdy citlivější, než je tomu u jiných služeb. Jistě si zákazník více chrání přístup např. ke svému účtu u Google, který je spojen s většinou služeb, jež Google poskytuje, než třeba účet na Twitter.com, jenž je ve zjednodušeném pojetí pouze přístupem k příspěvkům, které jsou i tak veřejné. Tento problém řeší autentizační mechanismus OAuth, který nepožaduje po uživateli jeho jméno ani heslo. V aplikaci je nyní pouze tlačítko Přihlásit pomocí služby XYZ, na které když klikne, je přesměrován na stránky služby, kde se přihlásí se svým jménem a heslem. Poté potvrdí, zda aplikace, ze které přišel, může přistupovat k určitým datům, které si vyžádala (pomocí parametrů v odkazu pro přihlášení). Nyní se vygeneruje unikátní identifikační 5

11 Externí autentizační poskytovatel klíč pro danou aplikaci s určitými vlastnostmi (viz Token). Riziko zneužití je tedy minimalizováno a citlivé přihlašovací údaje jsou zadávány pouze cílové službě. Na pozadí probíhají operace, při kterých se vyměňují data pomocí protokolu HTTP. Tyto operace se liší v závislosti na použité verzi OAuth a nejsou vázány na konkrétní API ani platformu aplikace. Lze tedy OAuth využít jak v desktopové, tak ve webové aplikaci. OAuth je momentálně ve dvou verzích (1.0 a 2.0). U obou je nutné pro jeho používání splnit několik požadavků: 1. Registrace aplikace - Nejprve je nutné na straně poskytovatele ověření zaregistrovat aplikaci, ze které bude vznikat požadavek na ověření. 2. Nastavení vlastností aplikace - Poskytovatel ověření přidělí aplikaci identifikátor a tajný klíč (řetězec). Ty je nutné si uložit, jelikož budou použity dále při komunikaci nejen při autentizaci uživatele. 3. Nastavení Callback URL - Adresa pro přesměrování zpět do aplikace po úspěšné autentizaci na straně poskytovatele. Komunikace probíhá tak, že aplikace si nejprve vyžádá jednorázový token (code), poté přesměruje pomocí HTTP uživatele na stránky poskytovatele autentizace, společně s tímto tokenem a požadavkem na požadovaný rozsah informací, které aplikace požaduje. Poskytovatel ověří uživatele a poté je dotázán, zda souhlasí s poskytnutím požadovaných zdrojů aplikaci, ze které přišel. V případě souhlasu je vygenerován nový token, který slouží jako přístupový klíč, kterým pak aplikace přistupuje k API poskytovatele. Celý postup je graficky znázorněn na obr Token Token reprezentuje povolení k přístupu aplikace k datům uloženým ve vzdáleném uložišti. Jedná se o řetězec, který má v sobě zakódované některé další informace jako jsou rozsah přístupu aplikace k datům a čas vypršení přístupu k nim pomocí tohoto povolení. 6

12 Externí autentizační poskytovatel Uživatel Aplikace Poskytovatel služby Žádost o vstup do aplikace Žádost o ověření uživatele Žádost uživatele o poskytnutí potřebných oprávnění Rozhodnutí uživatele Přístupový token Žádost o uživatelská data Objekt s daty Přihlášení uživatele Obrázek 2.1: Autentizace a přihlášení uživatele pomocí OAuth 2.0 JSON objekty JavaScript Object Notation neboli JSON je formát pro výměnu strukturovaných dat, který lze snadno číst i zapisovat. Jedná se textový formát, nezávislý na programovacím jazyku, který využívá podobné konvence programovacích jazyků rodiny C (C, C++, C#, Java, JavaScript a další). Příklad jednoduchého JSON objektu nesoucího základní informace o uživateli: { } "name": "John Doe", "address": { "streetaddress": "Vaclavske namesti", "city": "Prague", }, "phonenumber": [{ "type": "home", "number": " " }, { "type": "fax", "number": " " }] 7

13 Externí autentizační poskytovatel Tento formát v současné době podporuje většina programovacích jazyků a je tedy velmi vhodný pro výměnu dat mezi aplikacemi. Způsob přenosu informací přes JSON objekty využívají služby jako např. Facebook nebo Twitter v případě, že autorizovaná aplikace požaduje informace z jejich komunikačních rozhraní. Jeho výhodou oproti XML je zejména vyšší míra zjednodušení zápisu oproštěním od parametrů přímo v objektech XML souborů OpenID OpenID je otevřený standard, který popisuje způsoby autentizace uživatelů. Decentralizovaný je proto, že není závislý na žádném centrálním poskytovateli autentizace. Jeho výhodou je opět skutečnost, že autentizace je celkově v roli poskytovatele a není nijak předepsaná. Je tedy možné uživatele ověřovat standardně pomocí jména, hesla a k tomu přidat např. ověření čipové karty nebo biometrických vlastností uživatele. To znamená, že si uživatel může zvolit takovou autentizační autoritu, která mu bude vyhovovat jak z hlediska autority, kterou bude používat, tak z pohledu úrovně zabezpečení, kde se může snáze předejít odcizení elektronické identity nebo kompromitaci dat. OpenID zavádí několik termínů, které je potřeba znát pro pochopení jeho principu. Tyto identifikátory jsou detailně popsány ve specifikaci OpenID [4]. Identifikátor (Identifier) - Jednoznačná URI včetně protokolu (http, https) nebo XRI 4. V případě, že je poskytovatel Google, je toto URI např. Poskytovatel (OpenID Provider - OP) - Server poskytující potvrzení o tom, že konkrétnímu uživateli patří konkrétní identifikátor (server provádějící autentizaci). OP Identifikátor (OpenID Provider Identificator) - Identifikátor poskytovatele. OP Endpoint (OpenID Provider Endpoint URL) - Koncový bod OP ve formě URL s http nebo https, na kterém poskytovatel přijímá požadavky klientů. 4 Extensible Resource Identifier - schéma a protokol pro abstraktní identifikátory kompatibilní s URI. Používá se zejména u strukturovaných webů. (např. xri://broadview.library.example.com/(urn:isbn: )/(+reference) 8

14 Externí autentizační poskytovatel Klient (Relying Party - RP) - Klient spoléhá na ověření identity od OP. Zpravidla se jedná o web, který implementuje možnost přístupu k vlastním službám přes OpenID. Uživatelský klient (User-Agent) - Jedná se o webového klienta, který implementuje protokol HTTP/1.1. V našem případě se bude jednat pouze o webový prohlížeč. Uživatelem poskytnutý identifikátor (User-Supplied Identifier - USID) - Identifikátor, který si uživatel vybral na straně poskytovatele. Uživatel si může vybrat, zda bude zadávat svůj identifikátor nebo OP identifikátor - v tomto případě si uživatel později vybere, pod kterým identifikátorem chce být přihlášen (toto nabídne poskytovatel). Přidělený identifikátor (Claimed Identifier) - Jedná se o normalizovaný identifikátor, který je určen z URI nebo XRI. Komunikace při použití OpenID V případě, že se uživatel chce přihlásit na stránky nějaké služby pomocí svého OpenID účtu, musí nejprve zadat svůj identifikátor do pole pro OpenID přihlášení. Klient normalizuje dodaný identifikátor a poté získá adresu OP Endpoint procesem zvaným Discovery (více v [3]). Nyní si klient a poskytovatel vymění klíč, kterým bude poskytovatel podepisovat data, a klient tak může ověřit jejich pravost (tento krok je volitelný). Dále klient přesměruje uživatelův prohlížeč na stránky poskytovatele s požadavkem na autentizaci. Poskytovatel ověří, zda je uživatel opravdu majitelem zadaného ID. Mechanismus ověření je zcela v kompetenci poskytovatele a každý poskytovatel si může vyžádat jiná data jako např. kombinaci jména, hesla a nějaké formy biometrického ověření. Nyní je uživatel autentizován a přesměrován zpět na stránky klienta, který ověří data předaná poskytovatelem. Kontroluje se zejména návratové URL, Informace o endpointu, kód požadavku (tzv. nonce kód) a ověřuje se podpis, bud pomocí společného klíče dohodnutého dříve, nebo dalším dotazem na poskytovatele. Celý mechanismus je zobrazen na obr

15 Externí autentizační poskytovatel Uživatel Aplikace Poskytovatel služby Uživatel zadá svůj identifikátor Discovery zjištění adresy OpenID providera Výměna klíčů Přesměrování uživatele Přesměrování na OpenID Providera Žádost uživatele o poskytnutí potřebných oprávnění Rozhodnutí uživatele Informace o autentizaci Přihlášení uživatele Obrázek 2.2: Autentizace uživatele pomocí OpenID 10

16 3 Právní aspekty uchovávání neuroinformatických dat Pro účely aplikace EEG/ERP portálu jsou od měřených osob požadovány jejich osobní údaje, přičemž některé jsou dle zákona č. 101/2000 Sb. klasifikovány jako citlivé. Zákon č. 101/2000 Sb., o ochraně osobních údajů slouží k naplnění práva každého na ochranu před neoprávněným zasahováním do soukromí, upravuje práva a povinnosti při zpracování osobních údajů a stanoví podmínky, za nichž se uskutečňuje předání osobních údajů do jiných států (převzato z [12]). Osobní údaj 4. odst. a a) osobním údajem je jakákoliv informace týkající se určeného nebo určitelného subjektu údajů. Subjekt údajů se považuje za určený nebo určitelný, jestliže lze subjekt údajů přímo či nepřímo identifikovat zejména na základě čísla, kódu nebo jednoho či více prvků, specifických pro jeho fyzickou, fyziologickou, psychickou, ekonomickou, kulturní nebo sociální identitu, Citlivý údaj 4, odst. b) citlivým údajem je osobní údaj vypovídající o národnostním, rasovém nebo etnickém původu, politických postojích, členství v odborových organizacích, náboženství a filozofickém přesvědčení, odsouzení za trestný čin, zdravotním stavu a sexuálním životě subjektu údajů a genetický údaj subjektu údajů; citlivým údajem je také biometrický údaj, který umožňuje přímou identifikaci nebo autentizaci subjektu údajů, Těmito údaji jsou v případě zpracování neuroinformatických dat v aplikaci portálu (viz příloha B - ERP Metadata): Osobní údaje Jméno a příjmení Datum narození Pohlaví Kontakt 11

17 Uchovávání osobních údajů Citlivé údaje Porucha zraku Porucha sluchu Pravák/Levák 3.1 Uchovávání osobních údajů Svolení k uchovávání osobních údajů je dáno 11 zákona č. 101/2000 sb. 1. (1) Správce je při shromažd ování osobních údajů povinen subjekt údajů informovat o tom, v jakém rozsahu a pro jaký účel budou osobní údaje zpracovány, kdo a jakým způsobem bude osobní údaje zpracovávat a komu mohou být osobní údaje zpřístupněny, nejsou-li subjektu údajů tyto informace již známy. Správce musí subjekt údajů informovat o jeho právu přístupu k osobním údajům, právu na opravu osobních údajů, jakož i o dalších právech stanovených v 21. (2) V případě, kdy správce zpracovává osobní údaje získané od subjektu údajů, musí subjekt údajů poučit o tom, zda je poskytnutí osobního údaje povinné či dobrovolné. Je-li subjekt údajů povinen podle zvláštního zákona osobní údaje pro zpracování poskytnout, poučí jej správce o této skutečnosti, jakož i o následcích odmítnutí poskytnutí osobních údajů. (5) Při zpracování osobních údajů podle 5 odst. 2 písm. e) a 9 písm. h) je správce povinen bez zbytečného odkladu subjekt údajů informovat o zpracování jeho osobních údajů. Zpracování citlivých údajů upřesňuje 9 zákona č. 101/2000. a) subjekt údajů dal ke zpracování výslovný souhlas. Subjekt údajů musí být při udělení souhlasu informován o tom, pro jaký účel zpracování a k jakým osobním údajům je souhlas dáván, jakému správci a na jaké období. Existenci souhlasu subjektu údajů se zpracováním osobních údajů musí být 1 Vybrány byly pouze odstavce týkající se EEG/ERP portálu, celé znění zákona je uvedeno v [12] 12

18 Souhlas s uchováním osobních údajů správce schopen prokázat po celou dobu zpracování. Správce je povinen předem subjekt údajů poučit o jeho právech podle 12 a 21, Pozn. zmíněn je pouze odstavec (a), který se týká aplikace. Celé znění viz [12]. 3.2 Souhlas s uchováním osobních údajů Než je provedeno měření je měřená osoba obeznámena s údaji, které budou zpracovány, jak s nimi bude nakládáno a jak probíhá průběh měření (viz příloha A - Podmínky účasti v projektu s názvem Měření mozkové aktivity a příloha B - ERP Metadata). Přesné znění: Podpisem těchto podmínek účasti v projektu uděluji ve smyslu zákona č. 101/2000 Sb., o ochraně osobních údajů a o změně některých zákonů, ve znění pozdějších předpisů Západočeské univerzitě v Plzni a Fakultní nemocnici Plzeň po poučení o svých právech výslovný souhlas se zpracováním osobních a citlivých údajů v rozsahu těchto podmínek účasti v projektu, včetně přílohy, která je nedílnou součástí tohoto poučení, za účelem realizace a následného vyhodnocení projektu. Tento souhlas uděluji na dobu realizace projektu a následně po dobu let po jeho skončení. Jsem si vědom(a) toho, že poskytnutí osobních a citlivých údajů je dobrovolné, a že souhlas se zpracováním osobních nebo citlivých údajů mohu kdykoli odvolat. Ukládání osobních a citlivých dat je tedy v aplikaci v souladu se zákonem č. 101/2000 Sb a dokumenty, které jsou měřenou osobou vyplněny, jsou také v souladu s tímto zákonem. 13

19 4 Technologie použité při řešení autentizace a autorizace v EEG/ERP portálu Celá webová aplikace EEG/ERP portálu je vytvořena v programovacím jazyce JAVA s využitím kombinace technologií: 1. Spring Framework Spring Security Hibernate 4.1 Spring Framework Programátor při vývoji netriviálních aplikací často potřebuje běžně se vyskytující aspekty návrhu, jakými jsou například autentizace, autorizace, ukládání dat do databáze, správa transakcí apod. Dále je u aplikací problém se strukturováním kódu, který sice lze řešit využitím návrhových vzorů, ale i takováto dekompozice představuje neustále se opakující obdobné kusy kódu. V aplikaci je využito open-source frameworku 1 Spring Framework ve verzi 2.5, který je určen pro vývoj J2EE aplikací. Tento framework řeší výše uvedené problémy tak, že běžně opakující se funkce aplikací implementuje ve svých třídách a tím poskytuje vývojáři již hotovou infrastrukturu, kterou aplikace využívají (více v [2]). Jednou z vlastností Spring Framework je správa životního cyklu aplikace a kód aplikace je jím v požadovaných chvílích volán. Tímto je zajištěn přesun kontroly běhu aplikace na framework. Předpokladem pro tento fakt je nutnost správné strukturovanosti a dekompozice aplikace, kterou framework předepisuje. Velmi často se jedná právě o rozšířené návrhové vzory. 1 za framework lze označit komplexní aplikační servery, webové kontejnery jako např. Apache Tomcat či odlehčené a specializované rámce, kterými jsou např. Spring Framework, WebWord či Struts. 14

20 Spring Security Dependency Injection (Inversion of Control) Spring Framework je označován jako IoC kontejner. Inversion of Control (IoC) je návrhový vzor, který umožňuje převést kontrolu závislosti třídy na jiných komponentách mimo tuto třídu. Ve výsledku to znamená, že komponenty, na kterých je třída závislá jsou jí nastaveny (angl. injected) tímto návrhovým vzorem. Z tohoto důvodu bylo IoC později přejmenováno na Dependency Injection (DI). Sít vytvářených objektů je definována např. v konfiguračním souboru (obvykle XML), na jehož základě framework zajistí, aby objekty byly vzájemně provázány. Framework pro tento úkon využívá set metod (Setter Injection) a konstruktorů (Constructor Injection). Detailněji je popsán tento návrhový vzor v [2]. 4.2 Spring Security Spring security je bezpečnostní framework, který poskytuje zabezpečení pro aplikace založených na frameworku Spring. Tento framework umožňuje komplexní možnost pro zabezpečení aplikace. Detailně je Spring Security popsán v referenční dokumentaci [1] a je mu věnována kapitola v knize Spring In Action [2]. V případě zabezpečení webových aplikací využívá Spring Security servletové filtry, které zachycují požadavky na servlety tak, aby nejprve byla provedena autentizace a autorizace, a tím bylo zajištěno zabezpečeného přístupu k chráněným zdrojům. Obvykle je zabezpečován přístup k celému bloku programu, zejména obslužných kontrolerů. Tento framework však také umožňuje provést zabezpečení na úrovni volání metod. Lze tedy zabezpečit každou metodu zvlášt podle požadovaného oprávnění k jejímu provedení (např. mazat příspěvky je umožněno pouze uživateli s úrovní oprávnění ROLE_ADMIN. 15

21 Hibernate 4.3 Hibernate Hibernate je framework, který zajišt uje objektově-relační mapování (ORM) tříd programovacího jazyka na tabulky databáze. Tento framework poskytuje mechanismy jako např. transakční zpracování dat, cache objektů a obsahuje vlastní dialekt jazyka SQL pro práci s daty zvaný HQL neboli Hibernate Query Language. Ten dokáže na základě objektové notace manipulovat s daty v databázi jako s objekty. Hibernate používá pro mapování objektů tzv. mapovací soubory, které obsahují informace o tom, jakým způsobem budou propojeny tabulky databáze s objekty aplikace, které se v programovacím jazyce Java nazývají Plain Old Java Object (POJO). Soubory je možné mapovat i pomocí anotací přímo v POJO objektu a u metod kontrolerů, k docílení stejného efektu jako v případě mapovacích souborů. Výhodou Hibernate je usnadnění práce programátorovi, který nemusí upravovat relace mezi objekty ručně, ale může tuto práci přenechat zmíněnému frameworku. Další výhodou je využití HQL, které eliminuje nutnost použít pro jiný typ databázového systému jiný dotazovací jazyk. 4.4 Message-Digest Algorithm - MD5 MD5 je velmi rozšířená hash 2 funkce, jejíž výstupem je 128 bitů dlouhý otisk reprezentovaný 32 hexadecimálními znaky. V programovacím jazyce Java bylo využito funkce ControllerUtils.getMD5String(String text);, která jako svůj parametr přejímá libovolný řetězec a jejím výstupem je MD5 otisk, který tomuto vstupu odpovídá. Např. v případě zadání uživatelského hesla abc123 bude výstupem funkce pro převod do MD5 řetezec: e99a18c428cb38d5f e03 V případě zadání hesla abc124 bude výstupem funkce: 2 Hash je reprodukovatelná metoda pro převod dat do posloupnosti znaků, které vytváří jejich jednoznačnou charakteristiku. 16