eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Autentiza£ní metody webových aplikací Ji°í pa£ek
Vedoucí práce:
Ing. Ji°í Mlejnek
Studijní program: Softwarové technologie a management, Bakalá°ský
Obor: Softwarové inºenýrství
29. kv¥tna 2010
iv
v
Pod¥kování Rád bych pod¥koval vedoucímu práce Ing. Ji°ímu Mlejnkovi za £as, který mi v¥noval p°i konzultacích a za jeho cenné p°ipomínky k implementaci této práce. Dále pak mým rodi£·m za poskytnutí studijního prostoru p°i psaní této práce. V neposlední °ade bych cht¥l pod¥kovat koleg·m z týmu SWINPRO za kvalitní spolupráci, zejména pak kolegovi Mat¥ji Plchovi za jeho neocenitelné rady k administraci systému.
vi
vii
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
V Praze dne 27. 5. 2010
.............................................................
viii
Abstract This thesis provides design of authentication interface for the SWINPRO system. After brief overview of web-based authentication methods, aims to description of the Shibboleth system architecture. Afterward describes the deployment of this authentication system more precisely. Second part of this thesis deals with realization of LDAP authentication mechanism for SWINPRO application. In the end, this thesis aims to access control capabilites of Subversion repositories.
Abstrakt Tato práce se zabývá návrhem autentiza£ního rozhraní systému pro správu projekt· SWINPRO. Po stru£ném p°ehledu autentiza£ních °e²ení následuje popis architektury systému Shibboleth. Následn¥ popisuje detailní postup nasazení tohoto systému pro ov¥°ování uºivatel· v aplikaci SWINPRO. Druhá £ást této práce se zabývá implementací p°ihla²ovacího mechanizmu LDAP pro aplikaci SWINPRO. Na záv¥r jsou popsány moºnosti °ízení p°ístupu uºivatel· do SVN repozitá°· a je p°edvedena realizace tohoto °ízení z prost°edí systému SWINPRO.
ix
x
Obsah 1 Úvod
1
2 P°ehled autentiza£ních °e²ení
3
2.1
Terminologie
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
Autentizace v aplikacích na platform¥ Java
. . . . . . . . . . . . . . . . . . .
4
2.3
Mechanizmus Single sign-on . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.1
De nice
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.2
P°ehled existujících implementací . . . . . . . . . . . . . . . . . . . . .
6
3 Systém Shibboleth 3.1
3.2
3
9
Architektura systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.1.1
Identity Provider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2
Service Provider
3.1.3
Shibboleth Federace
3.1.4
Sluºba WAYF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
Princip funkce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Výb¥r bezpe£nostního rámce aplikace SWINPRO
9 10 10
13
4.1
Poºadované funkce
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.2
Autentiza£ní rozhraní aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.2.1
Dostupné technologie . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
4.2.2
Výb¥r autentiza£ního frameworku . . . . . . . . . . . . . . . . . . . . .
14
Spring Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.3
4.3.1
P°ehled moºností frameworku . . . . . . . . . . . . . . . . . . . . . . .
15
4.3.2
Princip funkce
15
4.3.3
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2.1
Hlavní komponenty frameworku
4.3.2.2
Filtrování HTTP poºadavk·
. . . . . . . . . . . . . . . .
15
. . . . . . . . . . . . . . . . . .
16
Kon gurace bezpe£nostního kontextu . . . . . . . . . . . . . . . . . . .
18
5 Autentizace v systému FELid
21
5.1
Systém FELid . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.2
Kon gurace Shibboleth SP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5.3
Nastavení Spring Security
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.3.1
Rozbor °e²ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.3.2
Alternativní °e²ení
27
5.3.3
Realizace vybraného °e²ení
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
xi
27
xii
OBSAH
5.4
Testování výsledného sestavení
. . . . . . . . . . . . . . . . . . . . . . . . . .
6 Autentizace proti adresá°ové sluºb¥ LDAP
30
31
6.1
Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
6.2
Instalace a kon gurace testovacího LDAP serveru . . . . . . . . . . . . . . . .
31
6.3
Autentiza£ní LDAP modul aplikace SWINPRO
6.4
Testování výsledného sestavení
. . . . . . . . . . . . . . . . .
32
. . . . . . . . . . . . . . . . . . . . . . . . . .
34
7 ízení p°ístupu do SVN repozitá°·
35
7.1
Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
7.2
Analýza °e²ení
35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2.1
Princip zabezpe£ení
7.2.2
Návrh °e²ení
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
7.3
Realizace
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
7.4
Testování
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
8 Záv¥r
41
8.1
Zhodnocení dosaºených výsledk·
. . . . . . . . . . . . . . . . . . . . . . . . .
41
8.2
Diskuze nabízejících se vylep²ení
. . . . . . . . . . . . . . . . . . . . . . . . .
41
8.3
Osobní p°ínos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
Literatura
43
A Instala£ní p°íru£ka
47
A.1
A.2
Systém Shibboleth
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
A.1.1
Kompilace a instalace systému
. . . . . . . . . . . . . . . . . . . . . .
47
A.1.2
Kon gurace Apache modulu modshib . . . . . . . . . . . . . . . . . . .
49
A.1.3
Kon gurace sluºby shibd . . . . . . . . . . . . . . . . . . . . . . . . . .
49
A.1.4
Kon gurace Shibboleth rozhraní aplikace SWINPRO . . . . . . . . . .
51
Nastavení LDAP autentizace
. . . . . . . . . . . . . . . . . . . . . . . . . . .
52
A.2.1
Instalace a kon gurace sluºby LDAP . . . . . . . . . . . . . . . . . . .
52
A.2.2
Kon gurace LDAP rozhraní aplikace SWINPRO
53
. . . . . . . . . . . .
B Seznam pouºitých zkratek
55
C Obsah CD
57
Seznam obrázk· 3.1
Obecné schéma autentizace uºivatele systémem Shibboleth [27]
. . . . . . . .
11
4.1
Obecnné schéma autentizace Spring Security . . . . . . . . . . . . . . . . . . .
17
4.2
Vykonávání ltr· Spring Security . . . . . . . . . . . . . . . . . . . . . . . . .
18
5.1
P°ihla²ovací sekvence Shibboleth komponent . . . . . . . . . . . . . . . . . . .
28
5.2
HTTP komunikace autentiza£ního procesu . . . . . . . . . . . . . . . . . . . .
29
6.1
Struktura testovacího LDAP adresá°e . . . . . . . . . . . . . . . . . . . . . . .
32
6.2
P°ihla²ovací sekvence LDAP autentizace . . . . . . . . . . . . . . . . . . . . .
34
7.1
Pr·b¥h vykonání svnaccess.py skriptu
39
xiii
. . . . . . . . . . . . . . . . . . . . . .
xiv
SEZNAM OBRÁZK
Seznam tabulek 5.1
Seznam atribut· poskytovaných systémem FELid [10]
A.1
Prerekvizity pro kompilaci systému Shibboleth[11]
xv
. . . . . . . . . . . . .
24
. . . . . . . . . . . . . . .
47
xvi
SEZNAM TABULEK
Kapitola 1
Úvod Kdyº byl po£átkem zimního semestru akademického roku 2009/2010 p°edloºen návrh na vytvo°ení systému pro správu projekt· SWINPRO, jedna z prvotních otázek, která byla projednávána se zadavatelem, byl zp·sob autentizace uºivatel· v systému s nímº bylo úzce spojený i zp·sob vytvá°ení nových ú£t· v tomto sytému. Detailní analýzou poºadavk· na zabezpe£ení aplikace SWINPRO se zabývá diplomová práce[12] mého kolegy Zde¬ka Ryboly. Úkolem mojí práce je analyzovat tyto poºadavky po technologické stránce a uvést zde jejich °e²ení (více v kapitole 4. podkapitole 1.). Jednou z alternativ autentizace uºivatel·, která v²ak byla hned z po£átku zavrºena bylo ov¥°ování uºivatel· oproti univerzitnímu informa£nímu systému KOS. Ten v²ak disponuje pom¥rn¥ p°ísnou bezpe£nostní politikou a získat oprávn¥ní pro napojení vlastní aplikace na tento systém je velmi obtíºné, ne li zhola nemoºné. Jako optimáln¥ realizovatelná varianta se nakonec ukázala moºnost p°ipojení aplikace SWINPRO do federace FELid, která je postavena na základech architektury Shibboleth. Popis realizace tohoto p°ipojení je jádrem této práce a je mu v¥nována nejv¥t²í £ást textu. Po zprovozn¥ní tohoto typu autentizace byl vznesen poºadavek na nasazení této aplikace i na Fakult¥ informa£ních technologií VUT v Praze. V jejím prost°edí v²ak neexistuje ºádná infrastruktura, která by byla se systémem Shibboleth kompatibilní. Proto byly autentiza£ní schopnosti aplikace SWINPRO dopln¥ny o ov¥°ování oproti adresá°ové sluºb¥ LDAP v níº mají studenti a zam¥stnanci FIT své osobní ú£ty.
1
2
KAPITOLA 1. ÚVOD
Kapitola 2
P°ehled autentiza£ních °e²ení 2.1 Terminologie V celém tomto textu je pracováno se st¥ºejními termíny jako je autentizace a autorizace. I kdyº jsou tyto pojmy obecn¥ známé, p°esto povaºuji za nutné je zde up°esnit, abych zabránil pozd¥j²ím faktickým nesrovnalostem v textu.
Autentizace Termínem
autentizace
rozumíme proces ov¥°ení proklamované identity subjektu.[18] Tento
proces m·ºe být uskute£n¥n ov¥°ením jednoho £i více faktor·:
•
vlastnictví p°edm¥t, který subjekt vlastní (nap°. identi ka£ní kartu)
•
znalost informace, kterou subjekt zná (nap°. heslo, PIN kód)
•
osobní charakteristika biometrický prvek jedine£n¥ identi kující subjekt (otisk prstu, sken duhovky)
Pro dosaºení vy²²í úrovn¥ zabezpe£ení autentiza£ního procesu se £asto vý²e zmín¥né faktory kombinují. Nap°íklad p°i výb¥ru z bankomatu je nutné pouºít platební kartu (n¥co, co mám) a zadat £íselný kód - PIN (n¥co, co znám). asto v²ak jednostranná autentizace (tedy ov¥°ení klienta) není posta£ující. Pro opravdu zabezpe£enou komunikaci, je ve v¥t²in¥ p°ípad· vyºadováno, i ov¥°ení identity serveru. To je velmi £asto °e²ení serverovými certi káty vyuºívajících technologií asymetrického ²ifrování. Tento zp·sob ochrany slouºí jako prost°edek k zabrán¥ní útok· prost°edníka zabra¬uje zejména útok·m prost°edníka
1 . Tato problematika je v²ak nad rámec této bakalá°ské práce
a není pot°eba se jí blíºe zaobírat. 1
tzv. Man-in-the-middle útok
3
4
KAPITOLA 2. PEHLED AUTENTIZANÍCH EENÍ
Autorizace Autorizace
je proces, který nastupuje vºdy aº po autentizaci. Pracuje s jiº prokázanou iden-
titou a slouºí k p°id¥lení oprávn¥ní vyuºívat sluºby, které systém nabízí. Nap°íklad autorizace v prost°edí více uºivatelského opera£ního systému, si lze p°edstavit jako proces ur£ení, ke kterým adresá°·m je uºivateli umoºn¥no p°istupovat nebo které aplikace m·ºe uºivatel spou²t¥t.[18]
2.2 Autentizace v aplikacích na platform¥ Java Autentiza£ní metody je velice ²iroký pojem a to i kdy je jeho rozsah zúºen metody pouºitelné u webových aplikacích. Proto jsem byl p°i výb¥ru autentiza£ních metod postaven p°ed otázku, z jakého úhlu mám zde poskytnout pohled na sou£asné trendy v tomto oboru. Necht¥l jsem aby se z této £ásti bakalá°ské práce stal jakýsi pahýl, který je zde jen proto, ºe to p°ikazuje zadání práce. Rad¥ji jsem se snaºil dbát na moºnost pouºití zde zmín¥ných poznatk· v dal²ích £ástech text. Protoºe nemalá £ást implementace této bakalá°ské práce se týká vytvo°ení vytvo°ení autentiza£ního rozhraní v aplikaci SWINPRO, která je napsaná v programovacím jazyce Java, je i tato podkapitola v¥nována p°ehledu moºností autentizace na této platform¥. Poznatky zmín¥né v této podkapitole se tak stanou základem p°i výb¥ru autentiza£ního °e²ení v systému SWINPRO (viz. sekce 4.2.2). Celá tato kapitola p°edpokládá základní znalost enterprise edice jazyku Java (JavaEE). Bohuºel zde není dostatek prostoru pro vysv¥tlení v²ech termín·, které jsou zde zmi¬ovány.
Zabezpe£ení s pouºitím servletových ltr· Jedná se o zcela základní zp·sob zabezpe£ení webových aplikací. Toto °e²ení se opírá o speci kaci Java Servlet Speci cation (viz. [6]) Servletový lter je speciální t°ída implementující rozhraní jeho metodu
doFilter.
Filter
a de nující mimo jiné
Tato metoda je volána p°i kaºdém novém p°íchozím HTTP po-
ºadavku. Jejím parametry jsou mimo jiné objektová reprezentace p°íchozího poºadavku (ServletRequest) a objektová reprezentace odchozí odpov¥di, která bude navrácena uºi-
2 a následn¥ na n¥j zareago-
vateli. Obecnou funkcí ltru je analyzovat p°íchozí poºadavek
vat nastavením p°íslu²né HTTP odpov¥di (typicky jde o p°esm¥rování prohlíºe£e, nap°.: na stránku s p°ihla²ovacím formulá°em). Podstatou vyuºití ltr· pro pot°eba autentizace je fakt, ºe se servletové ltry vºdy vykovávají je²t¥
p°edtím
neº je aktivován Javovský servlet, který je poºádán o navrácení po-
3 stránku nebo jakýkoliv jiný obsah spravovaný
ºadovaného zdroje (a´ uº se jedná o JSP servletovým kontejnerem).
Autentiza£ní schéma p°i pouºití této metody vychází tedy z odchycení p°íchozího HTTP poºadavku a kontroly zda je uºivatel odesílající tento poºadavek
4 . Pokud je uºivatel shledán
Nap°íklad ov¥°it zda se snaºí p°istoupit na URL n¥jaké privátní zabezpe£eného Java Server Pages 4 toho m·ºe být dosaºeno °adou nejr·zn¥j²ích zp·sob·, typickým p°íkladem takové kontroly je ov¥°ení n¥jakého identi kujícího tokenu nastaveného v session 2 3
2.3. MECHANIZMUS SINGLE SIGN-ON
5
oprávn¥ným pouºít poºadovaný zdroj, pokra£uje servlet v £innosti voláním dal²ího servletu v °ad¥. Pokud je uºivatel nep°ihlá²ený je p°esm¥rován voláním funkce
redirect()
na p°i-
hla²ovací stránku[3]. I kdyº toto °e²ení ve v¥t²in¥ reálných aplikací neposta£uje a je vhodné spí²e pro aplikace men²ího rozsahu, je pot°eba upozornit na fakt, ºe tém¥° v²echny bezpe£nostní frameworky dostupné na platform¥ Java na tomto °e²ení staví a dále jej rozvád¥jí[3].
JAAS 5
Daleko robustn¥j²í a komplexn¥j²í °e²ení podává bezpe£nostní balí£ek JAAS , který je sou£ástí rozsáhlého frameworku Java SE Security vydávaného spole£ností Sun Microsystems (nyní Oracle). Snahou JAAS je poskytovat ucelené standardizované autentiza£ní °e²ení, které
6
lze snadno implementovat v celé ²kále Javovských technologií . Základní vlastností tohoto frameworku je modulárnost jeho autentiz£ních °e²ení a abstrakce nad nimi. Díky tomu lze nap°íklad zcela transparentn¥ p°idávat £i odebírat jednotlivé autentiza£ní moduly (LoginModule) a tím m¥nit p°ihla²ovací mechanizmy aplikace. Tyto zm¥ny jsou navíc realizovány pouhým nastavením kon gura£ních soubor· frameworku a není tedy vyºadováno jakéhokoliv zásahu do zdrojových kód· aplikace[20]. e²ení poskytované rámcem JAAS není vázáno jen na prost°edí webových aplikací, ale lze je nasadit i na
desktopové
aplikace zpravidla fungující jako tenký klient[20].
Spring Security Tento bezpe£nostní rámec je podrobn¥ji popisován v kapitole 4.3.
Dal²í bezpe£nostní frameworky platformy Java Následující seznam uvádí stru£ný vý£et bezpe£nostních °e²ení dostupných v technologiích pracujících na platform¥ Java.
•
Apache Shiro (d°íve známé jako Apache jSecurity)
•
jGuard
•
OWASP Enterprise Security API
•
XWS-Security (zabezpe£ení SOAP zpráv)
2.3 Mechanizmus Single sign-on 2.3.1 De nice Single sign-on (SSO) je mechanizmus umoº¬ující subjektu autentizovat se jednou do systému a poté p°istupovat k libovolným zdroj·m, bez nutnosti op¥tovné autentizace[14]. 5 6
Java Authentication and Authorization Service JAAS je podporován tém¥° ve v²ech servletových kontejnerech a aplika£ních serverech
6
KAPITOLA 2. PEHLED AUTENTIZANÍCH EENÍ
Tento p°ístup s sebou p°iná²í i hlavní nevýhodu tohoto mechanizmu, která se projeví v p°ípad¥, kdy je ú£et uºivatele kompromitován (nap°. prolomením hesla). V tomto okamºiku získává úto£ník p°ístup ke v²em aplikacím a sluºbám, ke kterým uºivatel s tímto ú£tem p°istupoval[14]. Mezi výhody pouºívání tohoto mechanizmu pat°í, krom¥ jiº zmín¥ného zvý²ení uºivatelského komfortu odpadnutím nutnosti op¥tovn¥ se p°ihla²ovat, i rapidní sníºení nárok· na administraci uºivatelských ú£t·. V p°ípad¥ sluºeb, které tento mechanizmus nepouºívají, je totiº nezbytné udrºovat celou databázi uºivatelských ú£t·. S tím jsou v²ak spojeny vysoké náklady na administraci, zabezpe£ení a poskytování dal²ích sluºeb jako je nap°íklad obnova hesla, £i jiný druh uºivatelské podpory. To v²e s pouºitím Single sign-on odpadá, protoºe jsou v²echny ú£ty udrºovány pouze na jediném míst¥ spravovaném jedinou centrální autoritou a ostatní sluºby je pak jen vyuºívají[25].
2.3.2 P°ehled existujících implementací V této podkapitole uvádím n¥kolik znám¥j²ích autentiza£ních mechanizm·, které n¥jakým zp·sobem implementují lozo i mechanizmu SSO.
Kerberos Kerberos pat°í mezi nejznám¥j²ím autentiza£ním protokolem podporující SSO. Kerberos je závislý na metodách symetrické kryptogra e, zejména na ²ifrovacích algoritmu DES a AES[14]. Kerberos podporuje SSO jiº z podstaty samotného ov¥°ovacího mechanizmu. Ten lze velmi stru£n¥ shrnout v následujících krocích[14]. 1. Uºivatel zadá p°ihla²ovací údaje do speciálního Kerberos klienta
7
2. Klient tyto údaje za²ifruje a ode²le je komponent¥ KDC
8
3. KDC tyto údaje ov¥°í a následn¥ vygeneruje za²ifrovaný TGT , který ode²le zp¥t na klienta 4. Klient si TGT uloºí do svého lokálního úloºi²t¥ a pouºívá jej dokud trvá jeho platnost. Následující sled operací probíhá v p°ípad¥ kdy chce uºivatel pouºít TGT k p°ístupu k n¥jaké kerberizované sluºb¥. 1. Klient ode²le TGT zp¥t na KDC spolu s oznámením, ºe jej hodlá vyuºít pro p°ístup k n¥jaké sluºb¥ 2. KDC zkontroluje validitu tohoto TGT a ov¥°í, zda je ºádající uºivatel p°ítomen v seznamu povolených uºivatel· dané sluºby a tím pádem ji m·ºe pouºít 3. Po tomto ov¥°ení vygeneruje takzvaný Service ticket (ST) a ode²le jej zp¥t na klienta
KDC - Key distribution center. Tuto komponentu si lze p°edstavit jako úloºi²t¥ uºivatelských ú£t·. Ticket Granting Ticket - jedná se o autentiza£ní token, který jednozna£n¥ a nezpochybniteln¥ identi kuje uºivatele, a pozd¥ji je pouºit k prop·j£ení práv p°ístupu k sluºbám, aniº by byly od uºivatele op¥tovn¥ vyºadovány p°ihla²ovací údaje. 7 8
2.3. MECHANIZMUS SINGLE SIGN-ON
7
4. Ten pak po navázání spojení s poºadovanou sluºbu ji tento ticket ode²le a ta je následn¥ schopná si jej ov¥°it a umoºnit uºivateli p°ihlá²ení bez nutnosti zadání dal²ích dopl¬ujících údaj·. Nasazení autentiza£ního systému Kerberos v prost°edí webových aplikací v²ak s sebou nese zna£ná omezení. Klientský prohlíºe£ p°istupující na kerberizované webové stránky totiº musí podporovat propojení s klientem systému Kerberos, který musí být nainstalován na po£íta£i uºivatele. Toto propojení v²ak není dostupné ve v²ech prohlíºe£ích. Nap°íklad Internet Explorer, £i prohlíºe£ Safari je podporují bez jakékoliv nutné kon gurace. Av²ak v p°ípad¥ prohlíºe£e Firefox je pot°eba zasáhnou do jeho kon gura£ních nastavení (coº m·ºe být pro laického uºivatele problém) a prohlíºe£ Opera tuto podporu prohlíºe£ v·bec neposkytuje[22]. Proto je autentiza£ní °e²ení nasazováno zejména v intranetových aplikacích ve remním prost°edí, kde není problém de novat jednotné nastavení klientských stanic v£etn¥ p°edinstalovaného klienta Kerberos a p°edkon gurovaného webového prohlíºe£e.
JOSSO Java Open Single Sign-On je open source °e²ení pro webové enterprise aplikace postavené na platform¥ Java. Mezi jeho hlavní vlastnosti pat°í podpora ²iroké ²kály aplika£ních ser-
9
ver· nebo servletových kontejner· . Dal²í významnou vlastností je t°eba kvalitní integrace s ostatními bezpe£nostními frameworky jako jsou JAAS, Spring Security a dal²í[21].
OpenSSO OpenSSO je komplexní robustní autentiza£ní infrastrukturu vyvíjenou donedávna rmou Sun Microsystems. Po koupení rmy Sun rmou Oracle, bylo v únoru 2010 oznámeno, ºe OpenSSO jiº nadále nebude strategickým produktem rmy Oracle a jeho podporu p°evezme norská rma ForgeRock[24].
9
nap°.: Apache Tomcat, JBoss Application Server, BEA WebLogic nebo Websphere CE
8
KAPITOLA 2. PEHLED AUTENTIZANÍCH EENÍ
Kapitola 3
Systém Shibboleth Shibboleth je open source systém realizující
Single-sign on
autentizaci pro webové aplikace.
Projekt Shibboleth byl zaloºen v roce 2000 iniciativou MACE (Middleware Architecture Committee for Education) za ú£elem vytvo°ení jednotné infrastruktury pro autentizaci a °ízení p°ístup· v oblasti výzkumných a vzd¥lávacích institucí[32]. Systém byl navrºen s ohledem na dodrºování standard· za ú£elem dosaºení interoperability s ostatními systémy pro správu identit. Tato vlastnost je zaru£ena dodrºováním striktní kompatibility se standardem SAML, ze kterého Shibboleth p°ejímá a realizuje pro l WebSSO a pro l pro vým¥nu atribut· (atribut-exchange pro le)[32]. Díky tomu je moºné jej propojit s ostatními systémy pro správu identit, které jsou kompatibilní se speci kacím SAML[32].
3.1 Architektura systému Architektura systému Shibboleth de nuje dv¥ hlavní komponenty zaji²´ující SSO autentizaci pro webové aplikace. První komponentou je Identity Provider (IdP) provozovaný domovskou organizací (nap°. univerzitou, ústavem apod.) Dal²í komponentou je tzv. service provider (SP), který je nasazován na stran¥ aplikací vyuºívajících autentiza£ní sluºby IdP.
3.1.1 Identity Provider Identity Provider, je softwarová komponenta, která má na starost autentizaci uºivatel· oproti lokálnímu datovému úloºi²ti uºivatelských ú£t·. Protoºe zna£ná £ást aplikací vyuºívajících ov¥°ovací sluºby Shibboleth vyºadují dodate£né informace o ov¥°eném uºivateli jako jsou nap°íklad: jeho celé jméno, název pracovi²t¥ nebo katedry, email, telefon apod.), umoº¬uje IdP odbavovat poºadavky na tyto dopl¬ující atributy[26].
1
Kaºdý identity provider je jednozna£n¥ ur£en svým providerId, které má podobu URI . Tento identi kátor musí být jedine£ný v celé federaci[26]. 1
Uniform Resource Identi er
9
10
KAPITOLA 3. SYSTÉM SHIBBOLETH
3.1.2 Service Provider Service provider je entita mající na starost správu zabezpe£ených zdroj·. To zda bude uºivateli umoºn¥n k t¥mto zdroj·m p°ístup závisí na ov¥°eních (SAML Assertions), které si service provider vyºádá od poskytovatele identity[26].
3.1.3 Shibboleth Federace Federace v architektu°e Systému Shibboleth p°edstavuje dohodu mezi poskytovateli identit (IdP) a poskytovateli sluºeb (SP). Aby tato dohoda mohla být uskute£n¥na, musí se v²echny zú£astn¥né subjekty shodnout na jednotné sad¥ atribut· de nujících uºivatele a na schématu, které tyto atributy popisuje[29]. Princip federace vysv¥tlím na následujícím p°íklad¥: Uvaºujme studenta univerzity, která je p°ipojená do federace (jinými slovy provozuje IdP p°ipojené do federace). Tento student by cht¥l p°istupovat ke sluºb¥ poskytované cizí univerzitou (nap°. k elektronické knihovn¥). Tato univerzita je taktéº £lenem této federace a je k ní p°ipojená i sluºba touto univerzitou provozovaná. Studentovi pak sta£í, aby se p°ihlásil (ov¥°il) u svého poskytovatele identit a na základ¥ dohody de nované mezi jeho univerzitou a federací je mu umoºn¥n p°ístup i k sluºbám poskytovaným jinými univerzitami p°ipojenými do federace. V zásad¥ lze °íci, ºe federace slouºí k zjednodu²ení vztah· mezi sluºbami a ov¥°ovacími autoritami r·zných subjekt· (organizací, podnik· apod.). Tam, kde by musela kaºdá sluºba za°izovat dohodu s kaºdým poskytovatelem identit zvlá²´, sta£í nyní aby uzav°ela pouze jedinou úmluvu s federací. Tím pak automaticky garantuje p°ístup v²em £len·m federace.
3.1.4 Sluºba WAYF Sluºba WAYF poskytuje uºivateli, který se chce p°ipojit do federace s více poskytovateli identit, výb¥r svojí domovské organizace, u které je registrován. Takovou federací je nap°íklad
eduID.cz
provozovaná organizací CESNET, sdruºující n¥které z £eských univerzit, vysokých
²kol a ústav·.
3.2 Princip funkce Na následujícím p°íkladu je popsán ukázkový scéná°, popisující p°ístup k zdroji chrán¥nému systémem Shibboleth a ov¥°ení proklamované identity uºivatele u IdP jeho domovské organizace. Aktéry v tomto p°ípad¥ jsou tedy webový prohlíºe£ na stran¥ klienta, service provider na stran¥ poºadovaného zdroje a identity provider domovské organizace. Tento p°íklad byl spolu s obrázkem 3.1 popisujícím komunikaci jednotlivých komponent p°evzat z [27].
P°ístup k chrán¥nému zdroji Autentiza£ní mechanizmus je iniciován webovým prohlíºe£em odesláním HTTP poºadavku na obdrºení zdroje chrán¥ného SP (krok 1). Server na poºadavek odpoví p°esm¥rováním webového prohlíºe£e na URL adresu sluºby WAYF. Ta prohlíºe£i vrátí formulá° se seznamem domovských organizací pat°ících do federace a tento formulá° ode²le zp¥t prohlíºe£i (kroky 2 a 3).
3.2. PRINCIP FUNKCE
11
Obrázek 3.1: Obecné schéma autentizace uºivatele systémem Shibboleth [27]
Autentizace u domovského IdP V této £ásti autentiza£ního procesu probíhá ov¥°ení identity uºivatele u své domovské organizace. Nejd°íve je ale nezbytné, aby uºivatel zvolil ze seznamu domovských organizací obdrºeného v kroku 3 tu, u níº má uºivatel vytvo°ený ú£et a svoji volbu odeslal zp¥t sluºb¥ WAYF (krok 4). Ta prohlíºe£ p°esm¥ruje na adresu SSO sluºby vybraného IdP. Spolu s tímto krokem vybranou volbu uloºí do cookie prohlíºe£e[7] tak, aby mohl být uºivatel p°i dal²ím pokusu o p°ihlá²ení automaticky p°esm¥rován na svého domovského poskytovatele identit (krok 5). Po p°esm¥rování ov¥°í SSO komponenta IdP zda jiº uºivatel nemá nastavený platný autentiza£ní
token, který mu byl uloºen do cookie prohlíºe£e p°i posledním p°ihlá²ení. Tento
token je ve skute£nosti SAML zpráva identi kující uºivatele a obsahující mimo jiné informace, kdy a kým byl ov¥°en a dobu platnosti tohoto ov¥°ení. Pokud je tento autentiza£ní token shledán platný, pak není od uºivatele poºadováno zadání p°ihla²ovacích údaj· a tím pádem m·ºe být automaticky p°esm¥rován zp¥t na service providera. V tomto p°ípad¥ se proces p°ihlá²ení jeví uºivateli jako zcela transparentní. V p°ípad¥, ºe uºivatel tento token v cookies nemá nebo vypr²ela jeho platnost, je uºivateli zobrazen formulá° pro vypln¥ní p°ihla²ovacích údaj· (krok 7). Uºivatel vyplní do formulá°e své p°ihla²ovací údaje a ode²le je zp¥t IdP, který zadané
12
KAPITOLA 3. SYSTÉM SHIBBOLETH
informace vzáp¥tí ov¥°í oproti svému lokálnímu datovému úloºi²ti
2 (krok 8).
Po vypln¥ní a odeslání korektních údaj· je prohlíºe£ p°esm¥rován na SSO sluºbu poskytovatele identity (známou také jako Handle Server) a zárove¬ s p°esm¥rováním je mu uloºen autentiza£ní token do
cookies
prohlíºe£e informující tuto sluºbu o úsp¥²nosti ov¥°ení uºiva-
tele (krok 9). Handle Server následovn¥ vygeneruje SAML Response zprávu (tzv. Handle) obsahující SAML Assertion informující service providera, ºe byl daný uºivatel korektn¥ autentizován svojí domovskou organizací. Spolu s touto zprávou je tedy prohlíºe£ automaticky p°esm¥rován na ACS (Assertion Consumer Service) sluºbu service providera, která ov¥°í zda je obdrºená SAML zpráva validní (krok 10).
Poºadavek na dopl¬ující atributy Jak jiº bylo zmín¥no d°íve, service provider zpravidla vyºaduje po IdP dopl¬ující informace (atributy) o ov¥°eném uºivateli. Jejich vyºádání je iniciováno zasláním poºadavku obsahujícím zprávu obdrºenou od IdP v p°edchozím kroku. Poté co IdP zkontroluje platnost tohoto poºadavku, získá z lokálního úloºi²t¥ informace o uºivateli, které op¥t v podob¥ SAML odpov¥di ode²le zp¥t poskytovateli sluºby(kroky 11 a 12). Tato komunikace probíhá na pozadí celého procesu a uºivatel do ní není nijak zapojen. V samotném záv¥ru je uºivateli povolen p°ístup k chrán¥nému zdroji, který poºadoval a je na n¥j p°esm¥rován (krok 13). V tomto moment¥ jsou také umíst¥ny atributy obdrºené v kroku 11 a 12 do
cookies
prohlíºe£e uºivatele. Alternativn¥ je moºné tyto atributy p°ená²et
i ve form¥ HTTP hlavi£ek.
coº m·ºe být nap°íklad LDAP, rela£ní databáze apod. IdP není v tomto ohledu vázán na n¥jaké konkrétní °e²ení 2
Kapitola 4
Výb¥r bezpe£nostního rámce aplikace SWINPRO 4.1 Poºadované funkce P°i de nování poºadavk·, které musí navrºené °e²ení p°ihla²ování spl¬ovat bylo vycházeno z analýzy systému a z poºadavk· na systém, které s °e²eným problémem autentizace p°ímo souvisely. Tuto analýzu provád¥l kolega Zden¥k Rybola v rámci své diplomové práce, a proto pro bliº²í seznámení s t¥mito poºadavky odkazuji na tuto práci[12]. Nejd·leºit¥j²ím poºadavkem byla moºnost automatického vytvo°ení uºivatelského ú£tu po prvním p°ihlá²ení uºivatele do systému. Tato metoda tedy p°edpokládá, ºe identita uºivatele byla jiº p°edtím ov¥°ena n¥jakou d·v¥ryhodnou autoritou, v tomto p°ípad¥ systémem FELid, a uºivateli je tedy vytvo°en ú£et a je mu povolen p°ístup do aplikace. Pro vytvo°ení uºivatelského ú£tu (pro lu) jsou v²ak nutné dopl¬ující informace o uºivateli, jmenovit¥: fakultní p°ihla²ovací jméno, k°estní jméno a p°íjmení s diakritikou a fakultní email. Po zvoleném autentiza£ním °e²ení je tedy poºadováno, aby bylo schopné tyto atributy dodat a bylo schopné iniciovat jiº p°ipravené
business
metody zaji²´ující vytvo°ení pro lu. Dal²ím
poºadavkem bylo, aby byly ur£ité stránky aplikace SWINPRO dostupné i bez p°edchozího p°ihlá²ení. V pr·b¥hu vývoje byl vznesen poºadavek na roz²í°ení moºností p°ihla²ování o ov¥°ování oproti adresá°ové sluºb¥ LDAP, tak aby mohla být aplikace SWINPRO v budoucnu snadno nasaditelná i na Fakult¥ informatiky VUT v Praze. Z tohoto d·vodu byl kladen zvý²ený d·raz na moºnost jednoduchého p°epnutí mezi ob¥ma zp·soby autentizace tak, aby bylo moºné mezi t¥mito systémy p°echázet pouhou zm¥nou kon gurace bez nutnosti zásahu do zdrojového kódu. e²ení ov¥°ování oproti LDAP serveru je popsáno v kapitole 6.
4.2 Autentiza£ní rozhraní aplikace 4.2.1 Dostupné technologie e²ení autentizace jakékoliv webové aplikace je v¥t²inou spjato s technologiemi pouºitými p°i vývoji této aplikace. Termínem pouºité technologie je v tomto p°ípad¥ my²leno nap°íklad:
13
14
KAPITOLA 4. VÝB
R BEZPENOSTNÍHO RÁMCE APLIKACE SWINPRO
programovací jazyk,
frameworky
nebo prost°edí, v rámci kterého je aplikace provozována
(server, opera£ní systém apod.) Proto je nezbytné popsat technologie stojící za vývojem aplikace SWINPRO a °e²ení navrhnout tak, aby bylo s nimi kompatibilní a pokud moºno snadno propojitelné. Systém SWINPRO je aplikace napsaná v programovacím jazyce Java na platform¥ JavaEE (d°íve známé jako J2EE). Aplikace je nasazená na servletovém kontejneru Apache Tomcat 6.0.24 b¥ºícím na opera£ním systému Debian 4.0 Etch v prost°edí virtuálního stroje Javy JRE verze 6.17.1. Na stejném stroji je také provozován server Apache verze 2.2.3, který má na starost obsluhu p°ístupu k SVN repozitá°·m a
issue tracking
systému Trac spravovaných aplikací
SWINPRO. Jádrem aplikace je aplika£ní framework Spring 2.5, z jehoº funkcí je vyuºíván zejména
IoC 1
kontejner, který propojuje jednotlivé komponenty systému. Pro prezenta£ní vrstvu je
2
pouºit framework JSF . Ostatní pouºité frameworky nebo API, pouºité nap°. pro implementaci databázové vrstvy apod., nejsou z hlediska výb¥ru autentiza£ního °e²ení relevantní, a tudíº zde nejsou uvedeny. Podrobný rozbor pouºitých technologií a architektury aplikace lze nalézt v bakalá°ské práci mého kolegy Vojt¥cha Krále[4].
4.2.2 Výb¥r autentiza£ního frameworku V kapitole 2. byl £tená° seznámen s moºnostmi zabezpe£ení aplikací platformy Java. Po dlouhé rozvaze, které z t¥chto framework· pouºít pro aplikaci SWINPRO, byli vybráni dva hlavní kandidáti. Prvním z nich byl autentiza£ní rámec JAAS. O jeho vlastnostech jiº bylo psáno v kapitole 2., tudíº není pot°eba je zde dále rozvád¥t. Co je ale pot°eba shrnout, jsou d·vody pro£ nebylo toto °e²ení p°ijato a byla dána p°ednost °e²ení, které poskytuje rámec Spring Security. Hlavním p°í£inou jeho zavrºení byl relativn¥ sloºitý zp·sob provázání
3
login modul· s business
logikou aplikace SWINPRO . Ty jsou totiº, jak jiº bylo zmín¥no, spravovány aplika£ním frameworkem Spring, potaºmo jeho
IoC
kontejnerem a jsou dostupné p°es aplika£ní kontext
frameworku. Ten by pak musel být sloºit¥
injektován
do p°ihla²ovacího modulu.
Tento problém s pouºitím Spring Security zcela odpadá, protoºe v²echny komponenty jeho autentiza£ního mechanizmu jsou zárove¬ spravovány p°ímo springovým kontextem, a tím pádem je velmi snadné do nich nastavit ostatní t°ídy z
business
vrstvy aplikace[1].
Po vyhodnocení t¥chto argument· a také s p°ihlédnutím, k mým d°ív¥j²ím zku²enostem s frameworkem Spring, jsem se nakonec p°iklonil k variant¥ nasazení Spring Security. Aby byl tento rozbor kompletní, je vhodné zde zmínit je²t¥ jednu alternativní cestu. Tato cesta je jakýmsi kompromisem mezi ob¥ma vý²e zmín¥nými variantami. Framework Spring Security totiº po£ítá se svým nasazením v aplikacích, které jiº mají implementované p°ihla²ování pomocí JAAS modul· a pot°ebují je pouze navázat na Spring. Spring Security toto °e²í sadou t°íd, které delegují autentiza£ní poºadavky na stávající JAAS moduly. Výhoda
Inversion of Control Java Server Faces 3 p°esn¥ji s komponentou AccountManager 1 2
4.3. SPRING SECURITY
15
tohoto °e²ení spo£ívá v moºnosti ponechat stávající kon gura£ní soubory bezpe£nostního frameworku JAAS[1]. V p°ípad¥ systému SWINPRO jsem v²ak nena²el ºádný racionální d·vod n¥co takového implementovat a uvádím zde tuto moºnost jen jako zajímavost.
4.3 Spring Security 4.3.1 P°ehled moºností frameworku Spring Security pat°í mezi nejvysp¥lej²í a nejroz²í°en¥j²í projekty Springového portfolia. Poskytuje komplexní °e²ení otázky zabezpe£ení
enterprise
aplikací postavených na frameworku
Spring. Mezi nabízené funkce pat°í zejména autorizace HTTP poºadavk·, podobným zp·sobem jak ji de nuje speci kace Java Servlet· (viz. [6]). Mezi dal²í moºností vyuºití toho frameworku pat°í zabezpe£ení volání metod
business
vrstvy (Service Layer Security) autori-
zací iniciujícího subjektu (uºivatele, sluºby apod.) volání nebo °ízení p°ístupu k doménovým objekt·m (Domain object instance security)[36]. Spring Security podporuje ²irokou ²kálu systém· oproti kterým m·ºe provád¥t ov¥°ování identit uºivatel·. Krom¥ standardní autentizace v·£i údaj·m uloºeným v rela£ní databázi,
4
podporuje i v¥t²inu z b¥ºn¥ pouºívaných °e²ení jako nap°íklad CAS , OpenID, LDAP £i autentizaci pomocí protokolu HTTP (HTTP Basic a HTTP Digest). P°ipravována je i podpora autentiza£ního systému Kerberos, která je v²ak zatím v ranné fázi vývoje[37]. P·vodn¥ byl tento projekt vyvíjen pod názvem Acegi Security, který si podrºel aº do verze 1.0.7. Od této verze byl pln¥ za°azen do Springového portfolia a podpora p·vodních verzi Acegi Security jiº byla ukon£ena[17]. Projekt Spring Security se v sou£asnosti nachází ve nejnov¥j²í verzi Spring Security 3.0.2. Tato verze v²ak nemohla být pouºita, protoºe je kompatibilní pouze s verzí 3.0.1 frameworku Spring Core[35], kdeºto aplikace SWINPRO je nasazená na jeho star²í verzi 2.5. Z tohoto d·vdu jsem se uchýlil k pouºití sta²í verze Spring Security 2.0.5, která je s verzí Spring 2.5 pln¥ kompatibilní[35].
4.3.2 Princip funkce V této podkapitole je stru£n¥ popsán princip funkce zabezpe£ení HTTP poºadavk· spolu s moºnostmi kon gurace. Ostatní rysy frameworku, jako nap°íklad °ízení p°ístupu k doménovým objekt·m, nejsou sou£ástí °e²ení zadaného problému, a proto zde nejsou popisovány. V¥t²ina informací v této podkapitole byla £erpána z referen£ní p°íru£ky Spring Security[1]. Funkci jednotlivých komponent Spring Security lze pozorovat na sekven£ním diagramu 4.1.
4.3.2.1 Hlavní komponenty frameworku SpringSecurityContextHolder. V n¥m jsou udrºován autentiza£ní token typu Authentication. V tomto objektu jsou obsaºeny aktuální p°ihla²oJedním z nejd·leºit¥j²ích objekt· je
vací údaje spolu s p°íznakem ur£ujícím zda jsou tyto údaje validní. Dále je v n¥m obsaºen 4
Central Authentication Service
16
KAPITOLA 4. VÝB
R BEZPENOSTNÍHO RÁMCE APLIKACE SWINPRO
seznam p°id¥lených autorit (GrantedAuthority), které reprezentují role uºivatele v systému. Dohromady tyto informace tvo°í aktuální bezpe£nostní kontext, podle kterého se dal²í £ásti bezpe£nostního systému rozhodují zda danému uºivateli p°id¥lí práva p°ístupu. Komponenta
zodpov¥dná
AuthenticationProvider. °eném
tokenu
za
ov¥°ování
t¥chto
autentiza£ních
token·
se
nazývá
Tato komponenta p°evezme vypln¥né údaje obsaºené v neov¥-
a ov¥°í je oproti úloºi²ti uºivatelských ú£t·. V p°ípad¥ úsp¥chu nastaví
tokenu
p°íkaz validity a vrátí jej zp¥t autentiza£nímu mechanizmu. B¥hem ov¥°ování správnosti údaj· je do procesu zapojena dal²í z d·leºitých komponent a to sice
UserDetailsService.
Tato komponenta má na starost nataºení dopl¬ujících informacích o uºivateli a jeho ú£t¥ (nap°íklad £íslo pracovi²t¥, telefon apod.). Tyto informace vrací v podob¥
AuthenticationProvider
UserDetails
je poté m·ºe p°ipojit k ov¥°enému autentiza£nímu
Poslední z d·leºitých komponent je
tokenu.
a
AuthenticationManager. Jeho £innost spo£ívá v udrAuthenticationProvider (pro kaºdý
ºování °et¥zu instancí t°íd implementujících rozhraní
zdroj uºiv. ú£t· jeden), kterým je p°edkládán autentiza£ní
token
za ú£elem ov¥°ení. Tím je
zaru£ena moºnost de novat vícero autentiza£ních systém· (nap°. LDAP a rela£ní databáze) sou£asn¥ a
AuthenticationManager
postupn¥ ov¥°uje p°ihla²ovací údaje proti v²em, dokud
mu n¥který z nich nepotvrdí jejich validitu.
4.3.2.2 Filtrování HTTP poºadavk· V p°edchozích odstavcích byl zmi¬ován autentiza£ní mechanizmus, který produkuje autentiza£ní tokeny. Co si pod tímto pojmem m·ºeme p°edstavit objas¬uje následující odstavec. Mechanizmus ochrany HTTP poºadavk· je °e²en sadou speciálních t°íd fungující jako servletové ltry. Tyto ltry jsou spou²t¥ny instancí Springové t°ídy
FilterChainProxy. Kaºdý
z ltr· °e²í jednu ze ²kály funkcionalit poºadovaných od autentiza£ního mechanizmu jako jsou nap°íklad p°esm¥rovávání na zabezpe£ený protokol HTTPS, udrºování autentiza£ních informací v
session
nebo samotná extrakce p°ihla²ovacích údaj· z odeslaného autentiza£-
ního formulá°e a jejich následné ov¥°ení. Nejv¥t²í výhodou tohoto °e²ení je moºnost odvození stávajících ltr· a upravení jejich chování tak aby odpovídalo poºadované funk£nosti. Následující seznam obsahuje vý£et nejd·leºit¥j²ích ltr· se°azených tak, jak jsou postupn¥ volány p°i zpracování HTTP poºadavku.
1.
ChannelProcessingFilter
je ltr vynucující automatické p°esm¥rování na ²ifrovanou
komunikaci protokolem HTTPS 2.
HttpSessionContextIntegrationFilter
má na starost napln¥ní
HTTP session na za£átku HTTP poºadavku HTTP session p°ed skon£ením poºadavku. z
3.
AuthenticationProcessingFilter mulá°em.
Z
t¥chto
údaj·
AuthenticationManageru 4.
vytvá°í
zpracovává objekt
SecurityContextu
a uloºení zm¥n SecurityContextu do
údaje
odeslané
Authentication,
p°ihla²ovacím který
dále
for-
ode²le
za ú£elem jeho ov¥°ení.
RememberMeProcessingFilter
umoº¬uje uloºení p°ihla²ovacích údaj· do
cookies,
aby mohl být uºivatel p°í²t¥ p°ihlá²en bez nutnosti tyto údaje znovu zadávat.
tak
4.3. SPRING SECURITY
17
sd SpringAuth
Browser
Spring Security Pre-Authentication Filters
AuthenticationProccessing Filter
AuthenticationManager
AuthenticationProvider(s)
UserDetailsService
loginFormSubmit() doFilter(request) extractCredentials(request)
createToken()
Authentication
setCredentials() :authToken
authenticate(authToken) loop loopThroughProv iders [authToken is NOT valid] authenticate(authToken) retrieveUser(authToken) :UserDetails
validate(authToken) :validAuthToken :validAuthToken
storeInSecurityContext(authToken)
Obrázek 4.1: Obecnné schéma autentizace Spring Security
5.
AnonymousProcessingFilter
Pokud ºádný z p°edchozích ltr· nenastavil v bezpe£-
nostním kontextu ov¥°ený autentiza£ní
6.
ExceptionTranslationFilter
token, pak je tímto ltrem vytvo°en anonymní.
zachytává výjimky vyvolané °et¥zem ltr· a p°ekládá
je na HTTP chybové odpov¥di nebo p°esm¥rování na p°ihla²ovací stránku.
7.
FilterSecurityInterceptor
je vºdy poslední z °ady ltr· a provádí kontrolu plat-
nosti autentiza£ního tokenu. Na základ¥ p°id¥lených rolí (GrantedAutheroty) v tomto tokenu rozhodne, zda je uºivatel oprávn¥n obdrºet zdroj poºadovaný v HTTP dotazu.
et¥zové volání t¥chto ltr· je znázorn¥no na následujícím sekven£ním diagramu.
18
KAPITOLA 4. VÝB
R BEZPENOSTNÍHO RÁMCE APLIKACE SWINPRO
sd SpringFiters ApacheCatalina Frontend
FilterChainProxy
HttpSessionContext Filter
AuthenticationProcessing ExceptionTranslation Filter Filter
FilterSecurityInterceptor
JSPServlet
Browser request(url) invoke(httpRequest) doFilter(request) restoreSession() doFilter(request) attemptAuth(request)
doFilter(request) doFilter(request)
resolveAuthDemand()
alt succesful authentication [negative result]
:throwException
:errorPageRedirect doRequest() [positive result] :securedPage :requestedPage
: requestedPage
:response storeSession() :response
:response
:response
Obrázek 4.2: Vykonávání ltr· Spring Security
4.3.3 Kon gurace bezpe£nostního kontextu Nastavení Spring Security je koncipováno stejn¥ jako v p°ípad¥ nastavení aplika£ního kontextu Spring Core. To znamená, ºe dovoluje vyuºívat IoC de nováním jednotlivých komponent (Spring bean) v podob¥ a jejich vzájemným propojením. Tím pádem lze do kaºdé komponenty spring security snadno
injektovat
springovou beanu zabezpe£ované aplikace. V
zásad¥ lze pouºít dva zp·soby kon gurace. Prvním je nade nování Security ltr· a ostatních security komponent jako klasické
springové beany
v contextovém XML souboru.
Toto °e²ení nám dává plnou kontrolu nad tím jak mají být jednotlivé komponenty iniciovány a jak z nich bude výsledný systém sloºen. Jako nevýhoda tohoto °e²ení se jeví zna£ná nep°ehlednost kon gura£ního souboru. Navíc ve v¥t²in¥ p°ípad· není takový stupe¬ kontroly pot°eba. Mnoho webových aplikací °e²í autentizaci jednoduchým ov¥°ením proti rela£ní databázi £i ov¥°ení oproti LDAP serveru s n¥jakým zhusta pouºívaným schématem pro ukládání ú£t·. Z tohoto d·vodu byl od verze Spring Security 2.0.5 zahrnut nový typ kon gura£ního nastavení pomocí speciálního XML jmenného prostoru, vycházející z paradigmatu
Convention
over con guration. Tento jmenný prostor de nuje speciální tagy, které v podstat¥ zastupují springových bean a tím zna£n¥ zp°ehled¬uje vý-
£ásti kon gurace jinak de nované pomocí
4.3. SPRING SECURITY
19
sledný kon gura£ní soubor, který se tak stává více £itelný. Následující p°íklad kon gura£ního souboru de nuje ukázkové nastavení autentizace Spring Security pomocí t¥chto namespac· (p°evzato z [15] a následn¥ zkráceno pro lep²í £itelnost).
<password-encoder hash="md5"/> <user-service> <user name="bob" password="foobarbaz" authorities="ROLE_SUPERVISOR, ROLE_USER" /> <user name="sam" password="swordfish" authorities="ROLE_USER" /> Pro srovnání s p°edchozí metodou kon gurace zde poukazuji na fakt, ºe pro zaji²t¥ní stejné funkcionality by bylo nutné nade novat a vzájemn¥ provázat 15 springových bean a
5
výsledný soubor by obsahoval p°es 100 °ádk· . Pouºití tohoto zp·sobu kon gurace je výhodné zejména pokud není pot°eba n¥jak zásadn¥ roz²i°ovat standardní zp·soby zabezpe£ení (nap°. LDAP, rela£ní databáze, CAS), i kdyº i to tento p°ístup umoº¬uje (nap°. vkládáním vlastních ltr·).
5
ov¥°eno podle p°íkladu uvedeného na [15]
20
KAPITOLA 4. VÝB
R BEZPENOSTNÍHO RÁMCE APLIKACE SWINPRO
Kapitola 5
Autentizace v systému FELid 5.1 Systém FELid FELid je autentiza£ní a autoriza£ní systém umoº¬ující jednotné p°ihla²ování pro webové aplikace provozované na Fakult¥ elektrotechnické. Technologicky je systém koncipován Shibboleth federace s jediným poskytovatelem identit. Ov¥°ování identity momentáln¥ probíhá v·£i univerzitnímu systému KOS a tím pádem se nem·ºe stát, ºe by uºivatel nemohl být ov¥°en, protoºe je kaºdý povinn¥ v tomto systému zanesen po nastoupení na fakultu. Systém FELid je momentáln¥ vyuºíván p°ibliºn¥ osmi webovými aplikacemi[8], mezi které pat°í t°eba Diskusní fórum FEL, CourseWare katedry kybernetiky nebo webové stránky katedry ekonomiky, manaºerství a humanitních v¥d. Systém je pln¥ kompatibilní s federací eduID.cz spravovanou organizací CESNET a po£ítá se s jeho roz²í°ením o aplikace pat°ící i do této federace[8]. Pro registraci nové aplikace do systému FELid je nezbytné poºádat administrátora systému o p°idání metadat vlastního service providera a spolu s tím dodat vygenerovaný certi kát, který bude identi kovat aplikaci v rámci federace. (více informací lze najít na stránkách FELid [10]).
5.2 Kon gurace Shibboleth SP Instalace Mezi podporované platformy, na které je Shibboleth SP portován, pat°í zejména systémy zaloºené na opera£ním systému UNIX tj. Linux, Mac OS X a Solaris[28]. Dal²í kompatibilní platformou je pak Microsoft Windows, na které m·ºe SP poskytovat autentiza£ní sluºby pro Internetovou informa£ní sluºbu (IIS)[30]. Jedná se o voln¥ dostupný software ²í°ený pod open source licencí Apache 2.0[32] na stránkách organizace Internet2, odkud je moºné jej stáhnout, bu¤ v podob¥ RPM balí£k· pro Linuxové distribuce (Red Hat Enterprise Linux, CentOS, SUSE Linux Enterprise a openSUSE)[33] nebo jako instalátory systému Windows. Pro ostatní podporované systémy a linuxové distribuce nekompatibilní s balí£kovacím systémem RPM (jako nap°. distribuce zaloºené na Debianu) jsou zde dostupné snadno zkompilovatelné zdrojové kódy v jazyce C.
21
22
KAPITOLA 5. AUTENTIZACE V SYSTÉMU FELID
Protoºe je systém SWINPRO provozován na linuxové distribuci Debian, nebylo moºné pro instalaci SP pouºít RPM balí£ky, ale bylo nutné jej zkompilovat ze zdrojových kód·. Postup kompilace zdrojového kódu a jeho instalace je závislá na vybrané linuxové distribuci a není st¥ºejní pro pochopení kon gurace SP. Z tohoto d·vodu v této £ásti není popisována a je podrobn¥ji speci kována v Dodatku A. Instala£ní p°íru£ka.
Nastavení AJP Proxy Jak bylo zmín¥no v kapitole 4. podkapitole 2.1, je systém SWINPRO provozován na javovském servletovém kontejneru Apache Tomcat. To je v²ak z hlediska nasazení SP problém, nebo´ ten je kompatibilní pouze s webovým serverem Apache, protoºe je jeho nedílnou sou£ástí modul Apache modshib, viz kapitola o Shibbolethu. Na²t¥stí existuje °e²ení pro tento problém v podob¥ AJP proxy[31]. AJP
1 je protokol zabezpe£ující p°enos HTTP poºadavk· z webového serveru na apli-
ka£ní server, který pracuje v pozadí. Webový server v tomto p°ípad¥ funguje jako proxy, která zpracovává p°íchozí HTTP poºadavky a následn¥ je
forwarduje
dál na konektor apli-
ka£ního serveru nebo servletového kontejneru. Zprávy vym¥¬ované mezi ob¥ma stranami jsou v binárním (ne£itelném) formátu zejména kv·li zaji²t¥ní vysoké výkonnosti komunikace. Typickým p°íkladem pouºití AJP je tzv.
load balancing, kde server Apache funguje jako frontend
sluºba, která dále distribuuje poºadavky na jednotlivé aplika£ní servery v pozadí[5]. V na²em p°ípad¥ je server Apache pouºíván pro ov¥°ování identity uºivatele a odbavování v²ech poºadavk· autentizace p°es Shibboleth. B¥ºné poºadavky do systému SWINPRO jsou p°eposílány pomocí AJP na Tomcat.
Kon gurace sluºby shibd Jako neocenitelná pomoc p°i nasazení této komponenty na systém Debian se ukázal návod na stránkách federace SWITCHaai[11], zabývající se kompilací a nasazením Service Providera na tuto distribuci. Kon gura£ní nastavení speci cké pro p°ipojení k systému FELid lze snadno dohledat na wiki stránkách systému[9]. Dodate£né informace o obecném nastavení systému Shibboleth jsou p°ehlednou formou zpracovány také na stránkách federace eduID.cz (viz. [19]). V¥t²inu z kon gura£ních voleb Service Providera lze nalézt v souboru shibboleth2.xml umíst¥ném v hlavním adresá°i s kon gurací systému Shibboleth (typicky /etc/shibboleth/). Tento soubor slouºí k nastavení parametr· sluºby shibd. V této podkapitole jsou z nich vybrány jen ty, jenº jsou n¥£ím d·leºité pro p°ipojení k systému FELid. Kompletní podobu kon gura£ního souboru shibboleth2.xml lze nalézt v instala£ní p°íru£ce nebo na p°iloºeném CD se zdrojovými kódy. V následujících odstavcích je popsáno jakým zp·sobem je nezbytné upravit výchozí kon gura£ní soubor, tak aby mohl být SP p°ipojen do systému FELid. Jsou zde v²ak uvedeny pouze úpravy, speci cké pro systém FELid, které je pot°eba provést nad výchozím kon gura£ním souborem dodávaným spolu s instalací
SP.
Nejd·leºit¥j²ím bodem kon gurace je nastavení tzv. EntityID. EntityID je jednozna£ný identi kátor komponenty systému Shibboleth (tedy SP nebo IdP) v rámci federace do níº 1
Apache JServ Protocol
5.2. KONFIGURACE SHIBBOLETH SP
23
je tato komponenta p°ipojena. V kon gura£ním souboru se nastavuje v podob¥ atributu
entityID
v rámci elementu
ApplicationDefaults.
<ApplicationDefaults id="default" policyId="default" entityID="https://rabbit.felk.cvut.cz/shibboleth/swinpro" homeURL="https://rabbit.felk.cvut.cz/" REMOTE_USER="felid-uid eppn persistent-id targeted-id" signing="true" encryption="true" attributePrefix="felid-" > Nyní kdyº je Service Provider °ádn¥ identi kován, je nezbytné mu dodat informace o federaci, ke které se p°ipojuje. Tyto metadata, jak jsou také nazývány, obsahují údaje o v²ech sluºbách p°ipojených do federace. Samotný SP obsahuje také svoje vlastní metadata. Aby byla pro v²echny sluºbu federace dostupná jednotná metadata, jsou tato voln¥ vystavena na adrese
https://ovt.feld.cvut.cz/felid/rep/metadata/felid-metadata.xml.
Pro p°ipojení SP aplikace SWINPRO do federace je pot°eba tyto metadata vygenerovat a zaslat je spolu s unikátním identi kátorem entityID a kontaktními informacemi administrátorovi systému FELid, který tyto informace doplní do metadat federace[10]. Pak uº jen sta£í se na tyto metadata odkázat v kon gura£ním souboru v elementu
dataProvider.
Meta-
Na metadata se odkazujeme nasm¥rováním atributu URL metadata systému
FELid. Aby bylo zabrán¥no nefunk£nosti systému p°i výpadku serveru s metadaty, je nezbytné umístit jejich kopii do adresá°e SP a tím vytvo°it jejich zálohu.
<MetadataProvider type="XML" uri="https://ovt.feld.cvut.cz/felid/rep/metadata/felid-metadata.xml" backingFilePath="felid-metadata-backup.xml" reloadInterval="7200"> Jak bylo zmín¥no v kapitole o poºadavcích na zabezpe£ení systému SWINPRO, je od p°ihla²ovacího mechanizmu poºadováno, aby po úsp¥²ném provedení p°ihlá²ení vracel údaje o uºivateli ze ²kolního úloºi²t¥ ú£t·. Proto je posledním kon gura£ním nastavením speci ckým pro kaºdou federaci je de nování mnoºiny SAML atribut·, které bude Service Provider p°i kaºdém p°ihlá²ení vyºadovat od IdP, a které mu IdP m·ºe poskytnout. O poskytnutí t¥chto údaj· bylo pot°eba poºádat administrátora systému FELid. Atributy jsou mezi IdP a SP p°ená²eny v podob¥ SAML zprávy a po zpracování této zprávy jsou systémem Shibboleth zkonvertovány do podoby HTTP hlavi£ek ve formátu
název:hodnota.
Proto sta£í Security systému aplikace (v tomto
p°ípad¥ Spring Security) tyto hlavi£ky extrahovat z p°íchozího HTTP poºadavku a na jejich základ¥ provést p°ihlá²ení na úrovni aplikace SWINPRO. Vý²e uvedené °e²ení v²ak v sob¥ skrývá potencionální bezpe£nostní trhlinu. Obsah HTTP
requestu
je totiº voln¥ dostupný jakémukoliv uºivateli a s ním tedy i HTTP hlavi£ky v tomto
dotazu odesílané. Jednodu²e by tedy sta£ilo ru£n¥ vygenerovat hlavi£ky odpovídající t¥m, které vytvá°í systém Shibboleth a následn¥ je podstr£it Spring Security systému. Ten v takovém p°ípad¥ není schopen ur£it zda tyto hlavi£ky pocházejí opravdu z ov¥°eného zdroje, £i byli vytvo°eny zá²kodníkem pokou²ejícím se p°ihlásit do systému.
24
KAPITOLA 5. AUTENTIZACE V SYSTÉMU FELID
Název atributu
HTTP hlavi£ka
Popis
uid
felid-uid
uºivatelské jméno v rámci fakultní sít¥
cvutUid
felid-cvutUid
uºivatelské jméno unikátní v rámci VUT
cnCs
felid-cnCs
celé jméno i s tituly s diakritikou v UTF-8
givenNameCs
felid-givenNameCs
k°estní jméno s diakritikou v UTF-8
snCs
felid-snCs
p°íjmení s diakritikou v UTF-8
mail
felid-mail
fakultní email
cn
felid-cn
celé jméno i s tituly bez diakritiky
givenName
felid-givenName
k°estní jméno bez diakritiky
sn
felid-sn
p°íjmení bez diakritiky
telephoneNumber
felid-telephoneNumber
fakultní telefonní £íslo
departmentNumber
felid-departmentNumber
£íslo katedry
employeeNumber
felid-employeeNumber
osobní £íslo (unikátní ID v rámci VUT)
employeeType
felid-employeeType
vztah k fakult¥ (student, zam¥stnanec, ...)
o
felid-o
identi kátor organizace (nap°. CTU FEE)
Tabulka 5.1: Seznam atribut· poskytovaných systémem FELid [10]
Na²t¥stí systém Shibboleth po£ítá i s takovýmto typem útoku. Kaºdý poºadavek prochází p°es
frontend
serveru Apache, je tím pádem zpracováván i Shibboleth modulem modshib (viz.
následující podkapitola). Ten ov¥°uje zda odesílané hlavi£ky jsou opravdu výsledkem p°ihlá²ení v systému Shibboleth (ov¥°ením platnosti Shibboleth session) nebo zda byly podstr£eny úto£níkem[34]. Tabulka 5.1 obsahuje seznam atribut· dostupných aplikaci SWINPRO. Pro umoºn¥ní vým¥ny atribut· mezi
SP
a
IdP
je pot°eba speci kovat jakým zp·sobem
2
se mají p°ekládat SAML atributy, reprezentované v¥t²inou svým URN , na jejich textová zkrácení. Tato mapování jsou v¥t²inou de nována v souboru
attribute-map.xml
v podob¥
XML element· Attribute[28]. Jako p°íklad je zde uvedeno mapování jednoho atributu s názvem
givenName na jeho unikátní identi kátor urn:mace:dir:attribute-def:givenName.
Cestu k souboru s atributy speci kuje element souboru
Service Providera, zp·sobem uvedeným níºe.
v kon gura£ním
Kon gurace modulu modshib Pro zabezpe£ení p°íchozích poºadavk· na webový server Apache systémem Shibboleth je pot°eba nahrát do b¥hového prost°edí modul modshib. Tento modul funguje jako jakýsi m·stek mezi webovým serverem a sluºbou shibd. 2
Uniform Resource Name
5.3. NASTAVENÍ SPRING SECURITY
25
Nahrání tohoto modulu p°i startu serveru je zaji²t¥nou klasickou direktivou LoadModule v kon gura£ním souboru shib.load. Poté je nutné p°edat tomuto modulu cestu k kon gura£nímu souboru shibboleth2.xml. To zajistíme p°idáním direktivy ShibCon g do souboru shib.conf. Na záv¥r sta£í de novat kon gura£ním souboru Apache, které virtuální servery a na nich umíst¥né URL zdroje mají být chrán¥ny systémem Shibboleth. P°íklad takového nastavení lze vid¥t níºe.
# Basic configuration ServerName rabbit.felk.cvut.cz DocumentRoot /var/www/swinpro Options Indexes FollowSymLinks MultiViews Order deny,allow Allow from all AuthType shibboleth ShibRequireSession Off ShibUseHeaders On require shibboleth
5.3 Nastavení Spring Security Tato podkapitola detailn¥ popisuje jakým zp·sobem muselo být upraveno standardní chováni frameworku Spring Security, a které komponenty musely by upraveny £i zcela nahrazeny vlastními.
5.3.1 Rozbor °e²ení Nejprve je ale nezbytné zd·raznit co se od tohoto °e²ení o£ekává a jaké alternativy se nabízely. Scéná° autentizace, kterého bylo nutné docílit byl následující:
1. Uºivatel v prohlíºe£i zadá adresu serveru s aplikací SWINPRO a potvrdí. Následn¥ se mu zobrazí uvítací stránka, ze které má p°ístup do nechrán¥ných sekcí aplikace SWINPRO, pro které není vyºadováno p°ihlá²ení
26
KAPITOLA 5. AUTENTIZACE V SYSTÉMU FELID
2. Uºivatel se chce p°ihlásit a tak tedy klikne na p°ihla²ovací odkaz v hlavním menu aplikace, které ho následn¥ p°esm¥ruje na speciální URL adresu service providera
3.
3. Systém Shibboleth pak ov¥°í, zda jiº má uºivatel vytvo°enou p°ihla²ovací Session. 4. Pokud ji vytvo°enou nemá nebo je expirovaná, je uºivatel p°esm¥rován na p°ihla²ovací formulá° federace FELid. 5. Po p°ihlá²ení do federace FELid je prohlíºe£ p°esm¥rován zp¥t na adresu service providera
4 aplikace SWINPRO, který ov¥°í p°ihla²ovací metadata, vyºádá si od IdP fede-
race dopl¬ující informace o uºivateli (atributy) a ty jsou pak odesílány v podob¥ HTTP hlavi£ek p°i dotazech sm¥°ujících od uºivatele k serveru. Následn¥ je spolu s t¥mito hlavi£kami p°esm¥rován na URL speci kovanou parametrem
target
v p°ihla²ovacím
URL
(viz. bod 1). 6. V tomto míst¥ je pot°eba zapojit do procesu framework Spring Security, který musí vytáhnout z p°íchozího dotazu HTTP hlavi£ky, které v minulém kroku nastavil SP, a pomocí t¥chto hlavi£ek provedl ov¥°ení uºivatele proti lokální databázi aplikace SWINPRO. Toto ov¥°ení se skládá zejména z kontroly zda má tento uºivatel jiº vytvo°ený ú£et £i zda není ú£et zablokovaný. Pokud uºivatel ú£et v databázi nemá, je mu automaticky vytvo°en s pouºitím informací obdrºených z hlavi£ek.
5
7. Na záv¥r musí být vytvo°en validní autentiza£ní token a tím musí být napln¥n
SecurityContextHolder. Zde by bylo vhodné ve zkratce p°ipomenout klí£ových komponent Spring Security podílejících na procesu autentizace. Filtr
AuthenticationProccessingFilter (nebo z ní odvozená
t°ída) odchytí HTTP poºadavek obsahující p°ihla²ovací údaje vzniklý jako produkt odeslání p°ihla²ovacího formulá°e. Z nich tento ltr vytvo°í autentiza£ní komponent¥
AuthenticationManager.
token, který následn¥ p°edá
Ten se pak pokou²í tento token autentizovat u jed-
notlivých instancí t°íd odvozených od t°ídy
AuthenticationProvider6 ,
zda je tento token
validní. Poté je jiº ov¥°ený token vrácen autentiza£nímu ltru, který jej následn¥ uloºí do
SecurityContextHolderu
a tím umoºní p°ístup uºivatele k zabezpe£eným stránkám.
Toto klasické schéma bohuºel ne²lo pouºít tak jak je, nebo´ Spring Security neposkytuje podporu pro systém Shibboleth. To má za d·sledek ten, ºe neexistuje ºádný
Provider
a neumoº¬uje ani jakoukoliv komunikaci s SP p°es vystavené API.
Tento nedostatek byl vy°e²en implementací vlastních t°íd a
Authentication
ShibbolethAuthenticationProvider.
ShibbolethProcessingFilter
Jak jsou tyto t°ídy realizovány lze nalézt v podka-
pitole Realizace vybraného °e²ení. 3
obecná podoba tohoto URL je následující:
https://<server>/Shibboleth.sso/Login?target=
P°esn¥ji na jeho komponentu Assertion Consumer Service. Vyºadovány jsou hlavi£ky uid, givenNameCs, snCs a mail, ostatních poskytovaných informací prozatím není pouºíváno. 6 Kaºdý z podporovaných autentiza£ních mechanizm· má zpravidla svého vlastního providera, nap°.: LdapAuthenticationProvider, CasAuthenticationProvider nebo OpenIDAuthenticationProvider 4 5
5.3. NASTAVENÍ SPRING SECURITY
27
5.3.2 Alternativní °e²ení Jak jiº bylo zmín¥no d°íve Spring Security nemá ºádnou nativní podporu systému Shibboleth. To v²ak není zcela pravda. Existuje zde totiº alternativa v podob¥ SAML roz²í°ení frameworku Spring Security[13], dávající vývojá°i moºnost p°ipojit aplikaci k libovolnému ov¥°ovacímu systému kompatibilnímu se standardem SAML, kterým systém Shibboleth je. Tím pádem by m¥lo být teoreticky moºné nahradit tímto modulem protoºe tento modul zastává práci K tomuto °e²ení jsem se nakonec neuchýlil a to hned z n¥kolika d·vod·. Prvním d·vodem je relativn¥ malá roz²í°enost tohoto °e²ení[38]. . Dal²ím d·vodem byl fakt, ºe toto roz²í°ení nebylo proti systému Shibboleth nikdy testováno (testováno bylo pouze oproti autentiza£nímu systému OpenSSO, viz. [13]) a tím pádem nebyla zaru£ena bezproblémová funk£nost v²ech poºadovaných vlastností autentizace (zejména vým¥ny atribut· mezi roz²í°ením a IdP federace FELid). Posledním d·vodem pro£ jsem upustil od tohoto °e²ení je fakt,ºe toto roz²í°ení momentáln¥ není sou£ástí aktuáln¥ pouºívané verze
security
frameworku (t.j. 2.0.5)
7 , i kdyº se
uvaºuje o jeho nasazení do n¥které z budoucích vydání verze 3.0.0[38].
5.3.3 Realizace vybraného °e²ení T°ída ShibbolethProcessingFilter re ektuje funkce poskytované ltrem AuthenticationProcessingFilter. Metoda attemptAuthentication této t°ídy nejd°íve vytvo°í instanci t°ídy LoginIdentity. LoginIdentity je speciální objekt, který byl implementován, za ú£elem zapouzd°ení p°ihla²ovacích údaj· a jejich p°edání t°íd¥ AccounManager, která je sou£ástí business vrstvy aplikace. Tento objekt je vytvo°en a zárove¬ i napln¥n daty voláním metody
populateLoginIdentity,
která si z HTTP poºadavku (p°edaného jako parametr) získá z
HTTP hlavi£ek kompletní údaje údaje o uºivateli a ty následn¥ uloºí do lokálních prom¥nných kontejneru. Ten je vzáp¥tí p°edán jako parametr metod¥
AccountManager. Realizace
business
login
pat°ící do rozhraní
logiky je v²ak p°edm¥tem bakalá°ské práce mého kolegy Vojt¥cha
Krále, a proto zde nejsou popisovány podrobnosti týkající se interní správy uºivatelských ú£t· v aplikaci SWINPRO. Jen ve stru£nosti:
AccountManager
se dotáºe do databáze, zda
je v ní uºivatel p°ítomen a pokud ne pak tento ú£et vytvo°í metodou
AccountManager
createProfile. Pokud
zjistí, ºe byl ú£et zablokován, oznámí to autentiza£nímu ltru vyvoláním
výjimky. Po úsp¥²ném ov¥°ení proti lokální databázi následuje vytvo°ení autentiza£ního tokenu t°ídy
Authentication,
který je nastaven do stavu platný a ten je umíst¥n do bezpe£nost-
ního kontextu aplikace, a tím se stane klient pln¥ autorizovaným a je mu umoºn¥n p°ístup na v²echny zabezpe£ené URL adresy v aplikaci. Práv¥ popsaný postup je znázorn¥n sekven£ním diagramem 5.1. Prezenta£ní vrstva aplikace SWINPRO ur£uje p°ístup k jednotlivým ovládacím prvk·m prezenta£ní vrstvy na základ¥ oprávn¥ní de novaných v t°íd¥ 7
LoginBean. LoginBean je t°ída
pozn.: Autorem tohoto roz²í°ení je Vladimir Schäfer, který není £lenem vývojového týmu Spring
28
KAPITOLA 5. AUTENTIZACE V SYSTÉMU FELID
sd SpringShibAuth
Browser
Spring Security Pre-Authentication Filters
ShibbolethProcessing Filter
LoginBean
AccountManager
UserDAO
loginFormSubmit() doFilter(request)
attemptAuth(request)
populateLoginIdentity(request)
LoginIdentity
extractShibbolethHeaders(request)
login(loginIdentity) retrieveUserFromDB() :userEntity
opt profile creation [account is NOT created] createNewUser(profileInfo)
:userEntity registerAuthenticatedUser(userEntity)
Obrázek 5.1: P°ihla²ovací sekvence Shibboleth komponent
spravovaná Faces Contextem,
8 , který tvo°í základní sou£ást prezenta£ního frameworku JSF
(jedná se o jakousi obdobu aplika£ního kontextu Springu). Aby mohla být získána aktuální instance Faces Contextu je nezbytné aby p°íchozí poºadavek byl nejd°íve zpracován t°ídou
FacesServlet.
Problém nastává v p°ípad¥, kdyº se
snaºíme získat instanci kontextu v servlet ltru jako práv¥ v tomto p°ípad¥. Protoºe se servletové ltry provád¥jí p°ed samotnými servlety [6] nemohl tedy být jiº iniciován a tím pádem nám volání
FacesContext.getCurrentInstance()
FacesContext,
vrátí nulovou referenci.
Tento problém byl vy°e²en malým trikem. Po odeslání p°ihla²ovacího formulá°e na stránkách FELid, je uºivatel p°esm¥rován na speciální JSP stránku shib-auth-forwarder.jsp, na které se nachází element
<jsp:forward page="/faces/j_security_check"/>.
Tento ele-
ment °íká webovému serveru aby namísto této stránky vrátil stránku odkazovanou atributem
page 9 .
Díky tomuto postupu se nejprve vyvolá FacesServlet, který tak m·ºe nastavit aktu-
tzv. backing bean pozn.: v tomto p°ípad¥ se neprovádí redirect, t.j. prohlíºe£ negeneruje nový poºadavek, forward je vykonán intern¥ v rámci servletového kontejneru 8 9
5.3. NASTAVENÍ SPRING SECURITY
29
ální kontext a pak je volání p°esm¥rováno na novou URL, p°i jejímº zpracování je teprve vykonán
ShibbolethProcessingFilter.
Trochu jiný pohled na proces autentizace podává sekven£ní diagram 5.2. Je na n¥m zobrazena HTTP komunikace mezi hlavními participanty procesu. sd ShibLoginSequence ApacheTomcat
Spring Security Filters
Shibboleth Service Provider rabbit.felk.cvut.cz
Browser
Shibboleth FELid IdP login.feld.cvut.cz
FacesServlet
request(secured_page.jsp) doFilter(request) redirect(Shibboleth.sso/Login?target=auth-forward.jsp)
request(Shibboleth.sso/Login?target=auth-forward.jsp) redirect(login.feld.cvut.cz/idp/login-form)
request(idp/login-form) response(loginForm) submitLoginForm(credentials)
checkCredentials()
redirect(Shibboleth.sso/SAML2/POST)
request(Shibboleth.sso/SAML2/POST) proccessAsertion() fillHTTPHeaders() redirect(/swinpro/faces/auth-forward.jsp)
request(auth-forward.jsp) doFilter(request)
process(request) setFacesContextInstace() forward(j_security_check)
doFilter(request) redirect(secured_page.jsp)
authenticate()
Obrázek 5.2: HTTP komunikace autentiza£ního procesu
Mezi komponenty bezpe£nostního rámce, které nemohly být pouºity tak jak jsou dodávány frameworkem pat°í
AuthenticationProcessingFilterEntryPoint.
Tato t°ída speci-
kuje adresu p°ihla²ovacího formulá°e, na kterou je automaticky p°esm¥rován nep°ihlá²ený uºivatel p°i pokusu p°istoupit na zabezpe£enou URL. V tomto p°ípad¥ je v²ak p°ihla²ovací formulá° umíst¥n na serveru poskytovatele identit
login.feld.cvut.cz. To je v²ak problém
protoºe frameworkem dodávaná t°ída vstupního bodu umoº¬uje p°esm¥rování pouze v rámci aplikace, respektive serveru, na kterém je aplikace spu²t¥na. Z tohoto d·vodu byla vytvo°ena vlastní odvozená t°ída
ShibbolethAuthenticationEntryPoint,
která p°ede nuje metodu
30
KAPITOLA 5. AUTENTIZACE V SYSTÉMU FELID
buildRedirectUrlToLoginPage, Te¤
zbývá
tak aby bylo umoºn¥no p°esm¥rování i na jiný server.
zodpov¥d¥t
otázku
ShibbolethAuthenticationProvider,
jakou
úlohu
vlastn¥
hraje
t°ída
kdyº v²echny její funkce jsou odbavovány jiº v
samotném autentiza£ním ltru. Odpov¥¤ je snadná: Autentiza£ní systém frameworku nedovoluje být spu²t¥n bez n¥jakého autentiza£ního providera, a proto byl vytvo°en tento fake provider, který je systému podstr£en, ale ve skute£nosti ºádnou funkci neplní. V²echny
t°ídy
vý²e
zmín¥né
cz.cvut.fel.swinpro.auth.shibboleth
a
t°ídy
lze
nalézt
v
balí£cích
cz.cvut.fel.swinpro.auth.
5.4 Testování výsledného sestavení Testování tohoto °e²ení bylo provád¥no v rámci testováním celé aplikace SWINPRO. Systém byl nasazen ve zku²ebním provozu na virtuální server
rabbit.felk.cvut.cz
vytvo°eným pouze
za ú£elem provozování aplikace SWINPRO. Na tomto serveru byla aplikace testována cca. 100 studenty, kte°í m¥li zapsán p°edm¥t X36SIN, a samoz°ejm¥ také celým vývojovým týmem aplikace. B¥hem tohoto období byly odhaleny pouze dva závaºn¥j²í problémy s nastavením. První z problém· ze projevil v p°ípad¥, kdy se uºivatel p°ihlásil k systému Shibboleth a tím mu byla nastavena p°ihla²ovací
session
a její identi kátor uloºen do
cookie.
Problém
v²ak nastal aº kdyº uºivatel sv·j po£íta£ uspal a p°enesl jej na jiné pracovi²t¥, kde se s tímto po£íta£em p°ihlásil do sít¥ a obdrºel p°itom odli²nou IP adresu, neº z které se p°ihla²oval do aplikace SWINPRO. V tomto okamºiku systém Shibboleth zcela správn¥ identi koval nastalou situaci jako pokus o pr·nik metodou kradení p°ihla²ovací
session a zamezil uºivateli
opakované p°ihlá²ení do aplikace. I kdyº bylo °e²ení této situace relativn¥ jednoduché (sta£ilo vymazat
cookies drºící si SessionID
spojení se systémem Shibboleth), v p°ípad¥ svého vzniku
byla pro uºivatele siln¥ matoucí a tím sniºovala komfortnost pouºívání aplikace. Druhým, podstatn¥ závaºn¥j²ím problémem se pozd¥ji ukázala být nefunk£nost p°ihla²o-
10 , kdy
vání do systému z prohlíºe£· Internet Explorer verze 7 a 8
shibboleth daemon
odmítal
poºadavky obslouºit. Pozd¥ji se ukázalo, ºe tento problém byl zap°í£in¥n stejnou chybou jako problém první. Oba problémy byly vy°e²eny vypnutím kontroly IP adresy klienta na stran¥ service providera. To bylo realizováno nastavením atributu
checkAddress elementu <Session>, umíst¥-
ném v hlavním kon gura£ním souboru SP, na hodnotu
false. Informace pro °e²ení problému
byly £erpány zejména z dokumentace systému Shibboleth [28].
10
verze 6 Internet Exploreru testována nebyla, ale p°edpokládá se, ºe by se v ní chyba projevila také
Kapitola 6
Autentizace proti adresá°ové sluºb¥ LDAP 6.1 Motivace Poºadavek na doimplementování tohoto zp·sobu autentizace byl dodán po rozhodnutí zprovoznit systém SWINPRO na Fakult¥ informa£ních technologií VUT v Praze. Bohuºel nebylo £asové stihnutelné v období psaní této práce zajistit ov¥°ování oproti skute£nému LDAP serveru, který na FIT slouºí k ov¥°ování student· a zam¥stnanc· fakulty. Z tohoto d·vodu byl mnou navrºený zp·sob °e²ení je koncipován jako £ist¥ referen£ní. Tím pádem bylo ov¥°ování nakon gurováno proti testovacímu LDAP serveru s klasickým schématem adresá°ové struktury. Nep°edpokládá se v²ak, ºe pro reálné nasazení bude pot°eba provád¥t n¥jaké v¥t²í zásahy do stávající implementace.
6.2 Instalace a kon gurace testovacího LDAP serveru Pro ov¥°ování funk£nosti autentiza£ního rozhraní aplikace, byl na serveru rabbit.felk.cvut.cz nainstalována adresá°ový server protokolu LDAP, respektive jedna z jeho implementací OpenLDAP ve verzi 2.3.30, staºená z o ciálního repozitá°e distribuce Debian jako balí£ek
slapd.
Na tomto serveru byly vytvo°eny dv¥ organiza£ní jednotky. První jednotka s názvem
people
v sob¥ udrºuje záznamy o uºivatelích, umíst¥ných v atributech de novaných t°ídami
inetOrgPerson a posixAccount. Tyto dv¥ t°ídy byly zvoleny pro své £asté nasazení na LDAP serverech za ú£elem uchovávání dat o uºivatelích. Z tohoto d·vodu je velice pravd¥podobné, ºe i ú£ty na serveru FIT budou t¥mito t°ídami reprezentovány. Druhá vytvo°ená jednotka nese název
groups
a obsahuje v sob¥ role, ve kterých m·ºou uºivatelé vystupovat. V tomto
p°ípad¥ jsou jednotlivé role instancemi t°ídy
posixGroup. V takto p°ipravené struktu°e bylo swinpro. Jak
vytvo°eno n¥kolik zku²ebních ú£t·, které byli p°idány do jednotné skupiny výsledné schéma LDAP úloºi²t¥ vypadá zachycuje následující ilustrace.
Podrobn¥j²í popis instalace LDAP serveru a jeho nastavení lze nalézt v p°íloze A Instala£ní p°íru£ka.
31
32
KAPITOLA 6. AUTENTIZACE PROTI ADRESÁOVÉ SLUB
LDAP
LDAP root
o:rabbit.felk.cvut.cz class:organization
ou:people
ou:groups
class:organizationalUnit
uid:xfranta
class:inetOrgPerson class:posixAccount
class:organizationalUnit
uid:spaceji3
class:inetOrgPerson class:posixAccount
uid:xtester
class:inetOrgPerson class:posixAccount
cn:swinpro class:posixGroup memberUid:xfranta memberUid:xtester
Obrázek 6.1: Struktura testovacího LDAP adresá°e
6.3 Autentiza£ní LDAP modul aplikace SWINPRO Tato podkapitola se zabývá dopln¥ním stávající kon gurace Spring Security tak, aby byla autentizace aplikace SWINPRO pln¥ p°ipravena na ov¥°ování oproti adresá°ové sluºb¥ LDAP. V záv¥ru je pak zmín¥no jakým zp·sobem je moºné jednodu²e p°epnout mezi stávajícím ov¥°ováním p°es systém Shibboleth a novým p°es LDAP. Spring Security obsahuje velmi dobrou podporu autentizace oproti LDAP. Pro komunikaci s adresá°ovým serverem existuje ve Springovém portfoliu podprojekt SpringLDAP.
LDAPProvider AuthenticationProvider
Podpora LDAP je ve Spring Securiy realizovaná zejména pomocí t°íd
LdapAuthenticator. LDAPProvider
je implementací rozhraní
a a
má na starosti delegování autentiza£ních dotaz· na server LDAP. Tato t°ída ov²em nemohla být pouºita tak jak je a bylo nutné ji speciáln¥ upravit pro systém SWINPRO. To spo£ívalo v roz²í°ení metody spektive její metody
login.
authenticate
o volání t°ídy
AuthenticationManager,
re-
Dal²í úpravou této metody je p°idání registrace úsp¥²n¥ ov¥-
°eného uºivatele do Tyto úpravy jsou vlastn¥ obdobné t¥m, které jsou provád¥ny v t°íd¥
ShibbolethProcessingFilter
v rámci Shibboleth modulu. V LDAP modulu jsou vý²e
zmín¥né funkce realizované t°ídou
LDAPProvider.
CustomLDAPAuthenticationProvider
d¥dící od t°ídy
6.3. AUTENTIZANÍ LDAP MODUL APLIKACE SWINPRO
T°ída
33
LDAPProvider neprovádí spojení s LDAP serverem sama o sob¥, nýbrº deleguje LDAPAuthenticator (p°esn¥ji na t°ídu implementující toto rozhraní).
tuto akci rozhraní
T°ída implementující toto rozhraní de nuje strategii, jakým zp·sobem vytvo°it autentiza£ní LDAP dotaz do adresá°e a tím ov¥°it p°ihla²ovaného uºivatele. Spring Security umoº¬uje zvolit mezi dv¥ma strategiemi, které implementují následující dv¥ t°ídy:
• BindAuthenticator
p°i ov¥°ování pomocí této strategie je pouºito uºivatelovo p°i-
hla²ovací jméno a heslo zadané p°i p°ihlá²ení do Springové aplikace k p°ihlá²ení k adresá°ovému serveru. Pokud LDAP server p°ihlá²ení s t¥mito údaji umoºní, je uºivatel povaºován frameworkem Spring Security za úsp¥²n¥ ov¥°eného
• PasswordComparisonAuthenticator
Pokud LDAP server neumoº¬uje p°ihlásit se
1 , je moºné vyuºít tento alternativní p·sob
uºivatel·m, kte°í v n¥m mají vytvo°ené ú£ty
ov¥°ení, který funguje tak, ºe se Springová aplikace p°ihlásí pod n¥jakým speciální administrátorským ú£tem k LDAP serveru, na který následn¥ ode²le dotaz kontrolující existenci ú£tu uºivatele jenº se chce do aplikace p°ihlásit. Pokud LDAP server hledaný ú£et najde, je aplikací povaºován za validní.
Pro
ov¥°ování
oproti
BindAuthenticator.
testovacímu
serveru
jsem
zvolil
strategii
de novanou
t°ídou
Není v²ak problém tuto strategii zm¥nit.
Sekvenci volání komponent tvo°ící LDAP autentiza£ní systém znázor¬uje sekven£ní diagram 6.2. Na tomto diagramu je také moºné zpozorovat t°ídu
InetOrgPersonContextMapper. Tato
t°ída zaji²´uje nataºení dodate£ných údaj· o uºivateli, kterými je následn¥ napln¥n kontejner
LoginIdentity
a p°edán
business
logice aplikace SWINPRO mající na starost p°ihla²ování.
Jeho funkcí je v zásad¥ mapování dat obdrºených jako výsledek dotazu do LDAP adresá°e na objekt
InetOrgPerson,
coº je vlastn¥ jen roz²í°ením generického objektu
UserDetails.
Zde v²ak tkví zdroj moºných budoucích problém·. Mnou vytvo°ená implementace
LDAPProvider InetOrgPerson. Ten
t°ídy
p°edpokládá, ºe mu
LDAPAuthenticator
vºdy vrátí instanci t°ídy
v²ak tuto t°ídu vrací pouze v p°ípad¥ kdy jsou uºivatelské ú£ty v
adresá°ové sluºb¥ opravdu uloºeny v podob¥ objekt· t°ídy inetOrgPerson. V p°ípad¥ ºe tomu tak není (nap°íklad pokud jsou ú£ty instancemi t°ídy posixAccount), pak nevrátí instanci t°ídy
InetOrgPerson,
ale jeho nadt°ídy
Person.
Ta v²ak v sob¥ neobsahuje v²echny
informace vyºadované aplikací SWINPRO pro vytvo°ení lokálního ú£tu uºivatele. V tomto okamºiku tedy nezbývá nic jiného, neº aby výjimku
AuthenticationServiceException
CustomLDAPAuthenticationProvider
vyvolal
a tím zamezil uºivateli moºnost se p°ihlásit.
Toto °e²ení rozhodn¥ není ideální a po£ítá se s jeho budoucí úpravou tak, aby mohla být autentizace provád¥na oproti adresá°i s libovolnou reprezentací ú£t·.
1
nap°íklad protoºe to bezpe£nostní politika podniku nebo organizace nedovoluje
34
KAPITOLA 6. AUTENTIZACE PROTI ADRESÁOVÉ SLUB
LDAP
sd SpringLDAPAuth
Browser
Spring Security AuthenticationProcessing Pre-Authentication Filter Filters
loginFormSubmit()
CustomLDAP AuthenticationProvider
BindAuthenticator
InetOrgPerson ContextMapper
AccountManager
doFilter(request) createToken()
Authentication
setCredentials() :authToken
authenticate(authToken) authenticate(authToken) mapUserFromContext(username) :inetorgUserDetails appendUserDetailsToToken() :validatedAuthToken LoginIdentity
login(identity)
Obrázek 6.2: P°ihla²ovací sekvence LDAP autentizace
6.4 Testování výsledného sestavení Protoºe aplikace SWINPRO (resp. její autentiza£ní rozhraní nedovoluje) provozování obou ov¥°ovacích zp·sob· zárove¬ (je to technicky obtíºn¥ realizovatelné), byla spu²t¥na druhá testovací verze aplikace SWINPRO, tentokrát s ov¥°ováním p°es LDAP, na virtuálním serveru pouºívaném p°i jejím vývoji. Protoºe testovací Tomcat server slouºil výhradn¥ k vývoji nových verzí aplikace SWINPRO, tím pádem nepro²el tento typ autentizace ºádnou zat¥ºkávací zkou²kou, jako tomu bylo v p°ípad¥ ov¥°ování p°es Shibboleth. Jedinými testery byli tedy £lenové vývojového tým, kte°í pouºívali n¥kolik testovacích ú£t·. Za celou dobu testování nebyly odhaleny ºádné závaºn¥j²í nedostatky.
Kapitola 7
ízení p°ístupu do SVN repozitá°· 7.1 Motivace Jednou z hlavních funkcí systému SWINPRO je automatické zakládání SVN repozitá°· na vzdáleném serveru. V pr·b¥hu implementace této funk£nosti byl vznesen poºadavek na °ízení omezení p°ístupu k t¥mto repozitá°·m. Do té doby fungovalo jejich vytvá°ení tak, ºe do nich m¥l p°ístup kdokoliv kdo se dokázal ov¥°it proti ²kolnímu serveru Solaris. Tato situace byla zna£n¥ nevýhodná, protoºe jakýkoliv ov¥°ený uºivatel tím získal kompletní kontrolu nad v²emi repozitá°i spravovanými systémem. Kompletní kontrolou je zde my²leno jak staºení jejich pracovní kopie (tzv, checkout), tak i moºnost nahrát vlastní soubory (tzv. commit). Poºadavek na °e²ení tohoto problému byl tedy takový, aby p°i zaloºení nového projektu a jeho schválení supervizor m¥l nov¥ vytvo°ený repozitá° povolen p°ístup (pro £tení i zápis) pouze £len·m daného projektu a jejich supervizorovi.
7.2 Analýza °e²ení 7.2.1 Princip zabezpe£ení V zásad¥ existují dva zp·soby p°ístupu k vzdáleným SVN repozitá°·m (neuvaºujeme repozitá°e umíst¥né na lokálním lesystému). První je pomocí nativního protokolu svn, který se p°ipojuje na sluºbu zaji²´ovanou
daemonem svnserve.
Druhou moºností je vyuºití modulu
modsvn pro webový server Apache, ke kterému se klienti p°ipojují pomocí roz²í°ení protokolu HTTP zvaného WebDAV[2]. Pro bliº²í seznámení s problematikou odkazuji na bakalá°skou práci kolegy Jana Ustohala[16]. Systém SWINPRO vyuºívá práv¥ druhý jmenovaný zp·sob, a proto je navrhované °e²ení zam¥°eno primárn¥ na n¥j. ízení p°ístupu k repozítá°·m je nastavováno pomocí speciálních kon gura£ních sou-
1
bor· (ACL ) modulu modsvn, které de nují seznam repozitá°·, kde pro kaºdý repozitá°e je uvedena mnoºina dvojic hodnot username : p°ístupová práva. Na následujícím p°íkladu je patrná struktura takového souboru: 1
Access Control List
35
36
KAPITOLA 7. ÍZENÍ PÍSTUPU DO SVN REPOZITÁ
[/] * = [groups] hardworkers = spaceji3, alice, bob [/SWINPROProject] @hardworkers = rw trudy = [/RedProject] @hardworkers = r george = rw [/RedProject/TopSecretFolder] carol = rw V hranatých závorkách je umíst¥na relativní cesta k repozitá°i a pod ní jsou de novány pravidla pro jednotlivá uºiv jména, ur£ující p°ístup jednotlivých uºivatel· k dané cest¥. Práva jsou de nována znaky
r pro povolení pouze £tení, £i rw pro £tení i zápis. Pro zakázání trudy = v
p°ístupu do repozitá°e sta£í tuto £ást nechat prázdnou jak ukazuje pravidlo p°edchozím p°íklad¥.
Jednou z vítaných vlastností, kterou tyto kon gura£ní soubory poskytují je moºnost de nování skupin uºivatel· pomocí speciální sekce t¥mto skupinám v zápisem
[groups]
a následné p°id¥lování práv
@názevskupiny = práva. Této vlastnosti je vyºito p°i de nování
skupiny supervizor·, obsahující v²echny supervizory systému SWINPRO a de nování plného p°ístupu (rw) do v²ech zakládaných repozitá°·. Toto °e²ení, ºe p°i p°id¥lení nebo odebrání supervizorských práv uºivateli v systému SWINPRO sta£í zm¥nit v kon gura£ním souboru jediný °ádek. Dal²ím prvkem vlastností kon gurace hodnou pozornosti je moºnost de nování výchozího nastavení pro v²echny repozitá°e. To zaji²´uje speciální sekce
[/],
ve které jsou de novány
pravidla platná pro v²echny repozitá°e. V p°edchozím p°ípad¥ vidíme, ºe tato sekce obsahuje pravidlo
* =
. Toto pravidlo zakazuje p°ístup v²em uºivatel·m do v²ech repozitá°·, pokud
nejsou výslovn¥ de novány v kon gura£ním souboru níºe. Znak *
2 zde tedy zastupuje
libovolného uºivatele. Veliká výhoda kon gurace pomocí t¥chto
ACL soubor·
spo£ívá v tom, ºe je moºné tyto
soubory upravovat za b¥hu webového serveru Apache bez nutnosti jeho restartování a tím znovuna£tení kon gurace. Zm¥ny provád¥né v tomto kon gura£ním souboru jsou tedy poznatelné ihned po uloºení takového souboru a modsvn s nimi pracuje tém¥° okamºit¥. Jako nevýhodu tohoto °e²ení je moºné povaºovat fakt, ºe jen jediná chyba v syntaxi kon gura£ního souboru vede k okamºitému zablokování p°ístupu ke v²em repozitá°·m spravovaným modulem modsvn, do doby neº je tato chyba odstran¥na zásahem administrátora serveru. 2
tzv. wildcard
7.3. REALIZACE
37
7.2.2 Návrh °e²ení V zásad¥ se p°i návrhu naskytla dv¥ moºná °e²ení. Prvním variantou bylo vytvo°it na stran¥ serveru rezidentní aplikaci naslouchající na sí´ovém rozhraní a zpracovávající poºadavky odesílané systémem SWINPRO. Na základ¥ t¥chto poºadavk· by pak tato sluºba provád¥la modi kaci kon gura£ního souboru. Toto °e²ení jsem v²ak zavrhl pro jeho zbyte£nou komplikovanost. Mezi jiné nevýhody by pat°ily nap°íklad v¥t²í nároky na administraci (spou²t¥ní/zastavování
daemona ), £i blokování systémových port·, na kterých by bylo nasloucháno.
Varianta, která byla nakonec p°ijata jako nejoptimáln¥j²í se skládala z vyhotovení skriptu v n¥kterém skriptovacím jazyce, který se bude starat o úpravy spojené s p°idáváním a odebíráním repozitá°· a ud¥lování £i zamítání p°ístupových práv. Tento skript je vzdálen¥ spou²t¥n aplikací SWINPRO za pouºití protokolu SSH, jehoº podpora je v systému zabudovaná v podob¥ aplika£ního rozhraní dodaného kolegou J. Ustohalem (viz. [16]). Otázka architektury navrhovaného °e²ení byla tedy vy°e²ena, zbývalo jen vybrat vhodný skriptovací jazyk v n¥mº bude °e²ení implementováno. Kdyº se °ekne skriptování v UNIXovém prost°edí kaºdému asi vyvstane na mysli podpora skriptování v p°íkazovém interpretu bash. Skripty ur£ené pro bash v²ak vykazují, spolu s malou roz²i°itelností i vysokou míru nep°ehlednosti p°i °e²ení komplexn¥j²ích problém·. Takºe z vý²e uvedených d·vod· jsem tuto moºnost zamítl. e²ením tohoto problému se nabízelo pouºitím n¥kterého ze skriptovacích jazyk·. Volil jsem tedy mezi jazyky Perl, Ruby a Python, zejména z d·vodu jejich ²iroké roz²í°enosti na UNIXové platform¥. Vzhledem k tomu, ºe jsem nem¥l ºádné d°ív¥j²í zku²enosti s jazykem Perl ani s jazykem Ruby, rozhodl jsem se nakonec skript implementovat v jazyce Python. Tato volba s sebou nese dal²í výhodu, a to sice v podob¥ moºnosti pouºít skript nejen pro p°id¥lování práv k SVN repozitá°·m, ale i pro p°id¥lování práv v rámci issue tracking systému Trac, jehoº projekty jsou taktéº spravovány systémem SWINPRO. Systém Trac obsahuje kvalitní programové rozhraní v jazyce Python[39], které by tím pádem bylo p°ímo pouºitelné z kon gura£ního skriptu. Tím pádem pokud by se objevil poºadavek na roz²í°ení funk£nosti systému SWINPRO vzhledem k omezení p°ístupu k Trac projekt·m (momentáln¥ neomezován), sta£ilo by pouze roz²í°it stávající mnou navrºený skript a nebylo by nutné hledat nové °e²ení.
7.3 Realizace Skriptu spravující kon gura£ní soubor má jako povinný parametr cestu ke ko°eni SVN repozitá°e, ve kterém musí být umíst¥n soubor s názvem
access.acl, ve kterém jsou de nována
jednotliví kon gura£ní pravidla. Pokud tento soubor neexistuje skript jej sám vytvo°í. Protoºe je tento skript spou²t¥n vzdálen¥ pomocí protokolu SSH, existuje zde jistá moºnost, ºe p°i hromadném zakládání více projekt· najednou bude skript spu²t¥n v jednom £asovém okamºiku n¥kolikrát (v rámci kaºdé SSH relace jednou). Protoºe skript pracuje vºdy pouze nad jedním kon gura£ním souborem, je tato vlastnost neºádoucí, protoºe by v jejím d·sledku docházelo k vzájemnému p°episování dat r·znými instancemi skriptu a tím by kon gura£ní soubor ztratil integritu.
38
KAPITOLA 7. ÍZENÍ PÍSTUPU DO SVN REPOZITÁ
Tomuto jevu je zabrán¥no implementací zamykacího mechanizmu. Zamykání funguje tak, ºe kaºdá nová spu²t¥ná instance skriptu zkontroluje zda se v adresá°i s kon g. souborem nalézá speciální zamykací soubor
access.lock.
Pokud je nalezen, znamená to, ºe je práv¥ spu²-
t¥na jiná instance skriptu, která práv¥ manipuluje s daty uvnit° kon gura£ního souboru. Nov¥ spu²t¥ná instance tedy za£ne cyklicky testovat existenci zamykacího souboru a pokud zjistí, ºe byl z adresá°e odstran¥n, znamená to ºe star²í instance dokon£ila svoji práci a kon gura£ní soubor je tedy moºné upravovat. Protoºe se p°edpokládá volání z prost°edí systému SWINPRO je neºádoucí aby £ekání na uvoln¥ní zamykacího souboru trvalo nekone£n¥ dlouho. Proto je ve skriptu napevno nastavena prodleva (5 sekund) ur£ující jak dlouho se má £ekat na otev°ení zámku a po uplynutí tohoto £asového úseku a za p°edpokladu, ºe zámek nebyl uvoln¥n, je skript s chybovým stavem ukon£en. Vý²e zmín¥né °e²ení má v²ak jednu zna£nou nevýhodu. Problém m·ºe nastat v p°ípad¥, ºe skript bude p°i svém b¥hu násiln¥ ukon£en (nap°. UNIXovým p°íkazem kill apod.). V tomto p°ípad¥ nebude °ádn¥ odstran¥n zamykací soubor vytvo°ený ukon£eným skriptem a provád¥ní nových instancí skriptu bude tedy blokováno. Tento problém byl vy°e²en tak, ºe p°i kaºdé kontrole existence zamykacího souboru je zkontrolována jeho doba vytvo°ení. Pokud tato doba p°esáhne 120 vte°in, je tento soubor povaºován za neplatný a je vymazán. Tím je zaru£ena maximální doba zotavení z pádu instance skriptu. Skript obsluhující kon gura£ní soubor s p°ístupovými právy do repozitá°· je sloºen z n¥kolika funkcí. Ve zkratce lze jeho £innost shrnout v následujících krocích: 1. Parsování p°epína£· a parametr· p°íkazové °ádky - Tento krok je je pokryt kódem
main(). K parsování parametr· je pouºita t°ída OptionParser ze standardního modulu optparse. Z na£tených parametr· je analyzováno, který p°íkaz je provád¥n a ten je spolu s cestou k kon gura£nímu souboru p°edán funkci processcmd() ke
funkce
zpracování 2. Kontrola zámku - Pokud jiº
lock le
existuje, £eká se na jeho uvoln¥ní (maximáln¥
v²ak 5 vte°in, poté je vrácena výjimka a skript skon£í chybou). Jestliºe neexistuje je vytvo°en a skript m·ºe pokra£ovat v práci. 3. Vytvo°ení zálohy kon gura£ního souboru - Kon gura£ní soubor je zazálohován do souboru
access.backup.
Pokud kdykoliv b¥hem provád¥ní skriptu dojde k fatální chyb¥ je
z n¥j p·vodní soubor obnoven. 4. Parsování kon gura£ního souboru a vytvo°ení jeho objektové reprezentace - Metoda
parse()
t°ídy
Parser
vytvo°í z na£teného ACL souboru jeho objektovou reprezentaci
v podob¥ instance t°ídy ACLModel. 5. Provedení poºadovaného p°íkazu nad objektem t°ídy ACLModel - Toto je realizováno £lenskými metodami t°ídy ACLModel 6. Serializace objektu ACLModel zp¥t do kon gura£ního souboru 7. Smazání záloºního souboru, a zámkového souboru 8. Konec b¥hu skriptu
7.3. REALIZACE
39
act SVNAccess
Inv oke Config Script
createProject Invocation
ssh call
OptionParser.parse_args()
ACL Model
[grant()/revoke()]
Execute Input Command
[parsing succeeded]
Parse Config File
ﾫmodified ﾫ ACLModel
Parse CLI Options Parser.parse()
Lock File Check
[parsing failed]
[failure]
Backup Config File
ACLModel.to_string() Serialize To Config File
backup_file() Restore Config File [success]
Wait 1 sec locked?
[false]
[false]
Create Lock File
[true] Remov e Backup and Lock File
is_lock_expired() Remov e Lock File [true]
expired?
final
Obrázek 7.1: Pr·b¥h vykonání svnaccess.py skriptu
Vý²e zmín¥ný sled operací je znázorn¥n diagramem aktivit na obrázku 7.1. Volání skriptu ze strany systémy SWINPRO je zaji²t¥no voláním metody instance t°ídy
SSHConnector,
executeCommand()
která je sou£ástí API vytvo°eného kolegou J. Ustohalem v
rámci jeho bakalá°ské práce[16]. P°íklad volání z metody
createProject z t°ídy SVNServerBo
lze vid¥t na následujícím úryvku kódu:
command = "/usr/bin/env python " + baseDir + "/svn-access.py " + baseDir + " setpriv -p rw -r /" + getProject().getAbbreviation() + " -u @supervisors" + usrList; int result; try { result = ssh.executeCommand(command); } catch (IOException ex) { ssh.closeConnection(); throw new ToolServerException("Chyba p°idávání práv. " + ex.getClass().getCanonicalName()); } if (result != 0) { ssh.closeConnection();
40
KAPITOLA 7. ÍZENÍ PÍSTUPU DO SVN REPOZITÁ
}
throw new ToolServerException("Chyba p°i p°idávání práv. ");
Volání skriptu pouºito pouze pro
business
metodu za°izující zaloºení nového projektu.
Mezi dal²í p°ípady uºití, ve kterých bylo moºné skript nasadit bylo nap°íklad zm¥na supervizorských £i administrátorských práv uºivatele. Bohuºel
business
logika aplikace nebyla
v té dob¥ dostate£n¥ p°ipravena, aby bylo moºné v ní volání skriptu zcela integrovat.
3 S
nasazením skriptu do metod je po£ítáno spolu s refaktorizací kódu systému SWINPRO.
7.4 Testování Spolu s vývojem kon gura£ního skriptu, probíhal na systému SWINPRO testovací provoz student· p°edm¥tu X36SIN. Bohuºel vývoj skriptu byl dokon£en, aº poté kdy uº m¥la v¥t²ina student· své projekty a SVN repozitá°e zaloºené. Z tohoto d·vodu nebylo moºné otestovat funk£nost skriptu na reálných p°ípadech. Proto byl k otestování napsán jednotkový test, který testuje správnou funk£nost skriptu tím zp·sobem, ºe na£te údaje o v²ech projektech v systému SWINPRO. Poté za£ne sekven£n¥ volat skript na stran¥ SVN serveru pro kaºdý projekt v seznamu a tím sestaví kompletní kon gura£ní soubor. Na konec bylo nutné tento soubor manuáln¥ zkontrolovat, zda je pln¥ funk£ní. Pouºitý jednotkový test je napsán s uºitím frameworku JUnit verze 4.4 a lze jej nalézt v p°íloze.
D·vodem byly zejména chyb¥jící business metody, pro operace odebrání supervizorských práv. Tyto operace byly v té dob¥ °e²eny p°ímou úpravou doménových objekt·. 3
Kapitola 8
Záv¥r 8.1 Zhodnocení dosaºených výsledk· Cíle vyty£ené p°i zadávání této bakalá°ské práce bylo úsp¥²n¥ dosaºeno. Realizace p°ihla²ování pomocí systému Shibboleth bylo v celém období letního semestru p°ibliºn¥ stovkou student· p°edm¥tu X36SIN. V tomto období nedo²lo k ºádným výpadk·m aplikace SWINPRO z d·vodu nefunk£nosti autentiza£ního systému a nebyly odhaleny ºádné chyby v jeho kon guraci. Autentiza£ní rozhraní pro LDAP na svoje zat¥ºkávací zkou²ky teprve £eká. Ty budou provád¥ny na Fakult¥ informa£ních technologií , kde budu aplikaci SWINPRO s tímto typem ov¥°ování nasazovat na po£átku zimního semestru 2009/2010.
8.2 Diskuze nabízejících se vylep²ení Jako roz²í°ení kaºdého asi okamºit¥ napadne p°idání nových zp·sob· autentizace (nap°. systémem Kerberos). To v²ak není tak pravd¥podobné. Nesmíme zapomínat, ºe volba autentiza£ního mechanizmu je p°ímo závislá tom, zda je na fakult¥ tento zp·sob autentizace poskytován. V tomto ohledu se nejnad¥jn¥ji jeví autentizace oproti domén¥ Solaris, resp. ú£t· spravovaným NIS serverem. Zatím se v²ak neobjevil ºádný d·vod pro£ nad n¥£ím takovým uvaºovat, a proto jsem tuto moºnost v této práci nijak blíºe nerozvád¥l. Jedním z ryze technických nám¥t· k roz²í°ení je slou£ení ov¥°ování oproti systému Shibboleth a LDAP kon gurace tak, aby ²lo provozovat oba systémy zárove¬. To by mohlo fungovat nap°íklad tak, ºe by uºivatel zadával své p°ihla²ovací údaje do aplikace SWINPRO, která by se vzáp¥tí pokusila ov¥°it tohoto uºivatele oproti adresá°ové sluºb¥ LDAP. Pokud by nebyl na LDAP serveru uºivatel nalezen, pokusila by se aplikace tohoto uºivatele ov¥°it v rámci sít¥ Shibboleth.
8.3 Osobní p°ínos P°i návrhu autentiza£ního rozhraní jsem pochopil, ºe ne vºdy je ta nejjednodu²²í a nejp°ím¥j²í cesta ta správná, a ºe je vºdy pot°eba zamyslet se nad moºností budoucích roz²í°ení a
41
42
KAPITOLA 8. ZÁV
R
sm¥°ováním dal²ího vývoje systému. To jsem pocítil v moment¥, kdy byl vznesen poºadavek na doimplementování ov¥°ování p°es LDAP server. V tom období v²ak bylo autentiza£ní rozhraní aplikace napevno nastavené pro ov¥°ování systémem Shibboleth a tím pádem bylo naprosto nepouºitelné pro jiné autentiza£ní systémy. Tento problém ve svém d·sledku vedl ke kompletní zm¥n¥ autentiza£ního °e²ení na stran¥ aplikace SWINPRO a pouºití bezpe£nostního frameworku Spring Security.
Literatura Alex and L. Taylor. Spring Security reference documentation. http: //static.springsource.org/spring-security/site/docs/2.0.x/reference/ springsecurity.html, stav ze 28. 4. 2010.
[1] B.
[2] B. Collins-Sussman, B. W. Fitzpatrick, and C. M. Pilato. Version Control with Subversion, 2008. [3] M.
http://svnbook.red-bean.com/en/1.5/svn-book.html, stav ze 8. 4. 2010.
Klaene.
Securing
J2EE
Applications
with
a
Servlet
Filter.
http://www.developer.com/security/article.php/11580_3467801_1/ Securing-J2EE-Applications-with-a-Servlet-Filter.htm, stav ze 27. 5. 2010. [4] V. Král.
Návrh architektury systému na správu projekt·.
Bakalá°ská práce, Katedra
po£íta£·, Fakulta elektrotechnická, VUT v Praze, 2010. [5] D. Milstein.
Apache JServ Protocol version 1.3, 2000.
tomcat-3.3-doc/AJPv13.html,
http://tomcat.apache.org/
stav ze 25. 4. 2010.
[6] R. Mordani. JSR-000154 Java Servlet Speci cation Version 2.5 MR6, 2007.
org/aboutJava/communityprocess/mrel/jsr154/index2.html,
http://jcp.
stav ze 10. 5. 2010.
[7] R. L. Morgan, S. Cantor, S. Carmody, W. Hoehn, and K. Klingenstein. Federated Security: The Shibboleth Approach. http://www.educause.edu/EDUCAUSE+Quarterly/ EDUCAUSEQuarterlyMagazineVolum/FederatedSecurityTheShibboleth/157315, stav ze 28. 4. 2010. [8] I. Novakov.
aplikace,
Aplikace podporující FELid.
https://wiki.feld.cvut.cz/net/felid/
stav ze 11. 4. 2010.
[9] I. Novakov. Kon gurace service provideru - felid wiki.
net/admin/aai/provoz/konfigurace/index, [10] I. Novakov.
Registrace SP do federace FELid.
admin/aai/provoz/pozadavky,
https://wiki.feld.cvut.cz/
stav ze 20. 4. 2010.
https://wiki.feld.cvut.cz/net/
stav ze 21. 4. 2010.
[11] H. Reusser. Deployment of Shibboleth Service provider (SP) 2.3.1 on Debian GNU/Li-
https://www.switch.ch/aai/docs/shibboleth/SWITCH/ 2.3/sp/deployment/debian-lenny-source.html, stav ze 25. 4. 2010. nux 5.0 from sources, 2010.
[12] Z. Rybola.
Analýza poºadavk· pro systém na správu projekt·. Diplomová práce, Katedra
po£íta£·, Fakulta elektrotechnická, VUT v Praze, 2010.
43
44
LITERATURA
Spring Security SAML module, 2009. http://jira.springframework. org/secure/attachment/15148/SpringSecurity+SAML+-+documentation.pdf, stav
[13] V. Schäfer.
ze 21. 5. 2010. [14] J. M. Stewart, E. Tittel, and M. Chapple.
rity Professional Study Guide.
CISSP: Certi ed Information Systems Secu-
Sybex, 4th edition, 2008. In English.
http://blog.springsource.com/ 2010/03/06/behind-the-spring-security-namespace/, stav ze 15. 5. 2010.
[15] L. Taylor. Behind the Spring Security Namespace.
Podpora pro nástroje na správu zdrojového kódu pro aplikaci SWINPRO.
[16] J. Ustohal.
Bakalá°ská práce, Katedra po£íta£·, Fakulta elektrotechnická, VUT v Praze, 2010. [17] Acegi Security System for Spring.
http://www.acegisecurity.org/, stav ze 11. 5. 2010.
http://www.authenticationworld.com/,
[18] Authentication World.
[19] Pro správce - eská akademická federace identit eduID.cz.
eduid/admins/index,
stav ze 27. 4. 2010.
http://www.eduid.cz/wiki/
stav ze 20. 4. 2010.
http://download.oracle.com/docs/cd/ E12840_01/wls/docs103/security/fat_client.html#wp1047391, stav ze 2. 4. 2010.
[20] Using JAAS Authentication in Java Clients.
http://www.josso.org/ confluence/display/JOSSO1/JOSSO+-+Java+Open+Single+Sign-On+Project+Home,
[21] JOSSO
-
Java
Open
Single
Sign-On
Project
Home.
stav ze 27. 4. 2010. [22] Con guring Web Browsers for Kerberos Authentication.
edu/topics/applications/kerberos/4782/,
http://www.helpdesk.umd.
stav ze 2. 4. 2010.
installation on Debian. http://www.debian-administration.org/ article/OpenLDAP_installation_on_Debian, stav ze 27. 4. 2010.
[23] OpenLDAP
http://www.h-online.com/open/ news/item/Oracle-kills-OpenSSO-Express-ForgeRock-steps-in-939634.html,
[24] Oracle kills OpenSSO Express - ForgeRock steps in. stav ze 2. 4. 2010.
v2.0 Executive Overview. http://www.oasis-open.org/committees/ download.php/13525/sstc-saml-exec-overview-2.0-cd-01-2col.pdf, stav ze
[25] SAML
27. 4. 2010. Architecture. http://shibboleth.internet2.edu/docs/ internet2-mace-shibboleth-arch-protocols-200509.pdf, stav ze 27. 4. 2010.
[26] Shibboleth
[27] Shibboleth Authentication Expert Demo.
html,
http://www.switch.ch/aai/demo/expert.
stav ze 20. 4. 2010.
[28] Shibboleth 2 Documentation.
https://spaces.internet2.edu/display/SHIB2/Home,
stav ze 21. 4. 2010. introduction to Shibboleth Federations. http://iamsect.ncl.ac.uk/ deliverables/docs/federations/index.html#id2468386, stav ze 27. 4. 2010.
[29] An
LITERATURA
45
https://www.switch.ch/aai/docs/ shibboleth/SWITCH/1.3/sp/install-sp-1.3-win2003.html#iis-configuration,
[30] Install Shibboleth SP on Windows 2003 Server. stav ze 24. 4. 2010. [31] Install Shibboleth to protect Java Servlets.
SHIB2/NativeSPJavaInstall, [32] Shibboleth
https://spaces.internet2.edu/display/
stav ze 25. 4. 2010.
http://shibboleth.internet2.edu/project.html,
Project.
stav
ze
4. 5. 2010.
http://download.opensuse.org/repositories/
[33] Shibboleth openSUSE repository.
security://shibboleth/, [34] Shibboleth
Service
stav ze 24. 4. 2010.
Provider
http://shib.kuleuven.be/docs/sp/
Usage.
Shibboleth-SP-usage-v1.2.pdf,
stav ze 21. 5. 2010.
[35] Spring Security - Frequently Asked Questions.
spring-security/site/faq.html, [36] Spring
Security
Main
http://static.springsource.org/
stav ze 11. 5. 2010.
http://static.springsource.org/
Features.
spring-security/site/features.html,
stav ze 10. 5. 2010.
http://static.springsource.org/ spring-security/site/extensions/krb/index.html, stav ze 10. 5. 2010.
[37] Spring
Security
Kerberos
Extension.
[38] Add support for SAML 2.0 SSO - Spring Projects Issue Tracker.
springframework.org/browse/SEC-1004, [39] The
Trac
TracGuide,
User
and
Administration
stav ze 9. 4. 2010.
http://jira.
stav ze 21. 5. 2010.
Guide.
http://trac.edgewall.org/wiki/
46
LITERATURA
Dodatek A
Instala£ní p°íru£ka A.1 Systém Shibboleth Instalace Pokud by p°i instalaci do²lo k n¥jakým problém·m, odkazuji £tená°e na materiál [11], ze kterého bylo p°i tvorb¥ této p°íru£ky £erpáno.
A.1.1 Kompilace a instalace systému Jak jiº byl zmín¥no v textu, distribuce Debian neobsahuje systém Shibboleth ve svých repozitá°ích. Proto je jedinou moºností jak ho nainstalovat, je jeho zkompilování ze zdrojových kód·, které jsou voln¥ ke staºení na adrese
shibboleth/cppsp/latest/.
http://shibboleth.internet2.edu/downloads/
P°edtím neº je moºné za£ít kompilovat zdrojové kódy, musí být do systému doinstalovány balí£ky obsahující knihovny, které jsou ke kompilaci vyºadovány. Seznam vyºadovaných knihovna je obsaºen v tabulce A.1.
Název balí£ku
Popis
apache2
webový server Apache 2.2
openssl
knihovna s nástroji pro asymetrickou kryptogra i
ntp
sluºba protokolu NTP
gcc, g++, make
nástroje pro kompilaci zdrojových kód· v C/C++
libssl0.9.8 libssl-dev
knihovny vyºadované balí£kem openssh
libcurl3 libcurl3-dev
knihovna pro podporu p°enosu soubor· po síti
libxerces-c28 libxerces-c2-dev
knihovny XML parseru Xerces
libxml-security-c14 libxml-security-c-dev
knihovna zprost°edkující zpracování XKMS zpráv
apache2-threaded-dev
hlavi£kové soubory modul· serveru Apache
Tabulka A.1: Prerekvizity pro kompilaci systému Shibboleth[11]
47
48
DODATEK A. INSTALANÍ PÍRUKA
Balí£ek libxml-security-c14 není p°ítomen v repozitá°ích systému Debian Etch (dostupná je star²í verze). Na²t¥stí je moºné tento balí£ek stáhnout z Debian
backports
repozitá°· na
http://www.backports.org/ obsahujícího verze balí£k· ur£ené primárn¥ pro Debian Lenny zp¥tn¥ portované pro Etch. Po nainstalování prerekvizit stáhneme následující archivy se zdrojovými kódy následují-
1
cích aplikací :
•
log4shib-1.0.4.tar.gz
•
xmltooling-1.3.3.tar.gz
•
opensaml-2.3.tar.gz
•
shibboleth-sp-2.3.1.tar.gz
Tyto balí£ky poté rozbalíme do libovolného adresá°e.s V rámci p°íkazové °ádky speci kujeme prom¥nnou cílovému instala£nímu adresá°i, a prom¥nnou
MYBUILD,
SHIB_HOME,
která obsahuje cestu k
která obsahuje cestu k adresá°i se
staºenými zdrojovými kódy.
export MYBUILD=~/shibsp2.3.1-build export SHIB_HOME=/opt/shibboleth-sp-2.3.1/ Provedeme kompilaci zdrojových kod·:
export SHIB_HOME=/opt/shibboleth-sp-2.3.1/ sudo mkdir $SHIB_HOME cd $MYBUILD/log4shib-1.0.4/ ./configure --disable-static --disable-doxygen --prefix=$SHIB_HOME make sudo make install cd $MYBUILD/xmltooling-1.3.3/ ./configure --with-log4shib=$SHIB_HOME --prefix=$SHIB_HOME -C make sudo make install cd $MYBUILD/opensaml-2.3/ ./configure --prefix=$SHIB_HOME --with-log4shib=$SHIB_HOME -C make sudo make install cd $MYBUILD/shibboleth-2.3.1/ ./configure --with-saml=$SHIB_HOME --enable-apache-22 --with-log4shib=$SHIB_HOME \ 1
Tyto archivy jsou ke stáhnutí na adrese: http://shibboleth.internet2.edu/downloads
A.1. SYSTÉM SHIBBOLETH
49
--with-xmltooling=$SHIB_HOME --prefix=$SHIB_HOME -C make sudo make install
A.1.2 Kon gurace Apache modulu modshib V adresá°i
/etc/apache2/mods-available
vytvo°íme soubor
shib.load
a do n¥j umístíme ná-
sledující direktivu, která nám zajistí nahrání tohoto modulu p°i startu serveru.
LoadModule mod_shib /opt/shibboleth-sp2/lib/shibboleth/mod_shib_22.so Ve stejném adresá°i vytvo°íme kon gura£ní soubor tohoto modulu
shib.conf. Do n¥j vlo-
ºíme direktivu ShibCon g, která speci kuje modulu modshib cestu k hlavnímu kon gura£nímu souboru sluºby
shibd.
ShibConfig /etc/shibboleth/shibboleth2.xml Allow from all Alias /shibboleth-sp/main.css /opt/shibboleth/share/doc/shibboleth/main.css Alias /shibboleth-sp/logo.jpg /opt/shibboleth/share/doc/shibboleth/logo.jpg Do /etc/apache2/envvars p°idáme de nici prom¥nné
LD_LIBRARY_PATH
ur£ující cestu ke
knihovnám systému Shibboleth.
export LD_LIBRARY_PATH=/opt/shibboleth-sp2/lib
A.1.3 Kon gurace sluºby shibd Tato £ást p°íru£ky pov¥t²inou popisuje nastavení Shibboleth daemona, úpravou kon gura£ního souboru shibboleth2.xml. Z d·vodu p°ehlednosti, jsou zde v²ak uvedeny pouze úryvky tohoto souboru, d·leºité pro kon guraci. Neº se m·ºeme pustit do kon gurace shibd, je vhodné abychom zaru£ili jeho automatické spu²t¥ní p°i startu systému. To zaru£íme zkopírováním jeho spou²t¥cího skriptu do adresá°e /etc/init.d.
sudo chmod +x /etc/init.d/shibd sudo update-rc.d shibd defaults Následuje nastavení logování systému, bez jehoº p°ítomnosti odmítne sluºba shibd nastartovat. Nastavené logovacího mechanizmu probíhá v souborech native.logger, shibd.logger a syslog.logger. Tyto soubory je moºné zkoipírovat bez jakékoliv dal²í úpravy z instala£ního adresá°e.
50
DODATEK A. INSTALANÍ PÍRUKA
sudo cp /opt/shibboleth/etc/shibboleth/native.logger /etc/shibboleth/ sudo cp /opt/shibboleth/etc/shibboleth/shibd.logger /etc/shibboleth/ sudo cp /opt/shibboleth/etc/shibboleth/syslog.logger /etc/shibboleth/ Jak jiº bylo zmín¥no, Shibboleth service provider pot°ebuje k podpisování zpráv posílaných v rámci komunikace s poskytovatelem identity podepsaný certi kát. Pokud server, na kterém se pokou²íme systém Shibboleth nasadit, takový certi kát nemá, pak je moºné si vygenerovat
self-signed
certi kát utilitou
openssl.
Nyní jiº m·ºeme p°istoupit k samotné kon guraci sluºby shibd, nacházející se v souboru shibboleth2.xml. Tato £ást je v podstat¥ obsahem kapitoly 5.2. P°esto je zde zmín¥na z d·vodu zachování ucelenosti této p°íru£ky. První zm¥nu ve výchozím kon gura£ním souboru provedeme v elementu kde nastavíme hodnotu jeho podelementu
Host
RequestMapper,
na aktuální DNS serveru následovn¥:
<Path name="" requireSession="true" /> Stejnou hodnotu nastavíme i elementu Site uvnit° ISAPI.
<Site id="1" name="rabbit.felk.cvut.cz"/> Nastavíme identi kátor
entityID
identi kující na²í sluºbu v rámci federace.
<ApplicationDefaults id="default" policyId="default" entityID="https://rabbit.felk.cvut.cz/shibboleth/swinpro" homeURL="https://rabbit.felk.cvut.cz/" REMOTE_USER="felid-uid eppn persistent-id targeted-id" signing="true" encryption="true" attributePrefix="felid-" > Následn¥ nasm¥rujeme service providera na zdrojová metadata federace FELid a zárove¬ s tím udáme cestu k souboru
felid-metadata-backup.xml
obsahující záloºní lokální kopii t¥chto
metadat.
<MetadataProvider type="XML" uri="https://ovt.feld.cvut.cz/felid/rep/metadata/felid-metadata.xml" backingFilePath="felid-metadata-backup.xml" reloadInterval="7200">
A.1. SYSTÉM SHIBBOLETH
51
Nastavíme cestu k na²emu certi kátu, který jsme p°edtím vygenerovali.
Zadáme cestu k souboru obsahující mapování atribut· nabízených federací FELid.
Te¤ uº jen zbývá stáhnout soubor s mapováním atribut· attribute-map.xml ze stránek federace FELid
xml
https://ovt.feld.cvut.cz/felid/rep/sp/config/2.1/attribute-map.
a umístit jej do adresá°e /etc/shibboleth. To samé provedeme i se záloºním souborem
https://ovt.feld.cvut.cz/felid/rep/metadata/ felid-metadata.xml. Tento soubor musíme anvíc p°ejmenovat na felid-metadata-backup.xml. metadat federace, který je ke staºení na
A.1.4 Kon gurace Shibboleth rozhraní aplikace SWINPRO Kon gurace je dostupná v souboru security-context-shib.xml v adresá°i WEB-INF v adresá°i se zdrojovými kódy aplikace. První
úpravou,
kterou
musí
administrátor
v
tomto
souboru
p°i
instalaci
pro-
vést je nastavení hodnoty loginUrlPropertyBean (). Tato springová beana je ve skute£nosti oby£ejná prom¥nná typu String a udává, kam bude uºivatel p°esm¥rován po kliknutí na tla£ítko P°ihlásit aby
bylo
v
menu
zaji²t¥no,
aplikace. ºe
se
Hodnota
p°i
zm¥n¥
tohoto
odkazu
p°ihla²ování
na
je
realizována
LDAP
(tedy
tímto
p°i
zp·sobem
vým¥n¥
secu-
rity context soubor·), zm¥ní tento odkaz automaticky a není tím pádem nutné zasahovat
do
JSP
stránky.
Nastavení
URL
odkazu
v
loginPropertyBean musí vºdy /Shibboleth.sso/Login).
sm¥°ovat na p°ihla²ovací vstupní bod sevice providera (tedy Toto
URL
kon£ení
musí
také
p°ihlá²ení.
obsahovat
Tento
parametr
parametr
musí
target,
být
vºdy
údávající
cíl
nastaven
na
p°esm¥rování adresu
JSF
po
do-
stránky
/swinpro/faces/shib-auth-forwarder.jsp. Výsledná podoba takového odkazu tedy m·ºe být nap°íklad: "http://rabbit.felk.cvut.cz/Shibboleth.sso/Login?target=https% 3a%2f%2frabbit.felk.cvut.cz%2fswinpro%2ffaces%2fshib-auth-forwarder.jsp Podobn¥ jako je pot°eba upravit adresu p°ihla²ovacího odkazu, je nezbytné ur£it URL, na kterou je uºivatel p°esm¥rován p°i svém odhlá²ení. To zajistíme nastavením prvního parametru konstruktoru LogoutFilteru.
<property name="filterProcessesUrl" value="/j_spring_security_logout"/> Posledním
loginFormUrl jako v p°ípade
nastavením
v
souboru
security-context-shib.xml
je
nastavení
authenticationProcessingFilterEntryPoint loginPropertyBean.
v bean¥
prom¥nné
na hodnotu stejnou
52
DODATEK A. INSTALANÍ PÍRUKA
A.2 Nastavení LDAP autentizace A.2.1 Instalace a kon gurace sluºby LDAP P°i instalaci a kon guraci sluºby LDAP na systém Debian bylo, aº na drobné odchylky postupováno podle návodu na[23]. Tato podkapitola popisuje jak je moºné tento postup zopakovat. LDAP server je standardní sou£ástí balí£k· tém¥° kaºdé Linuxové distribuce. Proto není problém jej na systémech Debian nainstalovat z repozitá°· p°íkazem:
sudo apt-get install slapd ldap-utils libldap2 libdb4.6 V pr·b¥hu instalace budete dotázání na DNS serveru a název organizace. Jako obojí tedy zadáme nap°íklad
rabbit.felk.cvut.cz.
Dal²í informací, která po nás bude poºadována
bude heslo administrátora. Po vypln¥ní t¥chto údaj· bude nastartován proces
slapd,
coº
vlastní sluºba LDAP serveru. Následuje úvodní kon gurace serveru. V souboru
/etc/slapd/slapd.conf zkontrolujeme
jestli jsou povolena v²echna základní schémata.
include include include include
/etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/nis.schema /etc/ldap/schema/inetorgperson.schema
V tomto souboru také nastavíme maximální úrove¬ logování °ádkem:
loglevel 256 V souboru
/etc/ldap/ldap.conf
nastavíme následující °ádky.
BASE dc=felk,dc=cvut,dc=cz URI ldap://rabbit.felk.cvut.cz Aby se tyto zm¥ny projevily je nutné sluºbu slapd restartovat.
sudo sudo sudo sudo
invoke-rc.d slapd stop slapindex chown openldap:openldap /var/lib/ldap/* invoke-rc.d slapd start
Nyní by m¥l být LDAP server nainstalovaný a správn¥ nakon gurovaný. Nyní je jiº moºné v n¥m vytvo°it adresá°ovou strukturu, která bude slouºit k ukládání uºivatelských ú£t·. K tomu nám m·ºe poslouºit p°íkaz
ldif,
který je schopný nahrát do LDAP adresá°e
p°edp°ipravenou strukturu de novanou v externím textovém souboru. mnohem p°íjemn¥j²í a jednodu²²í je v²ak pouºití n¥kterého z gra ckých manaºer· jako je nap°íklad JXplorer, který je moºné pouºít i k vytvo°ení testovací uºivatelských ú£t·. Na uºivatelské ú£ty se klade poºadavek, aby byli vytvá°eny jako instance objektové t°ídy (objectclass) inetOrgPerson. Pokud toto není zaru²eno, nemá autentiza£ní mechanizmus aplikace SWINPRO dostatek informací o uºivatel, aby pro n¥j mohla aplikace vytvo°it ú£ty ve své databázi (více v kapitole 6.3). Nyní kdyº je LDAP server p°ipraven, je pot°eba nakon gurovat autentiza£ní rozhraní SWINPRO tak, aby se k n¥mu mohlo p°ipojit a za£ít oproti n¥mu ov¥°ovat klienty.
A.2. NASTAVENÍ LDAP AUTENTIZACE
53
A.2.2 Kon gurace LDAP rozhraní aplikace SWINPRO Pro zm¥nu kon gurace LDAP autentizace není nutné jakéhokoliv zásahu do zdrojových kód· a jejich rekompilace, protoºe ve²keré kon gura£ní nastavení je p°ítomné v XML souboru
security-context-ldap.xml
v podadresá°i
WEB-INF
projektu aplikace SWINPRO.
Aby se aplikace mohla p°ipojit k LDAP databázi, musí mít de novaný cestu k serveru (jeho URL), na kterém je tato databáze umíst¥na. To se nastavuje de nováním beany s názvem
ldapContextSource
jak ukazuje následující p°íklad.
<property name="userDn" value="cn=admin,dc=felk,dc=cvut,dc=cz"/> <property name="password" value=""/> 2
Argument konstruktoru de nuje URL serveru následovaný DN adresá°e, který bude slouºit jako ko°enový adresá° p°i ov¥°ování autentiza£ních dotaz·. Atributy
userDn
a
password
jsou nepovinné a jsou pouºity pouze v p°ípad¥ kdy je pouºita ov¥°ovací strategie de no-
3
vaná t°ídou PasswordComparisonAuthenticator . V tom okamºiku odpovídají administrátorskému ú£tu, který byl na serveru vytvo°en p°i jeho instalaci. Na záv¥r je nezbytné stanovit, ve které organiza£ní jednotce se nachází uºivatelské ú£ty a který z jejich atribut· reprezentuje uºivatelské jméno
userDnPatterns
t°ídy
4 . To je ur£enou prom¥nnou
BindAuthenticator.
<property name="userDnPatterns"> <list>uid={0},ou=people Kompletní kon gura£ní soubor s jiº nastaveným ov¥°ováním proti testovacímu serveru je samoz°ejm¥ sou£ástí CD p°iloºeného k této práci.
Distinguished Name ov¥°ovací strategie jsou blíºe rozebírány v kapitole 6.3 4 typicky je to atribut uid 2 3
54
DODATEK A. INSTALANÍ PÍRUKA
Dodatek B
Seznam pouºitých zkratek ACL
Access Control List
ACS
Assertion Consumer Service
AJP
Apache JServ Protocol
API
Application Programming Interface
CAS DN
Central Authentication Service
Distinguished Name
HTTP
Hypertext Transfer Protocol
IdP
Identity Provider
IoC
Inversion of Control
JAAS JRE JSF
Java Authentication and Authorization Service
Java Runtime Environment Java Server Faces
LDAP MACE SAML SP
Lightweight Directory Access Protocol Middleware Architecture Committee for Education Security Assertion Markup Language
Service Provider
SSH
Secure Shell
SSO
Single-sign on
SVN URN
Subversion Uniform Resource Name
55
56
DODATEK B. SEZNAM POUITÝCH ZKRATEK
WAYF
Where Are You From Service
WebDAV XML
Web-based Distributed Authoring and Versioning
Extensible Markup Language
Dodatek C
Obsah CD . |-|-| | | | | | | `--
latexsrc sources |-- shib_config |-- svn_access `-- swinpro_auth |-- auth | |-- ldap | `-- shibboleth `-- security_context_config text
zdrojové soubory tohoto textu ve formátu LaTex adresá° se zdrojovými soubory konfigura£ní soubory systému Shibboleth skript °ízení p°ístupu k svn repozitá°·m zdrojové kódy autentiza£ního rozhraní
konfigura£ní soubory pro Spring Security adresá° obsahující PDF s textem této práce
57
