Portál AbcLinuxu, 1. května 2025 17:57
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.
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.
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 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ů.
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.
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
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).
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
Server je připraven a můžeme jej nastartovat.
[root@srv-web1 ~]# service httpd start
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>
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 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.
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.
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.
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.