Pokročilá autentizace v Java aplikacích pomocí protokolu Kerberos

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Pokročilá autentizace v Java aplikacích pomocí protokolu Kerberos BAKALÁŘSKÁ PRÁCE Adam Navrátil Brno, 2011

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

Poděkování Rád bych poděkovat Mgr. Pavlu Tučkovi za trpělivost, ochotu a cenné rady poskytované při vytváření práce. Dále bych chtěl poděkovat všem, kteří mě podporovali a motivovali k jejímu dokončení.

Shrnutí Bakalářská práce se zabývá autentizací uživatele ve webové Java aplikaci, běžící na Apache Tomcat. Tato aplikace si vyžádá od uživatele jeho přihlašovací údaje, které poté ověří pomocí autentizačního protokolu Kerberos proti Microsoft Active Directory. Práce popisuje instalaci a konfiguraci Apache Tomcat, průběh autentizace pomocí Java Authentication and Authorization Service a jakým způsobem je v ní možné se autentizovat pomocí Kerberos protokolu. Součástí je také popis zkušební aplikace a nastavení Apache Tomcat pro komunikaci pomocí protokolu SSL. Druhá část se zabývá instalací a konfigurací technologie Shibboleth pro tentýž účel.

Klíčová slova Java, Apache Tomcat, Kerberos, Shibboleth, JAAS, Active Directory

Obsah Úvod...2 1 Základní technologie...3 1.1 Active Directory a protokol Kerberos...3 1.2 Autentizace v jazyce Java...5 1.3 Apache Tomcat...6 2 Přihlašovací modul...8 2.1 Průběh autentizace z pohledu přihlašovacího modulu...8 2.2 Načtení přihlašovacího modulu...9 2.3 Přihlašovací modul pro Kerberos...10 3 Konfigurace Apache Tomcat...12 3.1 Tomcat Realms...12 3.1.1 Konfigurace realmu...12 3.2 Zabezpečení komunikace...13 3.2.1 Vytvoření certifikátu...13 3.2.2 Nastavení HTTPS protokolu v Apache Tomcat...14 4 Zkušební aplikace...16 4.1 Konfigurace aplikace...17 4.2 Vyzkoušení aplikace...18 4.3 Vytvoření vylepšeného modulu...19 5 Shibboleth...21 5.1 Popis autentizace uživatele pomocí Shibbolethu...22 5.2 Metadata...23 5.3 Poskytovatel identit...24 5.3.1 Komunikace s poskytovatelem služeb...24 5.3.2 Konfigurace autentizace...25 5.3.3 Atributy...26 5.4 Poskytovatel služeb...26 5.4.1 Instalace SP a jeho integrace s Apache HTTP serverem...27 5.4.2 Konfigurace SP...28 5.4.3 Nastavení atributů...28 5.5 Vyzkoušení autentizace...28 Závěr...29 Literatura...30 Dodatek A...A Dodatek B...B Dodatek C...C

Úvod Zabezpečení stránek na internetu a zpřístupnění jejich obsahu pouze určité skupině lidí patří dnes již k běžným věcem. Rozhodnutí, zda uživatel má ke chráněné stránce přístup, předchází rozpoznání uživatele a ověření, zda je skutečně tím, za koho se vydává. Tomuto procesu se říká autentizace. Autentizace může probíhat různými způsoby, například podle otisků prstů, rozpoznáním tvaru ruky, oční duhovky, nebo třeba kombinací jména a hesla. Poslední jmenovaný způsob je na internetu nejrozšířenější metodou autentizace uživatele. Tato metoda si vyžádá od uživatele jméno a heslo, které se poté odešle na server a ověří se podle databáze uživatelů. Základními složkami takovéto autentizace je webová aplikace běžící na serveru, zajišťujícím komunikaci pomocí protokolu HTTP, a databáze uživatelů, kteří mají přístup ke chráněnému obsahu, a jejich hesel. Tyto prvky se dají realizovat různými technologiemi. Tato práce se zabývá popisem autentizace, ve které je databáze uživatelů adresářová služba Microsoft Active Directory a webová aplikace běží na Apache Tomcat. Jelikož je třeba, aby se aplikace dokázala autentizovat proti Active Directory k ověření údajů, které jí uživatel poskytne, použije se pro tento účel protokol Kerberos. Těmto technologiím a jejich základnímu popisu se věnuje první kapitola. Další kapitola je zaměřena na přihlašovací moduly, jenž jsou jedním ze základních prvků autentizačního procesu v Java Aplikacích, zvláštní pozornost je věnována popisu přihlašovacího modul pro protokol Kerberos. Po popsání nastavení všech prvků, které se autentizace zúčastní, bude autentizace vyzkoušena ve zkušební aplikaci. Ta bude využívat autentizaci přímo na straně serveru, a aby byla komunikace mezi uživatelem a serverem zabezpečena, bude komunikace probíhat pomocí protokolu HTTPS. Další částí práce je popis stejné autentizace pomocí technologie Shibboleth, konkrétně nastavení poskytovatele identit (IdP) a poskytovatele služeb (SP) a jejich komunikaci mezi sebou. Poskytovatel identit bude využívat k autentizaci uživatele již zmíněný přihlašovací modul pro Kerberos a poskytovatel služeb bude chránit stránky běžící na webovém serveru Apache. 2

Kapitola 1 Základní technologie 1.1 Active Directory a protokol Kerberos Jednou z hojně používaných adresářových služeb v dnešní době je Microsoft Active Directory (dále jen AD). Tato služba se používá na stanicích s operačním systémem Microsoft Windows a je dostupná od verze Windows Server 2000. Všechny verze dokáží autentizovat uživatele pomocí protokolu Kerberos. Kerberos slouží k autentizaci uživatele v nezabezpečené síti a umožňuje tuto autentizaci bezpečně předat někomu jinému. Byl vyvinut na Massachusetts Institute of Technology jako součást projektu Athena a v první verzi vydán jako Kerberos v4. Vylepšený Kerberos v5 byl vydán jako RFC 1510 v roce 1993 (později RFC 4120 v roce 2005) a odstraňuje nedostatky a zabezpečovací problémy předchozí verze. Je založen na symetrické kryptografii a potřebuje důvěryhodnou třetí stranu, označovanou jako KDC (Key Distribution Center). [1] KDC se skládá ze dvou částí: AS (Authentication service) a TGS (Ticket-granting service). Ve Windows Server 2003 a 2008 R2 je KDC implementován jako doménová služba na každém doménovém řadiči. Používá doménu Active Directory jako jeho databázi účtů a informace o uživatelích získává z globálních katalogů. AS ověřuje uživatele a vydává TGT (Ticket-granting ticket), TGS slouží k vydávání služebního tiketu (service ticket). V následující tabulce jsou vypsány položky, které tiket obsahuje. První tři položky jsou v prostém textu, zbylé jsou zašifrovány pomocí tajného klíče, který zná pouze KDC a služby. Poslední dvě jsou nepovinné. Ticket Version Number 5 Realm Server name Flags Key Client realm Client name Transited Authentication Time Start Time End Time Client Address Jméno realmu (domény), která tiket vydala. Jméno serveru. Popis jak a kde je možné tiket využít. Relační klíč sloužící k šifrování zpráv mezi službou a klientem. Jméno klientova realmu. Klientovo jméno. Kerberos realmy obsahující část klientovi autentizace během crossrealm autentizace. Čas, kdy byl klient autentizován. Čas, od kterého je tiket platný. Čas, kdy tiket vyprší. Jedna, nebo více adres, z které může být tiket použit. 3

ZÁKLADNÍ TECHNOLOGIE Authorization-Data Obsahuje autorizační data klienta. Autentizace probíhá následovně: klient vyšle požadavek na autentizaci do AS (KRB_AS_REQ). V případě, že je autentizace úspěšná, vygeneruje AS dvě kopie relačního klíče (session key) určené ke komunikaci mezi klientem a KDC. Jednu kopii zašifruje klíčem vytvořeným z uživatelova hesla a druhou kopii klíčem, který zná pouze KDC. Tuto druhou kopii (šifrovanou KDC klíčem) vloží do TGT a pošle ho spolu s první kopií jako odpověď klientovi (KRB_AS_REP). Klient si obě uloží do cache paměti. V tuto chvíli je klient autentizován. Relační klíč získaný od KDC slouží k šifrování komunikace, probíhající mezi klientem a službami nebo KDC. Je unikátní pro každou službu a jeho životnost je tak dlouhá, dokud je platný tiket, ve kterém je uložen. Aby klient získal přístup k síťové službě, musí mít služební tiket dané služby. Ten získá od TGS pomocí požadavku na tento tiket (KRB_TGS_REQ). Spolu s požadavkem se odesílá i TGT a autentizátor (anglicky authenticator). Autentizátor slouží k ověření, že daný tiket byl odeslán skutečně tím, kdo jej odeslal. Je zašifrován pomocí relačního klíče a posílá se s každým tiketem. Obsahuje mimo jiné i časové razítko, a když doba doručení překročí stanovenou hranici, je spolu s tiketem zahozen. Proto je důležité, aby byl na účastněných strojích vždy stejný čas, jinak se autentizace nezdaří a Kerberos nebude fungovat. Když je požadavek platný, tak TGS vygeneruje relační klíč sloužící pro komunikaci mezi klientem a danou službou. Ten pošle klientovi jako odpověď (KRB_TGS_REP) opět ve dvou kopiích. První je určená klientovi a je šifrována pomocí relačního klíče sdíleným mezi klientem a KDC. Druhá je uvnitř služebního tiketu. Obě kopie si klient uloží do cache paměti a používá je ke komunikaci s danou službou. Obr. 1.1: Komunikace klienta s KDC a službou. 4

ZÁKLADNÍ TECHNOLOGIE Přístup ke službě získá uživatel tak, že pošle dané službě služební tiket a autentizátor. Služba dešifruje služební tiket, získá relační klíč, který sdílí s klientem a pomocí kterého dešifruje autentizátor a ověří uživatele. [2] Klientovo heslo se tedy použije jenom jednou při úvodním přihlášení, další komunikace je šifrována pomocí vygenerovaných relačních klíčů. Velkou výhodou je, že si server nemusí pamatovat tyto relační klíče po celou dobu jejich platnosti. Při požadavku na komunikaci mu ho pošle klient uvnitř TGT, nebo služebního tiketu, které má uloženy v cache paměti. Služební tiket a TGT nemají omezený počet použití, mají ovšem určitou dobu platnosti. Stačí tedy, aby si je klient při každém přístupu k dané službě vytáhl z cache paměti. Ta záleží na nastavení daného systému, v RFC je doporučeno maximálně 1 den, v Kerberos v5 i ve Windows Server 2003 a 2008 R2 je standardně nastaveno 10 hodin nebo dokud se uživatel neodhlásí. Doba platnosti TGT může být prodlužována, takže se relační klíč periodicky obnovuje bez vydání nového tiketu. Když je obnovování povoleno, přidává se do TGT druhý časový limit, který zahrnuje i obnovovací časy, které se sčítají, ty po dosažení určité hranice již obnovit nejde. [3] 1.2 Autentizace v jazyce Java K autentizaci uživatelů na platformě Java Standart Edition (J2SE) 1 slouží Java Authentication and Autorization Service (JAAS). JAAS je navrhnuta tak, že se autentizace (a autorizace) provádí mimo hlavní kód aplikace, díky čemuž je možné lehce vylepšit nebo vyměnit používané autentizační technologie za jiné beze změn v samotné aplikaci. Základními prvky v JAAS jsou: Principal objekt představující identitu přihlášeného uživatele nebo stroje. Credentials bezpečnostní prvky použité při autentizaci. Mohou to být například kryptografické klíče, Kerberos tiket a jiné. Subject množina, do které se při úspěšné autentizaci vloží Principal a Credentials. Přihlašovací modul třída zajištující samotnou autentizaci. Klasické přihlašovací moduly ověřují uživatelská jména a hesla, jiné mohou ověřovat například hlas nebo otisky prstů. Přihlašovacímu modulu se věnuje druhá kapitola. Celý systém autentizace probíhá následovně: [4] 1) Při spuštění autentizačního procesu se vytvoří objekt LoginContext, ten načte přihlašovací moduly, které se mají podle konfigurace použít pro autentizaci uživatele. 2) Zavolá se metoda login() na objektu LoginContext, která se pokusí autentizovat uživatele pomocí všech načtených přihlašovacích modulů. 1 http://www.oracle.com/technetwork/java/javase/overview/index.html 5

ZÁKLADNÍ TECHNOLOGIE 3) Pokud autentizace proběhne úspěšně, přidá každý modul do Subject údaje o autentizovaném uživateli (Principal) a prvky použité při autentizaci (Credentials). 4) LoginContext poté oznámí aplikaci, zda se uživatel správně autentizoval a v případě úspěchu předá aplikaci Subject s údaji. 1.3 Apache Tomcat Základní prvek webové Java aplikace je Java servlet. Je to třída v Java Enterprise Edition (J2EE), popsaná ve specifikaci Java Servlet API 2. Servlet je navržen pro používání protokolů pracujících stylem požadavek-odpověď, ale jedinou rozšířenou implementací je pouze HTTP servlet pro obsluhu protokolu HTTP. Každý servlet potřebuje ke svému chodu prostředí, zajišťující komunikaci s okolím, předávající mu HTTP požadavky a přijímající odpovědi. Toto prostředí se označuje jako servlet kontejner a jedním z nich je Apache Tomcat 3. Je to open source servlet kontejner vyvíjený společností Apache Software Foundation. Životní cyklus servletu začíná načtením třídy servletu z webového kontejneru a vytvořením jeho instance. Předtím, než servlet přijme jakékoliv požadavky, nastaví své počáteční hodnoty zavoláním metody init(). Servlet poté obslouží klientovi požadavky, přičemž je každý požadavek obsloužen v samostatném vlákně. Nakonec je zavolána metoda destroy(), která servlet ukončí. Obr. 1.2: Životní cyklus servletu. 2 http://jcp.org/aboutjava/communityprocess/mrel/jsr154/index.html 3 http://tomcat.apache.org/ 6

ZÁKLADNÍ TECHNOLOGIE Protože vývoj aplikací pomocí servletů není nejrychlejší, byly vyvinuty Java Server Pages (JSP). Ty jsou vytvořeny k rychlejšímu a snadnějšímu vývoji dynamického obsahu, než jaký poskytují servlety. Kontejner převede každou JSP stránku na servlet a ten se poté vykoná běžným způsobem. V systému Windows se Tomcat instaluje jednoduchým instalátorem do vybrané složky. Tuto složku budu označovat při popisu cest jako Tomcat_home. Důležitým údajem je při instalaci port, na kterém bude naslouchat, obvykle to je 8080. Tomcat sám je Java aplikace, potřebuje tudíž ke svému chodu Java Virtual Machine (JVM). Běží ve Windows jako služba na pozadí a pro jeho správu slouží Tomcat Monitor. Ten umožňuje Tomcat lehce spustit, zastavit nebo určit cestu k JVM. Nastavují se v něm také konfigurační parametry, se kterými je Tomcat spuštěn. Parametry jsou specifikovány v poli Java Options na záložce start. 7

Kapitola 2 Přihlašovací modul Přihlašovací modul (anglicky LoginModule) je Java třída implementující rozhraní javax.security.auth.spi.loginmodule. Jeho úkolem je ověřit, zda uživatel (případně počítač) zadal správné přihlašovací údaje, oznámit výsledek a přidat přihlašovací údaje do Subjekt. Jak je popsáno v kapitole 1.2, přihlašovací modul je načítán pomocí třídy LoginContext, která řídí celou autentizaci. Při jedné autentizaci se může využít jeden nebo i více modulů, které si mezi sebou mohou předávat parametry. Váha výsledku autentizace jednoho přihlašovacího modulu na celkovou autentizaci se dá nastavit pomocí čtyř úrovní: [5] Requiered pro výsledek celé autentizace je nutné, aby se modul správně autentizoval. Další moduly v pořadí se pokusí o autentizaci pokud je tento modul úspěšný, i když selže. Requisite pro výsledek celé autentizace je nutné, aby se modul správně autentizoval. Pokud je tento modul úspěšný, další moduly v pořadí se pokusí autentizovat, ale v případě selhání to již nezkouší. Sufficient není potřebné pro celkovou autentizaci, aby se modul úspěšně autentizoval. Další moduly se v případě úspěchu již o autentizaci nepokoušejí, ale při selhání pokračuje autentizace i na následujících modulech. Optional není potřebné pro celkovou autentizaci, aby se modul úspěšně autentizoval. Další moduly v pořadí se pokusí o autentizaci, pokud je tento modul úspěšný i když selže. 2.1 Průběh autentizace z pohledu přihlašovacího modulu Celá autentizace začíná voláním metody login() na objektu LoginContext. I když se to zdá z pohledu aplikace jako jedna operace, skládá se ze dvou fází. V první fázi se zavolá metoda login() na všech načtených přihlašovacích modulech. V této metodě si vyžádá každý přihlašovací modul od uživatele údaje pomocí CallbackHandleru (například uživatelské jméno a heslo) a poté se těmito údaji pokusí uživatele autentizovat. Při úspěšné autentizaci si modul uloží údaje do privátních proměnných. Výsledek metody je buď true při úspěšné autentizaci, false při neúspěšné nebo může vyhodit výjimku při chybě. Ve druhé fázi, pokud je celková úspěšnost autentizace všech načtených modulů (po vyhodnocení podmínek důležitosti) úspěšná, zavolá LoginContext na načtených modulech metodu commit(). Ta v případě, že se modul úspěšně přihlásil, vloží příslušné Principaly a Credential do Subject. V případě neúspěšné autentizace je zavolána na všech přihlašovacích modulech metoda abort(), která vymaže z modulu všechna používaná autentizační data. Při odhlašování se volá pouze metoda logout(), která odstraní ze Subject všechny Principal nebo Credential. [6] 8

PŘIHLAŠOVACÍ MODUL Obr. 2.1: Průběh autentizace za použití dvou přihlašovacích modulů. První je označen LM1 a druhý je označen LM2. 2.2 Načtení přihlašovacího modulu Jaké přihlašovacích moduly má LoginContext k autentizaci uživatele použít, se určuje v souboru sloužícímu k nastavení přihlášení. Ten se načítá při startu aplikace, která se tedy musí restartovat po každé změně tohoto souboru, aby změny byly viditelné. Cesta ke konfiguračnímu souboru se dá nastavit dvěma způsoby. Prvním z nich je přidání konfiguračního parametru při startu aplikace. Například pokud má mít Tomcat pouze svůj vlastní konfigurační soubor jaas.conf, přidá se v Tomcat Monitor do Java Options řádek -Djava.security.auth.login.config=C:\jaas.conf 9

PŘIHLAŠOVACÍ MODUL Druhým způsobem je nastavit cestu ke konfiguračnímu soubor pro celou Java Security (bude načten v každé aplikaci) v souboru {java_home}/lib/security/java.security. Cesta ke konfigu-račnímu JAAS souboru se v něm nastaví jako hodnota vlastnosti login.config.url.n. Konfiguračních souborů může být použito více než jeden, rozlišují se podle parametru n ve jménu vlastnosti, které musí začínat od 1. Například pro konfigurační soubor, který se jmenuje jaas.conf umístěným ve složce C:\Jaas se přidá do java.security řádek login.config.url.1=file:c:/jaas/jaas.conf Konfigurační soubor obsahuje jednu nebo více položek pro různé aplikace, kde uvnitř každé položky jsou vypsány moduly, které se mají použít. Struktura každé položky je následující : <jméno položky> { <přihlašovací modul> <příznak> <nastavení>; <přihlašovací modul> <příznak> <nastavení>; }; jméno položky jméno dané LoginContextu v aplikaci. přihlašovací modul celé jméno třídy přihlašovacího modulu. příznak jedna ze čtyř úrovní, určující důležitost úspěšné autentizace modulu na výsledek celkové autentizace (required, requisite, sufficient, optional). nastavení každý přihlašovací modul může mít nějaká svá vlastní nastavení. Může to být například zapnutí vypisování chyb, zapnutí testů, adresa LDAP serveru a další. Správný zápis je tvořen párem jméno-hodnota např.: debug=true. [7] 2.3 Přihlašovací modul pro Kerberos Jediným přihlašovacím modulem využívající protokol Kerberos obsaženým přímo v JAAS je Krb5LoginModule. Zajišťuje odeslání požadavku na danou AS a obdržení TGT čímž potvrdí, že uživatel vložil správné uživatelské jméno a heslo. Při autentizaci proti MS Active Directory přidá v případě úspěšného přihlášení do Subject uživatelův Principal se jménem ve formátu jméno@- doména a přijatý tiket. [8] Krb5LoginModule umožnuje nastavit tři vlastnosti: usekeytab zdali se má používat soubor keytab (soubor sloužící k ukládání klíčů). Může nabývat dvou hodnot true nebo false. Pokud není zadán, je hodnota false. keytab cesta ke keytab souboru. storekey jestli se má uchovávat klíč v Credentials. Může být buď true, nebo false, výchozí nastavení je false. 10

PŘIHLAŠOVACÍ MODUL Pro správnou funkci modulu se musí nastavit adresa KDC a realm. Existují opět dvě možnosti. Vytvoří se konfigurační soubor s těmito hodnotami, kde se dají navíc nastavit i další parametry, například které šifry se mají pro komunikaci s KDC použít nebo cesta ke keytab. Obsah souboru má následující strukturu : [libdefaults] default_realm = MOJE.DOMENA.CZ default_keytab_name = FILE:c:\krb5.keytab default_tkt_enctypes = rc4-hmac default_tgs_enctypes = rc4-hmac forwardable = true renewable = true noaddresses = true clockskew = 300 [realms] MOJE.DOMENA.CZ = { kdc = moje.domena.cz:88 default_domain = domena.cz } [domain_realm].domena.cz = MOJE.DOMENA.CZ Tento soubor se hledá buď na adrese C:\windows\krb5.ini, nebo se pro samostatnou aplikaci určí startovacím parametrem -Djava.security.krb5.conf Druhou možností je přidání dvou následujících startovacích parametrů pro aplikaci (Tomcat) s adresami na KDC a realm: -Djava.security.krb5.realm=<realm> -Djava.security.krb5.kdc=<kdc:port> Toto nastavení adres má přednost, před nastavením údajů ze souboru. [9] 11

Kapitola 3 Konfigurace Apache Tomcat 3.1 Tomcat Realms K autentizaci na straně serveru používá Tomcat tzv. realmy. Mají podobnou funkci jako databáze uživatelských jmen, hesel a rolí podle níž se kontroluje, kteří uživatelé dostanou přístup k daným stránkám, celé aplikaci nebo celému serveru. Role je skupina uživatelů, mající stejná přístupová práva, přičemž každý uživatel může být členem více rolí. Realmy bývají vytvořeny jako zásuvné moduly, které je možné připojit k již existující databázi nebo autentizačnímu mechanizmu. Existuje několik standardních implementací, jenž poskytují připojení k různým zdrojům: JDBCRealm - zpřístupňuje autentizační informace z relační databáze pomocí JDBC. DataSourceRealm - zpřístupňuje autentizační informace z relační databáze skrz JNDI jmenného JDBC datového zdroje. Využívá se hlavně pro optimalizaci spojení, například connection pooling. Má stejné požadavky na strukturu databáze jako JDBC realm. JNDIRealm - zpřístupňuje autentizační informace uložené v LDAP adresářovém serveru, pomocí JNDI. UserDatabaseRealm - zpřístupňuje autentizační informace uložené v uživatelské databázi JNDI, bývá to většinou XML dokument. Při startu se načtou informace o všech uživatelích a jim odpovídajících rolích z XML dokumentu. Uživatelé, jejich hesla a role mohou být měněny i za běhu pomocí JMX. Změny se uloží a budou promítnuty do XML souboru. MemoryRealm - zpřístupňuje autentizační informace uložené v paměti jako kolekci objektů, které jsou vytvořeny z XML dokumentu. Slouží pouze jako jednoduchá ukázka, ukazující implementaci rozhraní Tomact 6 Realm. Není určený pro produkční užití. JAASRealm - zpřístupňuje autentizační informace skrz JAAS. 3.1.1 Konfigurace realmu Spočívá v přidání elementu <realm classname="">, kde atribut classname určuje jméno realmu, do konfiguračního souboru {tomcat_home}/conf/server.xml. Tento element musí být v jednom z následujících elementů, jenž určí rozsah jeho působení. engine - bude se vztahovat na všechny aplikace a všechny virtuální hosty. Virtuální host je server, který běží na stejném fyzickém stroji s několika dalšími virtuálními hosty, ale chová se stejně, jako kdyby běžel na samostatném. host - bude se vztahovat na všechny aplikace od tohoto virtuálního hosta. 12

KONFIGURACE APACHE TOMCAT context - bude se vztahovat jenom k této konkrétní aplikaci. Element pro přidání JAAS realmu, který je nejvhodnější k autentizaci pomocí Kerbera, vypadá následovně : <Realm classname="org.apache.catalina.realm.jaasrealm" appname="tomcat" userclassnames="javax.security.auth.kerberos.kerberosprincipal" roleclassnames="javax.security.auth.kerberos.kerberosprincipal" /> Atribut appname je jméno položky v konfiguračním JAAS souboru (kapitola 2.2). Zbylé dva atributy určují typ Principalu v Subject, které má realm brát jako Principal uživatele (atribut userclassnames) a Principal představující uživatelovu roli (atribut roleclassnames). [10] Při použití Krb5LoginModule se přidává do Subject pouze KerberosPrincipal, proto se musí při jeho použití dát tento typ oběma těmto atributům. Role uživatele bude tedy stejná jako jeho jméno. 3.2 Zabezpečení komunikace Aby se data mezi klientem a Apache Tomcat nepřenášela v prostém textu, budou šifrována. K tomu se použije protokol HTTPS. Ten je nadstavbou protokolu HTTP využívající protokol SSL, který přenášená data šifruje a autentizuje komunikující strany. SSL využívá asymetrické šifry, kdy klient i server znají veřejný klíč, ale privátní klíč zná pouze server. Server si poté pomocí privátního klíče dešifruje zprávu od klienta, obsahující klíč, který bude použit při následné komunikaci. Veřejný klíč je obsažen v certifikátu, který odešle server klientovi při začátku komunikace. Certifikátem se také ověřuje, zda je daný server skutečně ten, za který se vydává. 3.2.1 Vytvoření certifikátu Certifikát bývá uložen ve formátu podle standardu X.509, který kromě veřejného klíče obsahuje i dodatečné informace o vlastníkovi. K uchovávání certifikátů a privátních klíčů se používá keystore (úložiště klíčů). Existují různé druhy keystore, přičemž Tomcat pracuje s typy JKS, PKCS11 a PKCS12. Verze JKS je standardní formát Java KeyStore a dá se vytvořit a měnit pomocí programu keytool, zahrnutým v základní instalaci JDK. PKCS11 a PKCS12 jsou standardy vyvíjené v RSA Laboratories. Dají se spravovat pomocí Open SSL, Microsoft Key-Manager a mnohými dalšími. Certifikáty jsou v keystore uloženy jako jednotlivé položky a každá je identifikována svým jménem. Většina druhů keystore nerozlišuje velikost písmen v názvu, až na některé výjimky jako například PKCS11. Pro testovací účely vytvořím vlastní keystore typu JKS a certifikát podepsaný sám sebou (Selfsigned certificate). Pro jeho vytvoření použiji program keytool. Keytool se ovládá z příkazové 13

KONFIGURACE APACHE TOMCAT řádky a k vytvoření certifikátu slouží příkaz Tento příkaz vytvoří veřejný a privátní klíč. Veřejný klíč vloží do certifikátu dle standardu X.509, ten uloží do jednoprvkového řetězce certifikátů, který je uložen spolu s privátním klíčem jako nová položka keystore. Tento příkaz se dá navíc rozšířt o několik parametrů: alias - název položky certifikátu v klíčence keyalg - algoritmus, kterým se bude šifrovat, použiji RSA keystore\{path} určí, kde se má vytvořit keystore s certifikátem Celý příkaz bude tedy vypadat následovně: {java_home}\bin\keytool -genkeypair $java_home\bin\keytool -genkeypair -alias tomcat -keyalg RSA -keystore C:\MyApp\.keystore Po zadání tohoto příkazu vyžaduje keytool heslo, kterým bude keystore šifrován. Toto heslo musí znát i Tomcat, aby keystore dokázal otevřít. Tomcat používá jako výchozí heslo changeit, ale to se dá změnit v konfiguraci. Poté se zadají základní informace o certifikátu jako jméno firmy, kontaktní jméno, země původu a další. Tyto informace jsou zobrazeny uživateli, kterému bude certifikát nabídnut ke stáhnutí při začátku šifrované komunikace. Nakonec se zadá heslo sloužící k ochraně vygenerovaného privátního klíče tohoto certifikátu. Implementace Apache Tomcat vyžaduje, aby toto heslo bylo stejné jako heslo do keystore. Po zadání tohoto hesla se vygeneruje keystore s certifikátem na určeném místě. [11] 3.2.2 Nastavení HTTPS protokolu v Apache Tomcat Aby byl Tomcat schopen komunikovat pomocí protokolu HTTPS, musí se mu nastavit nový HTTP konektor (anglicky connector) a v něm povolit SSL. Nový konektor se do Tomcat přídává pomocí elementu Connector vloženého do elementu Engine v konfiguračním souboru {tomcat_home}/config/server.xml. Tomcat dokáže použít dvě odlišné implemetace SSL. JSSE (Java Secure Socket Extension) podpora pro protokol SSL implementovaná v Javě. APR (Apache Portable Runtime) APR je nativní knihovna, která dokáže využívat Open SSL. Výběr implementace se určuje automaticky podle toho, jestli je v instalaci Apache Tomcat nainstalována knihovna APR. Když nainstalována je, použije se APR, v opačném případě se použije 14

KONFIGURACE APACHE TOMCAT JSSE. Je možné přímo určit, která implementace bude použita podle hodnoty atributu protocol v elementu Connector. Pro APR je to třída pro JSSE <Connector protocol="org.apache.coyote.http11.http11aprprotocol" port="8443".../> <Connector protocol="org.apache.coyote.http11.http11protocol" port="8443".../> Vzhledem k tomu, že APR knihovna není běžně nainstalována, použiji JSSE implementaci. Do konfiguračního souboru se tedy přidá tento element: <Connector port="8443" scheme="https" secure="true" SSLEnabled="true" keystorefile="c:\myapp\.keystore" keystorepass="changeit" sslprotocol="tls"/> V základní instalaci Apache Tomcat je tento element v konfiguračním souboru již obsažen, ale je zakomentován, stačí jej tedy pouze odkomentovat a upravit atributy. Element konektor se dá rozšířit o několik atributů, jejichž význam je popsán v následující tabulce. [12] port scheme secure SSLEnabled keystorefile Určuje na jakém portu TCP portu má konektor očekávat příchozí připojení. Nastavuje jméno protokolu, které bude tento konektor používat, tedy HTTPS. Určuje, jestli je konektor zabezpečen, vzhledem k tomu že používám SSL tak je hodnota true. Tímto atributem se zapíná konektoru SSL podpora. Cesta ke klíčence, kde je uložen používaný certifikát. keystorepass Heslo keystore. sslprotocol Verze SSL protokolu, která bude použita. Použiji nejnovější verzi - TLS. 15

Kapitola 4 Zkušební aplikace Tato aplikace bude sloužit k otestování všech nastavení, které jsou popsány v předchozích kapitolách. Povolí uživateli vstup na chráněný obsahu (servlet), pouze pokud se uživatel správně autentizuje a bude mít povolení k přístupu. Aplikace obsahuje tři jsp stránky a dva servlety. Specifikace servletu vyžaduje určité požadavky, které je třeba dodržet, aby byl webový kontejner schopen úspěšně a správně provést autentizaci. Jedním z nich je, že v konfiguračním souboru aplikace musí být definována přihlašovací stránka (v aplikaci to je login.jsp) a chybová stránka (error.jsp). Další požadavky se týkají jednotlivých stránek. index.jsp tato stránka je úvodní, uživatel se na ni dostane po vstupu do aplikace. Vedou z ní dva odkazy na chráněný servlet. První odkaz vede přes nešifrované HTTP spojení a druhý je šifrován pomocí HTTPS. login.jsp tato stránka slouží k přihlášení uživatele. Uživatel je na ni vždy přesměrován, pokud se pokusí dostat do chráněné části aplikace bez toho, aniž by byl dosud přihlášen. Stránka obsahuje přihlašovací formulář. Formulář je posílán HTTP metodou POST a jeho akce je hodnota j_security_check. Akce přihlašovacího formuláře musí být podle specifikace vždy j_security_check, jinak nebude autentizace správně fungovat. Dále formulář obsahuje dvě pole pro zadání jména a hesla, která jsou pojmenována j_username a j_password, což je podle specifikace též povinné. Celý formulář vypadá následovně: <form method="post" action="j_security_check"> <input type="text" name="j_username"> <input type="password" name="j_password"> <input value="login" type="submit"> </form> error.jsp na tuto stránku se uživatel dostane, pokud autentizace neproběhne úspěšně. Obsahuje chybové oznámení, že autentizace selhala. security.java představuje chráněnou oblast aplikace a je dostupný pouze přihlášeným uživatelům. Vypíše na výstup webovou stránku, která bude oznamovat, že autentizace proběhla v pořádku a uživatelovo jméno. logout.java slouží k odhlášení uživatele. 16

ZKUŠEBNÍ APLIKACE Obr. 4.1: Diagram tříd zkušební aplikace. 4.1 Konfigurace aplikace Aplikace se konfiguruje v souboru {application_path}/web-inf/web.xml. V tomto souboru se nastavuje mapování na servlety a především zabezpečovací prvky. Nejdůležitější elementy jsou: security-role - seznam všech rolí používaných v aplikaci, každá role musí být v elementu <role-name>. security-constraint - nastavení chráněných částí a způsobu ochrany. web-resource-collection - obsahuje seznam stránek, které budou vyžadovat autentizaci. Musí obsahovat povinný element <web-resource-name> určující jméno seznamu. Dále definuje stránky, které mají být chráněny, každá v elementu <url-pattern> a chráněné HTTP metody v elementu <http-method>. V aplikaci budou chráněny všechny stránky, které budou za {server_address}/security/ (jméno servletu), a metody POST a GET. user-data-constraint - určuje, jak budou data mezi klientem a serverem chráněna. Je zapsána v elementu <transport-guarantee>. Může nabývat 3 hodnot: NONE bez ochrany INTEGRAL - data musí být zaslána cestou, která zaručí, že data nebudou během vysílání změněna (SSL, kontrolní součet). CONFIDENTIAL - data musí být zaslána cestou, která zaručí, že data nebudou odposlechnuta nebo změněna (pomocí SSL, šifrování) auth-constraint - seznam rolí, které mají povolen přístup ke chráněným částem aplikace. Každá role je v elementu <role-name> a musí být definována i v elementu <security role>. 17

ZKUŠEBNÍ APLIKACE V konfiguraci je nastaveno, že uživatelova role bude stejná jako jeho jméno, musí zde tedy být vypsána všechna jména, která mají mít povolen vstup a to ve formátu jméno@realm. login-config - použitá autentizační metoda, může být buď BASIC nebo FORM, je v elementu <auth-method>. Aplikace využívá metodu FORM. [13] Příklad možného web.xml (který je použit v aplikaci) je v dodatku A. Celá vytvořená aplikace je dostupná na přiloženém CD jako Maven projekt 4, i jako war soubor. Aplikace je šířena pod licencí Berkeley Software Distribution (dále jen BSD). Text licence je přiložen v dodatku C. 4.2 Vyzkoušení aplikace Při natavení Tomcatu tak, jak je popsáno v předchozích kapitolách (použití Tomcat JAAS realm, využívající Krb5LoginModule autentizující se proti Active directory), je aplikace dostupná (při použití na localhost) na adrese http://localhost.cz:8080/zkusebniaplikace. Při mém testování probíhala celá autentizace v pořádku. Zde je několik poznámek k nastavení a chování autentizace: Při konfiguraci Kerbera a jeho adres (kapitola 2.3) může nastat problém s používanými šiframi. Windows 2008 R2 používají při výchozím nastavení šifrování RC4-HMAC. Nedovolují však jako výchozí nastavení mít šifrování DES. Kvůli tomu se musí Kerberos nastavovat konfiguračním souborem, kde se dá nastavit i používaná šifra. Jméno realmu v konfiguračním souboru Kerbera (kapitola 2.3) musí být napsáno velkými písmeny, jinak bude přihlašovací modul hlásit chybu. Prohlížeče Internet Explorer 8 a 9 hlásí upozornění na nepravost certifikátu, ale to je díky self-signed certifikátu, který neznají. Při přihlašování nezáleží na velikosti písmen u přihlašovacího jména, takže uzivatel a UZIVATEL je to samé. U hesla na velikosti písmen samozřejmě záleží. Celá autentizace se dá ještě vylepšit menší úpravou. Při použití Krb5LoginModule vyvstává totiž problém, že realm povolí uživateli přístup na stránku pouze tehdy, pokud má správnou roli. Realm bere roli ze Subject, ale používaný přihlašovací modul vkládá do Subject pouze Principal reprezentující uživatelovo jméno, tudíž bere jako roli jeho jméno. V konfiguračním souboru aplikace by tedy museli být vypsáni všichni uživatelé, kteří mají povolený přístup, což je při větším množství uživatelů značně nepraktické a dlouhodobě neudržitelné. Jedním ze způsobů řešení je vytvořit nový přihlašovací modul, který bude využívat Krb5LoginModule k autentizaci, a vloží navíc do Subject i RolePrincipal, který bude představovat roli uživatele. 4 http://maven.apache.org/ 18

ZKUŠEBNÍ APLIKACE 4.3 Vytvoření vylepšeného modulu Popíši, jak se dá vytvořit přihlašovací modul využívající Krb5LoginModule a vkládající do Subject spolu s KerberosPrincipal i RolePrincipal prezentující roli uživatele. Přihlašovací modul musí implementovat rozhraní javax.security.auth.spi.loginmodule, které obsahuje 5 metod: void initialize(subject subject, CallbackHandler callbackhandler, Map sharedstate, Map options) Tato metoda je volána při inicializaci přihlašovacího modulu. Uloží obdržené argumenty do lokálních proměnných. Argumenty metody jsou subject množina obsahující informace o přihlášeném uživateli. Mohou být typu Principal nebo Credentials. callbackhandler slouží pro komunikaci mezi přihlašovacím modulem a uživatelem za účelem získání autentizačních údajů. sharedstate slouží k poskytnutí dodatečných autentizačních informací, které chceme poskytnout dalším přihlašovacím modulům. options obsahuje konfigurační údaje, které mohou ovlivnit chování přihlašovacího modulu. boolean login() throws LoginException Vytvoří novou instanci třídy Krb5LoginModule, uloží ji do lokální proměnné a zavolá na ní metodu initialize() s argumenty, obdrženými při inicializaci modulu. Poté se zavolá metoda login(), která obstará samotnou autentizaci. Když bude autentizace neúspěšná, vyhodí se výjimka, jinak vrátí true. boolean commit() throws LoginException Tato metoda se provede, pokud bude úspěšná metoda login(). Použije instanci třídy Krb5LoginModule, která je uložena v lokální proměnné a zavolá se na ní metodu commit(). Takto se přidá do Subject Principal přihlášeného uživatele. Ten se ze Subject může vybrat, zjistit jeho jméno a podle něj určit role. Poté se do Subject přidá Principal i s jeho rolemi. Při úspěchu vrátí metoda true, při chybě vyhodí výjimku. boolean abort() throws LoginException Tato metoda se provádí, když první fáze autentizace selže. Vymažou se v ní uživatelská data, která se používala při přihlašování a jsou uložena v lokálních proměnných. Při úspěchu vrátí metoda true, při chybě vyhodí výjimku. boolean logout() throws LoginException Metoda se provede při odhlášení. Vymaže všechny Principal třídy, které jsou obsaženy v objektu Subject a vynuluje lokální proměnné v modulu. Při úspěchu vrátí true, při chybě vyhodí výjimku. 19

ZKUŠEBNÍ APLIKACE Dále se vytvoří třída RolePrincipal, implementující rozhraní Principal. Ta bude mít pouze jeden atribut name, představující jméno role. Obě třídy (LoginModule i RolePrincipal) se vloží do společného balíku. Aby s tímto balíkem mohl Tomcat pracovat, musí se tento balík přidat do jeho classpath {tomcat_home}/lib/. V nastavení realmu poté stačit změnit, že typ Principalu, který má být považován za roli je RolePrincipal. Balík obsahující tyto dvě třídy je též na přiloženém CD. Obr. 4.2: Třídy v novém package. 20

Kapitola 5 Shibboleth Shibboleth je projekt vyvíjený organizací Internet2 5. Umožňuje uživateli bezpečně předat důvěryhodné informace o sobě na vzdálený zdroj, kde může být tato informace použita k autentizaci, autorizaci, individuálnímu nastavení obsahu a jednotnému přihlášení mezi širokým okruhem služeb od různých poskytovatelů. Pod pojmem jednotné přihlášení (běžně se užívá anglický termín Single sign-on, zkráceně SSO) se myslí, že se uživatel při vstupu na zabezpečenou službu jednou přihlásí a při vstupu na jinou zabezpečenou službu požadující stejné přihlášení se již nemusí přihlašovat podruhé. Shibboleth používá různé standardy a je postaven na Security Assertion Markup Language (SAML) vyvíjeném organizací OASIS. Existuje více verzí Shibbolethu stavících na různých verzích SAML v této práci se budu zabývat verzí Shibboleth2, která staví na SAML 2.0. Shibboleth tedy umožňuje předání autentizačních a autorizačních údajů mezi poskytovatelem identit (anglicky Identity Provider, zkráceně IdP ) a poskytovatelem služeb (Service Provider, zkráceně SP). Při jejich komunikaci se využívají tyto základní pojmy : SAML assertion tvrzení předávající informace o uživateli, může obsahovat tři typy zpráv: autentizace uživatel byl autentizován určitým způsobem v určitý čas atribut uživatel je spojen s dodávaným atributem autorizační rozhodnutí požadavek pro vstup na určitý chráněný zdroj byl uživateli zamítnut nebo povolen SAML binding mapování podporovaných protokolů na standardní komunikační protokoly. SAML profile způsob předání zpráv mezi IdP a SP podle toho, jaké protokoly se použijí. Protože SAML umožňuje předávat si zprávy pomocí různých protokolů, musí se obě strany dozvědět, jaké protokoly podporuje druhá strana. To se děje pomocí metadat, kde jsou podporované protokoly vypsány. Na základě těchto dat se vybere SAML profile, tedy způsob komunikace mezi zúčastněnými stranami. Nejčastější (a doporučený) způsob je Web Browser SSO Profile popsaný v další podkapitole. 5 http://www.internet2.edu/ 21

SHIBBOLETH 5.1 Popis autentizace uživatele pomocí Shibbolethu Obr. 5.1: Průběh autentizace uživatele pomocí Shibbolethu. 1. Neautentizovaný uživatel se pokusí přistoupit k obsahu chráněném pomocí Shibbolethu. Pokud je uživatel již přihlášen a toto přihlášení je stále aktivní, pustí ho SP dál. V opačném případě je tento požadavek poskytovatelem služeb zachycen a zablokován. 2. Poskytovatel služeb vybere, na kterém IdP se uživatel bude chtít autentizovat a poté na něj uživatele přesměruje. Proces vybírání správného IdP se jmenuje IdP discovery a zahrnuje kombinaci konfiguračních nastavení, cookies a jiných technik. Je také možnost, že si uživatel vybere IdP sám z nabízených možností. 3. SP předá vybranému IdP autentizační požadavek. Formát tohoto požadavku závisí na protokolu vybraném SP ke komunikaci. Požadavek se předává pomocí webového prohlížeče a poté je uživatel přesměrován (pomocí GET nebo POST) na vybraný IdP. 4. IdP přijme požadavek a vybere autentizační metodu, pomocí níž se uživatele pokusí autentizovat. 5. Když se uživatel úspěšně autentizuje, použije IdP Atribute Resolver ke zjištění uživatelových atributů. Po jejich zjištění je transformuje (pokud je to nutné) a přiřadí každému atributu dané šifrování. Zjištěné atributy se dále zredukují pomocí Atribute Fillteru, kde se všechny nepotřebné vyřadí. Které informace o uživateli se pošlou zpět, závisí na daném SP a uživateli. Informace může obsahovat pouze oznámení, že se uživatel správně autentizoval, nebo jakýkoliv atribut, který může IdP zjistit. Všechny informace jsou zabaleny a 22

SHIBBOLETH je z nich vytvořeno SAML tvrzení. Toto tvrzení může být podepsáno IdP klíčem a zašifrováno pomocí SP klíče pro větší bezpečnost. Tvrzení je odesláno zpět na SP přes uživatelův prohlížeč. 6. SP převezeme odpověď obsahující tvrzení. Poté zprávu dešifruje, dešifruje tvrzení a pokud je to nezbytné provede ochranné testy. Když je vše v pořádku SP extrahuje atributy a jiné informace z odpovědi. Atributy jsou převedeny do cachovatelné podoby za použití SP Atribute Extraktoru, vyfiltrovány přes Atribute Filter a cachovány v nové session s ostatními relevantními informacemi. 7. V posledním kroku je prohlížeč přesměrován zpět na chráněný zdroj, na který se přistupovalo v kroku 1, ale tentokrát se zdroj objeví v kontextu s uloženou session uvnitř SP. [14] 5.2 Metadata Aby se poskytovatel služeb a poskytovatel identit mezi sebou dorozuměli a věděli, jaké informace si předat, musí znát informace o tom druhém. Tyto informace jsou označovány jako metadata, což je XML dokument ve formátu podle standardu SAML 2.0. Metadata popisují IdP nebo SP a bývají buď v elementu <md:entitydescriptor> pro popis jednoho poskytovatele, nebo v <md:entitiesdescriptor> pro popis více entit. Jako entita se označuje objekt, vytvářející SAML požadavky nebo odpovědi tedy například SP nebo IdP. Každá taková entita musí mít entityid, která ji rozlišuje od ostatních. Metadata popisující SP a předávána IdP Tato metadata jsou umístěna v elementu <md:spssodescriptor>. Metadata o poskytovateli služeb většinou obsahují tyto elementy: veřejný klíč používaný poskytovatelem služeb k autentizaci a šifrování. Když se klíč neshoduje s používaným, nedokáže IdP správně dešifrovat příchozí zprávy. adresy na které se mají posílat požadavky různých protokolů, které SP podporuje. podporované formáty. vyžadované atributy o uživateli. Poskytovatel dokáže vygenerovat metadata o sobě na základě svojí konfigurace. Metadata popisující IdP a předávána SP Tato metadata jsou v elementu <md:idpssodescriptor>, který obsahuje podobné elementy jako metadata o poskytovateli služeb. 23

SHIBBOLETH 5.3 Poskytovatel identit Je Java web aplikace, která je ve své verzi 2 založena na Servlet 2.4 specifikaci. Je poskytována jako war soubor, ke svému běhu tedy potřebuje servlet kontejner s podporou SSL spojení. Může to být například Apache Tomcat, jehož instalace je popsána v kapitole 1.3 a natavení SSL v kapitole 3.2. Nastavení IdP se skládá ze dvou částí: nastavení správné komunikace mezi SP a IdP a nastavení autentizace uživatele. 5.3.1 Komunikace s poskytovatelem služeb Relying party Přestože IdP komunikuje téměř výhradně pouze se SP, může v některých výjimečných případech komunikovat i s jiným objektem (například s jiným IdP). Proto se pro bod, se kterým IdP může komunikovat používá označení relying party. SP je tudíž jedním z relying party. Ty se nastavují v souboru relying-party.xml a existují 3 druhy: anonymní IdP pro ni nemá žádná metadata. výchozí IdP pro ni má metadata, ale nemá specifickou konfiguraci. specifická IdP pro ni má metadata i specifickou konfiguraci. V každém relying party je povinný atribut provider určující, jaké entityid při komunikaci s ním použije. U specifické relying party je navíc povinný atribut id které určuje, jakou entityid musí relying party mít, aby se toto nastavení použilo. Dále lze u všech nastavit volitelný atribut defaultauthenticationmethod, což je autentizační metoda, která se použije v případě, že není podporována ta, kterou vyžaduje SP. Každá relying-party může mít žádný, nebo více komunikačních profilů. Když se relying party pokusí komunikovat pomocí profilu, který pro ni není povolen, dostane IdP chybou zprávu informující, že daný profil není povolen. Ve výchozím nastavení jsou relying party nastaveny tak, že anonymní relying party nemá žádný profil a výchozí má všechny podporované. Ve většině případů není nutné toto nastavení měnit. Získání metadat o SP Kvůli nastavení popsanému v předchozí podkapitole je nutné získat metadata o SP, se kterými chce IdP komunikovat. Tato metadata se dají získat různými způsoby pomocí tzv. metadata provider. Ty se nastavují v souboru relying-party.xml a existuje jich několik druhů: Chaining Metadata Provider kombinuje různé metadata providery. Ti jsou postupně procházeni a vybrán je ten, který jako první vrátí neprázdnou odpověď. 24

SHIBBOLETH Filesystem Metadata Provider načítá metadata ze souboru umístěném na lokálním disku. Metadata jsou ukládána do cache a IdP sleduje, zda nebyl soubor na disku změněn. V případě změny ho znovu načte. HTTP Metadata Provider načítá metadata z HTTP nebo HTTPS URL adresy. Metadata jsou uchovávaná určitou dobu v paměti. File Backed HTTP Metadata Provider pracuje stejným způsobem jako HTTP metadata provider s tou změnou, že uchovává metadata na lokálním disku pro případ, že by metadata byly správně jednou načtena, ale podruhé by byla metadata na serveru nějaký čas nepřístupná. Inline Metadata Provider načte metadata přímo z vloženého elementu Entities descriptors. 5.3.2 Konfigurace autentizace Login handler Důležitým bodem je nastavení autentizace uživatele. IdP může podporovat najednou více autentizačních metod. V SAML 2.0 může SP vyžadovat jednu autentizační metodu, která bude použita a v případě, že je IdP pro tuto metodu nakonfigurován, použije se ona. Pokud není poskytovatovatelem služeb žádná vybrána, použije se výchozí metoda nastavená v relying party a v případě, že není nastavena ani zde, tak se vybere náhodně. Pokud je nakonfigurována previous session a uživatel již má existující session, vybere se pro přihlášení previous session čímž se zajistí SSO. Autentizaci poskytuje tzv. Login handler, který se nastavuje v souboru handler.xml. Existuje jich více druhů a každý poskytuje rozdílný autentizační mechanizmus : Remote User používá pro autentizaci přímo kontejner. External Authn login handler, který přenese jiný autentizační mechanizmus na současného uživatele. Username/password přenese uživatele na autentizační stránku a poté zkontroluje jméno a heslo podle protokolu Kerberos 5 nebo LDAP. IP adress zkontroluje, zda je uživatelova IP adresa v předepsaném rozsahu Previous session se volá v případě, že je již existující session použita jako autentizační mechanizmus (když server podporuje SSO). 25

SHIBBOLETH Nastavení autentizace pomocí Kerbera Z předchozího výpisu možných technologií, se k autentizaci pomocí Kerbera použije Login handler username/password. Tento login handler je postaven na JAAS a využívá tedy pro autentizaci přihlašovací moduly. Pro jeho podporu se musí do souboru handler.xml přidat element <LoginHandler xsi:type="usernamepassword" jaasconfigurationlocation="c:/jaas.conf"> který jaasconfigurationlocation určuje místo, kde se nachází konfigurační JAAS soubor pro přihlašování. Nastavení přihlašovacího modulu je tedy stejné, jak je popsáno v kapitole 2. Zde je vhodné také použít Krb5LoginModul který se nastaví stejně jako v kapitole 2. Na rozdíl od předchozí zkušební aplikace se zde autentizace nezakládá na žádných rolích a není tedy třeba modul nijak upravovat. 5.3.3 Atributy Atributy jsou vybrány z datového zdroje za použití data konektoru. Data konektory mohou produkovat více atributů, přičemž jeden atribut může mít více hodnot. Existují následující data konektory: static data connector pro statické atributy. computed ID data connector pro vytvoření unikátních identifikátorů pomocí hashování informací. stored ID data connector vytvoření trvalých identifikátorů v databázi. relational database connector pro vybrání atributů z relační databáze pomocí SQL příkazu. LDAP data connector pro vybrání attributů z LDAP serveru spuštěním LDAP filtru. Data konektory se nastavují v souboru attribute-resolver.xml. Poté, co mají atributy jméno a hodnotu, se musí upravit, aby měla správný formát po přenos po síti. Poté se dají ještě atributy filtrovat různými způsoby, což se nastavuje v souboru attribute-filter.xml. 5.4 Poskytovatel služeb Je nainstalován na stejném stroji, jako webový server a zajišťuje komunikaci s IdP. Je dostupný pro většinu operačních systémů včetně Microsoft Windows ve verzích: Windows XP SP2 a novější, Windows 2003 Server SP1 a novější nebo Windows 2008 Server. Z webových serverů jsou podporovány IIS nebo Apache HTTP server. 26

SHIBBOLETH 5.4.1 Instalace SP a jeho integrace s Apache HTTP serverem Poskytovatel služeb se instaluje do Windows jako služba běžící na pozadí. Instalace pomocí instalátoru, staženého z oficiálních stránek je rychlá a služba se poté spustí při každém startu Windows. Dále je potřeba nainstalovat Apache HTTP server. Instaluje se obdobně jako Tomcat Server a v základním nastavení stačí nastavit pouze číslo portu, které je standardně 80. Po instalaci se musí u Apache nastavit podpora zabezpečeného spojení (HTTPS) a také podpora pro SP. Podpora pro Shibboleth se přidává do Apache serveru jako nový modul. Tento modul je obsažen v instalační složce SP, stačí ho tedy načíst přidáním následující řádky do konfiguračního souboru {apache_home}/conf/httpd.conf. LoadModule mod_shib {SP}/lib/shibboleth/mod_shib_22.so Když už Apache HTTP server má Shibboleth načten, stačí jenom určit, které části webových aplikací mají vyžadovat jeho povolení ke vstupu. To se udělá přidáním elementu <Directory>, který určuje složku s webovou aplikací, která má být přístupná pouze přihlášeným uživatelům. V tomto elementu se poté nastaví, že přístup k dané složce je umožněn pouze uživatelům přihlášených pomocí autentizace Shibboleth (mající jeho session). Příklad elementu je následovný: <Directory "C:/Program Files/Apache2.2/htdocs/Auth"> AuthType shibboleth ShibRequireSession On require valid-user </Directory> Dále je třeba zapnout podporu HTTPS protokolu pro Apache, aby se dorozuměl s IdP. Toto má již Apache po instalaci přednastaveno a stačí odkomentovat následující řádek v konfiguračním souboru {apache_home}/conf/httpd.conf. Include conf/extra/httpd-ssl.conf Tímto se načte soubor, ve kterém je nastaveno načtení modulu pro podporu SSL. Je to soubor ve složce {apache_home}/conf/extra/httpd-ssl.conf. V tomto souboru je již nastaveno skoro vše potřebné, chybí pouze potřebné certifikáty a klíče které se budou při HTTPS spojení používat. Při jejich doplnění je Apache HTTP server nastaven a při pokusu o vstup na chráněné stránky se spustí proces přihlašování pomocí Shibbolethu. 27

SHIBBOLETH 5.4.2 Konfigurace SP Hlavní nastavení SP se provádí editací souboru {SP}/etc/shibboleth/shibboleth2.xml. Důležité je nastavit SP jeho entityid v elementu <ApplicationDefaults>. Dále je nutné nastavit poskytovatele identit, kterým SP důvěřuje. V případě podpory pouze jednoho IdP stačí přidat jeho id do atributu entityid elementu <SSO> a přidat metadata provider pro načtení jeho metadat. 5.4.3 Nastavení atributů Jestliže IdP odesílá v odpovědi nějaké atributy, musí k nim SP přiřadit jejich lokální id, aby s nimi mohla webová aplikace pracovat. V případě, že pro daný atribut není žádné nastavení, tak ho SP automaticky ignoruje. K překladu atributů slouží atribut extractor, který se musí manuálně nastavit v souboru {apache_home}/conf/extra/atributte-map.xml. Soubor obsahuje řadu pravidel, která přiřazují příchozím atributům jejich lokální názvy. Pravidlo má tvar: <Attribute name="urn:oid:2.16.756.1.2.5.1.1.1" id="name"> <AttributeDecoder xsi:type="scopedattributedecoder"/> </Attribute> Atribut name je název, pod kterým ho odesílá IdP a atribut id je lokální jméno. V případě, že IdP daný atribut odesílá nějak zakódován, musí se přidat element AtributDecoder s názvem dekodéru. 5.5 Vyzkoušení autentizace K vyzkoušení autentizace jsem použil již vytvořenou webovou aplikaci napsanou v programovacím jazyce PHP 6. Použil jsem tzv. lazy session, díky níž mohou nepřihlášení uživatelé stránky anonymně prohlížet a v případě, že se přihlásí, zpřístupní se jim další obsah. [15] Při začátku autentizačního procesu je třeba dát pozor, aby byl uživatel při přihlašování na straně SP připojen přes protokol HTTPS, jinak nebude IdP schopen určit zpáteční adresu (protože SP mapuje ve svých metadatech zpáteční adresy za použití protokolu HTTPS). Průběh autentizace z pohledu uživatele (co vidí uživatel na stránkách) je v dodatku B. 6 http://www.php.net/ 28

Závěr Výsledkem práce je popis nastavení webové Java aplikace tak, aby se dokázala autentizovat proti Microsoft Active Directory. Při použití JAAS není nastavení nijak složité, nejdůležitější je správné nastavení přihlašovacího modulu. Přihlašovací modul umožňující autentizaci pomocí Kerbera poskytovaný přímo v JAAS je dostačující pro většinu situací, není proto nutné používat jiný modul. Problémy nastávají až při autorizaci, kdy modul vrací pouze uživatelovo jméno. Autorizace se dá zajistit buď vytvořením vlastní databáze autorizačních pravidel nebo se může použít LDAP bind, ke zjištění atributů o uživateli přímo z Active Directory. Při použití Shibbolethu je autentizace proti Active Directory, na straně poskytovatele identit, podobná. Používá se také JAAS a jeho přihlašovací modul Krb5LoginModule, nastavení autentizace je tedy v Shibbolethu stejné. Obrovskou výhodou je, že Shibboleth zajišťuje celý proces autentizace sám a navíc je velmi dobře konfigurovatelný pro různé situace. Přidat Shibboleth autentizaci do již existující aplikace (tzv. Shibboletizace) není nijak složité. Silnou stránkou je také možnost přiřadit uživateli atributy, které se dají získat ať už přímo z dat získaných po autentizaci pomocí přihlašovacího modulu nebo z jiných zdrojů (například pomocí LDAP z Active Directory). 29

Literatura [1] Kerberos (protocol) - History and development [online].[cit. 1.listopadu 2010]. Dostupné z URL: <http://www.spiritus-temporis.com/kerberos-protocol-/history-anddevelopment.html>. [2] Jean-Yves Migeon, The MIT Kerberos Administrator s How-to Guide [online]. MIT Kerberos Consortium, 23. června 2008, s 4-11. [cit. 1. listopadu 2010]. Dostupné z URL: <http://www.kerberos.org/software/adminkerberos.pdf>. [3] Microsoft Corporation, How the Kerberos v5 Authentication Protocol Works [online]. [cit. 1. listopadu 2010]. Dostupné z URL: <http://technet.microsoft.com/enus/library/cc772815(ws.10).aspx>. [4] JAAS Reference Guide [online].[cit. 15. června 2010]. Dostupné z URL: <http://java.sun.com/javase/6/docs/technotes/guides/security/jaas/jaasrefguide.html>. [5] Class config [online].[cit. 15. června 2010]. Dostupné z URL: <http://download.oracle.com/javase/6/docs/api/javax/security/auth/login/configuration.html>. [6] Login Module developt [online].[cit. 2. listopadu 2010]. Dostupné z URL: <http://download.oracle.com/javase/1.4.2/docs/guide/security/jaas/jaaslmdevguide.html>. [7] Login Config File [online].[cit. 19. října 2010]. Dostupné z URL: <http://download.oracle.com/javase/1.4.2/docs/guide/security/jaas/tutorials/loginconfigfile.html>. [8] Kerberos login module [online].[cit. 23. června 2010]. Dostupné z URL: <http://download.oracle.com/javase/1.4.2/docs/guide/security/jaas/spec/com/sun/security/auth/mod ule/krb5loginmodule.html>. [9] JSSE - Reference Guide [online].[cit. 29. listopadu 2010]. Dostupné z URL: <http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/jsserefguide.html>. 30

LITERATURA [10] Apache Tomcat 6.0 - Realm Configuration HOW-TO [online].[cit. 15. června 2010]. Dostupné z URL: <http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html>. [11] Keytool - Key and Certificate Management Tool [online].[cit. 2. listopadu 2010]. Dostupné z URL: <http://download.oracle.com/javase/6/docs/technotes/tools/windows/keytool.html/>. [12] Apache Tomcat 6.0 - SSL Configuration HOW-TO [online].[cit. 10. ledna 2011]. Dostupné z URL: <http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html>. [13] Using Deployment Descriptors to Secure Web Applications - The Java EE 6 Tutorial, Volume I [online].[cit. 1. ledna 2011]. Dostupné z URL: <http://download.oracle.com/docs/cd/e19226-01/820-7627/bncbe/index.html >. [14] How the Shibbolets works [online].[cit. 16. května 2011]. Dostupné z URL: <https://wiki.shibboleth.net/confluence/display/shib2/flowsandconfig>. [15] Konfigurace Shibboleth SP 2.4.x [online].[cit. 16. května 2011]. Dostupné z URL: <http://www.eduid.cz/wiki/eduid/admins/howto/deploy/sp/config/common/index>. 31

Dodatek A Příklad části souboru web.xml věnující se zabezpečení. <security-constraint> <display-name>constraint1</display-name> <web-resource-collection> <web-resource-name>security</web-resource-name> <description/> <url-pattern>/security</url-pattern> </web-resource-collection> <auth-constraint> <role-name>user</role-name> </auth-constraint> <user-data-constraint> <description/> <transport-guarantee>none</transport-guarantee> </user-data-constraint> </security-constraint> <login-config> <auth-method>form</auth-method> <form-login-config> <form-login-page>/login.jsp</form-login-page> <form-error-page>/error.jsp</form-error-page> </form-login-config> </login-config> <security-role> <description/> <role-name>user</role-name> </security-role> A

Dodatek B Po vstupu na webové stránky, má návštěvník možnost se přihlásit buď pomocí původního přihlašovacího systému nebo použít k při- - hlášení Shibboleth. Při volbě přihlášení pomocí Shibbolethu, ho poskytovatel slu-žeb přesměruje na poskytovatele identit, kde se uživatel může při-hlásit pod svým účtem. Pokud se přihlásí úspěšně, poskytovatel identit ho přesměruje zpět na původní stránku, ze které byl na IdP přesměrován, kde webová aplikace již pozná, že je uživatel správně přihlášen a zobra-zí mu obsah určený pro přihláše-ného uživatele. B