Kerberos, SSO a web

12. 8. 2008 | Jiří Mlíka | Bezpečnost | 10014×

V dnešním dílu seriálu o SSO v Linuxu prozkoumáme, jak můžeme využít SSO při práci s webem. Ukážeme si konfiguraci podpory Kerbera ve webovém serveru Apache. Dále se podíváme na podporu Kerbera v v populárních webových prohlížečích Konqueror, Mozilla Firefox a Internet Explorer.

Úvod

Možná se teď někteří z vás ptají, jaký má SSO u webu smysl. Web je nedílnou součástí Internetu a na Internetu nikdy nedosáhneme stavu, kdy by všichni uživatelé patřili do jednoho Kerberos realmu, nebo všechny realmy měly mezi sebou navázaný cross realm trust. Odpovědí na tuto otázku jsou intranetové aplikace, které zdomácněly v mnoha organizacích.

Konfigurace serveru

Nezbytná systémová nastavení

Jako webový server pro naše pokusy použijeme nový stroj srv-web1.firma.local. Nezbytná systémová nastavení budou stejná jako v předchozích případech popsaných v seriálu. Pro úplnost zde uvádím odkazy na soubory /etc/hosts a /etc/krb5.conf tohoto stroje.

Instalace Apache

Instalace webového serveru Apache je podle očekávání jednoduchá. Myslím, že není třeba ji nijak zvlášť popisovat. Následující výpis uvádím, aby bylo zcela zřejmé, které komponenty jsem nainstaloval.

[root@srv-web1 etc]# urpmi apache
Je zapotřebí jeden z následujících balíčků:
1- apache-mpm-itk-2.2.4-6.4mdv2007.1.i586: Implements a non-threaded, pre-forking web server (experimental) (k instalaci)
2- apache-mpm-event-2.2.4-6.4mdv2007.1.i586: Implements a hybrid multi-threaded multi-process web server (experimental) (k instalaci)
3- apache-mpm-prefork-2.2.4-6.4mdv2007.1.i586: Implements a non-threaded, pre-forking web server (stable) (k instalaci)
4- apache-mpm-worker-2.2.4-6.4mdv2007.1.i586: Implements a hybrid multi-threaded multi-process web server (experimental) (k instalaci)
Jaká je vaše volba? (1-4) 3
Aby byly splněny závislosti, budou nainstalovány následující balíčky
apache-base-2.2.4-6.4mdv2007.1.i586
apache-conf-2.2.4-4mdv2007.1.i586
apache-modules-2.2.4-6.4mdv2007.1.i586
apache-mpm-prefork-2.2.4-6.4mdv2007.1.i586
Pokračovat v instalaci 4 balíčků? (2 MB) (A/n) A
...

Dále jsem nainstaloval podporu PHP do Apache. PHP s funkcí a konfigurací Kerbera nesouvisí, proto s detaily instalace nebudu čtenáře unavovat. PHP použiji při testování pro výpis některých zajímavých údajů.

Autentizační modul

Funkce

Kerberos autentizace je ve webovém serveru Apache zajištěna pomocí modulu mod_auth_kerb. Webový server a prohlížeč se dokáží dohodnout na autentizační metodě. Podporují-li oba SSO a uživatel má vystaven TGT, bude použita SSO autentizace. Pokud některá z podmínek pro SSO není splněna, mohou se dohodnout na jiném typu autentizace. Kromě uživatelského pohodlí je tak ovlivněna i bezpečnost. Některé autentizační metody např. "basic" přenášejí uživatelské jméno a hlavně heslo "po drátě" v nešifrované podobě. Proto i tam, kde se používá Kerberos autentizace, která je samo osobě bezpečná, je dobré použit pro přenos dat mezi webovým serverem a prohlížečem protokol HTTPS.

V případě, že se webový prohlížeč a server dohodnou na "basic" autentizaci, nedojde sice k použití SSO, ale modul alespoň dokáže ověřit heslo proti Kerberu, takže je zachována možnost jednotných hesel v celé námi spravované síti.

Instalace

Na Mandrivě máme dvě možnosti, jak autentizační modul nainstalovat. Příslušný balík není součástí základní distribuce, ale můžeme jej nalézt ve volitelném instalačním repositáři contrib. V takovém případě je instalace jednoduchá. Spočívá v jediném příkazu:

urpmi apache-mod_auth_kerb

Já sem zvolil instalaci modulu přímo ze zdrojových kódů. Nainstaloval jsem nejprve balíky se hlavičkovými soubory Apache a knihoven Kerbera, jak mi radila dokumentace k modulu.

[root@srv-web1 ~]# urpmi apache-devel
[root@srv-web1 ~]# urpmi libkrb53-devel

Zdrojové kódy modulu jsem rozbalil do adresáře ~/mod_auth_kerb-5.3. V tomto adresáři jsem modul zkompiloval a nainstaloval pomocí "Svaté trojice".

[root@srv-web1 mod_auth_kerb-5.3]# ./configure --with-krb5=/usr/include/krb5/
[root@srv-web1 mod_auth_kerb-5.3]# make
[root@srv-web1 mod_auth_kerb-5.3]# make install

Konfigurace Apache

Konfiguraci autentizačního modulu provádím přímo v hlavním konfiguračním souboru Apache /etc/httpd/conf/httpd.conf. Soubor je to poměrně rozsáhlý a odkazuje se na další soubory a adresáře. Zde uvádím pouze výtah direktiv důležitých pro naše bádání. Tučně jsou uvedeny direktivy týkající se samotného modulu mod_auth_kerb.

#Soubor /etc/httpd/conf/httpd.conf

ServerRoot "/etc/httpd"
...
Include modules.d/*.conf
...
User apache
Group apache
...
DocumentRoot "/var/www/html"
...
<Directory "/var/www/html"> 
    Options -Indexes FollowSymLinks MultiViews
    AllowOverride None
    Order allow,deny
    Allow from all
</Directory>
...


LoadModule auth_kerb_module modules/mod_auth_kerb.so 

<Directory "/var/www/html/krbauth"> 
    AuthType    Kerberos
    AuthName    "Kerberos Login"
    KrbAuthRealms       FIRMA.LOCAL
    Krb5Keytab  /etc/httpd/keytab
    require valid-user
</Directory>

Apache umožňuje konfigurovat autentizaci pro konkrétní adresář. V "DocumentRootu" web serveru /var/www/html jsem vytvořil adresář krbauth přístupný z webového prohlížeče pomocí URL http://srv-web1.firma.local/krbauth/. Apache pro tento adresář vyžaduje autentizaci (require valid-user). Autentizaci zajistí modul mod_auth_kerb (AuthType Kerberos). Služba web serveru na stroji srv-web1.firma.local potřebuje principal (SPN) z Kerberos realmu FIRMA.LOCAL (KrbAuthRealms), jehož klíč nalezne v "keytabu" /etc/httpd/keytab (Krb5Keytab). Aby mohl být modul použit, je třeba jej nejprve zavést (LoadModule).

Principal služby

Jak bylo zmíněno dříve a jak jistě tušíte i služba web serveru bude potřebovat svůj principal (SPN). Vytvoříme jej nám již dobře známým nástrojem kadmin.

[root@srv-web1 ~]# kadmin -p krbadmin/admin
Authenticating as principal krbadmin/admin with password.
Password for krbadmin/admin@FIRMA.LOCAL:

kadmin: addprinc -randkey HTTP/srv-web1.firma.local@FIRMA.LOCAL
WARNING: no policy specified for HTTP/srv-web1.firma.local@FIRMA.LOCAL; defaulting to no policy
Principal "HTTP/srv-web1.firma.local@FIRMA.LOCAL" created.
kadmin:


Klíče principalu neuložíme do systémového "keytabu" /etc/krb5.keytab, nýbrž do vlastního "keytabu" web serveru /etc/httpd/keytab. Proč? Protože web server běžící pod uživatelem apache a skupinou apache nemá přístup do systémového "keytabu". Ten je obvykle čitelný pouze pro uživatele root.

kadmin: ktadd -k /etc/httpd/keytab HTTP/srv-web1.firma.local@FIRMA.LOCAL
Entry for principal HTTP/srv-web1.firma.local@FIRMA.LOCAL with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab
WRFILE:/etc/httpd/keytab.
Entry for principal HTTP/srv-web1.firma.local@FIRMA.LOCAL with kvno 3, encryption type AES-128 CTS mode with 96-bit SHA-1 HMAC added to keytab
WRFILE:/etc/httpd/keytab.
Entry for principal HTTP/srv-web1.firma.local@FIRMA.LOCAL with kvno 3, encryption type AES-256 CTS mode with 96-bit SHA-1 HMAC added to keytab
WRFILE:/etc/httpd/keytab.
Entry for principal HTTP/srv-web1.firma.local@FIRMA.LOCAL with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab
WRFILE:/etc/httpd/keytab.


Přístupová práva ke "keytabu" Apache patřičně upravíme.

[root@srv-web1 ~]# chown root.apache /etc/httpd/keytab
[root@srv-web1 ~]# chmod 640 /etc/httpd/keytab

Start webového serveru

Server je připraven a můžeme jej nastartovat.

[root@srv-web1 ~]# service httpd start

Testovací stránka

Pokud se autentizace zdaří, bylo by dobré vidět něco milého v okně prohlížeče. Rozpomenul jsem se na své nesmělé pokusy s PHP z doby před 10 lety a vytvořil jsem malý skript, který zobrazí pár zajímavých údajů. Zároveň se snažím demonstrovat, jak můžeme identitu uživatele úspěšně ověřenou webovým serverem dále používat ve webových aplikacích. Skript jsem umístil do adresáře /var/www/html/krbauth jako soubor s názvem index.php.

<html><body>

        <h1>Funguje to! </h1>

<? 
echo "<code>";
echo "Promenne web serveru: <br>";
echo "--------------------- <br>";
echo "<br>";

echo "AUTH_TYPE:       {$_SERVER[AUTH_TYPE]}       <br>";
echo "REMOTE_USER:     {$_SERVER[REMOTE_USER]}     <br>";
echo "HTTP_USER_AGENT: {$_SERVER[HTTP_USER_AGENT]} <br>";

echo "</code>"
?>

</body></html>

Konfigurace linuxového klienta

Jako klienta použijeme opět stroj pc1.firma.local. Po systémové stránce je již nakonfigurovaný z předchozích dílů seriálu. Do jeho konfiguračního souboru /etc/host pouze přidáme záznam pro nový server srv-web1.firma.local.

Konqueror

Konqueror podporuje SSO zcela hladce. Není třeba vůbec nic konfigurovat. Zcela stačí, že jsme přihlášení pomocí Kerbera - tudíž máme TGT. V našem případě jsme přihlášeni jako uživatel josef_vosahlo. Při zadání URL http://srv-web1.firma.local/krbauth/ prohlížeč dohodne s webovým serverem metodu autentizace (AUTH_TYPE: Negotiate) a získá od Ticket Granting Service (TGS) tiket pro použití služby HTTP na stroji srv-web1.firma.local. Stav tiketů uživatele vypsaný příkazem klist můžeme vidět v okně terminálu na screenshotu. Všimněte si tiketu pro službu. HTTP/srv-web1.firma.local@FIRMA.LOCAL.

V okně Konqueroru vidíme pár zajímavých proměnných web serveru vypsaných testovacím PHP skriptem. Můžeme vidět metodu autentizace, na které se dohodl prohlížeč se serverem. Vidíme i identitu uživatele, tu lze dále využít ve webové aplikaci.

Napadlo mě, co by se asi stalo, kdybych se pokusil přistoupit k chráněné stránce, aniž bych byl autentizován pomocí Kerbera. Vymazal jsem tedy všechny tikety uživatele pomocí příkazu kdestroy (viz okno terminálu) a znovu jsme prohlížeč nasměroval na URL chráněné stránky. Podle očekávání prohlížeč zobrazil autentizační dialog, neboť se s webovým serverem domluvil na autentizaci "basic".

Pozn.: Všimněte si, že dialog je nazván "Authorization Dialog". Nepochopení rozdílů mezi autentizací a autorizací a jejich vzájemné zaměňování zjevně není problémem specifickým pouze pro naši zemi.

Poté, co jsme do autentizačního dialogu zadali uživatelské jméno a heslo, je tento pár odeslán webovému serveru v nešifrované podobě. V okně prohlížeče opět vidíme dohodnutou metodu autentizace a identitu přihlášeného uživatele.

Mozilla Firefox

Na rozdíl od Konqueroru Firefox vyžaduje určitou konfiguraci, aby byl schopen SSO použít. Jsme opět přihlášeni na klientu jako uživatel josef_vosahlo a máme příslušný TGT. Zadáme-li do adresního řádku speciální URL about:config, zobrazí se konfigurační proměnné prohlížeče. Je třeba nakonfigurovat, pro která URI má prohlížeč nabízet autentizaci typu "Negotiate". Nastavíme proměnné network.negotiate-auth.trusted-uris a network.negotiate-auth.delegation-uris na hodnotu firma.local.

Zadání URL chráněné stránky má prakticky stejný efekt jako v případě Konqueroru. Prohlížeč použije SSO. PHP skript zobrazuje stejné hodnoty proměnných AUTH_TYPE a REMOTE_USER.

Konfigurace Windows klienta

Internet Explorer

Stejně jako Firefox i Internet Explorer vyžaduje konfiguraci. Jak jsem vypozoroval, Internet Explorer se rozhoduje, kterému serveru nabídnout autentizaci pomocí SSO, podle bezpečnostních zón, jejichž nastavení najdeme v dialogu "Možnosti Internetu" na kartě "Zabezpečení (Nástroje / Možnosti Internetu... / Zabezpečení). Přidal jsem server srv-web1.firma.local do zóny "Důvěryhodné servery". Tato zóna má ve výchozím nastavení zapnutu možnost "Automatické přihlášení pod aktuálním uživatelským jménem a heslem", což je zřejmě ono.

Do Windows jsme přihlášeni opět pod uživatelem josef_vosahlo, což nám hezky ukazuje příkaz whoami z Resource Kitu, který jsem si do pokusných Windows doinstaloval. Ze stejného balíku je i příkaz klist. Ten podobně jako jeho ekvivalent na Linuxu umí zobrazit tikety uživatele. Stejně jako v případě předchozích pokusů můžeme vidět tiket pro službu HTTP/srv-web1.firma.local@FIRMA.LOCAL. Aby vše fungovalo bez DNS, je v souboru c:\windows\system32\drivers\etc\hosts záznam pro náš webový server srv-web1.firma.local. V okně prohlížeče opět vidíme identitu uživatele a použitou autentizační metodu.

Závěr

Kerberizace Apache díky zásuvným modulům není problém. Podpora SSO v hlavních prohlížečích je uspokojivá. Zatímco prohlížeče Firefox a Internet Explorer jsou trošku vybíravé v tom, s kým si budou hrát na SSO, Konqueror nabídne možnost SSO autentizace každému bez jakékoliv možnosti konfigurace (alespoň co mě je známo). Na platformě Apache(/PHP, ...) funguje velká spousta webových aplikací. Často jsem se setkal s tím, že webové aplikace řeší autentizaci po svém, tj. zobrazí uživateli vlastní autentizační dialog na webové stránce a ověřují heslo třeba proti LDAPu. Moc by se mi líbilo, kdyby se webové aplikace pokoušely nejprve zjistit identitu uživatele od web serveru a otevřely tak dveře pro jejich hladkou integraci do SSO prostředí. Při brouzdání po webu jsem přišel i na možnost, jak může PHP aplikace použít SSO, aniž by k tomu potřebovala podporu webového serveru.

V příštím dílu si ukážeme, jak Kerberos integrovat s LDAPem. LDAP bývá často využíván jako autorita pro ověření identity uživatelů. Některé aplikace, které neumí pracovat s Kerberem, umí pracovat právě s LDAPem. Proto je pro nás výhodné přesvědčit LDAP server, aby ověřování identity uživatele delegoval na Kerbera.

       

Komentáře

[Milan]

Pěkný článek, škoda že nevyšel před pár týdny, asi by mi ušetřil hodně času a nervů :) Jedna věc k doplnění - keytab soubor lze vytvořit i na windows serveru pomocí příkazu ktpass.exe (součástí WindowsServerTools). (ktpass.exe -princ HTTP/HOSTNAME@DOMENA -mapuser DOMENA\USER -crypto DES-CBC-MD5 -ptype KRB5_NT_PRINCIPAL -mapop set +desonly -pass HESLO_USER -out http.keytab)

Jedna otázka: Jak nastavit Windows server (doménový řadič), aby se uživatelům automaticky změnilo nastavení IE? (=automaticky přidal náš server do intranet zóny)

Díky, Milan

[smoco]

My puzivame ntlm autentifikaciu pre SSO a do trust sites v IE sme automaticky pridali nas intranet tak ze sme importli hodnotu do registru. Importujeme tam subor ttt.reg s obsahom :

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\centire.com]

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\centire.com\intranet] "https"=dword:00000001

Import spustame pri prihlaseni do domeny bat suborom s prikazom >

regedit /s \\cesta_k_suboru_na_zdielanom_disku\ttt.reg

[platYpus]

Pokud se jedna o domenovy radic postaveny na Windows 2000/2003/2008 tak je na to standardne volba v ActiveDirecotry GPO (User Configuration -> Windows Settiongs -> Internet Explorer Maintenance -> Security -> Security Zones and Content Ratings).

[slush]

Nevim, jestli to neni trochu offtopic, ale lze nejak jednoduse zmenit z linux klienta zmenit heslo do Windows domeny? Je to prece taky kerberos...