IBM Tivoli Access Manager for e-business
Plug-in for Web Servers Integration Guide Verze 5.1
SC09-3712-00
IBM Tivoli Access Manager for e-business
Plug-in for Web Servers Integration Guide Verze 5.1
SC09-3712-00
Poznámka Než začnete používat uvedené informace a produkt, o který se opírají, přečtěte si informace uvedené v části Dodatek F, “Poznámky”, na stránce 213.
První vydání (Listopad 2003) Toto vydání platí pro verzi 5, vydání 1, modifikace 0 IBM Tivoli Access Manager (číslo produktu 5724-C08) a pro všechna následná vydání a modifikace, pokud nebude uvedeno jinak v novém vydání. © Copyright International Business Machines Corporation 2000, 2003. Všechna práva vyhrazena.
Obsah Obrázky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Tabulky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Pro koho je určena tato kniha . . Co tato kniha obsahuje . . . . Publikace . . . . . . . . Informace o vydání . . . . Základní informace . . . . Informace o zabezpečení Webu . Odkazy pro vývojáře . . . . Technické dodatky . . . . Související publikace . . . Online přístup k publikacím . . Dostupnost . . . . . . . . Kontakt na softwarovou podporu . Konvence používané v této knize . Konvence typu písma . . . . Rozdíly v operačních systémech
. .
. . . . . .
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. .
. . . . .
.
.
. .
. . . . .
. . . . .
.
. xiii . xiv . xv . xv . xv . xv . xvi . xvii . xvii . xx . xx . xx . xx . xx . xxi
. . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
. . . . .
. . . . . .
.
. .
.
. . . .
.
. .
. .
. . . . .
.
.
Kapitola 1. Úvod do produktu IBM Tivoli Access Manager Plug-in for Web Servers . . . . 1 Technologie produktu Tivoli Access Manager Plug-in for Web Servers . . . . . . . . . Základní provozní komponenty a architektura . . . . . . . . . . . . . . . . Podpora virtuálních hostitelů . . . . . . . . . . . . . . . . . . . . . Ochrana vašeho webového prostoru pomocí produktu Tivoli Access Manager Plug-in for Web Servers Autentizace produktu Tivoli Access Manager Plug-in for Web Servers . . . . . . . . . Získání pověření. . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
1 1 2 3 4 4
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers . . 7 Obecné informace o plug-in programu . . . . . . . . . . . . . . . . Kořenový adresář instalace produktu Tivoli Access Manager Plug-in for Web Servers . Konfigurační soubor pdwebpi.conf . . . . . . . . . . . . . . . . Konfigurační soubor pdwebpimgr.conf . . . . . . . . . . . . . . . Spuštění a zastavení procesu produktu Tivoli Access Manager Plug-in for Web Servers Chybové zprávy HTTP . . . . . . . . . . . . . . . . . . . . Podpora maker . . . . . . . . . . . . . . . . . . . . . . Makra související s formáty . . . . . . . . . . . . . . . . . . Konfigurace autorizačního serveru . . . . . . . . . . . . . . . . . Konfigurace pracovních vláken . . . . . . . . . . . . . . . . . Nastavení maximální doby trvání relace pro požadavky IPC . . . . . . . . Konfigurace chybových stránek . . . . . . . . . . . . . . . . . Konfigurace virtuálních hostitelských serverů . . . . . . . . . . . . . Konfigurace specifická pro webový server . . . . . . . . . . . . . . Pokyny pro webový server . . . . . . . . . . . . . . . . . . Výpisy objektu pro přizpůsobení . . . . . . . . . . . . . . . . . Parametry příkazového řádku . . . . . . . . . . . . . . . . . Výstup . . . . . . . . . . . . . . . . . . . . . . . . Konfigurace SU (switch user) pro administrátory . . . . . . . . . . . . Pochopení toku procesu přepnutí uživatele . . . . . . . . . . . . . Povolení přepnutí uživatele . . . . . . . . . . . . . . . . . . Konfigurace formuláře HTML pro přepnutí uživatele . . . . . . . . . . Povolení nebo vyloučení uživatelů z přepnutí uživatele . . . . . . . . . . Konfigurace mechanismu pro autentizaci přepnutí uživatele . . . . . . . .
© Copyright IBM Corp. 2000, 2003
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . .
. 7 . 7 . 8 . 9 . 9 . 9 . 10 . 10 . 11 . 11 . 12 . 12 . 13 . 15 . 17 . 18 . 18 . 19 . 19 . 20 . 20 . 20 . 22 . 22
iii
Ovlivnění funkcionality ostatních plug-in programů . . . . . . . . . . . . . Konfigurace přepnutí při selhání pro servery LDAP . . . . . . . . . . . . . . Podpora P3P (Platform for Privacy Preferences) hlaviček . . . . . . . . . . . . Konfigurování hlaviček P3P . . . . . . . . . . . . . . . . . . . . Konfigurace monitorování, protokolování, trasování a databáze paměti cache plug-in programu . Prověřovací záznamy . . . . . . . . . . . . . . . . . . . . . . Konfigurace monitorování . . . . . . . . . . . . . . . . . . . . Trasování akcí plug-in programu . . . . . . . . . . . . . . . . . . Nastavení databáze paměti cache . . . . . . . . . . . . . . . . . . Konfigurace služby autorizačního rozhraní API . . . . . . . . . . . . . . . Obnovení pověření . . . . . . . . . . . . . . . . . . . . . . . Konfigurování obnovení pověření . . . . . . . . . . . . . . . . . . Konfigurace ukládání do paměti cache požadavku HTTP . . . . . . . . . . . . Konfigurace parametrů server-side ukládání do paměti cache . . . . . . . . . . Podpora jazyků a znakové sady . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
23 24 25 25 28 29 30 31 32 33 33 33 34 35 35
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Proces zacházení s požadavkem . . . . . . . . . . . Proces autentizace . . . . . . . . . . . . . . . Konfigurace autentizace . . . . . . . . . . . . . Konfigurace autentizace virtuálních hostitelů . . . . . . Konfigurace pořadí politik autentizace . . . . . . . . Konfigurace zpracování následujícího po autorizaci . . . . Správa stavu relace . . . . . . . . . . . . . . Konfigurace paměti cache pro relace/pověření plug-in programu Udržování stavu relace pomocí ID relace SSL . . . . . Udržování stavu relace pomocí Základní autentizace . . . Udržování stavu relace pomocí cookies relace . . . . . Udržování stavu relace pomocí HTTP hlaviček . . . . . Udržování stavu relace pomocí IP adres . . . . . . . Udržování stavu relace pomocí LTPA cookies . . . . . Udržování stavu relace pomocí IV hlaviček . . . . . . Přehled konfigurace autentizace . . . . . . . . . . . Mechanismus lokální autentizace . . . . . . . . . Parametry externí uživatelské autentizace CDAS . . . . . Přednastavená konfigurace plug-in programů . . . . . . Konfigurace několika politik autentizace . . . . . . . Příkazy pro odhlášení, změnu hesla a nápovědu . . . . . Konfigurace Základní autentizace . . . . . . . . . . Aktivace Základní autentizace . . . . . . . . . . Konfigurace mechanismu pro Základní autentizaci . . . . Nastavení jména sféry . . . . . . . . . . . . Práce s BA hlavičkami . . . . . . . . . . . . Uvedení UTF-8 zakódování BA hlaviček . . . . . . . Konfigurace autentizace pomocí formulářů . . . . . . . Aktivace autentizace pomocí formulářů . . . . . . . Konfigurace mechanismu pro autentizaci pomocí formulářů . Přizpůsobení HTML formulářů s odpovědí . . . . . . Přizpůsobení URI přihlášení pomocí formulářů . . . . . Vytvoření BA hlavičky . . . . . . . . . . . . Uvedení UTF-8 zakódování BA hlaviček . . . . . . . Konfigurace autentizace pomocí certifikátů . . . . . . . Vzájemná autentizace pomocí certifikátů . . . . . . . Aktivace autentizace pomocí certifikátů . . . . . . . Konfigurace mechanismu pro autentizaci pomocí certifikátů . Konfigurace autentizace pomocí tokenů . . . . . . . . Autentizace SecurID pomocí tokenu . . . . . . . . Aktivace autentizace pomocí tokenů . . . . . . . . Konfigurace mechanismu pro autentizaci pomocí tokenů . . Přizpůsobení stránek s odpovědí pro tokeny . . . . . .
iv
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39 41 41 42 44 48 49 50 52 52 53 54 54 55 55 55 56 56 57 57 57 58 59 59 59 59 61 61 61 62 62 63 63 63 64 64 64 65 65 65 67 68 68
Konfigurace autentizace pomocí SPNEGO . . . . . . . . . . . . . . Podpora platformy a registru uživatelů . . . . . . . . . . . . . . . Přechod konfigurace SPNEGO z verze 4.1 na 5.1 . . . . . . . . . . . Omezení . . . . . . . . . . . . . . . . . . . . . . . Konfigurace jednotného přihlášení k pracovní ploše Windows . . . . . . . . Rady pro odstraňování problémů . . . . . . . . . . . . . . . . Konfigurace autentizace pomocí NTLM0 (pouze pro platformy IIS) . . . . . . . Konfigurace autentizace pomocí webového serveru (pouze pro platformy IIS) . . . . Konfigurace autentizace po přepnutí při selhání . . . . . . . . . . . . . Koncepty autentizace po přepnutí při selhání . . . . . . . . . . . . . Konfigurace autentizace po přepnutí při selhání . . . . . . . . . . . . Konfigurace autentizace pomocí IV hlaviček . . . . . . . . . . . . . . Aktivace autentizace pomocí IV hlaviček . . . . . . . . . . . . . . Konfigurace parametrů IV hlaviček. . . . . . . . . . . . . . . . Uveďte UTF-8 zakódování IV hlaviček . . . . . . . . . . . . . . Konfigurace mechanismu pro autentizaci pomocí IV hlaviček pro iv-remote-address . Konfigurace autentizace pomocí HTTP hlaviček . . . . . . . . . . . . . Aktivace autentizace pomocí HTTP hlaviček . . . . . . . . . . . . . Určení typů hlaviček . . . . . . . . . . . . . . . . . . . . Konfigurace mechanismu pro autentizaci pomocí HTTP hlaviček . . . . . . . Konfigurace autentizace pomocí IP adresy . . . . . . . . . . . . . . Aktivace autentizace pomocí IP adresy . . . . . . . . . . . . . . Konfigurace mechanismu pro autentizaci pomocí IP adresy . . . . . . . . Konfigurace autentizace pomocí LTPA cookies . . . . . . . . . . . . . Aktivace autentizace pomocí LTPA cookies . . . . . . . . . . . . . Nastavení podrobných informací o klíči . . . . . . . . . . . . . . Konfigurace zpracování následujícího po autorizaci pomocí LTPA cookies . . . . Konfigurace přesměrování uživatelů po přihlášení . . . . . . . . . . . . Aktivace přesměrování uživatele . . . . . . . . . . . . . . . . Konfigurace parametrů přesměrování uživatele . . . . . . . . . . . . Přidání rozšířených atributů pro pověření . . . . . . . . . . . . . . . Mechanismy pro přidání rozšířených atributů do pověření . . . . . . . . . Konfigurace služby pojmenování . . . . . . . . . . . . . . . . Přidání rozšířených atributů LDAP do HTTP hlavičky (hodnota příznaku) . . . . . Aktivace zpracování pomocí hodnoty příznaku . . . . . . . . . . . . Konfigurace parametrů hodnoty příznaku . . . . . . . . . . . . . Podpora MPA (Multiplexing Proxy Agents) . . . . . . . . . . . . . . Platné typy dat relací a metody autentizace . . . . . . . . . . . . . Průběh procesu autentizace pro MPA a několik klientů . . . . . . . . . Aktivace autentizace MPA . . . . . . . . . . . . . . . . . . Vytvoření účtu uživatele pro MPA . . . . . . . . . . . . . . . Přidání účtu MPA do skupiny pdwebpi-mpa-servers . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 69 . 69 . 69 . 70 . 70 . 74 . 76 . 77 . 78 . 78 . 84 . 92 . 93 . 94 . 94 . 94 . 95 . 95 . 95 . 96 . 96 . 96 . 97 . 97 . 97 . 97 . 98 . 98 . 98 . 99 . 99 . 99 . 100 . 102 . 102 . 103 . 103 . 103 . 105 . 105 . 106 . 106
Kapitola 4. Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Politiky ACL (Access Control List) specifické pro plug-in program . . . . /PDWebPI/hostitel nebo virtuální-hostitel . . . . . . . . . . Oprávnění ACL plug-in programu. . . . . . . . . . . . . Předvolená politika ACL pro /PDWebPI . . . . . . . . . . . Politika pro přihlášení ″třikrát a dost″ . . . . . . . . . . . . . Politika odolnosti hesla . . . . . . . . . . . . . . . . . Nastavení politiky odolnosti hesla pomocí obslužného programu pdadmin . Nastavení pro určitého uživatele a globální nastavení . . . . . . . Politika POP odolnosti autentizace (zvýšená) . . . . . . . . . . Konfigurace úrovní pro zvýšenou autentizaci . . . . . . . . . Aktivace zvýšené autentizace . . . . . . . . . . . . . . Poznámky a omezení zvýšené autentizace . . . . . . . . . . Vícefaktorová autentizace . . . . . . . . . . . . . . . . Aktivace vícefaktorové autentizace . . . . . . . . . . . . Opětovná autentizace pomocí politiky chráněného objektu . . . . . . Podmínky ovlivňující opětovnou autentizaci pomocí POP. . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
107 108 109 109 110 111 111 113 113 114 114 116 116 117 117 117
Obsah
v
Vytvoření a použití opětovné autentizace pomocí POP . . Autentizace pomocí POP založená na síti . . . . . . . Určení IP adres a rozsahů . . . . . . . . . . . Zablokování zvýšené autentizace pomocí IP adresy . . . Algoritmus autentizace založené na síti . . . . . . . Úroveň zabezpečení politiky chráněného objektu . . . . . Zacházení s neautentizovanými uživateli (HTTP/HTTPS) . . . Zpracování požadavku od anonymního klienta . . . . . Přinucení uživatele, aby se přihlásil . . . . . . . . Použití neautentizovaného HTTPS . . . . . . . . Řízení neautentizovaných uživatelů pomocí politik ACL/POP
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
118 118 118 119 120 120 120 120 121 121 121
Kapitola 5. Řešení jednotného přihlášení pro web . . . . . . . . . . . . . . . . . 123 Koncepty jednotného přihlášení . . . . . . . . . . . . . . . . . Automatické přihlášení do zabezpečené aplikace . . . . . . . . . . . . Konfigurace jednotného přihlášení do zabezpečených aplikací pomocí HTTP hlaviček Jednotné přihlášení do WebSphere Application server pomocí LTPA cookies . . . Jednotné přihlášení do plug-in programu z WebSEAL nebo jiné proxy . . . . . . Aktivace a zablokování autentizace pomocí IV hlaviček . . . . . . . . . Konfigurace parametrů IV hlaviček . . . . . . . . . . . . . . . Použití failover cookie pro jednotné přihlášení . . . . . . . . . . . . . Aktivace jednotného přihlášení pomocí failover cookies . . . . . . . . . Používání globálního jednotného přihlášení (GSO - Global single sign-on) . . . . Konfigurace GSO (Global single sign-on) . . . . . . . . . . . . . Jednotné přihlášení pomocí SPNEGO (Security Provider NEGOtiation) . . . . . Jednotné přihlášení pomocí formulářů . . . . . . . . . . . . . . . Průběh procesu jednotného přihlášení pomocí formulářů . . . . . . . . . Požadavky pro podporu aplikace . . . . . . . . . . . . . . . . Aktivace jednotného přihlášení pomocí formulářů . . . . . . . . . . . Konfigurace jednotného přihlášení pomocí formulářů . . . . . . . . . . Příklad konfiguračního souboru pro IBM HelpNow . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
123 124 124 125 126 127 127 127 128 128 130 131 131 131 133 133 134 137
Kapitola 6. Řešení přihlášení napříč doménou . . . . . . . . . . . . . . . . . . 139 Cross domain single sign-on (služba CDSSO) . . . . . . . Průběh procesu autentizace pro CDSSO . . . . . . . . Aktivace a zablokování autentizace pomocí CDSSO . . . . Zašifrování dat tokenu autentizace . . . . . . . . . Konfigurace časového označení tokenu . . . . . . . . Zahrnutí atributů pověření v tokenech autentizace . . . . . Uvedení knihoven sso-create a sso-consume . . . . . . . Vysvětlení odkazů CDSSO . . . . . . . . . . . . Ochrana tokenu autentizace . . . . . . . . . . . Jednotné přihlášení pomocí e-Community . . . . . . . . Funkce a požadavky jednotného přihlášení pomocí e-Community Průběh procesu jednotného přihlášení pomocí e-community . . Cookie e-community . . . . . . . . . . . . . ″Vouch-for″ požadavek a odpověď . . . . . . . . . ″Vouch-for″ token . . . . . . . . . . . . . . Zašifrování ″vouch-for″ tokenu . . . . . . . . . . Konfigurace e-community . . . . . . . . . . . . Konfigurace jednotného přihlášení pomocí e-community - příklad
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
139 139 141 141 142 142 143 143 144 144 145 145 147 147 148 148 149 153
Kapitola 7. Integrace aplikace . . . . . . . . . . . . . . . . . . . . . . . . . 157 Udržování stavu relace mezi klientem a aplikacemi back-end. Aktivace správy ID relace uživatele . . . . . . . Vkládání dat pověření do hlavičky HTTP . . . . . Ukončení relací uživatele . . . . . . . . . . Poskytnutí řízení přístupu k dynamickým URL . . . . . Konfigurace dynamických URL . . . . . . . .
vi
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
157 157 158 159 159 160
Kapitola 8. Vyvolání ADI (authorization decision information retrieval) . . . . . . . . 163 Vyvolání přehledu ADI . . . . . . . . . . . . . . . . Načítání ADI z požadavku plug-in programu . . . . . . . . . Příklad: Načítání ADI z hlavičky požadavku . . . . . . . . Příklad: Načítání ADI z řetězce dotazu požadavku . . . . . . . Příklad: Načítání ADI z těla požadavku POST . . . . . . . . Načítání ADI z pověření uživatele . . . . . . . . . . . . . Dodání důvodu selhání . . . . . . . . . . . . . . . . Konfigurace vyvolání dynamické ADI . . . . . . . . . . . Konfigurace plug-in programu pro použití webové služby AMWebARS
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
163 164 164 165 165 166 166 167 168
Dodatek A. Použití pdbackup k zálohování dat pro plug-in . . . . . . . . . . . . . 169 Funkčnost . . . . . . Zálohování dat pro plug-in Obnova dat pro plug-in . Syntaxe . . . . . . Příklady . . . . . . Příklady pro UNIX . . Příklady pro Windows . Obsah pdinfo-pdwebpi.lst Další data zálohování .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
169 169 170 170 171 171 171 172 172
Dodatek B. pdwebpi.conf reference . . . . . . . . . . . . . . . . . . . . . . . 173 Obecné parametry konfigurace . . . . . . . . . Parametry konfigurace autentizace . . . . . . . Konfigurační parametry relace . . . . . . . . . Konfigurační parametry LDAP . . . . . . . . Konfigurační parametry proxy . . . . . . . . . Konfigurační parametry autorizačního API . . . . . Konfigurační parametry specifické pro daný webový server
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
173 176 186 187 187 188 189
Dodatek C. Stručná reference pro moduly . . . . . . . . . . . . . . . . . . . . 195 Dodatek D. Stručná reference pro příkazy . . . . . . . . . . . . . . . . . . . . 201 pdwebpi_start . . . . pdwebpi . . . . . pdwpi-version . . . pdwpicfg –action config pdwpicfg –action unconfig
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
202 204 205 206 208
Dodatek E. Speciální znaky dovolené v běžných výrazech . . . . . . . . . . . . . 211 Dodatek F. Poznámky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 Ochranné známky
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 214
Slovníček . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Rejstřík . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Obsah
vii
viii
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Obrázky 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Výměna informací mezi plug-in programem a produktem Tivoli Access Manager. . . . . . . . . . . . . . 2 Vývojový diagram, jak plug-in program určuje modul autentizace. . . . . . . . . . . . . . . . . . 47 Vývojový diagram logiky výzvy k autentizaci. . . . . . . . . . . . . . . . . . . . . . . . 48 Vývojový diagram, jak plug-in program určuje modul relace. . . . . . . . . . . . . . . . . . . . 50 Typická architektura serveru pro failover cookies. . . . . . . . . . . . . . . . . . . . . . . 78 Přístup uživatele k zabezpečeným aplikacím pomocí GSO. . . . . . . . . . . . . . . . . . . . 129 Průběh procesu jednotného přihlášení pomocí formulářů. . . . . . . . . . . . . . . . . . . . . 132 Průběh procesu pro CDSSO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Přihlášení se do e-community. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Příklad konfigurace jednotného přihlášení pomocí e-community . . . . . . . . . . . . . . . . . . 153 Průběh procesu ARS (Attribute retrieval service). . . . . . . . . . . . . . . . . . . . . . . 167
© Copyright IBM Corp. 2000, 2003
ix
x
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulky 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38.
Pole certifikátu EPAC produktu Tivoli Access Manager . . . . . . . . . . . . . . . . . . . . . 5 Souhrn sekcí souboru pdwebpi.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Podporované substituce maker . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Konfigurační parametry chybové stránky ve stanze [proxy] . . . . . . . . . . . . . . . . . . . 12 Konfigurační parametry specifické pro webové servery . . . . . . . . . . . . . . . . . . . . . 16 Parametry [p3p-header] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Definice polí autentizačního prověřovacího záznamu. . . . . . . . . . . . . . . . . . . . . . 29 Definice parametrů konfigurace monitorování . . . . . . . . . . . . . . . . . . . . . . . . 30 Jazyky podporované plug-in programem s podporovanými adresáři. . . . . . . . . . . . . . . . . . 36 Lokální zabudované autentizátory . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Parametry externího serveru CDAS . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Ekvivalentní konfigurace SPNEGO mezi verzí 4.1 a 5.1. . . . . . . . . . . . . . . . . . . . . 70 Jména souboru knihovny autentizace po přepnutí při selhání . . . . . . . . . . . . . . . . . . . 86 Popis polí IV hlavičky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Platné typy dat relací pro agenty MPA . . . . . . . . . . . . . . . . . . . . . . . . . 104 Platné typy autentizace agentů MPA . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Oprávnění ACL plug-in programu . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 Oprávnění WebDAV plug-in programu . . . . . . . . . . . . . . . . . . . . . . . . . 109 Příkazy politiky pro přihlášení pdadmin pro LDAP . . . . . . . . . . . . . . . . . . . . . . 111 Příkazy pdadmin odolnosti hesla pro LDAP . . . . . . . . . . . . . . . . . . . . . . . . 112 Příklady hesel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Popisy úrovní POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 Popis polí IV hlavičky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Parametry konfigurace LTPA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Popis polí IV hlavičky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Obecné parametry konfigurace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Konfigurační parametry autentizace . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Konfigurační parametry relace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Konfigurační parametry LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Konfigurační parametry proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Konfigurační parametry autorizačního API . . . . . . . . . . . . . . . . . . . . . . . . 188 Konfigurační parametry specifické pro daný webový server . . . . . . . . . . . . . . . . . . . 189 Reference pro politiky/moduly autentizace plug-in programu . . . . . . . . . . . . . . . . . . . 195 Moduly autentizace specifické pro Windows . . . . . . . . . . . . . . . . . . . . . . . . 197 Reference pro moduly relace plug-in programu . . . . . . . . . . . . . . . . . . . . . . . 197 Modul pro zpracování předcházející autorizaci plug-in programu . . . . . . . . . . . . . . . . . . 198 Reference pro moduly pro zpracování následující po autorizaci plug-in programu . . . . . . . . . . . . . 199 Reference pro modul odpovědi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
© Copyright IBM Corp. 2000, 2003
xi
xii
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Úvod Produkt IBM® Tivoli® Access Manager Plug-in for Web Servers spravuje zabezpečení ochrany dat vašich webových zdrojů tak, že vystupuje jako brána mezi vašimi klienty a bezpečným webovým prostorem. Plug-in program implementuje bezpečnostní politiku, která chrání váš webový prostor objektů. Plug-in program může nabídnout řešení pro jednotné přihlášení, podporovat webové servery vystupující jako virtuální hostitelé a zahrnout zdroje webového aplikačního serveru do své bezpečnostní politiky. Poznámka: Další informace o podporovaných platformách, požadavcích na disk a paměť, předem požadovaných opravách softwaru a instalační instrukce naleznete v knize Tivoli Access Manager for e-business Web Security Installation Guide. IBM® Tivoli® Access Manager (Tivoli Access Manager) je základní software, který je nezbytný, aby bylo možné pracovat s aplikacemi v produktové řadě IBM Tivoli Access Manager. Umožňuje integraci aplikací IBM Tivoli Access Manager, které nabízí širokou paletu řešení autorizace a správy. Jsou-li prodány jako integrované řešení, mohou tyto produkty nabídnout řešení pro správu řízení přístupu, které centralizuje síť a bezpečnostní politiku pro e-business aplikace. Poznámka: IBM Tivoli Access Manager je nové jméno dříve uvolněného softwaru zvaného Tivoli SecureWay® Policy Director. Uživatelům, kteří dobře znali software a dokumentaci produktu Tivoli SecureWay Policy Director, bychom chtěli dát vědět, že termín Management Server (server správy) je nyní nahrazen termínem Policy Server (server politik). Kniha IBM Tivoli Access Manager for e-business Plug-in for Web Servers: Průvodce uživatele obsahuje administrativní procedury a informace o technických odkazech, týkající se zabezpečení vaší webové domény pomocí plug-in programu pro aplikace webových serverů.
Pro koho je určena tato kniha Tento průvodce je určen pro systémové administrátory, odpovědné za instalaci, nasazení a administraci produktu Access Manager Plug-in for Web Servers. Čtenáři této knihy by měli znát: v Operační systémy pro PC a UNIX®. v Architekturu databáze a koncepty. v Správu zabezpečení. v Internetové protokoly, včetně HTTP, HTTPS a TCP/IP. v Lightweight Directory Access Protocol (LDAP) a adresářové služby. v Podporovaný registr uživatelů. v Autentizaci a autorizaci. Pokud používáte komunikaci SSL (Secure Sockets Layer), měli byste také znát protokol SSL, výměnu klíčů (veřejných a soukromých), digitální podpisy, šifrovací algoritmy a vydavatele certifikátů.
© Copyright IBM Corp. 2000, 2003
xiii
Co tato kniha obsahuje Tato kniha obsahuje následující části: v Kapitola 1, “Úvod do produktu IBM Tivoli Access Manager Plug-in for Web Servers” Obsahuje úvod do produktu Access Manager Plug-in for Web Servers, poskytuje podrobnosti o architektuře systému, o funkcionalitě a pracovním prostředí. v Kapitola 2, “Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers” Obsahuje informace o požadavcích konfigurace produktu Access Manager Plug-in for Web Servers. v Kapitola 3, “Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers” Diskuze o tom, jak plug-in obsluhuje proces autentizace a provádí zpracování následující po autorizaci, které je vyžadováno v autorizovaných relacích. v Kapitola 4, “Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers” Informace o konfiguraci a nastavení bezpečnostní politiky produktu Access Manager plug-in for Web Servers. v Kapitola 5, “Řešení jednotného přihlášení pro web” Diskuze o řešeních pro jednotné přihlášení do webového prostoru, chráněného produktem Access Manager Plug-in for Web Servers. v Kapitola 6, “Řešení přihlášení napříč doménou” Diskuze o řešení pro jednotné cross-domain přihlášení produktu Access Manager Plug-in for Web Servers. v Kapitola 7, “Integrace aplikace”, na stránce 157 Diskuze o integraci třístranné aplikace pomocí přídavného rozsahu proměnných prostředí a hlaviček HTTP plug-in programu a schopnosti dynamického URL. v Kapitola 8, “Vyvolání ADI (authorization decision information retrieval)”, na stránce 163 Diskuze o tom, jak plug-in program může poskytnout nebo získat ADI (autorization decision information) požadovanou ke zhodnocení autorizačních pravidel, která chrání zdroje v doméně Tivoli Access Manager. v Dodatek A, “Použití pdbackup k zálohování dat pro plug-in”, na stránce 169 Informace o použití utility pdbackup. v Dodatek B, “pdwebpi.conf reference” Seznam parametrů konfigurace Access Manager Plug-in for Web Servers, včetně odpovídajících popisů. v Dodatek C, “Stručná reference pro moduly” Seznam všech možností plug-in programu pro autentizaci, relace a po-autorizační politiky, včetně odpovídajících popisů. v Dodatek D, “Stručná reference pro příkazy” Seznam dostupných obslužných programů plug-in programu, včetně popisu akcí, které tyto obslužné programy provádějí. v Dodatek E, “Speciální znaky dovolené v běžných výrazech”, na stránce 211 Vypsání speciálních znaků povolených v běžných výrazech použitých v konfiguračním souboru pdwebpi.conf.
xiv
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Publikace Abyste určili, která publikace vám může být užitečná, zobrazte znovu popis Tivoli Access Manager knihovny, předpokládané publikace a související publikace. Až určíte, které publikace potřebujete, odkaz na instrukce pro on-line přístup k publikacím. Další informace o produktu IBM Tivoli Access Manager for e-business můžete nalézt v: http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/ Knihovna produktu Tivoli Access Manager je rozdělena do následujících kategorií: v “Informace o vydání” v “Základní informace” v “Informace o zabezpečení Webu” v “Odkazy pro vývojáře” na stránce xvi v “Technické dodatky” na stránce xvii
Informace o vydání v IBM Tivoli Access Manager for e-business Čtěte jako první (GI11-2930-00) Obsahuje informace pro instalaci a začátek práce s produktem Tivoli Access Manager. v IBM Tivoli Access Manager for e-business Release Notes (GI11-4156-00) Poskytuje nejnovější informace např. o omezeních softwaru, pomocných opravách problémů, nebo o aktualizacích dokumentace.
Základní informace v IBM Tivoli Access Manager Base Installation Guide (SC32-1362-00) Vysvětluje, jak nainstalovat a nakonfigurovat Tivoli Access Manager, základní software, včetně rozhraní Web Portal Manager. Tato publikace je podmnožinou IBM Tivoli Access Manager for e-business Web Security Installation Guide a je určena pro použití s dalšími Tivoli Access Manager produkty, stejně jako IBM Tivoli Access Manager pro Business Integration a IBM Tivoli Access Manager pro operační systémy. v IBM Tivoli Access Manager Base: Administrativní příručka (SC09-3708-00) Popisuje koncepty a procedury používání služeb produktu Tivoli Access Manager. Poskytuje instrukce pro provádění úloh z rozhraní Web Portal Manager a pro provádění úloh pomocí příkazu pdadmin.
Informace o zabezpečení Webu v IBM Tivoli Access Manager for e-business Web Security Installation Guide (SC32-1361-00) Poskytuje instrukce pro instalaci, konfiguraci a odstranění Tivoli Access Manager základního softwaru stejně jako komponent Web Security. Tato publikace je nadsadou IBM Tivoli Access Manager Base Installation Guide. v IBM Tivoli Access Manager Upgrade Guide (SC32-1369-00) Vysvětluje, jak přejít na vyšší verzi z Tivoli SecureWay Policy Director Version 3.8 nebo z předchozích verzí Tivoli Access Manager na Tivoli Access Manager verzi 5.1. v IBM Tivoli Access Manager for e-business WebSEAL: Administrativní příručka (SC09-3709-00) Poskytuje podkladové materiály, administrativní procedury a informace o technických odkazech, které používá server WebSEAL ke správě zdrojů ve vaší zabezpečené webové doméně. Úvod
xv
v IBM Tivoli Access Manager for e-business IBM WebSphere Application Server: Integrační příručka (SC09-3710-00) Poskytuje instrukce pro instalaci, odstranění a administrativu pro integrování Tivoli Access Manager s aplikačním serverem IBM WebSphere®. v IBM Tivoli Access Manager for e-business IBM WebSphere Edge Server Integration Guide (SC32-1367-00) Poskytuje instrukce pro instalaci, odstranění a administrativu pro integrování Tivoli Access Manager s aplikací IBM WebSphere Edge Server. v IBM Tivoli Access Manager for e-business Plug-in for Web Servers: Integrační příručka (SC09-3712-00) Poskytuje instrukce pro instalaci, administrativní procedury a informace o technických odkazech, týkající se zabezpečení vaší webové domény pomocí plug-in pro aplikace webových serverů. v IBM Tivoli Access Manager for e-business BEA WebLogic Server: Integrační příručka (SC09-3711-00) Poskytuje instrukce pro instalaci, odstranění a administrativu pro integrování Tivoli Access Manager s produktem BEA WebLogic Server. v IBM Tivoli Access Manager for e-business IBM Tivoli Identity Manager: Příručka k funkci zajištění rychlého spuštění (SC09-3713-00) Poskytuje přehled úloh souvisejících s integrováním Tivoli Access Manager a s produktem Tivoli Identity Manager a vysvětluje, jak použít a instalovat shromažďování Provisioning Fast Start.
Odkazy pro vývojáře v IBM Tivoli Access Manager for e-business Authorization C API Developer Reference (SC32-1355-00) Obsahuje referenční materiál, který popisuje, jak používat autorizační rozhraní C API produktu Tivoli Access Manager a servisní plug-in rozhraní produktu Access Manager pro přidání zabezpečení produktu Tivoli Access Manager do aplikací. v IBM Tivoli Access Manager for e-business Authorization Java Classes Developer Reference (SC32-1350-00) Poskytuje referenční informace, jak pomocí implementace autorizačního rozhraní API v jazyce Java™ povolit, aby aplikace používala zabezpečení produktu Tivoli Access Manager. v IBM Tivoli Access Manager for e-business Administration C API Developer Reference (SC32-1357-00) Poskytuje referenční informace, jak pomocí administrativního rozhraní API povolit, aby aplikace prováděla administrativní úlohy produktu Tivoli Access Manager. Tento dokument popisuje implementaci tohoto administrativního rozhraní API v jazyce C. v IBM Tivoli Access Manager for e-business Administration Java Classes Developer Reference (SC32-1356-00) Poskytuje referenční informace, jak pomocí implementace administrativního rozhraní API v jazyce Java povolit, aby aplikace prováděla administrativní úlohy produktu Tivoli Access Manager. v IBM Tivoli Access Manager for e-business Web Security Developer Reference (SC32-1358-00) Poskytuje informace o administrativě a programování CDAS (cross-domain authentication service), CDMF (cross-domain mapping framework) a modulu Odolnosti hesla.
xvi
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Technické dodatky v IBM Tivoli Access Manager for e-business Command Reference (SC32-1354-00) Poskytuje informace o obslužných programech příkazového řádku a skriptech, které jsou součástí produktu Tivoli Access Manager. v IBM Tivoli Access Manager Error Message Reference (SC32-1353-00) Obsahuje vysvětlení a doporučované akce pro zprávy, které vydává produkt Tivoli Access Manager. v IBM Tivoli Access Manager for e-business Problem Determination Guide (SC32-1352-00) Obsahuje informace napomáhající určení problému pro produkt Tivoli Access Manager. v IBM Tivoli Access Manager for e-business Performance Tuning Guide (SC32-1351-00) Poskytuje informace o ladění výkonnosti pro prostředí obsahující produkt Tivoli Access Manager, ve kterém je IBM Directory Server nadefinován jako registr uživatelů.
Související publikace Tato část obsahuje seznam publikací, souvisejících s knihovnou produktu Tivoli Access Manager. Tivoli Software Library obsahuje celou řadu publikací týkajících se produktů Tivoli, jako např. dokumenty typu white paper, základní informace o produktech, demonstrační materiály, tzv. redbooky a informace o ohlášení. Tivoli Software Library je k dispozici na této webové adrese: http://www.ibm.com/software/tivoli/library/ Obsahem Tivoli Software Glossary jsou definice mnoha technických termínů, vztahujících se k softwaru Tivoli. Tivoli Software Glossary je k dispozici pouze v anglickém jazyce na odkazu Glossary v levé části webové stránky Tivoli Software Library http://www.ibm.com/software/tivoli/library/
IBM Global Security Kit Produkt Tivoli Access Manager umožňuje šifrování dat pomocí produktu IBM Global Security Kit (GSKit) veze 7.0. Produkt GSKit je zahrnut na IBM Tivoli Access Manager základním CD-ROM pro vaši partikulární platformu, stejně jako na CD-ROM IBM Tivoli Access Manager Web Security, IBM Tivoli Access Manager Web Administration Interfaces a IBM Tivoli Access Manager Directory Server. Sada programů GSKit instaluje obslužný program pro správu klíčů iKeyman gsk7ikm, který vám dovolí vytvořit databáze klíčů, páry klíčů veřejný-soukromý a žádosti o certifikát. Následující dokument je k dispozici na webovém serveru Tivoli Information Center, a to ve stejné části jako dokumentace produktu IBM Tivoli Access Manager: v IBM Global Security Kit Secure Sockets Layer and iKeyman User’s Guide (SC32-1363-00) Obsahuje informace pro síťové nebo systémové administrátory, kteří chtějí aktivovat SSL komunikaci v prostředí produktu Tivoli Access Manager.
IBM Tivoli Directory Server Produkt IBM Tivoli Directory Server, verze 5.2, je na obsažen CD-ROM IBM Tivoli Access Manager Directory Server pro požadovaný operační systém. Poznámka: Produkt IBM Tivoli Directory Server je nové jméno pro dříve vydaný software známý jako: v IBM Directory Server (verze 4.1 a 5.1) v IBM SecureWay Directory Server (verze 3.2.2)
Úvod
xvii
Produkty IBM Directory Server verze 4.1, IBM Directory Server verze 5.1, a IBM Tivoli Directory Server verze 5.2 jsou všechny podporovány produktem IBM Tivoli Access Manager verze 5.1. Další informace o produktu IBM Tivoli Directory Server můžete nalézt v: http://www.ibm.com/software/network/directory/library/
IBM DB2 Universal Database Produkt IBM DB2® Universal Database™ Enterprise Server Edition, verze 8.1 je poskytnut na CD-ROM IBM Tivoli Access Manager Directory Server a je instalován se softwarem pro IBM Tivoli Directory Server. Produkt DB2 je požadován při použití produktu IBM Tivoli Directory Server, z/OS™, nebo OS/390® serverů LDAP jako registr uživatelů produktu Tivoli Access Manager. Další informace o produktu DB2 můžete nalézt v: http://www.ibm.com/software/data/db2/
IBM WebSphere Application Server IBM WebSphere Application Server, Advanced Single Server Edition 5.0, je součástí CD-ROM IBM Tivoli Access Manager Web Administration Interfaces pro požadovaný operační systém.WebSphere Application Server umožňuje jak podporu Web Portal Manager rozhraní, které se používá ke správě Tivoli Access Manager, tak podporu produktu Web Administration Tool, který se používá ke správě IBM Tivoli Directory Server. Produkt IBM WebSphere Application Server Fix Pack 2 je také vyžadován Tivoli Access Manager a je poskytnut na CD-ROM IBM Tivoli Access Manager WebSphere Fix Pack. Další informace o produktu IBM WebSphere Application Server můžete nalézt v: http://www.ibm.com/software/webservers/appserv/infocenter.html
IBM Tivoli Access Manager for Business Integration Produkt IBM Tivoli Access Manager for Business Integration je k dispozici jako samostatně objednatelný produkt. Nabízí řešení zabezpečení pro zprávy z produktů IBM MQSeries® verze 5.2 a IBM WebSphere® MQ for Version 5.3. Produkt IBM Tivoli Access Manager for Business Integration umožňuje, aby aplikace WebSphere MQSeries posílala data diskrétně a neporušeně pomocí klíčů, které jsou přidruženy k odesílacím a přijímajícím aplikacím. Stejně jako produkt WebSEAL a produkt IBM Tivoli Access Manager for Operating Systems, tak i produkt IBM Tivoli Access Manager for Business Integration je jedním ze správců zdrojů, který používá autorizační služby produktu IBM Tivoli Access Manager. Další informace o produktu IBM Tivoli Access Manager for Business Integration můžete nalézt v: http://www.ibm.com/software/tivoli/products/access-mgr-bus-integration/ Níže uvedené dokumenty, které se týkají produktu IBM Tivoli Access Manager for Business Integration verze 5.1, jsou k dispozici na webové stránce Tivoli Information Center: v IBM Tivoli Access Manager for Business Integration Administration Guide (SC23-4831-01) v IBM Tivoli Access Manager for Business Integration Problem Determination Guide (GC23-1328-00) v IBM Tivoli Access Manager for Business Integration Release Notes (GI11-0957-01) v IBM Tivoli Access Manager for Business Integration Read This First (GI11-4202-00)
xviii
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
IBM Tivoli Access Manager for WebSphere Business Integration Brokers Produkt IBM Tivoli Access Manager for WebSphere Business Integration Brokers dostupný jako část produktu IBM Tivoli Access Manager for Business Integration poskytuje řešení zabezpečení produktu WebSphere Business Integration Message Broker, verze 5.0 a produktu WebSphere Business Integration Event Broker, verze 5.0. Produkt IBM Tivoli Access Manager for WebSphere Business Integration Brokers funguje ve spojení s produktem Tivoli Access Manager pro zabezpečení JMS publikačních/podpisových aplikací pomocí poskytnutí hesla a autentizace na základě pověřovacích listů, centrálně definované autorizace a monitorovacích služeb. Další informace o produktu IBM Tivoli Access Manager for WebSphere Integration Brokers můžete nalézt v: http://www.ibm.com/software/tivoli/products/access-mgr-bus-integration/ Níže uvedené dokumenty, které se týkají produktu IBM Tivoli Access Manager for WebSphere Integration Brokers verze 5.1, jsou k dispozici na webové stránce Tivoli Information Center: v IBM Tivoli Access Manager for WebSphere Business Integration Brokers Administration Guide (SC32-1347-00) v IBM Tivoli Access Manager for WebSphere Business Integration Brokers Release Notes (GI11-4154-00) v IBM Tivoli Access Manager for Business Integration Read This First (GI11-4202-00)
IBM Tivoli Access Manager for Operating Systems Produkt IBM Tivoli Access Manager for Operating Systems je k dispozici jako samostatně objednatelný produkt. Pro UNIXové systémy nabízí další úroveň pro vymáhání politiky autorizace k původní úrovni vlastního operačního systému. Produkt IBM Tivoli Access Manager for Operating Systems je stejně jako produkty WebSEAL a IBM Tivoli Access Manager for Business Integration jedním ze správců zdrojů, kteří používají autorizační služby produktu IBM Tivoli Access Manager. Další informace o produktu IBM Tivoli Access Manager for Operating Systems můžete nalézt v: http://www.ibm.com/software/tivoli/products/access-mgr-operating-sys/ Níže uvedené dokumenty, které se týkají produktu IBM Tivoli Access Manager for Operating Systems verze 5.1, jsou k dispozici na webové stránce Tivoli Information Center: v IBM Tivoli Access Manager for Operating Systems Installation Guide (SC23-4829-00) v IBM Tivoli Access Manager for Operating Systems Administration Guide (SC23-4827-00) v IBM Tivoli Access Manager for Operating Systems Problem Determination Guide (SC23-4828-00) v IBM Tivoli Access Manager for Operating Systems Release Notes (GI11-0951-00) v IBM Tivoli Access Manager for Operating Systems Read Me First (GI11-0949-00)
IBM Tivoli Identity Manager Produkt IBM Tivoli Identity Manager Version 4.5 dostupný jako samostatně setřiditelný produkt vám umožňuje centrální správu uživatelů (jako jsou ID uživatelů a hesla) a zajišťování (které poskytuje nebo odvolává přístup k aplikacím, zdrojům nebo operačním systémům). Produkt Tivoli Identity Manager může být integrován s produktem Tivoli Access Manager pomocí produktu Tivoli Access Manager Agent. Abyste získali další informace o použití produktu Agent, kontaktujte zástupce vašeho IBM konta. Úvod
xix
Další informace o produktu IBM Tivoli Identity Manager můžete nalézt v: http://www.ibm.com/software/tivoli/products/identity-mgr/
Online přístup k publikacím Publikace pro tento produkt jsou k dispozici v online verzi ve formátu PDF (Portable Document Format) nebo HTML (Hypertext Markup Language), případně v obou v knihovně Tivoli software library: http://www.ibm.com/software/tivoli/library Chcete-li v knihovně nalézt publikace produktu, klepněte na odkaz Product manuals v levé části stránky library. Pak najděte na stránce Tivoli software information center jméno produktu a klepněte na ně. Publikace produktu obsahují poznámky k jednotlivým vydáním, průvodce instalací, průvodce uživatele, průvodce administrátora a reference pro vývojáře. Poznámka: Pokud chcete vytisknout PDF publikace, zaškrtněte pole Fit to page v dialogu Print produktu Adobe Acrobat (ke kterému se dostanete, pokud klepnete na File → Print).
Dostupnost Funkce dostupnosti pomáhají uživateli, který má tělesné postižení, jako např. sníženou pohyblivost nebo omezené viděni, úspěšně používat softwarové produkty. Pomocí těchto produktů můžete používat asistenční technologie, prostřednictvím kterých můžete poslouchat a navigovat rozhraní. Můžete také používat klávesnici místo myši pro obsluhu všech funkcí grafického uživatelského rozhraní.
Kontakt na softwarovou podporu Než se obrátíte na Softwarovou podporu IBM Tivoli se svým problémem, podívejte se klepnutím na Tivoli support na stránku podpory softwaru IBM Tivoli na této webové adrese: http://www.ibm.com/software/support/ Pokud budete potřebovat další pomoc, obraťte se na softwarovou podporu způsobem, který je popsán v příručce IBM Software Support Guide na této webové adrese: http://techsupport.services.ibm.com/guides/handbook.html Průvodce poskytuje následující informace: v požadavky na registraci a způsobilost pro obdržení podpory v telefonní čísla v závislosti na zemi, ve které pracujete v jaké informace je nutné shromáždit, než se obrátíte na Zákaznickou podporu
Konvence používané v této knize Tato příručka používá několik grafických konvencí pro speciální termíny a akce, a příkazy a cesty závislé na operačním systému.
Konvence typu písma V této knize jsou použity tyto konvence typu písma:
xx
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
tučné písmo Příkazy uvedené malými písmeny nebo smíšeně malými i velkými písmeny, které je těžké odlišit od okolního textu, klíčová slova, parametry, volby a jména tříd Javy a objekty jsou uvedeny tučným písmem. kurzíva Proměnné, názvy publikací a speciální slova nebo fráze, které je nutné zdůraznit, jsou vyznačeny kurzívou. monospace Příklady kódů, příkazové řádky, výstupy na obrazovku, jména souborů a adresářů, která je těžké odlišit od okolního textu, systémové zprávy, text, který musí uživatel správně zadat, a hodnoty argumentů nebo voleb příkazů jsou vyznačeny pomocí monospace.
Rozdíly v operačních systémech Tato kniha používá konvence operačního systému UNIX ve specifikacích proměnných prostředí a v zápisu adresářů. Pokud používáte příkazový řádek operačního systému Windows, nahraďte $proměnná za %proměnná% v proměnných prostředích a nahraďte každé lomítko (/) lomítkem zpětným (\) v cestách k adresářům.Pokud používáte nadstavbu bash v operačním systému Windows, můžete používat konvence operačního systému UNIX.
Úvod
xxi
xxii
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Kapitola 1. Úvod do produktu IBM Tivoli Access Manager Plug-in for Web Servers Produkt IBM Tivoli Access Manager (Tivoli Access Manager) Plug-in for Web Servers je integrační řešení, které ulehčuje implementaci a správu bezpečnostní politiky vašeho chráněného webového prostoru. Je-li nainstalován jako součást stejného procesu jako váš webový server, vystupuje plug-in program jako bezpečnostní brána mezi vašimi klienty a vaším chráněným webovým prostorem. Tato úvodní kapitola obsahuje přehled technologie produktu Tivoli Access Manager Plug-in for Web Servers, uvádí technické požadavky produktu a nabízí úvod do procesů zajišťujících zabezpečení vašeho webového prostoru pomocí plug-in programu. Poznámka: Další informace o podporavaných platformách, požadavcích na disk a paměť, předem požadovaných opravách softwaru a instalační instrukce naleznete v publikaci Tivoli Access Manager for e-business Web Security Installation Guide.Podrobné informace o tom, jak přejít na vyšší verzi produktu Tivoli Access Manager Plug-in for Web Servers (tj. na verzi 5.1), naleznete v publikaci IBM Tivoli Access Manager Upgrade Guide. Tato úvodní kapitola obsahuje následující témata: v “Technologie produktu Tivoli Access Manager Plug-in for Web Servers” v “Ochrana vašeho webového prostoru pomocí produktu Tivoli Access Manager Plug-in for Web Servers” na stránce 3 v “Autentizace produktu Tivoli Access Manager Plug-in for Web Servers” na stránce 4 v “Získání pověření” na stránce 4
Technologie produktu Tivoli Access Manager Plug-in for Web Servers Produkt Tivoli Access Manager Plug-in for Web Servers může být zaintegrován do aplikací produktu Tivoli Access Manager, aby bylo poskytováno úplné řešení zabezpečení ochrany dat vašich webových zdrojů. Plug-in program je součástí stejného procesu jako váš webový server, zachycuje každý požadavek, který dorazí, určí, zda bude nutné vyžadovat rozhodnutí o autorizaci, a také poskytuje prostředky pro autentizaci uživatele (je-li nezbytná). Plug-in program může nabídnout řešení pro jednotné přihlášení a zahrnout zdroje webových aplikací do své bezpečnostní politiky.
Základní provozní komponenty a architektura Produkt Tivoli Access Manager Plug-in for Web Servers se skládá ze dvou základních komponent architektury – komponenty vlastního plug-in programu a komponenty autorizačního serveru. Komponenta vlastního plug-in programu pracuje s vlákny webového serveru, a odesílá na autorizační server podrobnosti o každém požadavku přes rozhraní IPC (Inter-Process Communication). Autorizační server zpracovává autentizaci a autorizaci příchozích požadavků. Autorizační server je aplikace AZNAPI v lokálním režimu, která přijímá a zpracovává požadavky z plug-in komponenty a odpovídá tak, že sdělí plug-in komponentě, jak obsloužit každý požadavek.
© Copyright IBM Corp. 2000, 2003
1
Obrázek 1. Výměna informací mezi plug-in programem a produktem Tivoli Access Manager.
Autorizační server určuje, kterému z virtuálních hostitelů je adresován požadavek (pokud na webovém serveru existují virtuální hostitelé), a určuje, zda daný požadavek vyžaduje autorizaci. Požadavky, které nevyžadují autorizaci, jsou rovnou předány webovému serveru ke zpracování. Požadavky, které vyžadují autorizaci, jsou zpracovány následujícím způsobem autorizačním serverem: 1. 2. 3. 4.
Z požadavku, který byl již autentizován, jsou vyjmuty informace o relaci a autentizaci. Je-li to třeba, je zahájena autentizační výměna informací s uživatelem. Je vytvořeno pověření produktu Tivoli Access Manager. Provede se určení zdrojů, ke kterým může uživatel přistupovat, a tyto zdroje jsou namapovány na odpovídající jméno chráněného objektu produktu Tivoli Access Manager. Jméno chráněného objektu představuje elektronickou jednotku, jako např. zabezpečenou část webového serveru nebo aplikaci, ke kterým mají povolen přístup pouze určití uživatelé. 5. Určí se, zda požadavek nebo odpověď vyžadují úpravu. 6. Jsou vygenerovány odpovědi vyžadované plug-in programem nebo hostitelským webovým serverem tak, že k požadavku nebo odpovědi jsou připojeny cookies nebo hlavičky, nebo je vygenerována samostatná odpověď (např. odpověď o provedené autentizaci nebo odpověď, že uživatel není autorizován).
Podpora virtuálních hostitelů Virtuální hostitelství je schopnost webových serverů, která jim umožňuje, aby se objevily na internetu jako více než jeden hostitel. Všechny webové servery, podporované produktem Tivoli Access Manager Plug-in for Web Servers, nabízí schopnost virtuálního hostitelství.
2
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Produkt Tivoli Access Manager Plug-in for Web Servers nabízí možnost implementace bezpečnostní politiky na bázi jednotlivých virtuálních hostitelů. Nastavení aplikace nutné pro implementaci této schopnosti je obsaženo v dalších částech tohoto dokumentu.
Ochrana vašeho webového prostoru pomocí produktu Tivoli Access Manager Plug-in for Web Servers Produkt Tivoli Access Manager Plug-in for Web Servers obsahuje následující funkce: v Podporuje více politik autentizace, včetně Základní autentizace, autentizace pomocí IP adresy, tokenu, certifikátů, formulářů, atd. v Přijímá požadavky HTTP a HTTPS. v Chrání zdroje webového serveru pomocí autentizace a autorizace požadavků uživatele v závislosti na politice organizace. v Podporuje autentizaci a autorizaci požadavků v prostředí virtuálního hostitele. v Spravuje řízení přístupu do prostoru webového serveru. Podporované zdroje zahrnují URL, regulérní výrazy založené na URL, CGI programy, HTML soubory, Java servlety a soubory třídy Javy. v Ukládá do paměti cache informace o relaci a o pověření, aby eliminoval opakující se dotazy na databázi registru uživatelů během kontroly autorizace. v Nabízí schopnosti jednotného přihlášení. Firemní bezpečnostní politika určuje webové zdroje, které vyžadují ochranu, a úroveň zabezpečení ochrany dat pro každý z těchto webových zdrojů. Produkt Tivoli Access Manager používá virtuální znázornění těchto webových zdrojů, které se nazývá prostor chráněných objektů. Prostor chráněných objektů obsahuje objekty, které představují skutečné fyzické prostředky ve vaší síti. Bezpečnostní politiku naimplementujete pomocí odpovídajících zabezpečovacích mechanismů, které aplikujete na objekty vyžadující ochranu. Zabezpečovací mechanismy zahrnují: v politiky ACL (Access control list) Politiky ACL určují typy uživatelů, které mohou uvažovat o přístupu, a udávají operace, které je dovoleno provádět na objektu pro každý typ uživatele. v POP (Protected object policies - politiky chráněného objektu) POP určuje další podmínky regulující přístup ke chráněnému objektu, jako je např. utajení, integrita, monitorování a denní doba přístupu. v autorizační pravidla Autorizační pravidla jsou podmínky obsažené v autorizační metodě, které se používají k vynucení rozhodnutí o přístupu na základě atributů, jako je stav, aplikace a kontext prostředí. v rozšířené atributy Rozšířené atributy jsou další hodnoty, které jsou umístěny na objektu, ACL nebo POP, a které ovlivňují rozhodnutí o autorizaci. Autorizační server je tou komponentou produktu Tivoli Access Manager Plug-in for Web Servers, která povoluje nebo zamítá přístup ke chráněným zdrojům na základě pověření uživatele a řízení přístupu umístěných na objektu. Pokud chcete úspěšně naimplementovat bezpečnostní politiku, musíte logicky zorganizovat různé typy obsahu a aplikovat odpovídající politiky ACL a POP. Správa řízení přístupu může být komplexní a je možné ji vytvořit snadněji, pokud provedete důkladnou kategorizaci typů obsahu. Vyčerpávající informace o produktu Tivoli Access Manager, včetně podrobných informací o nastavení bezpečnostní politiky, najdete v knize IBM Tivoli Access Manager Base: Administrativní příručka. Kapitola 1. Úvod do produktu IBM Tivoli Access Manager Plug-in for Web Servers
3
Autentizace produktu Tivoli Access Manager Plug-in for Web Servers Autentizace je způsob, jak identifikovat jednotlivé procesy nebo jednotky, které se pokouší přihlásit se do zabezpečené domény. Autorizace je způsob, kterým se určuje, zda autentizovaný uživatel má právo provádět operaci s určitým zdrojem. Autentizace zajišťuje, že jedinec je tím, za koho se prohlašuje, ale neříká nic o jeho schopnosti a možnosti provádět operace se zdrojem. Produkt Tivoli Access Manager Plug-in for Web Servers prosazuje vysokou úroveň zabezpečení ochrany dat v zabezpečené doméně, a proto vyžaduje, aby každý klient poskytl důkaz o své totožnosti. Komplexní zabezpečení sítě je možné vytvořit tak, že produkt Tivoli Access Manager Plug-in for Web Servers bude řídit autentizaci a autorizaci klientů. Pro autentizaci produktu Tivoli Access Manager Plug-in for Web Servers platí následující podmínky: v Plug-in program podporuje standardní sadu politik autentizace. Plug-in program můžete přizpůsobit podle svých potřeb, aby podporoval i jiné politiky autentizace. v Proces plug-in programu je nezávislý na metodě autentizace. v Plug-in program vyžaduje pouze totožnost klienta. Z této totožnosti plug-in program získá pověření autentizován (nebo neautentizován), které může použít autorizační server k určení, zda je možné povolit nebo nutné zamítnout přístup ke zdrojům. Pružný přístup k autentizaci dovoluje, aby bezpečnostní politika byla založena na potřebách obchodu a ne na fyzické topologii sítě. Výsledkem procesu autentizace produktu Tivoli Access Manager Plug-in for Web Servers je: 1. výsledkem autentizace klienta je totožnost klienta Autentizace klienta je úspěšná pouze tehdy, má-li uživatel účet definovaný v registru uživatelů produktu Tivoli Access Manager. Jinak je uživatel označen jako neautentizovaný. 2. produkt Tivoli Access Manager Plug-in for Web Servers použije totožnost klienta, aby získal pro tohoto klienta jeho pověření Plug-in program přiřadí totožnost autentizovaného klienta k registrovanému uživateli produktu Tivoli Access Manager. Pak plug-in program získá pověření odpovídajícího uživatele. Tomuto procesu se říká získání pověření. Pověření obsahují jméno uživatele a všechny skupiny, ve kterých je uživatel členem. Tato pověření jsou plug-in programu k dispozici, aby mohl povolit nebo zamítnout přístup k požadovaným objektům v prostoru chráněných objektů produktu Tivoli Access Manager. Pověření může použít libovolná služba produktu Tivoli Access Manager, která vyžaduje informace o klientovi. Pověření dovolují produktu Tivoli Access Manager bezpečně provozovat velké množství služeb, jako např. autorizaci, monitorování a delegaci. Další informace o podpoře určitých politik autentizace najdete v části Kapitola 3, “Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers”, na stránce 39.
Získání pověření Primárním cílem procesu autentizace je získat informace o pověření, které popisují uživatele klienta. Pověření uživatele je klíčovým požadavkem, který musí být splněn, aby se uživatel mohl stát účastníkem zabezpečené domény. Produkt Tivoli Access Manager rozlišuje autentizaci uživatele a získání pověření. Totožnost uživatele je vždy stálá. Avšak pověření — která definují skupiny nebo role, ve kterých
4
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
uživatel může vystupovat — se mění. Kontextově specifická pověření se mohou během času měnit. Pokud je například určitá osoba povýšena, její pověření musí zohlednit úroveň nové odpovědnosti této osoby. Výsledkem procesu autentizace je informace o totožnosti uživatele, specifická pro danou politiku. Tato informace se porovná s informací o účtu uživatele, která je umístěna v registru uživatelů produktu Tivoli Access Manager (standardně LDAP). Produkt Tivoli Access Manager Plug-in for Web Servers namapuje informace o jménu uživatele a skupině na obecné celodoménové znázornění a formát, které jsou známy jako EPAC (Extended Privilege Attribute Certificate). Informace o totožnosti specifická pro danou politiku, jako např. hesla, tokeny a certifikáty, představují vlastnosti fyzické totožnosti uživatele. Tyto informace je možné použít k vytvoření bezpečné relace na serveru. Výsledné pověření, které představuje oprávnění uživatele v zabezpečené doméně, popisuje uživatele v určitém kontextu a je platné pouze po dobu platnosti dané relace. Pověření produktu Tivoli Access Manager obsahují totožnost uživatele a skupiny, jejichž členem je tento uživatel. Pověření může použít libovolná služba produktu Tivoli Access Manager, která vyžaduje informace o klientovi. Komponenta Tivoli Access Manager Authorization Server například používá pověření k tomu, aby určila, zda je uživatel oprávněn provádět určité operace s chráněným zdrojem v zabezpečené doméně. Pověření se také používají v dalších úlohách, jako např. v protokolování a monitorování. Certifikáty EPAC obsahují UUID (Unique Universal Identifiers), která potřebuje produkt Access Manager pro práci s přístupovými seznamy (ACL - access control list). Následující pole certifikátu EPAC využívá produkt Tivoli Access Manager: Tabulka 1. Pole certifikátu EPAC produktu Tivoli Access Manager Atribut
Popis
Secure Domain ID
Identifikátor domovské zabezpečené domény objektu
Principal UUID
UUID objektu
Group UUIDs
UUID (jedné nebo více) skupin, ve kterých je objekt členem
Produkt Tivoli Access Manager Plug-in for Web Servers může být nakonfigurován tak, aby pro uživatele obnovoval informaci pověření, když udržuje svou relaci aktuální. Toto je užitečná funkce v případě, když uživatel požaduje zvláštní přístup k určitým zabezpečeným aplikacím, nebo když chcete omezit přístup uživatele, aniž by se odhlásil ze své aktuální relace. Abyste získali další informace o konfigurování programu plug-in pro obnovení pověření, prohlédněte “Obnovení pověření” na stránce 33.
Kapitola 1. Úvod do produktu IBM Tivoli Access Manager Plug-in for Web Servers
5
6
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers Tato kapitola popisuje obecné administrativní a konfigurační úlohy, které je možné provést pro přizpůsobení produktu IBM Tivoli Access Manager (Access Manager) Plug-in for Web Servers. Témata v této kapitole zahrnují: v “Obecné informace o plug-in programu” v “Konfigurace autorizačního serveru” na stránce 11 v “Konfigurace virtuálních hostitelských serverů” na stránce 13 v “Konfigurace specifická pro webový server” na stránce 15 v “Výpisy objektu pro přizpůsobení” na stránce 18 v “Konfigurace SU (switch user) pro administrátory” na stránce 19 v “Konfigurace přepnutí při selhání pro servery LDAP” na stránce 24 v “Podpora P3P (Platform for Privacy Preferences) hlaviček” na stránce 25 v “Konfigurace monitorování, protokolování, trasování a databáze paměti cache plug-in programu” na stránce 28 v “Konfigurace služby autorizačního rozhraní API” na stránce 33 v “Obnovení pověření” na stránce 33 v “Konfigurace ukládání do paměti cache požadavku HTTP” na stránce 34 v “Podpora jazyků a znakové sady” na stránce 35
Obecné informace o plug-in programu Následující části popisují obecné informace o produktu Tivoli Access Manager Plug-in for Web Servers: v “Kořenový adresář instalace produktu Tivoli Access Manager Plug-in for Web Servers” v “Konfigurační soubor pdwebpi.conf” na stránce 8 v “Konfigurační soubor pdwebpimgr.conf” na stránce 9 v “Spuštění a zastavení procesu produktu Tivoli Access Manager Plug-in for Web Servers” na stránce 9 v “Chybové zprávy HTTP” na stránce 9 v “Podpora maker” na stránce 10 v “Makra související s formáty” na stránce 10
Kořenový adresář instalace produktu Tivoli Access Manager Plug-in for Web Servers Programové soubory produktu Tivoli Access Manager Plug-in for Web Servers jsou nainstalovány do následujícího kořenového adresáře: UNIX: /opt/pdwebpi/
Windows: C:\Program Files\Tivoli\PDWebPI\
© Copyright IBM Corp. 2000, 2003
7
Tuto cestu můžete nakonfigurovat během instalace plug-in programu na operačním systému Windows. Tuto cestu nelze nakonfigurovat pro instalace na operačních systémech UNIX. Tento průvodce používá proměnnou instalační-cesta, která představuje tento kořenový adresář. V instalacích na operačních systémech UNIX obsahuje níže uvedený samostatný adresář soubory, jako např. soubory protokolu a soubory prověřovacích záznamů, jejichž velikost může v čase významně růst: /var/pdwebpi/
Soubory protokolu jsou zapisovány do společného adresáře Tivoli, pokud byl vybrán během konfigurace runtimeproduktu Tivoli Access Manager.
Konfigurační soubor pdwebpi.conf Činnost plug-in programu můžete přizpůsobit tak, že nakonfigurujete parametry v konfiguračním souboru pdwebpi.conf. Soubor je umístěn v následujícím adresáři: UNIX: install_path/etc/
Windows: install_path\etc\
Níže uvedená tabulka třídí stanzy konfiguračního souboru. Tabulka 2. Souhrn sekcí souboru pdwebpi.conf Sekce
Stanzy
OBECNÉ
[module-mgr] [modules] [wpiconfig] [pdweb-plugins] [performance]
AUTENTIZACE
[common-modules] [authentication-levels] [authentication-mechanisms] [user-agent] [acctmgmt] [BA] [failover] [failover-add-attributes] [failover-restore-attributes] [forms] [login-form-1] [ltpa] [tag-value] [token-card] [http-hdr] [iv-headers] [login-redirect] [ntlm] [spnego] [boolean-rules] [switch-user] [dynurl] [cred-refresh] [ext-auth-int] [auth-data] [http-method-perms] [web-server-authn]
SINGLE SIGNON
[fsso] [ecsso] [ecsso-domain-keys] [ecsso-token-attributes] [ecsso-incoming-attributes] [cdsso] [cdsso-domain-keys] [cdsso-token-attributes] [cdsso-incoming-attributes]
VIRTUÁLNÍ HOSTITELÉ
[jméno-virtuálního-hostitele]
RELACE
[sessions] [session-cookie]
LDAP
[ldap]
LOGGING
[web-log]
AUTHORIZATION SERVER
[proxy-if] [proxy]
P3P
[p3p-header]
AUTORIZAČNÍ API
[aznapi-entitlement-services] [aznapi-configuration]
WEB SERVER
[ihs] [iis] [iplanet] [apache]
V části Dodatek B, “pdwebpi.conf reference”, na stránce 173 najdete popis konfigurovatelných parametrů v konfiguračním souboru pdwebpi.conf.
8
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Poznámka: Kdykoliv provedete jakoukoliv změnu v souboru pdwebpi.conf, musíte ručně znovu spustit proces produktu Tivoli Access Manager Plug-in for Web Servers, aby byly nově provedené změny tímto produktem zaznamenány. Informace o tom, jak spustit a zastavit aplikaci najdete v části “Spuštění a zastavení procesu produktu Tivoli Access Manager Plug-in for Web Servers”.
Konfigurační soubor pdwebpimgr.conf Instalace plug-in programu na operačních systémech UNIX obsahují konfigurační soubor pdwebpimgr.conf. Tento konfigurační soubor obsahuje parametry, které jsou nutné pro nastavení automatického opětovného spuštění autorizačního démona, pokud dojde k jeho náhlému zastavení. Soubor je umístěn v adresáři: install_path/etc/
Neexistují žádné důvody, proč byste mohli potřebovat měnit parametry v tomto souboru.
Spuštění a zastavení procesu produktu Tivoli Access Manager Plug-in for Web Servers Pokud chcete spustit a zastavit proces plug-in programu, použijte příkaz pdwebpi_start (v operačních systémech UNIX), nebo použijte Services Control Panel (Ovládací panel Služby) (pro operační systém Windows). UNIX: pdwebpi_start {start|stop|restart|status}
Chcete-li například zastavit plug-in program a pak jej znovu spustit, použijte: # pdwebpi_start restart
Příkaz pdwebpi_start je umístěn v tomto adresáři: install_path/sbin/
Windows: Označte proces plug-in programu v Services Control Panel (Ovládacím panelu Služby) a použijte odpovídající řídicí tlačítka. Poznámka: pdwebpi je proces autorizačního serveru. Na operačních systémech UNIX se proces pdwebpimgrd automaticky znovu spustí autorizační server, pokud tento je náhle zastaven. Na operačních systémech Windows se autorizační server znovu automaticky spustí pomocí služeb operačního systému Windows.
Chybové zprávy HTTP Někdy se produkt Tivoli Access Manager Plug-in for Web Servers pokusí obsloužit požadavek a to se mu nepodaří. Takové selhání může mít mnoho příčin. Dvě nejčastější příčiny selhání jsou: v soubor neexistuje v nastavení oprávnění nedovolí přístup Pokud se vyskytne selhání při obsluze požadavku, plug-in program vrátí webovému serveru chybový kód. Webový server přeloží obdržený chybový kód a zobrazí odpovídající chybovou stránku.
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
9
Přizpůsobení zobrazení chybových zpráv ISS Webový server IIS nabízí možnost přizpůsobit formát a obsah chybových stránek, které se zobrazují klientům. Tato vlastnost je užitečná, když chcete klientům zobrazit podrobnější informace o selhání. Pokud je plug-in program nainstalován spolu se serverem IIS, může uvedenou schopnost přizpůsobení chybových hlášení využívat. V parametru use-error-pages stanzy [iis] konfiguračního souboru pdwebpi.conf můžete nastavit, zda se budou prohlížeči klienta vracet nakonfigurované chybové stránky serveru IIS, nebo standardní chybové stránky. Hodnota yes parametru use-error-pages znamená, že plug-in program bude využívat přizpůsobené chybové stránky serveru IIS. Hodnota no znamená, že se budou zobrazovat standardní chybové stránky pro chyby, na které narazil autorizační Server. Standardně je parametr use-error-pages nastaven na hodnotu no. Poznámka: Následkem nastavení parametru use-error-pages na hodnotu yes, tedy povolení zobrazovat přizpůsobené chybové stránky serveru IIS pro chyby autorizačního serveru, je významné snížení výkonnosti plug-in programu.
Podpora maker Níže uvedená makra je možné používat pro přizpůsobení HTML chybových stránek. Makra dynamicky nahrazují odpovídající informace, které jsou dostupné. Tabulka 3. Podporované substituce maker Makro
Popis
%USERNAME%
Jméno přihlášeného uživatele
%ERROR_CODE%
Číselný chybový kód přidružený k chybě
%ERROR_TEXT%
Chybový text přidružený k chybě
%URL%
URL, které klient požadoval
%HOSTNAME%
Plně kvalifikované jméno hostitele
%HTTP_BASE%
Základní HTTP URL serveru: http://hostitel:tcpport/
%HTTPS_BASE%
Základní HTTPS URL serveru: https://hostitel:sslport/
%HTTP_BODY%
Tělo požadavku, pokud existuje.
%REFERER%
Hodnota hlavičky odkazovače z požadavku, nebo ’Unknown’, pokud neexistuje
%BACK_URL%
Hodnota hlavičky odkazovače z požadavku, nebo ’/’, pokud neexistuje
%BACK_NAME%
Hodnota ’BACK’, pokud požadavek obsahuje hlavičku odkazovače, nebo ’HOME’, pokud ji nemá
%POST_URL%
Konfigurované POST URL pro libovolné podporované formáty produktu Tivoli Access Manager.
%COOKIES%
Libovolné cookies nalezené v požadavku.
Makra související s formáty Produkt Tivoli Access Manager Plug-in for Web Servers poskytuje následující formáty umístěné v adresáři/opt/pdwebpi/nls/html/lang/charset: v switchuser v token v forms login
10
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
v change password Tyto formáty byly konfigurovány pomocí makra %POST_URL%. Makro %POST_URL% umožňuje plug-in programu přeposlat libovolná POST data, která mohla být zahrnuta v původním požadavku. Bez makra %HTTP_BODY% jsou poté, co plug-in program ukončí zpracování formátu, libovolná POST data poskytnutá s původním požadavkem ztracena. Předvolené formáty byly také konfigurovány, aby uchovaly v paměti cache libovolná nezbytná data relace ve formuláři. Tato data relace zahrnují původně požadované URL, odkaz na původně požadované URL a tělo původního požadavku.
Konfigurace autorizačního serveru Většina zpracování autorizací a autentizací je obsluhována autorizačním serverem. Autorizační server poskytuje množinu pracovních vláken, která: v přijímají požadavky od plug-in programu v odesílají výsledky každého požadavku zpět do plug-in programu Plug-in program komunikuje s autorizačním serverem prostřednictvím IPC mechanismu, který je naimplementován tak, aby používal sdílenou paměť. Stanza [proxy-if] v konfiguračním souboru pdwebpi.conf určuje konfigurační parametry, týkající se nastavení komunikace mezi plug-in programem a autorizačním serverem.
Konfigurace pracovních vláken Parametry number-of-workers a worker-size ve stanze [proxy-if] konfiguračního souboru udávají hodnoty, které je možné vyladit tak, aby bylo dosaženo optimální výkonnosti autorizačního serveru plug–in programu. Jak nastavíte tyto hodnoty, závisí na rozsahu a typu provozu ve vaší síti. [proxy-if] number-of-workers = 10 worker-size = 10000 cleanup-interval=300
Parametr number-of-workers určuje počet současných příchozích požadavků, které je možné plug-in programem obsloužit. Požadavky, které dorazí v okamžiku, kdy jsou všechna pracovní vlákna zaneprázdněna, jsou uloženy do vyrovnávací paměti, dokud se neuvolní nějaké pracovní vlákno. Tento parametr jednoduše určuje počet vláken, které jsou dány k dispozici pro obsluhu potenciálně nekonečné pracovní fronty. Tento parametr je možné zvýšit v závislosti na maximálním množství požadavků, které očekáváte, že bude webový server současně přijímat. Na platformách s operačním systémem UNIX může uvedenou hodnotu limitovat nastavení operačního systému. Zvýšením počtu vláken obecně snížíte průměrnou dobu, za kterou je požadavek vyřízen. Avšak zvýšení počtu vláken současně ovlivňuje další faktory, které by mohly mít nepříznivý účinek na výkonnost serveru. Parametr worker-size definuje množství paměti (v bajtech), které je předem alokováno pro každé pracovní vlákno. Parametr cleanup-interval určuje dobu (v minutách) mezi dvěma následnými vyčištěními sdílené paměti autorizačního serveru. Poznámka: Parametry cleanup-interval a worker-size měňte pouze tehdy, pokud potřebujete odstranit problémy s výkonností.
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
11
Nastavení maximální doby trvání relace pro požadavky IPC Parametr max-session-lifetime ve stanze [proxy-if] konfiguračního souboru pdwebpi.conf nastavuje dobu (ve vteřinách), po kterou plug-in program bude čekat na odpověď z autorizačního serveru. Po jejím uplynutí bude relace přerušena. Tento parametr se vztahuje pouze ke krátkodobým ″relacím″, které vznikají mezi plug-in programem a autorizačním serverem pro účely obsloužení požadavku. Pokud se vyskytne podobné překročení časového limitu, klientovi je odeslána chybová stránka. Podobná překročení časového limitu jsou vysoce nepravděpodobná. [proxy-if] max-session-lifetime = 300
Poznámka: Parametr max-session-lifetime neřídí dobu trvání autentizovaných relací. Doba trvání autentizovaných relací je řízena parametrem timeout ve stanze [sessions].
Konfigurace chybových stránek Ve stanze [proxy] konfiguračního souboru pdwebpi.conf jsou umístěny parametry určující HTML stránky, které se zobrazí, vyskytnou-li se chyby v proxy. Parametry, které se nastavují ve stanze [proxy], jsou: error-page, acct-locked-page, retry-limit-reached-page a login-success. Pro tyto parametry existují předvolené soubory. Tyto soubory je možné editovat, nebo můžete uvést nový soubor, který bude odpovídat požadavkům vaší organizace. Tyto parametry shrnuje níže uvedená tabulka. Tabulka 4. Konfigurační parametry chybové stránky ve stanze [proxy] Parametr
Popis
error-page
Cesta ke stránce, která se zobrazí v uživatelově prohlížeči, pokud se objeví neočekávaná chyba serveru.
acct-locked-page
Cesta ke stránce, která se zobrazí v uživatelově prohlížeči, když se uživatel pokusí přistoupit k uzamčenému účtu.
retry-limit-reached-page
Cesta ke stránce, která se zobrazí, pokud bylo dosaženo povoleného maximálního počtu selhání při přihlášení. Maximální počet povolených selhání při přihlášení je nastaven na serveru LDAP - podrobné informace o nastavení této hodnoty najdete v části “Politika pro přihlášení ″třikrát a dost″” na stránce 110.
login-success
Uvádí stránku, která se zobrazí, když plug-in program nemá stránku, na kterou by uživatele přesměroval po úspěšném přihlášení pomocí formulářů nebo tokenů. Tato situace může nastat tehdy, když vytvoříte svůj formulář pro přihlášení, které odešle POST data přihlášení přímo plug-in programu.
Standardně jsou vzorové HTML stránky umístěny v tomto adresáři: install_path/nls/html/lang/charset. Kde: v lang je brán z konfigurace NLS. Pro instalace v jazykovém prostředí americké angličtiny je parametr lang nastaven na hodnotu C. v charset je znaková sada, ve které je stránka zakódována. Předvolená hodnota je utf-8. Podrobné informace o jazykové podpoře plug-in programu najdete v části “Podpora jazyků a znakové sady” na stránce 35.
12
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Konfigurace virtuálních hostitelských serverů Produkt Tivoli Access Manager Plug-in for Web Servers identifikuje virtuální hostitele pomocí libovolného jména, které je nastaveno ve stanze [pdweb-plugins] konfiguračního souboru pdwebpi.conf. Plug-in program může použít zvláštní bezpečnostní politiku v souladu se dvěma charakteristikami požadavku: v ID virtuálního hostitele, kterému byl požadavek adresován v protokol (HTTP nebo HTTPS), kterým byl požadavek doručen ID virtuálního hostitele se odvozuje od informací o konfiguraci hostitelského webového serveru a je specifické pro daný webový server. Určuje se následujícím způsobem: IHS a Apache
Konfigurační algoritmus, který se používá pro vytvoření ID virtuálních hostitelů, je následující: 1. Pokud v bloku
existuje direktiva ServerName, pak se toto jméno použije pro vytvoření prostoru objektů pro každého hostitele v seznamu virtuálních hostitelů. Nebude učiněn žádný pokus přeložit dodané servername na plně kvalifikované hostname. 2. Pokud v bloku VirtualHost není žádná direktiva ServerName a pokud jména hostitelů v seznamu nejsou číselné IP adresy, pak se provede pokus plně kvalifikovat každé jméno a pak vytvořit prostory objektů pro každé jasné jméno hostitele. 3. Pokud v bloku VirtualHost není žádná direktiva ServerName a pokud jména hostitelů v seznamu jsou číselné IP adresy, pak je učiněn pokus přeložit každou IP adresu na plně kvalifikované jméno hostitele. 4. Pokud stále ještě neexistuje jméno hostitele a v globální direktivě ServerName je uvedeno nějaké jméno, použije se toto jméno (bez překládání). 5. Pokud neexistuje žádná globální direktiva ServerName, pak se použije plně kvalifikovaná verze jména hostitele systému.
IIS 5.0 a 6.0
ID odpovídá přesně jménu webového serveru, které je zobrazeno ve snímku správy produktu Internet Information Services. Například předvolený webový server, který se vytvoří během konfigurace IIS, se jmenuje ″Default Web Site″, což bude ID používané produktem Tivoli Access Manager Plug-in for Web Servers.
Sun ONE Web Server (dříve iPlanet)
ID odpovídá přesně jménu virtuálního hostitele, uvedenému během vytváření virtuálního hostitele v grafickém uživatelském rozhraní pro konfiguraci Sun ONE Web Server. Toto jméno je uloženo v prvku souboru server.xml.
Produkt Tivoli Access Manager Plug-in for Web Servers definuje bezpečnostní politiku z hlediska virtuálních hostitelů. Virtuální hostitel produktu Tivoli Access Manager Plug-in for Web Servers se identifikuje pomocí ID virtuálního hostitele, jak je definováno výše, a sady protokolů (http, https, nebo obou), které by měl chránit. Virtuální hostitel definuje sadu a priority autentizačních schémat, schémat pro identifikaci relací a zpracování po autorizaci, které by měly být aplikovány na požadavky přicházející na virtuální hostitele webového serveru prostřednictvím některého z odpovídajících protokolů. Virtuální hostitel také definuje mapování URI na jména v prostoru chráněných objektů produktu Tivoli Access Manager. Virtuální hostitelé produktu Tivoli Access Manager Plug-in for Web Servers jsou nadefinováni ve stanze [pdweb-plugins] konfiguračního souboru. Mohou být nadefinováni buď jako chránění, nebo jako nechránění. Nechráněný virtuální hostitel nebude používat žádnou bezpečnostní politiku produktu Tivoli Access Manager. Pokud bude obdržen požadavek, který neodpovídá žádnému definovanému chráněnému nebo nechráněnému virtuálnímu hostiteli, bude vygenerována varovná zpráva do souboru protokolu autorizačního serveru, která zaznamená ID virtuálního hostitele a protokol požadavku. To ulehčuje diagnostiku konfiguračních problémů. Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
13
Chránění virtuální hostitelé jsou definováni parametrem virtual-host ve stanze [pdweb-plugins]. Nechránění virtuální hostitelé jsou definováni parametrem unprotected-virtual-host ve stanze [pdweb-plugins]. Použité jméno virtuálního hostitele obvykle odpovídá ID virtuálního hostitele, kterému tento virtuální hostitel odpovídá, ale nemusí tak tomu nutně vždy být. Jména virtuálních hostitelů definovaná ve stanze [pdweb-plugins] se používají při definování bezpečnostní politiky zaměřené na virtuální hostitele. Bezpečnostní politika určitého virtuálního hostitele se definuje pomocí konfiguračních parametrů uvedených ve stanze se jménem virtuálního hostitele. Všechny parametry, které mohou být nadefinovány ve stanze virtuálního hostitele, mají odpovídající předvolené hodnoty, takže není nezbytně nutné mít stanzu pro každého virtuálního hostitele. Podobnou stanzu je nutné mít pouze tehdy, liší-li se bezpečnostní politika daného virtuálního hostitele od předvoleného chování. K tomu, aby bylo možné přiřadit příchozí požadavek k virtuálnímu hostiteli, který definuje bezpečnostní politiku, se používají dva atributy. Uvedená bezpečnostní politika by se měla aplikovat na příchozí požadavek. Tyto parametry jsou id a protocols. Parametr id je definován jako ID virtuálního hostitele, kterému tento virtuální hostitel odpovídá. Předvolená hodnota atributu id je vlastní jméno virtuálního hostitele. Parametr protocols definuje sadu protokolů, kterým bude virtuální hostitel odpovídat. Tato hodnota může být http, https, nebo both. Předvolená hodnota je both. Ostatní parametry virtuálního hostitele definují bezpečnostní politiku, která by měla být použita na požadavky přiřazené tomuto virtuálnímu hostiteli. Virtuální hostitelé jsou přidruženi k určité vedlejší větvi prostoru chráněných objektů. URI požadavku je předesláno touto vedlejší větví, aby bylo vytvořeno jméno prostoru chráněných objektů. Toto jméno prostoru chráněných objektů se používá pro rozhodování o autorizaci. Konfigurační parametr branch určuje jméno tohoto prostoru chráněných objektů. [jméno-virtuálního-hostitele] branch = id-virtuálního-hostitele
Pokud hodnota ID virtuálního hostitele nezačíná lomítkem (/), pak je před záznam přidáno /PDWebPI/. Parametr branch je předvoleně nastaven na hodnotu parametru id. Výsledkem je předvolený prefix jména objektu /PDWebPI/id-virtuálního-hostitele. Vysvětlení větví virtuálních hostitelů Během konfigurace plug-in programu se vytvoří prostor objektů s názvem /PDWebPI. V tomto prostoru objektů se vytvoří záznamy pro každého virtuálního hostitele chráněného plug-in programem. Prostor objektů pod objektem virtuálního hostitele je vlastněn autorizačním serverem plug-in programu, který provádí rozhodnutí o autorizaci pro zdroje v prostoru objektů virtuálního hostitele. Standardně má větev prostoru objektů, kterou používá určitý virtuální hostitel, jméno podle ID virtuálního hostitele. Pokud se má používat jiná větev prostoru objektů /PDWebPI, pak musíte tuto skutečnost zadat v příponě větev. Větve mohou být sdíleny několika virtuálními hostiteli. Taková situace může nastat v prostředí, kdy virtuální hostitelé jsou sami sobě aliasy. Poznámka: Když se změní větev, musí být vytvořen objekt s novým jménem. Všechny přístupové seznamy připojené ke staré větvi zůstávají připojeny k nyní již neexistujícím objektům.
14
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Následující příklad ukazuje konfigurační parametry nezbytné pro webový server, který má čtyři virtuální hostitele: v ibm.com v lotus.com-HTTP v lotus.com-HTTPS v domino.com Virtuální hostitelé lotus.com-HTTP a lotus.com-HTTPS jsou ve skutečnosti stejný virtuální hostitel a sdílejí stejnou větev. Jsou však rozlišení podle typu přístupu (HTTP nebo HTTPS). V tomto případě může být konfigurace autentizace nastavena rozdílně v závislosti na typu přístupu. Virtuální hostitel domino.com není chráněn plug-in programem a ibm.com je dalším virtuálním hostitelem na stejném serveru. [pdweb-plugins] virtual-host = ibm.com virtual-host = lotus.com-HTTPS virtual-host = lotus.com-HTTP unprotected-virtual-host = domino.com web-server = iplanet [lotus.com-HTTPS] id = lotus.com protocols = https branch = lotus.com [lotus.com-HTTP] id = lotus.com protocols = http branch = lotus.com [ibm.com] id = ibm.com protocols = http, https branch = ibm.com
Ujistěte se, že jste znovu spustili webový server pokaždé, když jste provedli změny v konfiguraci virtuálních hostitelů v konfiguračním souboru pdwebpi.conf. Je nezbytná další konfigurace, a to pro jednotlivé virtuální hostitele, aby bylo možné nastavit parametry autentizace pro každého jednotlivého virtuálního hostitele. Podrobné informace o konfiguraci metod autentizace virtuálních hostitelů najdete v části “Konfigurace autentizace virtuálních hostitelů” na stránce 42.
Konfigurace specifická pro webový server Některé akce plug-in programu jsou specifické pro daný webový server a proto je nutná určitá konfigurace, která je závislá na typu webového serveru, pro nějž plug-in program provádí zpracování. V parametru web-server stanzy [pdweb-plugins] konfiguračního souboru pdwebpi.conf nadefinujete typ vašeho webového serveru. Platné hodnoty jsou ihs, iplanet, iis, nebo apache. Například: [pdweb-plugins] web-server = ihs
Konfigurační položky specifické pro daný webový server jsou ve stanzách [iis], [ihs], [apache] a [iplanet] konfiguračního souboru pdwebpi.conf. Některé konfigurační parametry webových serverů je možné nastavit na úrovni jednotlivých větví tak, že přidáte úplnou větev virtuálního hostitele do stanzy. Například
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
15
[iplanet:/PDWebPI/lotus.com]. Tímto způsobem je možné nakonfigurovat parametry související s procházením webovým prostorem. Následující tabulka vysvětluje konfigurovatelné parametry pro jednotlivé typy webových serverů. Tabulka 5. Konfigurační parametry specifické pro webové servery Parametr
Popis
query-contents
Určuje program query contents, který se používá pro procházení webovým prostorem IBM HTTP Serveru pomocí příkazu ’pdadmin> object list’. Tento parametr je možné přepsat na úrovni větve uvedením hodnoty pro tento parametr ve stanze [ihs:větev], např. [ihs:/PDWebPI/lotus.com]
[ihs]
query-log-file doc-root
Umístění souboru protokolu pro chyby, na které narazil program query contents. Určuje kořen dokumentace, který poskytuje schopnost procházet webovým prostorem, která je nezbytná pro provádění příkazů ’pdadmin> object list’. Tento parametr je nastaven obslužným programem pro konfiguraci během nastavení virtuálních hostitelů - je definován na úrovni větve politiky ve stanze [ihs:větev], např. [ihs:/PDWebPI/lotus.com]
[apache] query-contents
Určuje program query contents, který se používá pro procházení webovým prostorem Apache HTTP Serveru pomocí příkazu ’pdadmin> object list’. Tento parametr je možné přepsat na úrovni větve uvedením hodnoty pro tento parametr ve stanze [apache:větev], např. [apache:/PDWebPI/lotus.com]
query-log-file
Umístění souboru protokolu pro chyby, na které narazil program query contents.
doc-root
Určuje kořen dokumentace, který poskytuje schopnost procházet webovým prostorem, která je nezbytná pro provádění příkazů ’pdadmin> object list’. Tento parametr je nastaven obslužným programem pro konfiguraci během nastavení virtuálních hostitelů - je definován na úrovni větve politiky ve stanze [apache:větev], např. [apache:/PDWebPI/lotus.com]
[iis] query-contents
query-log-file log-file
16
Určuje program query contents pro procházení webovým prostorem IIS pomocí pdadmin. Tento parametr je možné přepsat na úrovni větve uvedením hodnoty pro tento parametr ve stanze [iis:větev], např. [iis:/PDWebPI/lotus.com] Umístění souboru protokolu pro chyby, na které narazil program query contents. Definuje soubor protokolu pro chybové a trasovací zprávy z IIS plug-in programu, které se ukládají odděleně od souboru protokolu autorizačního serveru, aby byla zajištěna konzistence těchto souborů. Je-li zadán jako relativní cesta, pak je umístění relativní k podadresáři s protokoly instalačního adresáře. Je-li zadán jako absolutní cesta, použije se absolutní cesta.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 5. Konfigurační parametry specifické pro webové servery (pokračování) Parametr
Popis
query-contents
Určuje program query contents pro procházení webovým prostorem Sun ONE (iPlanet) pomocí pdadmin. Tento parametr je možné přepsat na úrovni větve uvedením hodnoty pro tento parametr ve stanze [iplanet:větev], např. [iplanet:/PDWebPI/lotus.com]
[iplanet]
query-log-file doc-root
Umístění souboru protokolu pro chyby, na které narazil program query contents. Určuje kořen dokumentace, který poskytuje schopnost procházet webovým prostorem, která je nezbytná pro provádění příkazů ’pdadmin> object list’. Tento parametr je nastaven obslužným programem pro konfiguraci během nastavení virtuálních hostitelů - je definován na úrovni větve politiky ve stanze [iplanet:větev], např. [iplanet:/PDWebPI/lotus.com]
V níže uvedeném příkladu mají virtuální hostitelé ibm.com a lotus.com odpovídající stanzu v konfiguračním souboru: [iplanet:/PDWebPI/ibm.com] a [iplanet:/PDWebPI/lotus.com], ve které jsou nadefinovány parametry specifické pro danou konfiguraci. [pdweb-plugins] virtual-host = ibm.com virtual-host = lotus.com web-server = iplanet [iplanet] query-contents = /opt/pdweb/bin/wpi_iplanet_ls [iplanet:/PDWebPI/ibm.com] doc-root = /usr/local/ibm.com/doc/root [iplanet:/PDWebPI/lotus.com] doc-root = /usr/local/lotus.com/doc/root
Pokyny pro webový server IIS Když konfigurujete nastavení bezpečnosti serveru IIS v oušku Directory Security (Zabezpečení adresářů) v dialogovém okně Properties (Vlastnosti), je důležité si pamatovat, že některá konfigurovatelná nastavení bezpečnosti je možné v rámci hierarchie webového prostoru dědit. Plug-in program dynamicky vytváří ″virtuální″ objekty webového prostoru, aby obsloužil různé funkce. Nastavení bezpečnosti na těchto objektech jsou často velmi důležitá. Je nezbytné, aby nebyly měněny vlastnosti zabezpečení na těchto objektech. Když změníte nastavení bezpečnosti serveru IIS na oušku Directory Security (Zabezpečení adresářů) v dialogovém okně Properties (Vlastnosti), zobrazí se dialogové okno Inheritance Overrides (Dědičnost přepíše). Dialogové okno Inheritance Overrides (Dědičnost přepíše) zobrazí seznam Child Nodes (Podřízené uzly), které přepíšou hodnotu, kterou jste právě nastavili. Máte možnost zvolit, které uzly by měly používat novou hodnotu. Uzly PDWebPI nesmí být v tomto dialogu nikdy zvoleny.
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
17
Apache a IHS Zablokování Multiviews: Když používáte webové servery Apache nebo IHS, měla by být zablokována direktiva MultiViews na kořenovém adresáři. Povolení direktivy MultiViews vynechává kontrolu autentizace pomocí produktu Tivoli Access Manager Plug-in for Web Servers a tím ohrožuje vynechat webového serveru. Pro Apache je direktiva Multiviews povolena na dokumentovém kořenovém adresáři předvolbou. Konfigurace pro skripty PHP: Produkt Tivoli Access Manager Plug-in for Web Servers pracuje správně pouze, když jsou skripty PHP pro webový server ovládány vnitřně pomocí podpory PHP konfigurované jako implementace modulu.
Výpisy objektu pro přizpůsobení Produkt Tivoli Access Manager Plug-in for Web Servers dodává binární soubor pro každý podporovaný webový server použitý k určení výstupu pro výpis objektu administrativy pdadmin nebo příkaz zobrazení objektu. Následující tabulka indikuje standardní binární jména a jejich umístění: v iPlanet — install_path/bin/wpi_apache_ls v IHS — install_path/bin/wpi_ihs_ls v IIS — install_path/bin/wpi_iis_ls Pokud požadujete schopnosti procházení objektu, které nejsou součástí standardní funkcionality, k přemístění objektů dodaných s plug-in programem budete potřebovat rozvinout váš vlastní přizpůsobený binární objekt. Když vyvíjíte přizpůsobený binární objekt, platí následující pokyny:
Parametry příkazového řádku iPlanet,IHS,Apache directory virtual_host log_file [-d] Kde: directory
Absolutní cesta k adresáři nebo souboru, který se má vypsat nebo zobrazit.
virtual_host
Virtuální hostitel pro adresář nebo soubor.
log_file
Absolutní cesta k adresáři, který bude obsahovat libovolnou chybovou informaci vyprodukovanou akcí.
-d
Když je uvedena volba -d, je místo vypsání objektu provedeno jeho zobrazení.
IIS [-log log_file] -path directory -vhost virtual_host [-d] Kde:
18
log_file
Absolutní cesta k adresáři, který bude obsahovat libovolnou chybovou informaci vyprodukovanou akcí.
directory
Absolutní cesta k adresáři nebo souboru, který se má vypsat nebo zobrazit.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
virtual_host
Virtuální hostitel pro adresář nebo soubor.
-d
Když je uvedena volba -d, je místo vypsání objektu provedeno jeho zobrazení.
Výstup Pro každý vypsaný záznam bude formát výstupu: [name]
Kde: type
Číslo indikující typ objektu. Aktuální hodnoty zahrnují: v 0 Neznámý v 1 Doména v 2 Soubor v 3 Program v 4 Adresář v 5 Spojení v 9 HTTP Server v 10 Neexistující objekt v 11 Zásobník v 12 Konec v 14 Zásobníková aplikace v 15 Koncová aplikace
description
Textový popis objektu.
attachable
Zda lze metodu připojit k objektu.
name
Jméno objektu. Toto jméno objektu by nemělo obsahovat žádná jména vedoucích adresářů.
Například: apache.gif
Konfigurace SU (switch user) pro administrátory Funkcionalita přepnutí uživatele produktu Plug-in for Web Servers dovoluje určitým administrátorům předpokládat totožnost uživatele, který je členem zabezpečené domény produktu Tivoli Access Manager. Implementace přepnutí uživatele je stejná jako příkaz su v prostředích UNIX. V prostředí plug-in programu získává administrátor pravá uživatelova pověření a spolupracuje se zdroji a s aplikacemi back-end se stejnými schopnostmi jako skutečný uživatel. Přepnutí uživatele je pro Help Desk užitečný nástroj k odstraňování a diagnostikování problémů. Přepnutí uživatele lze také použít k otestování přístupu uživatele ke zdrojům a provedení testování integrace aplikace. Následující položky zvýražňují důležité funkce přepnutí uživatele: v Přepnutí uživatele nevyžaduje uživatelovo heslo. v Aministrátor používá pověření reprezentující aktuálního uživatele. v Přepnutí uživatele je vyhrazeno pro členy speciální administrátorské skupiny. Administrátor nemůže přepnout uživatele na jiného člena této skupiny. Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
19
v Produkt Tivoli Access Manager zpracovává sec_master a ostatní vybraní uživatelé mohou být ze schopností přepnutí uživatele vyloučeni pomocí členství ve vyloučené skupině. v Speciální formulář HTML se použije k podpoře informace přepnutí uživatele a aktivaci speciálního mechanismu autentizace, který vrací uvedené pověření uživatele bez požadavku na heslo. v Administrátor používá obslužný program pkmslogout k ukončení relace přepnutí uživatele.
Pochopení toku procesu přepnutí uživatele Následující posloupnost popisuje tok procesu přepnutí uživatele: 1. Proces je spuštěn autentizovaným administrátorem, který je členem skupiny su-admins. 2. Administrátor navazuje spojení s předkonfigurovaným formulářem HTML pro přepnutí uživatele. Tento formulář je přístupný pouze členům skupiny su-admins. Pokud uživatel není členem skupiny su-admins, je vrácena stránka ″Not Found″. 3. Formulář přepnutí uživatele je dokončen a vrácen s následující informací: jméno uživatele (administrátor je ″přepnut″ na tohoto uživatele), URL místa určení a metoda autentizace. Tato akce se projeví v požadavku POST odeslanému do /pkmssu.form. 4. Před poskytnutím oprávnění k přepnutí se provedou dvě kontroly. a. Plug-in program kontroluje, zda je ″switched to″ uživatel členem skupiny su-admins. Uživatel se nemůže ″stát″ jiným uživatelem, který je členem skupiny su-admins. b. Plug-in program kontroluje, zda je ″switched to″ uživatel členem skupiny su-excluded. Žádný uživatel se nemůže ″stát″ členem skupiny su-excluded. Pokud jedna z těchto kontrol selže, je vrácena chyba. Všechny následné požadavky jsou vytvořeny, jako by je vytvořil ″switched to″ uživatel. 5. Administrátor zůstává ″switched to″ uživatelem, dokud není standardní obslužný program /pkmslogout produktu Tivoli Access Manager dotázán, kdy je ″switched to″ uživatel odhlášen a administrátor se vrací ke své původní relaci.
Povolení přepnutí uživatele Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech politik autentizace. K povolení funkcionality přepnutí uživatele musí být modul switch-user konfigurován jako předcházející autorizaci. To umožňuje, aby funkce přepnutí uživatele přistoupila k uživateli před provedením autorizace. [common-modules] ... pre-authzn = switch-user ...
Poznámka: Pokud je modul acctmgmt nakonfigurován jako předcházející autorizaci spolu s modulem switch-user, tak se musí modul switch-user objevit v seznamu před modulem acctmgmt. Zajistěte, že záznam pro přepnutí uživatele existuje ve stanze [modules] konfiguračního souboru pdwebpi.conf. Například: [modules] ... switch-user = pdwpi-su-module ...
Konfigurace formuláře HTML pro přepnutí uživatele Konfigurace formuláře přepnutí uživatele je definována ve stanze [switch-user] konfiguračního souboru pdwebpi.conf.
20
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
v Parametr switch-user-form uvádí jméno souboru. Předvoleně je jméno souboru switchuser.html a nachází se v adresáři install_path/nls/html/lang/charset. Na systémech US English je adresář lang nazýván C a adresář charset je nazýván utf-8. [switch-user] switch-user-form = switchuser.html
v Parametr switch-user-uri obsahuje URI, které se použije k vyvolání funkce přepnutí uživatele. Všimněte si, že standardní politika autorizace není pro toto URI použita. Místo kontroly autorizace ACL je provedena kontrola na základě skupiny. [switch-user] switch-user-uri = /switchuser.html
v Parametr switch-user-post-uri uvádí URI, jehož formulář přepnutí uživatele je zadán: [switch-user] switch-user-post-uri = /pkmssu.form
Formulář přepnutí uživatele může být editován na přizpůsobený vzhled a funkcionalitu. Formulář obsahuje požadavky pro: v Jméno uživatele (administrátor se na tohoto uživatele přepíná) Tento uživatel nemůže být členem su-excluded, bezpečnostní skupiny, nebo su-admins. v URL místa určení Tato stránka se zobrazí po úspěšné operaci přepnutí uživatele. Můžete ji nakonfigurovat jako skrytý vstup obsahující odpovídající domovskou stránku, nebo jako stránku potvrzující úspěšné přepnutí uživatele. v Metoda autentizace Metoda autentizace určuje typ informace použité k vytvoření pověření uživatele. Toto pole můžete nakonfigurovat jako skrytý vstup. Seznam platných parametrů metody autentizace naleznete v níže uvedených poznámkách. v Makro %CUSTOM% je zahrnuto v předvoleném formuláři a může se použít, aby ve formuláři automaticky zahrnulo všechny konfigurované mechanismy autentizace přepnutí uživatele. Poznámky pro formulář přepnutí uživatele: v Formulář je přístupný pouze členům skupiny su-admins. V tomto souboru není vyžadováno ACL. Plug-in program provádí kontrolu členství v interně pevně naprogramované skupině. Pokud kontrola členství ve skupině selže, plug-in program vrací chybu 404 ″Not Found″. v Požadovanými daty je jméno uživatele, URL místa určení a metoda autentizace. v Požadovaná data mohou být do formuláře vytvořena jako skrytá pole. v Plug-in program ověřuje, že se všechna požadovaná data nachází v zadaném formátu. Pokud data chybí, formulář je vrácen administrátorovi s popisnou zprávou. v Platné hodnoty pro metodu autentizace zahrnují: su-password su-token-card su-certificate su-http-request su-cdsso
Tyto parametry metody autentizace uvádí, který mechanismus autentizace používá plug-in program. v Data formuláře přepnutí uživatele jsou podporována pro URL akce /pkmssu.form.
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
21
Povolení nebo vyloučení uživatelů z přepnutí uživatele Pouze administrátoři, kteří jsou členy skupiny su-admins mohou použít funkci přepnutí uživatele a mohou obdržet formulář HTML pro přepnutí uživatele. Funkcionalitu přepnutí uživatele může použít libovolný uživatel, který je členem skupiny su-admins. Administrátoři mohou přepnout uživatele pro účet produktu Tivoli Access Manager, s výjimkou těch, které náleží k určitým skupinám. Ostatní uživatele produktu Tivoli Access Manager můžete vyloučit z přepnutí uživatele pomocí členství ve skupině su-excluded. Navíc členové skupiny securitygroup produktu Tivoli Access Manager jsou vyloučeni z funkcionality přepnutí uživatele. Obecně jsou sec_master a procesy produktu Tivoli Access Manager členy securitygroup. Během přepnutí uživatele provádí plug-in program kontrolu všech těchto skupin. Funkci ″switch to″ nemůžete použít pro někoho kdo je členem skupin su-admins , su-excluded, nebo securitygroup.
Konfigurace mechanismu pro autentizaci přepnutí uživatele Primární odpovědnost mechanismu pro autentizaci přepnutí uživatele je vytvořit pověření reprezentující uživatele ″switched-to″ na základě dodaného jména uživatele a metody autentizace, bez vyžadování hesla jako vstupu. Předvolený mechanismus pro autentizaci CDAS musí mít stejné požadavky. Mechanismus pro autentizaci přepnutí uživatele uvádíte ve stanze [authentication-mechanisms] konfiguračního souboru pdwebpi.conf. Jsou podporovány následující mechanismy pro autentizaci: [authentication-mechanisms ] #su-password = su-password-library #su-token-card = su-token-card-library #su-certificate = su-certificate-library #su-http-request = su-http-request-library #su-cdsso = su-cdsso-library
Produkt Tivoli Access Manager podporuje jednotlivou knihovnu přepnutí uživatele, která se může použít k povolení libovolného výše uvedeného mechanismu pro autentizaci v předvoleném, nepřizpůsobeném prostředí. Knihovna přepnutí uživatele se liší od standardních knihoven autentizace. Knihovna uvádí mechanismus pro autentizaci, který přijímá identitu uživatele (podporovanou ve formuláři přepnutí uživatele) a pro tohoto uživatele vrací platné pověření , aniž by vyžadoval jeho heslo jako vstup. Sdílená knihovna přepnutí uživatele built-in poskytnutá s produktem Tivoli Access Manager se nazývá: UNIX
libsuauthn
Windows suauthn Funkcionalita přepnutí uživatele také podporuje přizpůsobené mechanismy pro autentizaci CDAS. Tato podpora je důležitá, protože přizpůsobený CDAS často podporuje další informace pro pověření uživatele. Jste odpovědní za zapisování přizpůsobeného přepnutí uživatele CDAS, které napodobuje chování existujících CDAS při podporování požadavku navrácení pověření bez vyžadování hesla uživatele pro vstup.
22
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Každá konfigurovaná knihovna autentizace přepnutí uživatele musí být jedinečně pojmenována, stejně tak, když je předvolená knihovna (libsuauthn) použita pro více jak jednu metodu autentizace. Příklad: V následujícím příkladě (pro platformu Solaris) má existující prostředí povoleny tři metody autentizace: 1. Autentizace pomocí formulářů s knihovnou built-in libldapauthn 2. Autentizace pomocí certifikátů s knihovnou built-in libsslauthn 3. Autentizace pomocí tokenu s přizpůsobeným mechanismem CDAS Prostředí je nyní rozšířeno na podporu funkcionality přepnutí uživatele pro libovolnou z těchto tří metod. V konfiguračním souboru pdwebpi.conf musí být povoleny pro přepnutí uživatele další tři parametry autentizace. V dodatku, nová přizpůsobená knihovna CDAS musí být zapsána, aby napodobila CDAS existujícího tokenu a aby podporovala požadavky autentizace přepnutí uživatele: [authentication-mechanisms ] passwd-ldap =/opt/PolicyDirector/lib/libldapauthn.so cert-ssl =/opt/PolicyDirector/lib/libsslauthn.so token-cdas =/opt/PolicyDirector/lib/libcustom.so su-password =/opt/PolicyDirector/lib/libsuformauthn.so su-certificate =/opt/PolicyDirector/lib/libsucert.so su-token-card =/opt/PolicyDirector/lib/libsucustom.so
Ovlivnění funkcionality ostatních plug-in programů Vliv na konfiguraci časového limitu paměti cache relace Funkcionalita nečinnosti paměti cache konfigurované relace plug-in programu a hodnoty časového limitu doby trvání nejsou operací přepnutí uživatele ovlivněny. Časovače nečinnosti a doby trvání jsou přidruženy k záznamu paměti cache administrátora a nejsou daty relace, která se mění během operace přepnutí uživatele. Časovač nečinnosti relace pokračuje k vynulování, když administrátor provádí požadavky jako uživatel ″switched-to″. Když administrátor ukončuje relaci přepnutí uživatele, nečinnost je pro znovu zavedenou relaci administrátora stále platná. Hodnota doby trvání relace není operací přepnutí uživatele přidána. Je možné, že časový limit doby trvání relace administrátora během operace přepnutí uživatele vyprší. Pokud se toto překročení časového limitu vyskytne, jsou relace vymazány a dojde k odhlášení jak administrátora tak uživatele ’switched-to’. Administrátor musí znovu získat autentizaci a musí začít operaci přepnutí uživatele znovu.
Připojení úrovní zvýšené autentizace Specifikace sdílené knihovny může obsahovat další parametry ve formátu: library&arg1 arg2 ... argx
Úrovně zvýšené autentizace můžete označit pomocí volby –l následované číslem úrovně. Například: su-password =/opt/PolicyDirector/lib/libsuformauthn.so&-l 1 su-certificate =/opt/PolicyDirector/lib/libsucert.so&-l 0 su-token-card =/opt/PolicyDirector/lib/libsucustom.so&-l 2
Poznámka: Pro tuto verzi produktu Tivoli Access Manager musí administrátor k úspěšnému provedení zvýšené autentizace znát heslo uživatele.
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
23
Podpora nového získání autentizuace Operace přepnutí uživatele funkcionalitu nového získání autentizace plug-in programu rozeznává. Pokud je nové získání autentizace vyžadováno během operace přepnutí uživatele, administrátor musí provést ověřování identity jako uživatel ″switched-to″. Poznámka: Pro tuto verzi produktu Tivoli Access Manager musí administrátor k úspěšnému novému získání autentizace znát heslo uživatele ″switched-to″.
Podpora správy relace uživatele Operace přepnutí uživatele správu relace uživatele podporuje. Administrátor má jedinečné ID relace uživatele. Během operace přepnutí uživatele existuje pro uživatele ″switched-to″ jedinečné ID relace uživatele.Úloha ukončení jednotlivé relace uživatele a úlohy ukončení všech relací uživatele fungují následovně: v Relace uživatele ″switched-to″ je ukončena, když je zadáno ID relace ″switched-to″ nebo ID relace uživatele v Jak relace administrátora tak relace uživatele ″switched to″ jsou ukončeny, když je zadáno ID relace administrátora nebo ID relace uživatele
Podpora hodnoty příznaku Funkcionalita přepnutí uživatele schopnost hodnoty znaku, která je často používaná CDAS, rozeznává.
Monitorování administrátora během přepnutí uživatele Během operace přepnutí uživatele je možné administrátora monitorovat. Funkcionalita přepnutí uživatele přidává do pověření uživatele ″switch-to″ rozšířený atribut identifikující administrátora. Rozšířený atribut, tak jak je uložen v pověření, se nazývá tag_value_prefix_su-admin: tag_value_prefix_su-admin = su-admin-name
Kde tag_value_prefix_ reprezentuje hodnotu parametru tag_value_prefix konfigurovanou ve stanze [pdwebpi-plugins] konfiguračního souboru plug-in programu. Tento přídavný atribut je dostupný pro libovolný mechanismus monitorování.
Konfigurace přepnutí při selhání pro servery LDAP Produkt Tivoli Access Manager plug-in for Web Servers připojuje každý dostupný server LDAP — hlavní i replikovaný v závislosti na prioritě — když se spouští. Pokud je z nějakého důvodu hlavní server LDAP mimo provoz, plug-in program musí být schopen připojit se k dostupnému replikovanému serveru LDAP, aby mohl provádět libovolnou operaci pro čtení. To je standardní konfigurace repliky LDAP produktu Tivoli Access Manager. Podrobnější informace najdete v knize IBM Tivoli Access Manager Base: Administrativní příručka. IBM Directory (LDAP) podporuje existenci jednoho nebo více replikovaných serverů LDAP s oprávněním pouze pro čtení. Sun ONE (dříve iPlanet) Directory Server (LDAP) podporuje existenci jednoho nebo více replikovaných serverů LDAP s oprávněním pouze pro čtení, které nazývá ″spotřebiteli″ (consumers). Do stanzy [ldap] konfiguračního souboru pdwebpi.conf musíte přidat řádky, které budou označovat všechny replikované servery dostupné plug-in programu. Pro každou z replik použijte uvedenou syntaxi: replica =ldap-server,port,typ,preference
kde:
24
ldap-server
Síťové jméno replikovaného serveru LDAP.
port
Naslouchací port tohoto serveru. Obecně použijte pro nekódované komunikace 389 nebo pro komunikace přes SSL 636.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
typ
Funkcionalita replikovaného serveru - buď read-only (pouze pro čtení), nebo read-write (čtení i zápis). Obvykle se používá read-only (pouze pro čtení). Typ read-write (čtení i zápis) by měl představovat hlavní server.
preference
Číslo 1 - 10. Server s nejvyšší preferenční hodnotou se vybere pro připojení LDAP. Viz ″Nastavení preferenčních hodnot pro replikované servery LDAP″ v knize IBM Tivoli Access Manager Base: Administrativní příručka.
Příklad: replica =replica1.ldap.tivoli.com,389,readonly,5 replica =replica2.ldap.tivoli.com,389,readonly,5
Podpora P3P (Platform for Privacy Preferences) hlaviček P3P (Platform for Privacy Preferences) je standard pro World Wide Web Consortium poskytující způsob popsání preferencí utajení uživatele a politiky utajení webového serveru jednotným způsobem. Pomocí P3P může uživatel konfigurovat preference utajení určující, která informace je předána webovému serveru a jak se tato informace použije. Pomocí P3P může webový server uvést, kterou informaci politiky utajení uživatele poskytuje a jak tuto informaci použije. Politika utajení webového serveru je k dipozici uživatelům, jejichž prohlížecí programy povolené P3P ji mohou číst a porovnat s vlastními uživatelovými preferencemi utajení, ve formátu, který může počítač přečíst. Uživatel je upozorněn, když se metoda utajení webového serveru a konfigurace utajení uživatele neshodují. Obecné použití P3P je umožnit prohlížecím programům provádět inteligentní rozhodnutí o tom, zda přijmout cookies obdržené z webového serveru. Podpora této funkce je v produktu Internet Explorer 6.0 umožněna předvolbou. Pokud Internet Explorer 6.0 přijímá cookie ze serveru neodesílajím politiku P3P, nebo odesílajícím politiku neodpovídající preferencím utajení uživatele, tak se může prohlížecí program rozhodnou automaticky cookie blokovat. Plug-in program spoléhá na cookies, že udrží informaci relace tak jako, že například zadrží informaci přepnutí při selhání. Internet Explorer používá své předvolené cookies pro bloky nastavení a tudíž neuloží cookies plug-in programu, které efektivně omezují jeho funkcionalitu. Plug-in program poskytuje volby konfigurace P3P uvádějící vyhlášku kompaktní politiky P3P odeslanou se stránkami při nastavení cooike plug-in programu. Parametry konfigurace plug-in programu pro P3P vám umožňují vytvořit kompaktní politiku P3P odpovídající privátní politice vaší organizace. Je pak na klientovi, aby se rozhodl, zda povolí nastavení cookies pro produkt Tivoli Access Manager. Poznámka: Neměli byste konfigurovat politiku P3P, která se neshoduje s privátní politikou vaší organizace, abyste umožnili programu Internet Explorer přijmout cookies. Než pro cookies plug-in programu povolíte politiky P3P, zajistěte, že ovládáte specifikace P3P a chápete přesně, co prohlašujete za privátní politiku vaší organizace.
Konfigurování hlaviček P3P Plug-in program poskytuje parametry konfigurace, které se shodují s definicí syntaxe kompaktní politiky doporučení W3C P3P. Tyto parametry mohou být konfigurovány, aby povolily cookies plug-in programu, zatímco stále udržují integritu privátní politiky vaší organizace. Prvním krokem konfigurace hlaviček P3P je nastavit parametr send-p3p-header v [pdweb-plugins] v konfiguračním souboru pdwebpi.conf. Tento záznam může být nastaven na bázích po jednotlivých virtuálních hostech tak, že se definuje ve stanze [virtual_host_name] definované uživatelem. Nastavením na true uvádí parametr Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
25
send-p3p-header, zda plug-in program přidává hlavičku P3P obsahující příkaz kompaktní politiky do libovolné odpovědi HTTP, ve které nastavil cookies. Standardně je odeslání hlavičky P3P zakázáno. Pokud jste odesílání hlaviček P3P povolili, tak by měly být nastaveny parametry ve stanze [p3p-header] nebo [p3p-header:virtual_host]. Tyto parametry uvádějí kompaktní politiku použitou pro nastavení všech HTTP cookies. Předvolená nastavení v této stanze umožňují uložení cookies relace v prohlížecím programu Internet Explorer 6 —i když se objeví jako cookies třetí strany. Tabulka 6. Parametry [p3p-header] Parametr
Použití
p3p-element
Tento parametr se může použít k uvedení odkazu na plnou politiku XML v dodatku ke kompaktní politice konfigurované pomocí jiných parametrů v této stanze. Nevysvětlení řádku p3p-element = policyref="/w3c/p3p.xml" odkazuje prohlížecí program na odeslání uvedeného odkazu plné politice XML. Poznámka: ACL umožňující neautentizovaný přístup musí být v adresáři /w3c nastaveno, aby povolilo přístup k politice. Toto je požadováno, protože Internet Explorer neodesílá autentizační informaci s požadavkem povolujícím zobrazení politiky.
access
Uvádí přístup, který má uživatel k informaci obsažené uvnitř a odkazované pomocí cookie. Možné hodnoty jsou: none all nonident contact-and-other ident-contact other-ident
disputes
Uvádí, zda plná metoda P3P obsahuje nějakou informaci s ohledem na rozepře s informací obsaženou v cookie. Platné hodnoty jsou true or false. Tento parametr je standardně nastaven na hodnotu false.
remedies
Uvádí možné nápravy rozepří. Možné hodnoty jsou: correct money law Pokud není uvedeno, není v metodě obsažena žádná informace nápravy.
non-identifiable
26
Pokud je nastaveno na true, tento parametr uvádí, že žádná informace v cookie nebo informace odkazovaná pomocí cookie nikdy osobně neidentifikuje uživatele. Platné hodnoty jsou true nebo false. Tento parametr je standardně nastaven na hodnotu false.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 6. Parametry [p3p-header] (pokračování) Parametr
Použití
purpose
Uvádí smysl informace v cookie a informace odkazované pomocí cookie. Možné hodnoty jsou: current admin develop tailoring pseudo-analysis pseudo-decision individual-analysis individual-decision contact historical telemarketing a other-purpose. Pro všechny hodnoty s výjimkou current může být konfigurován dodatečný specifikátor. Možné hodnoty jsou: always opt-in opt-out. Pro neuvedené smysly je předvolenou hodnotou always. Tato hodnota je uvedena po smyslu a je oddělena pomocí dvojtečky, například: purpose = contact:opt-in
recipient
Uvádí příjemce informace v cookie a informaci odkazovanou pomocí cookie. Možné hodnoty jsou: ours delivery same unrelated public other-recipient.
retention
Uvádí, jak dlouho je zadržena informace v cookie nebo informace odkazovaná pomocí cookie. Možné hodnoty jsou: no-retention stated-purpose legal-requirement business-practices indefinitely.
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
27
Tabulka 6. Parametry [p3p-header] (pokračování) Parametr
Použití
categories
Uvádí typ informace uložené v cookie nebo informace odkazované pomocí cookie. Pokud je neidentifikovatelný parametr nastaven na true, pak nemusí být konfigurovány kategorie. Možné hodnoty jsou: physical online uniqueid purchase financial computer navigation interactive demographic content state political health preference location government other-category
Příklad konfigurace P3P: [pdweb-plugins] nebo [jméno-virtuálního-hostitele] send-p3p-header = true ... [p3p-header] nebo [p3p-header:jméno-virtuálního-hostitele] # p3p-element = policyref="/w3c/p3p.xml" access = none disputes = false non-identifiable = false purpose = current purpose = other-purpose:opt-in recipient = ours retention = no-retention categories = uniqueid
Konfigurace monitorování, protokolování, trasování a databáze paměti cache plug-in programu Protokolování a monitorování vám mohou poskytnout informace, které vám pomohou při identifikaci všech problémů, které byste mohli mít s plug-in programem. Pokud máte problémy a potřebujete pohled na chybové zprávy v reálném čase, pak spusťte plug-in program v popředí pomocí volby -foreground, tj.: pdwebpi -foreground
Poznámka: Máte-li nainstalován webový server IIS, musíte server IIS nejprve znovu spustit, abyste mohli plug-in program spustit v režimu spuštění na popředí, protože je nezbytné uvolnit všechny stávající sdílené paměti. Stavové a chybové zprávy se protokolují do souboru, který je nakonfigurován v parametrech log-file, logs a log-entries ve stanze [pdweb-plugins] konfiguračního souboru pdwebpi.conf.
28
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Konfigurace monitorovací a základní databáze paměti cache plug-in programu se provádí pomocí parametrů ve stanze [aznapi-configuration] konfiguračního souboru pdwebpi.conf.
Prověřovací záznamy Základní služby autorizačního rozhraní API umožňují zachycovat autentizační (authn) a autorizační (azn) monitorované události. Standardní ’authn’ monitorované události však nezahrnují dostatečné informace o pokusech o autentizaci, které by umožnily uvést tyto monitorované události do souvislosti s určitým virtuálním hostitelem, pokud plug-in program chrání více než jednoho hostitele. Z tohoto důvodu plug-in program obsahuje implementaci vlastní kategorie monitorovaných událostí, aby byl schopen zachycovat informace o autentizaci specifické pro daného virtuálního hostitele. Standardní ’azn’ monitorované události zachycují informace o virtuálním hostiteli relevantní pro plug-in program na základě jména chráněného objektu, které bylo vytvořeno s prefixem /PDWebPI/jméno-virtuálního-hostitele. Autentizační monitorované události specifické pro plug-in program jsou zaznamenávány do společných oblastí monitorovaných událostí specifických pro virtuální hostitele, které jsou vytvořeny následujícím způsobem: wpi.jméno-virtuálního-hostitele.authn.jméno-autentizačního-modulu
Autentizační monitorované události specifické pro plug-in program odpovídají definicím DTD, které byly popsány v knize IBM Tivoli Access Manager Base: Administrativní příručka. Prvky ’wpi’ prověřovacích záznamů ve XML stylu jsou popsány v níže uvedené tabulce: Tabulka 7. Definice polí autentizačního prověřovacího záznamu. Příznak XML
Popis
<event>
Zapouzdřuje příznak pro monitorovací záznam. Prvek obsahuje atribut, který popisuje revizi definice doc type záznamu.
Záznam data a času, kdy se událost objevila.
Prvek příznaku obsahuje parametr status, který identifikuje chybový kód produktu Tivoli Access Manager nebo plug-in programu. Prvek popisuje obecné výsledky události. Možné hodnoty jsou: v 0 = Úspěch v 1 = Selhání v 2 = Nevyřízeno v 3 = Neznámý
Příznak hlavičky části odesílatele zprávy monitorovacího záznamu. Prvek příznaku obsahuje parametr blade, který identifikuje proces blade produktu Tivoli Access Manager, který je za událost odpovědný.
Příznak identifikuje komponentu, která zachycuje prověřovací záznamy. Komponenta se zaznamenává ve tvaru: wpi.jméno-virtuálního-hostitele.typ-události.jméno-modulu
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
29
Tabulka 7. Definice polí autentizačního prověřovacího záznamu. (pokračování) Příznak XML
Popis Označuje použitou politiku autentizace. Kódy akcí a jim odpovídající mechanismus autentizace jsou: 16961 - BA (Základní autentizace) 17236 - Autentizace pomocí certifikátu klienta 17731 - Autentizace pomocí ECSSO modulu 17999 - Autentizace pomocí Failover cookie 17997 - Autentizace pomocí formulářů 18504 - Autentizace pomocí HTTP hlavičky 18768 - Autentizace pomocí IP adresy 4806211 - Autentizace pomocí IV hlavičky: pověření PAC 4806229 - Autentizace pomocí IV hlavičky: jméno uživatele 4806220 - Autentizace pomocí IV hlavičky: rozlišovací jméno 300609 - Autentizace pomocí IV hlavičky: IP adresa 21579 - Autentizace pomocí tokenu
Definuje jméno serveru, který inicioval událost.
Příznak hlavičky části monitorovacího záznamu pro toho, kdo se pokoušel o přístup. Prvek příznaku může obsahovat jméno toho, kdo se pokoušel o přístup.
<principal>
Příznak objektu obsahuje parametr auth, který označuje autentizační adresářovou službu. Příznak definuje potvrzené jméno uživatele.
Příznak cíle obsahuje parametr resource, který může mít jednu z následujících hodnot: v 0 = autorizace v 1 = zpracování v 2 = TCB v 3 = pověření v 4 = obecné Autentizační prověřovací záznamy vždy nastavují tuto hodnotu na 3 - pověření.
Zadržuje monitorovací data, která mají malý význam pro proces autentizace.
Další informace o selhání autentizace. Například výsledkem selhání během pokusu o autentizaci pomocí informací v HTTP hlavičce je záznam v protokolu monitorování, který zaznamená v tomto poli informaci, že selhala HTTP hlavička.
Konfigurace monitorování Následující tabulka zobrazuje parametry konfigurace monitorování a vysvětluje jejich funkci. Tabulka 8. Definice parametrů konfigurace monitorování Parametr
30
Popis
logsize
Velikost (v bajtech), po jejímž dosažení se soubor protokolu obnoví na nový soubor. Je-li tato velikost nastavena na hodnotu 0, soubory protokolu se nikdy neobnoví. Záporné číslo obnoví soubory protokolu každý den, bez ohledu na jejich velikost.
logflush
Interval (ve vteřinách), ve kterém jsou protokoly zarovnány. Maximální hodnota je 6 hodin, předvolba je 20 vteřin.
logaudit
Aktivuje nebo zablokuje monitorování.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 8. Definice parametrů konfigurace monitorování (pokračování) Parametr
Popis
auditlog
Uvádí jméno monitorovacího souboru.
auditcfg
Aktivuje nebo zablokovává monitorování autorizace a/nebo autentizace.
Například: [aznapi-configuration] logsize = 2000000 logflush = 20 logaudit = no auditlog = audit.log auditcfg = azn #auditcfg = authn auditcfg = wpi
Trasování akcí plug-in programu Produkt Tivoli Access Manager Plug-in for Web Servers nabízí možnost trasovat akce a uložit výsledky tohoto trasování do souboru pro účely ladění. Trasování je primárně nástrojem pro analýzu a diagnostiku problémů, který používají pracovníci podpory aplikací, aby získali komplexní pohled na akce způsobující problémy. Jako uživatel můžete zjistit, že některé ze systémových prostředků plug-in programu pro trasování jsou užitečné, ačkoliv většina z nich vám přinese minimální prospěch, pokud právě neprovádíte diagnostiku nějakého komplexního problému. V plug-in programu je možné trasovat HTTP zprávy. Tato vlastnost může být velmi užitečná, protože přesně ukazuje, co bylo obdrženo od uživatele a co bylo uživateli vráceno - i v případě komunikace přes protokol HTTPS. Trasování se zapíná a vypíná pomocí standardních trasovacích příkazů obslužného programu pdadmin. Vstupy a výsledky rozhodnutí o autorizaci mohou být trasovány pro usnadnění diagnózy problémů konfigurace politiky autorizace. Toto trasování zobrazuje informaci pověření uživatele obsahující jména, UUID, ID relace a atributy. Toto trasování také zobrazuje jméno chráněného objektu produktu Tivoli Access Manager použitého k požadovanému rozhodnutí a oprávnění. Výsledek rozhodnutí zobrazen také spolu s libovolnými navrácenými atributy.
Trasovací příkazy pdadmin Seznam trasovacích komponent: Příkaz list vytváří seznam všech akcí plug-in programu, které je možné trasovat. Syntaxe: pdadmin> server task PDWebPI-jméno-serveru trace list [komponenta]
Většina vypsaných trasovacích úloh je specifická pro produkt Tivoli Access Manager. Trasovací položky specifické pro plug-in program mají prefix pdwebpi. Nastavení trasovacích komponent: Při ladění programu vám mohou být užitečné dvě hlavní trasovací položky: v pdwebpi.request v pdwebpi.plugin v pdwebpi.azn
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
31
Je-li položka pdwebpi.request nastavena na dva, trasuje každou událost, která projde přes plug-in program. Je-li položka pdwebpi.request nastavena na devět, součástí trasování je i hlavička požadavku. Položka pdwebpi.plugin aktivuje trasování na serveru plug-in programu. Všechny zprávy jsou odeslány do souboru protokolu webového serveru, nebo v případě IIS do protokolu odlišného od toho, který se používá pro autorizační server.Položka pdwebpi.azn nastavená na jednu stručnou informaci trasování o každém rozhodnutí o autorizaci obsahuje jméno chráněného objektu, řetězec povolení, jméno uživatele, ID relace, metodu HTTP, URI HTTP a výsledek rozhodnutí. Když je položka pdwebpi.azn nastavena na dvě, objeví se trasování pro dodatečnou informaci atributu pověření a jak pro vstupní tak pro výstupní atributy rozhodnutí. Když je položka pdwebpi.azn nastavena na pět, je zahrnuta dodatečná informace o zpracování zvýšené a nové autentizace. Trasovací příkaz set má následující syntaxi: pdadmin> server task PDWebPI-jméno-serveru trace set komponenta úroveň [file path=soubor|jiná-konfigurace-protokolu-agenta]
Kde komponenta je jméno trasovací komponenty, jejichž seznam vypíše příkaz list. Pro tuto komponentu je trasování nastaveno. úroveň je množství podrobných informací, které se pro dané trasování shromáždí. Rozsah je 1 až 9, hodnota 1 znamená, že informace budou nejméně podrobné, hodnota 9 znamená, že informace budou maximálně podrobné. Volitelný parametr file path určuje umístění výstupu trasování. Výstup trasování je standardně nastaven do standardně nakonfigurovaného souboru protokolu plug-in programu (pokud se nepoužívá komponenta pdwebpi.plugin). Na serverech IIS je jméno souboru, do kterého je odesílán výstup z trasování komponenty plug-in programu, vždy nakonfigurován pomocí parametru log-file ve stanze [iis] konfiguračního souboru. Výstup je možné odeslat na obrazovku pomocí volby -foreground. To znamená: pdwebpi -foreground
Zobrazení trasovacích komponent: Pokud chcete zobrazit trasovací komponenty, použijte příkaz show v následujícím tvaru: pdadmin> server task PDWebPI-jméno-serveru trace show [komponenta]
Nastavení databáze paměti cache Plug-in program můžete nakonfigurovat tak, aby pravidelně vyzýval hlavní autorizační databázi, aby aktualizovala informace. Parametr cache-refresh-interval může být nastaven na ″default″, ″disable″, nebo na určitý časový interval (ve vteřinách). Nastavení ″default″ je disable. [aznapi-configuration] cache-refresh-interval = 60
Parametr db-file definuje úplnou cestu k databázi paměti cache přístupových seznamů. Standardně není tento parametr nastaven. [aznapi-configuration] db-file = /var/pdwebpi/db/pdwebpi.db
Parametr listen-flags dovoluje nebo zakazuje přijímání upozornění o aktualizaci paměti cache pro politiky. Hodnota ″disable″ zablokuje naslouchací proces pro upozornění. Tento parametr se nastavuje obslužným programem svrsslcfg. [aznapi-configuration] listen-flags = disable
32
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Konfigurace služby autorizačního rozhraní API Stanza [aznapi-entitlement-services] konfiguračního souboru pdwebpi.conf přiřazuje ID služeb k jednotlivým službám. Každý záznam stanzy definuje jiný typ služby aznAPI. Podrobnější informace najdete v knize IBM Tivoli Access Manager Administration C API Developer’s Reference. Každý záznam je ve tvaru: id-služby = cesta-k-dll [ & parametry ... ]
ID služeb používá klient aznAPI, aby mohl identifikovat služby. Můžete uvést parametry, které se službě předají, jakmile bude inicializována rozhraním aznAPI. Parametry jsou v záznamu uvedeny za symbolem ″&″.
Obnovení pověření Informace získaná při autentizaci uživatele je uložena v paměti cache pověření na dobu trvání relace, abyste získali další podrobnosti o pověřeních uživatele plug-in programu — vyhledejte “Získání pověření” na stránce 4. Pokud není obnovení pověření konfigurováno, změny provedené pro zdroj informace pověření uživatele jako je např. přidání nebo odstranění uživatele ze skupiny se v relaci uživatele neprojeví, dokud není vytvořena nová relace uživatele. Některé důvody proč je obnovení pověření užitečné: v Jste schopni obnovit pověření uživatelů, aniž by se museli odhlásit a znovu přihlásit do aplikace. To zvyšuje zkušenost uživatele. v Poskytuje administrátora se schopností dodat uživatelům zvláštní přístup k zabezpečeným objektům webu během jejich aktuální relace. v Zvyšuje zabezpečení tak, že administrátorovi dovoluje omezit oprávnění přístupu uživatele během aktuální relace, pokud má důvod věřit, že se uživatel nechová vhodně.
Konfigurování obnovení pověření Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. K povolení funkcionality obnovení pověření musí být modul cred-refresh konfigurován jako předcházející autorizaci. [common-modules] ... pre-authzn = cred-refresh ...
Zajistěte, že záznam pro obnovení pověření existuje ve stanze [modules] konfiguračního souboru pdwebpi.conf; to znamená: [modules] ... cred-refresh = pdwpi-cred-refresh-module ...
Když obnovujete pověření, můžete shledat důležitým uchování některých informací o uživateli z původního pověření. Přizpůsobený atribut může například nahrát čas protokolování uživatele, který může být hodnotou, jež se má uchovat při obnově pověření nezměněná. Plug-in program vám umožňuje konfigurovat atributy, které se mají při provedení obnovy uchovat. Tyto atributy jsou konfigurovány na základě svého jména.
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
33
Stanza [cred-refresh] nebo [cred-refresh:virtual-host] uvádí atributy, které se mají uchovat z původního pověření, a které se mají při provádění obnovovací operace obnovit do nového pověření.Pro atributy, které se mají uchovat z originálu, jsou hodnoty uvedeny ve formátu preserve = attribute_pattern. Hodnoty, které se mají obnovit, jsou ve formátu refresh = attribute_pattern. Pro vzory atributu se používají pravidla shody pro vzor standardního plug-in programu s výjimkou toho, když nejsou porovnání znaku citlivá na velikost písmen. Další informace o povolených pravidlech shody naleznete v části Dodatek E, “Speciální znaky dovolené v běžných výrazech”, na stránce 211. Pro seznam atributů platí následující podmínky: v Pravidla, která se objeví ve stanze dříve mají přednost před těmi, co se objeví později. v Pravidla neodpovídající žádnému atributu jsou standardně obnovena. v Určité atributy jsou uchovány vždy bez ohledu na to, jak je stanza [cred-refresh] nakonfigurována. Jsou to atributy: – AZN_CRED_AUTHNMECH_INFO, – AZN_CRED_BROWSER_INFO, – AZN_CRED_IP_ADDRESS, – AZN_CRED_PRINCIPAL_NAME – AZN_CRED_QOP_INFO v Atributy označené aznAPI jako pouze ke čtení jsou uchovány vždy bez ohledu na obsah stanzy [cred-refresh]. v Pokud se atribut v původním pověření neobjeví, nebude bez ohledu na konfiguraci této stanzy uchován. Poznámka: Pokud ověření neexistuje v paměti cache pověření, je obnoveno pouze z registru. Jakmile je funkcionalita obnovení pověření konfigurována, můžete k obnovení pověření partikulárního uživatele použít příkazový řádek pdadmin. Níže uvedený příklad ukazuje příkaz pro přidání uživatele do nové skupiny a obnovení pověření, zatímco je uživatel stále přihlášen, efektivně dává uživateli povolení přístupu do nové skupiny. pdadmin> group modify group_name add user_name pdadmin> server task server_name refresh all_sessions user_name
Poznámka: Na platformách se systémem UNIX není po přizpůsobení konfigurace obnovení pověření nutné restartovat plug-in program. Aby se ve Windows projevily změny konfigurace obnovení pověření, je po jejich provedení pro pdwebpi.conf nutné restartovat plug-in program.
Konfigurace ukládání do paměti cache požadavku HTTP Plug-in program ukládá data požadavku do paměti cache a pokud požadavek na novou autentizaci přeruší dokončení zpracování požadavku, tak je používá k přestavbě požadavku během přesměrování HTTP. Tato funkcionalita prospívá požadavkům POST a PUT, protože jejich typy mohou obsahovat různá pole informací. Když požadavek na autentizaci přeruší požadavek, plug-in program ukládá do paměti cache všechny informace nezbytné k přestavbě během přesměrování HTTP, které následuje po nové autentizaci. Data požadavku uložená do paměti cache zahrnují URL, METHOD, tělo zprávy, dotazové řetězce a všechny HTTP hlavičky (včetně cookies). Tato data jsou dočasně uložena v pověřeních plug-in programu/paměti cache relace. Po úspěšné autentizaci (nebo po nové autentizaci) odesílá plug-in program prohledávacímu programu přesměrování HTTP. Prohledávací program následuje přesměrování do původního
34
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
URL obsaženého v přesměrování. Plug-in program zachycuje přesměrování a přestavuje požadavek pomocí dat uložených v paměti cache. Přestavený požadavek je doručen do místa určení URL.
Konfigurace parametrů server-side ukládání do paměti cache Parametr max-cached-http-body ve stanze [pdweb-plugins] konfiguračního souboru plug-in programu uvádí maximální množství dat těla HTTP, které bude uloženo do paměti cache pro libovolný poskytnutý požadavek. Pokud množství dat těla překročí konfigurované maximum, všechna data těla budou odložena. Parametr worker-size ve stanze [proxy-if] ovládá množství paměti alokované pro libovolný poskytnutý požadavek. Velikost parametru max-cached-http-body by se měla minimálně podřídit následujícímu algoritmu: max-cached-http-body * 4/3 * 2 + 3000 <= worker-size # # Tento algoritmus předpokládá, že je 3000 bajtů dostatek paměti k zadržení požadavku, méně už libovolných dat pro POST a k zadržení vráceného formuláře a také k zadržení dat pro zachycený POST. Pokud by velikost požadavku plus velikost vráceného formuláře mohla překročit 3000 bajtů, měli byste zvýšit záznam worker-size, nebo snížit hodnotu max-cached-http-body.
Podpora jazyků a znakové sady Produkt Tivoli Access Manager Plug-in for Web Servers může zobrazovat HTML stránky generované produktem Tivoli Access Manager v jazyce upřednostňovaném zákazníkem. Jazyk, ve kterém se budou zobrazovat HTML stránky, je odvozen od standardní hlavičky Accept-Language, která je součástí požadavku HTTP. Hodnoty jazyka představují dva znaky. Hodnoty specifické pro danou lokalitu se vyjadřují ve formátu skládajícím se ze dvou částí, které určují jazyk a zemi, ve které se daná verze jazyka používá. Příklady: v v v v v v v
es (španělština) de (němčina) en (angličtina) it (italština) en-US (angličtina/Spojené státy) en-GR (angličtina/Spojené království) es-ES (španělština/Španělsko)
v es-MX (španělština/Mexiko) v pt-BR (portugalština/Brazílie) Pokud plug-in program nenalezne v HTTP požadavku žádný odpovídající kód jazyka, pokusí se vyhledat daný jazyk v seznamu jazyků bez určení dialektu (tj. es-MX bude použito jako es). Pokud ani tak nenalezne odpovídající jazyk, pak bude server používat angličtinu. Pouze stránky generované produktem Tivoli Access Manager, které jsou v adresáři instalační-adresář/nls/html/jazyk/znaková sada, mohou být používány pro více jazyků. Mezi takové stránky patří například všechny formuláře pro autentizaci produktu Tivoli Access Manager a stránky pro správu účtů produktu Tivoli Access Manager. Jazyky uvedené v poli Accept Language HTTP hlavičky jsou přímo namapovány na adresáře nalezené v adresáři instalační-adresář/nls/html. Je možné nakonfigurovat server, aby se staral o varianty specifikace jazyka tak, že okopírujete jazykové adresáře. Chcete-li změnit server, pak skutečné adresáře, které byste měli okopírovat, jsou: Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
35
tam-base-instalační-adresář/nls/msg/jazyk am-webpi-instalační-adresář/nls/html/jazyk/znaková sada am-webpi-instalační-adresář/nls/msg/jazyk/znaková sada
Níže uvedená tabulka obsahuje seznam jazyků, které plug-in program podporuje, spolu s příslušnými jmény podadresářů: Tabulka 9. Jazyky podporované plug-in programem s podporovanými adresáři. Jazyk
Systémový adresář angličtina (předvolba)
C
čeština
cs
němčina
de
španělština
es
francouzština
fr
maďarština
hu
italština
it
japonština
ja
korejština
ko
polština
pl
portugalština, Brazílie
pt_BR
ruština
ru
čínština, Čína
zh_CN
čínština, Tchaj-wan
zh_TW
V poli Accept Language HTTP hlavičky se rozeznává maximálně deset specifikací jazyka. Různé znakové sady pro různé poskytnuté jazyky se nalézají v adresáři pod tím pro podporu jazyků. Použitý adresář znakové sady je vybrán na základě hodnoty hlavičky accept-charset obdržené od klienta. Pokud není nalezen žádný záznam (nebo pokud není hlavička nastavena), použije se adresář utf-8. Podporu pro různé jazyky a znakové sady můžete povolit nebo zakázat na základě hlaviček accept-language aaccept-charset. Obecná nastavení pro tyto parametry jsou konfigurována ve stanze [pdweb-plugins], ale pokud jsou ve stanze definována pomocí ID virtuálního hostitele, mohou být přepsána na bázích virtuálního hostitele. [pdweb-plugins] nebo [virtuální-hostitel]... use-accept-langauge-header = true ... use-accept-charset-header = false
Použití hlavičky accept-charset je obecně zakázáno. Parametr use-accept-language-header povoluje nebo zakazuje použití HTTP hlavičky accept-language při pokusu o nalezení jazyka pro generovanou odpověď HTML. Parametr use-accept-charset-header povoluje nebo zakazuje použití HTTP hlavičky accept-charset při pokusu o nalezení znakové sady, ve které dekódovat prvky požadavku HTTP, nebo generovat odpověď HTML. Předvolenou hodnotou (pokud není nalezena v konfiguračním souboru) je false.
36
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Hlavička user-agent se pro hlavičky accept-language a accept-charset může pro vybrání jazyka a znakové sady použít jako alternativní.Hlavička user-agent obsahuje pro zařízení specifickou informaci, která se může použít k poskytnutí informace o jazyku a znakové sadě, když jsou známy požadavky zařízení. Hlavička user-agent se použije pouze, pokud nejsou nalezeny hlavičky accept-language a accept-charset, nebo pokud je použití těchto hlaviček zakázáno. Předvolené mapování z user-agent na jazyk nebo znakovou sadu je konfigurováno ve stanze [user-agent] a může být přepsáno na bázích po jednotlivých virtuálních hostitelích. Stanza zahrnuje seznam porovnávaných vzorů v pořadí určeném pro obsah hlavičky user-agent. Seznam dostupných zástupných znaků získáte v části Dodatek E, “Speciální znaky dovolené v běžných výrazech”, na stránce 211. Pokud je nalezena shoda, tak se použije adresář pro odpovídající jazyk a znakovou sadu. V dodatku k uvedení jazyka a znakové sady pro poskytnutý vzor user-agent lze také uvést adresář. V tom případě se při odesílání stránek produktu Tivoli Access Manager uvedené jméno adresáře použije raději než to pro znakovou sadu. Tento adresář se musí nalézat pod adresářem uvedeného jazyka.
Kapitola 2. Konfigurace produktu IBM Tivoli Access Manager Plug-in for Web Servers
37
38
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers Tato kapitola probírá, jak produkt IBM Tivoli Access Manager (Tivoli Access Manager) Plug-in for Web Servers spravuje stavy relací, obsluhuje proces autentizace a provádí zpracování následující po autorizaci, které je vyžadováno v autorizovaných relacích. Tato úvodní kapitola obsahuje následující témata: v “Proces zacházení s požadavkem” v “Konfigurace autentizace” na stránce 41 v “Správa stavu relace” na stránce 49 v “Přehled konfigurace autentizace” na stránce 55 v “Konfigurace Základní autentizace” na stránce 58 v “Konfigurace autentizace pomocí formulářů” na stránce 61 v “Konfigurace autentizace pomocí certifikátů” na stránce 64 v “Konfigurace autentizace pomocí tokenů” na stránce 65 v “Konfigurace autentizace pomocí SPNEGO” na stránce 69 v “Konfigurace autentizace pomocí NTLM0 (pouze pro platformy IIS)” na stránce 76 v “Konfigurace autentizace pomocí webového serveru (pouze pro platformy IIS)” na stránce 77 v “Konfigurace autentizace po přepnutí při selhání” na stránce 78 v “Konfigurace autentizace pomocí IV hlaviček” na stránce 92 v v v v v v
“Konfigurace autentizace pomocí HTTP hlaviček” na stránce 95 “Konfigurace autentizace pomocí IP adresy” na stránce 96 “Konfigurace autentizace pomocí LTPA cookies” na stránce 97 “Konfigurace přesměrování uživatelů po přihlášení” na stránce 98 “Přidání rozšířených atributů pro pověření” na stránce 99 “Přidání rozšířených atributů LDAP do HTTP hlavičky (hodnota příznaku)” na stránce 102 v “Podpora MPA (Multiplexing Proxy Agents)” na stránce 103
Proces zacházení s požadavkem Produkt Tivoli Access Manager Plug-in for Web Servers zpracovává každý požadavek webu v pořadí, ve kterém dorazí do webového serveru. Proces nakládání s požadavkem má osm kroků: 1. Identifikace virtuálního hostitele Prvním krokem ve zpracování požadavku je identifikace virtuálního hostitele, pro kterého je požadavek zamýšlen. Identifikace virtuálního hostitele je posouzena v části “Konfigurace virtuálních hostitelských serverů” na stránce 13. 2. Identifikace relace Jakmile byl virtuální hostitel určen, je požadavek posuzován na informaci o existující autentizované relaci. Tato informace může být cookie relace nebo ID SSL relace. Informace použitá pro identifikaci relace je určena moduly konfigurované relace. “Správa stavu relace” na stránce 49 posuzuje každý dostupný modul relace. 3. Autentizace © Copyright IBM Corp. 2000, 2003
39
4.
5.
6.
7.
Pokud není označena žádná existující relace, je požadavek posuzován na informaci o autentizaci. To může být informace, jako je jméno uživatele a heslo pro Základní autentizaci, nabídka na formulář protokolování, nebo certifikát klienta. Informace použitá pro autentizaci klienta je určena moduly konfigurované relace. “Proces autentizace” na stránce 41 posuzuje každý dostupný modul autentizace. Pokud se v požadavku vyskytuje platná informace o autentizaci, je vytvořena nová relace autentizovaného uživatele. Pokud není přítomna žádná informace o autentizaci, je požadavek považován za neautentizovaný. Pokud je v požadavku přítomna neplatná informace o autentizaci a metoda autentizace podporuje opětovné zadání (např. Základní autentizace) informace o autentizaci, je uživatel vyzván, aby poskytl svou autentizaci znovu. Pokud metoda autentizace nepodporuje opětovné zadání (např. certifikace klienta) je klientovi vrácena chyba. Před autorizací V některých případech může být před autorizací přístupu k požadovanému zdroji vyžadováno výchozí zpracování požadavku. Toto zpracování je provedeno libovolným konfigurovaným modulem předcházejícím autorizaci. Moduly předcházející autorizaci poskytují funkce, které nevyžadují autorizaci, nebo podporují schopnosti vyžadující přístup k požadavku před rozhodnutím o autorizaci. Autorizace Během autorizace je pomocí pověřovací informace přidružené k relaci konzultována politika produktu Tivoli Access Manager pro určení, zda by měl či neměl být přidělen přístup k požadovanému zdroji a když ano, tak pod jakou podmínkou. Politiky, které by mohly být definovány pro ovládání přístupu ke zdrojům, jsou definovány v části Kapitola 4, “Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers”, na stránce 107. Povýšení autentizace V případech, kdy je úroveň autentizace uživatele nevhodná pro přístup k požadovanému zdroji, nebo kdy je požadavek neautentizovatelný, je požadavek přezkoumáván znovu pro získání informace o autentizaci, která by mohla autentizovat uživatele v požadované úrovni autentizace. Pokud žádná taková informace neexistuje a je konfigurován modul autentizace podporující schopnost vyzvat uživatele k informaci na požadované úrovni autentizace, tak je uživatel vyzván tuto informaci poskytnout. Pokud neexistují žádné prostředky pro povýšení relace autentizovaného uživatele na dostačující verzi pro přístup ke zdroji, je přístup odepřen. Po autorizaci Občas jsou po rozhodnutí o autorizaci vyžadována určitá zpracování, aby: v modifikovala webový požadavek předtím, než je použit webovým serverem (například, aby vložila hlavičku) v modifikovala odpověď webu generovanou webovým serverem (například, aby nastavila cookie) v generovala kompletní odpověď, aniž by byl požadavek použit webovým serverem (například, aby po úspěšném přihlášení přesměrovala uživatele na partikulární stránku)
Tyto operace se objeví po výsledku zpracování autorizace potom, co rozhodnutí může ovlivnit způsob zacházení s požadavkem. Tyto schopnosti jsou poskytovány po-autorizačním modulem. 8. Zacházení s odpovědí Funkce, jako je zpracování FSSO (Forms Single Sign-on) a EAI (External Authentication Interface) vyžadují, aby byla odpověď vygenerovaná webovým serverem spíše zpracována plug-in programem, než aby byla poslána klientovi. Obecně lze o zacházení s odpovědí říci, že před odesláním alternativní odpovědi uživateli zpracovává odpovědi plug-in program. Moduly vyžadující tuto schopnost se nazývají moduly odpovědi.
40
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Proces autentizace Autentizace je způsob, jak identifikovat jednotlivé procesy nebo jednotky, které se pokouší přihlásit se do zabezpečené domény. Výsledkem úspěšné autentizace je totožnost produktu Tivoli Access Manager, která představuje uživatele. Plug-in program používá tuto totožnost, aby získal pověření pro daného uživatele. Autorizační server používá toto pověření k tomu, aby povolil nebo zakázal přístup ke chráněným objektům poté, co vyhodnotí povolení ACL a podmínky POP, regulující politiky přístupu ke každému objektu. Poznámka: ACL = politika přístupového seznamu POP = politika chráněného objektu Produkt Tivoli Access Manager Plug-in for Web Servers standardně podporuje několik politik autentizace a je možné jej přizpůsobit i pro jiné politiky.
Konfigurace autentizace Všechny dostupné politiky autentizace spolu se jmény k nim přidružených sdílených knihoven jsou nadefinovány ve stanze [modules] konfiguračního souboru pdwebpi.conf. Stanza [modules] obsahuje také seznam modulů, které se používají při identifikaci relace a zpracování následujícím po autorizaci. Tyto moduly budou popsány později. Sdílené knihovny musí být v adresáři pdwebpi/lib. Jména sdílených knihoven jsou uvedena bez prefixu specifického pro daný operační systém (např. lib) a bez jakékoliv přípony specifické pro daný operační systém (např. dll). Například: BA = pdwpi-ba-module
Ve výše uvedeném příkladu knihovna BA modulu je zadána jako pdwpi-ba-module. Na operačním systému Windows hledá plug-in program soubor s názvem pdwpi-ba-module.dll, na operačním systému Solaris Operating Environment hledá soubor s názvem libpdwpi-ba-module.so a na operačním systému AIX hledá soubor s názvem libpdwpi-ba-module.a. Poznámka: Alternativní zadání předvolené vyhledávací cesty pro soubory knihoven je možné nadefinovat ve stanze [module-mgr]. Každé označení nadefinované ve stanze [modules] má vlastní odpovídající stanzu. Například [BA], [cert] a [token]. Informace o konfiguraci specifické pro každou z politik autentizace jsou uvedeny v těchto stanzách a platí pro tuto politiku autentizace, bez ohledu z jakého virtuálního hostitele je volána. Je-li vyžadována speciální konfigurace na úrovni virtuálního hostitele, pak je možné předvolenou konfiguraci přepsat pomocí stanzy, která blíže určí označení modulu pomocí označení virtuálního hostitele. Například: [BA] basic-auth-realm = "Access Manager" [BA:ibm.com] basic-auth-realm = "ibm.com"
Ve výše uvedeném příkladu budou uživatelé přistupující k virtuálnímu hostiteli ibm.com pomocí Základní autentizace používat konfigurační parametry, uvedené ve stanze [BA:ibm.com]. Standardní konfigurace modulů povoluje, aby pro danou politiku autentizace byla zadána pouze jedna instance knihovny modulu. Například: [modules] BA = pdwpi-ba-module
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
41
Některé instalace mohou vyžadovat zadání více instancí knihovny autentizace. To může nastat v situaci, kdy je vyžadováno různé chování modulu v závislosti na úrovních autentizace. Níže uvedený příklad ukazuje konfiguraci dvou instancí modulu autentizace pomocí formulářů. [modules] BA = pdwpi-ba-module forms-authn-level1 = pdwpi-forms-module forms-authn-level2 = pdwpi-forms-module [common-modules] authentication = forms-authn-level1 authentication = forms-authn-level2 authentication = BA [forms-authn-level1] login-form = level1-form [forms-authn-level2] login-form = level2-form [BA] ...
Posledním krokem konfigurace politik autentizace je určení politik autentizace. Ty jsou nastaveny ve stanze [common-modules] konfiguračního souboru, a to v pořadí podle jejich preferencí. Například: [common-modules] session = ssl-id session = BA session = session-cookie authentication = cert authentication = BA post-authzn = ltpa
Ve výše uvedeném příkladu nastavení konfigurace zajišťuje, že: v ID relace SSL se používají přednostně ke správě informací o relaci v BA hlavičky (jsou-li k dispozici) se používají ke správě informací o relaci, pokud není ID relace SSL k dispozici v cookie relace se používají jako poslední možnost, jak spravovat informace o relaci, pokud není k dispozici ani ID relace SSL, ani BA hlavička v jako politika autentizace se přednostně používají certifikáty v pokud není k dispozici certifikát, použije se pro autentizaci BA v LTPA cookie se přidají v rámci zpracování následujícího po autorizaci k danému požadavku
Konfigurace autentizace virtuálních hostitelů Konfigurací politik autentizace je možné dokázat na úrovni jednotlivých virtuálních hostitelů tak, že uvedete politiky přímo ve stanze každého virtuálního hostitele. Například: [pdweb-plugins] virtual-host = ibm.com [ibm.com] .... session = ssl-id session = BA session = session-cookie
42
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
authentication = cert authentication = BA post-authzn = ltpa
Jiným způsobem, jak nadefinovat politiky autentizace pro virtuální hostitele, je nadefinovat stanzu pro konfiguraci politiky autentizace. To vám umožní, aby více virtuálních hostitelů sdílelo konfiguraci modulu. Stanza pro konfiguraci modulu je uvedena v parametru modules stanzy pro virtuální hostitele. Například: [pdweb-plugins] virtual-host = ibm.com virtual-host = lotus.com [ibm.com] modules = ibm-lotus-module-stanza [lotus.com] modules = ibm-lotus-module-stanza [ibm-lotus-module-stanza] authentication = BA session = BA post-authzn = ltpa
Pokud nejsou v konfiguračním souboru nadefinovány jednotlivé stanzy pro konfiguraci politik autentizace na úrovni jednotlivých virtuálních hostitelů, všichni virtuální hostitelé použijí parametry nakonfigurované ve stanze [common-modules]. To znamená, že předvolenou hodnotou parametru modules je common modules. Následující příklad nastavuje virtuálního hostitele s názvem ibm.com, který používá ID relací SSL tam, kde může, hlavičky BA tam, kde nemůže používat ID relace SSL, ale může používat hlavičky BA, a používá cookie relace jako poslední možnost, jak udržovat informace o relaci. Podporuje autentizaci pomocí certifikátů před Základní autentizací a v případě úspěšné autentizace přidá k požadavku LTPA cookie, aby bylo možné tento požadavek zpracovat webovým serverem. Příklad zobrazuje pouze parametry, které zde byly nadefinovány. [pdweb-plugins] virtual-host = ibm.com [modules] ssl-id = pdwpi-ssl-id session-cookie = pdwpi-session-cookie BA = pdwpi-ba cert = pdwpi-cert ltpa = pdwpi-ltpa [ibm.com] session = ssl-id session = BA session = session-cookie authentication = cert post-authzn = ltpa
Další konfiguraci parametrů autentizace je možné provést na úrovni jednotlivých virtuálních hostitelů tak, že vytvoříte konfigurační stanzy politik autentizace specifické pro dané virtuální hostitele. Níže uvedený příklad zobrazuje konfiguraci dvou virtuálních hostitelů: ibm.com a lotus.com. Každý virtuální hostitel má konfiguraci autentizace specifické pro daný modul.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
43
[pdweb-plugins] virtual-host = ibm.com virtual-host = lotus.com [modules] ... [ibm.com] session = BA session = session-cookie authenitcation = BA authentication = forms [lotus.com] session = session-cookie authenitcation = BA authentication = cert [BA:ibm.com] basic-auth-realm = "Access Manager - ibm.com" [BA:lotus.com] basic-auth-realm = "Access Manager - lotus.com"
Konfigurace pořadí politik autentizace Na pořadí, ve kterém se nakonfigurované politiky autentizace zobrazí v konfiguračním souboru, životně záleží správná funkčnost vašeho plug-in softwaru. Typy politik autentizace, které zvolíte, musí být pečlivě uváženy a implementovány tak, aby aby byly zabezpečeny proti poruše a aby splňovaly vaše bezpečnostní cíle. Produkt Tivoli Access Manager Plug-in for Web Servers podporuje různé politiky autentizace způsobem, který umožňuje, aby byly přizpůsobeny různým požadavkům zákazníka pro různé potřeby zabezpečení ochrany dat. Jak bylo vidět v předchozích částech tohoto dokumentu, stanza [common-modules] konfiguračního souboru pdwebpi.conf je místo, kde zadáváte politiky autentizace, které chcete používat. Stanza [authentication-levels] konfiguračního souboru definuje úrovně zvýšené autentizace (viz “Politika POP odolnosti autentizace (zvýšená)” na stránce 113), a současně je pořadí politik autentizace nakonfigurováno ve stanze [common-modules]. Politika autentizace je obvykle na úrovni 1, pokud pro ni není nadefinován žádný záznam ve stanze [authentication-levels]. Pořadí politik autentizace je pak určeno od nejvyšší úrovně autentizace po nejnižší úroveň autentizace podle pořadí, ve kterém jsou politiky autentizace nadefinovány ve stanze [authentication-levels]. Pokud je úroveň autentizace sdílena několika moduly, pomocné pořadí se určuje podle pořadí, ve kterém se moduly objeví ve stanze [common-modules]. Chcete-li porozumět autentizaci plug-in programu, je dobré vždy přemýšlet o plug-in programu tak, že si položíte dvě otázky pro každý zpracovávaný požadavek: 1. Mohu autentizovat tento požadavek pomocí nakonfigurovaných politik autentizace? Je-li odpověď na tuto otázku ne, pak si plug-in program položí další otázku. 2. Mohu vygenerovat požadavek na autentizaci pomocí nakonfigurované politiky autentizace? Představte si následující konfiguraci. [common-modules] authentication = BA
44
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Pro příchozí požadavek platí, že se bude vyžadovat autentizace uživatele, pokud přístupový seznam nepovolí přístup neautentizovaným uživatelům. Plug-in program, který vidí BA jako jedinou nakonfigurovanou politiku autentizace, se ptá: ″Mohu autentizovat tento požadavek pomocí Základní autentizace?″ Pokud jde o nový požadavek, pak je odpověď ne — plug-in program neví nic o tomto uživateli. Plug-in program se potom zeptá: ″Mohu vygenerovat požadavek na autentizaci s použitím Základní autentizace?″ Pokud byla Základní autentizace správně nakonfigurována, odpověď zní ano. Plug-in program vyzve uživatele, aby zadal své ID a heslo. Toto byl velmi jednoduchý příklad autentizace pomocí Základní autentizace. Je velmi pravděpodobné, že budete chtít nakonfigurovat více než jednu politiku autentizace, a to v závislosti na požadavcích na zabezpečení ochrany vašich dat ve vašem prostoru objektů. Níže je uveden podrobnější příklad logiky, kterou používá plug-in program při určování priority určité politiky autentizace. Logika autentizace, která je probírána v následujících odstavcích, předpokládá, že neautentizovaní uživatelé nemají povolen přístup ke zdroji a že byly provedeny následující konfigurace v konfiguračním souboru pdwebpi.conf. [common-modules] authentication = BA authentication = failover authentication = forms post-authzn = failover [authentication-levels] 1 = BA 2 = failover
Výše uvedená konfigurace udává tři politiky autentizace: BA (Základní autentizaci), autentizaci pomocí failover cookie a autentizaci pomocí formulářů s failover cookie, která bude také používána pro zpracování následující po autorizaci. Úrovně nastavené ve stanze [authentication-levels] určují pořadí, ve kterém budou politiky autentizace volány během autentizace požadavku. Autentizace pomocí formulářů je nastavena na úroveň 1, jelikož ve stanze [authentication-levels] nebyly nadefinovány žádné úrovně. S využitím výše uvedené konfigurace vyhledá plug-in program, který obdržel požadavek, failover cookie v hlavičce požadavku. Plug-in program hledá failover cookie dříve než data Základní autentizace, protože failover cookie je uvedena na úrovni 2 ve stanze [authentication-levels]. Stanza [authentication-levels] má přednost před pořadím definic modulů autentizace ve stanze [common-modules]. Plug-in program se zeptá: ″Mohu autentizovat tento požadavek pomocí failover cookie?″ Pokud nebyl požadavek již dříve autentizován, pak je odpověď ne, jelikož plug-in program dosud nevytvořil failover cookie pro daný požadavek. Plug-in program si položí druhou otázku: ″Mohu vygenerovat požadavek na autentizaci pomocí failover cookie?″ Odpověď je ne, protože modul pro failover cookie nemůže žádným způsobem vygenerovat požadavky na autentizaci. Plug-in program se přesune k další nakonfigurované politice autentizace ve stanze [authentication-levels], což je v tomto příkladě BA (Základní autentizace). Plug-in program se zeptá: ″Mohu autentizovat tento požadavek pomocí hlavičky BA?″ Odpověď je ne, jelikož požadavek dosud nebyl nikdy autentizován. Plug-in program si položí další otázku: ″Mohu vygenerovat požadavek na autentizaci pomocí BA?″ Odpověď pravděpodobně zní ano, a uživatel je vyzván, aby zadal své ID uživatele a heslo. Výsledkem úspěšné autentizace je
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
45
autorizovaná relace a do hlavičky požadavku se vloží failover cookie a použije se jako první politika autentizace pro následující požadavky během stejné relace. Pokud by nebyl modul BA (Základní autentizace) schopen vygenerovat způsob, jak autentizovat uživatele, plug-in program by se obrátil na pořadí politik vypsané ve stanze [common-modules] konfiguračního souboru. Ve výše uvedeném příkladě konfigurace by plug-in přiřadil prioritu politikám autentizace následujícím způsobem: úroveň 1 = BA (Základní autentizace), autentizace pomocí formulářů úroveň 2 = autentizace pomocí failover cookie Pokud by se nepodařilo ani s pomocí failover cookie, ani s pomocí BA autentizovat uživatele, plug-in program by se pokusil o autentizaci pomocí formulářů.
46
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Níže uvedený vývojový diagram zobrazuje logiku, pomocí které plug-in program vybírá modul autentizace.
Obrázek 2. Vývojový diagram, jak plug-in program určuje modul autentizace.
Plug-in program volá každý modul autentizace v pořadí, ve kterém jsou tyto moduly nakonfigurovány, dokud jeden z těchto modulů nevrátí pověření pro uživatele. Pokud žádný z nakonfigurovaných modulů autentizace není schopen vygenerovat pověření, je uživateli odeslána výzva k autentizaci a uživatel je vyzván, aby zadal informace o autentizaci. Je-li potřebné použít výzvu k autentizaci, pak se použije první vhodný modul autentizace z nakonfigurovaného seznamu modulů, aby vygeneroval nezbytné příkazy pro vytvoření této výzvy. Ne všechny moduly autentizace mohou vygenerovat výzvu. Například neexistuje žádná výzva, která by mohla požádat o HTTP hlavičky — ty jsou buď v požadavku, nebo ne. Navíc nemusí být modul autentizace dostupný, protože se v dané chvíli používá k identifikaci agenta proxy, který přeposílá požadavky na plug-in program. Většinou nejčastěji používané mechanismy autentizace, které mohou vygenerovat výzvu pro uživatele, jsou Základní autentizace (výzva BA se odešle přímo uživateli) a autentizace založená na formulářích (uživateli se pošle přihlašovací formulář). Pokud není k dispozici žádná politika autentizace, uživatele není možné autentizovat a plug-in program vrátí stránku, oznamující, že přístup byl odepřen. Níže uvedený vývojový diagram zobrazuje proces, podle kterého se vybírá politika autentizace, která má odeslat uživateli výzvu k autentizaci. Každá z nakonfigurovaných politik autentizace se vyzkouší v pořadí, ve kterém byly tyto politiky nakonfigurovány, dokud některá z nich nesplní požadovanou úroveň autentizace. Pokud se podaří nalézt modul, který splňuje kritéria pro autentizaci, je tento modul vyvolán, aby vytvořil výzvu, která bude odeslána uživateli. Pokud žádná z nakonfigurovaných politik autentizace není vhodná, pak není možná žádná autentizace. Plug-in program vrátí uživateli stránku s oznámením, že přístup byl odepřen, neboť uživatel neměl dostatečná oprávnění, nezbytná pro přístup k požadovanému zdroji a protože neexistuje žádná možnost, jak mu poslat výzvu k autentizaci na požadované úrovni.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
47
Obrázek 3. Vývojový diagram logiky výzvy k autentizaci.
Konfigurace zpracování následujícího po autorizaci Nakonfigurované moduly pro zpracování následující po autorizaci se volají poté, co byl požadavek autorizován. Moduly pro zpracování následující po autorizaci určují, zda je nutné provést nějakou další akci, než bude požadavek předán zpět plug-in programu ke zpracování webovým serverem. Všechny nakonfigurované moduly pro zpracování následující po autorizaci jsou volány, aby se určilo, zda by některý z nich neměl s požadavkem provést nějakou akci. Moduly pro zpracování následující po autorizaci je možné zařadit do jedné z následujících kategorií: v modifikace požadavku pro SSO — Tyto moduly pro zpracování následujícího po autorizaci přidají informace (cookies nebo hlavičky), které používají webové aplikace k identifikaci uživatele, aniž by byla nutná další autentizace. v modifikace odpovědí — Tyto moduly zpracování následujícího po autorizaci obvykle upravují odpovědi tak, že k nim přidají hlavičky nebo cookies. Například failover modul přidá do odpovědi failover cookie. v speciální funkce — Tyto moduly zpracování následujícího po autorizaci uznávají požadované URI jako spouštěcí impuls pro nějakou speciální funkci. Speciální funkce znamená, že požadavek bude obsloužen plug-in programem. Příkladem je ″vouch for″ požadavek při jednotném přihlášení pomocí e-community. Moduly zpracování následujícího po autorizaci se volají v tom pořadí, v jakém jsou uvedeny v konfiguračním souboru. Moduly zpracování následujícího po autorizaci, které jsou uvedeny
48
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
″dále″ v seznamu, mají možnost zrušit nebo přepsat změny, které byly provedeny dřívějšími moduly zpracování následujícího po autorizaci. Následující konfigurace může například způsobit rozdílné chování plug-in programu, a to v závislosti na pořadí parametrů BA a forms uvedeném ve stanze [common-modules]. [common-modules] ... post-authzn = BA post-authzn = forms [BA] ... strip-hdr = always [forms] ... create-ba-hdr = yes
Výše uvedená konfigurace je jednoduchým příkladem, jak pružná je konfigurace pomocí pořadí modulů zpracování následujícího po autorizaci a konfigurace modulů.
Správa stavu relace Informace o stavu relace používá plug-in program k identifikaci zdroje příchozích požadavků. Plug-in program používá totožnost zdroje požadavku, aby spravoval stav relace mezi klientem a serverem, zatímco klient provádí různé požadavky v rámci jedné relace. Bez nastavení stavu relace mezi klientem a serverem by musela být znovu vytvořena komunikace mezi klientem a serverem pro každý následující požadavek. Informace o stavu relace zlepšují výkonnost a eliminují potřebu opakovat autentizaci. Klient se může přihlásit jednou a provést množství požadavků, aniž by byl nucen se samostatně přihlásit při každém požadavku. Produkt Tivoli Access Manager Plug-in for Web Servers obsluhuje jak HTTP, tak i HTTPS komunikaci. Plug-in program je navržen tak, aby používal jakýkoliv z následujících typů informací pro udržování stavu relace s klientem: 1. ID relace SSL 2. Základní autentizace 3. cookie relace specifické pro server 4. data HTTP hlavičky 5. IP adresa 6. LTPA cookies 7. IV hlavičky Plug-in program volá jednotlivé nakonfigurované moduly relací jeden po druhém. Plug-in pokračuje ve vyhledávání nakonfigurovaných typů modulů relací, dokud jeden z nich nevrátí pověření. Plug-in program pak určí, zda se aplikace odkazuje na agenta Multiplexing Proxy Agent. Pokud to je Proxy Agent, pak pro skutečného koncového uživatele musí existovat ještě jiná relace. Protože musí plug-in program najít tuto další relaci, pokračuje ve volání ostatních nakonfigurovaných modulů relace. Pověření klienta se vrátí, pokud je nalezena již existující relace, pro kterou je již uživatel autentizován. Toto pověření se použije, aby byl požadavek autorizován. Pokud žádný z nakonfigurovaných modulů relace nevrátí pověření uživatele, je
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
49
relace buď nová, nebo jde o relaci, pro kterou nebylo vytvořeno žádné pověření.
Obrázek 4. Vývojový diagram, jak plug-in program určuje modul relace.
Konfigurace paměti cache pro relace/pověření plug-in programu Paměť cache pro relace umožňuje serveru ukládat informace o ID relace od několika klientů. Paměť cache obsahuje informace o stavu relace jak HTTP, tak i HTTPS. Paměť cache plug–in programu ukládá informace o ID relace plus informace o pověření, které byly získány pro každého klienta. Informace o pověření jsou ukládány do paměti cache, aby byly eliminovány opakující se dotazy do databáze registru uživatelů během kontrol autorizace. Paměť cache plug-in programu také udržuje informace o stavu relace pro SSL spojení mezi plug-in programem a registrem uživatelů LDAP. Paměť cache plug-in programu má několik konfiguračních parametrů, které vám umožňují vyladit výkonnost paměti cache. Poznámka: Hodnoty, které jsou nakonfigurovány ve stanze [sessions] konfiguračního souboru pdwebpi.conf, je možné přepsat ve stanze [jméno-modulu], ale některé je možné také přepsat ve stanze [jméno-modulu:jméno-virtuálního-hostitele] na úrovni jednotlivých virtuálních hostitelů.
Nastavení hodnoty maximálního počtu souběžných záznamů Parametr max-entries ve stanze [sessions] konfiguračního souboru pdwebpi.conf nastavuje maximální počet souběžných záznamů v paměti cache pro relace/pověření každého modulu relace. Tato hodnota odpovídá maximálnímu počtu souběžných relací přihlášení pro určitý modul relace. Když velikost paměti cache dosáhne této hodnoty, záznamy se z paměti cache vymažou podle toho, který byl nejdéle nepoužíván, aby bylo možné přijímat nová přihlášení. Předvolený počet souběžných relací přihlášení je 4096:
50
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
[sessions] max-entries = 4096
Nastavení časového limitu záznamu paměti cache Parametr timeout ve stanze [sessions] konfiguračního souboru pdwebpi.conf nastavuje časový limit maximální doby trvání záznamu v paměti cache pro relace/pověření plug-in programu. Plug-in program vnitřně ukládá do paměti cache informace o pověření. Parametr časového limitu paměti cache pro relace určuje dobu, po kterou informace o autorizačním pověření zůstává v paměti. Parametr není časový limit nečinnosti. Hodnota se spíše vztahuje k ″době trvání pověření″, než k ″časovému limitu pověření″. Jejím účelem je zvýšit zabezpečení tak, že uživatel bude nucen se znovu autentizovat, až uplyne uvedený časový limit. Předvolená hodnota časového limitu relace pro přihlášení (ve vteřinách) je 3600: [sessions] timeout = 3600
Můžete nakonfigurovat, aby byla znovu nastavena doba trvání záznamu v paměti cache pro relace pokaždé, když se vyskytne potřeba pro opětovnou autentizaci. Pokaždé, kdy se vyskytne opětovná autentizace, hodnota parametru timeout paměti cache pro relace se znovu nastaví. Pokud chcete nakonfigurovat, aby se doba trvání záznamu v paměti cache pro relace znovu nastavovala, použijte parametru reauth-lifetime-reset ve stanze [sessions] konfiguračního souboru pdwebpi.conf: [sessions] reauth-lifetime-reset = yes
Předvolená hodnota je no. Může se stát, že hodnota doby trvání záznamu v paměti cache pro relace bude překročena, zatímco uživatel provádí opětovnou autentizaci. Doba trvání záznamu v paměti cache pro relace může být překročena po odeslání formuláře pro přihlášení uživateli během procesu opětovné autentizace, a dříve, než je vyplněný formulář pro přihlášení vrácen. Pokud bude překročena doba trvání záznamu v paměti cache pro relace, záznam je z paměti cache pro relace vymazán. Pokud se plug-in programu vrátí formulář pro přihlášení, již pro tohoto uživatele neexistuje žádná relace. Navíc jsou všechny požadavky uživatele uložené do paměti cache ztraceny. Můžete nakonfigurovat časové rozšíření, nebo ″odklad″ pro dobu trvání záznamu v paměti cache pro relace, aby doba trvání záznamu v paměti cache pro relace nebyla během opětovné autentizace překročena. Parametr reauth-grace-period ve stanze [sessions] konfiguračního souboru pdwebpi.conf definuje toto časové rozšíření ve vteřinách. Například: [reauthentication] reauth-grace-period = 20
Předvolená hodnota 0 nedovoluje žádné rozšíření doby trvání záznamu v paměti cache pro relace. Parametr reauth-grace-period se použije u uživatelů, kteří mají již existující záznamy v paměti cache pro relace a kteří se musí opětovně autentizovat. Například: v uživatelé, kteří provádějí opětovnou autentizaci, požadovanou bezpečnostní politikou POP v uživatelé, kteří provádějí opětovnou autentizaci, požadovanou z důvodu nečinnosti paměti cache relace v uživatelé, kteří provádějí zvýšenou autentizaci Volba reauth-grace-period by se měla používat spolu s volbou reauth-lifetime-reset = yes. Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
51
Nastavení časového limitu nečinnosti záznamu v paměti cache Parametr inactive-timeout ve stanze [sessions] konfiguračního souboru pdwebpi.conf nastavuje časový limit pro nečinnost relace pro přihlášení. Předvolený časový limit nečinnosti relace pro přihlášení (ve vteřinách) je 600: [sessions] inactive-timeout = 600
Pokud chcete zablokovat tuto funkci časového limitu, nastavte parametr na hodnotu 0.
Udržování stavu relace pomocí ID relace SSL Produkt Tivoli Access Manager Plug-in for Web Servers může sledovat relace pomocí ID relací SSL příchozích požadavků HTTPS. Tato poskytovaná služba není dostupná na serveru IIS, neboť tento server nedává ID relací SSL k dispozici plug-in programu. Poznámka: ID relací SSL se nepoužívají k autentizaci požadavků. Stanza [common-modules] konfiguračního souboru pdwebpi.conf definuje použití všech relací, modulů pro autentizaci a modulů zpracování následujícího po autorizaci ve formátu typ-modulu = jméno-modulu. Chcete-li udržovat stav relace pomocí ID relací SSL, přiřaďte slovo ssl-id parametru session, podobně jako je tomu v následujícím příkladu: [common-modules] session = ssl-id
Ujistěte se, že je sdílená knihovna pro ssl-id nakonfigurována ve stanze [modules] konfiguračního souboru pdwebpi.conf. To znamená: [modules] ssl-id = pdwpi-sslsessid-module
Udržování stavu relace pomocí Základní autentizace Základní autentizace (BA - Basic Authentication) je politika, která provádí autentizaci uživatelů a udržuje stav relace pomocí vstupu obsahujícího jméno uživatele a heslo. BA je definována pomocí protokolu HTTP a může být naimplementována jak pro protokol HTTP, tak i pro protokol HTTPS. Základní autentizace udržuje stav relace tak, že ukládá do paměti cache záznam s hlavičkou Základní autentizace. Chcete-li nakonfigurovat plug-in program tak, aby udržoval stav relace pomocí Základní autentizace, použijte stanzu [common-modules] konfiguračního souboru pdwebpi.conf. Zadejte parametr session s hodnotou BA, jak je uvedeno v následujícím příkladu: [common-modules] session = BA
Pokud se BA používá k udržování stavu relace, musí být také používána pro autentizaci uživatele. Stanza [common modules] konfiguračního souboru by měla být také nastavena, aby BA byla používána pro autentizaci. [common-modules] session = BA authentication = BA
Varování zabezpečení: Pokud k identifikaci relace použijete autorizační hlavičku Základní autentizace, může to vystavit uživatele webového serveru neomezeným pokusům o napadení hesla.
52
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
To je omezení schématu HTTP Základní autentizace, které v hlavičce autorizace zahrnuje heslo uživatele. Standardně není produkt Tivoli Access Manager Plug-in for Web Servers povolen. Schopnost identifikace relace pomocí Základní autentizace je poskytována administrátorům, kteří jsou informováni o všech rizicích zabezpečení vztahujících se k použití Základní autentizace. Identifikaci relace pomocí Základní autentizace lze bezpečně použít, když webový server zabezpečený plug-in programem funguje za znásobujícím proxy agentem (například za spojením WebSEAL), který používá Základní autentizace, aby se autentizoval pro plug-in program. V situaci, kdy znásobující proxy agent nepostupuje plug-in programu autorizační hlavičky Základní autentizace od uživatelů, je napadení nemožné.
Udržování stavu relace pomocí cookies relace Používání cookies relace pro udržování informací o relaci je jedním ze způsobů, jak udržovat stav relace plug-in programu. Server zabalí informace o stavu určitého klienta do cookie a odešle je prohlížeči klienta. Pro každý nový požadavek prohlížeč sám sebe opětovně identifikuje tak, že odešle cookie (s informací o relaci) zpět na server. Cookies relací nabízí možné řešení v situacích, kdy klient používá prohlížeč, který znovu sjednává SSL relaci po uplynutí velmi krátkého časového intervalu. Například některé verze prohlížeče Microsoft Internet Explorer znovu sjednávají SSL relace každé dvě až tři minuty. Cookie relace poskytuje opětovnou autentizaci klienta pouze pro ten server, u kterého byl klient nedávno autentizován (cca během posledních deseti minut). Mechanismus je založen na tom, že ″cookie serveru″ nemůže být předána žádnému jinému počítači, než tomu, který vygeneroval cookie. Navíc cookie relace obsahuje pouze identifikátor s náhodným číslem, který se používá k indexaci jednotlivých cookie v paměti cache pro relace na serveru — v cookie relace nejsou uvedeny žádné další informace. Cookie relace nemůže ohrozit bezpečnostní politiku. Produkt Tivoli Access Manager Plug-in for Web Servers používá zabezpečenou cookie relace specifickou pro server. Pro mechanismus této cookie platí následující podmínky: v cookie obsahuje pouze informace o relaci a neobsahuje informace o totožnosti v cookie zůstává pouze v paměti prohlížeče (a není zapsána do souboru jar pro cookie prohlížeče, který je na disku) v cookie má omezenou dobu trvání (konfigurovatelnou) v cookie má parametry pro cestu a doménu, které nedovolují, aby byla použita jinými servery Chcete-li nakonfigurovat plug-in program, aby používat cookie relací k udržování stavu relace, použijte stanzu [common-modules] konfiguračního souboru pdwebpi.conf. Zadejte parametr session s hodnotou session-cookie, jak je uvedeno v následujícím příkladu: [common-modules] session = session-cookie
Parametr resend-pdwebpi-cookies ve stanze [sessions] konfiguračního souboru pdwebpi.conf dovoluje nebo zakazuje posílání cookie relací prohlížeči při každé odpovědi. Tato akce pomáhá zajistit, že cookie relace zůstává v paměti prohlížeče. Parametr resend-pdwebpi-cookies je standardně nastaven na hodnotu no: [sessions] resend-pdwebpi-cookies = no
Chcete-li posílat cookies relace plug-in programu při každé odpovědi, nastavte tento parametr na hodnotu yes. Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
53
Udržování stavu relace pomocí HTTP hlaviček Produkt Tivoli Access Manager Plug-in for Web Servers může být nakonfigurován tak, aby používal informace v HTTP hlavičkách k identifikaci relací a udržování stavu relací. Plug-in program může používat HTTP hlavičky pro sledování relací, stejně jako pro autentizaci uživatelů. Je-li plug-in program nakonfigurován tak, aby používal HTTP hlavičky ke sledování relací, pak musí být také nakonfigurován tak, aby používal HTTP hlavičky k autentizaci uživatelů. Avšak pokud máte plug-in program nakonfigurován tak, aby autentizoval příchozí požadavky pomocí HTTP hlaviček, není nezbytné, aby plug-in program byl nakonfigurován, aby sledoval relace. Podrobné informace o konfiguraci plug-in programu tak, aby používal HTTP hlavičky pro autentizaci klientů najdete v části “Konfigurace autentizace pomocí HTTP hlaviček” na stránce 95. Pokud chcete používat HTTP hlavičky k udržování stavu relace, stanza[common-modules] konfiguračního souboru pdwebpi.conf musí mít následující záznamy: [common-modules] authentication = http-hdr session = http-hdr
Standardní konfigurace HTTP hlaviček povoluje, aby byla uvedena pouze jedna hlavička, například: [modules] http-hdr = pdwpi-httphdr-module
Pokud chcete uvést více HTTP hlaviček, musíte nakonfigurovat více instancí modulu HTTP hlaviček. Například: [modules] entrust-client-header = pdwpi-httphdr-module some-other-header = pdwpi-httphdr-module [entrust-client-header] header = entrust-client [some-other-header] header = some-other
Udržování stavu relace pomocí IP adres Produkt Tivoli Access Manager Plug-in for Web Servers může používat IP adresy k identifikaci a sledování relací. Chcete-li nakonfigurovat plug-in program, aby používal IP adresy ke sledování relací, použijte stanzu [common-modules] v konfiguračním souboru pdwebpi.conf. Zadejte parametr session s hodnotou ip-addr. To znamená: [common-modules] session = ip-addr
Ujistěte se, že ve stanze [modules] konfiguračního souboru pdwebpi.conf je nakonfigurována sdílená knihovna pro autentizaci pomocí IP adres. To znamená: [modules] ip-addr = pdwpi-ipaddr-module
Pokud se IP adresy používají k udržování stavu relace, musí být také používány k autentizaci příchozích požadavků. Podrobné informace o tom, jak nakonfigurovat produkt Tivoli Access Manager Plug-in for Web Servers, aby používal IP adresy jako politiku pro autentizaci klientů
54
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
najdete v části “Konfigurace autentizace pomocí IP adresy” na stránce 96. Používání IP adres pro autentizaci klientů však nevyžaduje, aby byly IP adresy používány jako politika pro identifikaci relací.
Udržování stavu relace pomocí LTPA cookies Autentizaci pomocí LTPA je možné použít pro přijímání LPTA cookie a pro autentizaci založenou na těchto cookies. Autentizace pomocí LTPA může spravovat stav relace pomocí LTPA cookie, která je v každém požadavku HTTP. Chcete-li nakonfigurovat plug-in program, aby udržoval stav relace pomocí LTPA cookies, použijte stanzu [common-modules] konfiguračního souboru pdwebpi.conf. Zadejte parametr session s hodnotou ltpa, jak je uvedeno v následujícím příkladu: [common-modules] session = ltpa
Pokud používáte autentizaci pomocí LTPA cookies k udržování stavu relace, musíte ji také používat pro autentizaci uživatelů. Stanza [common-modules] konfiguračního souboru by měla být nastavena pro autentizaci pomocí LTPA cookies. [common-modules] authentication = ltpa session = ltpa
Udržování stavu relace pomocí IV hlaviček Produkt Tivoli Access Manager Plug-in for Web Servers může ukládat informace v IV hlavičkách do paměti cache, aby zlepšil výkonnost systému. Stanza [common-modules] konfiguračního souboru pdwebpi.conf definuje použití všech relací, modulů pro autentizaci a modulů zpracování následujícího po autorizaci ve formátu typ-modulu = jméno-modulu. Chcete-li ukládat informace v IV hlavičkách do paměti cache, přiřaďte parametru session hodnotu iv-headers, jak je uvedeno v následujícím příkladu: [common-modules] session = iv-headers
Ujistěte se, že ve stanze [modules] konfiguračního souboru pdwebpi.conf je nakonfigurována sdílená knihovna pro IV hlavičky. To znamená: [modules] iv-headers = pdwpi-iv-headers-module
Přehled konfigurace autentizace Jak bylo ukázáno v části “Konfigurace autentizace” na stránce 41, moduly autentizace provádějí proces vyjmutí informací o autentizaci z požadavků. Skutečná autentizace požadavků je prováděna mechanismem autentizace, který potvrdí informace o autentizaci. Rozdělení úloh mezi moduly autentizace a mechanismus autentizace dovoluje, aby spolu s plug-in programem byly používány přizpůsobené knihovny CDAS napsané pro server WebSEAL. Mechanismy pro všechny politiky autentizace, podporované produktem Tivoli Access Manager Plug-in for Web Servers, jsou nakonfigurovány ve stanze [authenticationmechanisms] konfiguračního souboru pdwebpi.conf. Parametry podporovaných politik autentizace zahrnují: v lokální (zabudované) autentizátory Parametry pro lokální autentizátory určují odpovídající zabudované sdílené knihovny (UNIX) nebo soubory DLL (Windows).
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
55
v uživatelské externí autentizátory Plug-in program nabízí kód serveru se šablonami, který můžete použít k vytvoření a specifikaci uživatelského externího CDAS serveru (Cross Domain Authentication Service). Externí CDAS autentizátor určuje odpovídající uživatelskou sdílenou knihovnu. Poznámka: Na rozdíl od konfigurace stanzy [modules], při konfiguraci mechanismů do stanzy [authentication-mechanisms] přidávejte úplné jméno souboru. To znamená včetně prefixu souboru a přípony specifické pro daný operační systém.
Mechanismus lokální autentizace Následující parametry mechanismu autentizace určují lokální zabudované autentizátory: Tabulka 10. Lokální zabudované autentizátory. Parametr
Popis
Autentizace pomocí formulářů a Základní autentizace passwd-ldap
Přístup klienta pomocí jména uživatele a hesla LDAP.
Autentizace pomocí certifikátu klienta cert-ssl
Přístup klienta pomocí certifikátu klienta přes SSL.
Autentizace pomocí HTTP hlaviček, pomocí IP adres, pomocí IV hlaviček s aktivovaným parametrem iv-remote-address http-request
Přístup klienta pomocí speciální HTTP hlavičky, IP adresy, nebo IV hlavičky s aktivovaným parametrem iv-remote-address.
Ke konfiguraci politiky a implementace autentizace použijte stanzu [authenticationmechanisms] v následujícím tvaru: parametr-politiky-autentizace = sdílená-knihovna
Parametry externí uživatelské autentizace CDAS Chcete-li zadat uživatelské sdílené knihovny pro externí servery CDAS, můžete použít následující parametry: Tabulka 11. Parametry externího serveru CDAS. Parametr
Popis
passwd-cdas
Přístup klienta pomocí jména uživatele a hesla pro registr třetí strany.
token-cdas
Přístup klienta pomocí jména uživatele a token passcode LDAP.
cert-cdas
Přístup klienta pomocí certifikátu klienta přes SSL.
Kromě autentizačních knihoven jsou k dispozici dvě další standardní knihovny produktu Tivoli Access Manager, které je možné používat v plug-in programu: v passwd-strength Tato knihovna kontroluje nová hesla, která byla zadána na formuláři pro změnu hesla. v cred-ext-attrs Tato knihovna umožňuje, aby byly zadány uživatelské atributy (páry jméno/hodnota), které budou zahrnuty do pověření. Podrobné informace o vytváření a konfiguraci uživatelské sdílené knihovny, pomocí které je možné naimplementovat server CDAS, najdete v knize IBM Tivoli Access Manager for Developer’s Reference.
56
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Přednastavená konfigurace plug-in programů Standardně je plug-in program nastaven tak, aby autentizoval klienty pomocí jmen uživatelů a hesel Základní autentizace (BA - Basic Authentication), která využívá registru LDAP. Plug-in program obvykle umožňuje přístup jak přes protokol TCP, tak i přes protokol SSL. Z tohoto důvodu typická konfigurace stanzy [authentication-mechanisms] obsahuje podporu pro jméno uživatele a heslo (registr LDAP) a podporu pro certifikáty klienta přes SSL. Následující příklad představuje typickou konfiguraci stanzy [authentication-mechanisms] pro operační systém Solaris: [authentication-mechanisms] passwd-ldap = libldapauthn.so cert-ssl = pdwpi-sslauthn.so
Chcete-li nakonfigurovat další politiky autentizace, přidejte odpovídající parametr spolu s jeho sdílenou knihovnou (nebo modulem CDAS).
Konfigurace několika politik autentizace Chcete-li, aby byla sdílená knihovna používána libovolnou podporovanou politikou autentizace, změňte stanzu [authentication-mechanisms] konfiguračního souboru pdwebpi.conf. Následující podmínky platí tehdy, nakonfigurujete-li několik politik autentizace: 1. Všechny politiky autentizace mohou pracovat nezávisle jedna na druhé. Sdílenou knihovnu je možné nakonfigurovat pro každou z podporovaných politik. 2. Politika cert-cdas vyřadí politiku cert-ssl, pokud jsou obě nakonfigurovány. Musíte povolit jednu z těchto politik, abyste podporovali certifikáty klienta. 3. Ve skutečnosti se používá pouze jeden autentizátor typu heslo, i když je nakonfigurován více než jeden. Plug-in program používá následující pořadí priorit, aby vyřešil problém s několika nakonfigurovanými autentizátory typu heslo: a. passwd-cdas b. passwd-ldap 4. Je možné nakonfigurovat stejnou uživatelskou knihovnu pro dvě rozdílné politiky autentizace. Například můžete napsat uživatelskou sdílenou knihovnu, která bude zpracovávat jak autentizaci pomocí jména uživatele/hesla, tak i pomocí HTTP hlaviček. V takovém případě byste měli nakonfigurovat jak parametr passwd-cdas, tak i parametr http-request ve stejné sdílené knihovně. Vývojář odpovídá za udržování stavu relace a vyvarování se konfliktů mezi těmito dvěma politikami.
Příkazy pro odhlášení, změnu hesla a nápovědu Produkt Tivoli Access Manager nabízí níže uvedené příkazy pro podporu klientů, kteří se autentizující pomocí HTTP nebo HTTPS.
pkmslogout Klienti mohou používat příkaz pkmslogout, aby se odhlásili ze stávající relace, pokud používají politiku autentizace, která nedodává autentizační data při každém požadavku. Pokud používají politiku autentizace, která dodává autentizační data při každém požadavku, pak příkaz pkmslogout vyčistí paměť cache pro relace, ale informace o pověření stále zůstávají v hlavičce požadavku. V takovém případě uživatel musí zavřít prohlížeč, aby se úplně odhlásil od relace. Příkaz pkmslogout je vhodný pro autentizaci pomocí token passcodes, autentizaci pomocí formulářů a některých implementací autentizace pomocí hlavičky HTTP.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
57
Příkaz spustíte následovně: https://www.tivoli.com/pkmslogout
Prohlížeč zobrazí formulář pro odhlášení, který je nadefinován v konfiguračním souboru pdwebpi.conf. [acctmgmt] logout-success = logout_success.html
Záznam logout-success může uvádět buď předdefinovaný HTML soubor (je uložen v základním adresáři instalační-adresář/nls/html/C) nebo URI. Uvedené URI může být buď relativní URO, nebo absolutní URI. Obslužný program pkmslogout dále podporuje vícenásobné stránky odpovědí z odhlášení, pokud architektura sítě vyžaduje, aby byly použity různé výstupní obrazovky pro uživatele, odhlašující se z výrazně odlišných virtuálních hostitelů.
pkmspasswd Tento příkaz můžete použít ke změně vašeho přihlašovacího hesla, které používáte při Základní autentizaci nebo autentizaci pomocí formulářů. Tento příkaz je vhodný pro HTTP a HTTPS. Například: https://www.tivoli.com/pkmspasswd
Prohlížeč zobrazí formulář pro změnu hesla, který je nadefinován v konfiguračním souboru pdwebpi.conf. [acctmgmt] password-change-form-uri = /pkmspasswd.form password-change-uri = /pkmspasswd password-change-success = password_change_success.html password-change-failure = password_change_failure.html
Soubory password_change_success.html a password_change_failure.html můžete změnit tak, aby odpovídaly vašim požadavkům.
pkmshelp Tento příkaz můžete použít, pokud chcete přistoupit ke stránkám s nápovědou. Tento příkaz je vhodný pro HTTP a HTTPS. Jméno a umístění stránek s nápovědou je nadefinováno v konfiguračním souboru pdwebpi.conf. [acctmgmt] help-uri = /pkmshelp help-page = help.html
Soubor help.html můžete změnit tak, aby odpovídal vašim požadavkům.
Konfigurace Základní autentizace Základní autentizace (BA - Basic Authentication) je standardní politikou, která předává jméno uživatele a heslo do mechanismu autentizace. BA je nadefinována pomocí protokolu HTTP a je implementována jak pro HTTP, tak i pro HTTPS.
58
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Aktivace Základní autentizace Standardně je plug-in program nakonfigurován tak, aby používal jméno uživatele a heslo BA. Stanza [common-modules] konfiguračního souboru pdwebpi.conf definuje použití BA pro požadavky na autentizaci. To znamená: [common-modules] authentication = BA
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že je zde uveden záznam pro Základní autentizaci, tj.: [modules] BA = pdwpi-ba-module
Standardně je mechanismu autentizace pomocí BA udělena úroveň jedna ve stanze [authentication levels] konfiguračního souboru. Toto nastavení se vztahuje k prioritě mechanismu autentizace pro příchozí požadavky.
Konfigurace mechanismu pro Základní autentizaci Parametr passwd-ldap určuje sdílenou knihovnu, která se bude používat k obsluze autentizace pomocí jména uživatele a hesla. v Na operačním systému UNIX je soubor, který poskytuje zabudované mapovací funkce, tzv. sdílená knihovna s názvem libldapauthn. v Na operačním systému Windows je soubor, který poskytuje zabudované mapovací funkce, tzv. DLL s názvem ldapauthn. Mechanismus autentizace pomocí jména uživatele a hesla můžete nakonfigurovat tak, že zadáte parametr passwd-ldap spolu se jménem sdílené knihovny specifickým pro danou platformu do stanzy [authentication-mechanisms] konfiguračního souboru pdwebpi.conf – tak, jako je uvedeno níže: Solaris: [authentication-mechanisms] passwd-ldap = libldapauthn.so
Windows: [authentication-mechanisms] passwd-ldap = ldapauthn.dll
Nastavení jména sféry Sféra se zobrazí v dialogu, který předloží prohlížeč uživateli, když ho vyzývá, aby zadal své jméno uživatele a heslo. Jméno sféry je přiřazeno v parametru basic-auth-realm ve stanze [BA] konfiguračního souboru pdwebpi.conf. [BA] basic-auth-realm = jméno-sféry
Práce s BA hlavičkami Plug-in program můžete nakonfigurovat tak, aby dodával chráněným aplikacím původní nebo upravené informace o totožnosti klienta tak, že bude řídit obsah BA hlaviček, které jsou posílány na webový server. Stávající hlavička, která je odesílán z klienta, může být: v odstraněna ze všech požadavků v odstraněna z neautentizovaných požadavků v ponechána nezměněná pro všechny požadavky
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
59
U klientů, kteří neposkytují BA hlavičku, nebo u hlaviček stávajících klientů již předaných na webový server, mohou informace v hlavičce: v být nastaveny na pevné jméno uživatele a heslo v mít nastaveno pevné heslo (předané jméno uživatele bude jméno autentizovaného uživatele) v být nastaveny pomocí informací z GSO produktu Tivoli Access Manager Plug-in program musí být nakonfigurován tak, aby dovoloval zpracování následující po autorizaci pomocí Základní autentizace, aby mohl pracovat s BA hlavičkami příchozích požadavků. Chcete-li zprovoznit tuto funkcionalitu, přidejte parametr post-authzn do stanzy [common-modules] konfiguračního souboru pdwebpi.conf a nastavte jej na hodnotu BA. To znamená: [common-modules] post-authzn = BA
Parametr strip-hdr dává pokyn plug-in programu, aby: Hodnota
Výsledek
ignore
Ponechat hlavičku tak, jak je. Plug-in program předá originální BA hlavičku klienta zdroji bez jakéhokoliv zásahu. To v podstatě znamená přímé přihlášení ke zdroji, zcela transparentní pro plug-in program, a to v případě, že chcete obejít autentizaci plug-in programu. Poznámky: 1. Tato volba teoreticky dovoluje, aby neautentizovaní uživatelé odesílali BA hlavičky na webový server. Tuto volbu byste měli používat pouze v případě, kdy si jste jisti, že ji potřebujete a že jste pochopili možné dopady na zabezpečení ochrany dat. 2. Je-li v plug-in programu nakonfigurována autentizace pomocí hlavičky BA a chráněný zdroj se pokusí autentizovat klienta pomocí vlastní výzvy Základní autentizace, pak nebude pověření uživatele akceptováno chráněným zdrojem. Jiný mechanismus, jako např. formuláře nakonfigurované v plug-in programu, obejdou původní hlavičku BA klienta a dostanou se ke zdroji bez dalšího zasahování.
always
Vždy odstranit informace z hlavičky Základní autentizace ze všech požadavků klientů, než budou tyto požadavky předány webovému serveru. V tomto případě se plug-in program stává jediným poskytovatelem zabezpečení. Pokud musíte webovému serveru dodat nějaké informace o klientovi, můžete použít tuto volbu s autentizací pomocí IV hlaviček a vložit informace o totožnosti klienta produktu Tivoli Access Manager do polí HTTP hlaviček. Poznámka: Pokud chráněný server odešle výzvu k autentizaci pomocí BA s aktivovanou touto volbou, klientovi se zobrazí rozevírací okno pro autentizaci, ale nebude se moci přihlásit, protože jeho odpověď bude vždy odstraněna.
unauth
BA hlavička obdržená od klienta se odstraní ze všech požadavků, s výjimkou těch uživatelů, kteří byli autentizováni plug-in programem pomocí Základní autentizace. Toto nastavení dovoluje, aby autentizovaní uživatelé odesílali autentizované BA hlavičky na webový server, ale brání v této činnosti neautentizovaným uživatelům.
Parametr add-hdr ve stanze [BA] konfiguračního souboru vám dovolí dodávat informace o totožnosti klienta v HTTP hlavičkách Základní autentizace. Dodávání informací o totožnosti klienta v HTTP hlavičkách Základní autentizace pomocí parametru add-hdr se vyskytuje po každém zpracování, které využívá funkcionalitu parametru strip-hdr. Parametr add-hdr může být nastaven na jednu z následujících hodnot: none, gso, nebo supply. v Je-li nastaven na hodnotu none, pak BA hlavička nebude přidána k požadavku.
60
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
v Je-li nastaven na hodnotu gso, pak se k požadavku přidá BA hlavička pro GSO — podrobné informace o konfiguraci plug-in programu pro GSO najdete v části “Používání globálního jednotného přihlášení (GSO - Global single sign-on)” na stránce 128. v Je-li nastaven na hodnotu supply, pak se do BA hlavičky přidá statické heslo a jméno uživatele. Tato statická hesla a jména uživatelů jsou nadefinována v parametrech supply-password a supply-username stanzy [BA] v konfiguračním souboru. Parametr supply-username může být nastaven na pevnou hodnotu jména uživatele. Pokud není nastaven parametr supply-username, pak se jméno uživatele v BA hlavičce vytvoří podle jména autentizovaného uživatele produktu Tivoli Access Manager. V takovém případě zdroj chráněný plug-in programem vyžaduje autentizaci podle totožnosti produktu Tivoli Access Manager. Je-li parametr add-hdr nastaven na hodnotu supply, a parametry supply-password a supply-username jsou nastaveny na nějaké hodnoty, pak se uvedené jméno uživatele a heslo použije ve všech požadavcích. Používání společného jména uživatele a hesla nenabízí aplikačnímu serveru žádnou možnost, aby prověřil pravost klienta, který se přihlásil s uvedeným jménem uživatele. Pokud klienti vždy prochází přes plug-in program, aby přistoupili ke zdroji, pak toto řešení nepředstavuje žádné problémy v zabezpečení. Je však důležité fyzicky zabezpečit zdroje před jinými způsoby přístupu. Jelikož tento scénář nemá žádné zabezpečení na úrovni hesla, zdroje chráněné plug-in programem musí implicitně důvěřovat plug-in programu, že ověří pravost klienta. Registr uživatelů musí dále rozeznávat totožnost produktu Tivoli Access Manager, aby ji mohl přijmout. Pokud není parametr supply-username nastaven, a uživatel není autentizován, pak k požadavku nebude přidána žádná BA hlavička.
Uvedení UTF-8 zakódování BA hlaviček Editujte konfigurační soubor plug-in programu. Uveďte, zda by měl či neměl plug-in program použít pro BA hlavičky UTF-8 zakódování. [BA] use-utf8 = true
Předvolená hodnota je true. Abyste získali další informace o podpoře plug-in programu pro UTF-8 zakódování, vyhledejte část “Podpora jazyků a znakové sady” na stránce 35.
Konfigurace autentizace pomocí formulářů Produkt Tivoli Access Manager nabízí autentizaci pomocí formulářů jako alternativu ke standardnímu mechanismu Základní autentizace. Tato politika vytváří uživatelský HTML formulář pro přihlášení z produktu Tivoli Access Manager namísto standardní výzvy k přihlášení, která je výsledkem výzvy Základní autentizace. Když se rozhodnete používat přihlášení založené na formulářích, prohlížeč nebude ukládat informace o jménu uživatele a hesle do paměti cache, jako to dělal u Základní autentizace.
Aktivace autentizace pomocí formulářů Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete aktivovat autentizaci pomocí formulářů, přiřaďte slovo forms k parametru authentication; to znamená: [common-modules] authentication = forms
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
61
Když používáte formuláře pro autentizaci, plug-in program musí být nakonfigurován tak, aby používal také formuláře pro zpracování následující po autorizaci. Tím umožníte plug-in programu přesměrovat autentizované uživatele zpět na originální URL požadavku. Ve stanze [common-modules] konfiguračního souboru pdwebpi.conf přidejte parametr pre-authzn následujícím způsobem: [common-modules] authentication = forms pre-authzn = forms
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že je zde uveden záznam pro formuláře, tj.: [modules] forms = pdwpi-forms-module
Konfigurace mechanismu pro autentizaci pomocí formulářů Parametr passwd-ldap určuje sdílenou knihovnu, která se bude používat k obsluze autentizace pomocí jména uživatele a hesla. v Na operačním systému UNIX je soubor, který poskytuje zabudované mapovací funkce, tzv. sdílená knihovna s názvem libldapauthn. v Na operačním systému Windows je soubor, který poskytuje zabudované mapovací funkce, tzv. DLL s názvem ldapauthn. Mechanismus autentizace pomocí jména uživatele a hesla můžete nakonfigurovat tak, že zadáte parametr passwd-ldap spolu se jménem sdílené knihovny specifickým pro danou platformu do stanzy [authentication-mechanisms] konfiguračního souboru pdwebpi.conf tak, jako je uvedeno níže: Solaris: [authentication-mechanisms] passwd-ldap = libldapauthn.so
Windows: [authentication-mechanisms] passwd-ldap = ldapauthn.dll
Přizpůsobení HTML formulářů s odpovědí Autentizace pomocí formulářů vyžaduje, abyste používali uživatelský formulář pro přihlášení. Standardně je vzorový formulář login.html umístěn v adresáři: instalačnícesta/nls/html/jazyk/znaková sada. Kde parametr jazyk je nastaven podle NLS konfigurace. Na systémech US English je adresář jazyk nazýván C a znaková sada je utf-8. Parametr login-form ve stanze [forms] konfiguračního souboru definuje jméno souboru formuláře, který bude předložen uživateli během jeho přihlášení. Cesta k souboru by měla být relativní k přeloženému pdwebpi HTML adresáři, např. pdwebpi/nls/html/jazyk/znaková sada. [forms] login-form = login.html
Poznámka: Odstranění pole wpi_url z formuláře login.html způsobí, že data pro POST zadaná s formulářem přihlášení budou v HTTP požadavku dostupná jako proměnné dat pro POST. To zahrnuje použití jména uživatele a hesla pro přihlášení k produktu Tivoli Access Manager. Také odstranění pole wpi_url z
62
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
formuláře zablokuje funkcionalitu ukládání do paměti cache a makra všech dat pro POST stejně tak, jako že nebude dále podporován %POST_URL%.
Přizpůsobení URI přihlášení pomocí formulářů Na jednom virtuálním hostiteli je možné používat více instancí modulu pro přihlášení pomocí formulářů. Pro takové instance je nezbytně nutné změnit URI uvedené v POST, jakmile je podán formulář pro přihlášení pro každou z uvedených instancí modulu přihlášení pomocí formulářů. Toto URI řídí parametr login-uri ve stanze [forms]. Je-li tento parametr změněn z předvolené hodnoty, pak musí být aktualizován formulář uvedený v parametru login-form (viz “Přizpůsobení HTML formulářů s odpovědí” na stránce 62), aby zohlednil uvedenou změnu.
Vytvoření BA hlavičky Autentizace pomocí formulářů nabízí možnost vytvořit BA hlavičku podle jména uživatele a hesla, zadaných ve formuláři pro přihlášení. Vytvoření hlavičky umožňuje jednoduchý mechanismus pro jednotné přihlášení, který je možné použít v případech, kdy aplikace typu back-end vyžadují Základní autentizaci, a kdy jméno uživatele a heslo odpovídá hodnotám, které používá produkt Tivoli Access Manager. Vytvoření hlavičky BA je používáno po-autorizační modul formulářů. Do stanzy [common-modules] konfiguračního souboru plug-in programu přidejte záznam pro zpracování formulářů následující po autorizaci: [common-modules] post-authzn = forms
Parametr create-ba-hdr ve stanze [forms] konfiguračního souboru povoluje nebo zakazuje vytváření BA hlaviček, například: [forms] create-ba-hdr = yes
Autentizace pomocí formulářů standardně nevytváří hlavičku BA - parametr create-ba-hdr je nastaven na no. Bez ohledu na nastavení tohoto parametru se BA hlavička nevytvoří, pokud se uživatel úspěšně neautentizoval. Hlavička se také nevytvoří v případě, že heslu uživatele skončila platnost. Poznámka: Pokud další modul, uvedený v seznamu post-authzn za modulem pro formuláře, přepíše BA hlavičku (nebo ji odstraní), pak tato funkce nebude fungovat. Doporučujeme, abyste modul pro formuláře uvedli na posledním místě v seznamu post-authzn.
Uvedení UTF-8 zakódování BA hlaviček Editujte konfigurační soubor plug-in programu.Uveďte, zda by měl či neměl plug-in program použít pro BA hlavičky UTF-8 zakódování. [forms] use-utf8 = true
Předvolená hodnota je true. Abyste získali další informace o podpoře plug-in programu pro UTF-8 zakódování, vyhledejte část “Podpora jazyků a znakové sady” na stránce 35.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
63
Konfigurace autentizace pomocí certifikátů Produkt Tivoli Access Manager Plug-in for Web Servers podporuje bezpečnou komunikaci s klienty pomocí digitálních certifikátů klienta předávaných přes protokol SSL. V této politice autentizace se certifikační informace (jako např. rozlišovací jméno (DN - Distinguished Name) namapují na totožnost produktu Tivoli Access Manager.
Vzájemná autentizace pomocí certifikátů Autentizace pomocí digitálních certifikátů se provádí ve dvou fázích: v Webový server, na kterém je umístěn plug-in program, identifikuje sám sebe vzhledem ke klientům SSL s pomocí certifikátu serveru. v Webový server použije svou databázi kořenových certifikátů vydavatele certifikátu (CA), aby ověřil klienty, kteří k němu přistupují pomocí certifikátů klienta. Probíhají následující procesy: 1. SSL klient žádá o připojení k webovému serveru přes plug-in program. 2. Jako svou odpověď odešle webový server svůj veřejný klíč prostřednictvím podepsaného certifikátu serveru. Tento certifikát byl již dříve podepsán ověřeným vydavatelem certifikátů třetí strany. 3. Klient ověří, zda vydavatel certifikátu je ten, kterému může věřit a kterého může přijmout. Prohlížeč klienta obvykle obsahuje seznam kořenových certifikátů od ověřených vydavatelů certifikátů. Pokud podpis na certifikátu webového serveru odpovídá některému z kořenových certifikátů, pak je možné server považovat za ověřený. 4. Pokud není nalezena shoda mezi podpisy, prohlížeč informuje svého uživatele, že tento certifikát byl vydán neznámým vydavatelem certifikátů. Pak je na odpovědnosti uživatele, zda přijme nebo odmítne certifikát. 5. Pokud podpis odpovídá některému ze záznamů v databázi kořenových certifikátů prohlížeče, klíče relace jsou bezpečně projednány mezi klientem a webovým serverem. Výsledkem tohoto procesu je bezpečný kanál, přes který se může klient autentizovat (například pomocí jména uživatele a hesla). Po úspěšné autentizaci mohou klient a server pokračovat v bezpečné komunikaci přes tento kanál. 6. Nyní klient odesílá svůj certifikát s veřejným klíčem přes plug-in program webovému serveru. 7. Webový server se pokusí najít podpis známého vydavatele certifikátů odpovídající podpisu na klientském certifikátu pomocí paměti certifikátů webového serveru. 8. Pokud není nalezena shoda mezi podpisy, vygeneruje se chybový kód SSL a odešle se klientovi. 9. Pokud je nalezena shoda mezi podpisy, pak je klient považován za ověřeného. Provede se autentizace klienta, jejímž výsledkem je totožnost produktu Tivoli Access Manager. 10. Klíče relace jsou bezpečně projednány mezi klientem a webovým serverem. Výsledkem tohoto procesu je bezpečný a ověřený komunikační kanál mezi navzájem autentizovaným klientem a serverem.
Aktivace autentizace pomocí certifikátů Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete aktivovat autentizaci pomocí certifikátů, přiřaďte slovo ’cert’ k parametru authentication: [common-modules] authentication = cert
64
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že je zde uveden záznam pro autentizaci pomocí certifikátů: [modules] cert = pdwpi-certificate-module
Poznámka: Pro instalace používající webový server IHS platí, že musíte webový server nakonfigurovat tak, aby požadoval certifikáty od klientů.
Konfigurace mechanismu pro autentizaci pomocí certifikátů Parametr cert-ssl určuje sdílenou knihovnu pro mapování informací autentizace pomocí certifikátů. Na operačním systému UNIX je soubor, který poskytuje zabudované mapovací funkce, tzv. sdílená knihovna s názvem libpdwpi-sslauthn. Na operačním systému Windows je soubor, který poskytuje zabudované mapovací funkce, tzv. DLL s názvem sslauthn. Mechanismus autentizace pomocí certifikátu můžete nakonfigurovat tak, že zadáte parametr cert-ssl spolu se jménem sdílené knihovny specifickým pro danou platformu do stanzy [authentication-mechanisms] konfiguračního souboru pdwebpi.conf. Solaris: [authentication-mechanisms] cert-ssl= libpdwpi-sslauthn.so
Windows: [authentication-mechanisms] cert-ssl = pdwpi-sslauthn.dll
Poznámka: Služba CDAS pdwpi-sslauthn vyžaduje, aby se DN subjektu v certifikátu uživatele přesně shodovalo s DN uživatele v LDAP. Pokud potřebujete složitější mapování, musíte vyvinout přizpůsobenou službu CDAS. Instrukce, jak vytvořit moduly CDAS najdete v knize IBM Developer’s Reference. Uvedené instrukce platí také pro produkt Tivoli Access Manager Plug-in for Web Servers.
Konfigurace autentizace pomocí tokenů Produkt Tivoli Access Manager Plug-in for Web Servers podporuje autentizaci pomocí hesla tokenu dodávaného klientem.
Autentizace SecurID pomocí tokenu Zpracování autentizace pro plug-in program pomocí tokenu vyžaduje, aby byl klient RSA SecurID instalován a konfigurován na serveru, kde je nainstalován plug-in program, ke komunikaci se vzdáleným serverem RSA. Podporovaná verze klienta SecurID je 5.1. ACE/Servers pro RSA ověřují identitu několika různých tokenů, včetně softwarových tokenů a příručních zařízení ovládaných mikroprocesorem. Softwarové tokeny SecurID jsou binární programy spouštěné na pracovních stanicích, instalované na smart-card, nebo spouštěné jako plug-in program pro prohledávací program webu. Softwarové tokeny SecurID mohou být spuštěny jako aplikace. Aplikace zobrazuje okno, do kterého uživatel zadává PIN (Personal Identification Number) a sotwarový token vypočítává passcode. Uživatel se může poté autentizovat plug-in programu, když zadá heslo do přihlašovacího formuláře. Nejběžnějším formátem tokenu SecurID je příruční zařízení. Zařízení je obvykle elektronický klíč nebo tenký elektronický klíč. Token může mít PIN klávesnici, na kterou uživatel zadává Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
65
PIN, aby vygeneroval heslo. Když nemá token žádnou PIN klávesnici, je heslo vytvořeno pomocí PIN uživatele a autentizačního kódu. Autentizační kód mění číslo zobrazené v elektronickém klíči. Autentizační kód je číslo generované tokenem SecurID v jednominutových intervalech. Uživatel poté k autentizaci pro ACE/Server zadává PIN a autentizační kód. Plug-in program podporuje oba režimy tokenu RSA: v režim Next tokencode Tento režim se použije, když uživatel zadává správné PIN, ale nesprávný autentizační kód. Běžně musí být pro odeslání tokencard do dalšího režimu autorizačního kódu zadán autorizační kód třikrát nesprávně. Pokud uživatel zadává správné heslo, je tokencard automaticky změněna. Uživatel čeká na nový autorizační kód a poté zadává heslo znovu. v režim New PIN Token může být v režimu New PIN, pokud je staré PIN stále přiřazeno. Token je umístěn v tomto režimu, když administrátor chce prosadit politiku maximálního stáří hesla. Token je také umístěn v tomto režimu, když je PIN odstraněno, nebo nebylo přiřazeno. Nově přiřazené tokeny nemusí mít ještě PIN. PIN může být administrátorem odstraněno, když ho uživatel zapomněl, nebo když předpokládá, že bylo ohroženo. PIN pro SecurID lze vytvořit různými způsoby: v uživatelsky-definovaná v vygenerovaná-systémem v volitelná-uživatelem Režimy pro PIN jsou definovány způsobem vytvoření a pravidly, která uvádí parametry pro vytvoření hesla a typ zařízení. Plug-in program podporuje následující typy uživatelsky-definovaných PIN: v v v v v v
4-8 alfanumerických znaků, token non-PINPAD 4-8 alfanumerických znaků, heslo 5–7 numerických znaků, token non-PINPAD 5-7 numerických znaků, token PINPAD 5-7 numerických znaků, čtyřčíselný PIN Deny 5-7 numerických znaků, alfanumerický Deny
Plug-in program nepodporuje následující typy nových PIN: v vygenerované-systémem, token non-PINPAD v vygenerované-systémem, token PINPAD v volitelné-uživatelem, token non-PINPAD v volitelné-uživatelem, token PINPAD Uživatelé tokenu nemohou vynulovat jejich PIN, aniž by administrátor ACE dříve token neodstranil, nebo aniž by ho nedal do nového režimu pro PIN. To znamená, že uživatelé s platnými PIN nemohou odesílat do formuláře pkmspassword.form. Pokusy o přístup k tomuto formuláři vrátí chybovou zprávu.
Postup autentizace pro tokeny v režimu nového PIN Pro autentizaci tokenů v režimu nového PIN se vyskytují následující procesy: 1. Klient (prohledávací program) požaduje chráněný objekt webu vyžadující autentizaci pomocí tokenů. 2. Plug-in program vrací autentizační stránku, požadující jméno uživatele a heslo. 3. Uživatel vkládá své jméno uživatele a autentizační kód a zadává formulář do knihovny autentizace plug-in programu. Když nemá uživatel žádné PIN (protože je autentizační
66
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
4. 5.
6. 7. 8.
9. 10. 11.
kód nový, nebo protože administrátor vynuloval PIN), je autentizační kód stejný jako heslo. Když má uživatel PIN, ale tokencard je v režimu New PIN, zadává PIN plus autorizační kód. Knihovna autentizace pomocí tokenu plug-in programu odesílá požadavek na autentizaci do ACE/Server. ACE/Server zpracovává požadavek následujícím způsobem: a. Když je autentizace neúspěšná, je výsledek vrácen knihovně autentizace pomocí tokenu plug-in programu, která klientovi zobrazuje chybovou stránku (návrat do kroku 2). b. Pokud nebyl token v režimu New PIN, je uživatel autentizován. Knihovna autentizace pomocí tokenu plug-in programu vrací úspěšnou autentizaci plug-in programu, který poskytuje požadovaný chráněný objekt webu. (Konec postupu autentizace). c. Pokud je token v režimu New PIN, tak ACE/Server vrací knihovně autentizace pomocí tokenu plug-in programu chybový kód NEW_PIN. Plug-in program ukazuje uživateli formulář zaniklého hesla. Uživatel zadává autentizační kód nebo heslo a nové PIN a posílá ho plug-in programu. Plug-in program kontroluje, jestli je nasazen server odolnosti hesla. a. Pokud není server odolnosti hesla nasazen, pokračuje plug-in program do kroku 9. b. Pokud je server odolnosti hesla nasazen, tak plug-in program kontroluje nové PIN. Pokud je PIN platné, pokračuje plug-in program do kroku 9. Pokud není PIN platné, vrací se plug-in program do kroku 6. Knihovna autentizace plug-in programu odesílá autentizační kód a nové PIN do ACE/Server. ACE/Server vrací kód odpovědi. Pokud je volání nastavení PIN do ACE/Server úspěšné, vrací plug-in program klientovi původně požadovaný chráněný objekt webu. Pokud volání nastavení PIN selže, vrací se autentizace do kroku 6.
Použití autentizace pomocí tokenu se serverem odolnosti hesla Plug-in program také podporuje server odolnosti hesla, který je určitý pro mechanismus autentizace. Tato podpora umožňuje architektům zabezpečení rozvinout metody účinnosti hesla pro různé metody autentizace při použití pouze mechanismu autentizace plug-in programu. Například čtyřčíselné, numerické PIN se může kvalifikovat pro ACE/Server, ale může selhat proti přísnějšímu serveru odolnosti hesla.
Aktivace autentizace pomocí tokenů Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete aktivovat autentizaci pomocí tokenů, přiřaďte slovo ’token’ k parametru authentication. Je-li aktivována autentizace pomocí tokenů, pak musí být také tokeny nakonfigurovány pro zpracování následující po autorizaci. Ve stanze [common-modules] konfiguračního souboru vytvořte parametr post-authzn a přiřaďte mu hodnotu ’token’. Stanza [common-modules] by měla obsahovat následující dva záznamy: [common-modules] authentication = token post-authzn = token
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že je zde uveden záznam pro autentizaci pomocí tokenů: Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
67
[modules] token = pdwpi-token-module
Konfigurace mechanismu pro autentizaci pomocí tokenů Parametr token-cdas určuje sdílenou knihovnu pro mapování informací autentizace pomocí autentizačního kódu tokenu. v Na operačním systému UNIX je soubor, který poskytuje zabudované mapovací funkce, tzv. sdílená knihovna s názvem libxtokenauthn. v Na operačním systému Windows je soubor, který poskytuje zabudované mapovací funkce, tzv. DLL s názvem xtokenauthn. Sdílená knihovna tokenu je instalována jako část sady programů produktu Tivoli Access Manager Web Security Runtime (PDWebRTE). Umístění této sdílené knihovny je: UNIX
/opt/pdwebrte/lib
Windows c:\Program Files\Tivoli\PDWebRTE\bin Standardně je tato zabudovaná sdílená knihovna pevně naprogramována tak, aby mapovala data autentizačního kódu SecureID tokenu. Tento soubor můžete přizpůsobit tak, aby autentizoval i jiné typy dat speciálních tokenů a, volitelně, namapovat tato data na totožnost produktu Tivoli Access Manager. Podrobné informace o rozhraní API najdete v knize IBM Tivoli Access Manager for e-business Web Security Developer Reference. Mechanismus autentizace pomocí tokenů můžete nakonfigurovat tak, že zadáte parametr token-cdas spolu se jménem sdílené knihovny specifickým pro danou platformu do stanzy [authentication-mechanisms] konfiguračního souboru pdwebpi.conf. Například: Solaris: [authentication-mechanisms] token-cdas = libxtokenauthn.so
Windows: [authentication-mechanisms] token-cdas = xtokenauthn.dll
Přizpůsobení stránek s odpovědí pro tokeny Parametr token-login-form ve stanze [token-card] konfiguračního souboru definuje jméno souboru formuláře, který bude předložen uživateli klienta během jeho přihlášení pomocí tokenů. Cesta k souboru by měla být relativní k přeloženému plug-in HTML adresáři, např. pdwebpi/nls/html/jazyk/znaková sada. Kde parametr jazyk je nastaven podle NLS konfigurace. Na systémech US English je adresář jazyk nazýván C a znaková sada je utf-8. Parametr next-token-form ve stanze [token-card] definuje formulář, který se zobrazí uživateli klienta, pokud bude třeba požádat o další token. Klient je žádán, aby zadal další token, pokud server není schopen úspěšně autentizovat uživatele z prvního tokenu. Neschopnost autentizovat uživatele může být způsobena řadou důvodů. Nejčastějším důvodem chyby je, že hodiny klienta a serveru nejsou synchronizovány. Pokud nemůže být úspěšně provedena autentizace pomocí prvního tokenu, zobrazí se stránka uvedená v parametru next-token-form a požádá o další token. Stanza token-card má následující formát:
68
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
[token-card] token-login-form = tokenlogin.html next-token-form = nexttoken.html
Konfigurace autentizace pomocí SPNEGO Autentizace pomocí SPNEGO poskytuje kontům uživatele Windows při přistupování ke chráněným objektům pomocí produktu Internet Explorer schopnost SSO (Single Signon). Pomocí autentizace pomocí SPNEGO provádí plug-in program serverovou část navazování spojení, Internet Explorer provádí klientskou část. Když požadavky uživatele přistupují ke chráněnému webovému serveru, Internet Explorer používá uživatelovo pověření přihlášení do Windows k účasti v navazování spojení s webovým serverem, aby tím zvýšil jeho autenticitu. Když server potvrdil totožnost uživatele, je mu poskytnut přístup pokud: v je uživatel členem domény v autorizační server aktivoval SPNEGO v autorizační server povolí přístup Uživatelé, kteří přistupují ke zdrojům chráněným autentizací pomocí SPNEGO plug-in programu, a kteří nejsou členy domény nebo používají jiné prohlížeče než Internet Explorer, se musí autentizovat pomocí jiné politiky, například pomocí Základní autentizace nebo pomocí formulářů. Poznámka: Funkcionalita modulu autentizace pomocí SPNEGO může správně fungovat pouze, pokud je webový server konfigurován, aby povolil anonymní přístup. V případě IIS musí být volba Integrated Login nezaškrtnuta a volba Anonymous Access musí být zaškrtnuta. V případě jiných webových serverů by se měla použít standardní konfigurace.
Podpora platformy a registru uživatelů Mechanismus autentizace pomocí SPNEGO je dostupný ve všech podporovaných kombinacích webový server/platforma/registr-uživatelů. Pokud není Aktivní adresář registrem uživatelů produktu Tivoli Access Manager, musí být uživatelé mezi registrem pro Aktivní adresář a registrem uživatelů produktu Access Manager replikováni.
Přechod konfigurace SPNEGO z verze 4.1 na 5.1 Produkt Tivoli Access Manager Plug–in for Web Servers verze 4.1 poskytoval modul spnego. Ve verzi 5.1 plug-in programu byla funkcionalita tohoto modulu včleněna do tří samostatných modulů: spnego, ntlm a web-server-authn. Neexistuje žádný automatický proces jak přemístit vaši konfiguraci SPNEGO 4.1 do 5.1 — budete muset provést překonfigurování ručně. Následující tabulka zobrazuje nastavení konfigurace 5.1 ekvivalentní k nastavením z verze 4.1. Existují dvě situace: v Nastavení parametru web-server-does-authn ve stanze [spnego] verze 4.1 konfiguračního souboru na true. v Nastavení parametru web-server-does-authn ve stanze [spnego] verze 4.1 konfiguračního souboru na false.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
69
Tabulka 12. Ekvivalentní konfigurace SPNEGO mezi verzí 4.1 a 5.1. Plug-in verze 4.1
Plug-in verze 5.1
[common-modules] authentication = spnego authentication = BA
[common-modules] authentication = web-server-authn session = session-cookie
session = spnego session = session-cookie [spnego] web-server-does-authn = true [common-modules] authentication = spnego authentication = BA session = spnego session = session-cookie [spnego] web-server-does-authn = false
Podrobnosti o konfiguraci najdete v části “Konfigurace autentizace pomocí webového serveru (pouze pro platformy IIS)” na stránce 77. [common-modules] authentication = spnego authentication = ntlm authentication = BA session = session-cookie Podrobnosti o konfiguraci najdete v části “Konfigurace autentizace pomocí NTLM0 (pouze pro platformy IIS)” na stránce 76.
Omezení Následující funkce plug-in programu nejsou podporovány s autentizací pomocí SPNEGO: v Opětovná autentizace klientů autentizovaných pomocí SPNEGO na základě POP nebo časovače relace. v Změna hesla pomocí pkmspasswd pro registry uživatelů jiné než Aktivní adresář. v Mapování jména uživatele přes CDAS. v Klienti SPNEGO se nemohou odhlásit z plug-in programu. Klienti se musí odhlásit z pracovní stanice. Klienti, kteří přistupují ke stránkám příkazu plug-in programu pkms (s výjimkou přepnutí uživatele) obdrží stránku nápovědy pro PKMS. v Opětovná autentizace, když vyprší časovač neaktivní relace pro klienty SPNEGO. Záznam paměti cache uživatele je smazán, ale ID relace je zadrženo. K opětovné autentizaci se použije informace v hlavičce obdržené od klienta SPNEGO. Klient se nemusí znovu přihlašovat, ale obdrží nový záznam paměti cache relace. v Opětovná autentizace, když uživatel přistupuje k objektu s připojenou politikou opětovné autentizace. V tomto případě je přístup zamítnut a uživatel obdrží zprávu, že je požadována opětovná autentizace.
Konfigurace jednotného přihlášení k pracovní ploše Windows Tato sekce obsahuje kroky konfigurace, které se musí dokončit pro implementaci jednotného přihlášení k pracovní ploše Windows použitím autentizace pomocí SPNEGO s plug-in programem. Ne všechny kroky jsou vyžadovány na každé platformě. Abyste nakonfigurovali autentizaci pomocí SPNEGO dokončete každý z následujících kroků:
Krok 1: Nakonfigurujte server plug-in programu v doméně Aktivní adresář Pro účast ve vzájemné výměně Kerberos s produktem Internet Explorer musí mít plug-in program identitu v Kerberos doméně Aktivní adresář. To vyžaduje, aby byl plug-in program registrován s řadičem domény Aktivní adresář. Prohledávací program Internet Explorer může poté použít pověření uživatele k přihlášení do Windows pro přístup k serveru rozšířenému o plug-in program.
70
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Instrukce, o tom jak do domény Aktivní adresář přidat totožnost pro hostitele serveru plug-in programu, naleznete v dokumentaci Microsoftu. Poznámky: 1. Ve Windows používá při kontaktování řadiče domény Aktivní adresář předvolený server plug-in programu (instance prvního serveru) identitu Local Service Account. 2. Pro UNIX zajistěte, že jméno uživatele odpovídá jménu hostitele pro hostitele serveru plug-in programu. Nepoužívejte plné jméno domény. Například pro systém diamond.subnet2.ibm.com vytvořte uživatele diamond. Nepožadujte, aby uživatel při dalším přihlášení měnil heslo. Nenastavujte heslo tak, aby mu vypršela platnost.
Krok 2: Mapujte objekt Kerberos na uživatele domény Aktivní adresář Klient programu Internet Explorer požaduje do požadavků řadiče domény Aktivní adresář přístup k objektu Kerberos, který se jmenuje: HTTP/DNS-jméno-serveru-plug-in-programu@jméno-domény-Aktivní-adresář
Toto jméno musí být mapováno na uživatele domény Aktivní adresář, který reprezentuje instanci serveru rozšířeného o plug-in program, jak byla vytvořena ve výše uvedeném kroku 1. Toto mapování vyžaduje obslužný program Windows ktpass. Obslužný program ktpass nemusí být v systému Windows předvoleně zaveden. Lze ho obdržet ze sady programů Windows Support Tools na CD s Windows. Windows: Registrujte jméno řídicí služby pro server plug-in programu.V řadiči domény Aktivní adresář zadejte příkaz ktpass. Pokud je například hostitel plug-in programu diamond.subnet2.ibm.com a doména Aktivní adresář je IBM.COM, je příkaz: ktpass -princ HTTP/[email protected] -mapuser diamond
UNIX: Dokončete následující kroky: 1. V systémech UNIX v dodatku k mapování uživatele musíte při přihlašování do domény Kerberos vytvořit soubor tabulky klíčů. Syntaxe je (zadáno jako jeden řádek): ktpass -princ HTTP/DNS-jméno-serveru-WebPI@jméno-domény-Aktivní-adresář -pass vaše-heslo -mapuser instance-serveru-WebPI -out plná-cesta-k-souboru-tabulky-klíčů -mapOp set
Identita uživatele uvedená volbou -mapuser ve výše uvedeném příkazu je uživatel domény Aktivní adresář. Heslo zde uvedené vynulovává heslo pro uživatele domény Aktivní adresář. Je preferováno vysoce zabezpečené heslo, jako je náhodně vygenerované heslo. Umístění souboru tabulky klíčů je libovolné. Zadržte toto heslo pro použití v pozdějším kroku k otestování vaší konfigurace Kerberos (když testujete autentizaci z počítače se systémem UNIX na Key Distribution Center pro Aktivní adresář). 2. Přeneste soubor tabulky klíčů do systému UNIX.Zajistěte, že se použije metoda zabezpečeného přenosu. Doporučené umístění je: /opt/pdwebpi/etc/jméno-souboru-tabulky-klíčů
3. Pro nejlepší zabezpečení vymažte soubor tabulky klíčů ze systému Windows. 4. Na systému UNIX přiřaďte vlastnictví souboru k pdwebpi a omezte povolení na souboru tabulky klíčů tak, že k němu může přistoupit pouze vlastník. Například: # chown pdwebpi soubor-tabulky-klíčů # chgrp pdwebpi soubor-tabulky-klíčů # chmod 600 soubor-tabulky-klíčů
5. Pro servery se systémem UNIX opakujte výše uvedené kroky pro každou instanci plug-in programu.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
71
Krok 3: Nainstalujte runtime klienta Kerberos (pouze pro UNIX) Server, ve kterém je instalován plug-in program musí mít instalovaný runtime Kerberos. Na systémech Windows je runtime klient Kerberos částí operačního systému. Nejsou vyžadovány žádné další sady programů. Na systémech UNIX instalujte odpovídající sadu programů: v AIX IBM Network Authentication Service Client. Tohoto klienta můžete nalézt v rozšiřujícím balíku AIX. v Solaris – IBM Network Authentication Service Client. Tento klient je zahrnut na CD produktu Tivoli Access Manager Web Security. K instalaci použijte pkgadd. – SUN Kerberos Client SUNWkr5cl. Tento produkt je vyžadován IBM Network Authentication Service Client. Tato sada programů je částí sady programů SEAM a lze ji stáhnout z webového serveru Sun. v Linux MIT Kerberos v1.2.5
Krok 4: Nakonfigurujte klienta Kerberos (pouze pro UNIX) Klient Kerberos nainstalovaný v předchozím kroku musí být nakonfigurován. To vyžaduje vytvoření nebo modifikaci konfiguračního souboru Kerberos. Na systémech Solaris a AIX je soubor /etc/krb5/krb5.conf, na systému Linux je soubor /etc/krb5.conf. Dokončete instrukce a poté aplikujte do vašeho operačního systému: AIX Použijte obslužný program mkkrb5clnt. Tento obslužný program vytváří a dokončuje /etc/krb5/krb5.conf. 1. Spusťte mkkrb5clnt. Syntaxe je: mkkrb5clnt -r doména-Aktivní-adresář -c řadič-pro-Aktivní-adresář-DNS -s řadič-pro-Aktivní-adresář-DNS -d lokální-doména-DNS
Například: mkkrb5clnt -r IBM.COM -c dc1.ibm.com -s dc1.ibm.com -d dns.com
2. Ručně editujte krb5.conf pro odstranění libovolných nastavení zakódování, která Aktivní adresář nepodporuje. [libdefaults] default_tkt_enctypes = des-cbc-md5 des-cbc-crc default_tgs_enctypes = des-cbc-md5 des-cbc-crc
Tento krok odstraňuje des3-cbc-sha1. Solaris a Linux Ručně editujte krb5.conf. Přizpůsobte následující informaci pro vaši doménu: v Sféra. Například IBM.COM v Jméno serveru řadiče Aktivní adresář. Například dc1. v Jméno domény. Například ibm.com. v Jméno DNS. Například ibm.com. Použitím výše uvedených hodnot bude konfigurační soubor Kerberos obsahovat následující záznamy:
72
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Částečný výpis krb5.conf: [libdefaults] default_realm = IBM.COM default_tkt_enctypes = des-cbc-md5 des-cbc-crc default_tgs_enctypes = des-cbc-md5 des-cbc-crc [realms] IBM.COM = { kdc = dc1.ibm.com:88 admin_server = dc1.ibm.com:749 default_domain = ibm.com } [domain_realm] dc1.ibm.com = IBM.COM .ibm.com = IBM.COM
Poslední řádek výše uvedeného příkladu (.ibm.com = IBM.COM ) reprezentuje doménu DNS, ve které server rozšířený o plug-in program funguje, a se kterým uživatel navazuje spojení. Všimněte si tečky (.) před doménou IBM v posledním řádku. Ta funguje jako zástupný znak pro všechny poddomény a hostitele v doméně ibm.com. Poznámka: V systému United Linux používajícím verzi Kerberos zvanou Heimdal může být nezbytné přidat do stanzy [libdefaults] pro usnadnění testování následující řádky. [libdefaults] default_etypes = des-cbc-md5 des-cbc-crc default_etypes_des = des-cbc-md5 des-cbc-crc
Krok 5: Ověřte autentizaci objektu webového serveru (pouze pro UNIX) Použijte program kinit k ověření, že objekt Kerberos pro server rozšířený o plug-in program lze autentizovat. Použijte heslo uvedené při spuštění ktpass v kroku 2: # /usr/krb5/bin/kinit [email protected] Heslo pro [email protected] : heslo-serveru # klist
Měli byste prohlédnout výstup z klist, který zobrazuje pověření pro [email protected] Poznámka: Umístění obslužného programu kinit by se mělo měnit v závislosti na platformě operačního systému.
Krok 6: Ověřte autentizaci pomocí plug-in programu použitím tabulky klíčů (pouze pro UNIX) Ověřte, že plug-in program může autentizovat pomocí tabulky klíčů v kroku 2. Zadejte následující příkaz kinit jako jeden souvislý řádek: # kinit -k -t /var/pdweb/keytab-diamond/diamond_HTTP.keytab HTTP/[email protected] # klist
Měli byste prohlédnout výstup z klist, který zobrazuje pověření pro HTTP/[email protected]
Krok 7: Povolte autentizaci pomocí SPENGO v plug-in programu Pokud chcete povolit autentizaci pomocí SPNEGO v plug-in programu: 1. Přiřaďte hodnotu spnego do parametru autentizace ve stanze [common-modules] konfiguračního souboru plug-in programu pdwebpi.conf. [common-modules] authentication = spnego Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
73
2. Ve stanze [authentication-mechanisms] nastavte parametr kerberosv5 na absolutní cestu sdílené knihovny stli (Security Translation Layer Interface). Například: AIX:
kerberosv5 = /opt/PolicyDirector/lib/libstliauthn.a
UNIX: kerberosv5 = /opt/PolicyDirector/lib/libstliauthn.so Windows: kerberosv5 = C:\PROGRA~1\Tivoli\POLICY~1\bin\stliauthn.dll 3. Ve stanze [spnego] nastavte: v spnego-krb-service-name na HTTP nebo na HTTP@plně-kvalifikované-jménodomény-hostitele. v spnego-krb5-keytab-file na plný název cesty souboru tabulky klíčů, který se použije plug-in programem. Tato hodnota je požadovaná pouze pro platformy UNIX. Na platformách Windows je volba ignorována.
Krok 8: Povolte autentizaci pomocí SPENGO ve webovém serveru Abyste pro IIS povolili SPNEGO zajistěte, že je přístupová politika webového serveru —nastavená v oušku Directory Security— nastavena na anonymous. Pro ostatní webové servery je předvolená konfigurace akceptovatelná. Pokud chcete povolit autentizaci pomocí SPNEGO v klientovi programu Internet Explorer: 1. Pokud je plug-in program nainstalován na platformě UNIX, nakonfigurujte zónu Local Intranet, aby zahrnovala jméno serveru UNIX: a. Vyberte Tools → Internet options. b. Z ouška Security vyberte Local Intranet → Sites → Advanced nebo Trusted Sites → Sites. c. Zadejte server UNIX, na kterém je spuštěn plug-in program. 2. Nakonfigurujte chování integrovaného přihlášení: a. Vyberte Tools → Internet Options. b. Z ouška Security klepněte na Custom Level. c. Přesuňte se do sekce Logon v dialogu Security Settings a v závislosti na funkcionalitě, kterou požadujete, vyberte Automatic... nebo Prompt.... Poznámka: Pokud byla v kroku 1 vybrána volba Trusted Sites, uživatel nebude nikdy vyzván, aby zadal informaci jména uživatele a hesla. 3. Pokud je klient verze 6 programu Internet Explorer, musíte nakonfigurovat integrované přihlášení pro Windows. Abyste to provedli: a. Vyberte Tools → Internet Options. b. Z ouška Advanced zaškrtněte Enable Integrated Windows Login. c. Aby se změny projevily, restartujte prohledávací program.
Rady pro odstraňování problémů Konfigurace Kerberos v Problém: Když testujete tabulku klíčů vytvořenou pro server UNIX pomocí programu kinit objeví se chyba ″Při získávání výchozích pověření se časová základna příliš vychyluje″. Řešení: Při používání Kerberos musí být časové základny synchronizované. Pro trvalé řešení použijte na vašich počítačích některou službu časové synchronizace. Pro dočasné řešení seřiďte na počítačích hodiny na minutovou přesnost. v Problém: Když testujete tabulku klíčů vytvořenou pro server UNIX pomocí programu kinit objeví se chyba ″Při získávání výchozích pověření selhala předautorizace″ nebo ″Při získávání výchozích pověření bylo nesprávné heslo″.
74
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Řešení: Klíč v souboru tabulky klíčů je nesprávný. Ujistěte se, že jste soubor tabulky klíčů vygenerovali správně, se správným jménem objektu, jménem uživatele pro Aktivní adresář a cestou. v Problém: Program kinit selhal při spuštění kinit -k -t Řešení: Některé verze programu kinit nejednají řádně s problémy, když není v souboru tabulky klíčů nalezen záznam. Dvakrát zkontrolujte, že soubor tabulky klíčů má stejný záznam jako ten, který posíláte do programu kinit. Konfigurace produktu Tivoli Access Manager Plug-in for Web Servers v Když se vyskytne problém, uvažte trasování pro SPNEGO. Přidejte záznam do souboru směrování. Soubor směrování je umístěn pod instalačním adresářem v etc/routing. Například: bst:*.9:TEXTFILE:cesta-instalace/log/spnegotrace.log
Na systému UNIX je předvolený adresář instalace plug-in programu /opt/pdwebpi. Napište cestu k vašemu instalačnímu adresáři. Zastavte a restartujte plug-in program.V souboru trasování vyhledejte chybové zprávy. v Problém: Server plug-in programu se nespustí. Soubor protokolu obsahuje chybu, která sděluje ″Metoda autentizace (kerberosv5) není nakonfigurována″. Řešení: Povolte metodu autentizace kerberosv5 ve stanze[authentication-mechanisms] v konfiguračním souboru plug-in programu. v Problém: Plug-in program se nespustí. Chybová zpráva je ″Funkce služby zabezpečení gss-import-name vrátila hlavní chybový kód 131072 a vedlejší chybový kód -1765328168.″ Řešení: Jméno objektu uvedené v konfiguračním souboru bylo neplatné. Jméno by mělo mít formát ″HTTP@jméno-hostitele″, kde jméno-hostitele je plně kvalifikované jméno DNS, které je nakonfigurované ve sféře Kerberos. v Problém: Server plug-in programu se nespustil. Chybová zpráva je ″Funkce služby zabezpečení gss-acquire-cred vrátila hlavní chybový kód 851968 a vedlejší chybový kód 39756033.″ Řešení: Jméno objektu uvedené v konfiguračním souboru neodpovídá žádnému z klíčů uvedených v souboru tabulky klíčů. Klíče v souboru tabulky klíčů mají jména jako HTTP/jméno-hostitele@REALM. Jméno objektu by mělo mít formát HTTP@jméno-hostitele v Problém: Když se uživatel pokouší přistoupit k plug-in programu, obdrží zprávu sdělující ″Vyskytla se vnitřní chyba HPDIA0100E.″ Soubor protokolu trasování plug-in programu obsahuje zprávu, která sděluje ″Funkce služby zabezpečení gss-accept-sec-context vrátila hlavní chybový kód 851968 a vedlejší chybový kód -1765328347.″ Řešení: Časová základna systému na počítači klienta je mimo synchronizaci s časovou základnou na serveru plug-in programu. Při používání Kerberos musí být časové základny synchronizované. Pro trvalé řešení použijte na vašich počítačích některou službu časové synchronizace. Pro dočasné řešení seřiďte na počítačích hodiny na minutovou přesnost. Další položky konfigurace, které se mají zkontrolovat při výskytu problémů v Pomocí autorizačního serveru plug-in programu uvedeného v části “Krok 2: Mapujte objekt Kerberos na uživatele domény Aktivní adresář” na stránce 71 zkontrolujte, zda povolení souboru a vlastnictví souboru tabulky klíčů umožňují přístup. v Použitím obslužného programu ktutil pro zobrazení informace obsažené v souboru tabulky klíčů zkontrolujte, že soubor tabulky klíčů obsahuje platná data a klíče pro správné jméno objektu.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
75
v Zkontrolujte, zda je konfigurace DNS pro celou doménu (řadič a klienti domény) správná, a že jména jsou rozlišována správně a odpovídají hodnotám v položkách konfigurace jména objektu služby v různých umístěních (soubor tabulky klíčů, soubor konfigurace plug-in programu, atd).. v Zkontrolujte, že jsou časové základny systému synchronizované, a že distribuovaná služba času podporuje synchronizaci časové základny na všech systémech v doméně. v Zkontrolujte, že je konfigurace sítě správná, a že neexistují žádná vydání jako zahlcení, nesprávné směrování, kolize jmen, atd. Zajistěte, že je utajenost v tolerovatelných mezích. Buďte si jisti, že firewalls, NAT a další služby zabezpečení sítě se nekříží s operacemi domény.
Konfigurace autentizace pomocí NTLM0 (pouze pro platformy IIS) Přejaté verze platformy Windows poskytovaly základní mechanismus SSO (Single Signon) známý jako autentizace pomocí NTLM (NT Lan Manager). Tato metoda autentizace je založena na algoritmech přepočtu klíčů poskytujících stejnou úroveň zabezpečení a operace jako je úroveň Základní autentizace. Plug-in program podporuje autentizaci pomocí NTLM, aby ulehčil zpětnou kompatibilitu mezi moderními platformami Windows (XP, 2000) a staršími systémy jako Windows NT. Plug-in program podporuje NTLM pouze na platformě Windows IIS, platformy UNIX nejsou podporovány. Abyste povolili autentizaci pomocí NTLM, přiřaďte hodnotu ntlm do parametru autentizace ve stanze [common-modules] konfiguračního souboru plug-in programu pdwebpi.conf. [common-modules] authentication = ntlm
Abyste povolili autentizaci pomocí, zajistěte, že je přístupová politika webového serveru IIS nastavena na anonymní. Abyste nakonfigurovali program Internet Explorer na účast ve vzájemných výměnách NTLM (a SPNEGO): 1. Nakonfigurujte chování integrovaného přihlášení: a. Vyberte Tools → Internet Options. b. Z ouška Security klepněte na Custom Level. c. Přesuňte se do sekce Logon v dialogu Security Settings a v závislosti na funkcionalitě, kterou požadujete, vyberte Automatic... nebo Prompt.... Poznámka: Pokud byla v kroku 1 vybrána volba Trusted Sites, uživatel nebude nikdy vyzván, aby zadal informaci jména uživatele a hesla. 2. Pokud je klient verze 6 programu Internet Explorer, musíte nakonfigurovat integrované přihlášení pro Windows. Abyste to provedli: a. Vyberte Tools → Internet Options. b. Z ouška Advanced zaškrtněte Enable Integrated Windows Login. c. Aby se změny projevily, restartujte prohledávací program. Parametr use-pre-windows-2000-logon-name ve stanze [ntlm] konfiguračního souboru plug-in programu se může použít k nakonfigurování formátů jména uživatele Windows 2000 nebo Windows verzí starších než Windows 2000. Standardně používá modul ntlm přihlašovací jméno pro Windows 2000 k reprezentování autentizovaného uživatele v produktu Tivoli Access Manager. Toto je část přihlašovacího jména jméno už[email protected] , která reprezentuje jméno uživatele. Parametr use-pre-windows-2000-logon-name dovoluje, aby přihlašovací jméno dřívější verze než Windows 2000 reprezentovalo v produktu Tivoli Access Manager autentizovaného uživatele. Toto je část přihlašovacího jména DOMAIN/USERNAME reprezentující jméno uživatele.Tento parametr je ignorován, pokud
76
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
produkt Tivoli Access Manager používá Aktivní adresář jako svůj registr uživatelů. S doménou Aktivní adresář je jméno uživatele produktu Tivoli Access Manager vždy část jméno uživatele přihlašovacího jména jméno už[email protected] .
Konfigurace autentizace pomocí webového serveru (pouze pro platformy IIS) Některé webové servery poskytují schopnost provést autentizaci. Jedním příkladem je schopnost IIS provést Integrated Windows Login (SPNEGO, NTLM nebo BA). Plug-in program může být nakonfigurován, aby použil tuto autentizaci pomocí webového serveru, která důvěřuje, že webový server provedl adekvátní kontroly zabezpečení autentizace. Momentální autentizace pomocí webového serveru pro plug-in program je podporovaná pouze na IIS. Abyste v plug-in programu povolili autentizaci pomocí webového serveru, přiřaďte hodnotu web_svr_authn do parametru autentizace ve stanze [common-modules] konfiguračního souboru plug-in programu pdwebpi.conf. [common-modules] authentication = web_svr_authn
Abyste nakonfigurovali program Internet Explorer na účast ve vzájemných výměnách NTLM (a SPNEGO): 1. Nakonfigurujte chování integrovaného přihlášení: a. Vyberte Tools → Internet Options. b. Z ouška Security klepněte na Custom Level. c. Přesuňte se do sekce Logon v dialogu Security Settings a v závislosti na funkcionalitě, kterou požadujete, vyberte Automatic... nebo Prompt.... Poznámka: Pokud byla v kroku 1 vybrána volba Trusted Sites, uživatel nebude nikdy vyzván, aby zadal informaci jména uživatele a hesla. 2. Pokud je klient verze 6 programu Internet Explorer, musíte nakonfigurovat integrované přihlášení pro Windows. Abyste to provedli: a. Vyberte Tools → Internet Options. b. Z ouška Advanced zaškrtněte Enable Integrated Windows Login. c. Aby se změny projevily, restartujte počítač. Modul autentizace web-server-authn může být nastavením parametru use-pre-windows-2000-logon-name v konfiguračním souboru plug-in programu pod stanzou [web-server-authn] nakonfigurován, aby používal formáty jména uživatele pro Windows 2000 nebo Windows starší verze než Windows 2000. Standardně používá modul web-server-authn přihlašovací jméno pro Windows 2000 k reprezentování autentizovaného uživatele v produktu Tivoli Access Manager. Toto je část přihlašovacího jména jméno už[email protected] , která reprezentuje jméno uživatele. Parametr use-pre-windows-2000-logon-name dovoluje, aby přihlašovací jméno dřívější verze než Windows 2000 reprezentovalo v produktu Tivoli Access Manager autentizovaného uživatele. Toto je část přihlašovacího jména DOMAIN/USERNAME reprezentující jméno uživatele.Tento parametr je ignorován, pokud produkt Tivoli Access Manager používá Aktivní adresář jako svůj registr uživatelů. S doménou Aktivní adresář je jméno uživatele produktu Tivoli Access Manager vždy část jméno uživatele přihlašovacího jména jméno už[email protected] .
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
77
Konfigurace autentizace po přepnutí při selhání Tato sekce obsahuje následující témata: v “Koncepty autentizace po přepnutí při selhání” v “Konfigurace autentizace po přepnutí při selhání” na stránce 84
Koncepty autentizace po přepnutí při selhání Plug-in program poskytuje metodu autentizace umožňující, aby byla autentizovaná relace mezi klientem a webovým serverem rozšířeným o plug-in program uchována, když se rozšířený server plug-in programu stane nedostupný. Metoda se nazývá autentizace po přepnutí při selhání. Autentizace po přepnutí při selhání umožňuje klientovi navázat spojení s jiným webovým serverem rozšířeným o plug-in program a vytvořit relaci autentizace obsahující data a pověření stejné relace uživatele. Funkci failover cookie obvykle používají klienti, kteří se připojují na replikovaný předřazený webový server prostřednictvím mechanismu pro vyvažování zatížení. Failover cookie brání před vynucenou opětovnou autentizací, pokud původní relace mezi serverem a klientem přestala být dostupnou. Pokud jsou failover cookies nakonfigurovány pro zpracování následující po autorizaci, plug-in program zašifruje data pověření buď do cookie specifické pro server, nebo do cookie pro celou doménu. Cookie se uloží do prohlížeče, jakmile se klient poprvé připojí. Pokud bude přerušena první relace s webovým serverem, cookie je předložena dalšímu serveru, na který je klient přesměrován. Cookie se používá pro automatickou opětovnou autentizaci, takže klient je uchráněn od toho, aby úlohu opětovné autentizace provedl ručně. Plug-in programy na replikovaných serverech sdílejí společný klíč, který dešifruje informace o pověření, které jsou uloženy v cookie, a vytvářejí novou relaci.
Obrázek 5. Typická architektura serveru pro failover cookies.
Výše uvedený diagram zobrazuje typickou architekturu, která může profitovat z použití failover cookies. Tři naprosto stejné instance stejného webového serveru jsou umístěny za serverem vyvažujícím zatížení, který směruje požadavky na jeden z těchto tří serverů v závislosti na jejich zatížení a dostupnosti. Předpokládejme například, že každá instance serveru www.ibm.com je nakonfigurována tak, aby autentizovala přístupy klientů pomocí failover cookies a že failover cookies jsou současně nakonfigurovány pro zpracování následující po autorizaci. Klient přistoupí na www.ibm.com a je přesměrován na instanci 1 serveru a úspěšně se autentizuje. Pověření klienta jsou zašifrována a uložena do cookie pro celou doménu, která je uložena do prohlížeče na klientovi. Pokud během relace potřebuje klient přistoupit buď k instanci 2 nebo k instanci 3 serveru www.ibm.com (tzn. že došlo k selhání instance 1, nebo žádost je příliš velká, aby ji instance 1 zpracovala), pak se failover cookie uložená v prohlížeči klienta použije k tomu, aby byl klient automaticky opětovně
78
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
autentizován, aniž by byla potřeba nějaká akce uživatele. Doba spuštění původní relace je ponechána s cookie, takže, když se provede automatické přesměrování do serveru failover, doba trvání relace zůstává platná.
Scénář autentizace po přepnutí při selhání Jako část schopnosti přepnutí při selhání podporuje plug-in program autentizaci uživatele pomocí failover cookie. Failover cookie je cookie určitá pro server nebo cookie domény. Failover cookie obsahuje data určitá pro klienta, jako je jméno uživatele, časové označení vytvoření cookie, původní metoda autentizace a seznam atributů. Seznam atributů standardně obsahuje úroveň autentizace uživatele. Plug-in program může být nakonfigurován, aby do seznamu atributů přidal určité rozšířené atributy. Plug-in program tato pro klienta určitá data šifruje. Plug-in programy na replikovaných serverech sdílejí společný klíč, který dešifruje informace cookie. Když replikovaný server plug-in programu obdrží tuto cookie, tak ji dešifruje a použije jméno uživatele a metodu autentizace k opětovnému vygenerování pověření klienta. Plug-in program může být také nakonfigurován, aby z cookie do pověření uživatele kopíroval libovolné rozšířené atributy. Klient nyní může zavést novou relaci se serverem rozšířeným o plug-in program repliky, aniž by byl vyzván k přihlášení. Poznámka: Failover cookies lze použít přes HTTP nebo HTTPS. Pořadí událostí pro autentizaci po přepnutí při selhání: 1. Klient (prohledávací program) se pokouší přistoupit ke chráněnému zdroji.Požadavek klienta se přemisťuje do prostředku pro vyrovnávání zatížení, který ovládá přístup k replikovaným serverům. 2. Prostředek pro vyrovnávání zatížení vybírá cílový server a postupuje požadavek uživatele. 3. Klient se úspěšně autentizuje do serveru přes plug-in program pomocí jedné z podporovaných metod autentizace. 4. Plug-in program vytváří cookie pro autentizaci po přepnutí při selhání, která obsahuje informaci o autentizaci klienta, a odesílá ji klientovi. 5. Klient odesílá cookie přes prostředek pro vyrovnávání zatížení do plug-in programu s každým následným požadavkem. Plug-in program zpracovává každý požadavek. 6. Pokud prostředek pro vyrovnávání zatížení zjistí, že server rozšířený o plug-in program není přístupný, je požadavek klienta odeslán do jiného replikovaného rozšířeného serveru plug-in programu. 7. Plug-in program na replikovaném serveru je nakonfigurován, aby kontroloval existenci cookie pro autentizaci po přepnutí při selhání pokaždé, když se pokouší autentizovat uživatele. 8. Plug-in program používá informaci v cookie, aby zavedl relaci s klientem bez toho, aby se musel klient znovu manuálně přihlašovat. Jsou vytvořena klientova data relace a pověření uživatele a je zpracován požadavek pro chráněný zdroj. 9. Změna relace z jednoho serveru rozšířeného o plug-in program na jiný je pro klienta transparentní. Protože servery rozšířené o plug-in program obsahují stejné zdroje, pokračuje relace klienta bez přerušení.
Knihovna autentizace po přepnutí při selhání Plug-in program poskytuje každé podporované metodě autentizace sdílenou knihovnu autentizace po přepnutí při selhání. Každá sdílená knihovna přepnutí při selhání napodobuje sdílenou knihovnu pro odpovídající metodu autentizace a dodatečně nahrazuje libovolné rozšířené atributy, které byly původně umístěny v pověřeních uživatele. Když se vyskytne autentizace po přepnutí při selhání, plug-in program volá její knihovnu, která odpovídá poslední metodě autentizace použité uživatelem před selháním původního serveru.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
79
Plug-in program dodává funkci autentizace po přepnutí při selhání pro následující metody autentizace: v základní autentizace nebo autentizace pomocí formulářů (nebo také autentizace pomocí hesla) v autentizace pomocí token card v autentizace pomocí certifikátu v autentizace pomocí požadavku HTTP v CDSSO (Cross-domain single signon) v SPNEGO (Kerberos authentication) Plug-in program dodává jednu standardní sdílenou knihovnu přepnutí při selhání, která funguje pro všechny výše uvedené metody autentizace. Tato knihovna se na systémech UNIX nazývá libfailoverauthn a na Windows failoverauthn. Poznámka: Alternativně můžete dodat přizpůsobenou knihovnu CDAS, která poskytuje určité schopnosti autentizace požadované vaším prostředím. Plug-in program může být například nakonfigurován, aby podporoval autentizaci pomocí formulářů a autentizaci po přepnutí při selhání. Když se plug-in program spouští je zavedena jak sdílená knihovna autentizace pomocí formulářů, tak knihovna autentizace pomocí ″failover-forms″. Uživatel se autentizuje pomocí autentizace pomocí formulářů.Server plug-in programu odesílá každému klientovi (prohledávacímu programu) cookie pro autentizaci po přepnutí při selhání. Data cookie uvádí, že byla vytvořena v prostředí autentizace pomocí formulářů. Když se server rozšířený o plug-in program stane nedostupným, je failover cookie odeslána druhému serveru rozšířenému o plug-in program. Druhý server (běžně je to replikovaný server) má v plug-in programu zavedenu také jak sdílenou knihovnu autentizace pomocí formulářů tak knihovnu forms-failover. Instance plug-in programu na druhém serveru obdrží failover cookie a zkoumá ji, aby určila předchozí metodu autentizace uživatele. Plug-in program na druhém serveru volá do sdílené knihovny autentizace failover–forms, aby z cookie vyjmul nezbytná data a poté tato data používá k autentizaci uživatele a k získání jeho pověření. Pokud je například v prostředí replikovaného plug-in programu povolena jak autentizace pomocí formulářů tak autentizace po přepnutí při selhání, musí být v konfiguračním souboru plug-in programu nakonfigurovány dvě oddělené knihovny. Jedna knihovna uvádí knihovnu metody autentizace pomocí formulářů. Další knihovna uvádí knihovnu metody autentizace po přepnutí při selhání. Příkladem záznamů konfiguračního souboru může být: [authentication-mechanisms] passwd-ldap = /opt/pdweb/lib/libldapauthn.so failover-password = /opt/pdweb/lib/libfailoverauthn.so
V tomto příkladě záznam stanzy passwd-ldap uvádí knihovnu autentizace pomocí formulářů plug-in programu. Záznam stanzyfailover-password uvádí knihovnu autentizace po přepnutí při selhání plug-in programu.
Dodatek dat pro failover cookie Plug-in program automaticky přidává určitá data z relace uživatele do každé cookie pro autentizaci po přepnutí při selhání. Plug-in program může být nakonfigurován, aby přidával další informace z dat klienta udržovaných v paměti cache pověření. Plug-in program může být také nakonfifurován, aby přidal uživatelsky definovaná data určitá pro jejich nasazení. Do cookie mohou být například přidány atributy uživatele obdržené přizpůsobenou službou CDAS.
80
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Standardně plug-in program přidává do každé cookie následující data: v Jméno uživatele Toto jméno odpovídá jménu použitému k identifikaci uživatele v registru uživatelů. Poznámka: Když autentizovaný uživatel použil k obdržení efektivní totožnosti od jiného uživatele funkci plug-in programu přepnutí uživatele, identita jiného uživatele není do cookie přidána. Do cookie je přidána pouze identita původně autentizovaného uživatele. v Metoda autentizace Metoda autentizace použitá k autentizaci uživatele pro plug-in program. v Čas vytvoření cookie Systémový čas vytvoření cookie. Plug-in program také vytváří seznam atributů, který obsahuje další data. Standardně obsahuje seznam atributů jednu hodnotu. v Úroveň autentizace Celočíselná hodnota odpovídající úrovni síly autentizace plug-in programu (také celočíselná hodnota), která je na lokálním serveru rozšířeném o plug-in program přiřazena metodě autentizace. Síla autentizace (také známá jako zvýšená autentizace) umožňuje uživateli se autentizovat do jiné metody autentizace, aniž by se musel odhlásit. Plug-in program definuje další data uživatele, která mohou být přidána do seznamu atributů cookie: v Časové označení doby trvání relace Když se uživatel autentizuje, plug-in program sleduje stáří nebo dobu trvání záznamu uživatele v paměti cache relace. Časové označení doby trvání relace se skládá z aktuálního času rozšířeného počtem vteřin konfigurovaným pro maximální čas, po který mohou data relace uživatele zůstat v paměti cache. Když aktuální čas systému překročí hodnotu časového označení, plug-in program zruší platnost záznamu uživatele v paměti cache (včetně pověření uživatele). Plug-in program může být nakonfigurován, aby do cookie přidal časové označení doby trvání relace.Když je toto časové označení do cookie přidáno, může být časovač doby trvání relace uchován přes události přepnutí při selhání. Takto mohou administrátoři plug-in programu vybrat, zda vynulovat nebo nevynulovat časovač relace klienta, když je zavedena na replikovaném serveru. Všimněte si, že úspěšné použití této funkce je závislé na synchronizaci časových základen mezi replikovanými servery rozšířenými o plug-in program. Pokud se výchylka časové základny stane velkou, relace vyprší v neurčených časech. v Časové označení nečinnosti relace Plug-in program také sleduje množství času, po který byl záznam uživatele v paměti cache relace plug-in programu nečinný. Když je relace uživatele nečinná po časové období delší, než je hodnota nastavená pro nečinnost relace, tak plug-in program zruší platnost relace uživatele. Časové označení nečinnosti relace může být také přidáno do cookie pro autentizaci po přepnutí při selhání. Toto časové označení se nepatrně liší od časového označení nečinnosti relace udržovaného pro paměť cache relace plug-in programu. Časový limit nečinnosti systému udržovaný pro paměť cache je určen kombinací dvou hodnot: – aktuální čas systému – maximální počet vteřin, po který může zůstat relace uživatele nečinná Když je tato hodnota přidána do cookie pro autentizaci po přepnutí při selhání, je zkombinována s jednou přídavnou hodnotou: Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
81
– maximální počet vteřin (interval) mezi aktualizacemi cookie pro autentizaci po přepnutí při selhání Nastavení intervalu mezi aktualizací failover cookies ovlivní výkon. Administrátoři musí vybrat rovnováhu mezi optimálním výkonem a absolutní přesností časovače nečinnosti v cookie. Abyste uchovali časovač nečinnosti nejpřesnější, měl by být aktualizován pokaždé, kdy uživatel vytvoří požadavek. Avšak častá aktualizace obsahu cookie způsobuje aktivitu požadovanou k provedení úlohy a snižuje výkon. Každý administrátor musí zvolit interval, který nejlépe vyhovuje nasazení plug-in programu. V některých případech je aktualizace failover cookie s každým požadavkem uživatele nezbytná. V jiných případech může administrátor vybrat, že se ve failover cookie nebude časovač nečinnosti nikdy aktualizovat. v Další rozšířené atributy Administrátoři mohou nakonfigurovat plug-in program, aby vložil do failover cookie přizpůsobenou sadu atributů. Atributy mohou být uvedeny jednotlivě nebo ve skupině. Abyste uvedli skupinu atributů, použijte vzor zástupného znaku shodující se v záznamech konfiguračního souboru. Tato funkce je užitečná v nasazeních, která používají přizpůsobené knihovny autentizace (jako jsou servery CDAS) také k vložení speciálních atributů do pověření uživatele. Uvedením těchto atributů v konfiguračním souboru plug-in programu může administrátor zajistit, že jsou atributy během autentizace po přepnutí při selhání dostupné pro přidání do znovu vytvořených pověření uživatele. Poznámka: Maximální velikost cookie pro autentizaci po přepnutí při selhání jsou 4 kilobajty (4096 bajtů).
Vyjmutí dat z failover cookie Když se vyskytne autentizace po přepnutí při selhání, plug-in program obdrží cookie pro autentizaci po přepnutí při selhání a standardně z každé cookie vyjímá následující data: v jméno uživatele v metoda autentizace v čas vytvoření cookie Plug-in program nejdříve odečtením času vytvoření cookie určuje, zda je platná a porovnává tuto hodnotu se záznamem konfiguračního souboru plug-in programu pro dobu trvání failover cookie. Pokud byla doba trvání cookie překročena, není cookie platná a autentizace po přepnutí při selhání není provedena. Pokud nebyla doba trvání cookie překročena, použije plug-in program k autentizaci uživatele jeho jméno a metodu autentizace a vytvoří pověření uživatele. Plug-in program dále kontroluje nastavení konfigurace, aby určil, zda by měla být vyjmuta a zhodnocena další data cookie. Všimněte si, že plug-in program z cookie pro autentizaci po přepnutí při selhání nevyjímá žádné další atributy. Každý další atribut, který se má vyjmout, musí být uveden v konfiguračním souboru. Abyste získali skupiny atributů, můžete použít shodu vzoru zástupného znaku. Plug-in program může být nakonfigurován, aby vyjmul následující definované atributy: v Úroveň autentizace Když je vyjmuta tato hodnota, používá ji plug-in program, aby zajistil, že je uživatel autentizován metodou nezbytnou k udržení zadané úroveň autentizace. Všimněte si, že plug-in program může obdržet úrovně autentizace z několika různých míst: – Failover cookie – Knihovna autentizace po přepnutí při selhání – Služba CDAS
82
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
– Služba pojmenování Úroveň autentizace vyjmutá z failover cookie má přednost před úrovněmi přijatými z jiných míst. v Časové označení doby trvání relace Plug-in program může použít toto časové označení k určení, zda záznam uživatele v paměti cache původní relace serveru mohl vypršet. Jestli mohl, plug-in program vyřadí cookie a všechny její potenciální atributy pověření. Doba trvání relace není uchována a uživatel je vyzván, aby se přihlásil. v Časové označení nečinnosti relace Plug-in program může použít toto časové označení k určení, zda záznam uživatele v paměti cache původní relace serveru mohl být příliš dlouho neaktivní. Jestli mohl, plug-in program vyřadí cookie a všechny její potenciální atributy pověření. Doba trvání relace není uchována a uživatel je vyzván, aby se přihlásil. Poznámka: Úspěšné použití těchto časových označení vyžaduje synchronizaci časových základen mezi replikovanými servery plug-in programu. Pokud se výchylka časové základny stane velkou, relace vyprší nebo se stane nečinnou v neurčených časech. v Další rozšířené atributy To zahrnuje uživatelsky definované přizpůsobené atributy, jako jsou ty vygenerované službami CDAS. Plug-in program přidává atributy do pověření uživatele. Atributy, které nejsou uvedeny v konfiguračním souboru plug-in programu, budou ignorovány a nebudou vyjmuty. Administrátoři mohou uvést, že určité atributy musí být během vyjmutí failover cookie ignorovány. Ačkoli je ignorovat standardní chování, může být uvedení těchto atributů užitečné, aby například zajistilo, že jsou atributy uživatele přijaty z registru uživatelů místo z failover cookie.
Autentizace pomocí failover cookie po celé šíři domény Plug-in program podporuje volitelnou konfiguraci, která umožňuje, aby byly cookies autentizace po přepnutí při selhání označeny jako dostupné k použití během autentizace pro libovolné servery rozšířené o plug-in program v Tivoli Access Manager doméně. Tato volba konfigurace umožňuje, aby byly cookies autentizace po přepnutí při selhání použity v nasazeních, které nemusí nutně mít prostředkem pro vyrovnávání zatížení a replikované servery rozšířené o plug-in program. Když prochází relace klienta autentizací po přepnutí při selhání k replikovaným serverům rozšířeným o plug-in program, pokračuje klient k přístupu ke stejné sadě chráněných zdrojů. Když prochází relace klienta autentizací po přepnutí při selhání k serveru rozšířenému o plug-in program, který není replikován, je možné, že klientovi bude k dispozici odlišná sada zdrojů.V širokých nasazeních je toto rozdělení zdrojů v Tivoli Access Manager doméně standardní. Toto rozdělení může být použito z důvodů výkonu a pro administrativní úmysly. Autentizace pomocí failover cookie po celé šíři domény se může použít k přesměrování klienta do jiného serveru v okamžiku, kdy ho požadavky klienta zavedly k požadování zdroje, který není přes lokální server k dispozici. V tomto případě je klient (prohledávací program) přesměrován do jiného serveru rozšířeného o plug-in program. Přijímající plug-in program může být nakonfigurován, aby vyhledával cookies autentizace po přepnutí při selhání. Plug-in program se pokouší o autentizaci klienta a rozeznává cookie autentizace po přepnutí při selhání. Použitím cookie nemusí plug-in program vyzývat klienta k informaci o přihlášení, ale místo toho s ním může zavést relaci a může vytvořit platnou sadu jeho pověření.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
83
Zpětná kompatibilita Failover cookies vygenerované verzí 5.1 plug-in programu mohou být pochopeny a přečteny (zpracovány) plug-in programy verzí starších než je verze 5.1. Také failover cookies vygenerované staršími plug-in programy (před verzí 5.1) mohou být pochopeny a přečteny (zpracovány) plug-in programy verze 5.1. Moduly CDAS zapsané do failover cookies přizpůsobení (před verzí 5.1) plug-in programu budou pracovat s verzí 5.1 plug-in programu. Abyste zajistili úplnou zpětnou kompatibilitu, jsou poskytovány následující funkce: v Plug-in program může být nakonfigurován, aby, pokud není přítomno časové označení doby trvání relace, autentizoval uživatele na základě obsahu failover cookie. V cookies autentizace po přepnutí při selhání před verzí 5.1 není časové označení doby trvání relace přítomno. v Plug-in program může být nakonfigurován, aby, pokud není přítomno časové označení nečinnosti relace, autentizoval uživatele na základě obsahu failover cookie. V cookies autentizace po přepnutí při selhání před verzí 5.1 není časové označení nečinnosti relace přítomno. v Algoritmus použitý k zašifrování dat klienta v cookies autentizace po přepnutí při selhání byl pro verzi 4.1 plug-in programu aktualizován. Když používáte plug-in program verzí starších než verze 4.1, může být nastavení konfiguračního souboru nastaveno, aby povolilo přístup ke cookies staršího stylu. v Plug-in program může být nakonfigurován, aby nepoužil na řetězcích ve failover cookie zakódování UTF-8. Tím, že senepoužije zakódování UTF-8 pro cookies vytvořené na verzi 5.1 plug-in programu, mohou být cookies pochopeny a přečteny (zpracovány) staršími verzemi plug-in programu.
Aktualizace autentizace po přepnutí při selhání V konfiguračním souboru plug-in programu nahrazují stanzy [failover-add-attributes] a [failover-restore-attributes] stanzu verzí starších než je verze 5.1 [failover-attributes]. Během aktualizace z Tivoli Access Manager verze 4.1 na aktuální Tivoli Access Manager verzi je stanza [failover-attributes] a její obsah migrován do stanzy [failover-add-attributes] stanza. Aktualizace je automatická a provede se při instalaci plug-in programu. Tyto záznamy se nemusí manuálně aktualizovat.
Konfigurace autentizace po přepnutí při selhání Tato část popisuje, jak nakonfigurovat autentizaci po přepnutí při selhání. Pokud nemáte zvládnuté koncepty autentizace po přepnutí při selhání, vyhledejte část “Koncepty autentizace po přepnutí při selhání” na stránce 78. Abyste nakonfigurovali autentizaci po přepnutí při selhání, proveďte následující kroky: 1. Zastavte server plug-in programu. 2. Abyste umožnili autentizaci po přepnutí při selhání, proveďte následující úlohy: a. “Aktivujte autentizaci pomocí failover cookies” na stránce 85 b. “Uveďte knihovnu autentizace po přepnutí při selhání” na stránce 86 c. “Vytvořte klíč šifrování pro data cookie” na stránce 86 d. “Uveďte dobu trvání cookie” na stránce 87 e. “Uvedení UTF-8 zakódování BA hlaviček” na stránce 63
84
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
3. Volitelně můžete nakonfigurovat plug-in program, aby uchoval stav relace přes relace autentizace po přepnutí při selhání. Pokud to odpovídá vašemu nasazení, proveďte následující instrukce: a. “Přiřaďte časové označení doby trvání relace” na stránce 88 b. “Přiřaďte časové označení aktivity relace” na stránce 89 c. “Přidejte interval pro aktualizaci časového označení aktivity” na stránce 89 4. Volitelně můžete nakonfigurovat plug-in program, aby do failover cookie přidal rozšířené atributy. v “Přidejte rozšířené atributy” na stránce 89 5. Když jste nakonfigurovali plug-in program, aby přidal do failover cookie atributy, musíte ho nakonfigurovat, aby při jejím čtení atributy vyjmul: v “Uveďte atributy pro extrahování” na stránce 90 6. Volitelně můžete umožnit použití cookies pro autentizaci po přepnutí při selhání na libovolném serveru rozšířeném o plug-in program v doméně. Pokud to odpovídá vašemu nasazení, vyhledejte v “Aktivujte failover cookies po celé šíři domény” na stránce 91 7. Pokud potřebujete uchovat zpětnou kompatibilitu s cookies pro autentizaci po přepnutí při selhání generovanými servery rozšířenými o plug-in program z verzí předcházejících verzi 5.1, proveďte následující instrukce: a. “Uvedení UTF-8 zakódování BA hlaviček” na stránce 63 b. “Požadujte ověření platnosti časového označení doby trvání” na stránce 91 c. “Požadujte ověření platnosti časového označení aktivity” na stránce 91 d. “Aktivujte zpětnou kompatibilitu pro šifrování” na stránce 92 8. Po dokončení všech instrukcí použitelných pro vaše nasazení restartujte server.
Aktivujte autentizaci pomocí failover cookies Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Failover cookies je možné nakonfigurovat i tak, aby prováděly autentizaci a úlohy zpracování následujícího po autorizaci. Plug-in programy nakonfigurované pro zpracování následující po autorizaci pomocí failover cookies zašifrují a uloží pověření do failover cookie v odpovědi na transakci. Plug-in programy nakonfigurované tak, aby používaly failover cookies pro autentizaci, opětovně autentizují klienty pomocí zašifrovaných pověření z failover cookie, které byly nalezeny v odpovědi na transakci. Pokud chcete aktivovat autentizaci a zpracování následující po autorizaci pomocí failover cookies, přiřaďte slovo ’failover’ k parametrům authentication a post-authzn ; tzn.: [common-modules] authentication = failover post-authzn = failover
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že je zde uveden záznam pro autentizaci po přepnutí při selhání: [modules] failover = pdwpi-failovercookie-module
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
85
Uveďte knihovnu autentizace po přepnutí při selhání Editujte konfigurační soubor plug-in programu.Ve stanze [authentication-mechanisms] nekomentujte záznam pro typ (nebo typy) autentizace, které musí podporovat failover cookies. Přidejte jméno knihovny cookie autentizace po přepnutí při selhání knihovny odpovídající typu operačního systému. Standardní záznam konfiguračního souboru je: [authentication-mechanisms] #failover-password = failover_password_library_filename #failover-token-card = failover_token_card_filename #failover-certificate = failover_certificate_filename #failover-http-request = failover_http_request_filename #failover-cdsso = failover_cdsso_filename #failover-kerberosv5 = failover_kerberos_library
Plug-in program dodává jednu standardní sdílenou knihovnu přepnutí při selhání, která funguje pro všechny výše uvedené metody autentizace. Jména knihovny naleznete v následující tabulce: Tabulka 13. Jména souboru knihovny autentizace po přepnutí při selhání Solaris
libfailoverauthn.so
Linux
libfailoverauthn.so
AIX
libfailoverauthn.a
Windows
failoverauthn.dll
Abyste například umožnili autentizaci po přepnutí při selhání klientům, kteří se původně autentizovali autentizací pomocí formulářů na platformě, nekomentujete záznam failover-password a přidejte jméno knihovny: [authentication-mechanisms] failover-password = libfailoverauthn.so
Když jste rozvinuli knihovnu CDAS implementující přizpůsobenou verzi autentizace po přepnutí při selhání pro jednu nebo více metod autentizace, vložte alternativně jako hodnotu pro klíčové slovo konfiguračního souboru jméno přizpůsobené CDAS. Pokud jste například rozvinuli přizpůsobenou CDAS pro autentizaci pomocí formulářů, zadejte absolutní název cesty: [authentication-mechanisms] failover-password = /dir_name/custom_cdas_failover_library.so
Vytvořte klíč šifrování pro data cookie Použijte obslužný program cdsso_key_gen, aby zabezpečil data cookie. Tento obslužný program vygeneruje symetrický klíč, který zašifruje a dešifruje data v cookie. Upozornění: Pokud nenakonfigurujete plug-in program, aby zašifroval cookies autentizace po přepnutí při selhání a umožnili jste autentizaci po přepnutí při selhání, plug-in program vygeneruje chybu a odmítne se spustit. Cookies autentizace po přepnutí při selhání musí být zašifrovány. 1. Spusťte obslužný program na jednom z replikovaných serverů.Z příkazového řádku uveďte umístění souboru klíčů, který chcete vytvořit. Musíte uvést absolutní název cesty. Například: UNIX: # /opt/pdwebrte/bin/cdsso_key_gen absolute_pathname_for_keyfile
Windows:
86
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
MSDOS> C:\Program Files\Tivoli\PDWebrte\bin\cdsso_key_gen absolute_pathname_for_keyfile
Souboru klíčů můžete dát libovolné odpovídající jméno, jako je /opt/pdwebrte/lib/wpi.key. 2. Editujte konfigurační soubor plug-in programu.Ve stanze [failover] uveďte umístění souboru klíčů. [failover] failover-cookies-keyfile = absolute_pathname_for_keyfile
3. Ručně zkopírujte soubor klíčů do každého zbývajícího replikovaného serveru. 4. V každém replikovaném serveru editujte konfigurační soubor plug-in programu, aby dodal správný název cesty do failover-cookies-keyfile ve stanze [failover].
Uveďte dobu trvání cookie Editujte konfigurační soubor plug-in programu.Uveďte platnou dobu trvání pro failover cookie. [failover] failover-cookie-lifetime = 30
Předvolená hodnota je 30 minut.
Uveďte UTF-8 zakódování řetězců cookie Editujte konfigurační soubor plug-in programu.Uveďte, zda by měl či neměl plug-in program použít ve failover cookies UTF-8 zakódování. [failover] use-utf8 = true
Předvolená hodnota je true. UTF-8 zakódování by se mělo použít, když nejsou jména uživatele nebo atributy pověření v cookie kódovány ve stejné kódové stránce jako ty, které používá server rozšířený o plug-in program. Plug-in program standardně UTF-8 zakódování podporuje. Když všechny servery v nasazení plug-in programu pužívají UTF-8 zakódování, nechte tuto hodnotu na true. Zpětná kompatibilita Instalace plug-in programu starší než je verze 5.1 UTF-8 zakódování nepoužívají. Tudíš cookies vytvořené těmito servery nemají UTF-8 zakódování ve svých řetězcích. Když instance plug-in programu používá plug-in program z verzí starších než je verze 5.1, tak by plug-in program neměl UTF-8 zakódování použít. Pro zpětnou kompatibilitu nastavte use-utf8 na false. [failover] use-utf8 = false
Abyste získali další informace o podpoře plug-in programu pro UTF-8 zakódování, vyhledejte část “Podpora jazyků a znakové sady” na stránce 35.
Uveďte úroveň autentizace Plug-in program poskytuje několik různých cest, jak uvést úroveň autentizace. Pro failover cookies jsou použitelné dvě metody. Jedna metoda nastavuje úroveň autentizace ve failover cookie. Druhá metoda nastavuje úroveň při volání knihovny autentizace po přepnutí při selhání. Když se použijí obě metody, má úroveň autentizace ve failover cookie přednost před nastavením úrovně při volání knihovny. Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
87
Když není konfigurována žádná z metod, je úroveň autentizace stanzou [authentication-levels] nastavena na úroveň přidruženou k metodě přepnutí při selhání. Metody jsou: v Uveďte úroveň autentizace v cookie autentizace po přepnutí při selhání. Přidejte úroveň autentizace do konfiguračního souboru plug-in programu. Musíte použít klíčové slovo záznamu stanzy AUTHENTICATON_LEVEL: [failover-add-attributes] or [failover-add-attributes:virtual-host] AUTHENTICATION_LEVEL = add
Skutečnou hodnotou pro AUTHENTICATION_LEVEL je celé číslo, které plug-in program vnitřně sleduje.V této stanze nemusíte uvést celé číslo. Abyste zadržely úroveň autentizace volitelně zavedenou do cookie odesílatelem zprávy, musí být hodnota také nakonfigurována, aby byla uchována na přijímajícím konci pomocí následujícího záznamu: [failover-restore-attributes] or [failover-restore-attributes:virtual-host] AUTHENTICATION_LEVEL = preserve
v Uveďte úroveň autentizace, když voláte knihovnu autentizace po přepnutí při selhání. Když konfigurujete knihovnu autentizace po přepnutí při selhání pro plug-in program nebo knihovnu CDAS, můžete volitelně uvést úroveň autentizace, která se má přiřadit autentizovanému uživateli. Úroveň autentizace je celé číslo, které mapuje pro určitou metodu autentizace, jako část funkce autentizace plug-in programu. Přidejte parametr příkazového řádku do záznamu konfiguračního souboru pro odpovídající knihovnu autentizace po přepnutí při selhání. Syntaxe je: [authentication-mechanisms] failover_authentication_method = failover_authentication_libary& -l level_number
Hodnota level_number musí odpovídat platnému celému číslu, jak je uvedeno ve stanze [authentication-levels] v konfiguračním souboru plug-in programu. Abyste například na systémech Solaris aktivovali autentizaci po přepnutí při selhání pro autentizaci pomocí formulářů, a abyste uživateli přiřadili úroveň autentizace ″3″, vytvořte následující záznam konfiguračního souboru: [authentication-mechanisms] failover-password = libfailoverauthn.so& -l 3
Přiřaďte časové označení doby trvání relace Plug-in program počítá časové označení doby trvání relace kombinací následujících hodnot: v Aktuální čas systému v Maximální doba trvání ve vteřinách, po kterou může záznam v paměti cache pověření plug-in programu existovat Maximální doba trvání relace ve vteřinách je uvedena ve stanze [session] konfiguračního souboru plug-in programu: [sessions] timeout = 3600
Abyste tuto hodnotu přidali do cookie autentizace po přepnutí při selhání, přidejte do konfiguračního souboru plug-in programu následující záznam: [failover-add-attributes] session-lifetime-timestamp = add
Všimněte si, že tento atribut nemůže být nastaven shodou zástupného znaku. Musí být zadán přesný záznam session-lifetime-timestamp.
88
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Přiřaďte časové označení aktivity relace Plug-in program počítá časové označení aktivity relace, tím že dává dohromady tyto hodnoty: v Čas systému. v Maximální doba trvání nečinných záznamů v paměti cache pověření. Maximální doba trvání nečinných procesů je nastavena ve stanze [sessions] v konfiguračním souboru: [session] inactive-timeout = 600
Předvolená hodnota je 600 vteřin. v Interval pro aktualizování cookie autentizace po přepnutí při selhání. Tato hodnota je nastavena ve stanze [failover] v konfiguračním souboru: [failover] failover-update-cookie = -1
Předvolená hodnota je -1 vteřina. Pokud je nastaveno na negativní celé číslo, tak bude failover cookie aktualizována při výskytu autentizace, nebo když je obnoveno pověření. Abyste získali další informace, prohlédněte část “Přidejte interval pro aktualizaci časového označení aktivity”. Abyste tuto hodnotu přidali do cookie autentizace po přepnutí při selhání, přidejte do konfiguračního souboru plug-in programu následující záznam: [failover-add-attributes] session-activity-timestamp = add
Všimněte si, že tento atribut nemůže být nastaven shodou zástupného znaku. Musí být zadán přesný záznam session-activity-timestamp.
Přidejte interval pro aktualizaci časového označení aktivity Časové označení aktivity relace může být ve failover cookie volitelně aktualizováno během relace uživatele. Tento záznam obsahuje celé číslo pro interval (ve vteřinách) mezi aktualizací časového označení failover cookie. Standardní záznam: [failover] failover-update-cookie = -1
Když je záznam failover-update-cookie nastaven na 0, je poslední časové označení aktivity aktualizováno s každým požadavkem. Když je záznam failover-update-cookie nastaven na celé číslo menší než 0 (libovolné záporné číslo), není poslední časové označení aktivity aktualizováno nikdy. Když je záznam failover-update-cookie nastaven na celé číslo větší než 0, je časové označení aktivity relace v cookie aktualizováno v intervalech tohoto počtu vteřin. Hodnota vybraná pro tento záznam stanzy může ovlivnit výkon. Viz část “Dodatek dat pro failover cookie” na stránce 80.
Přidejte rozšířené atributy Plug-in program může být volitelně nakonfigurován, aby do cookie autentizace po přepnutí při selhání umístil kopii určených rozšířených atributů z pověření uživatele. Standardně nejsou rozšířené atributy nakonfigurovány.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
89
Abyste přidali rozšířené atributy, přidejte do stanzy [failover-add-attributes] v konfiguračním souboru plug-in programu záznamy. Syntaxe je: [failover-add-attributes] attribute_pattern = add
Hodnota pro attribute_pattern může být jméno určitého atributu, nebo výraz zástupného znaku necitlivý na velikost písma, který odpovídá více jak jednomu jménu atributu. Abyste například uvedli všechny atributy s předponou tagvalue_, přidejte následující záznam: [failover-add-attributes] tagvalue_* = add
Pořadí záznamů stanzy je důležité. Pravidla, která se v záznamu [failover-add-attributes] objeví dříve, mají přednost před těmi, které jsou ve stanze umístěny později. Atributy, které neodpovídají žádnému vzoru zástupného znaku, nebo nejsou uvedeny explicitně, nejsou do failover cookie přidány.
Uveďte atributy pro extrahování Plug-in program může být volitelně nakonfigurován, aby z cookie autentizace po přepnutí při selhání extrahoval atributy a umístil je v pověření uživatele. Standardně nejsou atributy pro extrahování nakonfigurovány. Atributy, které se mají extrahovat, jsou uvedeny ve stanze [failover-restore-attributes] konfiguračního souboru plug-in programu. Syntaxe je: [failover-restore-attributes] attribute_pattern = {preserve|refresh}
Hodnota preserve sděluje plug-in programu, aby extrahoval atribut a vložil ho do pověření. Hodnoty nastavené touto metodou jsou nadřízené atributům stejného jména, které mohou být nastaveny, když CDAC autentizace vytváří nové pověření. Hodnota refresh sděluje plug-in programu, aby podmíněně extrahoval atribut a vkládal ho do pověření pouze, pokud nebyl při vytváření nového pověření pomocí CDAS autentizace do pověření vložen atribut stejného jména. Hodnota pro attribute_pattern může být jméno určitého atributu, nebo výraz zástupného znaku necitlivý na velikost písma, který odpovídá více jak jednomu jménu atributu. Abyste například extrahovali všechny atributy s předponou tagvalue_, přidejte následující záznam: [failover-restore-attributes] tagvalue_* = preserve
Atributy, které se neshodují se žádným vzorem zadaným hodnotou preserve nejsou z cookie autentizace po přepnutí při selhání extrahovány. Pořadí záznamů stanzy je důležité. Pravidla, která se v záznamu [failover-restore-attributes] objeví dříve, mají přednost před těmi, které jsou ve stanze umístěny později. Následující hodnoty nelze porovnat pomocí vzoru zástupného znaku, ale musí být pro extrakci definovány explicitně: v Úroveň autentizace [failover-restore-attributes] AUTHENTICATION_LEVEL = preserve
v Časové označení doby trvání relace [failover-restore-attributes] session-lifetime-timestamp = preserve
90
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
v Časové označení nečinnosti relace [failover-restore-attributes] session-inactivity-timestamp = preserve
Aktivujte failover cookies po celé šíři domény Můžete povolit, že se cookie autentizace po přepnutí při selhání použije libovolným plug-in programem ve stejné doméně jako plug-in program, který vytváří cookie. Tato funkce je ovládana záznamem stanzy ve stanze [failover]. Funkcionalita failover cookie po celé šíři domény je standardně zablokována: [failover] enable-failover-cookie-for-domain = false
Abyste tuto funkci aktivovali, nastavte enable-failover-cookie-for-domain na true: [failover] enable-failover-cookie-for-domain = true
Abyste získali informace o dopadech aktivování tohoto záznamu stanzy, prohlédněte část “Autentizace pomocí failover cookie po celé šíři domény” na stránce 83.
Požadujte ověření platnosti časového označení doby trvání Plug-in program může být volitelně nakonfigurován, aby požadoval, že každá cookie autentizace po přepnutí při selhání obsahuje časové označení doby trvání relace. Standardně není časové označení doby trvání relace požadováno. Standardní záznam konfiguračního souboru je: [failover] failover-require-lifetime-timestamp-validation = false
Tento záznam stanzy se primárně použije pro zpětnou kompatibilitu. Upozornění: Pro zpětnou kompatibilitu s failover cookies vytvořenými plug-in programy starší verze než 5.1 nastavte tento záznam na false. Cookies autentizace po přepnutí při selhání vytvořené plug-in programy starší verze než 5.1 toto časové označení neobsahují. v Když je tato hodnota false a z failover cookie je postrádáno časové označení doby trvání relace, zobrazí přijímající server cookie jako valid. v Když je tato hodnota true a z failover cookie je postrádáno časové označení doby trvání relace, zobrazí přijímající server cookie jako not valid. v Když je tato hodnota false nebo true a časové označení doby trvání relace je ve failover cookie přítomno, přijímající server ho ohodnotí. Pokud není časové označení platné, autentizace selže. Pokud je časové označení platné, proces autentizace proběhne. Poznámka: Časové označení doby trvání relace je konfigurováno odděleně od časového označení aktivity relace.
Požadujte ověření platnosti časového označení aktivity Plug-in program může být volitelně nakonfigurován, aby požadoval, že každá cookie autentizace po přepnutí při selhání obsahuje časové označení aktivity relace. Standardně není časové označení aktivity relace požadováno. Standardní záznam konfiguračního souboru je: [failover] failover-require-activity-timestamp-validation = false
Tento záznam stanzy se primárně použije pro zpětnou kompatibilitu.
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
91
Upozornění: Pro zpětnou kompatibilitu s failover cookies vytvořenými plug-in programy starší verze než 5.1 nastavte tento záznam na false.Cookies autentizace po přepnutí při selhání vytvořené plug-in programy starší verze než 5.1 toto časové označení neobsahují. v Když je tato hodnota false a z failover cookie je postrádáno časové označení aktivity relace, zobrazí přijímající server cookie jako valid. v Když je tato hodnota true a z failover cookie je postrádáno časové označení aktivity relace, zobrazí přijímající server cookie jako not valid. v Když je tato hodnota false nebo true a časové označení aktivity relace je ve failover cookie přítomno, přijímající server ho ohodnotí.Pokud není časové označení platné, autentizace selže. Pokud je časové označení platné, proces autentizace proběhne. Poznámka: Časové označení aktivity relace je konfigurováno odděleně od časového označení doby trvání relace.
Aktivujte zpětnou kompatibilitu pro šifrování Pro Tivoli Access Manager verzi 4.1 byla úroveň zabezpečení pro šifrování cookie autentizace po přepnutí při selhání zvýšena. Tento šifrovací algoritmus není zpětně kompatibilní. Pokud cookies autentizace po přepnutí při selhání integrujete pomocí serverů rozšířených o plug-in program používajících verze Tivoli Access Manager starší, než je verze 4.1, musíte uvést v konfiguračním souboru plug-in programu jeho nastavení, abyste aktivovali zpětnou kompatibilitu. Zpětná kompatibilita se starším šifrovacím algoritmem není standardně aktivována: [pdweb-plugins] pre-410-compatible-tokens = false
Abyste aktivovali zpětnou kompatibilitu, nastavte pre-410-compatible-tokens na true: [pdweb-plugins] pre-410-compatible-tokens = true
Konfigurace autentizace pomocí IV hlaviček Produkt Tivoli Access Manager podporuje autentizaci pomocí informací v interně generovaných hlavičkách dodávaných kompatibilním klientem nebo proxy agentem. Z historických důvodů jsou tyto hlavičky nazývány IV (IntraVerse) hlavičky. Pokud webový server rozšířený o plug-in program obdrží požadavek z ověřené aplikace, jako např. ze serveru WebSEAL nebo MPA (multiplexing proxy agent) agenta, je možné vložit IV hlavičky do požadavku předaného plug-in programu. IV hlavičky obsahují informace, které identifikují původního klienta, a ne předávající server. Informace v hlavičkách se používají k vytvoření pověření původního klienta pro účely autorizace. Podobně pokud webový server rozšířený o plug-in program předá požadavek dalšímu serveru produktu Tivoli Access Manager, který je schopen rozeznávat IV hlavičky, proxy plug-in programu může vložit IV hlavičky identifikující původního klienta. Plug-in program může být nakonfigurován tak, aby IV hlavičky používal pro zpracování následující po autorizaci nebo pro požadavky na autentizaci. Je-li nakonfigurován pro zpracování následující po autorizaci, plug-in program po dokončení úspěšné autentizace změní požadavek transakce tak, že vloží pravou totožnost klienta jako IV hlavičku. Tyto hlavičky mohou být původním webovým serverem přeposlány jinému serveru. Je-li plug-in program nakonfigurován tak, aby používal IV hlavičky k provádění autentizace klienta, pak tento plug-in program vytvoří pověření klienta pomocí totožnosti, kterou získá z IV hlavičky nalezené v požadavku transakce. Protože je pro klienty jednoduché padělat IV
92
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
hlavičky, je podobné pověření vytvořeno pouze tehdy, pokud je požadavek obdržen přes ověřeného MPA (multiplexing proxy agent).Viz též část “Podpora MPA (Multiplexing Proxy Agents)” na stránce 103. Pro autentizaci platí, že IV hlavičky je možné nakonfigurovat tak, aby přijímaly jednu, některé nebo všechny hlavičky iv-user, iv-user-l, iv-creds nebo iv-remote-address v požadavku jako potvrzení o autentizaci, pokud byly tyto přijaty prostřednictvím proxy. Hlavička iv-remote-address se používá k zaznamenání skutečné vzdálené adresy uživatele. Jsou-li nakonfigurovány pro zpracování následující po autorizaci, jsou IV hlavičky vloženy s jednou, některými nebo všemi HTTP hlavičkami iv-user, iv-user-l, iv-creds, iv-groups, a/nebo iv-remote-address do požadavku. Tabulka 14. Popis polí IV hlavičky Pole IV hlavičky
Popis
iv-user
Krátké jméno uživatele Access Manager. Standardně je nastaveno na neautentizován, pokud je klient neautentizován (neznámý).
iv-user-l
Plné jméno domény uživatele (dlouhý formát). Např. rozlišovací jméno LDAP.
iv-groups
Seznam skupin, jejichž členem je uživatel.
iv-creds
Neprůhledně zakódovaná struktura dat představující pověření uživatele produktu Tivoli Access Manager.
iv-remote-address
IP adresa klienta. Tato hodnota by mohla představovat i IP adresu proxy serveru nebo NAT (network address translator).
Poznámka: Access Manager věří pouze hlavičkám, které obdržel od důvěryhodných a ověřených předřazených počítačů. Předřazený počítač je považován za ověřený a důvěryhodný, pokud je rozeznáván jako agent MPA (Multiplexing Proxy Agent). Podrobné informace o konfiguraci plug-in programu pro podporu agentů MPA najdete v části “Podpora MPA (Multiplexing Proxy Agents)” na stránce 103.
Aktivace autentizace pomocí IV hlaviček Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete aktivovat autentizaci pomocí IV hlaviček, přiřaďte odkaz iv-headers k parametru authentication; to znamená: [common-modules] authentication = iv-headers
Pokud chcete aktivovat IV hlavičky pro zpracování následující po autorizaci, přiřaďte hodnotu iv-headers parametru post-authzn ve stanze [common-modules] konfiguračního souboru pdwebpi.conf: [common-modules] post-authzn = iv-headers
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že je zde uveden záznam pro autentizaci pomocí IV hlavičky: [modules] iv-headers = pdwpi-iv-headers-module
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
93
Konfigurace parametrů IV hlaviček Parametry autentizace pomocí IV hlaviček jsou nakonfigurovány ve stanze [iv-headers] konfiguračního souboru pdwebpi.conf. Parametr accept určuje typy IV hlaviček, které budou uznány během provádění autentizace pomocí IV hlaviček. Standardně plug-in program uznává všechny typy IV hlaviček. Platné volby jsou: all, iv-creds, iv-user, iv-user-l, iv-remote-address. Pokud chcete zadat více než jeden typ hlavičky, oddělte hodnoty čárkou. Například: [iv-headers] accept = iv-creds,iv-user
Parametr generate určuje typ IV hlaviček, který se má vytvořit, je-li přeposílán požadavek prošlý přes proxy. Standardně plug-in program vygeneruje všechny typy IV hlaviček, pokud přeposílá požadavky prošlé přes proxy. Platné volby jsou: all, iv-creds, iv-user, iv-user-l, iv-remote-address. Pokud chcete zadat více než jeden typ hlavičky, oddělte hodnoty čárkou.
Uveďte UTF-8 zakódování IV hlaviček Editujte konfigurační soubor plug-in programu.Uveďte, zda by měl či neměl plug-in program použít pro IV hlavičky UTF-8 zakódování. [iv-headers] use-utf8 = true
Předvolená hodnota je true. Abyste získali další informace o podpoře plug-in programu pro UTF-8 zakódování, vyhledejte část “Podpora jazyků a znakové sady” na stránce 35.
Konfigurace mechanismu pro autentizaci pomocí IV hlaviček pro iv-remote-address Pokud v IV hlavičce používáte iv-remote-address, musíte uvést sdílenou knihovnu pro mapování HTTP informací autentizace pomocí hlavičky. Mechanismus autentizace http-request udává sdílenou knihovnu pro mapování informací o autentizaci pomocí HTTP hlavičky. v Na operačním systému UNIX je soubor, který poskytuje zabudované mapovací funkce, tzv. sdílená knihovna s názvem libhttpauth. v Na operačním systému Windows je soubor, který poskytuje zabudované mapovací funkce, tzv. DLL s názvem httpauthn. Mechanismus autentizace pomocí HTTP hlaviček můžete nakonfigurovat tak, že zadáte parametr http-request spolu se jménem sdílené knihovny specifickým pro danou platformu do stanzy [authentication-mechanisms] konfiguračního souboru pdwebpi.conf tak, jak je uvedeno níže: Solaris: [authentication-mechanisms] http-request = libhttpauth.so
Windows: [authentication-mechanisms] http-request = httpauthn.dll
94
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Konfigurace autentizace pomocí HTTP hlaviček Produkt Tivoli Access Manager podporuje autentizaci pomocí informací v uživatelsky definovaných HTTP hlavičkách, dodávaných klientem nebo proxy agentem. Tento mechanismus vyžaduje funkci mapování (sdílenou knihovnu), které namapuje ověřená (předem autentizovaná) data hlavičky na totožnost produktu Tivoli Access Manager. Plug-in program může vzít tuto totožnost a vytvořit pověření pro uživatele. Plug-in program předpokládá, že data uživatelsky definované HTTP hlavičky byla již dříve autentizována proxy agentem. Z tohoto důvodu bude modul pracovat pouze tehdy, pokud bude plug-in program umístěn za autentizovaným agentem webové proxy, a pokud bude parametr mpa-enabled ve stanze [pdweb-plugins] nastaven na hodnotu true. Standardně je tato knihovna vybudována tak, aby mapovala data z hlaviček pověřené proxy.
Aktivace autentizace pomocí HTTP hlaviček Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete aktivovat autentizaci pomocí HTTP hlaviček, přiřaďte slovo http-hdr k parametru authentication; to znamená: [common-modules] authentication = http-hdr
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že je zde uveden záznam pro autentizaci pomocí HTTP hlavičky: [modules] http-hdr = pdwpi-httphdr-module
Určení typů hlaviček Musíte určit všechny podporované typy HTTP hlaviček ve stanze [http-hdr] konfiguračního souboru pdwebpi.conf. [http-hdr] header = typ-hlavičky
Standardní konfigurace HTTP hlaviček povoluje, aby byla uvedena pouze jedna hlavička, například: [modules] http-hdr = pdwpi-httphdr-module
Pokud chcete uvést více HTTP hlaviček, musíte nakonfigurovat více instancí modulu HTTP hlaviček. Například: [modules] entrust-client-header = pdwpi-httphdr-module some-other-header = pdwpi-httphdr-module [entrust-client-header] header = entrust-client [some-other-header] header = some-other
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
95
Konfigurace mechanismu pro autentizaci pomocí HTTP hlaviček Parametr http-request udává sdílenou knihovnu pro mapování HTTP informací autentizace pomocí hlavičky. v Na operačním systému UNIX je soubor, který poskytuje zabudované mapovací funkce, tzv. sdílená knihovna s názvem libpdwpi-http-cdas. v Na operačním systému Windows je soubor, který poskytuje zabudované mapovací funkce, tzv. DLL s názvem pdwpi-http-cdas. Standardně je tato zabudovaná sdílená knihovna pevně naprogramována tak, aby mapovala data hlavičky pověřené proxy na platnou totožnost produktu Tivoli Access Manager. Tento soubor musíte přizpůsobit tak, aby autentizoval i jiné typy dat speciálních hlaviček a, volitelně, namapoval tato data na totožnost produktu Tivoli Access Manager. Podrobné informace o rozhraní API najdete v knize IBM Tivoli Access Manager for e-business Web Security Developer Reference. Mechanismus autentizace pomocí HTTP hlaviček můžete nakonfigurovat tak, že zadáte parametr http-request spolu se jménem sdílené knihovny specifickým pro danou platformu do stanzy [authentication-mechanisms] konfiguračního souboru pdwebpi.conf. Například: Solaris: [authentication-mechanisms] http-request = libpdwpi-http-cdas.so
Windows: [authentication-mechanisms] http-request = pdwpi-http-cdas.dll
Konfigurace autentizace pomocí IP adresy IP adresa příchozího požadavku může být použita jak pro udržování stavu relace, tak i pro autentizaci požadavků klienta, a to pomocí hodnot uvedených v hlavičce adresy klienta. Pokud nakonfigurujete plug-in program, aby používal IP adresu pro udržování stavu relace, je to neplatné, pokud současně plug-in program nenakonfigurujete také tak, aby používal IP adresu pro autentizaci požadavků klienta. Avšak používání IP adresy pro autentizaci uživatele je platné, aniž by byl plug-in program nucen sledovat pomocí IP adresy relace uživatelů.
Aktivace autentizace pomocí IP adresy Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete aktivovat autentizaci pomocí IP adresy iniciátora požadavku, přiřaďte slovo ip-addr k parametru authentication tak, jak je uvedeno níže: [common-modules] authentication = ip-addr
Chcete-li aktivovat používání IP adresy ke sledování relací klienta, přiřaďte slovo ip-addr k parametru session tak, jak je uvedeno níže: [common-modules] session = ip-addr
96
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že zde existuje také záznam pro autentizaci pomocí IP adresy, tj.: [modules] ip-addr = pdwpi-ipaddr-module
Konfigurace mechanismu pro autentizaci pomocí IP adresy Mechanismus autentizace pomocí IP adresy je stejný jako pro autentizaci pomocí HTTP hlaviček. Parametr http-request udává sdílenou knihovnu pro mechanismus autentizace pomocí IP adresy. v Na operačním systému UNIX je soubor, který poskytuje zabudované mapovací funkce, tzv. sdílená knihovna s názvem libpdwpi-http-cdas. v Na operačním systému Windows je soubor, který poskytuje zabudované mapovací funkce, tzv. DLL s názvem pdwpi-http-cdas. Mechanismus autentizace pomocí IP adresy můžete nakonfigurovat tak, že zadáte parametr http-request spolu se jménem sdílené knihovny specifickým pro danou platformu do stanzy [authentication-mechanisms] konfiguračního souboru pdwebpi.conf. Například: Solaris: [authentication-mechanisms] http-request = libpdwpi-http-cdas.so
Windows: [authentication-mechanisms] http-request = pdwpi-http-cdas.dll
Konfigurace autentizace pomocí LTPA cookies Plug-in program může používat LTPA cookies pro autentizaci uživatelů. LTPA cookies mohou být poskytovány produktem Tivoli Access Manager WebSEAL, nebo produktem IBM WebSphere server.
Aktivace autentizace pomocí LTPA cookies Stanza [common-modules] konfiguračního souboru pdwebpi.conf definuje použití LTPA cookies pro autentizaci požadavků. [common-modules] authentication = ltpa
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že je zde uveden záznam pro autentizaci pomocí LTPA cookies, tj.: [modules] ltpa = pdwpi-ltpa-module
Nastavení podrobných informací o klíči Skutečná LTPA cookie, kterou program obdrží, je zašifrována odesílatelem. Než bude možné provést autentizaci, je nutné dešifrovat cookie. Stanza [ltpa] v konfiguračním souboru pdwebpi.conf obsahuje podrobné informace o klíči, který je procesem pro dešifrování cookie vyžadován:
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
97
[ltpa] ltpa-keyfile = full path of keyfile ltpa-stash-file = password stash file location ltpa-password = password in lieu of the stash file
Kde: v Záznam ltpa-keyfile určuje jméno souboru klíčů, získaného z původního počítače. Záznam pro soubor klíčů je požadován. v Záznam ltpa-stash-file určuje jméno souboru, který obsahuje heslo souboru klíčů. Tento záznam je volitelný. Ale pokud neexistuje, musí existovat záznam ltpa-password. Tento záznam má přednost před každým uvedeným záznamem ltpa-password. v Záznam ltpa-password se vyžaduje pouze tehdy, pokud neexistuje záznam ltpa-stash-file. Měl by obsahovat heslo k uvedenému souboru klíčů v čisté textové podobě.
Konfigurace zpracování následujícího po autorizaci pomocí LTPA cookies Modul LTPA je nakonfigurován pro zpracování následující po autorizaci jako součást řešení pro jednotné přihlášení k aplikačnímu serveru WebSphere. Podrobnosti o konfiguraci najdete v části “Jednotné přihlášení do WebSphere Application server pomocí LTPA cookies” na stránce 125.
Konfigurace přesměrování uživatelů po přihlášení Pomocí modulu login-redirect můžete plug-in program nakonfigurovat tak, aby přesměroval uživatele na určité URL, jakmile se úspěšně autentizují. Tato vlastnost může být vhodná v případech, kdy chcete, aby všichni uživatelé byli přesměrování na portál, a ne na webovou stránku, kterou požadovali, nebo abyste uživateli předložili uvítací stránku, nebo úvodní stránku do on-line aplikace. Funkcionalita plug-in programu týkající se přesměrování po přihlášení pracuje nezávisle na politice, která byla použita pro autentizaci uživatelů. Přesměrování nebude provedeno při zvýšené autentizaci nebo při opětovné autentizaci.
Aktivace přesměrování uživatele Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete přesměrovat uživatele na určité URI poté, co se přihlásil a autentizoval, přiřaďte slovo login-redirect k parametru pre-authzn tak, jak je uvedeno níže: [common-modules] pre-authzn = login-redirect
Poznámka: Pokud budete toto nastavení používat, doporučujeme, abyste parametr login-redirect umístili na první místo v seznamu modulů zpracování předcházejících autorizaci. Jinak může mít přednost jiné přesměrování v jiném modulu autentizace (například modul zpracování následujícího po autorizaci pomocí formulářů). Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že zde existuje také záznam pro přesměrování po přihlášení login-redirect, tj.: [modules] login-redirect = pdwpi-loginredirect-module
98
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Konfigurace parametrů přesměrování uživatele Parametry přesměrování uživatele jsou nakonfigurovány ve stanze [login-redirect] konfiguračního souboru pdwebpi.conf. [login-redirect] redirect-uri = uri-přesměrování
V parametru redirect-uri uveďte URI, na které chcete přesměrovat uživatele po jejich úspěšném přihlášení. Uvedené URI může být buď relativní URI, nebo absolutní URI.
Přidání rozšířených atributů pro pověření Tato sekce obsahuje následující témata: v “Mechanismy pro přidání rozšířených atributů do pověření” v “Konfigurace služby pojmenování” na stránce 100
Mechanismy pro přidání rozšířených atributů do pověření Proces autentizace produktu Tivoli Access Manager Plug-in for Web Servers přistupuje k registru uživatelů produktu Tivoli Access Manager a vytváří pověření pro uživatele. Pověření obsahuje informaci o uživateli, která je nezbytná pro rozhodnutí o přístupu. To zahrnuje informace, jako je jméno uživatele a seznam skupin, do kterých uživatele patří. Plug-in program podporuje několik různých mechanismů (služeb), které dovolují administrátorům a vývojářům aplikace rozšířit proces autentizace. Když plug-in program vede proces autentizace, tak kontroluje, zda byla některá vnější služba implementována a nakonfigurována. Pokud některá služba byla, tak ji plug-in program zavolá. Služby mohou provádět své vlastní zpracování, aby vytvořily seznam rozšířených atributů o totožnosti uživatele. Plug-in program přidává tyto rozšířené atributy do pověření uživatele. Jsou podporovány následující typy služeb: v Služba pojmenování atributu pověření Tato služba pojmenování je pro produkt Tivoli Access Manager vytvořena standardně. Tato služba obrdží z registru uživatelů (jako je registr uživatelů LDAP) uvedenou informaci o uživateli a vkládá ji do seznamu atributů v pověření uživatele. Tato služba pojmenování atributu pověření je generickou službou pojmenování, která může být použita mnoha správci zdrojů. Tato služba nahrazuje předchozí metodu, která vyžadovala, aby administrátoři vkládali záznamy ″tag/value″ do stanzy [ldap-ext-creds-tag] v konfiguračním souboru pdwebpi.conf. Ve verzi 5.1 byste měli službu pojmenování použít k obdržení dat registru uživatelů LDAP. Abyste získali informace o konfiguraci, vyhledejte část “Konfigurace služby pojmenování” na stránce 100 v Služba pojmenování přizpůsobeného atributu pověření Když služba pojmenování atributu pověření nemůže poskytnout všechny informace nezbytné pro vaše nasazení, můžete zapsat vaši vlastní službu pojmenování atributu pověření. Produkt Tivoli Access Manager podporuje tuto službu jako část API autorizace. Abyste získali další informace, prohlédněte IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. v Služba CDAS (credential extended attributes external authentication service) Plug-in program poskytuje vnější rozhraní pro API autentizace, které se může použít pro rozvoj služeb vnějších autentizace. Tyto služby se obecně nazývají CDAS (cross-domain authentication service). Vnější API autentizace plug-in programu můžete použít k rozvinutí vaší vlastní služby vnější autentizace. Ta se může použít, když potřebujete obdržet informaci o autentizaci uživatele rozšířenou za informací o pojmenováních. Použití CDAS rozšířených atributů pověření se doporučuje, když aplikace potřebuje informaci dostupnou pouze v době Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
99
autentizace, nebo když aplikace potřebuje mapovat ID uživatele použité pro autentizaci ID uživatele produktu Tivoli Access Manager. Abyste získali další informace, prohlédněte IBM Tivoli Access Manager for e-business Web Security Developer Reference.
Konfigurace služby pojmenování Abyste nakonfigurovali službu pojmenování, proveďte instrukce v následujících sekcích: v “Krok 1 — Určete atributy, které se mají přidat do pověření” v “Krok 2 — Definujte vaše použití služby pojmenování” v “Krok 3 — Uveďte atributy, které se mají přidat do pověření”
Krok 1 — Určete atributy, které se mají přidat do pověření Každý atribut uživatele, který chcete přidat do pověření uživatele, musí být definován v konfiguračním souboru produktu Tivoli Access Manager. To se většinou provede v konfiguračním souboru plug-in programu. Jděte do registru uživatelů produktu Tivoli Access Manager (například registr uživatelů LDAP). Vytvořte seznam jmen každého záznamu registru uživatelů, ze kterého má služba pojmenování atributů pověření extrahovat registr a umístit ho do pověření uživatele. Budete také potřebovat DN uživatele a DN skupiny.
Krok 2 — Definujte vaše použití služby pojmenování 1. Ověřte, že je nakonfigurována služba pojmenování atributů pověření. V konfiguračním souboru plug-in programu by se měl objevit následující standardní záznam: [aznapi-entitlement-services] AZN_ENT_EXT_ATTR = azn_ent_ext_attr
Všimněte si, že plug-in program automaticky bere hodnotu azn_ent_ext_attr a hledá odpovídající sdílenou knihovnu. Na platformě Solaris například, libazn_ent_ext_attr.so 2. Abyste uvedli vaše použití služby pojmenování, přidejte záznam definice služby API autorizace. Přidejte záznam ve stanze [aznapi-configuration]. Záznam musí použít parametr cred-attributes-entitlement-services. Můžete vybrat hodnotu jako TAM_CRED_ATTRS_SVC. Například: [aznapi-configuration ] cred-attributes-entitlement-services = TAM_CRED_ATTRS_SVC
Krok 3 — Uveďte atributy, které se mají přidat do pověření Atributy, které se mají přidat do pověření, jsou konfigurovány v několika stanzách. Přidejte tuto informaci do konfiguračního souboru plug-in programu. Poznámka: Atributy můžete alternativně definovat v odděleném souboru, který se má nazvat službou pojmenování. Abyste získali další informace, prohlédněte IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Prohlédněte si následující příklad záznamu. [TAM_CRED_ATTRS_SVC] eperson = azn_cred_registry_id group = cn=enterprise, o=tivoli [TAM_CRED_ATTRS_SVC:eperson] tagvalue_credattrs_lastname = sn tagvalue_credattrs_employeetype = employeetype tagvalue_credattrs_address = homepostaladdress tagvalue_credattrs_email = email [TAM_CRED_ATTRS_SVC:group] tagvalue_credattrs_businesscategory = businesscategory
100
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Jméno stanzy [TAM_CRED_ATTRS_SVC] je ID služby. V této stanze jsou načteny zdroje atributů. Zdrojová jména, jako je uživatel a skupina, se použijí k identifikaci umístění zdroje v registru. Zdrojová jména musíte definovat. Hodnoty pro tyto zdroje jsou identifikátory registru, které v registru existují. Hodnotami mohou být jména existujícího atributu pověření. Když je jménem písmeno, služba automaticky vyhledá a použije respektované hodnoty. Nakonfigurujte atributy registru pro každý zdroj pod stanzou služby v oddělené stanze. Syntaxe separované stanzy je jméno knihovny ID služby následované dvojtečkou (:) a poté jménem zdroje. Toto spojení je nezbytné, protože ve stejném souboru může být nakonfigurována více než jedna služba. Záznamy konfiguračního souboru obsahují mapování atributů registru uživatelů na uživatelsky definované atributy pověření. V registru uživatelů LDAP může být například DN pro uživatele cn=joeuser, o=tivoli Pro tohoto uživatele mohou být záznamy registru uživatelů LDAP: sn=Smith employeetype=bankteller homepostaladdress="3004 Mission St Santa Cruz CA 95060" [email protected] businesscategory=finance
Použitím výše uvedeného příkladu záznamů konfigurace může mít vrácený seznam atributů následující záznamy: Jméno atributu
Hodnota atributu
credattrs_lastname
Smith
credattrs_employeetype
bankteller
credattrs_address
3004 Mission St Santa Cruz CA 95060
credattrs_email
[email protected]
credattrs_businesscategory
finance
Všimněte si, že služba, zdroj a atributy mohou být vícehodnotové. Když uvedete stejné jméno atributu, jako je klíčové slovo záznamu stanzy, tak když načtené atributy přijdou z rozdílných zdrojů, budou přidány jako vícehodnotové. Dohromady může být například zřetězena více jak jedna služba pojmenování. To umožňuje, aby byly hodnoty načtené z jedné služby použity jako vstupní hodnoty pro jinou službu. Atributy mohou být také načteny z více jak jednoho DN v registru uživatelů. Pokud jste chtěli seznam všech záznamů businesscategory pro skupinu uživatelů, můžete tudíž pomocí výše uvedeného příkladu do jednoho atributu credattrs_businesscategory přidat hodnoty z vícenásobných uživatelů (DN). Pokud chcete například vytvořit atribut nazvaný myemployeeinfo, který se má přidat do pověření, a chcete, aby tento atribut obsahoval poslední jméno a typ zaměstnance každého, kdo se autentizuje, můžete definovat následující: [myID] source = azn_cred_authzn_id [myID:source] myemployeeinfo = lastname myemployeeinfo = employeetype
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
101
Přidání rozšířených atributů LDAP do HTTP hlavičky (hodnota příznaku) Často je vhodné připojit k hlavičkám autentizovaných HTTP požadavků informace z LDAP specifické pro uživatele (například telefonní číslo, adresu elektronické pošty). To umožní více aplikacím přistupovat k připojené informaci, aniž by se musely neustále dotazovat na LDAP serveru. Podstatou je, že tyto informace jsou relativně stálé a nikdy nejsou aktualizovány žádnou z aplikací, které je používají. Tato data jsou uložena do pověření klienta jako součást procesu autentizace ivauthn. Tyto informace je také možné připojit k pověření klienta pomocí uživatelsky implementovaného CDAS modulu pro autentizaci. Níže uvedený průběh procesu popisuje posloupnost událostí: v Uživatelsky definovaná dodatečná data z každého pole účtu registru LDAP uživatele se přidají jako data rozšířeného atributu do pověření uživatele produktu Tivoli Access Manager. v Je-li plug-in program nakonfigurován pro zpracování následující po autorizaci pomocí hodnoty příznaku, pak plug-in program vyjme data rozšířeného atributu LDAP a umístí je do HTTP hlavičky požadavku. v Aplikace typu back-end vyjme data z hlavičky, aniž by potřebovala speciální kód nebo autorizační rozhraní API. Pokud chcete nakonfigurovat plug-in program, aby vkládal informace z rozšířeného atributu LDAP do HTTP hlavičky, postupujte takto: 1. Nakonfigurujte zpracování následující po autorizaci pomocí hodnoty příznaku ve webovém plug-in programu. Podrobné informace, jak to provést, najdete v části “Aktivace zpracování pomocí hodnoty příznaku”. 2. Rozšířené atributy přidejte do objektu /PDWebPI/hostitel v prostředí Tivoli Access Manager. Například (zadáno na jednom řádku): pdadmin> object modify /PDWebPI/hostitel set attribute HTTP-Tag-Value ldap-home-phone=homePhone
Můžete také vytvořit nový modul CDAS pro rozšíření pověření produktu Tivoli Access Manager a uvést tento modul do plug-in programu jako mechanismus autentizace. Například: 1. Nastavte parametr cred-ext-attrs ve stanze [authentication-mechanisms] na nový modul CDAS. Například (zadáno na jednom řádku): [authentication-mechanisms] cred-ext-attrs = /opt/PolicyDirector/lib/libextcredtags.so & /opt/pdwebpi/etc/pdwebpi.conf
(předvolený konfigurační soubor je pd.conf) 2. Editujte soubor pdwebpi.conf a přidejte do něj novou stanzu [ldap-ext-attr-cdas-tags] a požadované rozšířené atributy LDAP. Například: [ldap-ext-attr-cdas-tags] ldap-home-phone = homePhone
3. Znovu spusťte plug-in program. 4. Přidejte rozšířené atributy do objektu /PDWebPI/hostitel v prostředí produktu Tivoli Access Manager. Například (zadáno na jednom řádku): pdadmin> object modify /PDWebPI/hostitel set attribute HTTP-Tag-Value ldap-home-phone=homePhone
Aktivace zpracování pomocí hodnoty příznaku Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete aktivovat zpracování pomocí hodnot příznaku, přiřaďte slovo tag-value k parametru post-authzn:
102
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
[common-modules] post-authzn = tag-value
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že zde existuje také záznam pro hodnotu příznaku, tj.: [modules] tag-value = pdwpi-tag-value-module
Konfigurace parametrů hodnoty příznaku Parametry hodnoty příznaku jsou nakonfigurovány ve stanze [tag-value] konfiguračního souboru pdwebpi.conf. [tag-value] cache-definitions = yes cache-refresh-interval = 60
Parametr cache-definitions povoluje nebo zakazuje ukládání definic hodnoty příznaku, které jsou připojeny k prostoru objektů, do paměti cache. cache-refresh-interval definuje interval obnovy (ve vteřinách) paměti cache pro definice. Pokud potřebujete, můžete nakonfigurovat prefix, který se má přidat ke jménům atributu použitým pro HTTP hlavičky hodnota-příznaku. Tento prefix: v Je při vyhledávání atributů pověření použit modulem hodnota-příznaku jako řetězec vyhledávání. v Je přidán do atributu pověření ID relace. v Je modulem přepnutí-uživatele přidán do atributu pověření, který používá k uložení jména uživatele administrátora. Pomocí parametru tag-value-prefix ve stanze [pdweb-plugins] konfiguračního souboru uveďte prefix. Tento parametr může být pro určitého virtuálního hostitele potlačen pomocí stanzy [virtual_host] pro virtuálního hostitele. Standardní chování je nemít žádný prefix.
Podpora MPA (Multiplexing Proxy Agents) Produkt Tivoli Access Manager nabízí řešení pro zabezpečení sítí, které používají MPA (Multiplexing Proxy Agent). Agenti MPA (Multiplexing Proxy Agents) jsou komunikační brány, které pojmou několik přístupů klientů. Komunikační brány vytvářejí jediný autentizovaný kanál k zabezpečenému webovému serveru a všechny požadavky klientů a odpovědi ″tunelují″ tímto kanálem. Plug-in programu se informace, které získá přes takovýto kanál, jeví, jako by dostal několik požadavků od jednoho klienta. Plug-in program musí rozlišovat mezi autentizací MPA serveru a další autentizací každého jednotlivého klienta. Obecným příkladem podobných komunikačních brán jsou brány WAP (Wireless Access Protocol). Produkt Tivoli Access Manager WebSEAL také vystupuje jako agent MPA, pokud je nakonfigurován se spojením k hostitelskému webovému serveru. Tak je možné nakonfigurovat jednotné přihlášení mezi serverem WebSEAL a plug-in programem. Chcete-li nakonfigurovat podobné řešení, můžete použít modul autentizace pomocí IV hlaviček. Podrobné informace o konfiguraci jednotného přihlášení najdete v části Kapitola 5, “Řešení jednotného přihlášení pro web”, na stránce 123.
Platné typy dat relací a metody autentizace Protože produkt Tivoli Access Manager Plug-in for Web Servers udržuje autentizovanou relaci pro agenta MPA, musí současně udržovat samostatné relace pro každého klienta. Z tohoto důvodu musí být data relace a politika autentizace používaná pro agenta MPA odlišná Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
103
od dat relace a politiky autentizace používané pro klienty. Níže uvedená tabulka obsahuje seznam platných typů relací pro agenty MPA a klienty: Tabulka 15. Platné typy dat relací pro agenty MPA Platné typy relací MPA-na-plug-in
Klient-na-plug-in
ID relace SSL HTTP hlavička
HTTP hlavička
BA hlavička
BA hlavička
IP adresa Cookie
Cookie
v Klient nemůže používat ID relace SSL jako typ dat relace. v Například pokud MPA používá BA hlavičku pro typ dat relace, možnosti typů dat relace pro klienta obsahují pouze HTTP hlavičku a cookie. v Pokud MPA používá HTTP hlavičku pro data relace, klient může používat jiný typ HTTP hlavičky. v Cookie specifická pro relace obsahuje pouze informace o relaci. Neobsahuje informace o totožnosti. v Pokud je podpora MPA aktivována, změní se použití ID relací SSL pro udržování stavu relací. Normálně pokud máte nakonfigurováno, aby se stav relace udržoval pomocí ID relace SSL, pak se k udržování relací HTTPS klientů používá pouze ID relace SSL. Proto, abyste umožnili MPA udržovat relaci pomocí ID relace SSL a klientům umožnili udržovat relace pomocí jiné politiky, je toto omezení zrušeno. Politika autentizace, která se bude používat pro relaci typu MPA-na-plug-in, musí být jiná, než politika autentizace, která se bude používat pro relaci typu klient-na-plug-in. Níže uvedená tabulka obsahuje seznam platných politik autentizace pro agenty MPA a klienty: Tabulka 16. Platné typy autentizace agentů MPA Platné typy autentizace MPA-na-plug-in
Klient-na-plug-in
Základní autentizace
Základní autentizace
Formuláře
Formuláře
Token
Token
HTTP hlavička
HTTP hlavička
Certifikát IP adresa
v Například pokud MPA používá Základní autentizaci, možnosti politik autentizace pro klienty obsahují formuláře, tokeny a HTTP hlavičky. v Politiky autentizace pomocí certifikátů a IP adres nejsou platné pro klienty. v Obvykle je autentizace pomocí formulářů (nebo tokenů) povolena pro určitý typ přenosu, a Základní autentizace je automaticky pro tento přenos zakázána. Pokud je aktivována podpora MPA, toto omezení je odstraněno. To umožní, aby se MPA přihlásil například pomocí formulářů (nebo tokenu) a aby se klienti mohli přihlásit pomocí Základní autentizace prostřednictvím stejné transportní vrstvy.
104
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Průběh procesu autentizace pro MPA a několik klientů Pro autentizaci MPA a vícenásobných klientů se provádí následující postup: 1. Proveďte následující změny konfigurace:
2. 3. 4. 5. 6. 7. 8.
9.
10. 11. 12. 13.
v Aktivujte podporu MPA v konfiguračním souboru. v Vytvořte účet pro určitou komunikační bránu MPA v produktu Tivoli Access Manager. v Udělte proxy přístup ([PDWebPI]p) tomuto účtu ke chráněnému objektu MPA pro virtuálního hostitele, na kterého budou směrovány tyto požadavky prošlé přes proxy. Ve standardní konfiguraci tohoto můžete dosáhnout tak, že z uživatele vytvoříte člena skupiny pdwebpi-mpa-servers. Klienti se připojí ke komunikační bráně MPA. Komunikační brána přeloží požadavek do požadavku HTTP. Komunikační brána provede autentizaci klienta. Komunikační brána vytvoří spojení s plug-in programem pomocí požadavku klienta. Agent MPA se autentizuje do plug-in programu (pomocí politiky odlišné od klienta) a provede se odvození totožnosti pro agenta MPA (který má již účet v plug-in programu). Plug-in program ověří, že MPA je členem skupiny pdwebpi-mpa-servers. Vytvoří se pověření pro MPA a je označeno v paměti cache, že má speciální typ pro MPA. Přestože toto MPA pověření doprovází všechny budoucí požadavky klienta, nepoužívá se pro kontrolu autorizace těchto požadavků. Nyní plug-in program potřebuje ještě identifikovat vlastníka požadavku. MPA je schopný rozlišit více klientů, aby mohl zajistit správné směrování výzev k přihlášení. Klient se přihlásí a provede svoji autentizaci pomocí politiky odlišné od typu autentizace, kterou použil MPA. Plug-in program vytvoří pověření pro autentizační data klienta. Typ dat relace používaný každým klientem musí být odlišný od typu dat relace používaného MPA. Autorizační server povolí nebo zakáže přístup ke chráněným objektů na základě pověření uživatele a oprávnění přístupového seznamu objektu.
Aktivace autentizace MPA Parametr mpa-enabled ve stanze [pdweb-plugins] konfiguračního souboru pdwebpi.conf aktivuje nebo zakazuje autentizaci MPA. Platná nastavení jsou true a false, pomocí kterých aktivujete, případně zakážete, autentizaci MPA. Standardně je autentizace MPA zakázána. Autentizaci MPA můžete nastavit pro jednotlivé virtuální hostitele tak, že parametr mpa-enabled uvedete ve stanze [virtuální-hostitel] konfiguračního souboru. Proto, aby bylo možné identifikovat novou relaci jako primární relaci vytvořenou MPA, je provedeno rozhodnutí o autorizaci, které zkontroluje povolení Proxy ([PDWebPI]p) na chráněném objektu MPA. Standardně je chráněný objekt MPA nadefinován jako /PDWebPI. Pokud chcete potlačit toto standardní nastavení například tak, že byste chtěli nadefinovat jinou sadu objektů, které by měly představovat agenty MPA pro každého virtuálního hostitele, můžete uvést hodnotu konfiguračního parametru mpa-protected-object. Tento parametr je možné potlačit na úrovni jednotlivých virtuálních hostitelů zadáním jeho hodnoty ve stanze [virtuální-hostitel] konfiguračního souboru. Chcete-li například povolit přístup MPA pro virtuálního hostitele ibm.com, ale ne pro virtuálního hostitele lotus.com, použijte následující nastavení v konfiguračním souboru pdwebpi.conf:
Kapitola 3. Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers
105
[pdmweb-plugins] virtual-host = ibm.com virtual-host = lotus.com [ibm.com] mpa-enabled = yes
Chcete-li nadefinovat členy skupiny ibm-mpa-servers, aby byli agenty MPA pro požadavky na virtuálního hostitele ibm.com, a členy skupiny lotus-mpa-servers, aby byli agenty MPA pro požadavky na virtuálního hostitele lotus.com, použijte následující konfiguraci: [pdweb-plugins] virtual-host = ibm.com virtual-host = lotus.com [ibm.com] mpa-enabled = yes mpa-protected-object = /PDWebPI/ibm.com [lotus.com] mpa-enabled = yes mpa-protected-object = /PDWebPI/lotus.com
A nadefinujte následující politiku produktu Tivoli Access Manager: pdadmin> pdadmin> pdadmin> pdadmin> pdadmin> pdadmin>
acl acl acl acl acl acl
create modify create modify attach attach
ibm-mpa ibm-mpa set group ibm-mpa-servers T[PDWebPI]p lotus-mpa lotus-mpa set group lotus-mpa-servers T[PDWebPI]p /PDWebPI/ibm.com ibm-mpa /PDWebPI/lotus.com lotus-mpa
Konfigurační parametr mpa-protected-object udává objekt, pro který budou prováděna rozhodnutí o autorizaci.
Vytvoření účtu uživatele pro MPA Informace o tom, jak vytvořit účty uživatelů, najdete v knihách IBM Tivoli Access Manager Base: Administrativní příručka a IBM Tivoli Access Manager Web Portal Manager Administration Guide.
Přidání účtu MPA do skupiny pdwebpi-mpa-servers Produkt Tivoli Access Manager Plug-in for Web Servers vytvoří skupinu, aby bylo možné snadněji spravovat servery MPA. Tato skupina se nazývá pdwebpi-mpa-servers. Standardní přístupový seznam default-pdwebpi připojený k objektu /PDWebPI uděluje oprávnění Proxy ([PDWebPI]p) členům skupiny pdwebpi-mpa-servers. V zabezpečené doméně produktu Tivoli Access Manager s minimálně jedním nakonfigurovaným serverem WebSEAL je přístupový seznam default-pdwebpi nakonfigurován tak, aby také udělil oprávnění Proxy členům skupin webseal-servers a webseal-mpa-servers. Můžete si zvolit své vlastní skupiny a přístupové seznamy, které budou používány k řízení identifikace objektů jako MPA. Informace o správě skupin najdete v knihách IBM Tivoli Access Manager Base: Administrativní příručka a IBM Tivoli Access Manager Web Portal Manager Administration Guide.
106
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Kapitola 4. Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers Tato kapitola obsahuje informace, které popisují, jak můžete nakonfigurovat a přizpůsobit bezpečnostní politiku produktu IBM Tivoli Access Manager (Tivoli Access Manager) Plug-in for Web Servers. Tato kapitola obsahuje následující témata: v “Politiky ACL (Access Control List) specifické pro plug-in program” v “Politika pro přihlášení ″třikrát a dost″” na stránce 110 v “Politika odolnosti hesla” na stránce 111 v “Politika POP odolnosti autentizace (zvýšená)” na stránce 113 v “Vícefaktorová autentizace” na stránce 116 v “Opětovná autentizace pomocí politiky chráněného objektu” na stránce 117 v “Autentizace pomocí POP založená na síti” na stránce 118 v “Úroveň zabezpečení politiky chráněného objektu” na stránce 120 v “Zacházení s neautentizovanými uživateli (HTTP/HTTPS)” na stránce 120
Politiky ACL (Access Control List) specifické pro plug-in program Následující kritéria bezpečnosti platí pro kontejner /PDWebPI v prostoru chráněných objektů: v Objekt produktu Tivoli Access Manager Plug-in for Web Servers začíná řetěz dědičnosti ACL pro oblast plug-in programu prostoru objektů. v Pokud nebudete používat žádný další explicitní přístupový seznam, tento objekt definuje (prostřednictvím dědičnosti) bezpečnostní politiku celého webového prostoru. v Přístup k tomuto objektu a všem objektům pod tímto bodem vyžaduje oprávnění pro přechod. Podrobné informace o politikách ACL produktu Tivoli Access Manager najdete v knize IBM Tivoli Access Manager Base: Administrativní příručka. Poznámka: Webový server Microsoft IIS nabízí možnost uvést předvolenou webovou stránku v adresáři, která se zobrazí, jakmile součástí požadavku uživatele bude URL, které bude obsahovat pouze cestu k adresáři. Produkt Plug-in for Web Servers provede kontrolu řízení přístupu podle ACL pouze pro adresář uvedený v URL požadavku, a ne na předvolenou webovou stránku nabízenou serverem IIS v odpovědi na takový požadavek. Uvedené omezení kontroly přístupového seznamu byste měli vzít v úvahu při implementaci vaší bezpečnostní politiky na platformě webového serveru IIS. Podobně z důvodu přirozeného chování architektury plug-in programu webového serveru zde není nic, co by vám bránilo před instalací dalších modulů, které mohou kolidovat s bezpečností, poskytovanou plug-in programem. Je odpovědností administrátora webového serveru, aby zajistil, že na webovém serveru nebudou nainstalovány žádné moduly, které budou kolidovat s plug-in programem. © Copyright IBM Corp. 2000, 2003
107
Například funkcionalita ″MultiViews″ na webových serverech Apache a IHS se pokouší dynamicky určit příponu požadovaného URL. Je-li například vydán požadavek na www.tivoli.com/index, pak by mohl webový server dynamicky namapovat toto na www.tivoli.com/index.html, pokud bude takový soubor existovat. Bohužel se toto mapování vyskytuje až po dokončení autorizace, což znamená, že kontrola autorizace se provádí na souboru index, místo aby se prováděla na souboru index.html. V těchto situacích se dopuručuje, aby byla volba ″MultiViews″ zakázána, nebo aby byla politika nastavena tak, aby zachytila toto mapování. Je možné například připojit ACL k /PDWebPI/www.tivoli.com, nebo, je-li vyžadována větší nespojitost, pak je možné ACL připojit jak k souboru /PDWebPI/www.tivoli.com/index, tak i k souboru /PDWebPI/www.tivoli.com/index.html.
/PDWebPI/hostitel nebo virtuální-hostitel Podstrom /PDWebPI/hostitel nebo virtuální-hostitel obsahuje prostor objektů určité instance plug-in programu. Pro tento objekt platí následující kritéria bezpečnosti: v přístup ke všem objektům pod tímto bodem vyžaduje oprávnění pro přechod v pokud nebudete používat žádný další explicitní přístupový seznam, tento objekt definuje (prostřednictvím dědičnosti) bezpečnostní politiku celého prostoru objektů na tomto počítači
108
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Oprávnění ACL plug-in programu Následující tabulka popisuje oprávnění ACL, které je možné použít pro oblast prostoru objektů produktu Tivoli Access Manager Plug-in for Web Servers: Tabulka 17. Oprávnění ACL plug-in programu Oprávnění
Operace
Popis
[PDWebPI]r
čtení
Zobrazí libovolný prvek spíše než adresář. Každý požadavek HTTP GET nebo POST vyžaduje toto oprávnění. Neexistuje žádné specifické oprávnění ″list″, pomocí kterého by bylo možné požádat o výpis adresáře (GET URL končící na /).
[PDWebPI]d
vymazání
Vymaže webový objekt z webového prostoru. Příkazy HTTP DELETE vyžadují toto oprávnění.
[PDWebPI]m
upravení
Umístí/publikuje objekt HTTP v prostoru objektů plug-in programu. Požadavek HTTP PUT vyžaduje toto oprávnění.
[PDWebPI]p
proxy
Určuje, zda uživatel může vystupovat jako agent MPA. Podrobné informace najdete v části “Přidání účtu MPA do skupiny pdwebpi-mpa-servers” na stránce 106.
přechod
Je nutné pro přístup ke všem objektům pod tímto bodem.
T
Plug-in program také podporuje operace WebDAV, které jsou uvedeny níže. Tabulka 18. Oprávnění WebDAV plug-in programu Úloha
Požadované oprávnění
PROPFIND
[PDWebPI]R
PROPPATCH
[PDWebPI]M
MKCOL
[PDWebPI]N
Operace WebDAV jsou autorizovány na základě URI požadavku – nikoliv na individuálních členech shromáždění. Navíc některé další operace WebDAV jsou částečně podporovány. v COPY - Vyžaduje [PDWebPI]R na shromáždění, takže je možné přečíst ’copy from’. Oprávnění pro místo určení nejsou kontrolována. v MOVE - Používá se ve smyslu, nejprve zkopírovat, pak vymazat. Vyžaduje [PDWebPI]Rd na shromáždění, ze kterého provádíte přesun. Oprávnění pro místo určení nejsou kontrolována.
Předvolená politika ACL pro /PDWebPI Klíčové záznamy přístupového seznamu produktu Tivoli Access Manager Plug-in for Web Servers default-pdwebpi obsahují: Group iv-admin
TcmdbsvaBR[PDWebPI]rR
User sec_master
cmdbsvaBR[PDWebPI]rR
Any-other
T[PDWebPI]rR
Unauthenticated
T
Group pdwebpi-mpa-servers
TBR[PDWebPI]p
Group webseal-servers
TBR[PDWebPI]p
Kapitola 4. Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers
109
Group webseal-mpa-servers
TBR[PDWebPI]p
Při instalaci je tento předvolený ACL připojen k objektu typu zásobník /PDWebPI v prostoru objektů. Oprávnění pro přechod umožňuje rozšíření webového prostoru, které je prezentováno v rozhraní Web Portal Manager. Oprávnění pro výpis umožňuje rozhraní Web Portal Manager zobrazit obsah webového prostoru.
Politika pro přihlášení ″třikrát a dost″ Politika pro přihlášení ″třikrát a dost″, která se používá v instalacích produktu Tivoli Access Manager založených na LDAP, vám umožňuje bránit se před útoky na heslo počítače tím, že zadáte maximální počet chybných pokusů o přihlášení a trestnou dobu uzamčení účtu. Politika vytváří podmínku, kdy uživatel musí čekat po určitou dobu, než bude moci provádět další pokusy o přihlášení, které budou chybné. Politika může například nařídit, že po 3 chybných pokusech bude následovat trest ve výši 180 vteřin. Tento typ politiky pro přihlášení může chránit před pokusy o přihlášení pomocí náhodně vygenerovaných hesel pomocí počítače, které se vyskytují mnohokrát za vteřinu. Politika pro přihlášení ″třikrát a dost″ vyžaduje úzkou spolupráci dvou nastavení příkazu politiky pdadmin: v maximální počet špatných pokusů o přihlášení policy set max-login-failures v trest za překročení nastaveného počtu chybných pokusů o přihlášení policy set disable-time-interval Nastavení trestu může obsahovat dobu uzamčení účtu nebo úplné zablokování účtu. Je-li politika pro přihlášení nastavena (jako v tomto příkladě) na tři špatné pokusy následované trestem uzamčení účtu po určitou dobu, pak výsledkem čtvrtého pokusu o přihlášení (ať už správného nebo špatného) je chybová stránka, která oznámí, že účet je dočasně nedostupný, protože to tak vyžaduje politika hesla. Časový interval je uveden ve vteřinách - minimální doporučovaný časový interval je 60 vteřin. Pokud je politika disable-time-interval nastavena na hodnotu disable, uživateli je uzamčen účet a LDAP atribut account valid pro tohoto uživatele je nastaven na hodnotu no. Administrátor může znovu aktivovat tento účet pomocí rozhraní Web Portal Manager. Poznámka: Výsledkem nastavení parametru disable-time-interval na hodnotu disable je další administrativní režie. Při replikaci informací do plug-in programu si můžete všimnout zpoždění způsobené replikací informací account valid. Tato situace závisí na vašem prostředí LDAP. Navíc některé implementace LDAP mohou mít určité snížení výkonnosti, které je výsledkem operací aktualizace account valid. Z těchto důvodů se doporučuje, abyste používali časový interval.
110
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Následující příkazy pdadmin je vhodné používat pouze s registrem LDAP. Tabulka 19. Příkazy politiky pro přihlášení pdadmin pro LDAP Příkaz
Popis
policy set max-login-failures {počet|unset} [-user jméno-uživatele] policy get max-login-failures [-user jméno-uživatele] Spravuje politiku tak, že řídí maximální počet špatných pokusů o přihlášení, který je dovolen před tím, než bude na daný účet uvalen trest. Tento příkaz závisí na nastavení trestu v příkazu policy set disable-time-interval. Jako administrátor můžete použít tuto politiku pouze pro určitého uživatele, nebo můžete tuto politiku aplikovat globálně na všechny uživatele v registru LDAP. Předvolené nastavení je 10 pokusů. policy set disable-time-interval {počet|unset|disable} [-user jméno-uživatele] policy get disable-time-interval [-user jméno-uživatele] Spravuje politiku trestu tak, že řídí časový interval, po který bude účet zablokován, pokud bude dosaženo maximálního počtu špatných pokusů o přihlášení. Jako administrátor můžete použít tuto politiku trestu pouze pro určitého uživatele, nebo můžete tuto politiku aplikovat globálně na všechny uživatele v registru LDAP. Předvolené nastavení je 180 vteřin.
Politika odolnosti hesla Instalace produktu Tivoli Access Manager založené na LDAP nabízí dva prostředky pro řízení vytváření hesel: v pět příkazů politik pdadmin týkajících se nastavení hesla v modul PAM (plugable authentication module), který vám umožní přizpůsobit politiku hesla vašim požadavkům Viz Tivoli Access Manager Authorization C API Developer’s Reference
Nastavení politiky odolnosti hesla pomocí obslužného programu pdadmin Pět atributů pro nastavení odolnosti hesla, které je možné naimplementovat pomocí obslužného programu pdadmin, je: v minimální délka hesla v minimální počet abecedních znaků v minimální počet neabecedních znaků v maximální počet opakujících se znaků v mezery povoleny Tyto politiky se uplatňují, když vytváříte uživatele pomocí obslužného programu pdadmin nebo rozhraní Web Portal Manager, a tehdy, kdy se mění heslo pomocí obslužného programu pdadmin, rozhraní Web Portal Manager nebo obslužného programu pkmspasswd.
Kapitola 4. Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers
111
Následující příkazy pdadmin je vhodné používat pouze s registrem LDAP. Volba unset zakáže tento atribut politiky – tj. politika se nepoužije. Tabulka 20. Příkazy pdadmin odolnosti hesla pro LDAP Příkaz
Popis
policy set min-password-length {číslo|unset} [-user jméno-uživatele] policy get min-password-length [-user jméno-uživatele] Spravuje politiku, která řídí minimální délku hesla. Jako administrátor můžete tuto politiku použít pouze pro určitého uživatele, nebo můžete tuto politiku aplikovat globálně na všechny uživatele v předvoleném registru. Předvolené nastavení je 8. policy set min-password-alphas {počet|unset} [-user jméno-uživatele] policy get min-password-alphas [-user jméno-uživatele] Spravuje politiku, která řídí minimální počet abecedních znaků, který je povolen v hesle. Jako administrátor můžete tuto politiku použít pouze pro určitého uživatele, nebo můžete tuto politiku aplikovat globálně na všechny uživatele v předvoleném registru. Předvolené nastavení je 4. policy set min-password-non-alphas {počet|unset} [-user jméno-uživatele] policy get min-password-non-alphas [-user jméno-uživatele] Spravuje politiku, která řídí minimální počet neabecedních (číselných) znaků, který je v hesle povolen. Jako administrátor můžete tuto politiku použít pouze pro určitého uživatele, nebo můžete tuto politiku aplikovat globálně na všechny uživatele v předvoleném registru. Předvolené nastavení je 1. policy set max-password-repeated-chars {počet|unset} [-user jméno-uživatele] policy get max-password-repeated-chars [-user jméno-uživatele] Spravuje politiku, která řídí maximální počet opakujících se znaků, který je povolen v hesle. Jako administrátor můžete tuto politiku použít pouze pro určitého uživatele, nebo můžete tuto politiku aplikovat globálně na všechny uživatele v předvoleném registru. Předvolené nastavení je 2. policy set password-spaces {yes|no|unset} [-user jméno-uživatele] policy get password-spaces [-user jméno-uživatele] Spravuje politiku, která řídí, zda heslo může obsahovat mezery. Jako administrátor můžete tuto politiku použít pouze pro určitého uživatele, nebo můžete tuto politiku aplikovat globálně na všechny uživatele v předvoleném registru. Předvolené nastavení je unset.
112
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Následující tabulka předvádí několik příkladů hesel a výsledků politiky hesel, na základě předvolených hodnot pěti parametrů pdadmin: Tabulka 21. Příklady hesel Příklad
Výsledek
password
Není platné: musí obsahovat alespoň jeden neabecední znak.
pass
Není platné: musí obsahovat alespoň 8 znaků.
passs1234
Není platné: obsahuje více než dva opakující se znaky.
12345678
Není platné: musí obsahovat alespoň čtyři abecední znaky.
password3
Platné.
Nastavení pro určitého uživatele a globální nastavení Příkazy politiky pdadmin je možné nastavit pro určitého uživatele (pomocí volby - user), nebo globálně (když nepoužijete volbu - user). Jakékoliv nastavení pro určitého uživatele přepisuje globální nastavení politiky. Můžete také zakázat (unset) parametr politiky, což znamená, že parametr neobsahuje žádnou hodnotu. Politika s volbou unset se nekontroluje nebo nepoužívá. Například: pdadmin> policy set min-password-length 8 pdadmin> policy set min-password-length 4 -user matt pdadmin> policy get min-password-length Minimální délka hesla: 8 pdadmin> policy get min-password-length -user matt Minimální délka hesla: 4
Uživatel matt má nastavenu politiku minimální délky hesla na 4 znaky, všichni ostatní uživatelé mají politiku minimální délky hesla nastavenu na 8 znaků. pdadmin> policy set min-password-length unset -user matt
Uživatel matt se nyní musí řídit globálním nastavením délky hesla na 8 znaků. pdadmin> policy set min-password-length unset
Všichni uživatelé, včetně uživatele matt nyní nepoužívají omezení délky hesla.
Politika POP odolnosti autentizace (zvýšená) Politika POP (Protected Object Policy) odolnosti autentizace umožňuje řídit přístup k objektům na základě politiky autentizace, kterou používají. Tuto funkcionalitu – někdy známou také jako zvýšenou autentizaci – můžete používat, abyste se ujistili, že uživatelé, kteří přistupují k citlivějším zdrojům, používají silnější mechanismus autentizace. Jelikož u podobných zdrojů existuje velká hrozba nezákonného přístupu, může nastat situace, kdy budete chtít tuto podmínku použít. Můžete například zajistit větší bezpečnost oblasti webového prostoru pomocí zvýšené POP politiky, která vyžaduje vyšší úroveň autentizace, než kterou používají klienti při prvním vstupu do domény plug-in programu. Zvýšená autentizace může být také nastavena pro určité virtuální hostitele na webovém serveru, čímž dovolí individuálním virtuálním hostitelům mít své vlastní zvýšené úrovně autentizace, aniž by byly součástí implementace bezpečnostní politiky celého serveru. Kapitola 4. Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers
113
Politika odolnosti autentizace se nastavuje v atributu Metoda autentizace pomocí koncového bodu IP politiky POP.
Konfigurace úrovní pro zvýšenou autentizaci Prvním krokem v konfiguraci přístupu specifického pro danou autentizaci je nakonfigurovat podporované metody autentizace a určit pořadí, ve kterém se dá předpokládat, že tyto metody autentizace budou nejodolnější. Podrobné informace o konfiguraci mechanismů autentizace najdete v části Kapitola 3, “Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers”, na stránce 39. Každý klient, který přistupuje k webovému serveru prostřednictvím plug-in programu, má nějakou úroveň autentizace, jako např. ″neautentizovaný″ nebo ″heslo″, která označuje metodu, pomocí níž se klient naposledy autentizoval prostřednictvím plug-in programu. V některých situacích může být nezbytné vynutit minimální ″bezpečné″ úrovně autentizace, které budou vyžadovány pro přístup k některým objektům webového prostoru. Například v jednom prostředí může být autentizace pomocí token passcode považována za bezpečnější než autentizace pomocí jména uživatele a hesla. Jiné prostředí může potřebovat jiné standardy. Spíše než aby byli klienti nuceni znovu spustit své relace, když nesplňují požadovanou úroveň autentizace, mechanismus zvýšené autentizace dává klientům druhou šanci, aby se znovu autentizovali pomocí požadované metody (úrovně). Zvýšená autentizace znamená, že uživateli není okamžitě zobrazena zpráva ″zamítnuto″, když se pokusí přistoupit ke zdroji, který vyžaduje ″vyšší″ úroveň autentizace, než se kterou je tento uživatel přihlášen. Namísto toho se mu zobrazí další výzva k autentizaci, která požaduje informace, které se opírají o vyšší úroveň autentizace. Pokud je schopen dodat tuto úroveň autentizace, jeho původní požadavek bude povolen. Úrovně autentizace můžete nakonfigurovat ve stanzách [authentication-levels] nebo [authentication-levels:označení-virtuálního-hostitele] konfiguračního souboru pdwebpi.conf. Například: [authentication-levels] 1 = BA 2 = iv-headers 3 = cert
Podle pořadí metod v seznamu je každé metodě přiřazen index úrovně. v Předpokládá se, že neautentizovaný má úroveň 0. v Další metody mohou být umístěny v libovolném pořadí. Viz “Poznámky a omezení zvýšené autentizace” na stránce 116. v Chcete-li povolit zvýšenou autentizaci, musíte mít v této stanze minimálně dva záznamy. v Úrovně mechanismu autentizace je možné nastavit pro určité virtuální hostitele, pokud uvedete úrovně pomocí stanzy ve tvaru: [authentication-levels:jméno-virtuálníhohostitele] Poznámka: Podrobné informace o nastavení požadovaného mechanismu autentizace najdete v části Kapitola 3, “Zpracování požadavku a autentizace produktu IBM Tivoli Access Manager Plug-in for Web Servers”, na stránce 39.
Aktivace zvýšené autentizace Zvýšená autentizace je implementována pomocí politiky POP uložené na objektech, které vyžadují autorizaci pomocí citlivé autentizace. Používáte atribut politiky POP s názvem Metoda autentizace pomocí koncového bodu IP.
114
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Příkaz pdadmin pop modify set ipauth určuje jak povolené sítě, tak i požadované úrovně autentizace v atributu IP Endpoint Authentication Method. Nakonfigurované úrovně autentizace mohou být propojeny do oblastí IP adres. Cílem této metody je pružnost správy. Pokud není důležité filtrovat uživatele podle IP adresy, můžete nastavit jeden záznam pro anyothernw (libovolná další síť). Toto nastavení ovlivní všechny přistupující uživatele bez ohledu na jejich IP adresy a vyžaduje, aby se všichni autentizovali na zadané úrovni. Toto je nejčastější způsob implementace zvýšené autentizace. Syntaxe: pdadmin> pop modify pop_name set ipauth anyothernw level_index
Záznam anyothernw se používá jako rozsah sítí, který odpovídá libovolné síti, není-li jinak uvedeno v POP. Tato metoda se používá k vytvoření předvoleného záznamu, který by mohl buď zakázat všechny neodpovídající IP adresy, nebo povolit přístup každému, který může splňovat požadavky na úroveň autentizace. Standardně se anyothernw objevuje v POP spolu s indexem úrovně autentizace o hodnotě 0. Záznam se v příkazu pop show zobrazí jako ″Libovolná jiná síť″: pdadmin> pop show test Politika chráněného objektu: test Popis: Test POP Varování: ne Úroveň auditu: žádná Úroveň zabezpečení: žádná Přístup během dne: ne, po, út, st, čt, pá, so: kdykoliv:lokální Metoda autentizace koncového bodu IP Libovolná jiná síť 0
Během zvýšené autentizace může být ověření platnosti dodaného ID uživatele aktivováno nastavením parametru verify-step-up-user ve stanze [module-mgr] na true. [module-mgr] verify-step-up-user = true
Aktivace parametru verify-step-up-user zajišťuje, že když jste vyzváni k další autentizaci pomocí mechanismu vyšší úrovně, zadaná identita odpovídá původně zadané. Když se identity neshodují, je vrácena stránka ’403 Forbidden’.
Příklad zvýšené autentizace 1. Nakonfigurujte úrovně autentizace v souboru pdwebpi.conf: [authentication-levels] nebo [authentication-levels:označení-virtuálního-hostitele] 1 = BA 2 = token
2. Nakonfigurujte atribut POP metody autentizace pomocí koncového bodu IP: pdadmin> pop modify test set ipauth anyothernw 2 pdadmin> pop show test Politika chráněného objektu: test Popis: Test POP Varování: ne Úroveň auditu: žádná Úroveň zabezpečení: žádná Přístup během dne: po, st, pá:kdykoliv:lokální Metoda autentizace koncového bodu IP Libovolná jiná síť 2
Proto budou uživatelé, kteří budou přistupovat k objektu chráněnému politikou test POP, nuceni autentizovat se na úrovni 2 nebo budou donuceni, aby se autentizovali pomocí Kapitola 4. Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers
115
tokenu. Viz též “Autentizace pomocí POP založená na síti” na stránce 118.
Poznámky a omezení zvýšené autentizace v Zvýšená autentizace je podporována jak HTTP tak i HTTPS. v Nemůžete zvýšit úroveň z HTTP protokolu na HTTPS. v Metody autentizace, které nejsou uvedeny ve stanze [authentication-levels], jsou standardně nastaveny na úroveň 1. v Metody autentizace je možné v seznamu úrovní uvést pouze jednou. v Autentizaci pomocí SPNEGO nelze zvýšit na žádnou metodu autentizace, která používá formuláře POST. Výsledkem konfigurace zvýšené autentizace pomocí modulu autentizace pomocí SPNEGO může být chybová stránka, která bude vrácena klientovi. v Nesprávná konfigurace úrovní zvýšené autentizace vede k zablokování funkcionality zvýšení úrovně v plug-in programu. Tato situace může vést k neočekávanému chování autentizace, např. může být vydána stránka pro přihlášení pomocí hesla pro objekty, které jsou chráněné pomocí POP, a které vyžadují metodu autentizace pomocí token passcode. Až nakonfigurujete mechanismus zvýšené autentizace, zkontrolujte soubor pdwebpi.log, zda v něm nejsou zaznamenány nějaké konfigurační chyby.
Vícefaktorová autentizace Funkcionalita vícefaktorové autentizace je rozšířením funkcionality zvýšené autentizace, která vám umožňuje uvést politiku chráněného objektu (POP), která přinutí uživatele, aby se autentizoval pomocí všech mechanismů autentizace s úrovní nižší než úroveň autentizace nakonfigurované POP. To znamená, že se uživatel před udělením přístupu musí autentizovat na všech úrovních do požadované úrovně včetně ní. Vícefaktorová autentizace může být také použita ve spojení s opětovnou autentizací, aby vynutila vícefaktorovou opětovnou autentizaci. Autentizace na základě standardní úrovně autentizace umožňuje, aby byla politika přidružena k objektu nastavujícímu minimální požadovanou úroveň autentizace, která musí být před udělením přístupu archivována. Podporované mechanismy autentizace poskytují pořadí v konfiguraci udávající, které mechanismy jsou považovány za silnější než ostatní. Když se uživatel nejdříve autentizuje pro přístup k objektu, je mu poskytnut výběr všech metod autentizace, které mají požadovanou úroveň pro tento objekt. Je na uživateli, aby si zvolil, kterou metodu použije. Aby zvýšená autentizace dosáhla vícefaktorovou autentizaci, musí být nakonfigurována, jak je řečeno v části “Politika POP odolnosti autentizace (zvýšená)” na stránce 113. Jakmile je zvýšená autentizace nakonfigurována, musíte do politiky chráněného objektu (POP) pro objekt nebo objekty produktu Tivoli Access Manager Plug-in for Web Servers přidat rozšířený atribut MULTI-FACTOR-AUTH. Když je atribut MULTI-FACTOR-AUTH nastaven, jsou před udělením přístupu ke zdroji požadovány všechny úrovně autentizace do uvedené úrovně autentizace politiky POP. Pro příklad předpokládejme, že je v konfiguračním souboru nastavena následující konfigurace: [authentication-levels] 1 = cert 2 = forms
Když se s výše uvedenou konfigurací politika POP připojí ke zdroji, který vyžaduje úroveň autentizace 2 a nový atribut MULTI-FACTOR-AUTH je nastaven na true, musí uživatel před
116
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
přihlášením pomocí formulářů nejprve dodat platný certifikát klienta. Když se politika POP připojí ke zdroji, který nemá aktivován atribut MULTI-FACTOR-AUTH, použije se pouze autentizace pomocí formulářů.
Aktivace vícefaktorové autentizace Vícefaktorová autentizace je implementována pomocí politiky POP uložené na objektech, které ji vyžadují. Syntaxe: pdadmin> pop modify pop_name set attribute MULT-FACTOR_AUTH true
Opětovná autentizace pomocí politiky chráněného objektu Produkt Tivoli Access Manager Plug-in for Web Servers může donutit uživatele, aby provedl další přihlášení se (opětovnou autentizaci), chce-li zajistit, že uživatel, který přistupuje ke chráněnému zdroji, je stejnou osobou, která se původně autentizovala na začátku relace. Opětovnou autentizaci může aktivovat politika chráněného objektu (POP - Protected Object Policy) na chráněném objektu nebo při překročení časového limitu nečinnosti paměti cache relace. Tato část probírá opětovnou autentizaci, která je založena na bezpečnostní politice, jak je nastaveno v rozšířeném atributu POP. Podrobné informace o konfiguraci paměti cache relace/pověření najdete v části “Konfigurace paměti cache pro relace/pověření plug-in programu” na stránce 50.
Podmínky ovlivňující opětovnou autentizaci pomocí POP Vynucená opětovná autentizace poskytuje další ochranu citlivých zdrojů v zabezpečené doméně. Opětovná autentizace založená na bezpečnostní politice se aktivuje pomocí určitého rozšířeného atributu v POP, který chrání požadované objekty zdrojů. POP může být přímo připojena k objektu, nebo objekt může převzít podmínky POP od nadřízeného objektu. Opětovná autentizace je podporována následujícími metodami autentizace plug-in programu: v autentizace pomocí formulářů (jména uživatele a hesla) v autentizace pomocí tokenů Dále je možné napsat uživatelský modul CDAS pro jméno uživatele/heslo, který bude podporovat opětovnou autentizaci. Opětovná autentizace předpokládá, že se uživatel již přihlásil do zabezpečené domény a že pro tohoto uživatele existuje platné pověření. Během opětovné autentizace se musí uživatel přihlásit pomocí stejné totožnosti, která byla použita pro vygenerování stávajícího pověření. Produkt Tivoli Access Manager udržuje během opětovné autentizace původní informace o relaci uživatele, včetně pověření. Pověření se během opětovné autentizace nenahrazuje. Během opětovné autentizace dále plug-in program ukládá do paměti cache požadavek, který byl důvodem výzvy k opětovné autentizaci. Po dokončení úspěšné opětovné autentizace se data uložená do paměti cache použijí na rekonstrukci požadavku. Pokud dojde k selhání opětovné autentizace, plug-in program znovu vrátí výzvu k přihlášení. Pokud bude opětovná autentizace úspěšně dokončena, ale kontrola ACL pro daný zdroj selže, bude vrácena zpráva 403 ″Zakázáno″ a uživateli je zakázán přístup k požadovanému zdroji. V každém případě není uživatel nikdy odhlášen. Pomocí stále platného pověření může uživatel přerušit proces opětovné autentizace (tak, že požádá o jiné URL) a může i nadále pracovat v zabezpečené doméně a přistupovat k jiným zdrojům, které nevyžaduji opětovnou autentizaci.
Kapitola 4. Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers
117
Vytvoření a použití opětovné autentizace pomocí POP Vynucená opětovná autentizace založená na bezpečnostní politice se nakonfiguruje tak, že se vytvoří politika chráněného objektu (POP - Protected Object Policy) se speciálním rozšířeným atributem se jménem ″reauth″. Tuto politiku POP můžete připojit k libovolnému objektu, jenž vyžaduje další ochranu, kterou je možné splnit pomocí vynucené opětovné autentizace. Pamatujte, že všechny podřízené objekty objektu s POP také přebírají podmínky POP. Každý požadovaný podřízení objekt vyžaduje samostatnou opětovnou autentizaci. Použijte příkazy pdadmin pop create, pdadmin pop modify a pdadmin pop attach. Následující příklad demonstruje vytvoření POP s názvem ″secure″ a s rozšířeným atributem reauth, a její připojení k objektu: pdadmin>pop create secure pdadmin>pop modify secure set attribute REAUTH true pdadmin>pop attach /PDWebPI/hostA/budget.html secure
Každý, kdo se pokusí přistoupit k budget.html, je donucen se opětovně autentizovat pomocí stejné totožnosti a metody autentizace, pomocí které bylo vygenerováno stávající pověření. Pokud je uživatel požadující zdroj neautentizovaný, POP ho donutí se autentizovat. Opětovná autentizace se vyžaduje při každém přístupu k objektu chráněnému politikou opětovné autentizace. V případě, že většina objektů v adresáři vyžaduje opětovnou autentizaci, zatímco některé z nich nikoliv, je nejlepší k celému adresáři připojit politiku POP včetně rozšířeného atributu ″reauth″. Pro ty objekty, které nevyžadují opětovnou autentizaci, připojte politiku POP, která je totožná s politikou, která je připojena k adresáři, s výjimkou rozšířeného atributu ″reauth″. Podrobné informace o obslužném programu pdadmin s příkazovým řádkem můžete najít v knize IBM Tivoli Access Manager Base: Administrativní příručka.
Autentizace pomocí POP založená na síti Autentizace pomocí POP založená na síti umožňuje řídit přístup k objektům na základě IP adresy uživatele. Tuto funkcionalitu můžete použít k tomu, abyste zabránili určitým IP adresám (nebo rozsahům IP adres) v přístupu ke všem zdrojům ve vaší zabezpečené doméně. Pro tuto politiku můžete také použít konfiguraci zvýšené autentizace a dále můžete vyžadovat určitou metodu autentizace pro každý uvedený rozsah IP adres. Politika autentizace založené na síti je nastavena v atributu Metoda autentizace pomocí koncového bodu IP politiky POP. V tomto atributu musíte uvést dva požadavky: v úrovně autentizace v povolené sítě Podrobné informace, jak zadat informace o úrovni konfigurace, najdete v části “Konfigurace úrovní pro zvýšenou autentizaci” na stránce 114.
Určení IP adres a rozsahů Až nakonfigurujete úrovně autentizace, musíte uvést IP adresy a rozsahy IP adres, které jsou povoleny touto politikou POP. Příkaz pdadmin pop modify set ipauth add určuje jak síť (nebo rozsah sítí) tak i požadovanou úroveň autentizace atributu Metody autentizace pomocí koncového bodu IP.
118
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Syntaxe: pdadmin> pop modify pop_name set ipauth add network netmask level_index
Nakonfigurované úrovně autentizace jsou propojeny na rozsahy IP adres. Cílem této metody je pružnost. Pokud není důležité filtrovat uživatele podle IP adresy, můžete nastavit jeden záznam pro anyothernw (libovolná další síť). Toto nastavení ovlivní všechny přistupující uživatele bez ohledu na jejich IP adresy a vyžaduje, aby se všichni autentizovali na zadané úrovni. Syntaxe: pdadmin> pop modify pop_name set ipauth anyothernw level_index
Naopak, pokud si přejete ignorovat úrovně autentizace a chcete pouze povolit nebo zakázat přístup na základě IP adresy, můžete použít úroveň 0 pro rozsahy IP adres, které chcete povolit a ″zakázáno″ pro rozsahy, které chcete zakázat. Záznam anyothernw se používá pro rozsah sítí, které odpovídají každé síti, která nebyla jinak určena v politice POP. Tato metoda se používá k vytvoření předvoleného záznamu, který by mohl buď zakázat všechny neodpovídající IP adresy, nebo povolit přístup každému, kdo může splňovat požadavky na úroveň autentizace. Standardně se anyothernw objevuje v POP spolu s indexem úrovně autentizace o hodnotě 0. Záznam se v příkazu pop show zobrazí jako ″Libovolná jiná síť″: pdadmin> pop show test Politika chráněného objektu: test Popis: Test POP Varování: ne Úroveň auditu: žádná Úroveň zabezpečení: žádná Přístup během dne: ne, po, út, st, čt, pá, so: kdykoliv:lokální Metoda autentizace koncového bodu IP Libovolná jiná síť 0
Podrobné vysvětlení nastavení úrovní autentizace najdete v části “Konfigurace úrovní pro zvýšenou autentizaci” na stránce 114.
Příklad Vyžadujete, aby se uživatelé z rozsahu IP adres 9.0.0.0 s maskou sítě 255.0.0.0 hlásili na úrovni autentizace 1 (standardně ″heslo″): pdadmin> pop modify test set ipauth add 9.0.0.0 255.0.0.0 1
Vyžadujete, aby určitý uživatel používal autentizaci na úrovni 0: pdadmin> pop modify test set ipauth add 9.1.2.3 255.255.255.255 0
Chcete zabránit všem uživatelům (kromě toho, který byl uveden v příkladu výše) přistupovat k objektu: pdadmin> pop modify test set ipauth anyothernw forbidden
Zablokování zvýšené autentizace pomocí IP adresy Abystze zablokovali zvýšenou autentizaci IP adresou, zadejte následující příkaz: pdadmin> pop modify pop_name set ipauth remove network netmask
Například: pdadmin> pop modify test set ipauth remove 9.0.0.0 255.0.0.0
Kapitola 4. Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers
119
Algoritmus autentizace založené na síti Produkt Tivoli Access Manager Plug-in for Web Servers používá ke zpracování podmínek v politice POP následující algoritmus: 1. Zkontroluje politiku politiky autentizace pomocí koncového bodu IP v politice POP. 2. Zkontroluje oprávnění v ACL. 3. Zkontroluje politiku přístupu během dne v politice POP. 4. Zkontroluje politiku úrovně auditu v politice POP.
Úroveň zabezpečení politiky chráněného objektu Atribut úroveň zabezpečení politiky POP vám umožňuje určit, jakou úroveň zabezpečení dat vyžadujete při provádění operací s objektem. pdadmin> pop modify pop_name set qop {none|integrity|privacy} Tabulka 22. Popisy úrovní POP Úroveň QOP
Popis
privacy
Vyžaduje se zašifrování dat (SSL).
integrity
Použijí se některé mechanismy, které zajistí, že se data nezmění.
none
Nepoužije se žádná metoda ochrany dat.
Například: pdadmin> pop modify test set qop privacy
Atribut úroveň zabezpečení politiky POP povoluje jednu transakci, pokud odpověď ″ano″ na rozhodnutí politiky ACL současně obsahuje také požadovanou úroveň zabezpečení. Pokud plug-in program nemůže zaručit požadovanou úroveň ochrany, požadavek se zamítne.
Zacházení s neautentizovanými uživateli (HTTP/HTTPS) Produkt Tivoli Access Manager Plug-in for Web Servers přijímá požadavky jak od autentizovaných, tak i od neautentizovaných uživatelů přes protokoly HTTP a HTTPS. Plug-in program se potom spoléhá na autorizační server, který má vynutit bezpečnostní politiku tak, že povolí nebo zakáže přístup ke chráněným zdrojům. Pro neautentizované uživatele, kteří přistupují přes protokol SSL, platí následující podmínky: v Výměna informací mezi neautentizovaným uživatelem a plug-in programem je zašifrována – jako kdyby šlo o autentizovaného uživatele. v Připojení SSL mezi neautentizovaným uživatelem a plug-in programem vyžaduje pouze autentizaci na straně serveru.
Zpracování požadavku od anonymního klienta 1. Anonymní klient podává požadavek na webový server prostřednictvím plug-in programu (pomocí HTTP nebo HTTPS). 2. Plug-in program vytvoří pro tohoto klienta neautentizované pověření. 3. Požadavek je postoupen s tímto pověřením chráněnému webovému objektu. 4. Autorizační server zkontroluje oprávnění na neautentizovaném záznamu v ACL pro tento objekt a povolí nebo zakáže požadovanou operaci. 5. Úspěšné přistoupení k tomuto objektu závisí na záznamu pro neautentizované uživatele v ACL, který by měl obsahovat minimálně oprávnění pro čtení (r). 6. Pokud požadavek selže při rozhodnutí o autorizaci, klient obdrží formulář pro přihlášení (BA nebo založený na formulářích).
120
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Přinucení uživatele, aby se přihlásil Můžete přinutit neautentizovaného uživatele, aby se přihlásil tak, že správně nastavíte odpovídající oprávnění u neautentizovaného záznamu v politice ACL, která chrání požadovaný objekt. Oprávnění pro čtení [PDWebPI]r umožňuje neautentizovaným uživatelům přistupovat k objektu. Pokud chcete přinutit neautentizovaného uživatele, aby se přihlásil, odstraňte oprávnění pro čtení [PDWebPI]r z neautentizovaného záznamu v politice ACL, která chrání objekt.
Použití neautentizovaného HTTPS Existuje mnoho praktických obchodních důvodů, aby byl podporován neautentizovaný přístup přes HTTPS k webovému serveru rozšířenému o plug-in program.Tyto důvody jsou: v Některé aplikace nevyžadují osobní přihlášení, ale vyžadují citlivé informace, jako např. adresu nebo číslo kreditní karty. Příkladem mohou být online nákupy letenek nebo jiného zboží. v Některé aplikace vyžadují, abyste se přihlásili na účet s obchodem, než budete moci pokračovat dalšími transakcemi. Znovu platí, že přes síť musí být předány citlivé informace.
Řízení neautentizovaných uživatelů pomocí politik ACL/POP Abyste řídili neautentizované uživatele pomocí politik ACL/POP: Poznámka: Typ záznamu ″any-other″ (ostatní, každý-další) je také znám jako typ záznamu ″any-authenticated″ (každý-autentizovaný). 1. Chcete-li povolit neautentizovaným uživatelům přistupovat k veřejným objektům, chraňte obsah veřejných objektů pomocí přístupového seznamu, který bude obsahovat pro záznamy unauthenticated (neautentizovaný) a any-other (ostatní) minimálně oprávnění [PDWebPI]r: unauthenticated [PDWebPI]r any-other [PDWebPI]r
Poznámka: Záznam unauthenticated je maska (logická operace ″and″) pro záznam any-other, jsou-li určena oprávnění. Oprávnění pro unauthenticated je uděleno pouze tehdy, je-li oprávnění současně i u záznamu any-other. Poněvadž unauthenticated závisí na any-other, má malý význam, aby ACL obsahoval unauthenticated bez any-other. Pokud ACL obsahuje unauthenticated bez any-other, pak předvolenou odpovědí je neudělit žádná oprávnění pro unauthenticated. 2. Pokud vyžadujete šifrování (SSL), chraňte obsah pomocí politiky chráněného objektu (POP - protected object policy), která určí jako podmínku utajení (privacy). Viz část “Úroveň zabezpečení politiky chráněného objektu” na stránce 120.
Kapitola 4. Bezpečnostní politika produktu IBM Tivoli Access Manager Plug-in for Web Servers
121
122
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Kapitola 5. Řešení jednotného přihlášení pro web Je-li produkt Tivoli Access Manager Plug-in for Web Servers implementován jako autorizační služba, aby poskytoval ochranu zabezpečené doméně, často se objevuje ještě požadavek, aby byl současně řešením pro jednotné přihlášení ke zdrojům v této doméně. Tato kapitola probírá řešení jednotného přihlášení pro webový prostor, chráněný produktem Tivoli Access Manager Plug-in for Web Servers. Tato kapitola obsahuje následující témata: v “Koncepty jednotného přihlášení” v “Automatické přihlášení do zabezpečené aplikace” na stránce 124 v “Jednotné přihlášení do plug-in programu z WebSEAL nebo jiné proxy” na stránce 126 v “Použití failover cookie pro jednotné přihlášení” na stránce 127 v “Používání globálního jednotného přihlášení (GSO - Global single sign-on)” na stránce 128 v “Jednotné přihlášení pomocí SPNEGO (Security Provider NEGOtiation)” na stránce 131 v “Jednotné přihlášení pomocí formulářů” na stránce 131
Koncepty jednotného přihlášení Je-li chráněný zdroj umístěn na webovém aplikačním serveru rozšířeném o plug-in program, může být na klientovi, který žádá o určitý zdroj, požadováno, aby provedl několik přihlášení, pokud přistupuje k různým zabezpečeným aplikacím. Každé přihlášení pravděpodobně bude vyžadovat různé totožnosti přihlášení. Problém správy a udržování více totožností přihlášení je často možné vyřešit pomocí mechanismu pro jednotné přihlášení (SSO - single signon). SSO dovoluje uživateli přistupovat ke zdroji pomocí jediného počátečního přihlášení. Všechny další požadavky na přihlášení, nutné pro zdroje na webovém serveru, jsou obsluhovány tak, aby celý proces byl pro uživatele zcela transparentní. Produkt Tivoli Access Manager Plug-in for Web Servers podporuje řadu různých architektur řešení pro jednotné přihlášení. Jsou to: 1. Jedna instance plug-in programu, která poskytuje jednotné přihlášení pro více než jednu zabezpečenou aplikaci na serveru. 2. Jednotné přihlášení na plug-in program ze serveru WebSEAL nebo jiného proxy agenta, jako je např. komunikační brána WAP. 3. Failover cookies použité tak, aby umožnily jednotné přihlášení mezi rozdílnými doménami. 4. Modul GSO (Global Single sign-on) Lockbox použitý tak, aby umožnil přístup k aplikacím pomocí uložených informací o pověření klienta. 5. SPNEGO (Security Provider NEGOtiation) použitá tak, aby povolila přístup ke zdrojům na webových serverech založených na technologii IIS. 6. Autentizace pomocí formulářů jako mechanismus pto SSO. 7. CDSSO (Cross Domain Single Sign On) poskytující mechanismus pro přenos pověření uživatele přes vícenásobné zabezpečené domény. 8. Jednotné přihlášení e-community, ve kterém se uživatel jednou autentizuje a pak je vydán token, který uživateli umožní přistupovat i k jiným doménám v rámci virtuální komunity domén, aniž by byl nucen se znovu autentizovat. © Copyright IBM Corp. 2000, 2003
123
Prvních šest scénářů jednotného přihlášení je probíráno v této kapitole. Sedmý a osmý scénář jsou tématem následující kapitoly.
Automatické přihlášení do zabezpečené aplikace Chcete-li docílit SSO k aplikaci na serveru, který je chráněn jednou instancí plug-in programu, můžete použít HTTP hlavičky a LTPA cookies (je-li aplikací WebSphere Application Server). Po dokončení úvodní autentizace klienta může plug-in program vytvořit HTTP hlavičku, která obsahuje informace o totožnosti klienta a kterou je možné použít k automatické autentizaci klienta do zabezpečené aplikace spuštěné na serveru. Podobným způsobem je možné použít LTPA cookie, chcete-li docílit SSO na webový aplikační server, jako např. na WebSphere.
Konfigurace jednotného přihlášení do zabezpečených aplikací pomocí HTTP hlaviček HTTP hlavičky, které se používají pro přihlášení do aplikace, jsou vytvářeny modulem pro zpracování následujícího po autorizaci iv-header. Sada hlaviček, které je možné vytvořit, se souhrnně nazývá IV hlavičky. Po dokončení úspěšné autorizace požadavku uživatele plug-in program může vložit IV hlavičky, které definují totožnost klienta do požadavku na zpracování pomocí aplikace. Tyto informace v hlavičce je možné použít jako potvrzení totožnosti uživatele, je-li požadavek zpracováván aplikací umístěnou na zabezpečeném webovém serveru. Uživatel je ušetřen nutnosti přihlásit se pokaždé, kdy je přistupováno k nové zabezpečené aplikaci. Jsou-li IV hlavičky nakonfigurovány pro zpracování následující po autorizaci, jsou tyto hlavičky vkládány pomocí jednoho, některých nebo všech typů HTTP hlaviček: iv-user, iv-user-l, iv-creds, iv-groups, iv-remote-address. Uvedené typy hlaviček jsou popsány v následující tabulce. Tabulka 23. Popis polí IV hlavičky Pole IV hlavičky
Popis
iv-user
Krátké jméno uživatele produktu Tivoli Access Manager. Standardně je nastaveno na neautentizován, pokud je klient neautentizován (neznámý).
iv-user-l
Plné jméno domény uživatele (dlouhý formát), například rozlišovací jméno LDAP.
iv-groups
Seznam skupin, jejichž členem je uživatel.
iv-creds
Neprůhledně zakódovaná struktura dat představující pověření uživatele produktu Tivoli Access Manager.
iv-remote-address
IP adresa klienta. Tato hodnota by mohla představovat i IP adresu proxy serveru nebo NAT (network address translator).
Aktivace a zablokování vytváření IV hlaviček Pokud chcete povolit plug-in programu, aby vkládal IV hlavičky do autorizovaných požadavků, musí být plug-in program nakonfigurován tak, aby používal IV hlavičky pro zpracování následující po autorizaci. Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete aktivovat IV hlavičky pro zpracování následující po autorizaci, přiřaďte hodnotu iv-headers parametru post-authzn ve stanze [common-modules] konfiguračního souboru pdwebpi.conf. To znamená: [common-modules] post-authzn = iv-headers
124
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Konfigurace parametrů IV hlaviček Parametry autentizace pomocí IV hlaviček jsou nakonfigurovány ve stanze [iv-headers] konfiguračního souboru pdwebpi.conf. Parametr generate určuje typ IV hlaviček, který se má vytvořit, je-li přeposílán požadavek prošlý přes proxy. Standardně plug-in program vygeneruje všechny typy IV hlaviček, pokud přeposílá požadavky prošlé přes proxy. Platné volby jsou: all, iv-creds, iv-user, iv-user-l, iv-remote-address. Pokud chcete zadat více než jeden typ hlavičky, oddělte hodnoty čárkou. Například: [iv-headers] generate = iv-creds,iv-user,iv-user-1
Jednotné přihlášení do WebSphere Application server pomocí LTPA cookies Pokud je plug-in program nainstalován jako ochranná vrstva na aplikačním serveru WebSphere, přistupující klienti stojí před dvěma potenciálními body přihlášení – plug-in programem a zabezpečenou aplikací obsluhovanou WebSphere. Chcete-li nabídnou v této situaci jednotné přihlášení, plug-in program je možné nakonfigurovat tak, aby vygeneroval a předával LTPA (lightweight Third Party Authentication) cookie webovým aplikačním serverům, které podporují LTPA cookies. Když uživatel vydá požadavek na zdroj umístěný na serveru, musí se nejprve autentizovat do plug-in programu. Po dokončení úspěšné autentizace plug-in program vygeneruje v zastoupení uživatele LTPA cookie. LTPA cookie, která funguje jako autentizační token pro webový aplikační server, obsahuje informace o totožnosti uživatele a hesle. Tyto informace jsou zašifrovány pomocí heslem chráněného tajného klíče, který je sdílen plug-in programem a aplikačním serverem. Plug-in program vloží cookie do HTTP hlavičky požadavku, který se odešle na webový aplikační server. Aplikační server obdrží požadavek, dešifruje cookie a autentizuje uživatele na základě informací o totožnosti, které byly dodány v cookie. Proto, aby byla zlepšena výkonnost, plug-in program ukládá LTPA cookie do paměti cache relace a používá LTPA cookie uloženou do paměti cache pro následující požadavky v rámci stejné relace uživatele. Podrobné informace o nastavení parametrů paměti cache relace najdete v části “Konfigurace paměti cache pro relace/pověření plug-in programu” na stránce 50.
Konfigurace jednotného přihlášení do WebSphere pomocí LTPA cookies Použití LTPA cookies k tomu, aby bylo dosaženo jednotného přihlášení do aplikačních serverů podporujících LTPA cookies, je součástí zpracování následujícího po autorizaci plug-in programu. Pokud chcete tuto funkcionalitu aktivovat, zadejte klíčovou hodnotu ltpa do parametru post-authzn stanzy [common-modules] konfiguračního souboru pdwebpi.conf. [common-modules] post-authzn = ltpa
Kapitola 5. Řešení jednotného přihlášení pro web
125
Konfigurace LTPA cookie se provádí ve stanze [ltpa] konfiguračního souboru pdwebpi.conf. Následující parametry vyžadují konfiguraci. Tabulka 24. Parametry konfigurace LTPA Parametr
Popis
ltpa-keyfile
Úplná cesta k souboru klíčů, který se používá k zašifrování informací, obsažených v cookie.
ltpa-stash-file
Umístění souboru pro uložení hesla. Pokud neexistuje žádný soubor pro uložení hesla, tento záznam může být zakomentován.
ltpa-password
Heslo, které se bude používat, pokud soubor pro uložení hesla neexistuje.
ltpa-lifetime
Doba trvání (ve vteřinách) LTPA cookie.
Technické poznámky pro jednotné přihlášení pomocí LTPA v Soubor klíčů obsahuje informace o určitých webových aplikačních serverech. Pokud přidáte více než jeden aplikační server do stejného plug-in programu, všechny servery budou sdílet stejný soubor klíčů. v Má-li být jednotné přihlášení úspěšné, plug-in program a aplikační server musí nějakým způsobem sdílet informace o stejném registru. v Aplikační server je odpovědný za nastavení LTPA a vytvoření sdíleného tajného klíče.
Jednotné přihlášení do plug-in programu z WebSEAL nebo jiné proxy Pokud webový server rozšířený o plug-in program obdrží požadavek z ověřené aplikace, jako např. ze serveru WebSEAL nebo MPA (multiplexing proxy agent) agenta, je možné vložit IV hlavičky do požadavku předaného plug-in programu. IV hlavičky obsahují informace, které identifikují původního klienta, a ne předávající server. Informace v hlavičkách se používají k vytvoření pověření původního klienta pro účely autorizace. Je-li plug-in program nakonfigurován tak, aby používal IV hlavičky k provádění autentizace klienta, pak tento plug-in program vytvoří pověření klienta pomocí totožnosti, kterou získá z IV hlavičky nalezené v požadavku transakce. Protože je pro klienty jednoduché padělat IV hlavičky, je podobné pověření vytvořeno pouze tehdy, pokud je v požadavku na autentizaci nastaven příznak ’použít sekundárního autentizátora’. Pro autentizaci platí, že IV hlavičky je možné nakonfigurovat tak, aby přijímaly jednu, některé nebo všechny hlavičky iv-user, iv-user-l, iv-creds nebo iv-remote-address v požadavku, jako potvrzení o autentizaci, pokud byly tyto přijaty prostřednictvím proxy. Hlavička iv-remote-address se používá k zaznamenání skutečné vzdálené adresy uživatele. Tyto typy IV hlaviček jsou rozeznávány produktem Tivoli Access Manager a serverem WebSEAL. Tabulka 25. Popis polí IV hlavičky
126
Pole IV hlavičky
Popis
iv-user
Krátké jméno klienta. Standardně je nastaveno na neautentizován, pokud je klient neautentizován (neznámý).
iv-user-l
Plné jméno domény uživatele (dlouhý formát).
iv-groups
Seznam skupin, jejichž členem je uživatel.
iv-creds
Neprůhledně zakódovaná struktura dat představující pověření uživatele produktu Tivoli Access Manager.
iv-remote-address
IP adresa klienta. Tato hodnota by mohla představovat i IP adresu proxy serveru nebo NAT (network address translator).
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Poznámka: Access Manager věří pouze hlavičkám, které obdržel od důvěryhodných a ověřených předřazených počítačů. Předřazený počítač je považován za ověřený a důvěryhodný, pokud je rozeznáván jako agent MPA (Multiplexing Proxy Agent). Podrobné informace o konfiguraci plug-in programu pro podporu agentů MPA najdete v části “Podpora MPA (Multiplexing Proxy Agents)” na stránce 103. Pokud mají být přijímáni jako ověření totožnosti klienta, musí být WebSEAL nebo jiná proxy sami autentizováni do plug-in programu. Toho se obvykle dosáhne pomocí vzájemně autentizovaného spojení SSL mezi proxy a webovým serverem, chráněným plug-in programem.
Aktivace a zablokování autentizace pomocí IV hlaviček Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete aktivovat autentizaci pomocí IV hlaviček, přiřaďte odkaz ’iv-header’ k parametru authentication; to znamená: [common-modules] authentication = iv-header
Konfigurace parametrů IV hlaviček Parametry autentizace pomocí IV hlaviček jsou nakonfigurovány ve stanze [iv-headers] konfiguračního souboru pdwebpi.conf. Parametr accept určuje typy IV hlaviček, které budou uznány během provádění autentizace pomocí IV hlaviček. Standardně plug-in program uznává všechny typy IV hlaviček. Platné volby jsou: all, iv-creds, iv-user, iv-user-l, iv-remote-address. Pokud chcete zadat více než jeden typ hlavičky, oddělte hodnoty čárkou. Například: [iv-headers] accept = iv-creds,iv-user
Použití failover cookie pro jednotné přihlášení Pokud jsou failover cookies nakonfigurovány pro zpracování následující po autorizaci, plug-in program zašifruje data pověření buď do cookie specifické pro server, nebo do cookie pro celou doménu. Cookie se uloží do prohlížeče, jakmile se klient poprvé připojí. Pokud se klient pokusí přistoupit k jinému zabezpečenému serveru v rámci domény, je cookie předložena tomu serveru, na který je klient přesměrován. Cookie se používá pro automatickou opětovnou autentizaci, takže klient je uchráněn od toho, aby úlohu opětovné autentizace provedl ručně. Plug-in programy na replikovaných serverech sdílejí společný klíč, který dešifruje informace o pověření, které jsou uloženy v cookie, a vytvářejí novou relaci. Poznámka: Zabezpečení tokenu při vytváření failover cookie bylo ve vydání 4.1 plug–in programu vylepšeno. Zlepšení nejsou schopna spolupracovat s šifrovacím schématem tokenů ve vydání 3.9 produktu Tivoli Access Manager. Chcete-li i nadále být schopni spolupracovat s produkty Tivoli Access Manager Web Security verze 3.9, nastavte konfigurační parametr pre-410-compatible-tokens ve stanze [pdweb-plugins] má hodnotu true. Tento parametr platí pro celý proces a nelze jej nastavit na úrovni virtuálního hostitele.
Kapitola 5. Řešení jednotného přihlášení pro web
127
Aktivace jednotného přihlášení pomocí failover cookies Failover cookies je možné nakonfigurovat i tak, aby prováděly autentizaci a úlohy zpracování následujícího po autorizaci. Plug-in programy nakonfigurované pro zpracování následující po autorizaci pomocí failover cookies zašifrují a uloží pověření do failover cookie v odpovědi na transakci. Plug-in programy nakonfigurované tak, aby používaly failover cookies pro autentizaci, opětovně autentizují klienty pomocí zašifrovaných pověření z failover cookies, které byly nalezeny v odpovědi na transakci. Pokud chcete aktivovat jednotné přihlášení pomocí failover cookies, přiřaďte slovo ’failover’ k parametrům authentication a post-authzn ve stanze [common-modules] konfiguračního souboru. To znamená: [common-modules] authentication = failover post-authzn = failover
Abyste získali další informace o konfigurování autentizace pomocí failover cookie, prohlédněte část “Konfigurace autentizace po přepnutí při selhání” na stránce 78.
Používání globálního jednotného přihlášení (GSO - Global single sign-on) Produkt Tivoli Access Manager Plug-in for Web Servers může být nakonfigurován tak, aby udělil uživatelům přístup k počítačovým zdrojům, které jsou tito uživatelé autorizováni používat, pomocí jednotného přihlášení. Protože bylo toto řešení navrženo pro velké společnosti, obsahující mnoho systémů a aplikací v heterogenním distribuovaném počítačovém prostředí, GSO eliminuje nutnost, aby koncoví uživatelé spravovali více jmen uživatelů a hesel. Poznámka: GSO není vhodným řešením jednotného přihlášení pro webové servery iPlanet, pokud webový server iPlanet používá stejné instance LDAP jako Tivoli Access Manager. Chcete-li vytvořit řešení GSO, musíte nejprve vytvořit pomocí rozhraní Web Portal Manager nebo obslužného programu pdadmin zdroje GSO a skupiny zdrojů GSO produktu Tivoli Access Manager. Podrobné informace o vytváření zdrojů GSO a skupin zdrojů GSO najdete v knize IBM Tivoli Access Manager Base: Administrativní příručka. Jakmile je požadavek autorizován, zavolá se modul zpracování následujícího po autorizaci pomocí Základní autentizace, aby určil, zda je pro požadovaný zdroj k dispozici pověření zdroje. Pověření zdroje je kombinace jména uživatele/hesla, která je namapována na každý zdroj a uložena v registru uživatelů. Modul zpracování následujícího po autorizaci pomocí Základní autentizace načte pověření zdroje odpovídající uživateli a požadovaný aplikační zdroj, a s pomocí načteného pověření vytvoří HTTP hlavičku Základní autentizace a tuto hlavičku Základní autentizace vloží do HTTP požadavku. Pověření zdroje je načteno z registru uživatelů pouze pro první požadavek. U následujících požadavků je pověření zdroje načteno jako informace o relaci. Níže uvedený obrázek zobrazuje, jak se používá mechanismus GSO k načtení jmen uživatelů a hesel pro aplikační zdroje typu back-end.
128
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Obrázek 6. Přístup uživatele k zabezpečeným aplikacím pomocí GSO.
1. Uživatel Michal požaduje přístup ke chráněné aplikaci webového serveru typu back-end travel-app. Produkt Tivoli Access Manager autentizuje klienta a obdrží totožnost produktu Tivoli Access Manager. Pokud je požadovaný zdroj nechráněný, požadavek je přesměrován na webový server, kde proběhne jeho zpracování. Poznámka: Proces jednotného přihlášení je nezávislý na původní metodě autentizace. 2. Plug-in program předá totožnost produktu Tivoli Access Manager serveru s registrem uživatelů (LDAP nebo URAF). Server s registrem uživatelů spravuje úplnou databázi informací o autentizaci ve formě mapování zdrojů na určité informace o autentizaci. Informace o autentizaci jsou kombinací jména uživatele / hesla, která je známá jako pověření zdroje. Pověření zdroje je možné vytvářet pouze pro registrované uživatele. Níže uvedená tabulka představuje strukturu databáze pověření zdrojů GSO: Michal
Jana
resource: travel-app username=mike password=123
resource: travel-app username=Jane password=abc
resource: payroll-app username=smith password=456
resource: payroll-app username=Jones password=xyz
3. V tomto příkladě registr vrátí plug-in programu jméno uživatele ″mike″ a heslo ″123″. 4. Plug-in program vloží informace o jméně uživatele a hesle uživatele Michal do HTTP hlavičky Základní autentizace požadavku a pošle je zpět na webový server. 5. Webový server autentizuje Michala (pro zdroje, které požaduje) na základě jeho pověření v hlavičce Základní autentizace, která byla v kroku 4 vložena do požadavku, jako kdyby ji obdržel přímo z klienta.
Kapitola 5. Řešení jednotného přihlášení pro web
129
Konfigurace GSO (Global single sign-on) Pokud chcete aktivovat funkcionalitu GSO, musíte nakonfigurovat konfigurační soubor pdwebpi.conf. Ve stanze [common-modules] uveďte do parametru post-authzn hodnotu BA tak, jako je to uvedeno níže: [common-modules] authentication = ... session = ... post-authzn = BA
Ujistěte, že parametru BA je ve stanze modules přiřazen alespoň předvolený modul. To znamená: [modules] BA = pdwpi-ba-module
Ve stanze [BA] konfiguračního souboru pdwebpi.conf je množství parametrů, které se používají ke konfiguraci modulu zpracování následujícího po autorizaci pomocí Základní autentizace. Jsou to: v basic-auth-realm v strip-hdr v add-hdr v gso-resource-name v supply-password v supply-username Musíte nakonfigurovat parametry add-hdr a gso-resource-name, abyste dosáhli řešení GSO k aplikacím typu back-end. Ostatní parametry Základní autentizace jsou podrobněji probírány v části “Konfigurace Základní autentizace” na stránce 58. Parametr add-hdr řídí přidání nové hlavičky Základní autentizace, jakmile byl požadavek autentizován. Chcete-li využívat výhod řešení GSO, nastavte tento parametr na hodnotu gso. Například: [BA:virtual_host1] ... add-hdr = gso
Nastavení parametru add-hdr na hodnotu gso znamená, že do HTTP požadavku se přidá nová hlavička Základní autentizace, a to na základě informací o zdroji, které jsou uloženy v registru uživatelů. Parametr gso-resource-name ve stanze [BA] konfiguračního souboru určuje jméno zdroje webového serveru, který má mít povoleno řešení GSO. Toto jméno je možné uvést na úrovni jednotlivých virtuálních hostitelů. Pověření zdroje uložené v registru uživatelů je namapováno na každý zdroj uložený v registru uživatelů. Parametr gso-resource-name nastavte na jméno zdroje produktu Tivoli Access Manager, který bude používat řešení GSO. Například: [BA:virtual_host1] ... gso-resource-name = payroll-app
Pro každého virtuálního hostitele je možné uvést pouze jedno jméno zdroje GSO. Pokud v parametru gso-resource-name není uvedena žádná hodnota, pak se jako jméno zdroje GSO použije jméno virtuálního hostitele. Poznámka: Pokud sdílíte registr LDAP mezi webovým serverem Sun ONE (dříve iPlanet) a produktem Tivoli Access Manager, nemůžete vytvořit pověření zdroje GSO v rámci produktu Tivoli Access Manager s cílovými jmény uživatelů stejnými,
130
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
která by se měla použít při autentizaci na Sun ONE Web Server. Tato situace nastala proto, že Sun ONE Web Server nemůže omezit vyhledávací kritéria LDAP při autentizaci uživatelů tak, aby se vyhledávaly pouze objekty správné třídy objektů LDAP.
Jednotné přihlášení pomocí SPNEGO (Security Provider NEGOtiation) Používání SPNEGO jako mechanismu autentizace v rámci plug-in programu nabízí možnost jednotného přihlášení, které dovoluje uživatelům přistupovat ke zdrojům na zabezpečeném webovém serveru IIS z klientů na platformě Windows, aniž by se museli autentizovat jinak, než prvním přihlášením do domény. Podrobnosti o práci a konfiguraci jednotného přihlášení pomocí SPNEGO jsou uvedeny v části “Konfigurace autentizace pomocí SPNEGO” na stránce 69
Jednotné přihlášení pomocí formulářů Autentizace jednotného přihlášení pomocí formulářů umožňuje produktu Access Manager Plug-in for Web Servers transparentně protokolovat autentizovaného uživatele produktu Tivoli Access Manager do webového serveru zabezpečeného plug-in programem, který požaduje autentizaci pomocí formuláře HTML. Autentizace jednotného přihlášení pomocí formulářů podporuje existující aplikace, které k autentizaci používají formuláře HTML a nemohou být modifikovány, aby přímo důvěřovaly autentizaci provedené plug-in programem. Jednotné přihlášení založené na formulářích plug-in programu poskytuje rychlé řešení integrace (na které by mělo být nahlíženo jako na prozatimní), které se použije, když je pro autentizaci rozvinuta důvěryhodnější a výkonější metoda. Aktivace autentizace jednotného přihlášení pomocí formulářů má následující důsledky: v plug-in program přerušuje proces autentizace zavedený back-end aplikací v plug-in program dodává data požadovaná formulářem pro přihlášení a zadává ho ve prospěch uživatele v uživatel neví, že se probíhá druhé přihlášení v back-end aplikace neví, že formulář pro přihlášení nepřichází přímo od uživatele Plug-in program musí být nakonfigurován, aby: v rozeznal a zachytil formulář pro přihlášení v vložil odpovídající data autentizace Administrátor aktivuje jednotné přihlášení pomocí formulářů nakonfigurováním, jak je formulář pro přihlášení rozeznán, dokončen a zpracován.
Průběh procesu jednotného přihlášení pomocí formulářů Následující scénář předpokládá, že plug-in program již autentizoval uživatele.
Kapitola 5. Řešení jednotného přihlášení pro web
131
Obrázek 7. Průběh procesu jednotného přihlášení pomocí formulářů.
1. Uživatel požaduje na chráněném virtuálním hostiteli zdroj. 2. Plug-in program odesílá požadavek back-end aplikaci. 3. Protože back-end aplikace vyžaduje autentizaci uživatele, je přesměrování do stránky přihlášení aplikace odesíláno zpátky do plug-in programu. 4. Plug-in program odesílá přesměrování prohledávacímu programu. 5. Prohledávací program následuje přesměrování a požaduje stránku přihlášení. Poznámka: Vše do tohoto bodu průběhu procesu je standardní funkcionalita plug-in programu 6. Plug-in program byl nakonfigurován na jednotné přihlášení pomocí formulářů.FSSO modul plug-in programu rozeznává požadavek jako požadavek pro stránku přihlášení, na základě informace obsažené v konfiguračním souboru plug-in programu. Požadavek je odeslán aplikaci. 7. Aplikace vrací stránku přihlášení a možné cookies specifické pro aplikaci. 8. Plug-in zadržuje odpověď a analyzuje HTML vrácený k identifikaci formuláře pro přihlášení. Když plug-in vyhledá HTML formulář v dokumentu, porovnává URI akce ve formuláři s hodnotou parametru login-form-action z konfiguračního souboru plug-in programu. Pokud nalezne shodu, použije nalezený formulář, jinak pokračuje v hledání jiných formulářů. Pokud žádný formulář ve stránce neodpovídá vzoru URI akce z konfiguračního souboru, tak ruší zpracování jednotného přihlášení pomocí formulářů a odesílá zpět prohlížecímu programu nezměněnou odpověď.
132
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
9. 10.
11. 12.
Pokud není formulář pro přihlášení nalezen, analyzuje plug-in program HTML formulář v dokumentu, aby identifikoval metodu požadavku, URI akce a další vstupní pole ve formuláři a ukládá je pro použití v kroku 10. Poté odesílá prohledávacímu programu přesměrování do URI akce formuláře pro přihlášení s jedinečným identifikátorem požadavku přidaným jako dotaz. V přesměrování jsou také zahrnuty libovolné cookies specifické pro aplikaci. Prohledávací program následuje přesměrování a požaduje URI akce. Plug-in program rozeznává příchozí požadavek pomocí jeho jedinečného datazového řetězce a generuje požadavek na autentizaci pomocí pravidel ze stanzy atributu a dat uložených v kroku 8. Dokončený formulář pro přihlášení (požadavek na autentizaci) je poté odeslán back-end aplikaci. Aplikace poskytuje autentizaci pomocí dat autentizace poskytnutých plug-in programem ve formuláři. Aplikace vrací přesměrování původně požadovanému zdroji. Plug-in vrací přesměrování prohledávacímu programu.
Poznámka: To dokončuje funkcionalitu specifickou pro SSO pomocí formulářů. 13. Prohledávací program následuje přesměrování a požaduje zdroj. 14. Plug-in program odesílá požadavek zabezpečenému zdroji. Během tohoto procesu vytváří prohledávací program pro plug-in program čtyři požadavky. Z pohledu uživatele je pro zdroj vytvořen pouze jediný požadavek. Další požadavky se objeví automaticky přes přesměrování HTTP.
Požadavky pro podporu aplikace Jednotné přihlášení pro autentizaci pomocí formulářů je podporováno pro aplikace, které splňují následující požadavky: 1. Stránka nebo stránky přihlášení pro aplikaci musí být jedinečně označitelné pomocí jediného regulárního výrazu nebo několika regulárních výrazů. 2. Stránka přihlášení může zahrnovat více jak jeden formulář HTML. Avšak formulář pro přihlášení musí být označený aplikováním regulárního výrazu pro URI akce každého formuláře pro přihlášení, nebo je formulář pro přihlášení prvním formulářem ve stránce přihlášení. Všimněte si, že když k označení formuláře pro přihlášení používáte atribut ″action″, neprošel tento atribut přes HTML filtrování plug-in programu. Regulární výraz by měl před filtrováním odpovídat URI akce. 3. Tvoření skriptů ze strany klienta se může použít k potvrzení vstupních dat, ale nesmí je upravovat. To znemožňuje, aby podpora pro webové stránky pomocí Javascript dynamicky vytvořila formuláře přihlášení, nebo aby nastavila cookies v prohledávacím programu uživatele. 4. Data přihlášení jsou zadána pouze v jednom bodě procesu autentizace. 5. URI přihlášení, které se má zadržet v kroku 8 v předcházející sekci, musí být zpracováno základním webovým serverem jako jediný požadavek. Scénáře PHP, se kterými se například v Apache zachází jako s vnějšími příkazy, oddělují vícenásobný podpožadavek a nemohou se zadržet.
Aktivace jednotného přihlášení pomocí formulářů Modul FSSO obsluhuje proces jednotného přihlášení pomocí formulářů. Modul musí být zavolán po autorizaci požadavku a před tím, než webový server odpoví na požadavek. Modul FSSO proto musí být nakonfigurován jako modul post-authzn a jako modul response. Tyto moduly jsou uvedeny ve stanza [common-modules] v konfiguračním souboru pdwebpi.conf. To znamená:
Kapitola 5. Řešení jednotného přihlášení pro web
133
[common-modules] ... response = fsso
Modul response se použije k zachycení formuláře pro přihlášení prezentovaného webovým serverem, který tak může být zpracován. Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Zajistěte, že záznam pro fsso existuje: [modules] fsso = pdwpi-fsso-module
Protože hlavní rolí plug-in programu je chránit webové zdroje od neautorizovaného přístupu, musí autorizovat všechny požadavky pro zdroje, i když jsou částí procesu jednotného přihlášení na základě formulářů. Než povolí přístup ke stránce přihlášení back-end aplikace kontroluje plug-in program databázi ACL a také provádí kontrolu předtím, než povolí přístup k URI uvedenému v akci formuláře (kam je odesílán dokončený formulář pro přihlášení). Pokud bezpečnostní politika neposkytuje aktuálnímu uživateli povolení pro přístup k těmto stránkám, tak jednotné přihlášení na základě formulářů selže.
Konfigurace jednotného přihlášení pomocí formulářů Informace o konfiguraci jednotného přihlášení pomocí formulářů je umístěna v konfiguračním souboru pdwebpi.conf pod stanzou [fsso] nebo [fsso:virtual-host]. Stanza obsahuje jeden nebo více záznamů login-page-stanza ukazujících na jiné přizpůsobeně pojmenované stanzy, které obsahují informaci o konfiguraci pro stránky přihlášení nalezené v back-end aplikaci. Schopnost podporovat vícenásobné stránky přihlášení je důležitá, protože server může hostit několik aplikací používající každá jinou metodu autentizace. Například: [fsso] login-page-stanza = login-from-1 login-page-stanza = login-form-2
Stanza přizpůsobené stránky přihlášení Každá stanza přizpůsobené stránky přihlášení se použije k zadržení vzoru partikulárního URL. Stanza může obsahovat následující parametry:
134
Parametr
Popis
login-page
Uvádí vzor používající regulární výraz, který jedinečně označuje požadavky pro stránku přihlášení aplikace. Konfigurovaný vzor je porovnáván s URI požadavku.
login-form-action
Uvádí vzor používající regulární výraz, který označuje, který formulář obsažený v zadržené stránce je formulář přihlášení aplikace. Pokud vícenásobné formuláře odpovídají vzoru, tak se použije ten první.
argument-stanza
Ukazuje na jinou předvolenou stanzu, která zobrazuje seznam polí a data vyžadovaná k dokončení formuláře přihlášení.
gso-resource
Tento parametr podporuje jméno zdroje produktu Tivoli Access Manager, který bude používat řešení GSO. Pro každou přizpůsobenou stránku přihlášení stanzy je možné uvést pouze jedno jméno zdroje GSO. Pokud v parametru gso-resource není uvedena žádná hodnota, pak se jako jméno zdroje GSO použije jméno virtuálního hostitele.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Například: [login-form-1] login-page = /cgi-bin/getloginpage* login-form-action = * argument-stanza = form1-data gso-resource = payroll-app
O parametru login-page: Hodnota parametru login-page je regulérní výraz, který plug-in program používá k určení, zda je příchozí požadavek požadavkem pro stránku přihlášení. V tom případě je požadavek plug-in programem zadržen a začíná zpracování jednotného přihlášení pomocí formulářů. V každé stanze přizpůsobené stránky přihlášení je povolen pouze jeden parametr login-page. Pro každý další parametr login-page musíte vytvořit další stanzu přizpůsobené stránky přihlášení. Regulární výraz login-page je porovnáván s URI požadavku. V následujícím příkladě by se mělo objevit URI požadavku pro chráněného virtuálního hostitele nazvaného myserver1: https://myserver1.mycompany.com/auth/login.html
Část tohoto URI, ketrá je porovnávána s regulárním výrazem login-page, je: /auth/login.html
O parametru login-form-action: Parametr login-form-action se použije k označení formuláře pro přihlášení na stránce vrácené back-end serverem následující požadavek odpovídající parametru login-page. V každé stanze je povolen pouze jeden parametr login-form-action. Hodnota parametru login-form-action je regulární výraz, ketrý je porovnáván s obsahem atributu action= HTML příznaku form. Atribut action je URI vyjádřené jako relativní, serverově relativní nebo absolutní cesta. Parametr login-form-action musí odpovídat této cestě, jak přichází z back-end serveru - i když může být před vrácením klientovi plug-in programem normálně změněna. Pokud vícenásobné atributy action na stránce odpovídají regulárnímu výrazu, je jako formulář pro přihlášení přijat pouze první. Pokud regulární výraz login-form-action neodpovídá žádnému formuláři na stránce, je prohlížecímu programu vrácena chyba ohlašující, že formulář nejde nalézt. Když stránka obsahuje pouze jeden formulář pro přihlášení, můžete nastavit login-form-action = * jako jednoduchou cestu k porovnání formuláře pro přihlášení. Použití regulárních výrazů: Speciální znaky povolené v regulárních výrazech použitých v konfiguraci jednotného přihlášení pomocí formulářů jsou definovány v částiDodatek E, “Speciální znaky dovolené v běžných výrazech”, na stránce 211. Ve většině případů nejsou speciální znaky vyžadovány, protože je požadavek na stránku přihlášení jednoduše označitelné URI. V některých případech můžete na konci výrazu použít ″*″, takže žádná data dotazu na konci URI nechrání stránku přihlášení od porovnávání. Stanza argumentu: Přizpůsobená stanza argumentu obsahuje jeden nebo více záznamů v následujícím formátu: name = method:value
Kapitola 5. Řešení jednotného přihlášení pro web
135
name Hodnota parametru name je nastavena, aby vyrovnávala hodnotu atributu name HTML příznaku input. Například: Username
Tento parametr může také používat hodnotu atributu name HTML příznaků select nebo textarea. method:value Tato kombinace parametrů načítá data autentizace požadovaná formulářem. Data autentizace zahrnují: v Data literárního řetězce string:text
Použitý vstup je textový řetězec. v Jméno uživatele GSO a heslo gso:username gso:password
Vstupem je aktuální jméno uživatele GSO a jeho heslo (z cíle gso-resource uvedeného ve stanze přizpůsobvené stránky přihlášení). v Hodnota atributu v pověření uživatele cred:cred-ext-attr-name
Standardně obsahuje pověření informaci, jako je jméno uživatele a DN uživatele produktu Tivoli Access Manager. Abyste použili jméno uživatele produktu Tivoli Access Manager jako vstupní hodnotu, zadejte hodnotu jako: cred:azn_cred_principal_name
DN uživatele může být přistoupeno jako: cred:azn_cred_authzn_id
Mohou se také použít atributy přizpůsobeného pověření (přidané pomocí mechanismu příznak/hodnota). V této stanze se nemusí uvést pole skrytého vstupu. Tato pole jsou automaticky načtena z formuláře HTML a zadána s požadavkem na autentizaci. Například: [form1-data] uid = string:brian
Poznámky: 1. Plug-in program neprovádí kód scénáře (Javascript, AxcitveX, atd.) předtím, než je zadán formulář, což může způsobit problémy, pokud je pro proces přihlášování požadován kód. Problémy se nevyskytnou, pokud tento kód jednoduše kontroluje vstup před zadáním, ale mohou se vyskytnout, pokud kód upravuje vstup uživatele. 2. I když SSO na základě formulářů může použít informaci v databázi GSO, neslučuje se schopností GSO poskytnutou modulem BA. Pokud je požadováno, je možné používat jeden cíl GSO pro vložení hlaviček Základní autentizace odeslaných back-end serveru a jiný uvedený v konfiguraci SSO na základě formulářů používat pro vložení formulářů pro přihlášení.
136
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Příklad konfiguračního souboru pro IBM HelpNow Server IBM HelpNow vyvolává své vlastní přihlášení založené na formulářích a je proto příkladem, jak může řešení jednotného přihlášení pomocí formulářů poskytnout zapsaným uživatelů serveru bezespárový přístup. Tato sekce obsahuje následující témata: v Sekce formuláře stejná s formulářem odeslaným na stránce HTML přihlášení vrácené aplikací HelpNow v Konfigurační soubor přizpůsobeného jednotného přihlášení pomocí formulářů použitý ke zpracování tohoto formuláře Formulář nalezený v zadržené HTML stránce:
Přizpůsobený konfigurační soubor použitý ke zpracování tohot formuláře: konfigurace helpnow FSSO: [forms-sso-login-pages] login-page-stanza = helpnow [helpnow] # Server HelpNow vás přesměrovává do této stránky # musíte se protokolovat. login-page = /bluebase/bin/files/wcls_hnb_welcomePage1.cgi # Formulář přihlášení je první na stránce, takže ho můžeme pouze zavolat # ’*’. login-form-action = * # Zdroj GSO, helpnow, obsahuje sériové číslo zaměstnance. gso-resource = helpnow # Následují parametry autentizace. argument-stanza = auth-data [auth-data] # Pole ’data’ obsahuje sériové číslo zaměstnance. data = gso:username # Pole Cntselect obsahuje číslo odpovídající tomu, které má # země původu zaměstnance. Řetězec "897" odpovídá USA. Cntselect = string:897
Kapitola 5. Řešení jednotného přihlášení pro web
137
138
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Kapitola 6. Řešení přihlášení napříč doménou Je-li produkt Tivoli Access Manager Plug-in for Web Servers naimplementován tak, aby poskytoval ochranu zabezpečené doméně, často se objevuje ještě požadavek, aby byl současně řešením pro jednotné přihlášení ke zdrojům. Tato kapitola pojednává o dvou metodách dosažení jednotného přihlášení přes různé domény chráněné plug-in programem; jednotné přihlášení pomocí e-Community a služba CDSSO (cross domain single sign-on). Obě řešení používají k odeslání informace o autentizaci uživatele mezi různými doménami ověřený token. Jaké řešení si zvolíte, závisí na požadované flexibilitě. Jednotné přihlášení pomocí e-Community používá centrální server, který koordinuje proces jednotného přihlášení mezi různými doménami. S CDSSO neexistuje žádný centrální server autentizace a žádné automatizované přesměrování poskytující větší flexibilitu. Jsou zahrnuta následující témata: v “Cross domain single sign-on (služba CDSSO)” v “Jednotné přihlášení pomocí e-Community” na stránce 144
Cross domain single sign-on (služba CDSSO) CDSSO (Cross-Domain Single Sign-on) produktu Tivoli Access Manager poskytuje mechanismus pro přenos pověření uživatele přes vícenásobné zabezpečené domény. CDSSO podporuje povolením integrace vícenásobných zabezpečených domén cíle stavitelné architektury sítě. Velký společný extranet může být například nastaven dvěma nebo více jedinečnými doménami—každou s jejími vlastními uživateli a prostorem objektů. CDSSO dovoluje pohyb uživatelů mezi doménami pomocí jednotného přihlášení. Mechanismus autentizace CDSSO nespoléhá na Master Authentication Server jako “Jednotné přihlášení pomocí e-Community” na stránce 144. Když s CDSSO dává uživatel požadavek zdroji umístěnému v jiné doméně, přemisťuje mechanismus CDSSO token identity zašifrovaného uživatele z první domény do druhé. Druhá doména má nyní identitu uživatele (jak byl autentizován v první doméně) a uživatel není nucen provést další protokolování. Domény CDSSO jsou založeny na doménách DNS. Všechny servery v doméně DNS sdílejí stejný symetrický klíč. Abyste provedli CDSSO se servery v jiné doméně DNS (která může a nemusí být v jiné doméně produktu Tivoli Access Manager), je potřeba jiný klíč.
Průběh procesu autentizace pro CDSSO Průběh procesu pro CDSSO je popsán v níže uvedeném diagramu a textu. Libovolný uživatel, který se chce účastnit ve vícenásobných doménách, musí mít v primární doméně platný účet uživatele, v tomto případě doména A, a identitu, která může být mapována v platném účtu v každé zúčastněné vzdálené doméně. Uživatel nemůže vyvolat funkcionalitu CDSSO, aniž by byl na začátku autentizován pro výchozí zabezpečenou doménu (A) obsahující jeho účet.
© Copyright IBM Corp. 2000, 2003
139
Obrázek 8. Průběh procesu pro CDSSO.
1. Uživatel dává požadavek pro přístup ke zdroji v doméně B pomocí přizpůsobeného odkazu na webové stránce domény A. 2. Odkaz obsahuje výraz speciálního CDSSO uvedeného parametrem uri ve stanze [cdsso] konfiguračního souboru pdwpi.conf. Předvolená hodnota je pkmscdsso: /pkmscdsso?destination-URL
Například: /pkmscdsso?https://www.domainB.com/index.html
Požadavek je nejprve zpracován serverem plug-in programu v doméně A. Plug-in program vytváří token autentizace obsahující identitu uživatele produktu Tivoli Access Manager (krátké jméno), aktuální doménu (″A″), další informace o uživateli a časové označení. Další informace o uživateli (rozšířené atributy) jsou obdrženy zavoláním sdílené knihovny přizpůsobeného CDMF (cdmf_get_usr_attributes). Tato knihovna má schopnost dodat atributy uživatele, které mohou být použity doménou B během procesu mapování uživatele. Trojité DES plug-in programu zašifruje tato data tokenu pomocí symetrického klíče vygenerovaného obslužným programem cdsso_key_gen. Tento soubor klíčů je sdílen a uložen ve stanze [cdsso-domain-keys] konfiguračního souboru pdwebpi.conf jak na webovém serveru rozšířeném o plug-in program domény A tak domény B. Token obsahuje konfigurovatelné časové označení (authtoken-lifetime) definující dobu trvání tokenu. Když je časové označení řádně nakonfigurováno, může předcházet napadení přenosu. 3. Server plug-in programu domény A přesměrovává požadavek plus zašifrovaný token zpět do prohledávacího programu a pak do serveru plug-in programu domény B (přesměrování HTTP). 4. Server plug-in programu domény B používá verzi stejného souboru klíčů k dešifrování a potvrzení tokenu jako je příchozí z odkazující domény. Server plug-in programu domény B nyní volá do knihovny mechanismu autentizace pomocí CDSSO. Tato knihovna CDSSO volá do knihovny přizpůsobeného CDMF, která provádí mapování aktuálního uživatele (cdmf_map_usr). Knihovna CDMF posílá identitu uživatele a informaci o dalších atributech zpět do knihovny CDSSO. Knihovna CDSSO používá tuto informaci k vytvoření pověření.
140
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
5. Služba autorizace domény B povoluje nebo zakazuje přístup ke chráněným objektům na základě pověření uživatele a povolení specifického ACL přidruženého k požadovaným objektům.
Aktivace a zablokování autentizace pomocí CDSSO Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Abyste aktivovali autentizaci pomocí CDSSO, přiřaďte do parametru autentizace výraz cdsso: [common-modules] authentication = cdsso
Když používáte autentizaci pomocí CDSSO, plug-in program musí být nakonfigurován tak, aby používal také CDSSO pro zpracování následující po autorizaci. Ve stanze [common-modules] konfiguračního souboru pdwebpi.conf přidejte parametr post-authzn následujícím způsobem: [common-modules] authentication = cdsso post-authzn = cdsso
Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že je zde uveden záznam pro autentizaci pomocí formulářů: [modules] cdsso = pdwpi-cdsso-module
Zašifrování dat tokenu autentizace Plug-in program musí zašifrovat autentizační data, která jsou umístěna v tokenu, pomocí klíče, který byl vygenerován obslužným programem cdsso_key_gen. Tento klíč musíte ″synchronizovat″ jeho sdílením s každým webovým serverem rozšířeným o plug-in program v každé z účastnících se domén. Každý účastnící se plug-in server v každé z domén musí používat stejný klíč. Poznámka: Vytvoření a distribuce souborů klíčů není součástí procesu CDSSO produktu Tivoli Access Manager. Obslužný program cdsso_key_gen při svém spuštění vyžaduje, abyste zadali umístění (absolutní cestu) souboru klíčů: UNIX: # cdsso_key_gen absolute-pathname Windows: MSDOS> cdsso_key_gen absolute-pathname Zadejte umístění tohoto souobru klíčů ve stanze [cdsso-domain-keys] konfiguračního souboru pdwebpi.conf účastnícího se serveru plug-in programu v každé doméně. Stanza[cdsso-domain-keys] odvozuje své jméno ze jména pdwpi-cdsso-module definovaného ve stanze [modules]. Má formát [cdsso-module-name-domain-keys]. Klíče domény mohou být uvedeny na bázích po jednotlivých virtuálních hostitelích vytvořením stanzy [cdsso-module-name-domain-keys:virtual-host-name]. Formát záznamu zahrnuje jméno domény a umístění souboru klíčů: [cdsso-domain-keys] jméno-domény = umístění-souboru-klíčů
Příklad konfigurace domény A: [cdsso-domain-keys] www.domainB.com = pathname/A-B.key Kapitola 6. Řešení přihlášení napříč doménou
141
Příklad konfigurace domény B: [cdsso-domaina-keys] www.domainA.com = pathname/A-B.key
Ve výše uvedeném příkladě může být soubor A-B.key vygenerován na jednom počítači (například Plug-in program A) a manuálně (a bezpečně) zkopírován do jiného počítače (například Plug-in program B).
Konfigurace časového označení tokenu Token obsahuje konfigurovatelné časové označení definující dobu trvání tokenu. Jakmile časové označení vyprší, je token považován za neplatný a není použit. Časové označení se používá, aby pomohlo předcházet napadení přenosu nastavením hodnoty dostatečně krátké, aby předešla odcizení a přenesení tokenu v době jeho trvání. Parametr authtoken-lifetime ve stanze [cdsso] konfiguračního souboru pdwebpi.conf nastavuje hodnotu doby trvání tokenu.Hodnota je vyjádřena ve vteřinách. Předvolená hodnota je 180: [cdsso] authtoken-lifetime =180
Tato hodnota může být přepsána na bázích po jednotlivých virtuálních hostitelích. Musíte vzít v úvahu časový posuv mezi účastnícími se doménami.
Zahrnutí atributů pověření v tokenech autentizace Atributy pověření můžete zahrnout v tokenech CDSSO jejich uvedením ve stanze [cdsso-token-attributes] konfiguračního souboru plug-in programu. Atributy, které se mají zahrnout mohou být uvedeny na bázích peer-to-peer nebo na bázích po jednotlivých doménách. Atributy pověření vypsané v této stanze jsou relevantní pouze, pokud se používají předvolené SSO knihovny vytvoření a použití tokenu. Pokud ve vouch-for tokenech CDSSO nevyžadujete atributy pověření, tak můžete nechat tuto stanzu prázdnou. Předvolené jméno této stanzy je odvozeno od jména modulu pro pdwpi-ecsso-module, nadefinovaného ve stanze [modules]. Je ve tvaru [jméno-modulu-ecsso-atributy-tokenu]. Hodnoty ve stanze [cdsso-token-attributes] jsou standardní pro všechny virtuální hostitele a mohou být přepsány na bázích po jednotlivých virtuálních hostitelích vytvořením stanzy [jméno-modulu-cdsso-atributy-tokenu:virtuální-hostitel]. Formát záznamů je: jméno-domény = vzor1, vzor2, ... vzor n. Atributy pověření odpovídající uvedeným vzorům pro cílového hostitele nebo doménu jsou zahrnuty ve vouch-for tokenech CDSSO vytvořených pro tohoto hostitele nebo doménu. Pro každý atribut se použije pouze jedna hodnota a jsou podporovány pouze hodnoty řetězce. Ostatní typy hodnot atributů pověření jsou ignorovány. Vzory mohou být uvedeny pomocí znaků odpovídajících vzoru vysvětlených v části Dodatek E, “Speciální znaky dovolené v běžných výrazech”, na stránce 211. Například: [cdsso-token-attributes] ibm.com = attrprefix_*, *name* tivoli.com = *_attrsuffix, některý-přesný-atribut
142
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Předvolené nastavení atributů může být nakonfigurováno pomocí záznamu <default> v této stanze. Předvolené nastavení atributů se použije, když neexistuje žádný další záznam odpovídající partikulárnímu cílovému hostiteli. Když není přítomen záznam <default>, nebudou předvolbou zahrnuty žádné atributy.
Přijetí a zamítnutí atributů pověření z tokenů autentizace pomocí CDSSO Uvedením hodnot ve stanze [cdsso-incoming-attributes] můžete uvést atributy pověření, které se mají z příchozích tokenů autentizace pomocí CDSSO přijmout a ty, které se mají zamítnout. Narozdíl od konfigurace odchozích atributů, nemohou být příchozí atributy nakonfigurovány na bázích per-peer a na bázích po jednotlivých doménách. Může být nakonfigurována pouze jedna sada vzorů atributů a tyto vzory se použijí pro příchozí tokeny bez ohledu na zdroj. Toto zpracování se provede pouze, pokud se používají předvolené SSO knihovny vytvoření a použití tokenu. Předvolené jméno této stanzy je odvozeno od jména modulu pro pdwpi-ecsso-module, nadefinovaného ve stanze [modules]. Je ve tvaru [jméno-modulu-cdsso-příchozí-atributy].Hodnoty v této stanze jsou standardní pro všechny virtuální hostitele. Avšak mohou být přepsány na bázích po jednotlivých virtuálních hostitelích vytvořením stanzy [jméno-modulu-cdsso-příchozí-atributy:virtuální-hostitel]. Formát záznamů v této stanze je: vzor-atributu = preserve|refresh
Atributy v tokenech CDSSO odpovídající záznamu refresh jsou z tokenu odstraněny před tím, než je knihovna CDMF volána na mapování vzdáleného uživatele v lokální doméně. Atributy neodpovídající záznamu preserve nebo neodpovídající žádnému záznamu jsou zadrženy. Pokud nejsou nakonfigurovány žádné záznamy, jsou zadrženy všechny atributy.
Uvedení knihoven sso-create a sso-consume Abyste uvedli knihovny sso-create a sso-consume, editujte konfigurační soubor plug-in programu. Ve stanze [authentication-mechanisms] nekomentujte záznam pro sso-create a sso-consume a přidejte jméno knihovny failover cookie plug-in programu odpovídající typu operačního systému. Standardní záznam konfiguračního souboru je: [authentication-mechanisms] sso-create = /opt/pdwebrte/lib/ibssocreate.so sso-consume = /opt/pdwebrte/lib/libssoconsume.so
Když jste rozvinuli knihovnu CDAS implementující přizpůsobenou verzi funkcionality sso-create a sso-consume, vložte alternativně jako hodnotu pro klíčové slovo konfiguračního souboru jméno přizpůsobené CDAS. Pokud jste například rozvinuli přizpůsobenou CDAS pro sso-create, zadejte absolutní název cesty: [authentication-mechanisms] sso-create = /dir_name/custom_cdas_sso-create.so
Vysvětlení odkazů CDSSO Odkazy ke zdrojům na sekundárně zabezpečené doméně musí obsahovat výraz speciálního CDSSO, který je nakonfigurován pomocí parametru uri ve stanze [cdsso] konfiguračního souboru. Předvolená hodnota je /pkmscdsso: /pkmscdsso?destinationURL
Když je nakonfigurován jako po-autorizační modul, přesměrují požadavky do /pkmscdsso?remote-uri klienta do remore-uri?PD-REFERER=thishost&argument=authentication-token
Kapitola 6. Řešení přihlášení napříč doménou
143
Jméno parametru řetězce dotazu uvádějícího token autentizace je nakonfigurováno parametrem cdsso-argument ve stanze [cdsso] konfiguračního souboru pdwebpi.conf. Předvolená hodnota je PD-ID. Tato hodnota může být přepsána na bázích po jednotlivých virtuálních hostitelích. Předvolená hodnota PD-ID parametru cdsso-argument by měla být změněna pouze, když se používá knihovna vytvoření/použití přizpůsobeného SSO. Když se používají knihovny vytvoření/použití zaslaného SSO, musí se použít předvolené PD-ID.
Ochrana tokenu autentizace Token autentizace neobsahuje informaci o autentizaci (jako je jméno uživatele a heslo), ale obsahuje identitu uživatele, která je v přijímající doméně ověřena. Token sám musí být tedy chráněn před odcizením a přehráním. Token je proti odcizení mimo vedení chráněn použitím SSL pro zabezpečené komunikace mezi webovými servery rozšířenými o plug-in program a uživatele. Token může být pochopitelně odcizen z historie prohledávacího programu. Časové označení tokenu by mělo být tak krátké, aby zamezilo možnosti jeho odcizení a přehrání během jeho doby trvání. Avšak token, který vypršel s ohledem na své časové označení je stále zranitelný kryptografickými útoky. Pokud je objeven klíč použitý k zašifrování tokenu, nebo je jinak ohrožen, atakující uživatelé si mohou vytvořit své vlastní tokeny. Tyto tokeny mohou být poté vloženy do ″pseudo-CDSSO flow″. Mohou být nerozlišitelné od reálných tokenů autentizace do serverů plug-in programu účastnících se v doméně CDSSO. Z tohoto důvodu musí být klíče použité k ochraně tokenů spravovány opatrně a musí být měněny na regulárních bázích.
Jednotné přihlášení pomocí e-Community Funkcionalita jednotného přihlášení produktu Tivoli Access Manager Plug-in for Web Servers pomocí e-community umožňuje uživatelům přistupovat ke zdrojům na více serverech ve více doménách, aniž by byla na těchto uživatelích požadována opětovná autentizace. ″e-community″ je skupina zvláštních domén (Tivoli Access Manager nebo DNS), které se podílejí na obchodním vztahu. Tyto účastnící se domény je možné nakonfigurovat jako součást jednoho obchodu (a pravděpodobně z geografických důvodů pomocí odlišných jmen DNS), nebo jako různé obchody se sdíleným vztahem (například ústředí firmy, životní pojišťovna a společnost pro řízení financí). V obou scénářích je zde vždy jedna doména, která je označena jako ″domovská″ nebo ″vlastnická″ doména. V případě podílejících se obchodů domovská doména vlastní obchodní smlouvy, které určují e-community. V obou scénářích jsou informace o autentizaci uživatelů, kteří se podílejí na e-community (včetně jmen uživatelů a hesel používaných pro autentizace), udržovány v domovské doméně. Toto uspořádání umožní zavedení jediného referenčního bodu pro úlohy administrativy, jako např. volání na helpdesk v rámci e-community, které se všechny vztahují k domovské doméně. Chcete-li, aby podílející se domény měly odpovědnost za administrativu vlastních uživatelů, můžete také použít rozhraní Web Portal Manager produktu Tivoli Access Manager k delegaci správy těchto informací.
144
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Domovská doména ″vlastní″ uživatele – to znamená, že řídí informace o autentizaci uživatelů. Bez ohledu na to, kde uživatel vydal požadavek na zdroje, musí se tento uživatel autentizovat v domovské doméně. Autentizace se provádí vzhledem k hlavnímu autentizačnímu serveru (MAS - master authentication server) – serveru (nebo sadě replikovaných serverů), který je umístěn v domovské doméně a který je nakonfigurován tak, aby prováděl autentizaci všech uživatelů. Úkoly MAS serveru by měly být vyhrazeny pro poskytování služeb pro autentizace. MAS server by neměl obsahovat zdroje, které jsou uživatelům k dispozici. Jakmile je uživatel úspěšně autentizován MAS serverem, MAS server vytvoří ″vouch for″ token. Tento token se předá zpět serveru, na kterém uživatel podal požadavek. Server považuje tento ″vouch for″ token za potvrzení, že uživatel byl úspěšně autentizován na MAS server a může se tedy zapojit do e-community. Přenos informací mezi doménami e-community je podrobně popsán v části “Průběh procesu jednotného přihlášení pomocí e-community”.
Funkce a požadavky jednotného přihlášení pomocí e-Community Jednotné přihlášení pomocí e-Community má následující funkce a požadavky: v Funkcionalita e-community podporuje přístup ke zdrojům přes přímá URL (záložky). v Implementace e-community vyžaduje konzistentní konfiguraci všech plug-in programů ve všech doménách, podílejících se na e-community. v Všichni uživatelé, kteří jsou zapojeni do e-community, se autentizují vzhledem k jednomu MAS (master authentication server) serveru, který je umístěn v domovské doméně. v Implementace e-community umožňuje ″lokální″ autentizaci ve vzdálených doménách, pokud uživatel nemá na MAS serveru platný účet. Uživateli, kterému se nepodaří autentizovat se na MAS serveru a který požaduje zdroj v doméně, která neobsahuje MAS server (ale podílí se na e-community), je dána možnost autentizovat se na lokálním serveru, na kterém byl vytvořen daný požadavek. v MAS server (a eventuálně také další vybrané servery ve vzdálené doméně) ″ručí za″ (″vouch for″) autentizovanou totožnost uživatele. v Cookies specifické pro danou doménu se používají k identifikaci serveru, který poskytuje ″vouch for″ služby. Tak je umožněno serverům ve vzdálené doméně, aby požádaly lokálně o ″ručící - vouch for″ informace. Zašifrovaný obsah e-community cookies neobsahuje totožnost uživatele nebo informace o zabezpečení. v Pro předání zašifrovaných ″zaručených - vouched for″ totožností uživatele se používají speciální tokeny. ″Vouch for″ token neobsahuje skutečné informace o totožnosti uživatele. Integrita dat je zajištěna sdíleným tajným klíčem (triple-DES). Token obsahuje hodnotu časového limitu (dobu trvání), která omezuje dobu platnosti tokenu. v Implementace e-community je podporována jak HTTP, tak i HTTPS. v Konfigurace e-community je pro každý podílející se plug-in program nastavena v souboru pdwebpi.conf.
Průběh procesu jednotného přihlášení pomocí e-community E-community se skládá z hlavního autentizačního serveru (MAS - Master Authentication Server) rozšířeného o plug-in program a dalších serverů rozšířených o plug-in program. Všechny tyto servery vystupují jako e-community. Řešení jednotného přihlášení pomocí e-community může také pracovat se zdroji chráněnými serverem WebSEAL.
Kapitola 6. Řešení přihlášení napříč doménou
145
Implementace e-community je založena na systému ″ručení - vouch for″. Obvykle když neautentizovaný uživatel požaduje zdroj prostřednictvím plug-in programu, je vyzván, aby zadal informace potřebné k autentizaci. V konfiguraci e-community plug-in server identifikuje ″ručící - vouch for″ server a požaduje ověření z tohoto ″ručícího - vouch for″ serveru, že je tento uživatel autentizován. ″Ručící - vouch for″ server ukládá informace o platném pověření uživatele. Při prvním požadavku uživatele je vždy ″ručícím - vouch for″ serverem server MAS. MAS server dále vystupuje jako ″ručící - vouch for″ server pro zdroje, které jsou umístěny v domovské doméně. Jak uživatel pokračuje v požadování zdrojů v rámci celé e-community, samostatný server v každé vzdálené doméně může vytvořit své vlastní pověření pro tohoto uživatele (založené na informacích o totožnosti uživatele ze serveru MAS) a převzít na sebe roli ″ručícího - vouch for″ serveru pro zdroje v dané doméně.
Obrázek 9. Přihlášení se do e-community.
Výše uvedený příklad zobrazuje dvě domény, doménu IBM a doménu Lotus, které jsou nadefinovány v rámci e-community. Při prvním přihlášení uživatele na zabezpečený webový server v e-community nastanou následující procesy: 1. Uživatel požaduje přístup ke zdroji na webovém serveru ww1.ibm.com. Plug-in program zachytí požadavek a potvrdí, že ww1.ibm.com je nakonfigurován jako součást e-community s názvem Tivoli-IBM-Lotus. MAS server v e-community se určí z konfigurace ww1.ibm.com. 2. Požadavek je předán na MAS server - www.tivoli.com. MAS server autentizuje požadavek v zastoupení ww1.ibm.com a vydá ″ručící - vouch for″ token, který se stane totožností uživatele e-community. Informace o totožnosti uživatele v tokenu je zašifrována.
146
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
3. MAS server odešle ″ručící - vouch for″ token na ww1.ibm.com. ww1.ibm.com zachází s ″ručícím - vouch for″ tokenem jako s potvrzením, že uživatel byl úspěšně autentizován serverem MAS a může nyní přistupovat k požadovanému zdroji na základě normálního řízení autorizace.
Cookie e-community v Cookie e-community je cookie specifická pro doménu, která byla nastavena jedním plug-in programem, uložena do paměti prohlížeče uživatele a přenesena v následujících požadavcích na jiné instance plug-in programu (ve stejné doméně). v Cookie specifická pro danou doménu obsahuje jméno ″ručícího - vouch for″ serveru, totožnost e-community, umístění (URL) ″ručícího - vouch for″ serveru, funkcionalitu a hodnotu doby trvání. Cookie neobsahuje žádné informace o uživateli. v Cookie e-community dovoluje serverům v účastnících se doménách, aby požadovaly ″ručící - vouch for″ informace lokálně. Cookie e-community pro doménu, ve které je umístěn MAS server, hraje v takovém případě méně důležitou úlohu. v Cookie má dobu trvání (časový limit), která je nastavena v konfiguračním souboru pdwebpi.conf. Tato doba trvání určuje, jak dlouho může vzdálený server poskytovat ″ručící - vouch for″ informace o uživateli. Když skončí doba platnosti cookie, uživatel musí být přesměrován na MAS server, kde se znovu autentizuje. v Cookie je odstraněna z paměti, jakmile je prohlížeč uzavřen. Pokud se uživatel odhlásí z určité domény, cookie e-community je přepsána, jako kdyby byla prázdná. Tato akce účinně odstraní takovou cookie z prohlížeče.
″Vouch-for″ požadavek a odpověď Operace ″vouch for″ e-community vyžaduje vyhrazenou funkcionalitu, ke které je možné přistupovat prostřednictvím dvou speciálně vytvořených URL: požadavku ″vouch for″ a odpovědi ″vouch for″. Tato URL jsou vytvořena během přesměrování HTTP ″vouch for″ e-community, která jsou založena na informacích o konfiguraci v souboru pdwebpi.conf.
″Vouch-for″ požadavek
″Vouch for″ požadavek je spuštěn, když uživatel požaduje zdroj z cílového serveru (který je nakonfigurován jako součást e-community), který neobsahuje žádné informace o pověření tohoto uživatele. Server odešle přesměrování na ″vouch for″ server (buď MAS server, nebo delegovaný ″vouch for″ server určený v e-community cookie). ″Vouch-for″ požadavek obsahuje následující informace: https://vouch-for-server/pkmsvouchfor?ecommunity-jméno&cílové-url
Přijímající server zkontroluje ecommunity-jméno, aby zkontroloval totožnost e-community. Přijímající server používá cílové-URL ve ″vouch for″ odpovědi k přesměrování prohlížeče zpět na původně požadovanou stránku. ″Vouch for″ URL pkmsvouchfor je konfigurovatelné. Například: https://www.tivoli.com/pkmsvouchfor?companyABC&https://ww2.lotus.com/index.html
″Vouch-for″ odpověď
″Vouch for″ odpověď je odpověď ″ručícího - vouch for″ serveru cílovému serveru. ″Vouch-for″ odpověď obsahuje následující informace: https://cílové-url?PD-VFHOST=vouch-for-server&PD-VF=zašifrovaný-token
Kapitola 6. Řešení přihlášení napříč doménou
147
Parametr PD-VFHOST určuje server, který provedl operaci ″vouch for″. Přijímající (cílový) server používá tuto informaci, aby si vybral správný klíč, který je nutný k dešifrování ″vouch for″ tokenu (PD-VF). Parametr PD-VF představuje zašifrovaný ″vouch for″ token. Například: https://ww2.lotus.com/index.html?PD-VFHOST=www.tivoli.com&PD-VF=3qhe9fjkp...ge56wgb
″Vouch-for″ token Proto, aby bylo možné zajistit jednotné přihlášení přes všechny domény, je nutné mezi servery přenášet některé informace o totožnosti uživatele. Tyto citlivé informace se obsluhují pomocí přesměrování, které obsahuje zašifrované informace o totožnosti jako součást URL. Tato zašifrovaná data se nazývají ″vouch for″ token. v Token obsahuje ″vouch for″ stav, potvrzující úspěch nebo selhání, totožnost uživatele (byl-li požadavek úspěšný), plně kvalifikované jméno serveru, který vytvořil token, totožnost e-community a čas vytvoření. v Držitel platného ″vouch for″ tokenu může použít tento token k vytvoření relace (a sady pověření) na serveru, aniž by se musel explicitně k tomuto serveru autentizovat. v Token je zašifrován pomocí sdíleného tajného klíče triple-DES, takže je možné jeho důvěryhodnost ověřit. v Zašifrované informace tokenu nejsou uloženy v prohlížeči. v Token je předán pouze jednou. Přijímající server použije tuto informaci, aby vytvořil pověření klienta ve své vlastní paměti cache. Tato pověření server použije pro další požadavky tohoto uživatele během stejné relace. v Token má dobu trvání, která je nastavena v konfiguračním souboru pdwebpi.conf. Tato hodnota může být velmi krátká (vteřiny), aby bylo minimalizováno riziko přehrání tokenu jiným subjektem. Poznámka: Zabezpečení tokenu bylo ve vydání 4.1 plug-in programu vylepšeno. Zlepšení nejsou schopna spolupracovat s šifrovacím schématem tokenů ve vydání 3.9 produktu Tivoli Access Manager. Chcete-li i nadále být schopni spolupracovat s produkty Tivoli Access Manager Web Security verze 3.9, nastavte konfigurační parametr pre-410-compatible-tokens ve stanze [pdweb-plugins] má hodnotu true. Tento parametr platí pro celý proces a nelze jej nastavit na úrovni virtuálního hostitele.
Zašifrování ″vouch-for″ tokenu Produkt Tivoli Access Manager Plug-in for Web Servers musí zašifrovat autentizační data, která jsou umístěna v tokenu, pomocí klíče, který byl vygenerován obslužným programem cdsso z adresáře /bin. Tento klíč musíte ″synchronizovat″, aby všechny plug-in servery v každé z účastnících se domén mohly sdílet stejný soubor klíčů. Každý účastnící se plug-in server v každé z domén musí používat stejný klíč. Poznámka: Vytvoření a distribuce souborů klíčů není součástí procesu e-community produktu Tivoli Access Manager. Musíte ručně a bezpečně okopírovat klíče na každý z účastnících se serverů. Obslužný program cdsso při svém spuštění vyžaduje, abyste zadali umístění (absolutní cestu) souboru klíčů: UNIX: # /opt/pdwebrte/bin/cdsso_key_gen absolutní-název-cesty
Windows: MSDOS> cesta-instalace/pdwebrte/bin/cdsso_key_gen absolutní-název-cesty
148
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Šifrovací klíče jsou nakonfigurovány ve stanze [ecsso-domain-keys] konfiguračního souboru pdwebpi.conf. Podrobnosti týkající se konfigurace jsou součástí další části “Konfigurace e-community”.
Konfigurace e-community Tato část podává přehled všech konfiguračních parametrů, které jsou nezbytné pro implementaci e-community. Tyto parametry jsou umístěny v souboru pdwebpi.conf. Musíte pečlivě nakonfigurovat tento soubor pro každý účastnící se plug-in program v e-community. Aktivace a zablokování členů e-community Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Pokud chcete plug-in serveru dovolit, aby pracoval v rámci e-community, přiřaďte slovo ecsso k parametrům authentication a pre-authzn tak, jak je uvedeno v následujícím příkladě: [common-modules] authentication = ecsso pre-authzn = ecsso
Při konfiguraci členů e-community, které nejsou MAS, musí mít autentizace ecsso přednost před dalšími schématy autentizace. To znamená, že ecsso musí být v seznamu modulů autentizace uvedena dříve než ostatní schémata autentizace. Dále platí, že pokud má modul ecsso mít přednost před modulem autentizace uvedeným s větší úrovní autentizace než je předvolená 1, pak musí být modul ecsso sám o sobě nakonfigurován na minimálně stejné úrovni autentizace. Stanza [modules] v konfiguračním souboru pdwebpi.conf definuje všechny dostupné mechanismy autentizace a jména k nim přidružených sdílených knihoven. Ujistěte se, že je zde uveden záznam pro SSO e-comunity: [modules] ecsso = pdwpi-ecsso-module
e-community-name Parametr e-community-name označuje jméno e-community, ke které patří daný server. Například: [ecsso] e-community-name = companyABC
Hodnota e-community-name musí být stejná pro všechny členy e-community. is-master-authn-server Tento parametr znamená, zda je server MAS server nebo ne. Možné hodnoty jsou yes nebo no. Parametr by mohl být nastaven podobně, jak je uvedeno níže pro MAS server e-community: [ecsso] is-master-authn-server = yes
Je možné, aby více plug-in programů bylo nakonfigurováno tak, aby vystupovalo jako MAS servery, a pak je možné je umístit za server vyvažující zatížení. V takovém případě je server vyvažující zatížení ″rozeznáván″ jako MAS server všemi ostatními plug-in servery v e-community. Pokud je parametr is-master-authn-server nastaven na hodnotu yes, pak tento server přijímá ″vouch-for for″ požadavky od ostatních instancí plug-in programu, jejichž klíče domén jsou uvedeny v seznamu ve stanze [ecsso-domain-keys].
Kapitola 6. Řešení přihlášení napříč doménou
149
master-authn-server Pokud je parametr is-master-authn-server nastaven na hodnotu no, pak musí být u parametru master-authn-server zrušen znak komentáře a tento parametr musí být uveden. Parametr označuje plně kvalifikované jméno domény MAS serveru e-community. Například: [ecsso] master-authn-server = www.tivoli.com
master-http-port Přiřadí číslo portu MAS serveru, který tento server používá pro přijímání požadavků HTTP. Pokud se nepoužije standardní číslo portu 80, pak toto nestandardní číslo portu musí být zde uvedeno. [ecsso] master-http-port = číslo-portu
master-https-port Přiřadí číslo portu MAS serveru, který tento server používá pro přijímání požadavků HTTPS. Pokud se nepoužije standardní číslo portu 443, pak toto nestandardní číslo portu musí být zde uvedeno. [ecsso] master-https-port = číslo-portu
vf-token-lifetime Tento parametr nastavuje hodnotu časového limitu doby trvání (ve vteřinách) ″vouch for″ tokenu. Tato hodnota se kontroluje vzhledem k době vytvoření, která je otisknuta v cookie. Předvolená hodnota je 180 vteřin. Musíte vzít v úvahu časový posuv mezi účastnícími se servery. Standardně je tento parametr nastaven takto: [ecsso] vf-token-lifetime = 180
vf-url Tento parametr určuje ″vouch for″ URL. Hodnota musí začínat lomítkem (/). Předvolená hodnota nastavení je: [ecsso] vf-url = /pkmsvouchfor
Můžete také vyjádřit rozšířené URL: vf-url = /ecommA/pkmsvouchfor
vf-argument Hodnota parametru vf-argument je jméno parametru vouch-for tokenu, jak se objeví ve vouch-for odpovědi. Předvolená hodnota PD-VF by měla být měněna pouze, pokud se používají přizpůsobené moduly vytvoření a použití a pro reprezantaci vouch-for tokenu se používá jiné jméno parametru. Hodnota se použije k vytvoření odpovědí vouch-for pomocí MAS a k rozlišení příchozích požadavků jako těch s informací couch-for použitím účasti serverů ECSSO. [ecsso] vf-argument = PD-VF
allow-login-retry MAS server, který používá schéma autentizace založené na jméně uživatele/hesle má dvě možnosti, jak pokračovat, když se uživateli nepodaří přihlásit: může vyzvat uživatele, aby zadal znovu své pověření, nebo může okamžitě uživatele přesměrovat zpět na server, ke kterému se uživatel pokoušel přistoupit, aniž by za uživatele ručil. V druhém případě je uživatel donucen autentizovat se přímo na podřízeném serveru. Parametr allow-login-retry
150
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
řídí uvedené chování serveru MAS. Tento parametr je možné použít pouze u konfigurací serveru MAS v rámci řešení jednotného přihlášení pomocí e-community. Poznámka: Uživatelé se mohou pokusit znovu nastavit své heslo, kterému skončila platnost. Jiná selhání při přihlášení, která mohou nastat na MAS serveru, jako např. uzamčení účtu, způsobí okamžité přesměrování zpět na podřízený server bez ohledu na hodnotu parametru allow-login-retry. Standardně je tento parametr nastaven takto: [ecsso] allow-login-retry = true
use-utf8 Tento parametr ovládá zakódování řetězce uvnitř vouch-for tokenů ECSSO a cookies e-community. Hodnota tohoto parametru ovlivní pouze tokeny vouch-for vytvořené a použité předvolenými SSO knihovnami vytvoření a použití. [ecsso] use-utf8 = true
ecsso Domain Keys Ve stanze [ecsso-domain-keys] konfiguračního souboru jsou nadefinována umístění souborů klíčů, které jsou nutné pro zašifrování a dešifrování tokenů mezi MAS serverem a účastnícími se servery ve vzdálených doménách. Konfigurace MAS serveru vyžaduje nadefinování klíčů pro každou doménu, pro kterou tento server vystupuje jako hlavní. Konfigurace členů e-community, kteří nejsou MAS serverem, vyžaduje nadefinování klíčů pro doménu a pro MAS server. Musíte uvést plně kvalifikovaná jména domén pro servery a absolutní cesty pro umístění souborů klíčů. Následující příklad konfigurace MAS server obsahuje MAS server se soubory klíčů, potřebnými pro komunikaci se dvěma vzdálenými doménami: [ecsso-domain-keys] ibm.com = /abc/xyz/ibm-tivoli.key lotus.com = /abc/xyz/lotus-tivoli.key tivoli = /abc/xyz/tivoli.key
Poznámka: Ve výše uvedeném příkladu je rozhodující mít pro výměnu dat mezi servery v doméně tivoli tivoli.key . Konfigurace serverů v doménách vyžaduje uvedení domény MAS serveru a odpovídajícího klíče, používaného k výměně informací s MAS serverem. Klíč je také nezbytný při výměně dat mezi servery v doméně. Například stanza [ecsso-domain-keys] pro server v doméně, která se podílí na e-community, může vypadat třeba takto: [ecsso-domain-keys] #klíč pro výměnu dat mezi serverem MAS (tivoli.com) #a servery domény ibm.com tivoli.com = /abc/xyz/ibm-tivoli.key #klíč pro výměnu dat mezi servery domény ibm.com ibm.com = /abc/xyz/ibm.key
Zahrnutí atributů pověření ve vouch-for tokenech Atributy pověření můžete zahrnout v vouch-for tokenech eCSSO jejich uvedením ve stanze [ecsso-token-attributes] konfiguračního souboru plug-in programu. Atributy, které se mají zahrnout mohou být uvedeny na bázích peer-to-peer nebo na bázích po jednotlivých doménách. Atributy pověření vypsané v této stanze jsou relevantní pouze, pokud se používají předvolené SSO knihovny vytvoření a použití tokenu. Pokud ve vouch-for tokenech eCSSO nevyžadujete atributy pověření, tak můžete nechat tuto stanzu prázdnou.
Kapitola 6. Řešení přihlášení napříč doménou
151
Předvolené jméno této stanzy je odvozeno od jména modulu pro pdwpi-ecsso-module, nadefinovaného ve stanze [modules]. Je ve tvaru [jméno-modulu-ecsso-atributy-tokenu]. Hodnoty ve stanze [ecsso-token-attributes] jsou standardní pro všechny virtuální hostitele a mohou být přepsány na bázích po jednotlivých virtuálních hostitelích vytvořením stanzy [jméno-modulu-cdsso-atributy-tokenu:virtuální-hostitel]. Formát záznamů je: jméno-domény = vzor1, vzor2, ... vzor n. Atributy pověření odpovídající uvedeným vzorům pro cílového hostitele nebo doménu jsou zahrnuty ve vouch-for tokenech eCSSO vytvořených pro tohoto hostitele nebo doménu. Pro každý atribut se použije pouze jedna hodnota a jsou podporovány pouze hodnoty řetězce. Ostatní typy hodnot atributů pověření jsou ignorovány. Vzory mohou být uvedeny pomocí znaků odpovídajících vzoru vysvětlených v části Dodatek E, “Speciální znaky dovolené v běžných výrazech”, na stránce 211. Například: [ecsso-token-attributes] ibm.com = attrprefix_*, *name* tivoli.com = *_attrsuffix, some_exact_attribute
Předvolené nastavení atributů může být nakonfigurováno pomocí záznamu <default> v této stanze. Předvolené nastavení atributů se použije, když neexistuje žádný další záznam odpovídající partikulárnímu cílovému hostiteli. Když není přítomen záznam <default>, nebudou předvolbou zahrnuty žádné atributy.
Přijetí a zamítnutí atributů pověření z tokenů vouch-for Uvedením hodnot ve stanze [ecsso-incoming-attributes] můžete uvést atributy pověření, které se mají z příchozích tokenů autentizace pomocí CDSSO přijmout a ty, které se mají zamítnout. Narozdíl od konfigurace odchozích atributů, nemohou být příchozí atributy nakonfigurovány na bázích per-peer nebo na bázích po jednotlivých doménách. Může být nakonfigurována pouze jedna sada vzorů atributů a tyto vzory se použijí pro příchozí tokeny bez ohledu na zdroj. Toto zpracování se provede pouze, pokud se používají předvolené SSO knihovny vytvoření a použití tokenu. Předvolené jméno této stanzy je odvozeno od jména modulu pro pdwpi-ecsso-module, nadefinovaného ve stanze [modules]. Je ve tvaru [jméno-modulu-cdsso-příchozí-atributy].Hodnoty v této stanze jsou standardní pro všechny virtuální hostitele. Avšak mohou být přepsány na bázích po jednotlivých virtuálních hostitelích vytvořením stanzy [jméno-modulu-cdsso-příchozí-atributy:virtuální-hostitel]. Formát záznamů v této stanze je: vzor-atributu = preserve|refresh
Atributy v tokenech vouch-for eCSSO odpovídající záznamu refresh jsou z tokenu odstraněny před tím, než je knihovna CDMF volána na mapování vzdáleného uživatele v lokální doméně. Atributy neodpovídající záznamu preserve nebo neodpovídající žádnému záznamu jsou zadrženy. Pokud nejsou nakonfigurovány žádné záznamy, jsou zadrženy všechny atributy.
Uvedení knihoven sso-create a sso-consume Abyste uvedli knihovny sso-create a sso-consume, editujte konfigurační soubor plug-in programu. Ve stanze [authentication-mechanisms] nekomentujte záznam pro sso-create a sso-consume a přidejte jméno knihovny failover cookie plug-in programu odpovídající typu operačního systému. Standardní záznam konfiguračního souboru je:
152
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
[authentication-mechanisms] sso-create = /opt/pdwebrte/lib/ibssocreate.so sso-consume = /opt/pdwebrte/lib/libssoconsume.so
Když jste rozvinuli knihovnu CDAS implementující přizpůsobenou verzi funkcionality sso-create a sso-consume, vložte alternativně jako hodnotu pro klíčové slovo konfiguračního souboru jméno přizpůsobené CDAS. Pokud jste například rozvinuli přizpůsobenou CDAS pro sso-create, zadejte absolutní název cesty: [authentication-mechanisms] sso-create = /dir_name/custom_cdas_sso-create.so
Chyba při konfiguraci klíčů ecsso správně generuje varování do souboru protokolu plug-in programu.
Konfigurace jednotného přihlášení pomocí e-community příklad V následujícím příkladu jsou nakonfigurovány dvě e-community – lotus-domino a ibm-db2 – s jedním MAS serverem, který autentizuje požadavky z obou komunit.
Obrázek 10. Příklad konfigurace jednotného přihlášení pomocí e-community
Pro tento příklad platí následující podmínky: v www.tivoli.com je MAS server pro obě e-community. v V rámci e-community lotus-domino existují dvě rozdílné domény (pro zjednodušení je v každé doméně jeden server) – domino.com a lotus.com. Uživatelé přistupující k jedné z těchto domén mohou přistupovat i do druhé, aniž by se museli znovu autentizovat, neboť přístup je udílen prostřednictvím MAS serveru. v e-community s názvem ibm-db2 obsahuje dvě zvláštní domény – ibm.com a db2.com. Uživatelé přistupující k jedné z těchto domén mohou přistupovat i do druhé, aniž by se museli znovu autentizovat. v Uživatelé přistupující k jednomu ze serverů ibm.com mohou přistupovat k dalším serverům pomocí ″vouch for″ tokenů. V tomto případě je dosaženo jednotného přihlášení, aniž by bylo nutné používat MAS server k udílení přístupu. Kapitola 6. Řešení přihlášení napříč doménou
153
Ve výše uvedeném příkladu platí následující podmínky konfigurace: Konfigurace MAS serveru – www.tivoli.com Jelikož je MAS server řídicím centrem pro více než jednu e-community, musí být nakonfigurovány dvě rozdílné instance ecsso modulu a musí být nadefinována dvě jména e-community, které budou řízeny MAS serverem. MAS server musí mít uvedeny všechny klíče hlavních domén v rámci komunit, které řídí. Konfigurace je nastavena následovně: [modules] ecsso1 = pdwpi-ecsso-module ecsso2 = pdwpi-ecsso-module [common-modules] authentication = ecsso1 authentication = ecsso2 pre-authzn = ecsso1 pre-authzn = ecsso2 [ecsso1] e-community-name = lotus-domino is-master-authn-server = yes .....atd. [ecsso2] e-community-name = ibm-db2 is-master-authn-server = yes .....atd. [ecsso1-domain-keys] # jeden klíč pro každou doménu, řízenou MAS serverem domino.com = /abc/tivolikeys/tivoli-domino.key lotus.com = /abc/tivolikeys/tivoli-lotus.key db2.com = /abc/tivolikeys/tivoli-db2.key ibm.com = /abc/tivolikeys/tivoli-ibm.key
Konfigurace www.domino.com [modules] ecsso = pdwpi-ecsso-module [common-modules] authentication = ecsso pre-authzn = ecsso [ecsso] e-community-name = lotus-domino is-master-authn-server = no master-authn-server = www.tivoli.com .....atd. [ecsso-domain-keys] #klíč pro zašifrování/dešifrování dat #mezi servery v doméně domino.com domino.com = /abc/domino-keys/domino.key #klíč pro zašifrování/dešifrování dat mezi #servery v doméně domino.com domain a MAS serverem tivoli.com = /abc/domino-keys/tivoli-domino.key
Konfigurace www.lotus.com Parametry konfigurace, pomocí kterých je možné docílit jednotného přihlášení do www.lotus.com, budou identické s parametry, které byly nakonfigurovány pro www.domino.com, kromě klíčů domény, které budou jiné. Konfigurace klíčů domény pro www.lotus.com by měla být následující:
154
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
[ecsso-domain-keys] #klíč pro zašifrování/dešifrování dat #mezi servery v doméně lotus.com lotus.com = /abc/lotus-keys/lotus.key #klíč pro zašifrování/dešifrování dat #mezi servery v doméně lotus.com a MAS serverem tivoli.com = /abc/lotus-keys/tivoli-lotus.key
Konfigurace www.db2.com [modules] ecsso = pdwpi-ecsso-module [common-modules] authentication = ecsso pre-authzn = ecsso [ecsso] e-community-name = ibm-db2 is-master-authn-server = no master-authn-server = www.tivoli.com .....atd. [ecsso-domain-keys] #klíč pro zašifrování/dešifrování dat #mezi servery v doméně db2.com db2.com = /abc/db2-keys/db2.key #klíč pro zašifrování/dešifrování dat mezi #servery v doméně db2.com a MAS serverem tivoli.com = /abc/db2-keys/tivoli-db2.key
Konfigurace ww1.ibm.com Konfigurace jednotného přihlášení pomocí e-community pro ww1.ibm.com je identická s konfigurací www.db2.com. Jsou požadovány dva klíče, jeden pro zašifrování/dešifrování dat mezi MAS serverem a doménou ibm.com, a druhý pro zašifrování/dešifrování dat mezi servery v doméně ibm.com (tj. ww1.ibm.com a ww2.ibm.com pro tento příklad). [ecsso-domain-keys] ibm.com = /abc/ibm-keys/ibm.key tivoli.com = /abc/ibm-keys/tivoli-ibm.key
Konfigurace ww2.ibm.com Definice klíčů pro ww2.ibm.com bude identická s definicí pro ww1.ibm.com. [ecsso-domain-keys] ibm.com = /abc/ibm-keys/ibm.key tivoli.com = /abc/ibm-keys/tivoli-ibm.key
Kapitola 6. Řešení přihlášení napříč doménou
155
156
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Kapitola 7. Integrace aplikace Produkt Tivoli Plug-in for Web Servers podporuje integraci aplikací třetí strany pomocí proměnných prostředí a schopnosti dynamického URL. Plug-in program rozšiřuje rozsah proměnných prostředí a hlaviček HTTP, aby umožnil aplikacím třetí strany provést operace založené na totožnosti klienta. Plug-in program může poskytnout ovládání přístupu na dynamická URL, jako jsou ta obsahující text dotazu. V této kapitole jsou zahrnuta následující témata: v “Udržování stavu relace mezi klientem a aplikacemi back-end” v “Poskytnutí řízení přístupu k dynamickým URL” na stránce 159
Udržování stavu relace mezi klientem a aplikacemi back-end Jak můžete vidět v části “Správa stavu relace” na stránce 49, produkt Tivoli Access Manager for Web Servers může udržet stav relace s klienty přes HTTP a HTTPS použitím různých informací. Plug-in program také může back-end aplikacím poskytnout informaci o relaci uživatele, takže mohou udržet stav relace s klienty. Poskytnutí informace o relaci uživatele dává metodu pro její označení a schopnost ji uvolnit v požadavku aplikace chráněné plug-in programem. Bez nastavení stavu relace mezi klientem a serverem by musela být znovu vytvořena komunikace mezi klientem a serverem pro každý následující požadavek. Informace o stavu relace eliminací potřeby opakovat zavření a další otevření připojení klienta/serveru zlepšují výkonnost . Klient se může přihlásit jednou a provést množství požadavků, aniž by byl nucen se samostatně přihlásit při každém požadavku.
Aktivace správy ID relace uživatele Parametr add-session-id-to-cred ve stanze [performance] konfiguračního souboru plug-in programu vám umožňuje povolit nebo zakázat vytvoření jedinečného ID relace uživatele v pověření každého klienta, který dává požadavek. Předvolená hodnota je true (enabled): [performace] add-session-id-to-cred = true
Abyste zakázali vytvoření jedinečných ID relace uživatele, nastavte add-session-id-to-cred na false. Jedinečné ID relace uživatele je uloženo v pověření uživatele jako rozšířený atribut se jménem a hodnotou: tagvalue_user_session_id = user-session-id
V pověření se jméno jeho rozšířeného atributu (user_session_id) objeví s předponou ″tag value″, který konfigurovatelně používá parametr tag-value-prefix ve stanze [pdweb-plugins] konfiguračního souboru. Tato předpona brání konfliktům z dalšími stávajícími informacemi v pověření. Hodnota ID relace uživatele je řetězec, který jedinečně označuje určitou relaci pro autentizovaného uživatele. ID relace uživatele je řetězec zakódovaný pomocí MIME-64 zahrnující jméno instance plug-in programu (pro podporu několika instancí plug-in programu) a standardní ID relace plug-in programu pro uživatele.
© Copyright IBM Corp. 2000, 2003
157
Jednotlivý uživatel přihlašující se několikrát (například z různých počítačů) má více ID relace plug-in programu. Protože je ID relace uživatele vytvořeno na základě ID relace plug-in programu, existuje mezi nimi mapování jedna ku jedné. Jedinečné ID relace uživatele je uloženo jako atribut do pověření uživatele. To umožňuje, aby hodnota prošla spojeními jako hlavička HTTP (pomocí funkcionality hodnoty příznaku) a stala se dostupnou pro aplikaci back-end.
Vkládání dat pověření do hlavičky HTTP Cílem správy relace uživatele je poskytnout jedinečné ID relace uživatele do aplikačního serveru. Tento cíl je dokončen nakonfigurováním rozšířeného atributu HTTP-Tag-Value na objektu. Používáte příkaz atributu sady úpravy objektu pdadmin k nastavení rozšířeného atributu na objektu v prostoru objektu chráněného plug-in programem. pdadmin> object modify jméno-objektu set attribute attr_name attr_value
Atribut (″attr-name″) umožňuje plug-in programu provést určitý typ funkcionality. Atribut HTTP-Tag-Value umožňuje plug-in programu extrahovat hodnotu z rozšířeného atributu pověření a odeslat ji do serveru v hlavičce HTTP. Hodnota rozšířeného atributu HTTP-Tag-Value používá následující formát: jméno-rozšířeného-atributu-pověření =jméno-hlavičky-http
Pro data ID relace uživatele je záznam jméno-rozšířeného-atributu-pověření stejný jako jméno rozšířeného atributu id-relace-uživatele uvedené v konfiguračním souboru, ale bez nakonfigurovaného prefixu. Záznam není citlivý na velikost písmen. Hodnota tohoto rozšířeného atributu obsahuje jedineční ID relace uživatele. Záznam jméno-hlavičky-http uvádí jméno hlavičky HTTP použité k doručení dat. V tomto příkladu se použije hlavička nazvaná PD-USER-SESSION-ID: pdadmin> object modify /PDWebPI/host set attribute \ HTTP-Tag-Value user_session_id=PD-USER-SESSION-ID
Když plug-in program zpracovává požadavek uživatele pro aplikační server back-end, hledá jakékoli rozšířené atributy HTTP-Tag-Value nakonfigurované na objektu. V tomto příkladu vyhledává plug-in program pověření uživatele dávajícího požadavek, extrahuje hodnotu ID relace uživatele z rozšířeného atributu tagvalue_user_session_id v pověření a umisťuje hodnotu v hlavičce HTTP jako: PD-USER-SESSION-ID:user_session_id_number
Souhrn: Hodnota atributu HTTP-Tag-Value nastavená na objektu plug-in programu:
user_session_id=PD-USER-SESSION-ID
Jméno atributu a hodnota, jak se objeví v tagvalue_user_session_id:user_session_id_number pověření uživatele: Jméno a hodnota hlavičky HTTP:
PD-USER-SESSION-ID:user_session_id_number
Pokud je aplikace back-end aplikací CGI, diktují specifikace CGI, že se hlavičky HTTP stanou dostupné pro programy CGI jako proměnné prostředí ve formátu: HTTP_HTTP_jméno-hlavičky
Například: HTTP_PD-USER-SESSION-ID=id-relace-uživatele
158
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Ukončení relací uživatele Funkcionalita správy ID relace uživatele se může použít k ukončení relací uživatele poskytujících jedinečné ID relace uživatele nebo jméno uživatele produktu Tivoli Access Manager. Tyto příkazy mohou být spuštěny z příkazového řádku PDADMIN (pomocí úlohy serveru), ale jsou určeny pro použití aplikacemi back-end přes PDAdmin API. Ukončení relace pomocí ID relace uživatele způsobí, že plug-in odloží jednotlivou relaci, kterou ID relace uživatele označuje. Ostatní relace stejného uživatele mohou pokračovat. Ukončení pomocí jména uživatele produktu Tivoli Access Manager způsobí, že plug-in program odloží VŠECHNY relace, které jsou poskytnutým jménem uživatele vlastněny. Tento příkaz může ukončit mnoho relací, pokud je uživatel přihlášen vícekrát z různých umístění nebo prohledávacích programů. Uživatel může zahájit ukončení aktuální relace příkazem pkmslogout. Informace v ID relace uživatele umožňují administrátorům a aplikacím back-end sledovat a spravovat uživatele. Níže jsou uvedeny dva způsoby ukončení relací uživatele na úrovni administrativy: K ukončení jednotlivé relace uživatele pomocí ID uživatele může administrátor použít obslužný program pdadmin. pdadmin> server task pdwebpi-jméno-instance-plug-in-programu terminate all_sessions id-uživatele
Použitím příkazu all-sessions,jak bylo zobrazeno výše, je na všech virtuálních hostitelích na počítači ukončena každá relace pro uvedeného uživatele. Tento příkaz může být upraven, aby ukončoval relace uživatele pro partikulárního uživatele na partikulárním virtuálním hostiteli pomocí parametru -vhost jako v následujícím příkladu (zadáno jako jeden řádek): pdadmin> server task pdwebpi-jméno-instance-plug-in-programu terminate all_sessions id-uživatele -vhost "jméno-virtuálního-hostitele"
Poskytnutí řízení přístupu k dynamickým URL Produkt Tivoli Access Manager Plug-in for Web Servers může použít autorizaci k objektům webu na základě shody vzoru celého řetězce požadavku raději než jenom URL objektu. To je užitečné pro aplikace webu, které dynamicky generují URL v odpovědi na každý požadavek uživatele, který stále vyžaduje silnou ochranu od nechtěného použití nebo přístupu. To je také užitečné pro přiřazení různých oprávnění různým metodám scénářů. Řetězec dotazu GET /cgi-bin/servercontrol?action=showstatus může mít například jiné požadavky na zabezpečení na GET /cgi-bin/servercontrol?action=shutdown. Každý z těchto požadavků může požadovat, aby byl jedinečně reprezentován v objectspace, takže se může pro každý z nich použít odlišná metoda. Modul dynurl umožňuje sadě vzorů, aby byla definována jako porovnávané s příchozími požadavky. Vzory jsou porovnávány s celými řetězci požadavku, takže je shoda informace v řetězci požadavku možná. Pro každý vzor DynURL je definován objekt produktu Tivoli Access Manager. Tento objekt se objeví v objectspace, takže k němu může být přidružena metoda. V runtimu je libovolný požadavek odpovídající vzoru dynurl autorizován pomocí objektu přidruženého ke vzoru, ne objektu reprezentujícího URL. Definováním různých vzorů, které nezávisle odpovídají různým řetězcům požadavku, se mohou použít různé objekty produktu Tivoli Access Manager a může se použít různá politika.
Kapitola 7. Integrace aplikace
159
Konfigurace dynamických URL Stanza [common-modules] v konfiguračním souboru pdwebpi.conf definuje použití všech metod autentizace. Abyste aktivovali porovnávání vzorů dynamických URL pro příchozí požadavky, musí být modul dynurl nakonfigurován jako předcházející autorizaci. To umožňuje modulu dynurl, aby měnil požadovaný objekt před dosažením prostředku autorizace. [common-modules] ... pre-authzn = dynurl ...
Zajistěte, že záznam pro dynamická URL existuje ve stanze [modules] konfiguračního souboru pdwebpi.conf: [modules] ... dynurl = pdwpi-dynurl-module ...
Stanza [dynurl] (předvoleně nebo jméno stanzy odpovídající jménu konfigurovaného modulu) obsahuje definice pro předautorizační modul dynamického URL. Tato stanza může být přepsána na bázích po jednotlivých virtuálních hostitelích, to je, [dynurl:virtual-host]. Záznamy ve stanze [dynurl] mají formát objekt = vzor, kde je každý záznam na odděleném řádku. Pořadí v seznamu určuje pořadí, ve kterém jsou zpracovávána pravidla. Záznamy, které se ve stanze vyskytnou dříve, mají přednost před těmi, které se v ní vyskytnou později. Například: [dynurl] /servershutdown = /servercontrol.asp\?*action=shutdown* /serverreset = /servercontrol.asp\?*action=reset* /helppages = *help.html
Všimněte si, že všechny objekty začínají zpětným lomítkem (″/″). Poslední záznam ve výše uvedené konfiguraci zobrazuje druhé použití modulu dynurl. V tomto případě odpovídá vzor sadě URL (libovolné URL končící v help.html). V tomto případe provádí DynURL many-to-one mapování URL na objekty produktu Tivoli Access Manager. Všechny požadavky na stránky nazvané help.html (bez ohledu na jejich cestu) budou autorizovány před stejnými objekty produktu Tivoli Access Manager. To může být užitečné v situacích, kdy mají všechny soubory se stejnými jmény (která mohou být seskupena dle vzoru) stejné požadavky na zabezpečení. Avšak, všimněte si, že je každý definovaný vzor porovnáván s každým požadavkem a tak zpomaluje každou autentizaci. Také si všimněte, že použití vzoru *help.html může mít důsledky v zabezpečení pro scénáře, poněvadž požadavek /servercontrol.asp?action=some_other_action&pointless_variable _used_to_evade_acl_attached_to_server_control.asp=help.html
bude odpovídat dynamickému URL *help.html. Proto bude přístup zhodnocen na základě objektu /helppages, raději než na základě objektu /servercontrol.asp. Stejně tak bude požadavek pro /someotherscript?action=someaction&other_var=help.html
zhodnocen na základě objektu /helppages, raději než na základě objektu /someotherscript. Seznam speciálních znaků povolených v regulárních výrazech použitých v konfiguračním souboru jednotného přihlášení pomocí formulářů naleznete v části Dodatek E, “Speciální znaky dovolené v běžných výrazech”, na stránce 211.
160
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Ve většině případů nejsou speciální znaky vyžadovány, protože je požadavek na stránku přihlášení jednoduše označitelné URI. V některých případech můžete na konci výrazu použít ″*″, takže žádná data dotazu na konci URI nechrání stránku přihlášení od porovnávání.
Kapitola 7. Integrace aplikace
161
162
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Kapitola 8. Vyvolání ADI (authorization decision information retrieval) Tato kapitola obsahuje informace popisující, jak může produkt Tivoli Access Manager Plug-in for Web Servers poskytnout nebo získat ADI (autorization decision informnation) požadovanou ke zhodnocení autorizačních pravidel, která chrání zdroje v doméně Tivoli Access Manager. V této kapitole jsou zahrnuta následující témata: 1. “Vyvolání přehledu ADI” 2. “Načítání ADI z požadavku plug-in programu” na stránce 164 3. “Načítání ADI z pověření uživatele” na stránce 166 4. “Dodání důvodu selhání” na stránce 166 5. “Konfigurace vyvolání dynamické ADI” na stránce 167
Vyvolání přehledu ADI Program pro vyhodnocování pravidel autorizace produktu Tivoli Access Manager provádí rozhodnutí o autentuzaci na základě logiky Boolean použité pro určitou ADI (access decision information). Podrobnou informaci o konstrukci pravidel autorizace (pomocí logiky Boolean) a ADI (authorization decision information) můžete nalézt v knize IBM Tivoli Access Manager Base Administration Guide. ADI požadovaná pro ohodnocení pravidel může být načtena z následujících zdrojů: v Parametry rozhodnutí o autorizaci poskytnuté službou autorizace pravidlu autorizace jako ADI Parametry zahrnují cílový zdroj (chráněný objekt) a požadovaná akce na zdroji. Další informace o tomto tématu naleznete v knize IBM Tivoli Access Manager Base Administration Guide. v Pověření uživatele Pověření uživatele je vždy zahrnuto s voláním funkce do programu pro vyhodnocování pravidel autorizace, takže je okamžitě k dispozici. v Prostředí správce zdrojů (kontext aplikace) Správce zdrojů, jako je plug-in program, může být nakonfigurován, aby poskytl ADI ze svého vlastního prostředí. Plug-in program má například schopnost poskytnout ADI obsaženou v částech požadavku klienta. Speciální prefix se použije v pravidlu autorizace, aby ″dal spouštěcí impuls″ tomuto typu zdroje ADI. v Vnější zdroj přes služby vyvolání dynamické ADI ADI může být obdržena z vnějšku přes webovou službu AMWebARS. Volání do webové služby AMWebARS je provedeno přes službu pojmenování správce zdrojů. ADI z vnějšího zdroje je programu pro vyhodnocování pravidel autorizace vrácena ve formátu XML. ADI může být obdržena dynamicky přes volání do specifické služby pojmenování, která byla nakonfigurována, aby načetla ADI dynamicky během ověřování pravidel. Volání je uskutečněno pro službu vyvolání každé dynamické ADI a hodnoty ADI jsou vráceny programu pro vyhodnocování pravidel autorizace. Příkladem služeb vyvolání dynamické ADI zaslané s produktem Tivoli Access Manager jsou ″Služba pojmenování atributu registru″, která načítá hodnoty ADI z registru uživatelů, a služba pojmenování
© Copyright IBM Corp. 2000, 2003
163
AMWebARS, která načítá hodnoty ADI pomocí webové služby AMWebARS. Obě služby jsou podrobněji projednány v knize Tivoli Access Manager Authorization C Developer’s Reference.
Načítání ADI z požadavku plug-in programu ADI (authorization decision information) může být obsažena v hlavičce požadavku, v řetězci dotazu požadavku a v těle požadavku POST. Můžete vytvořit pravidla autorizace, která odkazují na tuto ADI (autorization decision information). To se provádí pomocí zásobníků XML specifických pro plug-in program, které odkazují na ADI, které se má získat. Parametr resource-manager-provided-adi ve stanze [aznapi-configuration] konfiguračního souboru pdwebpi.conf uvádí —do procesu ověřování pravidel autorizace— prefixy, které se mohou použít ve jménech zásobníků uvedených pravidly autorizace. Abyste uvedli několik prefixů, použijte několik záznamů parametru resource-manager-provided-adi: Následující jména zásobníku obsahují prefixy, které odpovídají plug-in programu: v AMWS_hd_jméno Jméno zásobníku hlavičky požadavku. Hodnota hlavičky HTTP nazvaná jméno v HTTP požadavku je vrácena programu pro vyhodnocování pravidel autorizace jako ADI. v AMWS_qs_jméno Jméno zásobníku řetězce dotazu požadavku. Hodnota pro jméno v řetězci dotazu požadavku je vrácena programu pro vyhodnocování pravidel autorizace jako ADI. v AMWS_pb_jméno Jméno zásobníku těla požadavku POST. Hodnota pro jméno v těle požadavku POST je vrácena programu pro vyhodnocování pravidel autorizace jako ADI. Prefixy mohou být určité pro libovolného správce zdrojů. Správce zdrojů tudíž musí být navržen, aby vhodně odpovídal na požadavek pro ADI. Pravidla autorizace jsou zapsána tak, že uvádějí ADI vyžadovanou z požadavků klienta. Pokud je například jméno hostitele obsažené v hlavičce HTTP požadováno jako ADI, použije se ve jméně zásobníku uvedeném v pravidle prefix AMWS_hd_. Tento prefix specifický pro plug-in program upozorňuje proces oveřování autorizace, že je požadovaná ADI dostupná v požadavku klienta, a že plug-in program ví, jak tuto ADI nalézt, extrahovat a vrátit. Plug-in programu je odesláno jméno zásobníku AMWS_hd_host. Plug-in program odpovídá na jméno zásobníku AMWS_hd_hostitel hledáním hlavičky ″host″ v požadavku klienta a extrahováním hodnoty přidružené k této hlavičce. Plug-in program vrací hodnotu hlavičky ″host″ (jako zásobník XML) procesu ověřování pravidel autorizace. Proces ověřování pravidel autorizace používá ve svém ověřování pravidel hodnotu jako ADI.
Příklad: Načítání ADI z hlavičky požadavku Následující příklad pravidla autorizace vyžaduje jméno hostitele počítače klienta. Požadavek klienta je nastaven, aby zahrnul hodnotu jména hostitele v hlavičce požadavku ″host″. Použití prefixu AMWS_hd_ v pravidle upozorňuje proces ověřování autorizace, že je požadovaná ADI dostupná v požadavku klienta, a že plug-in program ví, jak tuto ADI nalézt, extrahovat a vrátit. <xsl:if test=’AMWS_hd_host = "machineA"’>!TRUE!
Plug-in program je navržen, aby věděl jak zacházet s extrakcí informace ADI z požadavku: [aznapi-configuration] resource-manager-provided-adi = AMWS_hd_
164
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Plug-in program chápe, že lze tuto informaci nalézt ve jméně hlavičky požadavku hostitel. Plug-in program extrahuje hodnotu obsaženou v hlavičce ″host″ a vrací ji do procesu ověřování autorizace. Pokud hodnota poskytnutá v hlavičce ″host″ je ″machineA″, je příklad pravidla autorizace ohodnocen jako true. Stejným způsobem může informace požadovaná k ověření pravidla autorizace přijít z těla požadavku POST nebo z řetězce dotazu požadavku.
Příklad: Načítání ADI z řetězce dotazu požadavku Následující příklad pravidla autorizace vyžaduje jméno směrovacího čísla klienta, jak bylo posláno v řetězci dotazu požadavku GET (podpořeného v odpovědi na formulář). Požadavek klienta je nastaven, aby zahrnul hodnotu směrovacího čísla v poli ″zip″ řetězce dotazu požadavku. https://www.service.com/location?zip=99999
Použití prefixu AMWS_qs_ v pravidle upozorňuje proces oveřování autorizace, že je požadovaná ADI dostupná v požadavku klienta, a že plug-in program ví, jak tuto ADI nalézt, extrahovat a vrátit. <xsl:if test=’AMWS_qs_zip = "99999"’>!TRUE!
Plug-in program je navržen, aby věděl jak zacházet s extrakcí informace ADI z požadavku: [aznapi-configuration] resource-manager-provided-adi = AMWS_qs_
Plug-in program chápe, že lze tuto informaci nalézt v řetězci dotazu požadavku pod jménem pole ″zip″. Plug-in program extrahuje hodnotu obsaženou v poli ″zip″ a vrací ji do procesu ověřování autorizace. Pokud hodnota poskytnutá v řetězci dotazu požadavku ″zip″ je ″99999″, je příklad pravidla autorizace ohodnocen jako true. Stejným způsobem může informace požadovaná k ověření pravidla autorizace přijít z těla požadavku POST nebo z hlavičky požadavku.
Příklad: Načítání ADI z těla požadavku POST Následující příklad pravidla autorizace vyžaduje součet hodnoty nákupu klienta z nákupního košíku webu, jak byl poslán v těle požadavku POST (podpořeného v odpovědi na formulář). Požadavek klienta je nastaven, aby zahrnul součet hodnoty nákupu v poli ″purchase-total″ těla požadavku POST. Použití prefixu AMWS_pb_ v pravidle upozorňuje proces ověřování autorizace, že je požadovaná ADI dostupná v požadavku klienta, a že plug-in program ví, jak tuto ADI nalézt, extrahovat a vrátit. <xsl:if test=’AMWS_pb_purchase-total < "1000.00"’>!TRUE!
Plug-in program je navržen, aby věděl jak zacházet s extrakcí informace ADI z požadavku: [aznapi-configuration] resource-manager-provided-adi = AMWS_pb_
Plug-in program chápe, že lze tuto informaci nalézt v těle požadavku POST pod jménem pole ″purchase-total″. Plug-in program extrahuje hodnotu obsaženou v poli ″purchase-total″ a vrací ji do procesu ověřování autorizace. Kapitola 8. Vyvolání ADI (authorization decision information retrieval)
165
Pokud hodnota poskytnutá v těle požadavku POST ″purchase-total″ je menší než ″1000.00″, je příklad pravidla autorizace ohodnocen jako true. Stejným způsobem může informace požadovaná k ověření pravidla autorizace přijít z hlavičky požadavku nebo z řetězce dotazu požadavku.
Načítání ADI z pověření uživatele Pravidla autorizace mohou být zapsána, aby použila ADI, která je programu pro vyhodnocování pravidel autorizace poskytnuta na začátku jako část pověření. Výchozí volání do služby autorizace (azn_decision_access_allowed_ext()) momentálně obsahuje informaci o pověření klienta. Aby byla pravidlem zpracována libovolná ADI, tak si program pro vyhodnocování pravidel autorizace tuto informaci o pověření vždy prohlédne. Pravidlo autorizace může použít hodnotu z libovolného pole v pověření včetně rozšířených atributů přidaných do pověření během autentizace. Technika pro vytvoření rozšířených atributů v pověření uživatele je vysvětlena v části “Přidání rozšířených atributů pro pověření” na stránce 99.
Dodání důvodu selhání Pravidla autorizace vám umožňují nastavit speciální (a často komplexní) podmínky, které ovládají schopnost přistoupit ke chráněnému zdroji. Standardní důvod rozhodnutí o selhání autorizace však zastavuje zpracování požadavku do služby aplikace, která ovládá zdroj, a prezentuje klienta zprávou ″forbidden″. Pokud je pravidlo autorizace zapsáno, aby zahrnulo důvod selhání a je programem pro vyhodnocování pravidel autorizace produktu Tivoli Access Manager vyhodnoceno jako FALSE, obdrží plug-in program od služby autorizace důvod pro selhání pravidla spolu se standardní zprávou ″forbidden″. Důvod selhání je obvykle ignorován a je prosazeno rozhodnutí ″forbidden″. Plug-in program můžete volitelně nakonfigurovat, aby tuto standardní odpověď ignoroval, a aby aplikaci služby back-end povolil zpracovat odepřené požadavky. Požadavek je doprovozen důvodem selhání poskytnutým v pravidlu autorizace. Aplikace služby back-end poté má možnost provést zpracování se svou vlastní odpovědí na situaci. Tato volitelná konfigurace je uvedena parametrem pass-on-rule-failure-reason ve stanze [boolean-rules] v souboru pdwebpi.conf. Pravidla autorizace se obvykle používají ve spojení s aplikacemi služby, které mohou pochopit a zachází s nimi na více sofistikované úrovni ovládání přístupu. V některých případech je nutné, aby aplikace služby obdržela požadavek, který je službou autorizace produktu Tivoli Access Manager odepřen. Aplikace je zapsána, aby pochopila informaci o důvodu selhání a může poskytnout svou vlastní odpověď na požadavek, který způsobil selhání pravidla autorizace produktu Tivoli Access Manager. Komponenta pořadí zpracování aplikace nákupního košíku může být například ovládána pravidlem autorizace, které odepírá akci v pořadí, pokud celková cena překročí limit kreditu uživatele. To je důležité, aby aplikace nákupního košíku přijala celý požadavek a důvod pro selhání. Nyní může aplikace nákupního košíku brát záležitosti do svých vlastních rukou a může poskytnout uživatelsky příjemnou odpověď, jako je rada uživateli, aby vypustil část objednávky. Interakce s uživatelem je uchována spíše než vyjmuta. Tuto volbu použijte vždy s výstrahou. Je důležité koordinovat použití důvodů selhání v pravidlech autorizace se schopností aplikace služby interpretovat tuto informaci a odpovídat na ni. Nechcete náhodně vytvořit situaci, kdy je poskytnut přístup ke zdroji ovládanému aplikací, která přesně neodpovídá hlavičce AM_AZN_FAILURE.
166
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Konfigurace vyvolání dynamické ADI Pravidla mohou být zapsána, aby vyžadovala ADI (authorization decision information), kterou nelze nalézt v žádné informaci, ke které má služba autorizace produktu Tivoli Access Manager přístup. V těchto případech je nezbytné načíst ADI z vnějšího zdroje. Toto načtení může být v reálném čase provedeno pomocí službou vyvolání pojmenování dynamické ADI. Webová služba AMWebARS momentálně poskytnutá s WebSEAL Attribute Retrieval Service je jedním typem služby vyvolání pojmenování. ARS (Attribute Retrieval Service) poskytuje komunikaci a služby překladu formátu mezi knihovnou služby pojmenování plug-in programu a vnějším poskytovatelem informace o rozhodnutí o autorizaci. Následující diagram ilustruje průběh procesu pro webovou službu AMWEBARS:
Obrázek 11. Průběh procesu ARS (Attribute retrieval service)..
Průběh procesu: 1. Klient dává požadavek na zdroj chráněný pravidlem autorizace. 2. Program pro vyhodnocování pravidel autorizace —část služby autorizace— určuje, že je pro dokončení ověřování pravidla nutná informace ADI (authorization decision information). Požadovaná ADI není dostupná z pověření uživatele, služby autorizace nebo plug-in programu. 3. Webové službě AMWebARS je pomocí knihovny služby pojmenování odeslána úloha vyvolání ADI. Tato služba formátuje požadavek na ADI jako požadavek SOAP. Požadavek SOAP je odeslán přes HTTP do rozhraní WSDL (Web Service Description Language) webové služby AMWebARS. 4. Webová služba AMWebARS Web formátuje požadavek podle služby vnějšího profilování, která poskytuje ADI. 5. Služba vnějšího profilování vrací odpovídající ADI. 6. ADI je naformátována v jiném zásobníku SOAP a je vrácena službě pojmenování plug-in programu. Nyní má program pro vyhodnocování pravidel autorizace nezbytnou informaci k ověření pravidla a k rozhodnutí, zda přijmout nebo odmítnout původní požadavek klienta.
Kapitola 8. Vyvolání ADI (authorization decision information retrieval)
167
Informace o nasazení ARS (attribute retrieval service) naleznete v knize Tivoli Access Manager WebSEAL Administrator Guide.
Konfigurace plug-in programu pro použití webové služby AMWebARS Abyste nakonfigurovali plug-in program pro použití webové služby AMWebARS, proveďte následující úlohy: 1. V konfiguračním souboru pdwebpi.conf uveďte identifikační jméno (ID) služby načtení pojmenování dynamické ADI dotazované, když je během ověřování pravidel detekována chybějící ADI. V tomto případě je uvedena webová služba AMWebARS: [aznapi-configuration] dynamic-adi-entitlements-services = AMWebARS
2. V konfiguračním souboru pdwebpi.conf použijte ID služby načtení pojmenování nakonfigurované dynamické ADI jako parametr k určení odpovídající knihovny built-in, který formátuje požadavky odchozí ADI a zadržuje příchozí odpovědi: Například: [aznapi-entitlement-services] dynADI = azn_ent_amwebars
3. V konfiguračním souboru pdwebpi.conf uveďte URL do webové služby dynADI umístěné v prostředí WebSphere (zadáno jako jeden řádek): [amwebars] service-url = http://websphere_hostname:websphere_port \ /dynadi/dynadi/ServiceToIServicePortAdapter
4. Znovu spusťte plug-in program.
168
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Dodatek A. Použití pdbackup k zálohování dat pro plug-in Obslužný program pdbackup vám umožňuje zálohovat a obnovit data produktu Tivoli Access Manager. Obslužný program pdbackup používá jako argument soubor seznamu záloh, který uvádí soubory a adresáře požadované zálohováním. Každá hlavní komponenta produktu Tivoli Access Manager (jako Base, WebSEAL a plug-in) má vlastní soubor seznamu. Soubor pdinfo-pdwebpi.lst uvádí soubory a adresáře pro plug-in, které jsou obslužným programem pdbackup zálohovány. Tento dodatek popisuje jak použít obslužný program pdbackup k zálohování a obnově dat pro plug-in. Celý odkaz k obslužnému programu pdbackup je umístěn v produktu IBM Tivoli Access Manager Command Reference.
Funkčnost Zálohování dat pro plug-in Obslužný program pdbackup zálohuje seznam souborů a adresářů obsažený v souboru seznamu záloh pro plug-in, pdinfo-pdwebpi.lst.
UNIX: Předvolbou je soubor pdinfo-pdwebpi.lst umístěn v /opt/pdwebpi/etc/. Předvolbou je vyplývající zálohovací archivace uložena jako jednotlivý soubor .tar v /var/PolicyDirector/pdbackup. Předvolené jméno souboru .tar je vytvořeno pomocí jména souboru seznamu záloh a označení datem a časem: jméno-souboru-seznamu _ddmmyyy.hh_mm.tar
Například: pdinfo-pdwebpi.lst_30jul2003.10_39.tar
Volitelně můžete uvést: v Přizpůsobené jméno souboru pro soubor .tar (použijte volbu –file) Toto přizpůsobené jméno souboru neobsahuje označení datem a časem. v Přizpůsobené umístění adresáře pro soubor .tar (použijte volbu –path ) Obsah souboru .tar je vyjímán do následujících adresářů: opt/ var/ tmp/
Windows: Předvolbou je soubor pdinfo-pdwebpi.lst umístěn v C:\Program Files\Tivoli\PDWebpi\etc\ Předvolbou je vyplývající zálohovací archivace uložena jako stromový adresář v adresáři C:\Program Files\Tivoli\PDWebpi\pdbackup\. Předvolené jméno adresáře .dar je vytvořeno ze jména souboru seznamu záloh a označení datem a časem: jméno-souboru-seznamu _ddmmmyyyy.hh_mm.dar
© Copyright IBM Corp. 2000, 2003
169
Například: pdinfo-pdwebpi.lst_30jul2003.10_39.dar
Seznam souboru .dar je vyjímán so podadresáře a souboru: %C% Registr
Adresář %C% obsahuje kompletní strom zálohování. Jméno tohoto adresáře je určeno označením disku, kde jsou umístěny soubory a adresáře pro plug-in. Soubor registru ukládá klíče registru (přípony .reg). Volitelně můžete uvést: v Přizpůsobené jméno souboru pro archivaci souboru .dar (použijte volbu –file) Toto přizpůsobené jméno souboru neobsahuje označení datem a časem. v Přizpůsobené umístění adresáře pro archivaci souboru .dar (použijte volbu –path )
Obnova dat pro plug-in UNIX: Archivované soubory a adresáře jsou obnoveny ze souboru .tar do adresáře /opt/pdwebpi.
Windows: Archivované soubory jsou obnoveny do adresářů, kam byly původně nainstalovány.
Syntaxe Celý odkaz k obslužnému programu pdbackup je umístěn v produktu IBM Tivoli Access Manager Command Reference. pdbackup –zálohování –l jméno-cesty-seznamu-záloh \ [–path přizpůsobené-jméno-cesty][–file jméno-cesty-archivace] [–usage] [–?] pdbackup –obnova –souboru jméno-cesty-archivace \ [–path přizpůsobené-jméno-cesty] [–usage] [–?] Volba
Popis
– [backup|restore|extract]
Uvádí operace zálohování, obnovy nebo vyjmutí.
–l jméno-cesty-seznamu-záloh
Uvádí plně kvalifikovanou cestu k souboru seznamu záloh (pdinfo-pdwebpi.lst).
–path přizpůsobené-jméno-cesty
Pro zálohování uvádí přizpůsobené umístění adresáře archivace.
–file jméno-cesty-archivace
Pro zálohování uvádí přizpůsobené jméno pro soubor archivace. Pro obnovu uvádí plně kvalifikovanou cestu k souboru archivace, který se má obnovit.
Můžete použít krátké verze příkazu jmen volby, ale zkrácení musí být jednoznačné. Pro akci můžete například uvést a. Avšak hodnoty pro parametry těchto voleb nesmí být zkráceny.
170
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Příklady Příklady pro UNIX 1. Následující příklad provádí standardní zálohování s předvolenými hodnotami: pdbackup -a backup -l /opt/pdwebpi/etc/pdinfo-pdwebpi.lst
To se projeví v souboru pojmenovaném pdinfo-pdwebpi.lst_datum.čas.tar, který je uložen v adresáři /var/PolicyDirector/pdbackup. 2. Následující příkad provádí zálohování a ukládá předvolený soubor archivace v adresáři /var/backup: pdbackup -a backup -l /opt/pdwebpi/etc/pdinfo-pdwebpi.lst -path /var/backup
To se projeví v souboru pojmenovaném pdinfo-pdwebpi.lst_datum.čas.tar, který je uložen v adresáři /var/pdbackup. 3. Následující příklad provádí zálohování a vytváří soubor archivace pojmenovaný amwebarchive.tar: pdbackup -a backup -l /opt/pdwebpi/etc/pdinfo-pdwebpi.lst -file amwebarchive
Předvolená přípona archivace (.tar) je přidána do přizpůsobeného jména souboru amwebarchive. Tento soubor je uložen v předvoleném adresáři /var/PolicyDirector/pdbackup. 4. Následující příklad obnovuje soubor archivace z předvoleného umístění adresáře: pdbackup -a restore -file pdinfo-pdwebpi.lst_29Aug2003.07_24.tar
5. Následující příklad obnovuje soubor archivace z adresáře /var/pdback: pdbackup -a restore -file /var/pdback/pdinfo-pdwebpi.lst_29Aug2003.07_25.tar
Příklady pro Windows 1. Následující příklad provádí standardní zálohování s předvolenými hodnotami: pdbackup -a backup -l install_path\etc\pdinfo-pdwebpi.lst
To se projeví v souboru pojmenovaném pdinfo-pdwebpi.lst_datum.čas.dar, který je uložen v adresáři install_path\pdbackup pro plug-in. 2. Následující příklad provádí zálohování pomocí předvoleného jména souboru zálohování a ukládá soubor v adresáři C:\pdback: pdbackup -a backup -l install_path\etc\pdinfo-pdwebpi.lst -path c:\pdback
3. Následující příklad provádí zálohování a vytváří soubor pojmenovaný pdarchive.dar: pdbackup -a backup -l install_path\etc\pdinfo-pdwebpi.lst -file pdarchive
Předvolená přípona archivace (.dar) je použita pro přizpůsobené jméno souboru pdarchive. Tento soubor je uložen v předvoleném adresáři install_path\pdbackup. 4. Následující příklad provádí zálohování do adresáře \pdback na disku F:: pdbackup -a backup -l pdinfo-pdwebpi.lst -path f:\pdback
5. Následující příklad obnovuje soubor archivace z předvoleného adresáře (jednotlivý adresář zobrazený přes dva řádky): pdbackup -a restore -file install_path\pdbackup \pdinfo-pdwebpi.lst_29Jun2003.07_24.dar
6. Následující příklad obnovuje soubory z adresáře H:\pdbackup: pdbackup -a restore -file h:\pdbackup\pdinfo-pdwebpi.lst_29Jun2003.07_25.dar
Dodatek A. Použití pdbackup k zálohování dat pro plug-in
171
Obsah pdinfo-pdwebpi.lst [UNIX FILES] # plně kvalifikovaná jména souborů ./opt/pdwebpi/etc ./var/pdwebpi/audit ./var/pdwebpi/db ./var/pdwebpi/keytab ./var/pdwebpi/log [UNIX CONF FILES] # konfigurační soubory uvádějící soubor k zahrnutí # soubor:objekt stanza:volba /opt/pdwebpi/etc/pdwebpi.conf:uraf-ad:ad-server-config /opt/pdwebpi/etc/pdwebpi.conf:uraf-domino:domino-server-config /opt/pdwebpi/etc/pdwebpi.conf:ldap:ldap-server-config /opt/pdwebpi/etc/pdwebpi.conf:ldap:ssl-keyfile /opt/pdwebpi/etc/pdwebpi.conf:ldap:ssl-keyfile-stash /opt/pdwebpi/etc/pdwebpi.conf:failover:failover-cookies-keyfile /opt/pdwebpi/etc/pdwebpi.conf:ltpa:ltpa-keyfile /opt/pdwebpi/etc/pdwebpi.conf:ltpa:ltpa-stash-file /opt/pdwebpi/etc/pdwebpi.conf:iis:query-log-file /opt/pdwebpi/etc/pdwebpi.conf:iis:log-file /opt/pdwebpi/etc/pdwebpi.conf:iplanet:query-log-file [WINDOWS FILES] BASEDIR=SOFTWARE\Tivoli\Access Manager Plug-in for Web Servers:Path etc log audit db keytab [WINDOWS CONF FILES] # konfigurační soubory uvádějící soubor k zahrnutí # soubor:objekt stanza:volba etc/pdwebpi.conf:uraf-ad:ad-server-config etc/pdwebpi.conf:uraf-domino:domino-server-config etc/pdwebpi.conf:ldap:ldap-server-config etc/pdwebpi.conf:ldap:ssl-keyfile etc/pdwebpi.conf:ldap:ssl-keyfile-stash etc/pdwebpi.conf:failover:failover-cookies-keyfile etc/pdwebpi.conf:ltpa:ltpa-keyfile etc/pdwebpi.conf:ltpa:ltpa-stash-file etc/pdwebpi.conf:iis:query-log-file etc/pdwebpi.conf:iis:log-file etc/pdwebpi.conf:iplanet:query-log-file [WINDOWS REGISTRY] # uveďte klávesy k zálohování SOFTWARE\Tivoli
Další data zálohování Následující objekty stanza a parametry nejsou zobrazeny v souboru pdinfo-pdwebpi.lst a proto nejsou automaticky zálohovány. Pokud vyžadujete zálohování těchto dat, tak musíte editovat soubor pdinfo-pdwebpi.lst a přidat tuto informaci. Používejte formát popsaný na začátku souboru pdinfo-pdwebpi.lst. [cdsso-domain-keys] <jméno domény> = <soubor klíčů> [ecsso-domain-keys] <jméno domény> = <soubor klíčů>
172
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Dodatek B. pdwebpi.conf reference Produkt Tivoli Access Manager Plug-in for Web Servers se konfiguruje pomocí parametrů uvedených v konfiguračním souboru pdwebpi.conf. Soubor je umístěn v následujícím adresáři: UNIX: install_path/etc/
Windows: install_path\etc\
Dále jsou uvedeny popisy všech konfigurovatelných parametrů v konfiguračním souboru pdwebpi.conf. Parametry jsou v závislosti na jejich použití sdružovány do následujících tabulek: v obecné v autentizace v relace v LDAP v proxy v autorizační API v specifické pro webový server
Obecné parametry konfigurace Tabulka 26. Obecné parametry konfigurace Obecné Parametr
Popis
[pdweb-plugins] Definuje virtuální hostitele, které bude produkt Tivoli Access Manager Plug-in for Web Servers chránit a další globální nebo předvolené parametry konfigurace. virtual-host
Identifikace podřízených stanz, které obsahují informace o konfiguraci určitých virtuálních hostitelů.
web-server
Určuje typ používaného webového serveru. Přípustné hodnoty jsou: v iis pro Microsoft Internet Information Services v ihs pro IBM HTTP Server v iplanet pro Sun ONE (dříve iPlanet) Web Server v apache pro Apache Tento parametr se nastaví automaticky během instalace.
© Copyright IBM Corp. 2000, 2003
173
Tabulka 26. Obecné parametry konfigurace (pokračování) Obecné Parametr
Popis
windows-file-system
Dává najevo autorizačnímu serveru, že je nutné provést určitá předběžná opatření, aby bylo možné se vyvarovat bezpečnostních problémů souvisejících s URI, představujícími zdroje systému souborů. Je-li nastaven na true, pak všechny přístupy k URI s prvky cesty, jako např. krátké cesty ve Windows 2000, budou zakázány. Zvláště prvky cesty, končící znaky ~číslice budou zamítnuty. Pro operační systémy Windows je tento parametr nastaven na hodnotu true standardně. Pro operační systémy UNIX je tento parametr nastaven na false. Tento parametr může být potlačen na úrovni jednotlivých virtuálních hostitelů tak, že zadáte požadovanou hodnotu v odpovídající stanze [virtuální-hostitel].
case-sensitive
Sděluje autorizačnímu serveru, jak má pracovat s URI citlivými na velikost písma. Je-li nastaven na false, URI jsou převedena na malá písmena během vytváření odpovídajícího jména objektu produktu Tivoli Access Manager, o kterém má být vydáno rozhodnutí o autorizaci. Pro operační systémy UNIX je tento parametr nastaven na true. Pro operační systémy Windows je nastaven na false. Je-li parametr windows-file-system nastaven na hodnotu true a parametr case-sensitive není nadefinován, URI jsou standardně převedena na malá písmena. Všimněte si, že část jména objektu /PDWebPI/větev není takto přeložena. Tento parametr může být potlačen na úrovni jednotlivých virtuálních hostitelů tak, že zadáte požadovanou hodnotu v odpovídající stanze [virtuální-hostitel].
log-file
Určuje jméno souboru a cestu souboru protokolu, do kterého jsou zaznamenávány úlohy autorizačního serveru. Může být uveden jako absolutní nebo jako relativní název cesty.
logs
Určuje počet souborů protokolu, který se má vytvořit, než se znovu může použít první soubor protokolu.
log-entries
Určuje počet záznamů v protokolu, které je nutné zapsat, než se provede přesunutí do nového souboru protokolu.
mpa-enabled
Agenti MPA (Multiplexing Proxy Agents) jsou komunikační brány, které pojmou několik přístupů klientů. Vytvoří se jediný autentizovaný kanál k původnímu serveru a tímto kanálem jsou posílány všechny požadavky a odpovědi klientů. Je-li tento parametr nastaven na true, schopnost MPA je aktivována. Je-li tento parametr nastaven na false, schopnost MPA je zablokována. Tento parametr je možné přepsat na úrovni jednotlivých virtuálních hostitelů tak, že zadáte požadovanou hodnotu v odpovídající stanze [virtuální-hostitel].
174
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 26. Obecné parametry konfigurace (pokračování) Obecné Parametr mpa-protected-object
Popis Definuje objekt MPA, vůči kterému jsou prováděna rozhodnutí o autorizaci. Tento parametr je možné přepsat na úrovni jednotlivých virtuálních hostitelů tak, že zadáte požadovanou hodnotu v odpovídající stanze [virtuální-hostitel].
user
Na systémech s operačním systémem UNIX obsahuje tento parametr jméno uživatele, pod kterým jsou spuštěny procesy proxy a správce.
group
Na systémech s operačním systémem UNIX obsahuje tento parametr jméno skupiny, pod kterou jsou spuštěny procesy proxy a správce.
pre-410-compatible-tokens
Povoluje nebo zakazuje kompatibilitu mezi rozšířením tokenů ve verzi 4.1 produktu Tivoli Access Manager a tokeny verze 3.9 produktu Tivoli Access Manager. Je-li nastaven na hodnotu true, pak zabezpečení tokenu pro jednotné přihlášení pomocí e-community a vytváření failover cookies bude spolupracovat se šifrovacím schématem tokenů ve verzi 3.9 produktu Tivoli Access Manager. Tento parametr platí pro celý proces a nelze jej nastavit na úrovni virtuálního hostitele.
use-accept-language-header
Povoluje nebo zakazuje použití hlavičky HTTP accept-language při pokusu o nalezení jazyka pro generovanou odpověď HTML.
use-accept-charset-header
Povoluje nebo zakazuje použití hlavičky HTTP accept-charset při pokusu nalézt charset, ve kterém dekódovat prvky požadavku HTTP, nebo generovat odpověď HTML.
max-cached-http-body
Uvádí maximální množství dat těla HTTP, které bude použito pamětí cache pro libovolný poskytnutý požadavek. Pokud množství dat těla překročí konfigurované maximum, všechna data těla budou odložena.
send-p3p-header
Kontroluje, zda produkt Tivoli Access Manager Plug-in for Web Servers přidá, nebo nepřidá P3P hlavičku obsahující příkaz kompaktní politiky pro odpovědi HTTP, ve kterých nastavil cookie.
tag-value-prefix
Uvádí volitelný prefix přidaný do jmen atributu pověření použitých pro příznak/hodnotu hlaviček HTTP.
use-uri-encoded-session-id
Ovládá, zda by mělo či nemělo být ID relace uvedené v úloze administrativy ukončit relaci zakódováno pomocí URI.
Dodatek B. pdwebpi.conf reference
175
Tabulka 26. Obecné parametry konfigurace (pokračování) Obecné Parametr
Popis
remove-headers
Uvádí, zda libovolné hlavičky, které může modul hodnota-příznaku nastavit, by měly být odstraněny z požadavku před tím, než je hodnota-znaku zpracována. Odstraněním těchto hlaviček zajišťujete, že nemohou být vloženy agentem zlomyslného uživatele, aby porušily hodnoty odvozené od pověření. VAROVÁNÍ! ZABLOKOVÁNÍ SCHOPNOSTI ODSTRANIT HLAVIČKU MŮŽE ZPŮSOBIT VAŠEMU WEBOVÉMU SERVERU ZRANITELNOST ZABEZPEČENÍ. APLIKACE SPOLÉHAJÍCÍ NA HLAVIČKY HODNOTA-PŘÍZNAKU NEODSTRANĚNÉ Z POŽADAVKU PŘED JEJICH ZPRACOVÁNÍM MUSÍ BÝT ZNOVU ZAHRNUTY, ABYSTE SE VYVAROVALI MOŽNOSTI, ŽE BUDOU HLAVIČKY HTTP HODNOTA-PŘÍZNAKU PORUŠENY AGENTY ZLOMYSLNÉHO UŽIVATELE.
[module-mgr] Obsahuje podrobnosti pro správce proxy modulu. path
verify-step-up-user
Cesta obsahující modul souborů sdílených knihoven. Je povoleno zadat více než jeden záznam cesty, neboť plug-in program bude prohledávat všechny záznamy. Určuje, v události zvýšené operace, zda musí nové ID uživatele odpovídat libovolnému dříve existujícímu ID uživatele.
[wpiconfig] Obsahuje informaci, která je nastavená programem konfigurace, pro pomoc v odkongigurace. server-type
Nastaven během konfigurace, aby pomohl při odkonfigurování.
install-dir
Nastaven během konfigurace, aby pomohl při odkonfigurování.
vhosts
Nastaven během konfigurace, aby pomohl při odkonfigurování.
[user-agent] Vytváří mapování mezi agenty uživatele, jak je definováno hlavičkou HTTP agent-uživatele, a mezi určitou lokalitou. Formát je: vzor-agenta-uživatele = řetězec lokality
Parametry konfigurace autentizace Tabulka 27. Konfigurační parametry autentizace Autentizace Parametr
Popis
[modules] Deklaruje dostupné metody autentizace a přidružené knihovny. Formát je: jméno-modulu = jméno-sdílené-knihovny acctmgmt BA
176
Správa účtů Základní autentizace
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 27. Konfigurační parametry autentizace (pokračování) Autentizace Parametr cert failover forms fsso ip-addr iv-headers
Popis Certifikát Přepnutí při selhání Formuláře Jednotné přihlášení pomocí formátů IP adresa IV hlavičky
session-cookie
Cookie relace
ssl-id
ID relace SSL
tag-value
Hodnota příznaku
http-hdr
HTTP hlavička
token
Token
ltpa
LTPA Cookie
ecsso
Jednotné přihlášení pomocí e-Community
cdsso
Jednotné přihlášení pomocí Cross domain
login-redirect ntlm
Přesměrování po přihlášení NTLM
spnego
Security Provider Negotiation
web-log
Protokol webu
boolean rules
Pravidla pro Boolean
switch-user
Přepnout uživatele
dynurl
Dynamický URL
cred-refresh
Obnovení pověření
ext-auth-int
Vnější rozhraní autentizace
[common-modules] Obsahuje [common] modulovou konfiguraci. Stanza se skládá z formátu: typ-modulu = jméno-modulu. Podporující moduly zahrnují: Autentizace
Určuje politiku, která se má použít pro autentizaci uživatele.
Session
Určuje politiku, která se má použít pro udržování stavu relace.
Pre-authzn
Určuje politiky, které se mají použít pro libovolné zpracování nezbytné před autorizací uživatele.
Post-authzn
Určuje politiky, které se mají použít pro zpracování následující po autorizaci.
Response
Určuje politiky, které se mají použít pro libovolné zpracování odpovědí z webového serveru.
[authentication-levels]
Dodatek B. pdwebpi.conf reference
177
Tabulka 27. Konfigurační parametry autentizace (pokračování) Autentizace Parametr
Popis
Stanza [authentication-levels] definuje úrovně zvýšené autentizace stejně jako pořadí metod autentizace definovaných ve stanze [modules].Formát je: úroveň = jméno-modulu Politika autentizace je standardně na úrovni 1, pokud pro ni není nadefinován žádný záznam. Pořadí politik autentizace je určeno od nejvyšší úrovně autentizace po nejnižší úroveň autentizace podle pořadí, ve kterém jsou politiky autentizace nadefinovány. Pokud je úroveň autentizace sdílena několika politikami autentizace, pomocné pořadí se určuje podle pořadí, ve kterém se moduly objeví ve stanze [modules]. [authentication-mechanisms] passwd-cdas passwd-ldap passwd-uraf token-cdas cert-ssl cert-cdas http-request sso-create sso-consume passwd-strength cred-ext-attrs kerberosv5 ext-auth-interface failover-password cdsso su-password su-token-card su-certificate su-http-request su-cdsso
Seznam podporovaných a dalších mechanismů autentizace, včetně přidružených sdílených knihoven, které jsou vloženy do podsystému pro autentizaci produktu Tivoli Access Manager.
[sessions] Vyhlašuje předvolené hodnoty, které jsou společné pro všechny moduly pro relace. max-entries timeout inactive-timeout
Definuje maximální počet relací, uložených v rámci jedné instance modulu pro relace. Definuje maximální dobu trvání relace ve vteřinách. Definuje délku klidového intervalu ve vteřinách, která musí uplynout, než relaci vyprší časový limit.
resend-pdwebpi-cookies
Definuje, zda by měly být cookie pro Web Plug-In odeslány s každým požadavkem.
reauth-lifetime-reset
Pokud je hodnota yes, tak bude časovač doby trvání pověření vynulován po úspěšné opětovné autentizaci.
reauth-grace-period
Nastavuje dobu (ve vteřinách), po kterou klient může využít odklad, v rámci něhož může úspěšně provést opětovnou autentizaci, pokud jeho pověření nějakým způsobem skončila platnost.
[performance] Obsahuje různé volby konfigurce, které mohou pomoci v jemném ladění výkonu systému. enable-pop add-session-id-to-cred
178
Ovládá, zda jsou, či nejsou prosazeny politiky POP. Ovládá, zda bude či nebude ID relace přidáno do jejího pověření.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 27. Konfigurační parametry autentizace (pokračování) Autentizace Parametr
Popis
[user-agent] Vytváří mapování mezi agenty uživatele, jak je definováno hlavičkou HTTP agent-uživatele, a mezi určitou lokalitou. Podřizuje se formátu: vzor-agenta-uživatele = řetězec-lokace. [BA] basic-auth-realm
Deklaruje jméno sféry, které se objeví v dialogu, předloženému uživateli během přihlášení pomocí Základní autentizace. MUSÍ být uzavřeno dvojitými uvozovkami.
strip-hdr
Řídí odstranění BA hlaviček z požadavků. Platné hodnoty jsou: v ignore - nedělat nic s BA hlavičkou v always - odstranit BA hlavičku z požadavku v unauth - odstranit BA hlavičku z požadavků, pokud hlavička nebyla autentizována
add-hdr
Řídí přidání nové BA hlavičky do požadavku. Platné volby pro tento záznam jsou: v none - nepřidávat novou BA hlavičku do požadavku v gso - přidat BA hlavičku pro GSO do požadavku v supply - dodat do BA hlavičky statické jméno uživatele, nebo heslo, nebo obojí
gso-resource-name
Obsahuje jméno GSO zdroje, které se použije při vytváření BA hlaviček pro GSO. Uvedení hodnoty je volitelné, pokud add-hdr je nastaven na gso. Když add-hdr je nastaven na gso a gso-resource-name není nastaven, pak se použije jméno virtuálního hostitele obsluhujícího požadavek.
supply-password
Vyžaduje se hodnota, pokud add-hdr je nastaven na supply. Je-li nastaven, pak tento parametr udává statické heslo, které se má použít ve vytvářené BA hlavičce.
supply-username
Obsahuje statické jméno uživatele, které se má použít ve vytvářené BA hlavičce. Nastavení tohoto parametru je volitelní, pokud parametr add-hdr je nastaven na supply. Je-li nastaven parametr supply a parametr supply-username není nastaven (tj. zůstane zakomentován), pak se ve vytvářené BA hlavičce použije jméno autentizovaného uživatele.
[failover] Obsahuje všechny podrobnosti konfigurace pro autentizaci failover cookie a moduly postautorizace. failover-cookies-keyfile
Deklaruje cestu k souboru klíčů, který se používá k zašifrování a dešifrování dat pověření do failover cookie.
failover-cookies-lifetime
Platná doba trvání failover cookie v minutách.
enable-failover-cookie-for-domain failover-update-cookie
Aktivovat/zakázat failover cookie pro celý rozsah domény. Definuje, jak často je aktualizováno časové označení aktivity failover cookie. Pokud je nastaveno na 0, failover cookie bude aktualizována při každém požadavku. Pokud je nastaveno na pozitivní celé číslo, tak bude failover cookie aktualizována po uplynutí časového úseku v sekundách. Pokud je nastaveno na negativní celé číslo, tak bude failover cookie aktualizována při výskytu autentizace, nebo když je obnoveno pověření.
Dodatek B. pdwebpi.conf reference
179
Tabulka 27. Konfigurační parametry autentizace (pokračování) Autentizace Parametr
Popis
failover-require-lifetime-timestamp- Tyto záznamy určují, zda je pro úspěšnou autentizaci přepnutí při selhání vyžadováno ověření platnosti časového označení. validation Nastavení jsou: true: failover-require-activity-timestamp- false: validation
use-utf8
Časové označení je požadováno. Pokud chybí nebo je neplatné, autentizace přepnutí při selhání selže. Časové označení není vyžadováno, ale pokud existuje a je neplatné, tak autentizace přepnutí při selhání selže. Pokud plug-iny webu potřebují failover cookie generované dřívější verzí AMWebPI nebo AMWebSEAL, tato volba musí být použita pro obě položky.
Definuje, která znaková sada se použije pro zakódování failover cookie.
[failover-add-attributes]
Obsahuje konfiguraci, které atributy se mají do failover cookie přidat z původního pověření.
[failover-restore-attributes]
Obsahuje konfiguraci, které atributy se mají z failover cookie načíst do pověření, když uživatel provádí s její pomocí autentizaci.
[ltpa] Obsahuje všechny podrobnosti pro modul postautorizace založený na LTPA cookie. Tento modul je navržen, aby umožnil schopnost jednotného přihlášení pomocí serveru WebSphere. ltpa-keyfile
Úplná cesta souboru klíčů LTPA.
ltpa-stash-file
Umístění souboru pro uložení hesla.
ltpa-password
Heslo, které se má použít namísto souboru pro uložení.
ltpa-lifetime
Doba trvání (ve vteřinách) LTPA cookie.
[forms] Obsahuje všechny podrobnosti pro modul přihlášení na základě formulářů. login-form
Jméno souboru s formulářem pro přihlášení.
login-uri
URI, do kterého budou dodány podrobnosti o přihlášení. Podrobné informace o přihlášení musí být do tohoto URI dodány spolu se jménem uživatele uvedeným v atributu dat POST username a spolu s heslem uživatele uvedeným v atributu dat POST password.
create-ba-hdr
Provede boolean hodnoty pro indikování, zda by mělo být v hlavičce BA dodáno pro cílovou aplikaci jméno uživatele a heslo.
use-utf8
Indikuje, zda by měla být hlavička BA (pokud je vytvořena) zakódována pomocí UTF-8 nebo lokální kódové sady.Předvolená hodnota je true.
[fsso] Zobrazuje seznam formulářů přihlášení, které zastavit modulem Forms Single Sign On. login-page-stanza
Nahrává jméno jednoho nebo více objektů stanza obsahující podrobnosti o každém formuláři přihlášení, který se má zastavit.
[login-form-1]
180
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 27. Konfigurační parametry autentizace (pokračování) Autentizace Parametr
Popis
Formuláře přihlášení jsou označeny 2 fázovým zpracováním odpovídajícím vzoru. FSSO zastavuje všechna stránky odpovídající regulárnímu výrazu login-page. Formuláře přihlášení uvnitř těchto stránek jsou nalezeny porovnáváním atributu akce prvků formuláře HTML s regulárním výrazem login-form-action. login-page
Tento záznam konfigurace je umístěn v objektu stanza uvedeném parametrem login-page-stanza. Uvádí vzor používající regulární výraz, který jedinečně označuje požadavky pro stránku přihlášení aplikace, když používáte funkčnost jednotného přihlášení formuláře pro plug-in. Konfigurovaný vzor je porovnáván s URI požadavku.
login-form-action
Tento parametr je umístěn v objektu stanza uvedeném parametrem login-page-stanza. Uvádí vzor používající regulární výraz, který označuje, který formulář obsažený v zadržené stránce je formulář přihlášení aplikace, když používáte funkčnost jednotného přihlášení formuláře pro plug-in. Pokud vícenásobné formuláře odpovídají vzoru, tak se použije ten první.
argument-stanza
Tento parametr je umístěn v objektu stanza uvedeném parametrem login-page-stanza. Ukazuje na jiný předvolený objekt stanza, který zobrazuje seznam polí a dat vyžadovaných k dokončení formuláře přihlášení.
[auth-data] Obsahuje jeden nebo více záznamů formuláře: jméno = metoda:hodnota. Tento parametr je umístěn v objektu stanza uvedeném parametrem argument-stanza . jméno odpovídá jménu atributu vstupního prvku uvnitř formuláře pro přihlášení. metoda je cred, gso nebo řetězec. hodnota obsahuje řetězec interpretovaný v závislosti na hodnotě metody. [web-log] Obsahuje všechny podrobnosti pro modul uvádějící informaci, která se má zahrnout v přístupovém souboru protokolu pro webový server a pro SunONE, IHS a webové servery Apache, proměnná REMOTE_USER CGI. format-string
Řetězec formuláře, který je použit k vytvoření jména uživatele protokolu webu a pro SunONE, IHS a webové serveryApache, proměnná REMOTE_USER CGI.
unauth-user-string
Řetězec, který je použit k označení uživatele neautentizovaného správce přístupu (%u) uvnitř přístupového souboru protokolu pro webový server.
unauth-server-user-string
auth-type
Řetězec, který je použit k označení uživatele neautentizovaného webového serveru (%u) uvnitř přístupového souboru protokolu pro webový server. Řetězec formuláře pro uvedení typu autentizace pro ty webové servery, které umožňují s ní manipulovat. Jediný webový server, který tuto funkci podporuje je iPlanet.
[tag-value]
Dodatek B. pdwebpi.conf reference
181
Tabulka 27. Konfigurační parametry autentizace (pokračování) Autentizace Parametr cache-definitions
cache-refresh-interval use-utf8
use-uri-encoding
Popis Logická hodnota, která znamená, zda ukládat hodnoty příznaku, které byly připojeny k prostoru objektů, do paměti cache. Pokud jsou ukládány do paměti cache, nebude nutné znovu spustit proxy, aby zachytila změny v definicích příznak/hodnota. Interval obnovy (ve vteřinách) paměti cache pro definice. Definuje, která znaková sada se použije pro zakódování dat hodnoty příznaku. Pokud je hodnota nastavena na false, data hodnoty příznaku budou zakódována v lokální kódové stránce. Předvolená hodnota je true. Definuje, zda povolit pro hodnotu příznaku zakódování URI.
[token-card] Stránka pro přihlášení token-card. token-login-form
Jméno souboru pro stránku pro přihlášení pomocí tokenů.
next-token-form
Definuje formuláře, který se zobrazí uživateli klienta, aby požádal o další token. Klient je žádán, aby zadal další token, pokud server není schopen uživatele úspěšně autentizovat z prvního tokenu.
[http-hdr] Obsahuje všechny podrobnosti pro autentizační a relační modul hlavičky HTTP. header
Jméno hlavičky předávané CDAS (Cross Domain Authentication Service) serveru pro autentizaci.
[iv-headers] Obsahuje všechny podrobnosti pro autentizační a postautentizační modul IV-Headers. accept
Seznam hlaviček, které se budou přijímat jako potvrzení o autentizaci z proxy. Platné hodnoty jsou: v all - přijímá všechny typy hlaviček v iv-creds - informace o pověření klienta v iv-user - krátké jméno uživatele v iv-user-l - dlouhé jméno uživatele v iv-groups v iv-remote-address - IP adresa klienta v server-name
generate
Seznam hlaviček, které se budou vytvářet, bude-li požadavek přeposílán z proxy. Platné hodnoty jsou: v all - vygeneruje všechny typy hlaviček v iv-creds - informace o pověření klienta v iv-user - krátké jméno uživatele v iv-user-l - dlouhé jméno uživatele v iv-remote-address - IP adresa klienta
use-utf8
182
Definuje, zda by měly být iv-headers zakódovány v UTF-8, nebo lokální kódové sadě. Pokud plug-iny webu potřebují iv-headers generované dřívější verzí AMWebPI nebo AMWebSEAL, tato volba musí být nastavena na false.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 27. Konfigurační parametry autentizace (pokračování) Autentizace Parametr server-name-header
Popis Jméno hlavičky, která se má použít, když je server-name prezentováno v seznamu hodnot k vygenerování. Předvolená hodnota je iv-server-name.
[acctmgmt] Obsahuje data pro postautorizační modul správce účtu. Tento modul je odpovědný za oparace jako změna uživatelova hesla a odhlašování. password-change-form
Formulář, který se zobrazí uživateli, když uživatel požádá o změnu hesla.
password-change-form-uri
URI, ke kterému se přistoupí, když uživatel požádá o změnu hesla.
password-change-uri
Cíl URI po změně hesla.
password-change-success
Stránka, která se zobrazí, když uživatel úspěšně dokončí změnu hesla.
password-change-failure
Stránka, která se zobrazí, když se uživateli nepodaří úspěšně změnit heslo.
logout-uri help-uri help-page logout-success
Cíl URI po odhlášení uživatele. Umístění stránky nápovědy. Jméno souboru stránky nápovědy, která se zobrazí, když uživatel požádá o nápovědu. URI nebo soubor, který se uživateli zobrazí, když se uživatel úspěšně odhlásí.
[ecsso] Jednotné přihlášení pomocí e-Community. Jméno stanzy musí odpovídat modulovému jménu pro pdwpi-ecsso-module definovanému ve stanze [modules]. Pro správné zacházení s URI odhlášení (předvoleně /pkmslogout) s ohledem na e-Community Single Sign-On, musí být předautorizační modul ecsso konfigurován dříve nežpředautorizační modul acct-mgmt . e-community-name
Jméno e-community, které se objeví ve vouch-for tokenech a požadavcích.
is-master-authn-server
Určuje, zda je server hlavním serverem v e-community nebo ne. Je-li nastaven na yes, pak tento server přijímá ″vouch-for for″ požadavky od ostatních instancí plug-in programu, jejichž klíče domén jsou uvedeny v seznamu ve stanze [ecsso-domain-keys].
master-authn-server
Jméno hlavního serveru v e-community. Tento parametr je povinný, je-li is-master-authn-server nastaven na hodnotu no.
master-http-port
Uvádí port (jiný než standardní port 80), na kterém hlavní autentizační server očekává HTTP požadavky. Tento parametr se ignoruje, pokud je daný server hlavním autentizačním serverem.
master-https-port
Uvádí port (jiný než standardní port 443), na kterém hlavní autentizační server očekává HTTPS požadavky. Tento parametr se ignoruje, pokud je daný server hlavním autentizačním serverem.
vf-token-lifetime
Doba trvání ″vouch-for for″ tokenu ve vteřinách.
vf-url
″Vouch-for″ URL.
Dodatek B. pdwebpi.conf reference
183
Tabulka 27. Konfigurační parametry autentizace (pokračování) Autentizace Parametr
Popis
allow-login-retry
Povoluje nebo zakazuje uživateli se znovu pokusit o přihlášení, když byl neautentizovaný uživatel přesměrován na hlavní autentizační server, aby se zde autentizoval. Je-li nastaven na hodnotu true, pak hlavní autentizační server dovolí uživatelům znovu zadat jejich jméno uživatele/heslo, když jejich první pokus selhal. Je-li nastaven na hodnotu false, pak je uživatel přesměrován zpět na podřízený server, aniž by hlavní autentizační server za tohoto uživatele ručil.
vf-argument
Jméno parametru vouch-for tokenu, jak se objeví ve vouch-for odpovědi.
use-utf8
Povoluje nebo zakazuje řetězec utf8 v závislosti na vouch-for tokenech ECSSO a e-community cookies.
[ecsso-token-attributes] nebo [ecsso_module_name-token-attributes:virtual_host] domain_name = pattern1, pattern2, ... Uvádí atributy pověření, které se mají zahrnout ve vouch-for pattern n tokenech eCSSO. [ecsso-incoming-attributes] nebo [ecsso_module_name-incoming-attributes] attribute_pattern = preserve|refresh
Uvádí atributy pověření z příchozích vouch-for tokenů, které se mají přijmout, a ty, které se mají zamítnout.
[ecsso-domain-keys] Definuje klíče, které se mají používat při komunikaci s ostatními účastníky z uvedených domén v rámci e-community. Jméno této stanzy je odvozeno od jména modulu propdwpi-ecsso-module , nadefinovaného ve stanze [modules] .Je ve tvaru [ecsso-module-name-domain-keys]. Formát is:domain-name = key-file [cdsso] uri
Speciální uri indikující přesměrování CDSSO a jednotné přihlášení.
cdsso-argument
Jméno parametru dotazového řetězce uvádějícího token autentizace. Je použito v uri přesměrování.
authtoken-lifetime
Doba trvání tokenu autentizace ve vteřinách.
use-utf8
Ovládá zakódování řetězů v tokenu CDSSO. Tato volba ovlivní pouze tokeny CDSSO vytvořené a použité předvolenými SSO knihovnami vytvoření a použití. Standardně jsou tokeny kódovány v UTF-8.
[cdsso-token-attributes] Definuje sady atributů, které se mají zahrnout v CDSSO autentizačních tokenech, uvedených v základnách per-peer nebo per-domain. Toto zpracování se provede pouze, pokud se používají předvolené SSO knihovny vytvoření a použití tokenu. Formát těchto záznamů je: domain-name = pattern-1, pattern-2, ... pattern-n [cdsso-incoming-attributes] Definuje sady atributů, které se mají přijmout nebo zamítnout z příchozích CDSSO autentizačních tokenů. Formát záznamů v této stanze je: attribute pattern=preserve | refresh [cdsso-domain-keys] Definuje klíče, které se mají používat při komunikaci s ostatními účastníky z uvedených domén v rámci e-community. Formát je: jméno-domény = soubor-klíčů Jméno této stanzy je odvozeno od jména modulu propdwpi-ecsso-module , nadefinovaného ve stanze [modules] .Je ve tvaru [ecsso-module-name-domain-keys].
184
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 27. Konfigurační parametry autentizace (pokračování) Autentizace Parametr
Popis
[login-redirect] Obsahuje všechny podrobnosti pro postautorizační modul přesměrování přihlášení. Aby tento modul pracoval správně, MUSÍ být konfigurován před předautorizačním modulem správy účtu. redirect-uri
URI, na které je uživatel přesměrován po úspěšné autentizaci.
[spnego] spnego-krb-service-name spnego-krb-keytab-file
Ukládá jméno služby, pro kterou server AMWebPI ověřuje identitu během inicializace autorizačního modulu spnego. Název cesty konfiguračního souboru Kerberos.
[ntlm] use-pre-windows-2000-logon-name Dovoluje, aby přihlašovací jméno dřívější verze než Windows 2000 reprezentovalo v produktu Tivoli Access Manager autentizovaného uživatele. Toto je část přihlašovacího jména DOMAIN/USERNAME reprezentující jméno uživatele. [web-server-authn] use-pre-windows-2000-logon-name Dovoluje, aby přihlašovací jméno dřívější verze než Windows 2000 reprezentovalo v produktu Tivoli Access Manager autentizovaného uživatele. Toto je část přihlašovacího jména DOMAIN/USERNAME reprezentující jméno uživatele. [boolean-rules] Mění způsob, kterým pravidla autorizace pro boolean ovlivňují výsledek rozhodnutí o přístupu. pass-on-rule-failure-reason
Nastavte na předvolbu false nebo vynechejte, pokud pravidla autorizace vrací !FALSE!, tak bude požadavek zamítnut. Nastavte na true, avšak, pokud pravidla autorizace vrací !FALSE! a existuje řetězec odpovědný za selhání přidružený k objektu pravidel v databázi politiky, tak bude přístup umožněn s řetězcem odpovědným za selhání vloženým do požadavku HTTP v hlavičce AM_AZN_FAILURE.
[http-method-perms] Definuje oprávnění požadovaná k provedení požadavku pomocí metody partikulárníHTTP. <default>
Definuje oprávnění požadovaná pro libovolné metody, které nejsou explicitně uvedené ve stanze. Záznam<default> sám o sobě nemá předvolenou hodnotu a musí být ve stanze uveden jako neprázdný objekt.
[ext-auth-int] Umožňuje, aby byla pověření vytvářena na základě informace dodané back-end aplikací. auth-url
URL, do kterého je uživatel přesměrován, když je spouštěcí impuls autentizace proveden kvůli konfigurované bezpečnostní politice.
trigger-url
URL, které se použije pro naznačení, že pro vygenerování pověření by měla být použita odpověď.
redirect-url-hdr-name pac-hdr-name pac-svc-id-hdr-name user-id-hdr-name user-auth-level-hdr-name user-qop-hdr-name user-ext-attr-list-hdr-name
Tyto záznamy obsahují jména hlaviček odpovědí, které se použijí ve vygenerování pověření.
Dodatek B. pdwebpi.conf reference
185
Tabulka 27. Konfigurační parametry autentizace (pokračování) Autentizace Parametr
Popis
[switch-user] switch-user-form
Uvádí jméno HTML souboru, který je vrácen klientovi v odpovědi na ’su’.Soubor by se měl nalézat v adresáři, /opt/pdwebpi/nls/html/lang/charset.
switch-user-uri
Uvádí jméno URI použité k vyvolání přepnutí funkce uživatele.
switch-user-post-uri
Uvádí URI, jehož formulář ’su’ je zadán.
[dynurl] Uvádí definice pro předautorizační modul dynamického URL. Formát je: objekt = vzor
Konfigurační parametry relace Tabulka 28. Konfigurační parametry relace Relace Parametr
Popis
max-entries
Maximální počet relací, uložených v rámci jedné instance modulu pro relace. Maximální počet relací na jeden modul pro relace na jednoho virtuálního hostitele.
[sessions]
timeout
Maximální doba trvání relace ve vteřinách.
inactive-timeout
Délka klidového intervalu ve vteřinách, která musí uplynout, než relaci vyprší časový limit.
resend-pdwebpi-cookies
Povoluje nebo zakazuje posílání cookies webového plug-in programu s každým požadavkem.
reauth-lifetime-reset
Řídí časovač doby trvání relace. Je-li nastaven na yes, pak časovač doby trvání relace (tj. hodnota nastavená v parametru timeout) je znovu nastavena po dokončení úspěšné opětovné autentizace. Je-li nastaven na no, pak se znovunastavení po úspěšné opětovné autentizaci neprovede.
reauth-grace-period
Nastavuje dobu (ve vteřinách), po kterou klient může využít odklad, v rámci něhož může úspěšně provést opětovnou autentizaci, pokud jeho pověření nějakým způsobem skončila platnost.
[session-cookie] use-same-session
Uvádí, zda protokoly HTTP a HTTPS budou používat stejnou relaci, nebo ne.
[cred-refresh] Obsahuje informace o konfiguraci, pro kterou se mají uchovat atribututy z původního pověření, a která se má při provádění obnovovací operace obnovit do nového pověření.
186
preserve
Definuje atributy, které se mají uchovat z původního uživatelského pověření.
refresh
Definuje atributy, které se mají obnovit do nového pověření.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Konfigurační parametry LDAP Tabulka 29. Konfigurační parametry LDAP LDAP Parametr
Popis
[ldap] bind-pwd
Heslo pro Web Plug-in Daemon (nastaveno během konfigurace).
ssl-enabled
Indikuje, zda je povoleno SSL.
ssl-keyfile
Indikuje cestu/jméno souboru klíčů SSL.
ssl-keyfile-dn
Indikuje návěští certifikátu v klíčovém souboru SSL (pokud nějaké existuje).
ssl-keyfile-pwd
Indikuje heslo klíčového souboru SSL.
cache-enabled
Povolit nebo zakázat lokální paměť cache LDAP.
ldap-server-config
Umístění souboru ldap.conf.
auth-using-compare
Indikuje, zda provést autentizaci pomocí spojení nebo porovnání hesel LDAP.
prefer-readwrite-server
Indikuje, zda, když je dostupný, vybrat zapisovatelný server LDAP.
bind-dn
Indikuje Distinguished Name pro démona.
default-policy-override-support
Musí mít hodnotu yes nebo no. Pokud má hodnotu yes, nebude kontrolována žádná uživatelská metoda, je kontrolována pouze předvolená uživatelská metoda (ukládá některé vyhledávače LDAP).
user-and-group-in-same-suffix
Indikuje, zda jsou skupiny definovány ve stejné příponě LDAP jako uživatel.
Konfigurační parametry proxy Tabulka 30. Konfigurační parametry proxy Proxy Parametr
Popis
id
Uvádí ID nebo jméno souboru sdílené paměti pro rozhraní proxy. ID musí odpovídat informaci, kteoru používá plug-in program.
[proxy-if]
number-of-workers worker-size cleanup-interval max-session-lifetime
Počet pracovních vláken, které obsluhují požadavky plug-in programu. Množství paměti, předem alokované pro každé pracovní vlákno, které obsluhuje požadavky plug-in programu. Doba (ve vteřinách) mezi dvěma následujícími vyčištěními paměti. Doba (ve vteřinách), po kterou plug-in program bude čekat na odpověď z autorizačního serveru. Po jejím uplynutí bude relace přerušena.
[proxy]
Dodatek B. pdwebpi.conf reference
187
Tabulka 30. Konfigurační parametry proxy (pokračování) Proxy Parametr
Popis
error-page
Cesta ke stránce, která se zobrazí v uživatelově prohlížeči, pokud se objeví neočekávaná chyba serveru.
acct-locked-page
Cesta ke stránce, která se zobrazí v uživatelově prohlížeči, když se uživatel pokusí přistoupit k uzamčenému účtu.
retry-limit-reached-page
Cesta ke stránce zobrazené, když je dosaženo maximálního počtu selhaných přihlášení. Maximální počet povolených selhání při přihlášení je nastaven na serveru LDAP pomocí příkazu policy.
login-success
Uvádí stránku, která se zobrazí, když plug-in program nemá stránku, na kterou by uživatele přesměroval po úspěšném přihlášení pomocí formulářů nebo tokenů. Tato situace může nastat tehdy, když vytvoříte svůj formulář pro přihlášení, které odešle POST data přihlášení přímo plug-in programu.
Konfigurační parametry autorizačního API Tabulka 31. Konfigurační parametry autorizačního API Autorizační API Parametr
Popis
[aznapi-configuration] Parametry a konfigurace auditu a protokolování. logsize
Velikost (v bajtech), po jejímž dosažení se vytvoří nový soubor protokolu. Je-li nastaven na 0, nový soubor protokolu se nevytvoří. Je-li nastaven na záporné číslo, vytvoří se nový soubor protokolu bez ohledu na velikost předchozího souboru.
logflush
Interval (ve vteřinách), ve kterém jsou protokoly zarovnány. Maximální hodnota je 21600 (6 hodin).
logaudit
Povolí nebo zakáže protokolování auditu.
auditlog
Jméno souboru auditu.
auditcfg
Povolí nebo zakáže prověřovací záznamy pro danou komponentu. Platné hodnoty jsou: authn - Zachycuje události týkající se autentizace. azn - Zachycuje události týkající se autorizace.
db-file cache-refresh-interval listen-flags
188
Umístění souboru paměti cache databáze ACL. Interval (ve vteřinách) mezi dvěma kontrolami pro aktualizaci hlavního autorizačního serveru. Povoluje nebo zakazuje příznaky pro přijímání upozornění o aktualizaci paměti cache pro politiky.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 31. Konfigurační parametry autorizačního API (pokračování) Autorizační API Parametr
Popis
policy-cache-size
Maximální velikost paměti cache pro metodu. Tato hodnota kontroluje, kolik informací je uchováno v paměti cache. Velikost je uvedena jako počet záznamů.
resource-manager-provided-adi
Uvádí definice prefixu pro vyvolání informace o rozhodnutí o autorizaci z požadavku HTTP. Hodnoty přidružené k tomuto parametru by neměly být měněny.
input-adi-xml-prolog
Prolog, který se má přidat na začátek dokumentu XML vytvořeného pomocí ADI (Access Decision Information) potřebné k zhodnocení autorizačních pravidel pro Boolean.
xsl-stylesheet-prolog
Prolog, který se má přidat na začátek stylesheetu XSL vytvořeného pomocí textu XSL, který definuje autorizační pravidla pro Boolean.
dynamic-adi-entitlement-services
Tento paramatr uvádí seznam ID konfigurované služby pojmenování, která jsou dotazována jádrem pravidel pokud je chybějící ADI detekováno během zhodnocování autorizačních pravidel. Zde vypsané služby pojmenování musí být přidány k příchozím a odchozím specifikacím pro službu vyvolání dynamického ADI, která je popsána v publikaci Authorization Programmer’s Guide. Když je během zhodnocování zjištěno, že chybí ADI, každá služba v konfigurovaném seznamu je dotazována popořadě. Tyto záznamy musí odkazovat na existující služby pojmenování, které byly zavedeny pomocí záznamů služby v konfigurační stanze nebo inicializačním atributu služby pojmenování.
cred-attribute-entitlement-services
Seznam ID konfigurované služby pojmenování, který bude volán během vytváření pověření k poskytnutí atributů, které se mají do pověření vložit.
[aznapi-entitlement-services] Definice služby autorizačního API. id-služby
Každý záznam stanzy definuje jiný typ služby aznAPI. Podrobnější informace najdete v knize IBM Tivoli Access Manager Authorization C API Developer’s Reference.
AZN_ENT_EXT_ATTR
Toto je parametr na úrovni systému, který by neměl být měněn. Umožňuje používání rozšířených atributů prostoru objektů.
Konfigurační parametry specifické pro daný webový server Tabulka 32. Konfigurační parametry specifické pro daný webový server Specifické pro webový server Parametr
Popis
[p3p-header] Uvádí kompaktní politiku P3P použitou pro nastavení všech HTTP cookies.
Dodatek B. pdwebpi.conf reference
189
Tabulka 32. Konfigurační parametry specifické pro daný webový server (pokračování) Specifické pro webový server Parametr p3p-element
Popis Tento parametr se může použít k uvedení odkazu na plnou politiku XML v dodatku ke kompaktní politice konfigurované pomocí jiných parametrů v této stanze. Nevysvětlení řádky p3p-element = policyref="/w3c/p3p.xml" odkazuje plug-in na plnou politiku XML.
access
Uvádí přístup, který má uživatel k informaci obsažené uvnitř a odkazované pomocí cookie. Možné hodnoty: none all nonident contact-and-other ident-contact other-ident
disputes
Uvádí, zda plná metoda P3P obsahuje nějakou informaci s ohledem na rozepře s informací obsaženou v cookie. Platné hodnoty jsou true nebo false. Tento parametr je standardně zakázán.
remedies
Uvádí možné nápravy rozepří. Možné hodnoty jsou: correct money law Pokud není uvedeno, není v metodě obsažena žádná informace nápravy.
non-identifiable
190
Pokud je nastaveno na true, tento parametr uvádí, že žádná informace v cookie nebo informace odkazovaná pomocí cookie nikdy osobně neidentifikuje uživatele. Platné hodnoty jsou true nebo false. Tento parametr je standardně zakázán.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 32. Konfigurační parametry specifické pro daný webový server (pokračování) Specifické pro webový server Parametr purpose
Popis Uvádí smysl informace v cookie a informace odkazované pomocí cookie. Možné hodnoty jsou: current admin develop tailoring pseudo-analysis pseudo-decision individual-analysis individual-decision contact historical telemarketing a other-purpose. Pro všechny hodnoty s výjimkou current může být konfigurován dodatečný specifikátor. Možné hodnoty jsou: always opt-in opt-out. Pro neuvedené smysly je předvolenou hodnotou always. Tato hodnota je uvedena po smyslu a je oddělena pomocí dvojtečky, například: purpose = contact:opt-in
recipient
Uvádí příjemce informace v cookie a informaci odkazovanou pomocí cookie. Možné hodnoty jsou: ours delivery same unrelated public other-recipient.
retention
Uvádí, jak dlouho je zadržena informace v cookie nebo informace odkazovaná pomocí cookie. Možné hodnoty jsou: no-retention stated-purpose legal-requirement business-practices indefinitely.
Dodatek B. pdwebpi.conf reference
191
Tabulka 32. Konfigurační parametry specifické pro daný webový server (pokračování) Specifické pro webový server Parametr
Popis Uvádí typ informace uložené v cookie a informace odkazované pomocí cookie.
categories
Pokud je neidentifikovatelný parametr je nastaven na true, pak nemusí být konfigurovány kategorie. Možné hodnoty jsou: physical online uniqueid purchase financial computer navigation interactive demographic content state political health preference location government other-category [ihs] query-contents
query-log-file doc-root
Určuje program query contents, který se používá pro procházení webovým prostorem IBM HTTP Serveru pomocí příkazu ’pdadmin> object list’. Tento parametr je možné přepsat na úrovni větve uvedením hodnoty pro tento parametr ve stanze [ihs:větev], např. [ihs:/PDWebPI/foo.com] Umístění souboru protokolu pro chyby, na které narazil program query contents. Určuje kořen dokumentace, který poskytuje schopnost procházet webovým prostorem, která je nezbytná pro provádění příkazů ’pdadmin> object list’. Tento parametr je nastaven obslužným programem pro konfiguraci během nastavení virtuálních hostitelů - je definován na úrovni větve politiky ve stanze [ihs:větev], např. [ihs:/PDWebPI/foo.bar.com]
[apache]
192
query-contents
Určuje program query contents, který se používá pro procházení webovým prostorem Apache HTTP Serveru pomocí příkazu ’pdadmin> object list’. Tento parametr je možné přepsat na úrovni větve uvedením hodnoty pro tento parametr ve stanze [apache:větev], např. [apache:/PDWebPI/lotus.com]
query-log-file
Umístění souboru protokolu pro chyby, na které narazil program query contents.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 32. Konfigurační parametry specifické pro daný webový server (pokračování) Specifické pro webový server Parametr
Popis Určuje kořen dokumentace, který poskytuje schopnost procházet webovým prostorem, která je nezbytná pro provádění příkazů ’pdadmin> object list’. Tento parametr je nastaven obslužným programem pro konfiguraci během nastavení virtuálních hostitelů - je definován na úrovni větve politiky ve stanze [apache:větev], např. [apache:/PDWebPI/lotus.com]
doc-root
[iis] query-contents
query-log-file
Určuje program query contents pro procházení webovým prostorem IIS pomocí pdadmin. Tento parametr je možné přepsat na úrovni větve uvedením hodnoty pro tento parametr ve stanze [iis:větev], např. [iis:/PDWebPI/foo.bar.com] Umístění souboru protokolu pro chyby, na které narazil program query contents.
log-file
Definuje soubor protokolu pro chybové a trasovací zprávy z IIS plug-in programu. Tyto zprávy se ukládají odděleně od souboru protokolu autorizačního serveru, aby byla zajištěna konzistence těchto souborů. Je-li zadán jako relativní cesta, pak je umístění relativní k podadresáři s protokoly instalačního adresáře. Je-li zadán jako absolutní cesta, použije se absolutní cesta.
use-error-pages
Ovládá, zda jsou konfigurované stránky IIS pro chybový kód odesílány zpátky klientovi, nebo zda jsou místo nich zpět odesílány klientovi některé jednoduše postavené stránky.
[iplanet] Konfigurační parametry určité pro produkt Tivoli Access Manager iPlanet Web Server Plug-in. query-contents
query-log-file doc-root
Určuje program query contents pro procházení webovým prostorem Sun ONE (iPlanet) pomocí pdadmin. Tento parametr je možné přepsat na úrovni větve uvedením hodnoty pro tento parametr ve stanze [iplanet:větev], např. [iplanet:/PDWebPI/foo.bar.com] Umístění souboru protokolu pro chyby, na které narazil program query contents. Určuje kořen dokumentace, který poskytuje schopnost procházet webovým prostorem, která je nezbytná pro provádění příkazů ’pdadmin> object list’. Tento parametr je nastaven obslužným programem pro konfiguraci během nastavení virtuálních hostitelů - je definován na úrovni větve politiky ve stanze [iplanet:větev], např. [iplanet:/PDWebPI/foo.bar.com]
Dodatek B. pdwebpi.conf reference
193
194
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Dodatek C. Stručná reference pro moduly Autentizace je způsob, jak identifikovat jednotlivé procesy nebo jednotky, které se pokouší přihlásit se do zabezpečené domény. Politika autentizace, pomocí které se jedinec nebo proces pokouší přistoupit do domény chráněné plug-in programem, může mít mnoho tváří. Produkt IBM Tivoli Access Manager Plug-in for Web Servers podporuje řadu politik autentizace. Tyto politiky autentizace jsou spolu s příslušnými popisy vypsány v následujících tabulkách. Tabulka 33. Reference pro politiky/moduly autentizace plug-in programu Politika/modul autentizace BA pdwpi-ba-module
Popis Modul autentizace pro Základní autentizaci. Může být také nakonfigurován jako modul pro relace a modul pro zpracování následující po autorizaci.
forms pdwpi-forms-module
Modul autentizace pomocí HTML formulářů. Provádí autentizaci pomocí jména uživatele a hesla, které byly dodány prostřednictvím formuláře. Pokud se používá, musí být tento modul také nakonfigurován jako modul pro zpracování následující po autorizaci.
ip-addr pdwpi-ipaddr-module
Modul autentizace pomocí IP adresy klienta. Poskytuje autentizaci založenou výhradně na IP adrese klienta. Zákazník musí poskytnout mechanismus autentizace pomocí HTTP požadavku, aby bylo možné namapovat informaci o IP adrese na objekt produktu Tivoli Access Manager. Může být také nakonfigurován jako modul pro relace.
http-hdr pdwpi-httphdr-module
Modul autentizace pomocí HTTP hlavičky. Poskytuje autentizaci založenou výhradně na hodnotě navržené HTTP hlavičky v požadavku. Zákazník musí poskytnout mechanismus autentizace pomocí HTTP požadavku, aby bylo možné namapovat informace uvedené v hlavičkách na objekt produktu Tivoli Access Manager. Může být také nakonfigurován jako modul pro relace.
token pdwpi-token-module
Modul autentizace pomocí tokenu. Produkt Tivoli Access Manager Plug-in for Web Servers podporuje autentizaci pomocí token passcode, dodávaného klientem. Tato autentizace používá dvoufaktorové přihlášení založené na RSA SecureID fobs. Pokud se používá, musí být tento modul také nakonfigurován jako modul pro zpracování následující po autorizaci.
© Copyright IBM Corp. 2000, 2003
195
Tabulka 33. Reference pro politiky/moduly autentizace plug-in programu (pokračování) Politika/modul autentizace cert pdwpi-certificate-module
Popis Modul autentizace pomocí certifikátu klienta. DN certifikátu klienta uvedené v předmětu žádosti je namapováno pomocí mechanismu autentizace cert-ssl na jméno objektu produktu Tivoli Access Manager. Mechanismus autentizace cert-ssl vyžaduje, aby DN certifikátu klienta uvedené v předmětu žádosti bylo přímo namapováno na DN uživatele produktu Tivoli Access Manager v registru uživatelů. Tento modul ignoruje požadavky na autentizaci, které nebyly přijaty prostřednictvím relace SSL a nemohou být tedy bezpečně nakonfigurovány pro virtuální hostitele, kteří obsluhují autorizaci HTTP i HTTPS požadavků.
failover pdwpi-failovercookie-module
Modul autentizace pomocí failover cookie. Tento modul přijímá failover cookie, aby mohl provést autentizaci uživatele. Pokud se používá, musí být tento modul také nakonfigurován jako modul pro zpracování následující po autorizaci.
iv-headers pdwpi-iv-headers-module
Modul autentizace pomocí IV hlaviček Poskytuje autentizaci založenou na hodnotách HTTP hlavičky iv-user, iv-user-l, iv-creds, nebo iv-remote-address v požadavku. Tento způsob je vhodný pro jednotné přihlášení do produktu Tivoli Access Manager Plug-in for Web Servers, byl-li již uživatel autentizován na předřazeném proxy serveru. Aby byl požadavek ověřený, musí tento požadavek přijít prostřednictvím autentizované relace s předřazeným proxy serverem (například přes spojení WebSEAL). Proxy se musí autentizovat jako uživatel s oprávněním Proxy [PDWebPI]p) na větvi prostoru chráněných objektů virtuálního hostitele, ke kterému chce přistoupit. Pro autentizaci pomocí hlavičky iv-remote-address musí zákazník poskytnout mechanismus autentizace pomocí HTTP požadavku, aby bylo možné namapovat informaci o IP adrese na objekt produktu Tivoli Access Manager. Tento modul se může také nakonfigurovat jako modul pro zpracování následující po autorizaci a modul pro relaci.
ecsso pdwpi-ecsso-module
Modul autentizace pomocí jednotného přihlášení e-community Tento modul musí být nakonfigurován jako modul autentizace pro virtuální hostitele, kteří nejsou hlavním autentizačním serverem, a kteří se podílejí na e-community. Pokud se používá, musí být tento modul také nakonfigurován jako předautorizační modul.
unauth pdpwi-unauth-module
Modul autentizace pomocí neautentizovaného uživatele. Tento modul je zde vypsán proto, aby byl seznam úplný. Je implicitně vždy nakonfigurován jako modul autentizace s nejnižším pořadím a používá se pro vygenerování pověření pro neautentizované uživatele.
196
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 33. Reference pro politiky/moduly autentizace plug-in programu (pokračování) Politika/modul autentizace ltpa pdwpi-ltpa-module
Popis Modul autentizace pomocí LTPA cookies. Přijímá LTPA cookie a na jejich základě autentizuje uživatele. LTPA cookie může poskytnou buď server WebSEAL, nebo server WebSphere.
spnego pdwpi-spnego-module
Modul autentizace pomocí SPNEGO. Využívá standardní protokol pro autentizaci pomocí SPNEGO, který se používá v doménách LAN na platformě Windows, a pomocí kterého je možné nastavit řešení pro jednotné přihlášení pro implementace plug-in programu na platformě serverů IIS.
cdsso pdwpi-cdsso-module
Modul autentizace pomocí CDSSO. Dovoluje jednotné přihlášení přes domény mezi různými doménami.
ext-auth-int pdwpi-ext-auth-int -module
Modul vnějšího rozhraní autentizace Umožňuje, aby byla pověření vytvářena na základě informace dodané back-end aplikací.
Tabulka 34. Moduly autentizace specifické pro Windows Modul ntlm pdwpi-ntlm-module
Popis Modul autentizace pomocí NTLM. NTLM je modul autentizace specifický pro Windows používající přihlašovací jméno pro Windows 2000 k reprezentování autentizovaného uživatele v produktu Tivoli Access Manager.
web-server-authn pdwpi-websvrauth-module
Modul autentizace webového serveru. Moduly autentizace webového serveru v modulu autentizace pro platformy Windows. Modul používající přihlašovací jméno pro Windows 2000 k reprezentování autentizovaného uživatele v produktu Tivoli Access Manager.
Tabulka 35. Reference pro moduly relace plug-in programu Modul BA pdwpi-ba-module
Popis Modul relace se Základní autentizací. Používá hodnotu autorizační hlavičky Základní autentizace jako klíče relace. Pokud se používá, musí být tento modul také nakonfigurován jako modul autentizace. Může být také nakonfigurován jako modul pro zpracování následující po autorizaci.
ip-addr pdwpi-ipaddr-module
Modul relace s IP adresou. Používá IP adresu neautentizovaného klienta jako klíč relace. Pokud se používá, musí být tento modul také nakonfigurován jako modul autentizace.
Dodatek C. Stručná reference pro moduly
197
Tabulka 35. Reference pro moduly relace plug-in programu (pokračování) Modul http-hdr pdwpi-httphdr-module
Popis Modul relace s HTTP hlavičkou. Používá autentizovanou HTTP hlavičku jako klíč relace. Pokud se používá, musí být tento modul také nakonfigurován jako modul autentizace.
session-cookie pdwpi-sesscookie-module
Modul relace s cookie relace. Tento modul generuje a přijímá cookies, které se používají k identifikaci relací. Obvykle se používá pouze jako mechanismus pro identifikaci relací s nízkou prioritou.
ssl-id pdwpi-sslsessid-module
Modul relace s ID SSL relace. Používá ID SSL relace jako klíč relace. Všimněte si, že přestože je tento modul poskytován v distribuci pro operační systém Windows produktu Tivoli Access Manager Plug-in for Web Servers, webový server Microsoft Internet Information Services neposkytuje informaci o ID SSL relace plug-in programu, takže tato ID SSL relací není možné použít jako klíče relací pro IIS.
iv-headers pdwpi-iv-headers-module
Modul relace s IV hlavičkami Používá IV hlavičky k udržování stavu relace.
ltpa pdwpi-ltpa-module
Modul relace LTPA. Používá LTPA cookies k udržování stavu relace.
Tabulka 36. Modul pro zpracování předcházející autorizaci plug-in programu Modul
Popis
boolean-rules pdwpi-boolean-rules-module
Modul pro zpracování předcházející autorizaci pomocí Boolean Rules.
switch-user pdwpi-switch-user-module
Modul pro zpracování předcházející autorizaci pomocí Switch User.
dynurl pdwpi-dynurl-module
Modul pro zpracování předcházející autorizaci pomocí dynamického URL.
acctmgt pdwpi-acct-mgmt-module
Modul pro zpracování předcházející autorizaci pomocí produktu Account Management. Tento modul nabízí funkce pro odhlášení (/pkmslogout), změnu hesla (/pkmspasswd) a nápovědu (/pkmshelp).
198
cred-refresh pdwpi-cred-refresh-module
Modul pro zpracování předcházející autorizaci pomocí Credential Refresh.
forms pdwpi-forms-module
Modul pro zpracování předcházející autorizaci pomocí formátů.
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tabulka 36. Modul pro zpracování předcházející autorizaci plug-in programu (pokračování) Modul token pdwpi-token-module
Popis Modul pro zpracování předcházející autorizaci pomocí tokenu. Produkt Tivoli Access Manager Plug-in for Web Servers podporuje autentizaci pomocí token passcode, dodávaného klientem. Tato autentizace používá dvoufaktorové přihlášení založené na RSA SecureID fobs. Pokud se používá, musí být tento modul také nakonfigurován jako modul autentizace.
ext-auth-int pdwpi-ext-auth-int-module
Modul pro zpracování předcházející autorizaci pomocí rozhraní vnější autentizace.
login-redirect pdwpi-loginredirect-module
Modul pro zpracování předcházející autorizaci pomocí přesměrování protokolování. Jakmile se uživatel přihlásí některou z politik podporovaných plug-in programem, uživatel je po úspěšné autentizaci přesměrován na nakonfigurovanou stránku.
ecsso pdwpi-ecsso-module
Modul pro zpracování předcházející autorizaci pomocí jednotného přihlášení e-Community. Všichni virtuální hostitelé, kteří se podílejí na e-community, musí mít nakonfigurovaný ecsso modul jako modul pro zpracování následující po autorizaci. Tento modul musí být také nakonfigurován jako modul autentizace pro všechny účastníky, kromě hlavního autentizačního serveru.
Tabulka 37. Reference pro moduly pro zpracování následující po autorizaci plug-in programu Modul forms pdwpi-forms-module
Popis Modul pro zpracování následující po autorizaci pomocí HTML formátů. Tento modul obsluhuje odevzdání dat formulářů během přihlášení založeného na HTML formátech. Pokud se používá, musí být tento modul také nakonfigurován jako modul autentizace. Tento modul může také nastavit BA hlavičku ze získaného jména uživatele a hesla.
BA pdwpi-ba-module
Modul pro zpracování následující po autorizaci pomocí Základní autentizace Upravuje BA hlavičku, kterou vidí webový server, nebo ji vytvoří z dat v GSO lockboxu.
failover pdwpi-failovercookie-module
Modul pro zpracování následující po autorizaci pomocí failover cookie. Tento modul generuje failover cookie pro klienta. Pokud se používá, musí být tento modul také nakonfigurován jako modul autentizace.
Dodatek C. Stručná reference pro moduly
199
Tabulka 37. Reference pro moduly pro zpracování následující po autorizaci plug-in programu (pokračování) Modul iv-headers pdwpi-iv-headers-module
Popis Modul pro zpracování následující po autorizaci pomocí IV hlaviček. Tento modul vkládá informace o totožnosti uživatele jako IV hlavičky do požadavku, než dovolí, aby byl požadavek obsloužen webovým serverem. To je užitečné pro jednotné přihlášení do aplikací, jejichž hostitelem je webový server. Je možné přidat tyto hlavičky: iv-user, iv-user-l, iv-groups, iv-creds a iv-remote-address. Tento modul se může také nakonfigurovat jako modul pro zpracování následující po autorizaci a modul relace.
tag-value pdwpi-tag-value-module
Modul pro zpracování následující po autorizaci pomocí příznaku/hodnoty. Tento modul vkládá další rozšířené atributy z pověření uživatelů jako HTTP hlavičky do požadavku, než dovolí, aby byl požadavek obsloužen webovým serverem. Tyto rozšířené atributy obvykle odpovídají atributům uživatele v registru uživatelů.
ltpa pdwpi-ltpa-module
Modul pro zpracování následující po autorizaci pomocí LTPA cookie. Tento modul vkládá LTPA (Lightweight Third Party Authentication) cookie WAS (WebSphere Application Server) do požadavku, než dovolí, aby byl požadavek obsloužen webovým serverem. Toto řešení umožňuje jednotné přihlášení do WAS, jehož hostitelem je webový server.
cdsso pdwpi-cdsso-module
Modul pro zpracování následující po autorizaci pomocí CDSSO.
boolean-rules pdwpi-boolean-rules-module
Modul pro zpracování následující po autorizaci pomocí Boolean Rules.
fsso pdwpi-fsso-module
Modul jednotného přihlášení pomocí formátů.
web-log pdwpi-web-log-module
Modul pro zpracování následující po autorizaci pomocí protokolu webu.
Tabulka 38. Reference pro modul odpovědi Modul
200
Popis
fsso pdwpi-fsso-module
Modul odpovědi jednotného přihlášení pomocí formátů.
ext-auth-int pdwpi-ext-auth-int-module
Modul odpovědi vnějšího rozhraní autentizace
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Dodatek D. Stručná reference pro příkazy
© Copyright IBM Corp. 2000, 2003
201
pdwebpi_start Spouští, zastavuje a restartuje proces produktu Tivoli Access Manager Plug-in for Web Servers v instalacích na operačních systémech UNIX. Všimněte si, že je produkt Plug-in for Web Servers automaticky spuštěn a zastaven, když je spuštěn nebo zastaven základní produkt Tivoli Access Manager. Také zobrazuje stav všech webových serverů. Poznámka: Pokud je potřeba, může se příkaz pdwebpi_start použít k ovládání produktu Plug-in for Web Servers nezávisle na základním produktu Tivoli Access Manager.
Syntaxe pdwebpi_start start pdwebpi_start stop pdwebpi_start restart pdwebpi_start status
Parametry pdwebpi_start {start|stop|restart|status} kde: start Spouští proces Plug-in programu v instalacích na operačních systémech UNIX. stop Zastavuje proces Plug-in programu v instalacích na operačních systémech UNIX. restart Zastavuje a restartuje proces Plug-in programu v instalacích na operačních systémech UNIX. status Poskytuje informaci o stavu produktu Plug-in for Web Servers na operačních systémech UNIX.
Komentáře Pokud chcete spustit a zastavit plug-in program v instalacích na operačním systému Windows, označte proces Plug-in programu v Services Control Panel (Ovládacím panelu Služby) a použijte odpovídající řídicí tlačítka.
Dostupnost Tento příkaz je umístěn v následujících standardních instalačních adresářích: v Systémy UNIX: /opt/pdwebpi/sbin/
v Systémy Windows: C:\Program Files\Tivoli\pdwebpi\sbin\
Pokud je zvolen instalační adresář jiný než standardní, je tento obslužný program umístěn v adresáři sbin pod instalačním adresářem (například install_dir\sbin\).
Návratové kódy Mohou být vráceny následující kódy stavu ukončení:
202
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
0
Příkaz byl úspěšně dokončen.
1
Vyskytla se chyba.
Dodatek D. Stručná reference pro příkazy
203
pdwebpi Poskytují informaci o produktu Tivoli Access Manager Plug-in for Web Servers. Také určují, zda se má produkt Plug-in for Web Servers spustit jako démon, nebo zda ho spustit v popředí.
Syntaxe pdwebpi [–foreground] [–version]
Parametry –foreground Spouští binární Plug-in for Web Servers v popředí jako protiklad ke spuštění jako démon. –version Poskytuje informaci o verzi pro instalaci produktu Plug-in for Web Servers.
Dostupnost Tento příkaz je umístěn v následujících standardních instalačních adresářích: v Systémy UNIX: /opt/pdwebpi/bin/
v Systémy Windows: C:\Program Files\Tivoli\pdwebpi\bin\
Pokud je zvolen instalační adresář jiný než standardní, je tento obslužný program umístěn v adresáři bin pod instalačním adresářem (například install_dir\bin\).
Návratové kódy Mohou být vráceny následující kódy stavu ukončení: 0
Příkaz byl úspěšně dokončen.
1
Došlo k selhání příkazu. Pokud dojde k selhání příkazu, je poskytnut popis chyby a kód chybového stavu v hexadecimálním formátu (například 0x14c012f2). Odkaz na IBM Tivoli Access Manager Error Message Reference. Tento odkaz poskytuje pomocí hexadecimálních a decimálních kódů seznam chybových zpráv Tivoli Access Manager.
204
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
pdwpi-version Vypíše seznam verzí a informace o autorských právech pro instalaci produktu Tivoli Access Manager Plug-in for Web Servers.
Syntaxe pdwpi-version [–h] [–V] [–l | binary [binary ... ]]
Parametry –h Zobrazí nápovědu nebo zprávu použití. –l
Uvádí dlouhý seznam zobrazující verze všech binárních souborů, nejenom verzi sady programů.
–V Zobrazuje informaci o verzi pro binární pdwpi-version. binary [binary] Zobrazuje informaci o verzi pro uvedené binární soubory nebo, pokud není uveden žádný binární, pro všechny soubory.
Dostupnost Tento příkaz je umístěn v následujících standardních instalačních adresářích: v Systémy UNIX: /opt/pdwebpi/bin/
v Systémy Windows: C:\Program Files\Tivoli\pdwebpi\bin\
Pokud je zvolen instalační adresář jiný než standardní, je tento obslužný program umístěn v adresáři bin pod instalačním adresářem (například install_dir\bin\).
Návratové kódy Mohou být vráceny následující kódy stavu ukončení: 0
Příkaz byl úspěšně dokončen.
1
Vyskytla se chyba.
Dodatek D. Stručná reference pro příkazy
205
pdwpicfg –action config Konfiguruje produkt Tivoli Access Manager Plug-in for Web Servers.
Syntaxe pdwpicfg –action config –admin_id admin_id –admin_pwd admin_pwd –auth_port authorization_port_number –web_server {iis|iplanet|ihs|apache} –iis_filter {yes|no} –web_directory server_install_directory –vhosts virtual_host_id –ssl_enable {yes|no} –keyfile keyfile –key_pwd key_password –key_label key_label –ssl_port ssl_port_number pdwpicfg –action config –interactive {yes|no} pdwpicfg –action config –rspfile response_file pdwpicfg –operations pdwpicfg –help [ options] pdwpicfg –usage pdwpicfg –?
Parametry –admin_id admin_id Uvádí identifikátor administrátora (obvykle sec_master). –admin_pwd admin_pwd Uvádí heslo pro administrátora admin_id. –auth_port authorization_port_number Uvádí číslo portu serveru autorizace. Předvolená hodnota čísla portu je 7237. –help [options] Vypisuje jméno volby a krátký popis. Pokud je uvedena jedna nebo více voleb, tak vypisuje každou volbu a krátký popis. –interactive {yes|no} Pokud má příkaz hodnotu yes, aktivuje pro něj interaktivní režim; jinak ho zablokuje. Předvolená hodnota je yes. –iis_filter {yes|no} Pokud má hodnotu zes aktivuje filtrování IIS (Internet Information Server); jinak ho zablokuje. –keyfile keyfile Uvádí soubor klíčů SSL pro LDAPPředvolená hodnota neexistuje.Tuto volbu uveďte, pokud nespouštíte příkaz v interaktivním režimu a pokud jste aktivovali SSL mezi produktem Plug-in for Web Servers a LDAP. –key_label key_label Uvádí návěští klíčů SSL pro LDAPPředvolená hodnota neexistuje.Tuto volbu uveďte, pokud nespouštíte příkaz v interaktivním režimu a pokud jste aktivovali SSL mezi produktem Plug-in for Web Servers a LDAP. –key_pwd key_password Uvádí heslo souboru klíčů SSL pro LDAP
206
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
–operations Vypisuje po sobě každé jméno volby bez popisu. –rspfile response_file Poskytuje plně kvalifikovanou cestu a jméno souboru pro soubor odpovědi produktu Plug-in for Web Servers, které se mají použít během tiché instalace. Soubor odpovědi se může použít pro nakonfigurování nebo odkonfigurování. Předvolené jméno souboru odpovědi neexistuje. Soubor odpovědi obsahuje stanzy a párové záznamy stanzy volba=hodnota. Abyste použili soubory odpovědi, prohlédněte procedury v IBM Tivoli Access Manager for e-business Web Security Installation Guide. –ssl_enable {yes|no} Pokud má hodnotu yes, aktivuje komunikace SSL s LDAP; jinak je zakazuje. Předvolená hodnota je yes. –ssl_port ssl_port_number Uvádí port SSL pro LDAPPředvolená hodnota čísla portu je 636. –usage Zobrazuje syntaxi použití pro tento příkaz. Také zobrazuje příklad. –vhosts virtual_host_id Uvádí virtuální hostitele, kteří se mají chránit. Hodnota by měla být ve tvaru seznamu IDs virtuálních hostitelů, oddělených čárkami. Mezi ID virtuálních hostitelů by neměly být žádné mezery. –web_directory server_install_directory Uvádí instalační adresář webového serveru. –web_server {iis|iplanet|ihs|apache} Uvádí typ webového serveru, na kterém je nainstalován produkt Plug-in for Web Servers. Volby jsou: iis pro Internet Information Server, iplanet pro Sun ONE Server, ihs pro IBM HTTP Server , nebo apache pro Apache Server. Tato volba se stává standardní pro typ a umístění konfigurovaného webového serveru. –? Zobrazuje syntaxi použití pro tento příkaz. Také zobrazuje příklad.
Dostupnost Tento příkaz je umístěn v následujících standardních instalačních adresářích: v Systémy UNIX: /opt/pdwebpi/bin/
v Systémy Windows: C:\Program Files\Tivoli\pdwebpi\bin\
Pokud je zvolen instalační adresář jiný než standardní, je tento obslužný program umístěn v adresáři bin pod instalačním adresářem (například install_dir\bin\).
Návratové kódy Mohou být vráceny následující kódy stavu ukončení: 0
Příkaz byl úspěšně dokončen.
1
Došlo k selhání příkazu. Pokud dojde k selhání příkazu, je poskytnut popis chyby a kód chybového stavu v hexadecimálním formátu (například 0x14c012f2). Viz IBM Tivoli Access Manager Error Message Reference. Tento odkaz poskytuje pomocí hexadecimálních a decimálních kódů seznam chybových zpráv Tivoli Access Manager.
Dodatek D. Stručná reference pro příkazy
207
pdwpicfg –action unconfig Odkonfiguruje produkt Tivoli Access Manager Plug-in for Web Servers.
Syntaxe pdwpicfg –action unconfig –admin_id admin_id –admin_pwd admin_pwd –force {yes|no} –remove {none|acls|objspace|all} –vhosts virtual_host_id pdwpicfg –action unconfig –interactive {yes|no} pdwpicfg –action unconfig –rspfile response_file pdwpicfg –operations pdwpicfg –help [ options] pdwpicfg –usage pdwpicfg –?
Parametry –admin_id admin_id Uvádí identifikátor administrátora (obvykle sec_master). –admin_pwd admin_pwd Uvádí heslo pro administrátora admin_id. –force {yes|no} Vynucuje proces odkonfigurování pouze, pokud nelze kontaktovat server politiky. Předvolená hodnota je no. –help [options] Vypisuje jméno volby a krátký popis. Pokud je uvedena jedna nebo více voleb, tak vypisuje každou volbu a krátký popis. –interactive {yes|no} Pokud má příkaz hodnotu yes, aktivuje pro něj interaktivní režim; jinak ho zablokuje. Předvolená hodnota je yes. –operations Vypisuje po sobě každé jméno volby bez popisu. –remove {none|acls|objspace|all} Uvádí, zda se má jako část procesu odkonfigurování odstranit prostor objektů nebo ACL, nebo oba. Předvolená hodnota je none. –rspfile response_file Poskytuje plně kvalifikovanou cestu a jméno souboru pro soubor odpovědi produktu Plug-in for Web Servers, které se mají použít během tiché instalace. Soubor odpovědi se může použít pro nakonfigurování nebo odkonfigurování. Předvolené jméno souboru odpovědi neexistuje. Soubor odpovědi obsahuje stanzy a párové záznamy stanzy volba=hodnota. Abyste použili soubory odpovědi, prohlédněte procedury v IBM Tivoli Access Manager for e-business Web Security Installation Guide. –usage Zobrazuje syntaxi použití pro tento příkaz. Také zobrazuje příklad.
208
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
–vhosts virtual_host_id Uvádí virtuální hostitele, kteří se mají odkonfigurovat. Hodnota by měla být ve tvaru seznamu ID virtuálních hostitelů, oddělených čárkami. Mezi ID virtuálních hostitelů by neměly být žádné mezery. –? Zobrazuje syntaxi použití pro tento příkaz. Také zobrazuje příklad.
Dostupnost Tento příkaz je umístěn v následujících standardních instalačních adresářích: v Systémy UNIX: /opt/pdwebpi/bin/
v Systémy Windows: C:\Program Files\Tivoli\pdwebpi\bin\
Pokud je zvolen instalační adresář jiný než standardní, je tento obslužný program umístěn v adresáři bin pod instalačním adresářem (například install_dir\bin\).
Návratové kódy Mohou být vráceny následující kódy stavu ukončení: 0
Příkaz byl úspěšně dokončen.
1
Došlo k selhání příkazu. Pokud dojde k selhání příkazu, je poskytnut popis chyby a kód chybového stavu v hexadecimálním formátu (například 0x14c012f2). Odkaz na IBM Tivoli Access Manager Error Message Reference. Tento odkaz poskytuje pomocí hexadecimálních a decimálních kódů seznam chybových zpráv Tivoli Access Manager.
Dodatek D. Stručná reference pro příkazy
209
210
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Dodatek E. Speciální znaky dovolené v běžných výrazech Následující tabulka vypisuje speciální znaky povolené v běžných výrazech použitých v konfiguračním souboru pdwebpi.conf. *
Shoduje se nula nebo více znaků
?
Shoduje se libovolný znak
\
Únikový znak (například, \? odpovídá ?)
[acd]
Shoduje se znak a, c, nebo d (citlivý na velikost písmen)
[^acd]
Shoduje se libovolný znak kromě a, c, nebo d (citlivý na velikost písmen)
[a-z]
Shoduje se libovolný znak od a do z (malé písmo)
[^0-9]
Shoduje se libovolný znak, ale ne od 0 do 9 (né číslo)
[a-zA-Z]
Shoduje se libovolný znak od a do z (malé písmo) nebo od A do Z (velké písmo)
© Copyright IBM Corp. 2000, 2003
211
212
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Dodatek F. Poznámky Tyto informace jsou určeny pro produkty a služby nabízené v USA. Společnost IBM nemusí v ostatních zemích nabídnout produkty, služby a funkce popsané v tomto dokumentu. Informace o produktech a službách, které jsou momentálně ve vaší zemi dostupné, můžete získat od zástupce společnosti IBM pro vaši oblast. Žádný z odkazů na produkty, programové vybavení nebo služby není zamýšlen jako tvrzení, že lze použít pouze tyto produkty, programové vybavení nebo služby společnosti IBM. Jako náhrada mohou být použity libovolné funkčně ekvivalentní produkty, programové vybavení nebo služby, které neporušují žádné intelektuální vlastnické právo společnosti IBM. Za operace prováděné produkty, programovým vybavením nebo službami, které nepochází od společnosti IBM, nese zodpovědnost uživatel. Společnost IBM může mít k dispozici patenty nebo podané patentové přihlášky, vztahující se k informacím popsaným v tomto dokumentu. Vlastnictví tohoto dokumentu vám nedává žádná práva k těmto patentům. Písemné žádosti o licenci můžete posílat na adresu: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. Pokud máte zájem o licenci v zemi s dvoubajtovou znakovou sadou (DBCS), kontaktujte zastoupení společnosti IBM ve vaší zemi, nebo písemně zastoupení společnosti IBM na adrese: IBM World Trade Asia Corporation Licensing 2-31 Roppongi 3-chome, Minato-ku Tokyo 106-0032, Japan Následující odstavec se netýká Velké Británie nebo kterékoliv jiné země, kde taková opatření odporují místním zákonům: SPOLEČNOST INTERNATIONAL BUSINESS MACHINES CORPORATION TUTO PUBLIKACI POSKYTUJE TAKOVOU, “JAKÁ JE”, BEZ JAKÝCHKOLIV ZÁRUK, VYJÁDŘENÝCH NEBO ODVOZENÝCH, VČETNĚ, ALE NE VÝHRADNĚ, ODVOZENÝCH ZÁRUK PORUŠENÍ ZÁKONŮ, PRODEJNOSTI NEBO VHODNOSTI PRO URČITÝ ÚČEL. Některé právní řády nepřipouštějí omezení či vyvázání se ze záruk nebo odpovědnosti za následné či nepředvídatelné škody. V takovém případě se na vás výše uvedené omezení nevztahuje. Tato publikace může obsahovat technické nepřesnosti nebo typografické chyby. Informace zde uvedené jsou pravidelně aktualizovány a v příštích vydáních této publikace již budou tyto změny zahrnuty. Společnost IBM má právo kdykoliv bez upozornění zdokonalovat nebo měnit produkty a programy popsané v této publikaci. Všechny odkazy na tyto informace, uvedené na webových stránkách jiných provozovatelů než společnosti IBM jsou poskytovány pouze pro vaši potřebu a v žádném případě neslouží k propagaci těchto webových stránek. Materiály, uvedené na takovýchto webových stránkách nejsou součástí materiálů, určených pro tento produkt IBM, a proto tyto webové stránky používáte pouze na vlastní riziko. Společnost IBM může používat nebo distribuovat informace, které jí poskytnete, způsobem, o kterém si myslí, že je odpovídající, bez dalších závazků k vám.
© Copyright IBM Corp. 2000, 2003
213
Držitelé licence tohoto programu, kteří si přejí mít přístup i k informacím za účelem (i) výměny informací mezi nezávisle vytvořenými programy a jinými programy (včetně tohoto) a (ii) vzájemného použití sdílených informací, mohou kontaktovat: IBM Corporation 2Z4A/101 11400 Burnet Road Austin, TX 78758 U.S.A. Informace tohoto typu mohou být za odpovídajících podmínek dostupné. V některých případech připadá v úvahu zaplacení poplatku. Program popsaný v tomto dokumentu a všechny materiály s ním související, které podléhají licenci, jsou dodávány společností IBM v souladu s textem smlouvy mezi zákazníkem a společností IBM nebo ekvivalentní smlouvy. Všechny informace o provozu byly určeny v řízeném prostředí. Výsledky obdržené v jiném operačním prostředí se tudíž mohou výrazně lišit. Některá měření byla provedena v systémech s vývojovým prostředím a neexistuje žádná záruka, že tato měření budou stejná v obecně dostupných systémech. Některá měření byla odhadnuta extrapolací. Skutečné výsledky se mohou lišit. Uživatelé tohoto dokumentu by měli ověřit vhodnost dat pro svá specifická prostředí. Informace týkající se produktů jiných společností byly získány od dodavatelů těchto produktů, z jejich tištěných materiálů nebo z jiných veřejně dostupných zdrojů. Společnost IBM netestovala tyto produkty a nemůže potvrdit spolehlivost jejich provozu, kompatibilitu nebo jiné tvrzení týkající se těchto produktů. Otázky týkající se možností produktů jiných společností by měly být adresovány dodavatelům těchto produktů. Všechna tvrzení o budoucím zaměření nebo úmyslech společnosti IBM mohou být bez upozornění změněna nebo zrušena a představují pouze hrubý nástin cílů a podmínek společnosti. Tyto informace jsou určeny pouze pro účely plánování. Informace zde uvedené se mohou změnit, než bude popsaný produkt uvolněn do prodeje. Tyto informace obsahují příklady dat a sestav, používaných v běžných denních obchodních operacích. Aby tyto příklady byly maximálně úplné a demonstrativní, obsahují jména osob, společností, obchodních značek a produktů. Všechna tato jména jsou fiktivní a jakákoliv podobnost se jmény a adresami, používanými skutečnými obchodními společnostmi je čistě náhodná. Pokud si tyto informace neprohlížíte v kopii s trvalým záznamem, je možné, že se nezobrazily fotografie a barevné ilustrace.
Ochranné známky Následující termíny jsou ochranné známky společnosti International Business Machines Corporation v USA, v jiných zemích nebo obojí: AIX DB2 IBM IBM(logo) OS/390 SecureWay
214
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Tivoli Tivoli (logo) Universal Database WebSphere z/OS zSeries Microsoft a Windows jsou ochranné známky společnosti Microsoft Corporation v USA, v jiných zemích nebo obojí. UNIX je registrovaná ochranná známka v USA a v dalších zemích, jejíž licenci poskytuje výhradně společnost X/Open Company Limited. Jiné názvy společností, výrobků a služeb mohou být ochrannými známkami jiných společností.
Dodatek F. Poznámky
215
216
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Slovníček A access control (řízení přístupu) V zabezpečení počítače jde o proces, který zajišťuje, že zdroje počítačového systému mohou používat pouze oprávnění uživatelé a pouze oprávněným způsobem. access control list (ACL) (přístupový seznam) V zabezpečení počítačů jde o seznam, který je přidružen k objektu a který identifikuje všechny subjekty, které mohou k danému objektu přistupovat, a který určuje jejich přístupová práva k tomuto objektu. Například přístupový seznam je seznam, který je přidružen k souboru a který identifikuje uživatele, kteří mohou přistupovat k tomuto souboru, a který identifikuje přístupová práva těchto uživatelů k danému souboru. access permission (oprávnění k přístupu) přístupu, která platí pro celý objekt,
Oprávnění k
action (akce) Atribut oprávnění přístupového seznamu. Viz též access control list (přístupový seznam). ACL
Viz access control list (přístupový seznam).
administration service (administrativní služba) Plug-in program autorizačního rozhraní API, který se používá k provádění administrativních požadavků na aplikaci správce zdrojů produktu Tivoli Access Manager. Administrativní služba odpovídá vzdáleným požadavkům z příkazu pdadmin a provádí úlohy, jako např. výpis objektů pod určitým uzlem v prostoru chráněných objektů. Zákazníci si mohou tyto služby sami vytvořit pomocí sady pro vývoj authorization ADK. attribute list (seznam atributů) Propojený seznam, který obsahuje rozšířené informace používané k provedení rozhodnutí o autorizaci. Seznamy atributů se skládají z párů klíčové_slovo = hodnota. authentication (autentizace) (1) V zabezpečení počítačů jde o ověření totožnosti uživatele nebo způsobilosti uživatele přistoupit k objektu. (2) V zabezpečení počítačů jde o proces ověření, že zpráva nebyla pozměněna nebo porušena. (3) V zabezpečení počítačů jde o proces, který se používá k ověření uživatele informačního systému nebo chráněných zdrojů. Viz též multi-factor authentication (vícefaktorová autentizace), network-based authentication (autentizace založená na síti) a step-up authentication (zvýšená autentizace). authorization (autorizace) (1) V počítačovém zabezpečení jde o právo udělené uživateli, aby mohl komunikovat nebo používat počítačový systém. (2) Proces, který uživateli udělí buď úplný nebo omezený přístup k objektu, zdroji nebo funkci. authorization rule (autorizační pravidlo) (pravidlo).
© Copyright IBM Corp. 2000, 2003
Viz rule
authorization service plug-in (plug-in program autorizační služby) Dynamická knihovna (knihovna DLL nebo sdílená knihovna), kterou může načíst klient autorizačního rozhraní API produktu Tivoli Access Manager během své inicializace, aby mohl provádět operace, které rozšiřují rozhraní služeb v rámci autorizačního rozhraní API. Rozhraní služeb, která jsou v současné době k dispozici jsou: administrativní rozhraní, rozhraní pro externí autorizaci, rozhraní pro úpravu pověření, rozhraní pro nároky a rozhraní pro manipulaci s PAC. Zákazníci si mohou tyto služby sami vytvořit pomocí sady pro vývoj authorization ADK.
B BA
Viz basic authentication (základní autentizace).
basic authentication (základní autentizace) Politika autentizace, která vyžaduje, aby uživatel znal platné jméno uživatele a heslo, než mu bude povoleno přistoupit k zabezpečenému online zdroji. bind (spojit) Svázat identifikátor s jiným objektem v programu. Například spojit identifikátor s hodnotou, adresou nebo jiným identifikátorem, nebo spojit formální parametry a skutečné parametry. blade (rozřazovač) Komponenta, která poskytuje služby a komponenty specifické pro danou aplikaci. business entitlements (obchodní nároky) Doplňkový atribut pověření uživatele, který popisuje jemně strukturované podmínky, které lze použít při požadavku na autorizaci ke zdrojům.
C CA
Viz certificate authority (vydavatel certifikátů).
CDAS Viz Cross Domain Authentication Service (služba CDAS). CDMF Viz Cross Domain Mapping Framework (základní struktura CDMF). certificate (certifikát) V zabezpečení počítačů jde o digitální dokument, který spojuje veřejný klíč s totožností vlastníka certifikátu, a tím umožní vlastníkovi certifikátu, aby se autentizoval. Certifikát je vydán vydavatelem certifikátů. certificate authority (CA - vydavatel certifikátů) Organizace, která vydává certifikáty. Vydavatel certifikátů autentizuje totožnost vlastníka certifikátu a služby, které je vlastník oprávněn používat. Tato společnost dále vydává nové certifikáty, obnovuje stávající certifikáty a odvolává certifikáty, které patří uživatelům, kteří již nejsou oprávněni je používat.
217
CGI
Viz common gateway interface (program CGI).
cipher (šifra) Zašifrovaná data, která jsou nečitelná, dokud nebudou pomocí klíče převedena do prostých dat (dešifrovaných). common gateway interface (program CGI) Internetový standard pro definování skriptů, které předávají informaci z webového serveru do aplikačního programu prostřednictvím požadavku HTTP a naopak. Skript CGI je program CGI, který je napsán ve skriptovacím jazyce, jako např. v jazyce Perl. configuration (konfigurace) (1) Způsob, kterým je organizován a propojen hardware a software systémů zpracování dat. (2) Počítače, zařízení a programy, které vytvářejí systém, podsystém nebo síť. connection (připojení) (1) V datové komunikaci jde o zavedené sdružení funkčních jednotek pro postupování informací. (2) V protokolu TCP/IP jde o cestu mezi dvěma aplikacemi protokolu, které poskytují spolehlivou službu doručení toku dat. V Internetu připojení vede z aplikace TCP/IP na jednom systému k aplikaci TCP na jiném systému. (3) V systémových komunikacích jde o linku, prostřednictvím které je možné předávat data mezi dvěma systémy, nebo mezi systémem a zařízením. container object (objekt typu zásobník) Strukturální označení, které organizuje prostor objektů do rozdílných funkčních oblastí. cookie Informace, kterou server ukládá na počítači klienta a ke které se přistupuje během následujících relací. Cookies umožňují, aby si servery pamatovaly určité informace o klientech. credentials (pověření) Podrobné informace získané během autentizace, které popisují uživatele, všechna přidružení ke skupinám a další atributy totožnosti spojené se zabezpečením. Pověření je možné používat k provozování velkého množství služeb, jako např. autorizace, monitorování a delegace. credentials modification service (služba pro úpravu pověření) Plug-in program autorizačního rozhraní API, který se používá k úpravě pověření produktu Tivoli Access Manager. Služby pro úpravu pověření, které byly vyvinuty externě přímo zákazníky, jsou omezeny na provádění operací pro přidání a odstranění atributů ze seznamu atributů pověření, a to pouze pro ty atributy, které se pokládají za upravitelné. cross domain authentication service (služba CDAS) Služba produktu WebSEAL, jejíž součástí je mechanismus sdílené knihovny, který vám dovoluje nahradit předvolený mechanismus autentizace produktu WebSEAL za uživatelsky přizpůsobený proces, který vrátí totožnost produktu Tivoli Access Manager do produktu WebSEAL. Viz též WebSEAL. cross domain mapping framework (základní struktura CDMF) Programovací rozhraní, které dovoluje, aby vývojář upravil mapování totožností uživatelů a zacházení s atributy uživatelů, pokud se používá funkce e-community jednotného přihlášení produktu WebSEAL.
218
D daemon (démon) Program, který svoji činnost provádí bez účasti uživatele, a který souvisle nebo pravidelně provádí systémové funkce, jako např. kontrolu sítě. Některé démony jsou spouštěny automaticky, aby prováděly své úlohy. Jiné démony pracují pravidelně. directory schema (adresářové schéma) Platné typy atributů a třídy objektů, které se mohou v adresáři objevit. Typy atributů a třídy objektů definují syntaxi hodnot atributů, které atributy musí adresář obsahovat a které atributy adresář obsahovat nemusí. distinguished name (rozlišovací jméno) Jméno, které jedinečně identifikuje záznam v adresáři. Rozlišovací jméno se skládá z párů atribut:hodnota, které jsou odděleny čárkami. digital signature (digitální podpis) V elektronickém obchodu jde o data, která jsou připojena k jednotce dat, nebo o data, která jsou zašifrovanou informací jednotky dat, a která umožňují příjemci datové jednotky ověřit zdroj a integritu jednotky a rozeznat potenciální padělek. DN
Viz distinguished name (rozlišovací jméno).
domain (doména) (1) Logické seskupení uživatelů, systémů a zdrojů, které sdílí společné služby a obvykle pracuje na společném úkolu. (2) Ta část počítačové sítě, ve které jsou zdroje zpracování dat řízeny stejným společným ovládáním. Viz též domain name (jméno domény). domain name (jméno domény) V internetové sadě protokolů jde o jméno hostitelského systému. Jméno domény se skládá z posloupnosti podjmen, které jsou odděleny oddělovacím znakem. Například pokud plně kvalifikované jméno domény hostitelského systému je as400.vnet.ibm.com, pak každý z následujících příkladů je jméno domény: as400.rchland.vnet.ibm.com, vnet.ibm.com, ibm.com.
E EAS Viz External Authorization Service (externí autorizační služba). encryption (šifrování) V zabezpečení počítačů jde o proces transformace dat do nesrozumitelné formy takovým způsobem, aby nebylo možné originální data buď získat, nebo aby je bylo možné získat pouze pomocí dešifrovacího procesu. entitlement (nárok) Datová struktura, která obsahuje informace o realizované bezpečnostní politice. Nároky obsahují strategická data nebo schopnosti, které jsou naformátovány takovým způsobem, aby byly pro určitou aplikaci srozumitelné. entitlement service (služba nároků) Plug-in program autorizačního rozhraní API, který se používá pro daný objekt nebo sadu podmínek k navrácení nároků z externího zdroje. Nároky jsou obvykle data specifická pro aplikaci, která mohou být nějakým způsobem zpracována aplikací správce zdrojů, nebo která je možné přidat k pověření objektu, aby je bylo
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
možné použít později v průběhu procesu autorizace. Zákazníci si mohou tyto služby sami vytvořit pomocí sady pro vývoj authorization ADK. external authorization service (externí autorizační služba) Plug-in program autorizačního rozhraní API, který se používá k provádění rozhodnutí o autorizaci, specifických pro danou aplikaci nebo prostředí. Tato rozhodnutí jsou součástí procesu rozhodování o autorizaci produktu Tivoli Access Manager. Zákazníci si mohou tyto služby sami vytvořit pomocí sady pro vývoj authorization ADK.
F
Internet suite of protocols (internetová sada protokolů) Sada protokolů, které byly vyvinuty, aby byly používány na internetu, a které byly publikovány jako RFC (Requests for Comments) prostřednictvím společnosti IETF (Internet Engineering Task Force). interprocess communication (IPC) (1) Proces, pomocí kterého si programy předávají data mezi sebou a synchronizují své aktivity. Semafory, signály a interní fronty zpráv jsou běžnými metodami komunikace mezi procesy. (2) Mechanismus operačního systému, který dovoluje procesům, aby mezi sebou v rámci stejného počítače nebo přes síť komunikovaly. IP
file transfer protocol (FTP) V internetové sadě protokolů jde o protokol aplikační vrstvy, který používá služby TCP (Transmission Control Protocol) a Telnet pro přenos souborů dávkových dat mezi počítači nebo hostiteli.
G global signon (GSO) Pružné řešení jednotného přihlášení, které umožňuje uživateli, aby webovému aplikačnímu serveru typu back-end poskytl alternativní jména uživatele a hesla. GSO uděluje uživateli přístup k počítačovým zdrojům, k jejichž použití je autorizován — prostřednictvím jediného přihlášení. Toto řešení bylo navrženo pro velké společnosti, které se skládají z mnoha systémů a aplikací a jejichž počítačové prostředí je heterogenní a distribuované. V takovém prostředí GSO eliminuje potřebu, aby si uživatelé spravovali více jmen uživatelů a hesel. Viz též single signon (jednotné přihlášení). GSO
Viz global signon (GSO).
H
IPC
Viz Interprocess Communication (IPC).
J junction (spojení) HTTP nebo HTTPS propojení mezi předřazeným serverem WebSEAL a webovým aplikačním serverem typu back-end. Spojení umožňují produktu WebSEAL provádět ochranné služby v zastoupení serveru typu back-end.
K key (klíč) V zabezpečení počítačů jde o posloupnost znaků, která se používá v šifrovacím algoritmu pro zašifrování nebo dešifrování dat. Viz private key (soukromý klíč) a public key (veřejný klíč). key database file (databázový soubor klíčů) (klíčový řetězec). key file (soubor klíčů)
host (hostitel) Počítač, který je připojen k síti (jako např. k internetu nebo síti SNA) a který poskytuje přístupový bod k dané síti. Hostitel může také, v závislosti na prostředí, poskytovat centralizované řízení sítě. Hostitel může být klientem, serverem, nebo klientem a serverem současně. HTTP
Viz Internet Protocol (protokol IP).
Viz Hypertext Transfer Protocol (protokol HTTP).
Viz key ring
Viz key ring (klíčový řetězec).
key pair (pár klíčů) V zabezpečení počítačů jde o veřejný a soukromý klíč. Pokud se pár klíčů používá při šifrování, odesilatel použije veřejný klíč k zašifrování zprávy a příjemce použije soukromý klíč pro dešifrování zprávy. Pokud se pár klíčů používá pro podepisování, signatář vlastní soukromý klíč, aby mohl zašifrovat zprávu a příjemce použije veřejný klíč, aby dešifroval zprávu, a tak mohl ověřit podpis.
hypertext transfer protocol (protokol HTTP) V internetové sadě protokolů jde o protokol, který se používá k přenosu a zobrazení hypertextových dokumentů.
key ring (klíčový řetězec) V zabezpečení počítačů jde o soubor, který obsahuje veřejné klíče, soukromé klíče, důvěryhodné zdroje a certifikáty.
I
L
Internet protocol (protokol IP) V internetové sadě protokolů jde od bezspojový protokol, který směruje data v rámci sítě, nebo propojených sítí a vystupuje jako mezivrstva mezi vyššími vrstvami protokolu a fyzickou sítí.
LDAP
Viz Lightweight Directory Access Protocol.
lightweight directory access protocol (LDAP) Otevřený protokol, který (a) používá protokol TCP/IP, aby poskytl přístup k adresářům, které podporují model X.500, a (b) nevyvolá požadavky na zdroje komplexnějšího protokolu X.500 Directory Access Protocol (DAP). Aplikace, které používají LDAP, (známé jako adresářové aplikace) mohou používat adresář jako obecné úložiště dat a pro získávání Slovníček
219
informací o lidech nebo službách, jako např. o adresách elektronické pošty, veřejných klíčích, nebo konfiguračních parametrech specifických pro službu. LDAP byl původně uveden v RFC 1777. LDAP verze 3 je uveden v RFC 2251 a společnost IETF pokračuje v práci na dalších standardních funkcích. Některá standardní schémata definovaná společností IETF pro LDAP je možné nalézt v RFC 2256. lightweight third party authentication (LTPA) Základní struktura autentizace, která umožňuje realizaci jednotného přihlášení pro sadu webových serverů, které jsou umístěny v jedné internetové doméně. LTPA
Viz lightweight third party authentication.
M management domain (doména správy) Předvolená doména, ve které produkt Tivoli Access Manager vynucuje uplatňování bezpečnostních politik pro autentizaci, autorizaci a řízení přístupu. Tato doména se vytvoří během konfigurace serveru politik. Viz též domain (doména). management server (server správy) server (server politik). metadata dat.
policy (politika) zdrojů.
Sada pravidel, která se použijí ke správě
policy server (server politik) Server produktu Tivoli Access Manager, který spravuje informace o umístění dalších serverů v rámci zabezpečené domény. polling (systém výzev) Proces, ve kterém je v pravidelných intervalech vyslýchána databáze, aby se určilo, zda není nutné přenést nějaká data. POP Viz protected object policy (politika chráněného objektu). portal (portál) Integrovaný webový server, který dynamicky vytváří přizpůsobený seznam webových zdrojů, jako např. odkazů, obsahu nebo služeb, jenž je k dispozici určitým uživatelům, a to na základě oprávnění přístupu.
Zastaralé. Viz policy
Data, která popisují charakteristiky uložených
migration (migrace) Instalace nové verze nebo vydání programu, která má nahradit dřívější verzi nebo vydání. multi-factor authentication (vícefaktorová autentizace) Politika chráněného objektu (POP), která nutí uživatele, aby se autentizoval pomocí dvou nebo více úrovní autentizace. Řízení přístupu ke chráněnému zdroji může například vyžadovat, aby se uživatel autentizoval jak pomocí jména uživatele/hesla, tak i pomocí jména uživatele/token passcode. Viz též protected object policy (politika chráněného objektu). multiplexing proxy agent (MPA) Přenosová brána, která dokáže pojmout více přístupů klientů. Tyto přenosové brány se někdy nazývají bránami WAP (Wireless Access Protocol), a to tehdy, když klient přistupuje do zabezpečené domény pomocí protokolu WAP. Přenosové brány vytvářejí jediný autentizovaný kanál k původnímu serveru a všechny požadavky a odpovědi klientů ″tunelují″ tímto kanálem.
N network-based authentication (autentizace založená na síti) Politika chráněného objektu (POP), která řídí přístup k objektům na základě IP adresy uživatele. Viz též protected object policy (politika chráněného objektu).
P PAC Viz privilege attribute certificate (certifikát atributu oprávnění).
220
permission (oprávnění) Schopnost přistoupit ke chráněnému objektu, jako např. k souboru nebo adresáři. Počet a význam oprávnění pro daný objekt je nadefinován v přístupovém seznamu. Viz též access control list (přístupový seznam).
privilege attribute certificate (certifikát atributu oprávnění) Digitální dokument, který obsahuje atributy autentizace a autorizace objektu a schopnosti objektu. privilege attribute certificate service (služba certifikátu atributu oprávnění) Klientský plug-in program autorizačního rozhraní API, který překládá PAC v předdefinovaném formátu do pověření produktu Tivoli Access Manager a naopak. Tyto služby je možné použít také k zabalení nebo seřazení pověření produktu Tivoli Access Manager před jejich přenesením na další členy zabezpečené domény. Zákazníci si mohou tyto služby sami vytvořit pomocí sady pro vývoj authorization ADK. Viz též privilege attribute certificate (certifikát atributu oprávnění). protected object (chráněný objekt) Logické znázornění skutečného systémového zdroje, které se používá pro aplikaci politik ACL a POP a pro autorizaci přístupu uživatele. Viz též protected object policy (politika chráněného objektu) a protected object space (prostor chráněných objektů). protected object policy (politika chráněného objektu) Typ bezpečnostní politiky, která zavádí podmínky pro operace s přístupem ke chráněnému objektu, povolené politikou ACL. Správce zdrojů je odpovědný za to, že vynutí splnění podmínek POP. Viz též access control list (přístupový seznam), protected object (chráněný objekt) a protected object space (prostor chráněných objektů). protected object space (prostor chráněných objektů) Virtuální objektové znázornění skutečných systémových zdrojů, které se používá pro aplikaci politik ACL a POP a které používá autorizační služba. Viz též protected object (chráněný objekt) a protected object policy (politika chráněného objektu).
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
private key (soukromý klíč) V zabezpečení počítačů jde o klíč, který zná pouze jeho vlastník. Porovnejte s public key (veřejným klíčem). public key (veřejný klíč) V zabezpečení počítačů jde o klíč, který je k dispozici všem. Porovnejte se private key (soukromým klíčem).
Q quality of protection (úroveň zabezpečení) Úroveň zabezpečení dat, která je určena kombinací podmínek pro autentizaci, integritu a utajení.
R registry (registr) Úložiště dat, které obsahuje informace o přístupu a konfiguraci uživatelů, systémů a softwaru. replica (replika) Server, který obsahuje kopii adresáře nebo adresářů jiného serveru. Repliky zálohují servery ve smyslu zvýšení výkonnosti nebo snížení doby odezev, a také ve smyslu zajištění integrity dat. resource object (objekt typu prostředek) Znázornění skutečného síťového prostředku, jako např. služby, souboru, nebo programu. response file (soubor odpovědí) Soubor, který obsahuje sadu předdefinovaných odpovědí na dotazy, které pokládá program a které se používají namísto zadávání těchto hodnot postupně. role activation (aktivace role) přístupu na roli.
Proces aplikování oprávnění
role assignment (přiřazení role) Proces přiřazení role uživateli, takže tento uživatel bude mít odpovídající oprávnění přístupu k objektu, nadefinovanému v této roli. routing file (soubor směrování) Soubor ASCII, který obsahuje příkazy, které řídí konfiguraci zpráv. RSA encryption (šifrování RSA) Systém pro šifrování pomocí veřejného klíče, který se používá pro šifrování a autentizaci. Byl představen Ronem Rivestem, Adi Shamirem a Leonardem Adlemanem v roce 1977. Zabezpečení systému závisí na obtížnosti vydělení výsledku dvěma velkými prvočísly. rule (pravidlo) Jeden nebo více logických příkazů, které dovolují serveru událostí rozeznávat vzájemné souvislosti mezi jednotlivými událostmi (vzájemná souvislost událostí) a automaticky provádět příslušné odpovědí. run time (doba zpracování) Časový úsek, během kterého se provádí počítačový program. Runtime prostředí je prováděcí prostředí.
S scalability (škálovatelnost) Schopnost síťového systému odpovídat na zvyšující se počet uživatelů, kteří požadují zdroje. schema (schéma) Sada příkazů vyjádřená v jazyce definujícím data, která zcela popisuje strukturu databáze. Pro relační databázi jde o schéma, které definuje tabulky, pole v každé tabulce a vztahy mezi poli a tabulkami. secure sockets layer (SSL) Protokol zabezpečení, který poskytuje utajení komunikace. SSL umožňuje aplikacím klient/server, aby komunikovaly způsobem, který byl navržen tak, aby bránil naslouchání, falšování a padělání zpráv. SSL byl vyvinut společnostmi Netscape Communications Corp. a RSA Data Security, Inc. security management (správa zabezpečení ochrany dat) Obor správy, který adresuje schopnost organizace řídit přístup k aplikacím a datům, která jsou kritická pro její úspěch. self-registration (vlastní registrace) Proces, ve kterém uživatel může zadat požadovaná data a stát se registrovaným uživatelem produktu Tivoli Access Manager, aniž by bylo nutné zapojit administrátora. service (služba) Práce prováděná serverem. Služba může být jednoduchý požadavek na data, která mají být odeslána nebo uložena (jako např. u souborových serverů, HTTP serverů, serverů elektronické pošty nebo serverů finger), nebo to může být podstatně komplexnější práce, jako např. u tiskových serverů a provozních serverů. silent installation (tichá instalace) Instalace, která neposílá na konzoli zprávy, ale místo toho ukládá zprávy a chyby do souborů protokolu. Tichá instalace může také používat soubory odpovědí jako svůj datový vstup. Viz též response file (soubor odpovědí). single signon (SSO - jednotné přihlášení) Schopnost uživatele přihlásit se jednou a pak přistupovat k více aplikacím, aniž by se musel přihlašovat ke každé aplikaci samostatně. Viz též global signon (GSO). SSL
Viz Secure Sockets Layer.
SSO
Viz Single Signon (jednotné přihlášení).
step-up authentication (zvýšená autentizace) Politika chráněného objektu (POP), která je založena na předkonfigurované hierarchii úrovní autentizace a která vynucuje určitou úroveň autentizace v závislosti na politice, která je nastavena na daném zdroji. Politika POP zvýšené autentizace nenutí uživatele, aby se autentizoval pomocí více úrovní autentizace, chce-li přistoupit k danému zdroji, ale vyžaduje, aby se uživatel autentizoval minimálně na takové úrovni, která je vyžadována politikou chránící daný zdroj. suffix (přípona) Rozlišovací jméno, které určuje nejvyšší záznam v lokálně držené hierarchii adresářů. Z důvodu relativity schématu pojmenování používaného v protokolu LDAP (Lightweight Directory Access Protocol) toto Slovníček
221
rozlišovací jméno je také příponou každého dalšího záznamu v této hierarchii adresářů. Server adresářů může mít více přípon, z nichž každá určuje lokálně drženou hierarchii adresářů.
T token (1) V lokální počítačové síti jde o symbol oprávnění, který se úspěšně předává z jedné datové stanice na další, aby označil stanici, která dočasně řídí přenosové médium. Každá datová stanice má možnost získat a používat token k řízení média. Token je určitá zpráva nebo bitový vzor, který podepisuje oprávnění, které se má přenést. (2) V lokálních počítačových sítích jde o posloupnost bitů, která se předává z jednoho zařízení na další spolu s přenosovým médiem. Má-li token připojena data, stane se rámcem. trusted root (důvěryhodný zdroj) V protokolu SSL jde o veřejný klíč a přidružené rozlišovací jméno vydavatele certifikátů.
W Web Portal Manager (WPM, rozhraní WPM) Grafická aplikace založená na webu, která se používá ke správě bezpečnostní politiky produktů Tivoli Access Manager Base a WebSEAL v zabezpečené doméně. Alternativní prostředí k rozhraní příkazového řádku pdadmin. Toto grafické rozhraní umožňuje přístup vzdálenému administrátorovi a dovoluje administrátorům vytvářet domény delegovaných uživatelů a k těmto doménám přiřadit delegované administrátory. WebSEAL Proces blade produktu Tivoli Access Manager. Server WebSEAL je výkonný vícevláknový webový server, který aplikuje bezpečnostní politiku na prostor chráněných objektů. Server WebSEAL může poskytovat řešení pro jednotné přihlášení a zahrnout zdroje webových aplikačních serverů typu back-end do vlastní bezpečnostní politiky. WPM
Viz Web Portal Manager.
U uniform resource identifier (URI - jednotný identifikátor zdroje) Řetězec znaků, který se používá k identifikaci obsahu na internetu, včetně jména zdroje (adresáře a jména souboru), umístění zdroje (počítače, na kterém daný adresář a jméno souboru existuje), a způsobu, jak je k danému zdroji možné přistupovat (protokol, např. HTTP). Příkladem URI je URL. uniform resource locator (URL - jednotný lokátor zdroje, adresa URL) Posloupnost znaků, která představuje zdroje informací na počítači nebo v síti, jako např. v Internetu. Tato posloupnost znaků obsahuje (a) zkrácené jméno protokolu, který se používá k přístupu ke zdroji informací, a (b) informaci, kterou uvedený protokol použije k vyhledání zdroje informací. Například v prostředí Internetu se používají následující zkratky některých protokolů, které se používají k přístupu k různým zdrojům informací: http, ftp, gopher, telnet, news; a toto je například adresa URL domovské stránky firmy IBM: http://www.ibm.com. URI Viz uniform resource identifier (jednotný identifikátor zdroje). URL Viz uniform resource locator (jednotný lokátor zdroje, adresa URL). user (uživatel) Libovolná osoba, organizace, proces, zařízení, program, protokol nebo systém, který používá služby poskytované ostatními. user registry (registr uživatelů)
Viz registry (registr).
V virtual hosting (virtuální hostitelství) Schopnost webového serveru, která dovoluje, aby se tento objevil na Internetu jako více než jeden hostitel.
222
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Rejstřík A
C
add-hdr 60 ADI 163 ADI (authorization decision information) konfigurace vyvolání 167 přehled 163 allow-login-retry 150 AMWebARS konfigurace 168 aplikace back-end udržování stavu relace 157 architektura 1 atributy pověření cdsso 142 atributy pověření ecsso 151 autentizace 39 cíle 4 konfigurace pro virtuální hostitele 42 parametry 176 politika POP založená na síti 118 politiky 44 pořadí 44 stručná reference 195 pomocí certifikátů 64 pomocí failover cookies 78 pomocí HTTP hlaviček 95 pomocí IP adres 96 pomocí IV hlaviček 92 pomocí LTPA cookies 97 pomocí SPNEGO 69 pomocí tokenů 65 pomocí Základní autentizace 58 přehled 4 přehled konfigurace 41, 55 vícefaktorová 116 zvýšení 114 autentizace po přepnutí při selhání 78 aktualizace 84 autentizace pomocí NTLM 76 webového serveru 77 autentizace pomocí failover cookie po celé šíři domény 83 autentizace pomocí formulářů 61 autentizace pomocí NTLM 76 autentizace pomocí tokenů 65 Autentizace pomocí webového serveru 77 autorizační server konfigurace 11
cache-definitions 103 cache-refresh-interval 103 CDSSO 139 aktivace 141 cdsso_key_gen 86 certifikáty 64 cookies relace 53 create-ba-hdr 63 cred-ext-attrs 102
B BA hlavičky práce s 59 UTF-8 zakódování 63 bezpečnostní politika 3 běžné výrazy 211
© Copyright IBM Corp. 2000, 2003
Č časový limit nečinnost záznamu v paměti cache 52 časový limit nečinnosti záznamu v paměti cache časový limit relace 51
52
D databáze cache nastavení databáze 32 databáze paměti cache 28 doc-root 16 důvody selhání dodání 166 dynamická URL řízení přístupu 159 dynurl 159
E e-community-name 149 enable-failover-cookie-for-domain 91 EPAC 5 Extended Privilege Attribute Certificate (EPAC)
5
F Failover cookie jednotné přihlášení 127 failover cookies 78, 80, 82 aktivujte cokies po celé šíři domény 91 konfigurace doby trvání cookie 87 zašifrování/dešifrování dat cookie 86 failover-cdsso 86 failover-certificate 86 failover-cookie-lifetime 87 failover-cookies-keyfile 86 failover-http-request 86 failover-password 86 failover-token-card 86 formuláře autentizace 61 jednotné přihlášení 131 funkce 3
223
G Global Single sign-on - GSO GSO 128
128
H Hlavičky platformy pro utajení 25 hodnota příznaku 99, 102 HTML formuláře s odpovědí 62 HTTP hlavičky 54 autentizace 95 jednotné přihlášení 124
CH chybové stránky konfigurace 12 chybové zprávy 9 Chybové zprávy HTTP 9 chybové zprávy HTTP pro plug-in program 9 chyby IIS přizpůsobení 10 chyby, přizpůsobení pro IIS
K
10
I ID relace SSL 52 identifikace relace 39 ihs specifická konfigurace 15 iis specifická konfigurace 15 informace o rozhodnutí o autorizaci načítání 164 instalační adresář 7 IP adresy 54, 55, 96 IP adresy a rozsahy IP adres 118 iplanet viz Sun ONE 15 is-master-authn-server 149 IV hlavičky 124 autentizace 92 UTF-8 zakódování 94 iv-creds 93 iv-groups 93 iv-headers 55 iv-remote-address 93 iv-user 93 iv-user-l 93
J jazyky podpora 35 jednotné přihlášení do WebSEAL 126 e-community 144 formuláře 131 GSO 128 koncepty 123 na proxy 126 napříč doménou 139 pomocí failover cookies 127 pomocí HTTP hlaviček 124 pomocí LTPA cookies 125
224
jednotné přihlášení (pokračování) pomocí SPNEGO 69 SPNEGO 131 Windows 70 jednotné přihlášení pomocí e-community cookie 147 funkce a požadavky 145 konfigurace 149 průběh procesu 145 přehled 144 příklad 153 příklad konfigurace 153 zašifrování ″vouch-for″ tokenu 148 jméno sféry, nastavení 59
Kerberos 71 klíče domény ecsso 151 knihovna autentizace po přepnutí při selhání 79 komponenty 1 konfigurace autentizace 41 politiky 44 autentizace po přepnutí při selhání 84 autentizace pomocí certifikátů 64 autentizace pomocí webového serveru 77 autentizace pomoicí NTLM 76 autentizace virtuálních hostitelů 42 autorizační server 11 cookies relace pro relace 53 databáze cache 32 databáze paměti cache 28 failover cookies pro autentizaci 78 formuláře pro autentizaci 61 hodnota příznaku pro zpracování následující po autorizaci 102 HTTP hlavičky pro autentizaci 95 HTTP hlavičky pro relace 54 chybové stránky 12 ID relace SSL pro relace 52 IP adresa pro autentizaci 96 IP adresa pro relace 54, 55 IV hlavičky pro autentizaci 92 IV hlavičky pro relace 55 jednotné přihlášení pomocí e-community 149 Kerberos 72 LTPA cookies pro autentizaci 97 monitorování 30 následující po autorizaci 48 obnovení pověření 33 P3P 25 paměť cache pro relace/pověření 50 parametry autentizace 176 autorizační API 188 LDAP 187 obecné 173 proxy 187 relace 186 specifické pro webový server 189 pdwebpi.conf 8 pdwebpimgr.conf 9 plug-in 8 politiky autentizace 57 pro webové servery 16
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
99,
konfigurace (pokračování) protokoly 28 protokoly monitorování 28 přednastavená 57 přehled autentizace 55 přepnutí při selhání pro LDAP 24 přepnutí uživatele 19, 20 přesměrování přihlášení 98 služba rozhraní API 33 specifická pro servery 15 SPNEGO pro autentizaci 69 stanzy 173 stránky s odpovědí pro tokeny 68 tokeny pro autentizaci 65 ukládání do paměti cache požadavku HTTP virtuální hostitelé 13 Základní autentizace pro autentizaci 58 Základní autentizace pro relace 52 konfigurace modulů 41 konfigurace monitorování 30 konfigurace pracovních vláken 11 konfigurování P3P 25 kořenový adresář 7
L LDAP konfigurace přepnutí při selhání 24 rozšířené atributy 99, 102 LDAP, konfigurační parametry 187 ldap-ext-cred-tags stanza 102 log-file 16 login-form 62 login-redirect 98 login-uri 63 LTPA zpracování následující po autorizaci 98 LTPA cookies 97, 125 ltpa-keyfile 97 ltpa-password 97 ltpa-stash-file 97
M master-authn-server 149 master-http-port 150 master-https-port 150 max-session-lifetime 11 mechanismus pro autentizaci certifikáty 65 HTTP hlavička 96 pomocí formulářů 62 pomocí IP adres 97 pomocí IV hlaviček 94 přepnutí uživatele 22 tokeny 68 Základní autentizace 59 mechanismy autentizace 56 moduly 41 stručná reference 195 moduly autentizace stručná reference 195 monitorování 28 MPA 103 Multiplexing Proxy Agents 103
N napříč doménou jednotné přihlášení 139 následující po autorizaci pomocí hodnoty příznaku 99, 102 přesměrování přihlášení 98 neautentizované HTTPS 121 neautentizovaní uživatelé 120 řízení pomocí politiky 121
O 34
obnovení pověření 33 obslužné programy pdwebpi 204 pdwebpi_start 202 pdwpi-version 205 pdwpicfg -action config 206 pdwpicfg -action unconfig 208 odstraňování problémů pro Kerberos 74 SPNEGO 74 opětovná autentizace 117 oprávnění ACL 109 WebDAV 109 oprávnění ACL 109 oprávnění WebDAV 109 ovlivnění přepnutí uživatele 23
P P3P 25 hlavičky 25 paměť cache pro relace 50 parametr accept 94 parametr acct-locked-page 12 parametr auditcfg 30 parametr auditlog 30 parametr branch 14 parametr cache-refresh-interval 32 parametr cert-cdas 56 parametr cert-ssl 56 parametr cleanup-interval 11 parametr db-file 32 parametr error-page 12 parametr generate 94 parametr http-request 56 parametr id 11, 14 parametr listen-flags 32 parametr logaudit 30 parametr logflush 30 parametr login-success 12 parametr logsize 30 parametr max-entries 50 parametr max-session-lifetime 12 parametr number-of-workers 11 parametr passwd-cdas 56 parametr passwd-ldap 56 parametr protocols 14 parametr retry-limit-reached-page 12 parametr timeout 12 parametr token-cdas 56 parametr unprotected-virtual-host 13 parametr virtual-host 13 Rejstřík
225
parametr worker-size 11 parametry autentizace CDAS 56 parametry lokální autentizace 56 pdbackup 169 pdwebpi 204 pdwebpi.conf 8 pdwebpi_start 202 pdwebpimgr.conf 9 pdwpi-version 205 pdwpicfg -action config 206 pdwpicfg -action unconfig 208 pkmshelp 58 pkmslogout 57 pkmspasswd 58 plug-in autentizace 4 bezpečnostní politika 3 funkce 3 instalační adresář 7 konfigurace 11 podpora maker 10 spuštění a zastavení 9 podpora maker 10 Pokyny pro Apache 17 pro IHS 17 pro IIS 17 politika ACL 107, 109 autentizace pomocí POP založená na síti 118 hesla 111 IP adresy 118 opětovná autentizace 117 podmínky 117 vytvoření a použití 118 POP odolnosti autentizace 113 přihlášení 110 řízení neautentizovaných uživatelů 121 úroveň zabezpečení POP 120 user a global 113 zvýšení 113 politika ACL přednastavená 109 politika autentizace pomocí POP založená na síti 118 politika hesla 111 politika POP algoritmus 120 autentizace založená na síti 118 odolnost autentizace - zvýšení 113 opětovná autentizace 117 úroveň zabezpečení 120 politika pro přihlášení 110 politiky ACL 107 politiky autentizace 57 POP odolnosti autentizace IP adresa pro relace 113 použití neautentizovaného HTTPS 121 pověření získání 4 povolení přepnutí uživatele 20 proces autentizace 41 proces pro povýšení autentizace 40 protokolování 28 prověřovací záznamy 29 průběh procesu přepnutí uživatele 20
226
přehled procesu nakládání s požadavkem přepnutí při selhání pro LDAP 24 přesměrování po přihlášení 98 přihlášení vynucení 121 příkazy 201 nápověda 57 odhlášení 57 změna hesla 57
Q query-contents 16 query-log-file 16
R reauth-grace-period 51 reauth-lifetime-reset 51
S sdílená knihovna libfailoverauthn 86 služba rozhraní API 33 související publikace xvii speciální znaky 211 SPNEGO 69, 131 jednotné přihlášení 69 povolen9 73 spuštění plug-in programu 9 stanza authentication-levels 44 stanza common-modules 41 stanza modules 41 stanza pdweb-plugin 13 stanza pdweb-plugins 15 stanza proxy-if 11, 12 stanza sessions 50 stanzy, konfigurační soubor 173 stav relace pomocí cookies relace 53 pomocí HTTP hlaviček 54 pomocí ID relace SSL 52 pomocí IP adres 54, 55 pomocí IV hlaviček 55 pomocí Základní autentizace 52 správa 49 udržování 157 stránky s odpovědí pro tokeny 68 strip-hdr 60 Sun ONE specifická konfigurace 15 supply-password 60 supply-username 60
T tokeny 65 trasování 31 příkazy pdadmin typy hlaviček uvedení 95
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
31
39
U Ukládání do paměti cache požadavku HTTP ukončení relací uživatele 159 Úroveň zabezpečení politiky POP 120 use-utf8 151
34
V vf-argument 150 vf-token-lifetime 150 vf-url 150 vícefaktorová autentizace 116 vícejazyčná podpora 35 virtuální hostitelé konfigurace 13 konfigurace autentizace 42 podpora 2 vouch-for požadavek a odpověď 147 token 148 zašifrování tokenu 148 výpisy objektu 18 vysvětlení větví virtuálních hostitelů 14 vytvoření BA hlavičky 63 vývojový diagram plug-in programu 1 vyvolání dynamické ADI 167 výzva k autentizaci průběh procesu 48
W WebSEAL jednotné přihlášení na
126
Z zacházení s odpovědí 40 zacházení s požadavkem plug-in programu 39 Základní autentizace 52, 58 zálohování 169 zastavení plug-in programu 9 znovunastavení relace při opětovné autentizaci zpětná kompatibilita autentizace po přepnutí při selhání 84 zpracování anonymního klienta 120 zpracování autorizace 40 zpracování následující po autorizaci 40, 48 Zpracování předcházející autorizaci 40 zvýšení 113 aktivace 114 omezení 116 zablokování IP adresy 119
51
Rejstřík
227
228
IBM Tivoli Access Manager for e-business: Plug-in for Web Servers Integration Guide
Vytištěno v Dánsku společností IBM Danmark A/S.
SC09-3712-00