Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »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.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: