MASARYKOVA UNIVERZITA F}w¡¢£¤¥¦§¨ AKULTA INFORMATIKY !"#$%&'()+,-./012345 Správa SSL certifikátov v aplikaˇcnomserveri WildFly BAKALÁRSKAPRÁCA Filip Bogyai Brno, 2014 Prehlásenie Prehlasujem, že táto bakalárska 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 vypracovaní používal alebo z nich ˇcerpal,v práci riadne citujem s uvedením úplného odkazu na príslušný zdroj. Filip Bogyai Vedúci práce: RNDr. Adam Rambousek ii Pod’akovanie Rád by som pod’akoval Petrovi Škopkovi za jeho cenné rady a podnetné pripomienky pri vypracovaní bakalárskej práce. Dalejˇ by som chcel pod’ako- vat’ mojej rodine za všetku podporu poˇcaspísania práce. iii Zhrnutie Ciel’om tejto bakalárskej práce je vytvorit’ rozšírenie pre aplikaˇcnýserver WildFly, ktoré umožní získavat’ a ukladat’ SSL certifikáty zo serveru pre správu identít FreeIPA. Toto rozšírenie bude schopné sledovat’ a obnovo- vat’ tieto certifikáty, priˇcom budú ukladané do zabezpeˇcenéhokryptogra- fického úložiska, ktoré je dostupné aplikaˇcnémuserveru. Prvá ˇcast’ práce sa zaoberá analýzou rozhrania serveru FreeIPA, pomocou ktorého sa dajú certifikáty vzdialene získavat’. Dalejˇ obsahuje popis architektúry WildFly spolu s nastaveniami jeho bezpeˇcnosti.Druhá ˇcast’ práce sa zameriava na implementáciu samotného rozšírenia ako modulu v aplikaˇcnomserveri. Popisuje funkcie rozšírenia a poskytnuté výhody pre správu certifikátov. iv Kl’úˇcovéslová Java, aplikaˇcnýserver, WildFly, rozšírenie, modul, správa certifikátov, SSL, keystore, FreeIPA, Dogtag Certificate System v Obsah 1 Úvod ...... 2 2 Základné pojmy ...... 4 2.1 Kryptografia ...... 4 2.2 Protokoly SSL a TLS ...... 5 2.3 Infraštruktúra verejného kl’úˇca ...... 6 2.3.1 Digitálny certifikát ...... 6 2.3.2 Certifikaˇcnáautorita ...... 7 3 Server pre správu identít FreeIPA ...... 9 3.1 Dogtag Certificate System ...... 10 3.1.1 REST rozhranie ...... 11 3.1.2 Metódy pre získavanie certifikátov ...... 12 4 Aplikaˇcnýserver WildFly ...... 13 4.1 Modulárna architektúra ...... 14 4.2 Administrácia aplikaˇcnéhoserveru ...... 14 4.3 Zabezpeˇceniekomunikácie pomocou SSL ...... 15 4.3.1 Bezpeˇcnostnýmodel ...... 16 4.3.2 Bezpeˇcnostnádoména ...... 17 5 Návrh riešenia na sledovanie certifikátov ...... 19 5.1 Trieda JavaKeystoreManager ...... 20 5.2 Trieda KeystoreTrackingManager ...... 21 5.3 Rozhranie PKIClient ...... 21 5.4 Trieda DogtagPKIClient ...... 22 5.4.1 Dogtag REST klient ...... 22 6 Implementácia rozšírenia do WildFly ...... 24 6.1 Maven ...... 24 6.2 Rozhranie Extension ...... 25 6.3 Subsystém certificate-tracker ...... 25 6.3.1 Konfigurácia sledovaných úložísk ...... 26 6.3.2 Konfigurácia PKI klienta ...... 27 6.3.3 Podpora premenných v konfigurácii ...... 28 6.4 Štruktúra modelu subsystému ...... 29 6.5 Služba pre sledovanie certifikátov ...... 30 6.5.1 Kontrola certifikátov ...... 30 6.5.2 Použitie obnovených certifikátov ...... 30 6.6 Dalšíˇ vývoj rozšírenia ...... 31 7 Záver ...... 32 A Použitie rozšírenia v aplikaˇcnomserveri WildFly ...... 33 1 1 Úvod Bezpeˇcnost’ internetovej komunikácie je dôležitá najmä pri práci s citlivými dátami. S rastúcim používaním internetu je stále viac aplikácií prístupných online. Castoˇ sa jedná o dôležité služby, ako je napríklad internetové ban- kovníctvo. Tým stúpa aj riziko zneužitia a je potrebné zaistit’ spol’ahlivú komunikáciu s internetovými servermi. Útoky na komunikáciu môžu mat’ rôzne formy, napríklad odpoˇcúvanieprostredníctvom Man-in-the-middle útoku, alebo vytvorenie falošného serveru ako napodobeniny originálneho. Ciel’om týchto útokov je získat’ cenné informácie, a preto je potrebné urˇci- tým spôsobom chránit’ posielané citlivé dáta. Na zabezpeˇceniekomunikácie medzi dvoma uzlami siete sa používa protokol Secure Sockets Layer (SSL) alebo jeho následník Transport Layer Se- curity (TLS). Server preukazuje svoju identitu certifikátom, ktorý obsahuje aj jeho verejný kryptografický kl’úˇc.Pre distribúciu a správu týchto certi- fikátov je potrebná infraštruktúra verejných kl’úˇcov. Pri rozsiahlom využí- vaní informaˇcnýchtechnológií je žiaduce, aby bezpeˇcnostnédáta boli zhro- mažd’ované na jednom mieste. Tým môžeme docielit’ väˇcšiukonzistent- nost’ a l’ahšie spravovanie údajov. Pri komunikácii klienta so serverom je potrebné kontrolovat’ platnost’ certifikátov v zozname revokovaných cer- tifikátov, ktoré pravidelne vydávajú certifikaˇcnéautority. Jedným z riešení pre centralizovanú správu certifikátov je server FreeIPA, ktorý zároveˇnvy- stupuje aj ako certifikaˇcnáautorita. Ciel’om tejto bakalárskej práce je vytvorit’ rozšírenie do aplikaˇcného servera WildFly, ktoré má za úlohu synchronizovat’ certifikáty serveru so vzdialeným správcom identít FreeIPA. Pri obnove certifikátu na strane ser- veru FreeIPA dôjde k automatickému stiahnutiu a výmene za nový v ap- likaˇcnomserveri. Webové aplikácie, ktoré sú nasadené na aplikaˇcnomser- veri WildFly a využívajú zabezpeˇcenépripojenie, tak budú používat’ ak- tuálne platné certifikáty. Ako úvod do problematiky slúži druhá kapitola, ktorá sa zaoberá zá- kladnými pojmami ako kryptografia, protokoly SSL/TLS a významnými prvkami infraštruktúry verejných kl’úˇcov. Nadväzujúca tretia kapitola je venovaná serveru pre centralizovanú správu identít FreeIPA. Bližšie je po- písané rozhranie, ktoré slúži pre správu a distribúciu certifikátov. V štvrtej kapitole tejto bakalárskej práce je predstavený aplikaˇcnýserver WildFly. Podrobne je vysvetlená jeho modulárna architektúra a podpora pre bezpeˇcnúzašifrovanú komunikáciu. Dalejˇ je popísaný spôsob využitia certifikátov v serveri a ich naˇcítaniez úložiska kl’úˇcov. 2 1. ÚVOD Piata kapitola sa týka návrhu riešenia pre správu a sledovanie certifiká- tov, ktoré sú dostupné aplikaˇcnémuserveru. Sú prebrané hlavné triedy a rozhrania, ktoré poskytujú funkcionalitu pre prácu s certifikátmi. Nasledujúca šiesta kapitola popisuje samotnú implementáciu rozšíre- nia ako modulu do aplikaˇcnéhoservera WildFly. Je predstavený vlastný subsystém pre konfiguráciu rozšírenia a služby, ktoré zaist’ujú sledovanie a výmenu certifikátov. Spomenuté sú dôležité kroky pri vývoji rozšírenia a možnosti jeho budúceho vývoja. Závereˇcnákapitola poskytuje zhrnutie celej práce a jej ciel’ov. Dalejˇ pre- zentuje dosiahnuté výsledky a výhody, ktoré rozšírenie prináša. 3 2 Základné pojmy V tejto kapitole sú definované základné pojmy, ktoré súvisia so správou digitálnych certifikátov a sú potrebné pre bližšie pochopenie problematiky a významu tejto práce. Sú tu popísané funkcie a význam kryptografie, pro- tokolov SSL/TLS a infraštruktúry verejných kl’úˇcov. Všetky tieto prostried- ky sú dôležitou súˇcast’ou bezpeˇcnejkomunikácie po internete. 2.1 Kryptografia Kryptografia je veda zaoberajúca sa matematickými technikami, ktoré sa vzt’ahujú k informaˇcnejbezpeˇcnosti.Tieto techniky zaist’ujú dôvernost’ a integritu dát, ˇcoumožˇnujeimplementáciu autentizácie entít, ˇciuž osôb alebo serverov a ich služieb. Kryptografia nám poskytuje algoritmy pre šifrovanie a dešifrovanie informácií, za použitia tajného parametra, ktorý nazývame kl’úˇc.Šifrovací algoritmus je funkcia konvertujúca vstupné dáta v otvorenej forme pomocou kryptografického kl’úˇcana výstupné dáta, ktoré sú zašifrované a neˇcitatel’né. Pre získanie pôvodných dát je potrebné použit’ dešifrovací algoritmus spolu s príslušným kl’úˇcom.Podl’a Kerckhoffsovho princípu tieto algoritmy musia byt’ verejne známe, pretože bezpeˇcnost’ kryp- tosystému by mala byt’ postavená na utajovaní a sile kryptografického kl’ú- ˇca,a nie na základe utajovania algoritmu [2]. Kryptografické algoritmy sa delia podl’a druhu použitých kl’úˇcovdo dvoch skupín: • Symetrická kryptografia používa rovnaký kryptografický kl’úˇcpre za- šifrovanie aj dešifrovanie informácií. Pretože obe komunikujúce stra- ny musia používat’ rovnaký kl’úˇc,je nutné, aby si ho najskôr bez- peˇcnýmspôsobom vymenili. Najˇcastejšímspôsobom výmeny symet- rických kl’úˇcovcez internet je použitie asymetrickej kryptografie pre vytvorenie bezpeˇcnéhospojenia. • Asymetrická kryptografia nepoužíva rovnaký kryptografický kl’úˇczdie- l’aný medzi odosielatel’om a prijímatel’om informácií. Používa sa dvo- jica šifrovacích kl’úˇcov, ktoré oznaˇcujemeako verejný a súkromný kl’úˇc.Verejný kl’úˇcje verejne známy a slúži pre zašifrovanie dát, ktoré posielame vlastníkovi tejto dvojice kryptografických kl’úˇcov. Ten po- mocou príslušného súkromného kl’úˇcaje schopný dáta dešifrovat’, preto je potrebné, aby bol tento kl’úˇcudržiavaný v tajnosti. Asymet- rická kryptografia sa používa aj pre realizáciu digitálneho podpisu. 4 2. ZÁKLADNÉPOJMY 2.2 Protokoly SSL a TLS Protokoly Secure Sockets Layer (SSL) a Transport Layer Security (TLS) slúžia pre zabezpeˇceniesiet’ovej komunikácie medzi dvoma komunikujúcimi stra- nami. Prenášané dáta sú šifrované symetrickým kryptografickým kl’úˇcom, ktorý je vygenerovaný pri ustanovení spojenia. Pre bezpeˇcnúvýmenu toh- to symetrického kl’úˇcaje využívaná infraštruktúra verejného kl’úˇca,ktorá je postavená na asymetrickej kryptografii. Pri nadviazaní spojenia prebieha Handshake fáza protokolu, ktorá za- ist’uje autentizáciu komunikujúcich strán a ustanovenie šifrovacích algorit- mov. Priebeh ustanovenia spojenia je nasledovný: 1. Klient posiela pri nadviazaní spojenia ClientHello správu, ktorá ob- sahuje verziu SSL/TLS protokolu, zoznam podporovaných šifrovacích algoritmov a náhodne vygenerované ˇcíslo. 2. Server odpovedá klientovi ServerHello správou, ktorá obsahuje naj- vyššiu podporovanú verziu protokolu oboma stranami, vybrané spo- loˇcnéšifrovacie algoritmy, náhodne vygenerované ˇcísloa digitálny certifikát s verejným kryptografickým kl’úˇcomserveru. 3. Klient overí certifikát serveru, ˇcizodpovedá meno na certifikáte s menom serveru a je digitálne podpísaný dôveryhodnou certifikaˇcnou autoritou. Následne vytvorí požiadavku na vytvorenie spoloˇcného šifrovacieho kl’úˇca,ktorý zašifruje verejným kl’úˇcomserveru. 4. Server a klient si z vymenených šifier a náhodných ˇcísielvytvoria spoloˇcnýsymetrický kryptografický kl’úˇc,ktorý bude použitý pre šif- rovanie a dešifrovanie ich spoloˇcnejkomunikácie. 5. Klient oznamuje serveru ukonˇcenie Handshake fázy protokolu a d’alšia komunikácia prebieha šifrovane. 6. Server oznamuje klientovi ukonˇcenie Handshake fázy protokolu s potvr- dením použitých šifier. Po ukonˇcenítejto fázy prebieha celá komunikácia medzi serverom a klientom zašifrovane za použitia vymenených kryptografických kl’úˇcov. Po- sielané dáta sú chránené pred odpoˇcúvaním a falšovaním. Nikto na sie- ti okrem dvoch zúˇcastnenýchstrán nemôže posielané správy dešifrovat’ alebo napodobnit’. 5 2. ZÁKLADNÉPOJMY 2.3 Infraštruktúra verejného kl’úˇca Infraštruktúra verejného kl’úˇca1 (PKI) slúži pre správu a distribúciu ve- rejných kl’úˇcovz asymetrickej kryptografie. Tieto kl’úˇcesa využívajú pre vytvorenie zašifrovaného spojenia, problémom však ostáva, ako overit’ iden- titu majitel’a, ktorý daný verejný kl’úˇcvlastní. PKI umožˇnujepoužívatel’om bezpeˇcnekomunikovat’ cez internetovú siet’, pretože spája identitu komu- nikujúcej strany s jej verejným kl’úˇcom.Identitu majitel’a je možné zistit’ a overit’ na základe certifikátu verejného kl’úˇca,ktorý je digitálne podpísaný dôveryhodnou tret’ou stranou. Pre ustanovenie dôvery sú zavedené certi- fikaˇcnéautority, ktoré certifikáty digitálne podpisujú a spravujú zoznamy zneužitých certifikátov [3]. 2.3.1 Digitálny certifikát Digitálny certifikát je dátová štruktúra obsahujúca verejný kl’úˇca identi- fikaˇcnéúdaje vlastníka zodpovedajúceho súkromného kl’úˇca. Dalejˇ certi- fikát obsahuje napríklad názov vydavatel’a certifikátu, poradové ˇcísloa platnost’ certifikátu. Aby bol certifikát dôveryhodný, musí byt’ digitálne podpísaný certifikaˇcnouautoritou, ktorá potvrdzuje spojenie identity sub- jektu s verejným kryptografickým kl’úˇcom. Najviac rozšírené sú certifikáty, ktoré majú štruktúru podl’a štandardu X.509 verzie 3. Predošlé verzie obsahovali nedostatky a v dnešnej dobe sa už nepoužívajú. Pre potreby internetu je vytvorený internetový profil štan- dardu X.509, ktorý je definovaný v RFC 3280 [4]. Štruktúra X.509v3 certi- fikátu obsahuje nasledovné položky: Verzia Sériové ˇcíslo Algoritmus podpisu Vydavatel’ Platnost’ Nepoužívat’ pred | Nepoužívat’ po Subjekt Verejný kl’úˇc Rozšírenia certifikátu Digitálny podpis Príklad 1: Certifikát podl’a štandardu X.509v3 1. anglickyPublic-key Infrastructure 6 2. ZÁKLADNÉPOJMY • Verzia udáva ˇcíslonormy X509, podl’a ktorej je certifikát vytvorený. • Sériové ˇcíslo urˇcujejednoznaˇcnéporadové ˇcíslocertifikátu v rámci kon- krétnej certifikaˇcnejautority. • Algoritmus podpisu špecifikuje algoritmy použité certifikaˇcnouautori- tou pre vytvorenie digitálneho podpisu certifikátu. • Vydavatel’ je urˇcenýpomocou jedineˇcnéhomena2 toho, kto certifikát digitálne podpísal. • Platnost’ urˇcujeplatnost’ certifikátu pomocou dvoch položiek: Nepouží- vat’ pred, Nepoužívat’ po3 • Subjekt je držitel’ certifikátu, ktorý je urˇcenýpomocou jedineˇcného mena. • Verejný kl’úˇc sa skladá z dvoch položiek: identifikátor algoritmu, pre ktorý je verejný kl’úˇcvydaný a samotný verejný kl’úˇc. • Rozšírenia certifikátu umožˇnujúpridat’ d’alšie volitel’né informácie. • Digitálny podpis je mechanizmus, ktorý zaist’uje nepopieratel’nost’ dát. Umožˇnujeoverit’ vydavatel’a certifikátu a zároveˇnpomáha overit’, ˇci certifikát nebol od digitálneho podpísania zmenený. Z dát certifikátu je vytvorený hash, ktorý je následne podpísaný súkromným kl’úˇcom vydavatel’a. Overenie certifikátu je dôležitá bezpeˇcnostnáakcia a pozostáva z viace- rých krokov. Po obdržaní certifikátu od serveru je overený digitálny podpis a platnost’ certifikátu. Aby bol certifikát dôveryhodný, musí byt’ vydaný certifikaˇcnouautoritou, ktorej klient dôveruje. Následne je možné overit’, ˇcicertifikát nie je vyhlásený za neplatný (revokovaný) napríklad z dôvodu zneužitia súkromného kl’úˇcavlastníka. 2.3.2 Certifikaˇcnáautorita Certifikaˇcnáautorita (CA) predstavuje dôveryhodnú tretiu stranu, ktorá poskytuje certifikaˇcnéslužby spojené s vydávaním a overovaním certifiká- tov. Jej úlohou je overit’ identitu subjektu, ktorý žiada o vydanie certifikátu. 2. anglicky Distunguished Name 3. anglicky Not Before, Not After 7 2. ZÁKLADNÉPOJMY Subjekt sa musí preukázat’ vlastníctvom verejného a súkromného kryp- tografického kl’úˇca,na základe ˇcohomu CA vydá certifikát. Tento certifikát je digitálne podpísaný súkromným kl’úˇcomCA, ktorý zaruˇcujeautenticitu vydaného certifikátu. Pokial’ užívatel’ má certifikát CA a dôveruje mu, tak je možné považovat’ certifikáty vydané rovnakou CA za dôveryhodné. Dalšouˇ úlohou CA je sledovat’ certifikáty, ktoré boli odvolané alebo skon- ˇcilaich platnost’. Certifikáty je možné odvolat’ (revokovat’), pokial’ bol na- príklad vyzradený súkromný kl’úˇcvlastníka. CA pravidelne vydáva infor- mácie o týchto odvolaných certifikátoch v zozname revokovaných certi- fikátov4. Pre overenie platnosti certifikátu je potrebné st’ahovat’ aktuálne CRL, preto je dôležité, v akých intervaloch sú tieto zoznamy vydávané. Druhou alternatívou je služba Online Certificate Status Protocol (OCSP), ktorá umožˇnujekontrolovat’ certifikáty jednotlivo bez potreby st’ahovania celého zoznamu. Túto služby taktiež prevádzkuje CA, priˇcomje verejne prístupná a funguje na princípe žiadosti a odpovede. Certifikaˇcnéautority môžu byt’ usporiadané do hierarchie, priˇcomna vrchole sa nachádzajú koreˇnovéCA. Tie vydávajú a podpisujú svojím sú- kromným kl’úˇcomcertifikáty pomocných CA na nižších úrovniach. Certi- fikáty sú overované na základe ret’azca dôvery, ktorý pozostáva z uspori- adaného zoznamu certifikátov všetkých CA v danej certifikaˇcnejhierarchii. Výhodou certifikaˇcnejhierarchie je, že staˇcídôverovat’ certifikátu koreˇnovej CA a nie je potrebné spravovat’ všetky certifikáty pomocných CA. Príklad 2: Hierarchia certifikaˇcnýchautorít 4. anglicky Certificate Revocation List (CRL) 8 3 Server pre správu identít FreeIPA FreeIPA server je centralizované riešenie pre správu identít, politík a au- ditu (IPA). Toto riešenie je primárne urˇcenépre siete poˇcítaˇcovs operaˇcným systémom Linux alebo Unix. Zhromažd’uje a ukladá informácie o užívate- l’och, skupinách a poˇcítaˇcoch,ktoré sú potrebné pre správu bezpeˇcnostných aspektov. Centralizáciou bezpeˇcnostnýchdát na jedno miesto je možné do- siahnut’ jednoduchšiu a prehl’adnú správu údajov. Preto poskytuje FreeIPA služby na overovanie autentizaˇcnýchúdajov a autorizáciu operácií iným poˇcítaˇcom,ktoré nepotrebujú mat’ jednotlivo uložené potrebné dáta. Free- IPA server integruje viaceré systémy pre správu bezpeˇcnostnýchinformá- cií. Všetky z týchto komponentov sú známe open source riešenia, priˇcom každé poskytuje urˇcitúfunkcionalitu [5]: • Linux ako operaˇcnýsystém, na ktorom je FreeIPA spustená. (Fedora alebo Red Hat Enterprise Linux) • 389 Directory Server je hlavné úložisko dát, ktoré je zároveˇnplnohod- notný Lightweight Directory Access Protocol (LDAP) server. • MIT Kerberos poskytuje služby jednotného prihlásenia užívatel’ov k rôznym službám pomocou protokolu Kerberos. • Dogtag Certificate System je certifikaˇcnáautorita a distribuˇcnýsystém certifikátov, ktorý slúži pre kompletnú správu certifikátov. • DNS systém hierarchického pomenovania siet’ových zdrojov (poˇcí- taˇcov, služieb alebo l’ubovol’ných zdrojov). FreeIPA server poskytuje rozhrania XMLRPC and JSONRPC, pomocou ktorých sa dajú volat’ poskytované služby a operácie. Ciel’om tejto práce je vytvorit’ rožšírenie, ktoré bude sledovat’ a získavat’ certifikáty poskyto- vané serverom FreeIPA. Prístup k rozhraniam FreeIPA je rozdelený zvlášt’ pre užívatel’ov a služby. Poˇcasimplementácie rozšírenia ako služby na sle- dovanie certifikátov bola objavená chyba, ktorá znemožˇnujeslužbám získa- vat’ kompletné certifikáty v binárnej podobe pomocou rozhrania FreeIPA. Rozhranie FreeIPA je však len integraˇcnánadstavba nad rozhraním kom- ponentu Dogtag Certificate System, ktorý zaist’uje kompletnú správu certi- fikátov. Preto vhodným riešením je vytvorit’ klienta, ktorý bude komuniko- vat’ priamo s rozhraním systému Dogtag. 9 3. SERVER PRE SPRÁVU IDENTÍT FREEIPA 3.1 Dogtag Certificate System Dogtag Certificate System je open source implementácia systému urˇceného pre správu certifikátov v infraštruktúre verejných kl’úˇcov. Vznikol z Net- scape Certificate Server, ktorý bol vyvíjaný od roku 1997. Je to komplexné riešenie pre vytvorenie infraštruktúry PKI so všetkými potrebnými kom- ponentmi. Podporuje vydávanie, distribúciu, overovanie a revokáciu digi- tálnych certifikátov. Pre ukladanie certifikátov využíva LDAP server 389 Directory Server. Dogtag obsahuje šest’ konfigurovatel’ných subsystémov, ktoré poskytujú flexibilitu pri navrhovaní PKI [6]: • Certifikaˇcnáautorita (CA) je subsystém, ktorý poskytuje funkcie pre správu certifikátov, ako je vydávanie, obnovovanie, rušenie, overova- nie certifikátov a vytváranie a publikovanie Zoznamov revokovaných certifikátov (CRL). • Registraˇcnáautorita (RA) je subsystém, ktorý overuje žiadosti o certi- fikáty, na základe ktorých CA rozhodne o vydaní a podpísaní daného certifikátu. • The Online Certificate Status Protocol (OCSP) je volitel’ný subsystém, ktorý poskytuje OCSP overovacie služby. To znamená, že ukladá CRL pre rôzne CA a umožˇnujeznížit’ zat’aženie, ktoré spôsobuje overova- nie certifikátov. • The Data Recovery Manager (DRM) je volitel’ný subsystém, ktorý umož- ˇnujeukladanie a vyhl’adávanie privátnych kryptografických kl’úˇcov. • The Token Key Service (TKS) spravuje jeden alebo viac hlavných kryp- tografických kl’úˇcovpotrebných pre nastavenie zabezpeˇcenýchkaná- lov priamo k riadeniu systému. Privilegované operácie, ako je gene- rovanie nových kryptografických kl’úˇcovmožno žiadat’ len prostred- níctvom zabezpeˇcenéhokanála. • The Token Processing System (TPS) poskytuje funkcie pre registraˇcný orgán v infraštruktúre tokenov a vytvára zabezpeˇcenékanály. Dogtag Certificate System je možné ovládat’ pomocou grafického we- bového rozhrania. Prístup k jednotlivým službám je rozdelený podl’a role oprávnenia užívatel’a. Používatel’ sa autentizuje pomocou svojho certifikátu, ktorý musí byt’ zaregistrovaný v systéme. Služby, ktoré sú prístupné všet- kým bez prihlásenia (public), umožˇnujúzískavat’ zoznam dostupných cer- tifikátov. Služby urˇcenéprihláseným používatel’om (user) sa rozširujú o 10 3. SERVER PRE SPRÁVU IDENTÍT FREEIPA správu užívatel’ských kryptografických kl’úˇcova možnosti vytvorit’ žia- dost’ o registráciu nového alebo pred´lženie existujúceho certifikátu. Uží- vatel’ s oprávnením agent má neobmedzený prístup k všetkým službám, ako napríklad schval’ovanie žiadostí o certifikáty alebo revokácia zneužitých certifikátov. 3.1.1 REST rozhranie Dogtag Certificate System taktiež poskytuje rozhranie Representational state transfer (REST), ktoré umožˇnujeklientskym aplikáciám prístup k službám. Samotná REST architektúra je efektívne a škálovatel’né riešenie pre vývoj rôznych modulov, ktoré sú medzi sebou vol’ne viazané. Pre komunikáciu medzi modulmi sa používa jednotné rozhranie, ktoré identifikuje zdroje a k nim príslušné operácie. REST rozhranie postavené nad protokolom HTTP používa bežné metódy tohto protokolu, ktoré urˇcujútyp akcie vykonanej na zdroji dát: • GET : získanie reprezentácie záznamu definovaného pomocou URL. Používa sa na operácie, ktoré nespôsobujú zmeny záznamov. • POST : odoslanie nových záznamov na server • PUT : aktualizácia existujúcich záznamov • DELETE : odstránenie existujúcich záznamov Volanie služby prebieha tak, že klientska aplikácia vytvorí požiadavku na urˇcitúURL adresu, ktorá je bližšie špecifikovaná HTTP metódou podl’a typu akcie. Server má na urˇcenýchURL vystavené zdroje a podl’a metódy vyvolá príslušnú operáciu na záznamoch. Nastavené HTTP hlaviˇckyurˇcujú rôzne kritériá, napríklad preferovaný jazyk alebo kódovanie dát. Odpovede serveru obsahujú klasické stavové kódy protokolu HTTP závislé od výsled- ku operácie a výsledné záznamy. Záznamy sú pri komunikácii posielané vo forme XML alebo JSON. Dogtag Certificate System má REST služby implementované pomocou frameworku RESTEasy. RESTEasy je implementácia Java EE špecifikácie JAX-RS, ktorá definuje štandard RESTful webových služieb. Dostupné REST zdroje sú definované pomocou Java rozhraní, ktoré urˇcujúURL adresu, dá- tové modely použité pre prenos informácií a výsledky operácií. Pre konfi- guráciu týchto rozhraní sa používajú anotácie nad jednotlivými metódami. Ako dátové modely sú použité klasické Java triedy, ktoré rovnako využí- vajú anotácie pre definíciu atribútov. Výhodou je, že použité rozhrania a triedy sú zdiel’ané medzi serverom a klientom [7]. 11 3. SERVER PRE SPRÁVU IDENTÍT FREEIPA 3.1.2 Metódy pre získavanie certifikátov Pre vytvorenie služby na sledovanie certifikátov je potrebné implemento- vat’ REST klienta. Dogtag má vystavený zdroj pre získavanie certifikátov na URL adrese1: http://example.com/ca/rest/. Java rozhranie, ktoré definuje tento zdroj sa volá CertResource a obsahuje viaceré metódy pre prácu s certifikátmi. Na vzdialenú synchronizáciu certifikátov je potrebné využívat’ dve metódy z tohto rozhrania: • Pre získanie zoznamu dostupných certifikátov je vystavená metóda listCerts na URL: http://example.com/ca/rest/certs. Táto me- tóda vracia list informácií o certifikátoch, ktorých súˇcast’ou je ID, sub- jekt, aktuálny status, typ, verzia, použitý algoritmus, d´lžka kl’úˇcaa platnost’ certifikátu. Tejto metóde je možné pridat’ parametre, ˇcímsa obmedzí vrátený zoznam certifikátov, napríklad podl’a ID rozsahu, poˇctumaximálnych výsledkov alebo aktuálneho statusu. • Pre získanie konkrétneho certifikátu je vystavená metóda getCert na URL: http://example.com/ca/rest/certs/{ID}. Parameter ID je povinný a udáva identifikaˇcnéˇcíslocertifikátu, ktorý má byt’ vrátený. Táto metóda vracia detailné informácie o certifikáte vrátane jeho bi- nárnej podoby, ktorá sa dá dekódovat’ do potrebného Java objektu typu X509Certificate [8]. Rozhranie CertResource s potrebnými metódami je možné použit’ na strane klienta. Tým, že Dogtag Certificate System je open source projekt, sú k dispozícii aj triedy používané pre prenos dát. To umožˇnujejednoduchú implementáciu REST klienta, priˇcomtriedy je možné upravit’ tak, aby posky- tovali potrebnú funkcionalitu. V budúcich verziách Dogtag by mala pribudnút’ samostatná knižnica s predpripraveným REST klientom. To ešte viac zjednoduší integráciu, ked’že knižnice je možné pridávat’ ako závislosti do Java projektov. Momentálne však knižnica stále nie je k dispozícii ako samostatný modul. Preto sú v implementácii rozšírenia pre správu certifikátov použité vlastné upravené triedy, pomocou ktorých je možné certifikáty získavat’. 1. Adresa http://example.com je použitá ako vzorová adresa pre server FreeIPA 12 4 Aplikaˇcnýserver WildFly WildFly, predtým známy ako JBoss AplikaˇcnýServer(AS), je implementá- cia Java aplikaˇcnéhoserveru, ktorý sp´lˇnašpecifikáciu Java Enterprise Edi- tion(EE) 7. Všeobecne môžeme aplikaˇcnýserver chápat’ ako kontajner, ktorý poskytuje vhodné prostredie pre beh aplikácií. Aplikaˇcnýserver tvorí vrstvu medzi operaˇcnýmsystémom a aplikáciami. Poskytuje potrebné funkcie a služby aplikáciám, ktoré sú na ˇnomnasadené. To ul’ahˇcujevývoj samot- ných aplikácií, pretože nemusia implementovat’ služby ako je pripojenie k databázam, výmenu správ, bezpeˇcnost’ a vel’a d’alších. V prípade Java EE aplikaˇcnýchserverov ide o služby, ktoré sú urˇcené Java EE špecifikáciou. Špecifikácia Java EE sa d’alej delí na dva profily, ktoré bližšie urˇcujúpotrebné služby poskytované Java aplikaˇcnýmiservermi. We- bový profil je optimalizovaný pre jednoduchšie Java aplikácie, ktorým staˇcí základná podpora Java EE technológií. Naopak plný profil obsahuje všetky služby špecifikácie Java platformy. Príklad 3: Porovnanie Java EE profilov [13] Každý Java aplikaˇcnýserver, ktorý chce byt’ kompatibilný s Java EE špecifikáciou musí prejst’ certifikáciou. To zamedzuje vzniku nedokonˇcených, nekvalitných aplikaˇcnýchserverov, ktoré by neboli navzájom kompatibilné. Výsledkom takejto štandardizácie platformy Java EE je princíp „Napíš raz, 13 4. APLIKACNÝSERVERˇ WILDFLY spusti všade1“ [9]. Ten umožˇnujejednoduchšiu migráciu aplikáciám po- staveným na platforme Java EE. WildFly aplikaˇcnýserver je certifikovaný pre obidva profily Java EE 7 špecifikácie. Taktiež ponúka beh viacerých in- štancií serverov v jednej logickej skupine2, ˇcímje možné dosiahnut’ vysokú dostupnost’3 serverov. Nasadené aplikácie sú tak prístupné aj po výpadku jedného zo serverov a uložené informácie sú distribuované medzi servermi. 4.1 Modulárna architektúra Aplikaˇcnýserver WildFly tvorí množstvo modulov, priˇcomkaždý modul plní urˇcitúfunkciu. Tieto moduly sú zložené z jedného alebo viacerých Java archívov (JAR), ktoré sú umiestnené v adresárovej štruktúre podob- nej Java balíkom. Každý modul má definovanú svoju štruktúru v súbore module.xml. WildFly používa tento súbor pre naˇcítaniemodulov pomo- cou vlastného classloadera JBoss Modules, ktorý sa výrazne líši od pre- došlých verzií JBoss AS. Namiesto bežne známeho hierarchického naˇcítava- nia tried je použitý modulárny princíp, pomocou ktorého sa naˇcítavajúdo pamäte iba potrebné moduly. Naˇcítavanieprebieha paralelne, ˇcozaruˇcuje vysoký výkon aj pri vel’kých systémových štruktúrach [10]. Aplikaˇcnýserver WildFly automaticky definuje závislosti na moduly, ktoré poskytujú služby dané v Java EE špecifikácii. To znamená, že Java EE aplikácie nasadené na aplikaˇcnýserver nemusia definovat’ závislosti pre štandardizované Jave EE služby. Naopak samotné moduly, z ktorých sa WildFly skladá, musia explicitne uviest’ závislosti na iných moduloch vo svojom popisnom súbore module.xml. Tieto závislosti nie sú tranzitívne a preto je potrebné uviest’ ich kompletný zoznam [11]. 4.2 Administrácia aplikaˇcnéhoserveru WildFly ponúka tri rôzne spôsoby, ktorými je možné aplikaˇcnýserver kon- figurovat’ a ovládat’: • Webové rozhranie : je webová aplikácia, ktorá používa HTTP rozhranie • Konzolový klient : je klient podobný Unixovému príkazovému riadku • XML konfiguraˇcnésúbory : uložené nastavenia serveru v podobe XML 1. anglicky Write Once, Run Anywhere (WORA) 2. anglicky Cluster 3. anglicky High Availability (HA) 14 4. APLIKACNÝSERVERˇ WILDFLY Webové rozhranie poskytuje užívatel’sky prívetivé prostredie pre kon- figuráciu základných najpoužívanejších súˇcastíaplikaˇcnéhoserveru. Toto rozhranie je grafická manažment konzola, ktorá je prístupná z bežného prehliadaˇca.Niektoré pokroˇcilénastavenia je však možné robit’ iba pomo- cou konzolového klienta. Konzolový klient umožˇnujemenit’ všetky nasta- venia, poskytuje nápovedu a zadané operácie aj skontroluje, aby výsledná konfigurácia serveru bola bez chýb. Väˇcšinazmien sa ihned’ uplatní na spustenej WildFly inštancii. Zmeny v konfigurácii sa zapisujú aj do konfi- guraˇcnýchsúborov, odkial’ sú nastavenia naˇcítanépoˇcasštartu aplikaˇcného serveru. Preto poslednou možnost’ou konfigurácie je úprava týchto XML konfiguraˇcnýchsúborov aplikaˇcnéhoservera. Nevýhodou tohto spôsobu je nutnost’ reštartu celého serveru pre naˇcítanienovej konfigurácie a ˇcastý výskyt chýb kvôli chýbajúcej kontrole [12]. Nastavenia sú rozdelené do jednotlivých sekcií aplikaˇcnéhoserveru, ktoré sa nazývajú subsystémy. Každý subsystém zodpovedá urˇcitejslužbe aplikaˇcnéhoserveru, ktorú je možné pomocou nastavení v subsystéme bliž- šie konfigurovat’. Pre zavedenie subsystému urˇcitejslužby do nastavení je potrebné modul tejto služby pridat’ ako rozšírenie na zaˇciatkukonfigu- raˇcnéhosúboru serveru. V tomto module sa musí nachádzat’ schéma nas- tavení a definícia modelu nastavení pre subsystém. Okrem subsystémov sa v konfiguraˇcnomsúbore nachádzajú základné sekcie aplikaˇcnéhoserveru pre manažment, otvorené rozhrania a porty. 4.3 Zabezpeˇceniekomunikácie pomocou SSL Pripojenie k aplikaˇcnémuserveru WildFly je možné zabezpeˇcit’ pomocou protokolov SSL a TLS. Takéto bezpeˇcnéspojenia sa dajú nastavit’ zvlášt’ pre administraˇcnérozhranie aplikaˇcnéhoserveru a pre jednotlivé webové konektory k nasadeným aplikáciám. To umožˇnujeoddelit’ spôsoby auten- tizácie pre administrátorov serveru a užívatel’ov webových aplikácií. Ko- munikaˇcnérozhrania sa odkazujú na bezpeˇcnostnémodely, v ktorých sa definuje protokol pre spojenia s týmito rozhraniami. Pokial’ je protokol nas- tavený na SSL alebo TLS, server sa vždy pri pripojení klienta preukazuje svojim certifikátom, priˇcomklient sa rozhodne, ˇcinadviaže spojenie. Po- tom nasleduje autentizácia klienta, na základe nastavení v pridelenom bez- peˇcnostnommodeli. Pokial’ je nastavené prihlásenie klienta pomocou certi- fikátu, ide o obojstrannú SSL autentizáciu. Vtedy server vyžaduje od klienta, aby sa preukázal svojim klientskym certifikátom. 15 4. APLIKACNÝSERVERˇ WILDFLY 4.3.1 Bezpeˇcnostnýmodel Bezpeˇcnostnýmodel WildFly sa konfiguruje v sekcii manažmentu. Tam je možné nakonfigurovat’ security-realm, ktorý reprezentuje nastavenia bez- peˇcnostipre vytváranie spojenia medzi serverom a klientom. Obsahuje nas- tavenia pre identitu serveru, v ktorej sa konfiguruje kryptografické úložisko obsahujúce certifikát serveru. Dalejˇ je možné nastavit’ spôsob autentizácie klientov, napríklad pomocou užívatel’ského mena a hesla, alebo pomocou certifikátu. Pre aplikovanie urˇcitéhobezpeˇcnostnéhomodelu je nutné sa odkázat’ na jeho meno v nastaveniach komunikaˇcnéhorozhrania. Príklad 4: SecurityRealm používajúci protokol TLSv1 na zabezpeˇcnúko- munikáciu WildFly má oddelené administraˇcnérozhranie a webové konektory k nasadeným aplikáciám. Administraˇcnérozhranie sa nastavuje v manaž- ment sekcii management-interfaces. Rozhranie sa odkazuje na security-realm, ktorý používa na zabezpeˇceniekomunikácie. Pre povolenie zabezpeˇcenej SSL komunikácie je potrebné zmenit’ http soket na https soket. Príklad 5: Administraˇcnérozhranie zabezpeˇcenécez SSLSecuredRealm Prístup k nasadeným aplikáciám sa konfiguruje pomocou webových konektorov v subsystéme undertow. Undertow je webový server, ktorý umož- ˇnujenastavit’ https-listener zabezpeˇcenýrovnako pomocou security-realm [14]. 16 4. APLIKACNÝSERVERˇ WILDFLY Príklad 6: Konektor k aplikáciám zabezpeˇcenýcez SSLSecuredRealm 4.3.2 Bezpeˇcnostnádoména V predošlej kapitole boli opísané nastavenia, ktorými sa zabezpeˇcujeiba samotné spojenie medzi serverom a klientom. WildFly takisto poskytuje aplikáciám služby, ktoré sa dajú využit’ pre prihlasovanie užívatel’ov do ap- likácií. Klient sa môže pripojit’ na nezabezpeˇcenúúvodnú stránku apliká- cie, ale pokial’ chce pristúpit’ do chránenej ˇcastimusí sa urˇcitýmspôsobom autentizovat’. Na základe úspešného prihlásenia sú užívatel’ovi udelené oprávnenia (role), ktoré sú potrebné pre prístup k zabezpeˇcenýmˇcastiam aplikácie. WildFly obsahuje pre tieto úˇcelyrôzne prihlasovacie moduly4, pomocou ktorých sa užívatel’ môže autentizovat’. Prihlasovacie moduly sa konfigurujú v bezpeˇcnostnejdoméne5, na ktorú sa odkazujú nasadené ap- likácie v súbore jboss-web.xml. Po úspešnom prihlásení sa identita a role užívatel’a propagujú do aplikácie. Napríklad pri použití obojstrannej SSL autentizácie je vhodné použit’ prihlasovací modul CertificateRoles, ktorý mapuje užívatel’ské role na klient- ske certifikáty. Webové aplikácie, ktoré majú v súbore web.xml nastavenú autentizaˇcnúmetódu CLIENT_CERT a používajú bezpeˇcnostnúdoménu s nastaveným prihlasovacím modulom CertificateRoles, majú automaticky asociované užívatel’ské role ku každému klientovi, ktorý sa preukáže plat- ným certifikátom. Toto riešenie je užívatel’sky prívetivé, pretože klienti sa nemusia prihlasovat’ iným spôsobom, ako napríklad menom a heslom [15]. 4. anglicky Login Module 5. anglicky Security Domain 17 4. APLIKACNÝSERVERˇ WILDFLY Príklad 7: Autentizácia klientov na základe ich certifikátov V súbore roles.properties je uložené mapovanie rolí na užívatel’ské mená z klientskych certifikátov. Tieto certifikáty musia byt’ pridané ako dôveryhodné v odkazovanom kryptografickom úložisku app.truststore. 18 5 Návrh riešenia na sledovanie certifikátov V tejto kapitole sú popísané hlavné triedy, na ktorých je postavené rozšíre- nie pre správu a sledovanie certifikátov. Ked’že aplikaˇcnýserver používa certifikáty uložené v Java kryptografickom úložisku, je potrebné navrhnút’ triedu na spravovanie jednotlivých úložísk. Pre tieto úˇcelyslúži trieda Java- KeystoreManager. Aplikaˇcnýserver WildFly môže používat’ viacero kryp- tografických úložísk, preto bola navrhnutá trieda KeystoresTracking- Manager. Tá môže spravovat’ súˇcasneviacero inštancií tried Keystore- Manager. Taktiež obsahuje rozhranie PKIClient, ktoré poskytuje metódy pre získavanie certifikátov zo vzdialeného správcu identít. Jednou z imple- mentácií tohto rozhrania je trieda DogtagPKIClient, ktorá je upravený REST klient pre Dogtag Certificate System. Príklad 8: Class diagram s hlavnými triedami rozšírenia 19 5. NÁVRH RIEŠENIA NA SLEDOVANIE CERTIFIKÁTOV 5.1 Trieda JavaKeystoreManager Keystore (d’alej len úložisko) je dátová štruktúra pre bezpeˇcnéuloženie kryptografických kl’úˇcova certifikátov. S týmto úložiskom sa dá pracovat’ z programovacieho jazyku Java, v ktorom sa používa ako databáza kryp- tografických kl’úˇcov. Aplikaˇcnýserver WildFly taktiež používa úložiská pre konfiguráciu kryptografických kl’úˇcovalebo dôveryhodných certifikátov, ktoré sa používajú pri zabezpeˇcenejkomunikácii. Trieda JavaKeystoreManager je implementáciou rozhrania Keystore- Manager a má za úlohu spravovat’ práve jedno úložisko, ktoré sa iniciali- zuje pri vytváraní triedy. Podporuje tri rôzne typy úložiska: JKS, JCEKS a PKCS12. Pre naˇcítanieúložiska je potrebné vediet’ jeho umiestnenie, typ a heslo. Jenotlivé položky v úložisku sú prístupné pod unikátnym identifiká- torom nazývaným alias. Úložisko môže obsahovat’ rôzne typy záznamov, priˇcomale každý musí implementovat’ KeyStore.Entry rozhranie. Tri základné typy implementovaných záznamov v Jave sú: • PrivateKeyEntry : obsahuje privátny asymetrický kl’úˇc,ktorý je spojený s certifikátom pre jeho zodpovedajúci verejný kl’úˇc. • SecretKeyEntry : obsahuje tajný kryptografický kl’úˇc,ktorý sa pou- žíva pri symetrickej kryptografii. • TrustedCertificateEntry : obsahuje certifikát spojený s verej- ným kl’úˇcomsubjektu. V prípade privátneho kl’úˇcas certifikátom môžeme pomocou aliasu ur- ˇcit’, ktorým certifikátom sa bude aplikaˇcnýserver prezentovat’ klientom. Naopak záznamy obsahujúce iba certifikáty je možné použit’ ako databázu dôveryhodných verejných kl’úˇcov, priˇcomked’ klient predloží jeden z dôvery- hodných certifikátov, tak je automaticky autentizovaný [16]. JavaKeystoreManager poskytuje metódy pre vyhl’adávanie všetkých certifikátov v úložisku alebo jednotlivých certifikátov podl’a aliasov. Ked’že záznamov v úložisku môže byt’ vel’ké množstvo, umožˇnujepodl’a aliasov obmedzit’ certifikáty, s ktorými bude pracovat’. Pokial’ nie je nastavený žia- dny zoznam aliasov, automaticky sa spravujú všetky záznamy v úložisku. Dôveryhodné certifikáty uložené v zázname typu TrustedCertificate- Entry sa aktualizujú náhradou za nový. Avšak pri výmene certifikátu pre PrivateKeyEntry je potrebné vymenit’ kompletný ret’azec certifikátov, ktorý je spojený s privátnym asymetrickým kl’úˇcom. 20 5. NÁVRH RIEŠENIA NA SLEDOVANIE CERTIFIKÁTOV 5.2 Trieda KeystoreTrackingManager Ako už bolo spomínané v úvode kapitoly, aplikaˇcnýserver WildFly môže používat’ viacero úložísk, napríklad každý pre inú službu. Riešením pre správu certifikátov vo viacerých úložiskách je vytvorenie viacerých inš- tancií triedy JavaKeystoreManager. Tieto inštancie je potrebné jednotne ovládat’, ˇcozabezpeˇcujeSingleton1 trieda KeystoreTrackingManager. Slúži ako správca pre pridelenú kolekciu implementácií KeystoreManager a synchronizuje sledované certifikáty so vzdialeným certifikaˇcnýmsysté- mom. Používa rozhranie PKIClient, ktoré obsahuje metódy pre získa- vanie informácií o certifikátoch priamo z certifikaˇcnéhosystému. V pravidel- ných intervaloch kontroluje pomocou PKI klienta informácie o aktuálne dostupných certifikátoch. Pokial’ nájde aktualizovaný certifikát niektorého zo sledovaných certifikátov, tak dôjde k výmene za nový. Certifikát je po- važovaný za aktualizovaný, pokial’ sp´lˇnanasledujúce kritériá: • Meno subjektu, pre ktorý je nový certifikát vydaný musí byt’ totožné so sledovaným certifikátom. • Platnost’ certifikátu je väˇcšiaako pôvodného certifikátu a zároveˇn musí byt’ už aktuálne platný. • Status certifikátu v certifikaˇcnomsystéme je platný2 • Pri certifikáte, ktorý je spojený s privátnym kl’úˇcommusí certifikát obsahovat’ odpovedajúci verejný kl’úˇc. Všetky potrebné informácie o certifikátoch sú reprezentované pomocou triedy CertificateInfo. Pri dotazovaní PKI klienta na certifikaˇcnýsys- tém je vrátená kolekcia CertificateInfo, na základe ktorej Keystore- TrackingManager vie urˇcit’, ktoré certifikáty boli aktualizované. 5.3 Rozhranie PKIClient Rozhranie PKIClient poskytuje urˇcitúabstrakciu od konkrétnej imple- mentácie PKI klienta. To umožˇnujevytvorenie vlastnej implementáciie PKI klienta pre rôzne iné certifikaˇcnésystémy, pomocou ktorej bude Keystore- TrackingManager synchronizovat’ certifikáty. Na vytvorenie PKI klienta sa používajú dve metódy z rozhrania: 1. existuje práve jeden objekt tejto triedy, ktorý je globálne prístupný bez referencie 2. anglicky VALID 21 5. NÁVRH RIEŠENIA NA SLEDOVANIE CERTIFIKÁTOV • metóda init(Map • metóda isInitialized() vracia logický dátový typ boolean(áno/nie) urˇcu- júci, ˇcije PKI klient inicializovaný. Dalejˇ rozhranie PKIClient predpisuje dve hlavné metódy, pomocou ktorých sa certifikáty synchronizujú: • metóda listCertificates() vracia kolekciu základných informácií o certi- fikátoch vo forme objektov CertificateInfo. • metóda getCertificate(String id) vracia kompletný certifikát v objekte X509Certificate na základe zadaného parametru id. 5.4 Trieda DogtagPKIClient DogtagPKIClient je implementáciou PKI klienta pre certifikaˇcnýsystém Dogtag, ktorý je súˇcast’ou správcu identít FreeIPA. Certifikáty získava po- mocou REST klienta, ktorý komunikuje priamo s REST rozhraním Dogtagu. DogtagPKIClient upravuje návratové objekty ktoré získava REST klient tak, aby sp´lˇnalirozhranie PKIClient. Tak je možné použit’ tohto klienta na sledovanie certifikátov v triede KeystoreTrackingManager. 5.4.1 Dogtag REST klient REST klient pre certifikaˇcnýsystém Dogtag používa framework RESTEasy, ktorý zabezpeˇcujekomunikáciu cez REST rozhrania. Knižnica RESTEasy je obsiahnutá priamo v moduloch aplikaˇcnéhoserveru WildFly, takže ju nie je potrebné zvlášt’ dodávat’ k rozšíreniu. Ako už bolo spomenuté v kapi- tole 3.1.2 REST metódy a objekty pre získavanie certifikátov, REST klient vyvolá metódu namapovanú na urˇcitúURL cestu. Certifikaˇcnýsystém Dogtag vráti odpoved’ vo forme XML, ktorú REST klient premení na urˇcitýJava objekt podl’a anotácií nad jeho atribútmi [17]. Metóda listCerts() vracia zoznam všetkých dostupných certifikátov, ktoré sú namapované na strane klienta do tried CertDataInfo. Podl’a týchto in- formácií sú porovnané sledované certifikáty, ˇcinenastala aktualizácia nie- ktorého z nich. Pokial’ bol certifikát aktualizovaný, je zavolaná metóda na získanie jeho kompletnej podoby. 22 5. NÁVRH RIEŠENIA NA SLEDOVANIE CERTIFIKÁTOV Príklad 9: XML reprezentácia objektu CertDataInfo Metóda getCert(id) vracia všetky informácie o konkrétnom certifikáte na základe jeho id. Informácie sú namapované na strane klienta do triedy CertData a obsahujú aj binárnu reprezentáciu certifikátu. Z tejto binárnej podoby trieda DogtagPKIClient vytvorí Java objekt X509Certificate, s ktorým sú úložiská schopné pracovat’. Príklad 10: Binárna podoba certifikátu posielaná v objekte CertData Dogtag REST klient podporuje aj zabezpeˇcenépripojenie k certifikaˇcné- mu systému, ˇcozaist’uje integritu a autenticitu obdržaných certifikátov. Pre využitie bezpeˇcnéhospojenia je potrebné pri vytváraní klienta nastavit’ úlo- žisko s dôveryhodným certifikátom3 certifikaˇcnejautority Dogtag. 3. anglicky truststore 23 6 Implementácia rozšírenia do WildFly Rozšírenie pre správu a sledovanie certifikátov v aplikaˇcnomservery Wild- Fly, ktoré je súˇcast’ou tejto práce, je vytvorené ako samostatný modul. Ked’že tento modul rozširuje funkcionalitu aplikaˇcnéhoserveru, je vhodné zaˇclenit’ jeho konfiguráciu priamo do nastavení serveru. Pokial’ chce urˇcitýmodul byt’ ovládatel’ný pomocou konzolového klienta alebo z XML konfiguraˇc- ných súborov, musí obsahovat’ definíciu jeho vlastného subsystému [18]. 6.1 Maven Apache Maven je nástroj, ktorý ul’ahˇcujetvorbu Java projektov. Maven umož- ˇnujejednoduchú tvorbu projektu a správu jeho závislostí. Konfigurácia pre Maven je uložená v súbore pom.xml, v ktorom je definovaný proces zostavo- vania projektu a závislosti na rôznych knižniciach. Tieto knižnice sú oz- naˇcovanéako artefakty a bývajú prístupné v centrálnych Maven repozitá- roch. Pri zostavovaní projektu sa tieto knižnice stiahnu do lokálneho repo- zitára, odkial’ sú používané v samotnom projekte. Artefakty sú uložené pod urˇcitým groupId (identifikátor skupiny projektu) a articaftId (identi- fikátor konkrétneho projektu z danej skupiny), ktoré jednoznaˇcneidenti- fikujú jednotlivé projekty [19]. Pri vytváraní nového projektu je možné vygenerovat’ základnú štruk- túru projektu pomocou Maven Archetype. Ten preddefinuje urˇcitúkostru projektu, ˇcoumožˇnujeužívatel’om dodržiavat’ správne praktiky pre rôzne typy projektov. Maven Archetype existuje aj pre tvorbu WildFly modulov s vlastnými subsystémami. mvn archetype:generate \ -DarchetypeArtifactId=jboss-as-subsystem \ -DarchetypeGroupId=org.jboss.as.archetypes \ -DarchetypeVersion=7.1.1.Final \ -DarchetypeRepository=http://repository.jboss.org/nexus/ content/groups/public Príklad 11: Vytvorenie nového projektu so základnou štruktúrou Rozšírenie pre sledovanie certifikátov je vytvorené ako Maven projekt vygenerovaný pomocou tohto Maven Archetype. Rozšírenie je identifiko- vatel’né pod oznaˇcením groupId: org.jboss.certificate-tracker, artifactId: certificate-tracker. 24 6. IMPLEMENTÁCIAROZŠÍRENIADO WILDFLY 6.2 Rozhranie Extension Rozhranie org.jboss.as.controller.Extension umožˇnujeintegro- vat’ rozšírenia do jadra aplikaˇcnéhoserveru WildFly. Poˇcasštartu WildFly, pri parsovaní elementov • void initializeParsers(ExtensionParsingContext context) Pri vyvolaní tejto metódy sa inicializujú XML parsery, ktoré sú zod- povedné za naˇcítaniekonfigurácie zo subsystému tohto rozšírenia a registrujú sa do ExtensionParsingContext. • void initialize(ExtensionContext context) V tejto metóde sa registruje do jadra AS model subsystému spolu s operáciami pre jeho ovládanie. Dalejˇ nastavený parser pre ukladanie aktuálnej konfigurácie z pamäti do XML konfiguraˇcnýchsúborov [20]. 6.3 Subsystém certificate-tracker Rozšírenie pre sledovanie certifikátov sa konfiguruje vo vlastnom subsys- téme certificate-tracker. Hlavná trieda zodpovedná za ovládanie tohto subsystému, parsovanie informácií z konfiguraˇcnýchsúborov sa volá CertificateTrackerExtension. Každý WildFly subsystém musí mat’ svoje unikátne meno a byt’ umiestnený v urˇcitomXML mennom priestore. Subsystém certificate-tracker je umiestnený v mennom priestore urn:org.jboss.certificate-tracker:1.0. XML schéma pre sub- systém je súˇcast’ou modulu, aby užívatelia mali prehl’ad o štruktúre mož- ných nastavení subsystému. 25 6. IMPLEMENTÁCIAROZŠÍRENIADO WILDFLY Príklad 12: Subsystém obsahuje konfiguráciu pre úložiská a PKI klienta 6.3.1 Konfigurácia sledovaných úložísk Všetky úložiská, ktoré majú byt’ sledované a synchronizované pomocou PKI klienta je potrebné zaregistrovat’ v subsystéme certificate-tracker. Každé úložisko sa konfiguruje vo vlastnom XML elemente keystore, ktorý je zaregistrovaný pod unikátnym menom: name. Konfigurácia d’alej ob- sahuje povinné a volitel’né atribúty, ktoré bližšie urˇcujújeho nastavenia: • povinný atribút path urˇcujeplne kvalifikovanú systémovú cestu k úložisku. • povinný atribút password urˇcujeheslo k úložisku. • volitel’ný atribút type definuje typ Java úložiska. Predvolený typ je JKS, priˇcompodporované typy sú: JKS, JCEKS a PKCS12. • volitel’ný atribút aliases je zoznam aliasov pre certifikáty, ktoré majú byt’ sledované. Pokial’ atribút nie je zadaný, sú sledované všetky dostupné certifikáty v úložisku. Nastavenia je možné pridat’ úpravou XML konfiguraˇcnéhosúboru ap- likaˇcnéhoserveru WildFly. Keystore elementy sa pridávajú do rodiˇcovského elementu keystores vnútri subsystému certificate-tracker: Príklad 13: Konfigurácia sledovaných úložísk 26 6. IMPLEMENTÁCIAROZŠÍRENIADO WILDFLY Odporúˇcanýmspôsobom je však konfigurácia pomocou CLI klienta, ktorý operáciu validuje, prípadne poskytne nápovedu. /subsystem=certificate-tracker/keystore=host1:add(path="host1.jks", password="secret",aliases="host1,server,client") Príklad 14: Pridanie úložiska pomocou CLI klienta 6.3.2 Konfigurácia PKI klienta Rozšírenie pre sledovanie certifikátov umožˇnujepoužit’ l’ubovol’ného PKI klienta, ktorý bude certifikáty synchronizovat’ s urˇcitýmcertifikaˇcnýmsys- témom. Trieda PKI klienta musí implementovat’ rozhranie PKIClient. Sú- ˇcast’ou tejto práce je PKI klient pre certifikaˇcnýsystém Dogtag, ktorý má pre jednoduchšie ovládanie prednastavené meno Dogtag. Pri použití iného klienta je potrebné uviest’ úplné meno triedy a modulu pomocou atribútov v nastaveniach PKI klienta: • povinný atribút name urˇcujeúplné kvalifikované meno triedy, ktorá bude použitá ako PKI klient. • volitel’ný atribút module urˇcujeúplné meno modulu, v ktorom sa nachádza trieda pre PKI klienta. Pokial’ tento atribút nie je nastavený, trieda sa hl’adá v module certificate-tracker. • volitel’ný atribút time-interval definuje ˇcasovýinterval, v ktorom bude PKI klient kontrolovat’ zoznam certifikátov. Predvolená hod- nota je 600000 milisekúnd (10 min). Dalejˇ konfigurácia obsahuje volitel’né nastavenia client-options, po- mocou ktorých sa dá prispôsobit’ konfigurácia PKI klienta. Tieto nastavenia sú vo forme kl’úˇc/hodnota.Pri použití prednastaveného DogtagPKIClient klienta sa používajú tieto nastavenia: • povinný atribút url urˇcujewebovú adresu certifikaˇcnéhosystému, odkial’ bude PKI klient získavat’ aktuálne certifikáty. • volitel’ný atribút truststore-name umožˇnujenastavit’ úložisko s overeným certifikátom certifikaˇcnéhosystému. Túto možnost’ je nutné nastavit’, pokial’ PKI klient využíva zabezpeˇcenépripojenie. 27 6. IMPLEMENTÁCIAROZŠÍRENIADO WILDFLY Nastavenia je opät’ možné upravit’ v XML konfiguraˇcnomsúbore v ele- mente pki-client alebo pomocou CLI klienta: Príklad 15: Konfigurácia Dogtag PKI klienta /subsystem=certificate-tracker/pki-client=Dogtag:add( time-interval="1000", client-options={ "url"=>https://example.com/ca/rest","truststore-name"=>"host1"} Príklad 16: Pridanie Dogtag PKI klienta pomocou CLI 6.3.3 Podpora premenných v konfigurácii WildFly ponúka rôzne premenné prostredia, ktoré možno použit’ pre zjed- nodušenie konfigurácie v subsystéme. Pre nastavenie systémovej cesty v konfigurácii úložiska možno využit’ prednastavené premenné. Pokial’ sa úložisko nachádza v adresári aplikaˇcnéhoserveru sú k dispozícií napríklad tieto premenné: Názov premennej Požitie Predvolená hodnota jboss.home.dir Koreˇnovýadresár WildFly premenná JBOSS_HOME jboss.server.base.dir Adresár obsahujúci server jboss.home.dir/standalone jboss.server.config.dir Konfiguraˇcnýadresár jboss.server.base.dir/config Premenné sa dajú použit’ pre nastavenie atribútov pri práci s konzolovým klientom, alebo priamo v XML konfiguraˇcnýchsúboroch. Aby boli pre- menné správne rozoznané musia byt’ umiestnené do zložených zátvoriek s úvodným znakom $ [21]. Príklad 17: Úložisko umiestnené v konfiguraˇcnomsúbore serveru 28 6. IMPLEMENTÁCIAROZŠÍRENIADO WILDFLY WildFly taktiež obsahuje nástoj Vault pre zabezpeˇceniehesiel v kon- figurácii. Heslá, ktoré sú v ˇnomuložené môžu byt’ odkazované pomocou premennej a preto nie sú vol’ne vyˇcítatel’né z konfigurácie serveru. Tieto heslá sú získané z Vaultu až pri parsovaní konfigurácie. Rozšírenie pre sle- dovanie certifikátov tiež podporuje použitie tohto Vaultu. Vhodným použi- tím je napríklad zabezpeˇceniehesiel k úložiskám. Príklad 18: Použite Vaultu pre ochranu hesiel k úložiskám 6.4 Štruktúra modelu subsystému Pre použitie vlastného subsystému v aplikaˇcnomservery WildFly je pot- rebné zaregistrovat’ jeho model. Model subsystému je definícia príslušných zdrojov spolu s ich atribútmi, ktorá zodpovedá podobe subsystému v XML. Model obsahuje operácie, pomocou ktorých je možné ovládat’ samotný sub- systém. Taktiež môže mat’ pod sebou zaregistrované d’alšie submodely a vytvorit’ tak hierarchickú štruktúru ako v XML. Trieda, ktorá reprezentuje model subsystému musí implementovat’ roz- hranie ResourceDefinition. V subsystéme certificate-tracker je koreˇnovoutriedou definujúcou subsystém CertificateTrackerDefi- nition. Tá registruje operácie pre pridanie a odobranie prázdneho subsys- tému. Pre konfiguráciu úložísk a PKI klienta koreˇnovátrieda d’alej obsahuje dva submodely: • KeystoreDefinition je submodel, ktorý definuje atribúty a operá- cie pre nastavenie úložiska • PKIClientDefinition je submodel, ktorý definuje atribúty a ope- rácie pre nastavenie PKI klienta Tieto submodely registrujú operácie pre pridanie, odobranie a zmenu jednotlivých atribútov. Operácie sú schopné získat’ a menit’ aktuálnu kon- figuráciu, priˇcomzmeny sa prejavia v nastavení samotných služieb ap- likaˇcnéhoserveru. Vytvorené rozšírenie obsahuje službu pre sledovanie cer- tifikátov, ktorá je nastavitel’ná pomocou práve týchto dvoch submodelov. 29 6. IMPLEMENTÁCIAROZŠÍRENIADO WILDFLY 6.5 Služba pre sledovanie certifikátov Aplikaˇcnýserver WildFly sa skladá z množstva služieb, z ktorých každá zabezpeˇcujeurˇcitúfunkcionalitu. Tieto služby musia implementovat’ roz- hranie org.jboss.msc.service.Service, ktoré predpisuje metódy na spustenie a zastavenie služieb. Pri vytváraní je potrebné službu zaregistro- vat’ do kontroleru pre služby serveru. V rozšírení certificate-tracker je pre úˇcelsledovania certifikátov implementovaná služba Certificate- TrackingService. Táto služba sa vytvorí a aktivuje pri pridaní konfigu- rácie pre PKI klienta. Pomocou naˇcítanejkonfigurácie zo subsystému nas- taví triedu KeystoresTrackingManager a v pravidelných intervaloch používa metódu pre kontrolu nových certifikátov. 6.5.1 Kontrola certifikátov Kontrola certifikátov prebieha v triede KeystoresTrackingManager, kto- rá kontroluje certifikáty v zaregistrovaných úložiskách oproti aktuálnym certifikátom z certifikaˇcnéhosystému. Certifikát je aktualizovaný na zák- lade prijatých informácií, pokial’ sp´lˇnavšetky kritériá uvedené v kapitole 5.2 Trieda KeystoreTrackingManager. Pre prijímanie informácií a posielanie požiadaviek na certifikaˇcnýsys- tém musí byt’ PKI klient inicializovaný. Rozhranie PKIClient preto pred- pisuje metódu, ktorá je používaná v triede KeystoresTrackingManager pre vytvorenie klienta. Súˇcast’ou vytvoreného modulu pre správu certifiká- tov je klient DogtagPKIClient, ktorý synchronizuje certifikáty so správ- com identít FreeIPA. Rozšírenie umožˇnujepoužit’ vlastného PKI klienta pre l’ubovol’ný certifikaˇcnýsystém. Trieda PKI klienta je naˇcítanápomocou classloaderu zo zadaného modulu nachádzajúceho sa v aplikaˇcnomservery a následne je inicializovaná. PKI klient podl’a prijatých informácií o certifikátoch z certifikaˇcného systému vyhodnotí podmienky, ˇcibol niektorý zo sledovaných certifikátov aktualizovaný. Pokial’ sú podmienky splnené, PKI klient pošle požiadavku na kompletný certifikát v binárnej podobe. Z neho následne vytvorí triedu X509Certificate, s ktorou je úložisko schopné pracovat’. 6.5.2 Použitie obnovených certifikátov Po výmene certifikátov je potrebné úložisko naˇcítanév pamäti uložit’ spät’ do súborového systému. WildFly takéto zmeny však nevie detegovat’ a momentálne neobsahuje ani operáciu, ktorá by umožˇnovalaznovu naˇcí- 30 6. IMPLEMENTÁCIAROZŠÍRENIADO WILDFLY tat’ zmenené úložiská. Rozšírenie pre sledovanie certifikátov dokáže pri výmene certifikátu automaticky vyvolat’ naˇcítanieúložísk, a to bez potreb- ného reštartu celého aplikaˇcnéhoserveru. Pre opätovné naˇcítanieúložísk je nutné znovu inicializovat’ jednotlivé služby, ktoré dané úložiská používajú. Nato používa rozšírenie interného manažment klienta, ktorého si vytvorí ako pomocnú službu. V prvom kroku rozšírenie skontroluje, ˇciniektorá z bezpeˇcnostnýchslužieb(security-domain, security-realm) používajú jedno zo sledovaných úložísk. Pokial’ je v sledo- vanom úložisku zmenený certifikát, tak je pomocou interného manažment klienta vyvolané naˇcítanietohto úložiska. Tento prístup má viacero výhod oproti klasickému reštartu celého serve- ru. Rýchlost’ inicializácie jednotlivých služieb sa pohybuje rádovo v milise- kundách. Pri zmene certifikátov v úložisku, ktoré používa urˇcitáaplikácia zostávajú informácie uložené v relácii. Užívatel’ sa tak nemusí opätovne prihlasovat’ a aplikácia je neprístupná iba minimálnu dobu. 6.6 Dalšíˇ vývoj rozšírenia Rozšírenie pre sledovanie certifikátov má perspektívu pre d’alší vývoj, ktorý je z ˇcastiviazaný na nové funkcie v použitých technológiách. V budúcej verzii WildFly má byt’ dostupná operácia pre znovu naˇcítanie úložísk v urˇcenýchbezpeˇcnostnýchslužbách serveru. Preto pri d’alšom vývoji rozšírenia by bolo vhodné zmenit’ spôsob, akým je uskutoˇcnenénaˇcí- tanie zmenených úložísk a použit’ pre tieto úˇcelynovú operáciu. Dalšouˇ zaujímavou funkciou by bolo pridat’ spojenie, ktoré by umožˇno- valo pasívne ˇcakat’ na oznámenie certifikaˇcnéhosystému o zmene certifiká- tov. Tým by odpadla nutnost’ v pravidelných intervaloch kontrolovat’ stav na certifikaˇcnomsystéme. V certifikaˇcnomsystéme Dogtag je plánované vytvorit’ samostatnú kniž- nicu, ktorá by zjednodušila vytváranie REST klientov k tomuto systému. V súˇcasnostivšak táto knižnica stále nie je dostupná a preto je v rozšírení implementovaný jednoduchý REST klient so základnými funkciami. Pri použití oficiálnej knižnice je možné rozšírit’ funkcionalitu, ktorú poskytuje riešenie pre správu certifikátov. Napríklad pri detekcii konˇciacejplatnosti sledovaného certifikátu, by rozšírenie vedelo zadat’ požiadavku v certi- fikaˇcnomsystéme o jeho pred´lženie. 31 7 Záver Táto bakalárska práca sa zaoberala vývojom rožšírenia pre aplikaˇcnýserver WildFly, ktoré je schopné sledovat’ a aktualizovat’ používané SSL certi- fikáty. Tieto certifikáty sú synchronizované s certifikaˇcnýmsystémom Dog- tag, ktorý je súˇcast’ou komplexného riešenia pre správu identít FreeIPA. Prvá ˇcast’ práce obsahuje analýzu a popis REST rozhrania pre správu a distribúciu certifikátov v certifikaˇcnomsystéme Dogtag. Pre toto REST roz- hranie bol vyvinutý klient, ktorý vie získat’ zoznam aktuálnych certifikátov a jednotlivo aj kompletné certifikáty. Aplikaˇcnýserver WildFly umožˇnujeprevádzkovat’ aplikácie s podporou zabezpeˇcenejkomunikácie pomocou protokolov SSL alebo TLS. Použité certifikáty a kl’úˇcesú pri štarte serveru naˇcítanéz kryptografického úložiska. Aplikaˇcnýserver poˇcasbehu ale nevie detegovat’ a reagovat’ na zmeny cer- tifikátov v úložiskách. Jedinou súˇcasnoumožnost’ou je reštart serveru, ˇco predstavuje obmedzenie dostupnosti nasadených aplikácií. Tento problém bolo možné vyriešit’ implementovaním služby do vytvoreného rozšírenia, ktorá pri zmene certifikátov vyvolá opätovné naˇcítanieúložísk. Rozšírenie pre správu certifikátov bolo úspešne implementované ako samostatný modul aplikaˇcnéhoserveru a jeho nastavenia sú priamo inte- grované v konfigurácii WildFly. To je dosiahnuté pomocou vlastného sub- systému, v ktorom sa ovládajú služby rozšírenia. V module je zaˇclenený vyvinutý REST klient pre certifikaˇcnýsystém Dogtag, priˇcomale rozšírenie umožˇnujepoužit’ l’ubovol’ného klienta. Toto prináša možnost’ implemen- tovat’ si vlastného klienta pre akýkol’vek certifikaˇcnýsystém za použitia všeobecného rozhrania. Hlavnými prednost’ami rozšírenia pre správu certifikátov je možnost’ použit’ obnovené aktualizované certifikáty bez reštartu aplikaˇcnéhoserveru. Administrátorom taktiež odpadá povinnost’ sledovat’ a manuálne kopíro- vat’ certifikáty z certifikaˇcnéhosystému. Rozšírenie má potenciál pre d’alší vývoj, napríklad rozšírením jeho funkcií alebo pridaním klientov pre d’alšie certifikaˇcnésystémy. Zdrojové kódy rozšírenia sú dostupné pod licenciou GNU LGPL, priˇcomaktuálna verzia v ˇcaseodovzdania práce bola 1.0. 32 A Použitie rozšírenia v aplikaˇcnomserveri WildFly Rozšírenie pre správu certifikátov je vyvinuté ako Maven projekt, ktorý po skompilovaní vytvorí modul použitel’ný v aplikaˇcnomserveri WildFly. Nasledujúci návod slúži ako ukážka pre vytvorenie, pridanie a použitie rozšírenia v aplikaˇcnomserveri. Návod je urˇcenýpre distribúcie operaˇc- ného systému Linux, priˇcomvšetky príkazy je nutné písat’ na jeden riadok. 1. Získanie rozšírenia certificate-tracker Rozšírenie pre správu certifikátov je možné získat’ nasledujúcimi spô- sobmi: a. stiahnutie z GitHub repozitára Tento krok predpokladá nainštalovaný nástroj Git. Následne staˇcí zavolat’ príkaz, ktorý stiahne rozšírenie do aktuálneho adresára: git clone https://github.com/fbogyai/certificate-tracker b. stiahnutie z archívu závereˇcnejpráce Rozšírenie je uložené ako príloha v archíve závereˇcnejpráce. Staˇcí stiahnut’ a rozbalit’ ZIP archív s názvom certificate-tracker. 2. Vytvorenie modulu certificate-tracker Tento krok predpokladá nainštalovaný nástroj Apache Maven. Naj- skôr je nutné presunút’ sa do adresára, v ktorom je rozšírenie uložené: cd certificate-tracker Pre skompilovanie a vytvorenie modulu je potrebné zavolat’ príkaz: mvn clean install Pokial’ zostavenie projektu prebehlo úspešne, tak výsledný vytvorený modul je v adresári target/module. 3. Stiahnutie aplikaˇcnéhoserveru WildFly Aplikaˇcnýserver WildFly je vol’ne dostupný na stránkach projektu: http://wildfly.org/downloads/. V tejto práci bola používaná verzia WildFly 8.0.0.Final. Po stiahnutí a rozbalení ZIP archívu s dis- tribúciou serveru je WildFly pripravený na použitie. 33 A.POUŽITIEROZŠÍRENIAVAPLIKACNOMSERVERIˇ WILDFLY 4. Pridanie modulu do WildFly Pre pridanie modulu do WildFly staˇcískopírovat’ vytvorený modul medzi moduly aplikaˇcnéhoservera. cp -R target/module/* $JBOSS_HOME/modules Premenná $JBOSS_HOME urˇcujeadresár, v ktorom je umiestnený ap- likaˇcnýserver WildFly. 5. Pridanie rozšírenia do konfigurácie WildFly Najkôr je nutné aplikaˇcnýserver naštartovat’: ./$JBOSS_HOME/bin/standalone.sh Pre konfiguráciu serveru spustíme konzolového klienta: ./$JBOSS_HOME/bin/jboss-cli.sh -c Následne pridáme rozšírenie certificate-tracker: /extension=org.jboss.certificate-tracker:add( module=org.jboss.certificate-tracker) Pridáme subsystém, v ktorom sa rozšírenie nastavuje: /subsystem=certificate-tracker:add() 6. Nastavenie rozšírenia Pomocou konzolového klienta je možné rozšírenie ovládat’ a konfigu- rovat’. a. Konfigurácia spravovaných úložísk Úložisko, ktoré má byt’ sledované, je možné pridat’ nasledujúcim spôsobom: /subsystem=certificate-tracker/keystore=example:add( path=$JBOSS_HOME/example.jks,password=secret) b. Konfigurácia PKI klienta PKI klient, ktorý bude synchronizovat’ certifikáty s certifikaˇcným systémom Dogtag, sa pridá nasledovne: /subsystem=certificate-tracker/pki-client=Dogtag:add( client-options={url=>http://example.com/ca/rest/}) 34 Literatúra [1] OAKS, Scott. Java security. 1st ed. Sebastopol: O’Reilly, c1998, xv, 454 p. ISBN 15-659-2403-7. [2] MENEZES, Alfred J. Handbook of applied cryptography. Vyd. 1. CRC Press, 1997, 780 s. ISBN 08-493-8523-7. [3] DOSTÁLEK, Libor a Marta VOHNOUTOVÁ. Velký pr˚uvodceinfrastruk- turou PKI a technologií elektronického podpisu. Vyd. 1. Brno: Computer Press, 2006, 534 s. ISBN 80-251-0828-7. [4] HOUSLEY, R., POLK, W., FORD, W., SOLO, D. RFC 3280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [online]. 2002. [cit. 2014-03-17]. Dostupné z: http://tools. ietf.org/html/rfc3280 [5] LACKEY, Ella Deon. FreeIPA: Identity/Policy Management. Fedora Project [online], Red Hat, 2012. [cit. 2013-11-12]. Edition 3.1.5. Dos- tupné z: http://docs.fedoraproject.org/en-US/Fedora/ 18/html/FreeIPA_Guide/index.html [6] Dogtag Certificate System - Documentation. Fedora Project [on- line]. 12.3.2013 [cit. 2014-03-17]. Dostupné z: http://pki. fedoraproject.org/wiki/PKI_Documentation [7] Dogtag Certificate System - RESTEasy. Fedora Project [online]. 13.1.2014 [cit. 2014-03-17]. Dostupné z: http://pki.fedoraproject.org/ wiki/RESTEasy [8] Dogtag Certificate System - REST. Fedora Project [online]. 12.3.2013 [cit. 2014-03-17]. Dostupné z: http://pki.fedoraproject.org/ wiki/REST [9] Java EE FAQ. Oracle [online]. [cit. 2014-03-21]. Dostupné z: http://www.oracle.com/technetwork/java/javaee/ javaee-faq-jsp-135209.html [10] About - WildFly. WildFly [online]. [cit. 2014-03-21]. Dostupné z: http: //wildfly.org/about/ [11] Developer Guide. WildFly [online]. [cit. 2014-03-21]. Dostupné z: https://docs.jboss.org/author/display/WFLY8/ Developer+Guide 35 A.POUŽITIEROZŠÍRENIAVAPLIKACNOMSERVERIˇ WILDFLY [12] Admin Guide. WildFly [online]. [cit. 2014-03-21]. Dostupné z: https: //docs.jboss.org/author/display/WFLY8/Admin+Guide [13] Introduction to Java EE. Chess-iX [online]. [cit. 2014-03- 21]. Dostupné z: http://www.chess-ix.com/blog/ java-ee-6-an-introduction-part-2/ [14] Undertow subsystem configuration. WildFly [online]. [cit. 2014-03- 23]. Dostupné z: https://docs.jboss.org/author/display/ WFLY8/Undertow+(web)+subsystem+configuration [15] Authentication Modules. WildFly [online]. [cit. 2014-03-23]. Dos- tupné z: https://docs.jboss.org/author/display/WFLY8/ Authentication+Modules [16] KeyStore. Oracle [online]. [cit. 2014-03-25]. Dostupné z: http: //docs.oracle.com/javase/7/docs/api/java/security/ KeyStore.html [17] RestEasy Documentation. JBoss Community [online]. [cit. 2014-03-30]. Dostupné z: https://docs.jboss.org/resteasy/docs/3.0. 6.Final/userguide/html_single/ [18] Extending WildFly 8. WildFly [online]. [cit. 2014-03-30]. Dos- tupné z: https://docs.jboss.org/author/display/WFLY8/ Extending+WildFly+8 [19] Maven. Apache Maven [online]. [cit. 2014-04-13]. Dostupné z: http: //maven.apache.org/ [20] Key Interfaces and Classes Relevant to Extension Developers. WildFly [online]. [cit. 2014-04-10]. Dostupné z: https://docs.jboss.org/ author/display/WFLY8/Key+Interfaces+and+Classes+ Relevant+to+Extension+Developers [21] Command line parameters. WildFly [online]. [cit. 2014-03-31]. Dos- tupné z: https://docs.jboss.org/author/display/WFLY8/ Command+line+parameters 36
Správa SSL Certifikátov V Aplikaˇcnom Serveri Wildfly
