WebSEAL: Průvodce administrátora

IBM Tivoli Access Manager

򔻐򗗠򙳰

WebSEAL: Průvodce administrátora Verze 4.1

SC09-3686-01

IBM Tivoli Access Manager

򔻐򗗠򙳰

WebSEAL: Průvodce administrátora Verze 4.1

SC09-3686-01

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 D, “Poznámky”, na stránce 337.

Páté vydání (Srpen 2003) Toto vydání nahrazuje GC32-0684-01 © Copyright International Business Machines Corporation 1999, 2002. Všechna práva vyhrazena.

Obsah Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Pro koho je určena tato kniha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Co tato kniha obsahuje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Publikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Informace o vydání . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Základní informace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Informace o WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Informace o zabezpečení Webu . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii Reference pro vývojáře . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Technické dodatky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Související publikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv Online přístup k publikacím . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvi Objednání publikací . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Dostupnost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Kontakt na softwarovou podporu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Konvence používané v této knize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Konvence typu písma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii Rozdíly v operačních systémech . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii

Kapitola 1. Přehled produktu IBM Tivoli Access Manager WebSEAL . . . . . . . . . . 1 Úvod do produktů IBM Tivoli Access Manager a WebSEAL . . . Vysvětlení bezpečnostního modelu produktu Tivoli Access Manager . Prostor chráněných objektů . . . . . . . . . . . . Definice a použití politik ACL a POP . . . . . . . . . Administrativa politiky: rozhraní Web Portal Manager . . . . Ochrana webového prostoru pomocí serveru WebSEAL . . . . . Plánování a implementace bezpečnostní politiky . . . . . . . Určení typů obsahu a úrovní zabezpečení . . . . . . . . Vysvětlení autentizace serveru WebSEAL . . . . . . . . . Cíle autentizace . . . . . . . . . . . . . . . Autentizovaný a neautentizovaný přístup ke zdrojům . . . . Struktura paměti cache pro relace/pověření serveru WebSEAL . Vysvětlení spojení WebSEAL . . . . . . . . . . . . Spojení WebSEAL a škálovatelnost webového serveru . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. 1 . 3 . 3 . 4 . 6 . 6 . 8 . 8 . 9 . 10 . 10 . 11 . 12 . 14

Kapitola 2. Základní konfigurace serveru . . . . . . . . . . . . . . . . . . . . . 19 Obecné informace o serveru . . . . . . . . . . . . . . Kořenový adresář instalace produktu WebSEAL . . . . . . . Spuštění a zastavení serveru WebSEAL . . . . . . . . . Server WebSEAL znázorněný v prostoru chráněných objektů . . . Server WebSEAL vrací odpovědi ve formátu HTTP/1.1 . . . . Soubor protokolu serveru WebSEAL . . . . . . . . . . Používání konfiguračního souboru serveru WebSEAL . . . . . . Konfigurační soubor webseald.conf . . . . . . . . . . Kořenový adresář serveru WebSEAL . . . . . . . . . . Konfigurace komunikačních parametrů . . . . . . . . . . Konfigurace serveru WebSEAL pro požadavky HTTP . . . . . Konfigurace serveru WebSEAL pro požadavky HTTPS . . . . . Omezení připojení z určitých verzí SSL . . . . . . . . . Parametry pro nastavení časového limitu komunikace HTTP/HTTPS . Další parametry pro časový limit serveru WebSEAL. . . . . . Správa webového prostoru . . . . . . . . . . . . . . Kořenový adresář stromu webových dokumentů . . . . . . . Konfigurace indexování adresářů . . . . . . . . . . . Windows: Pojmenování souborů pro programy CGI . . . . . . © Copyright IBM Corp. 1999, 2002

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

19 19 20 20 20 21 21 21 23 23 23 24 24 24 25 25 26 27 28

iii

Spustitelné UNIXové soubory na hostitelském systému serveru WebSEAL Konfigurace ukládání webových dokumentů do paměti cache . . . . Zadání typů MIME dokumentů pro filtrování URL . . . . . . . Správa přizpůsobených HTTP stránek s chybovými zprávami . . . . . Podpora maker pro HTTP stránky s chybovými zprávami . . . . . Správa přizpůsobených stránek správy účtů . . . . . . . . . . Parametry a hodnoty přizpůsobené stránky . . . . . . . . . Popisy přizpůsobených HTML stránek . . . . . . . . . . . Podpora maker pro stránky správy účtů . . . . . . . . . . Podpora více lokalizací pro webové služby . . . . . . . . . . Správa certifikátů klienta a serveru. . . . . . . . . . . . . Typy souborů databáze klíčů produktu GSKit. . . . . . . . . Konfigurace parametrů databáze klíčů . . . . . . . . . . . Používání obslužného programu správy certifikátů iKeyman . . . . Konfigurace kontroly CRL . . . . . . . . . . . . . . Konfigurace paměti cache CRL . . . . . . . . . . . . . Konfigurace předvoleného protokolování HTTP . . . . . . . . . Aktivace a zakázání protokolování HTTP. . . . . . . . . . Určení typu časového označení . . . . . . . . . . . . . Určení prahových hodnot obnovy souborů protokolu . . . . . . Určení četnosti zarovnávání vyrovnávacích pamětí souboru protokolu . Obecný formát protokolu protokolu HTTP (pro soubor request.log) . . Zobrazení souboru request.log . . . . . . . . . . . . . Zobrazení souboru agent.log . . . . . . . . . . . . . . Zobrazení souboru referer.log . . . . . . . . . . . . . Konfigurace protokolování HTTP pomocí protokolování událostí . . . . Protokolování zpráv obslužnosti serveru WebSEAL . . . . . . . . Soubory prověřovacích záznamů serveru WebSEAL. . . . . . . . Konfigurace souborů prověřovacích záznamů. . . . . . . . . Záznamy monitorování HTTP . . . . . . . . . . . . . Záznamy monitorování autentizace . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28 29 31 31 33 34 34 34 35 35 37 38 39 41 41 42 42 43 43 43 44 44 44 45 45 45 46 47 47 50 51

Kapitola 3. Pokročilá konfigurace serveru . . . . . . . . . . . . . . . . . . . . . 55 Konfigurace předvolené úrovně zabezpečení . . . . . . . . . . . . . Konfigurace QOP pro jednotlivé hostitele a sítě . . . . . . . . . . . Konfigurace aktualizací a systému výzev autorizační databáze . . . . . . . Konfigurace naslouchání upozorněním o aktualizaci . . . . . . . . . Konfigurace systému výzev autorizační databáze . . . . . . . . . . Správa alokace pracovních vláken . . . . . . . . . . . . . . . . Konfigurace pracovních vláken serveru WebSEAL . . . . . . . . . . Alokace pracovních vláken pro spojení (spravedlnost spojení) . . . . . . . Replikace předřazených serverů WebSEAL . . . . . . . . . . . . . Konfigurace více instancí serveru WebSEAL . . . . . . . . . . . . . Přehled konfigurace . . . . . . . . . . . . . . . . . . . Konfigurace více instancí serveru WebSEAL na operačním systému UNIX . . . Konfigurace více instancí serveru WebSEAL na operačním systému Windows . . Odkonfigurování více instancí serveru WebSEAL . . . . . . . . . . Příkazy pro spuštění, zastavení, opětovné spuštění a dotaz na stav serveru . . . Konfigurace přepnutí uživatele . . . . . . . . . . . . . . . . . Přehled funkce přepnutí uživatele . . . . . . . . . . . . . . . Procedura konfigurace . . . . . . . . . . . . . . . . . . Používání přepnutí uživatele . . . . . . . . . . . . . . . . . Další funkční vlastnosti přepnutí uživatele . . . . . . . . . . . . Vývoj přizpůsobené služby CDAS pro přepnutí uživatele . . . . . . . . Konfigurace ukládání požadavku na straně serveru do paměti cache serveru WebSEAL Prostředí . . . . . . . . . . . . . . . . . . . . . . Proces ukládání do paměti cache na straně serveru . . . . . . . . . . Konfigurace parametrů pro ukládání do paměti cache na straně serveru . . . . Poznámky a omezení . . . . . . . . . . . . . . . . . . . Práce se znaky zakódovanými pomocí UTF-8 . . . . . . . . . . . . Předcházení zranitelnosti způsobené skriptováním napříč stranami . . . . . .

iv

IBM Tivoli Access Manager: WebSEAL: Průvodce administrátora

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . .

55 56 57 57 57 57 58 58 60 61 61 62 67 70 72 73 73 75 80 81 82 84 84 84 85 86 86 88

Prostředí . . . . . . . . . . . . . . . . . . . . . . . . . Konfigurace filtrování řetězců URL . . . . . . . . . . . . . . . . . Potlačení totožnosti serveru . . . . . . . . . . . . . . . . . . . . . Konfigurace kryptografického hardwaru pro šifrování a ukládání klíčů . . . . . . . . Podmínky a předpoklady . . . . . . . . . . . . . . . . . . . . Konfigurace serveru WebSEAL pro kryptografický hardware používající rozhraní BHAPI . Konfigurace serveru WebSEAL pro kryptografický hardware používající rozhraní PKCS#11 Nástroje pro určování problémů pro server WebSEAL . . . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

88 88 89 89 90 91 91 94

Kapitola 4. Bezpečnostní politika produktu WebSEAL . . . . . . . . . . . . . . . . 95 Politiky ACL specifické pro server WebSEAL . . . . . . . . . . /WebSEAL/ . . . . . . . . . . . . . . . . /WebSEAL//<soubor> . . . . . . . . . . . . . Oprávnění ACL serveru WebSEAL. . . . . . . . . . . . . Předvolená politika ACL pro /WebSEAL . . . . . . . . . . . Platné znaky pro jména ACL . . . . . . . . . . . . . . Politika pro přihlášení ″třikrát a dost″ . . . . . . . . . . . . . Politika uzamčení účtů u serverů WebSEAL s vyvažováním zatížení . . Syntaxe příkazu . . . . . . . . . . . . . . . . . . Politika odolnosti hesla . . . . . . . . . . . . . . . . . Nastavení politiky odolnosti hesla pomocí obslužného programu pdadmin . Syntaxe příkazu . . . . . . . . . . . . . . . . . . Příklady platného a neplatného hesla . . . . . . . . . . . . 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 . . . . . . . . . . . . . . Formulář pro přihlášení pomocí zvýšené autentizace . . . . . . . Algoritmus zvýšené autentizace . . . . . . . . . . . . . Poznámky a omezení zvýšené autentizace . . . . . . . . . . Rozlišení mezi zvýšenou a vícefaktorovou autentizací . . . . . . Metoda autentizace pomocí POP založená na síti . . . . . . . . . Konfigurace úrovní autentizace . . . . . . . . . . . . . Určení IP adres a rozsahů . . . . . . . . . . . . . . . Zablokování zvýšené autentizace pomocí IP adresy . . . . . . . Algoritmus autentizace založené na síti . . . . . . . . . . . Poznámky a omezení autentizace založené na síti . . . . . . . . Úroveň zabezpečení politiky POP . . . . . . . . . . . . . . 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 . . . .

Kapitola 5. Autentizace produktu WebSEAL

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. 95 . 95 . 95 . 95 . 96 . 96 . 96 . 97 . 98 . 98 . 99 . 99 . 100 . 100 . 101 . 101 . 102 . 103 . 103 . 104 . 104 . 105 . 105 . 106 . 107 . 107 . 107 . 107 . 108 . 108 . 108 . 108 . 108

. . . . . . . . . . . . . . . . . . . 111

Vysvětlení procesu autentizace. . . . . . . . . . . . Podporované typy dat relace . . . . . . . . . . . Podporované metody autentizace . . . . . . . . . . Správa stavu relace . . . . . . . . . . . . . . . Přehled stavu relace . . . . . . . . . . . . . . Přehled paměti cache pro relace produktů GSKit a WebSEAL . Konfigurace paměti cache pro ID relací SSL produktu GSKit . Konfigurace paměti cache pro relace/pověření serveru WebSEAL Udržování stavu relace pomocí cookies relace . . . . . . Určování platných typů dat ID relace . . . . . . . . . Konfigurace failover cookies . . . . . . . . . . . Přehled konfigurace autentizace . . . . . . . . . . . Parametry lokální autentizace . . . . . . . . . . . Parametry externí uživatelské autentizace CDAS . . . . . Přednastavená konfigurace autentizace serveru WebSEAL . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

111 112 112 112 113 113 114 114 115 117 118 121 122 122 122

Obsah

v

Konfigurace několika metod autentizace . . . . . . . . . . . . . . Výzva k přihlášení . . . . . . . . . . . . . . . . . . . . Příkazy pro odhlášení a změnu hesla . . . . . . . . . . . . . . . Zpracování následující po změně hesla . . . . . . . . . . . . . . Konfigurace Základní autentizace . . . . . . . . . . . . . . . . . Aktivace a zablokování Základní autentizace . . . . . . . . . . . . Nastavení jména sféry . . . . . . . . . . . . . . . . . . . Konfigurace mechanismu pro Základní autentizaci . . . . . . . . . . . Podmínky konfigurace . . . . . . . . . . . . . . . . . . . Konfigurace autentizace pomocí formulářů . . . . . . . . . . . . . . Aktivace a zablokování autentizace pomocí formulářů . . . . . . . . . Konfigurace mechanismu pro autentizaci pomocí formulářů . . . . . . . . Podmínky konfigurace . . . . . . . . . . . . . . . . . . . Přizpůsobení HTML formulářů s odpovědí . . . . . . . . . . . . . Konfigurace autentizace pomocí certifikátů klienta . . . . . . . . . . . . Prostředí: Vzájemná autentizace pomocí certifikátů . . . . . . . . . . Testovací certifikát serveru WebSEAL . . . . . . . . . . . . . . Aktivace a zablokování autentizace pomocí certifikátů . . . . . . . . . Konfigurace mechanismu pro autentizaci pomocí certifikátů . . . . . . . . Konfigurace autentizace pomocí HTTP hlaviček . . . . . . . . . . . . Aktivace a zablokování autentizace pomocí HTTP hlaviček . . . . . . . . Určení typů hlaviček . . . . . . . . . . . . . . . . . . . . Konfigurace mechanismu pro autentizaci pomocí HTTP hlaviček . . . . . . Podmínky konfigurace . . . . . . . . . . . . . . . . . . . Konfigurace autentizace pomocí IP adres . . . . . . . . . . . . . . Aktivace a zablokování autentizace pomocí IP adresy . . . . . . . . . . Konfigurace mechanismu pro autentizaci pomocí IP adresy . . . . . . . . Konfigurace autentizace pomocí tokenů . . . . . . . . . . . . . . . Aktivace a zablokování autentizace pomocí tokenů . . . . . . . . . . Konfigurace mechanismu pro autentizaci pomocí tokenů . . . . . . . . . Konfigurace serveru WebSEAL, aby používal knihovnu klienta SecurID . . . . Podpora agentů MPA (Multiplexing Proxy Agents) . . . . . . . . . . . Platné typy dat relací a metody autentizace . . . . . . . . . . . . . Průběh procesu autentizace pro MPA a několik klientů . . . . . . . . . Aktivace a zablokování autentizace pomocí MPA . . . . . . . . . . . Vytvoření účtu uživatele pro MPA . . . . . . . . . . . . . . . Přidání účtu MPA do skupiny webseal-mpa-servers . . . . . . . . . . Omezení autentizace pomocí MPA . . . . . . . . . . . . . . . Konfigurace opětovné autentizace založené na bezpečnostní politice . . . . . . Podmínky ovlivňující opětovnou autentizaci pomocí POP. . . . . . . . . Vytvoření a použití opětovné autentizace pomocí POP . . . . . . . . . Konfigurace vynulování a rozšíření doby trvání záznamu v paměti cache pro relace Přizpůsobení formulářů pro přihlášení pro potřeby opětovné autentizace . . . . Konfigurace opětovné autentizace založené na politice nečinnosti relace . . . . . Podmínky ovlivňující opětovnou autentizaci vyvolanou nečinností . . . . . . Aktivace opětovné autentizace vyvolané nečinností . . . . . . . . . . Vynulování a rozšíření hodnoty doby trvání záznamu v paměti cache pro relace . . Přizpůsobení formulářů pro potřeby opětovné autentizace . . . . . . . . . Konfigurace automatického přesměrování na domovskou stránku při přihlášení . . . Průběh procesu automatického přesměrování . . . . . . . . . . . . Podmínky ovlivňující automatické přesměrování . . . . . . . . . . . Konfigurace přizpůsobeného URL . . . . . . . . . . . . . . . Aktivace a zablokování automatického přesměrování . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

123 123 123 124 125 125 125 125 126 126 126 126 127 127 127 127 128 129 130 130 131 131 131 132 132 132 132 132 133 133 133 134 135 136 137 137 137 137 137 137 138 139 140 140 141 142 142 144 144 144 145 145 145

Kapitola 6. Řešení pro jednotné přihlášení mezi doménami . . . . . . . . . . . . . 147 Vysvětlení autentizace pro CDSSO . . . . . Přizpůsobení autentizace pro jednotné přihlášení Funkce a požadavky řešení CDSSO . . . . Průběh procesu autentizace pro řešení CDSSO s Konfigurace autentizace pro CDSSO . . . . . Shrnutí konfigurace CDSSO . . . . . .

vi

. . . . . . . . . . . . . . . . . . rozhraním CDMF . . . . . . . . . . . . .


. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

147 147 148 148 149 149

Aktivace a zablokování autentizace pro CDSSO . . . . . . . . Konfigurace mechanismu autentizace pro jednotné přihlášení . . . . Zašifrování dat autentizačního tokenu . . . . . . . . . . . Konfigurace časové značky tokenu . . . . . . . . . . . . Konfigurace jména označení tokenu . . . . . . . . . . . . Vytvoření HTML odkazu pro CDSSO . . . . . . . . . . . Ochrana autentizačního tokenu . . . . . . . . . . . . . Umožnění kompatibility s předchozími vydáními . . . . . . . . Vysvětlení jednotného přihlášení pomocí e-community . . . . . . . Funkce a požadavky jednotného přihlášení pomocí e-community . . . Průběh procesu e-community . . . . . . . . . . . . . . Vysvětlení e-community cookie . . . . . . . . . . . . . Vysvětlení ″vouch for″ požadavku a odpovědí . . . . . . . . . Vysvětlení “vouch for” tokenu . . . . . . . . . . . . . . Konfigurace jednotného přihlášení pomocí e-community . . . . . . . Shrnutí konfigurace e-community . . . . . . . . . . . . . Aktivace a zablokování autentizace pro e-community . . . . . . . Zadání jména e-community . . . . . . . . . . . . . . . Konfigurace mechanismu autentizace pro jednotné přihlášení . . . . Zašifrování ″vouch for″ tokenu . . . . . . . . . . . . . Konfigurace jména označení ″vouch for″ tokenu . . . . . . . . Určení hlavního autentizačního serveru (MAS) . . . . . . . . . Zadání ″vouch for″ URL . . . . . . . . . . . . . . . Konfigurace hodnot doby trvání tokenu a e-community cookie (ec-cookie) Umožnění kompatibility s předchozími vydáními . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . .

150 150 151 152 152 152 153 153 153 155 156 159 160 160 161 161 162 162 162 163 164 164 165 166 166

Kapitola 7. Spojení WebSEAL . . . . . . . . . . . . . . . . . . . . . . . . . 167 Přehled spojení WebSEAL . . . . . . . . . . . . . . . Umístění a formát databáze spojení . . . . . . . . . . . Použití hrubě strukturovaného řízení přístupu: shrnutí . . . . . . Použití jemně strukturovaného řízení přístupu: shrnutí . . . . . . Pokyny pro vytváření spojení WebSEAL . . . . . . . . . . Další odkazy na spojení WebSEAL . . . . . . . . . . . Použití programu pdadmin k vytvoření spojení . . . . . . . . . Konfigurace základního spojení WebSEAL . . . . . . . . . . Vytvoření spojení TCP typu . . . . . . . . . . . . . Vytvoření spojení SSL typu . . . . . . . . . . . . . Přidání dalších serverů typu back-end ke spojení . . . . . . . Vzájemně autentizovaná SSL spojení . . . . . . . . . . . . Server WebSEAL potvrdí certifikát serveru typu back-end . . . . Shoda rozlišovacích jmen (DN - Distinguished Name) . . . . . . Server WebSEAL se autentizuje pomocí certifikátu klienta . . . . Server WebSEAL se autentizuje pomocí hlavičky Základní autentizace. Manipulace s informacemi o totožnosti klienta ve spojeních . . . . Vytvoření TCP a SSL proxy spojení . . . . . . . . . . . . Spojení WebSEAL-na-WebSEAL přes protokol SSL . . . . . . . Modifikace URL ke zdrojům typu back-end . . . . . . . . . . Vysvětlení typů cest používaných v URL . . . . . . . . . Filtrování URL v odpovědích . . . . . . . . . . . . . Zpracování URL v požadavcích . . . . . . . . . . . . Práce s cookies z více serverů přes více spojení -j . . . . . . . Další volby spojení . . . . . . . . . . . . . . . . . Vynutit nové spojení (–f) . . . . . . . . . . . . . . Dodání totožnosti klienta v HTTP hlavičkách (–c) . . . . . . . Dodání IP adres klienta v HTTP hlavičkách (–r) . . . . . . . Omezení velikosti HTTP hlaviček generovaných serverem WebSEAL . Předání cookies relace do spojených portálových serverů (–k) . . . Podpora URL nezávislých na velikosti písma (–i) . . . . . . . Podpora stavových spojení (–s, –u) . . . . . . . . . . . Uvedení UUID serveru typu back-end pro stavová spojení (–u) . . . Spojení k systémům souborů Windows (–w) . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Obsah

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

167 167 168 168 168 169 169 170 170 170 171 172 172 173 173 173 174 175 175 176 177 178 180 182 183 184 184 186 186 187 187 187 188 190

vii

Technické poznámky k používání spojení WebSEAL . . . . . . . . Uchycení více serverů ke stejnému spojení . . . . . . . . . . Výjimky ve vynucování oprávnění přes spojení . . . . . . . . . Autentizace pomocí certifikátů přes spojení . . . . . . . . . . Práce s cookies domény . . . . . . . . . . . . . . . . Používání programu query_contents servery třetích stran . . . . . . . Instalace komponent query_contents . . . . . . . . . . . . Instalace programu query_contents na UNIXových serverech třetích stran . Instalace programu query_contents na serverech Win32 třetích stran . . Přizpůsobení query_contents . . . . . . . . . . . . . . Zabezpečení query_contents . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

191 192 192 192 193 193 193 194 194 195 196

Kapitola 8. Řešení pro jednotné přihlášení prostřednictvím spojení . . . . . . . . . 199 Konfigurace hlaviček Základní autentizace pro jednotné přihlášení . . . . . Koncepty jednotného přihlášení (Single sign-on - SSO) . . . . . . . Dodání totožnosti klienta v BA hlavičkách . . . . . . . . . . . Dodání totožnosti klienta a generického hesla . . . . . . . . . . Přeposílání informací o originální BA hlavičce klienta . . . . . . . Odstranění informací o BA hlavičce klienta . . . . . . . . . . . Dodání jmen uživatelů a hesel z GSO . . . . . . . . . . . . Používání globálního přihlášení (GSO - global sign-on) . . . . . . . . Mapování informací o autentizaci . . . . . . . . . . . . . Konfigurace spojení WebSEAL pro GSO . . . . . . . . . . . Konfigurace paměti cache GSO . . . . . . . . . . . . . . Konfigurace jednotného přihlášení k produktu IBM WebSphere (LTPA) . . . Konfigurace spojení LTPA . . . . . . . . . . . . . . . . Konfigurace paměti cache LTPA . . . . . . . . . . . . . . Technické poznámky k jednotnému přihlášení pomocí LTPA . . . . . . Konfigurace autentizace pomocí formulářů pro jednotné přihlášení . . . . . Prostředí a cíle . . . . . . . . . . . . . . . . . . . Průběh procesu jednotného přihlášení pomocí formulářů . . . . . . . Požadavky na podporu aplikace . . . . . . . . . . . . . . Vytvoření konfiguračního souboru pro jednotné přihlášení pomocí formulářů . Aktivace jednotného přihlášení pomocí formulářů . . . . . . . . . Příklad konfiguračního souboru pro IBM HelpNow . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

199 199 200 200 201 202 203 203 204 205 205 206 207 207 208 208 208 209 210 210 214 214

Kapitola 9. Integrace aplikací . . . . . . . . . . . . . . . . . . . . . . . . . . 217 Podpora programování CGI . . . . . . . . . . . Windows: Podpora proměnných prostředí WIN32 . . . . Podpora aplikací na straně serveru typu back-end . . . . . Osvědčené metody spojení pro integraci aplikací . . . . . Dodání úplné informace hlavičky HOST pomocí -v . . . Podpora standardního filtrování absolutních URL . . . . Vytváření přizpůsobené personifikované služby . . . . . Konfigurace serveru WebSEAL pro personifikovanou službu Příklad personifikované služby . . . . . . . . . Aktivace nároků dynamického obchodu (příznak/hodnota) . . Vytváření obchodních nároků z dat LDAP . . . . . . Vkládání dat pověření do HTTP hlavičky . . . . . . Udržování stavu relace mezi klientem a aplikací typu back-end . Prostředí správy relací uživatelů . . . . . . . . . Aktivace správy ID relací uživatelů . . . . . . . . Vkládání dat pověření do HTTP hlavičky . . . . . . Ukončení relací uživatele . . . . . . . . . . . Poskytování řízení přístupu k dynamickým URL . . . . . Komponenty dynamického URL . . . . . . . . . Mapování objektů ACL a POP na dynamická URL. . . . Aktualizace serveru WebSEAL pro dynamická URL . . . Rozlišování dynamických URL v prostoru objektů . . . Konfigurace omezení požadavků POST . . . . . . .

viii


. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . .

217 218 219 219 219 220 221 221 222 222 222 224 225 225 226 226 227 229 229 229 231 231 232

Souhrn a technické poznámky . . . . Příklad dynamického URL: Travel Kingdom Aplikace . . . . . . . . . . Rozhraní . . . . . . . . . . Bezpečnostní politika . . . . . . Zabezpečení klientů . . . . . . . Řízení přístupu . . . . . . . . Závěr . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

233 234 234 234 235 235 236 236

Dodatek A. Reference konfiguračního souboru serveru WebSEAL . . . . . . . . . . 237 Pokyny pro konfiguraci stanz . . . . . . . . . . . . . . . . . . Obecné pokyny . . . . . . . . . . . . . . . . . . . . . Předvolené hodnoty . . . . . . . . . . . . . . . . . . . . Řetězce . . . . . . . . . . . . . . . . . . . . . . . Definované řetězce . . . . . . . . . . . . . . . . . . . . Seznamy . . . . . . . . . . . . . . . . . . . . . . . Jména souborů . . . . . . . . . . . . . . . . . . . . . Celočíselné proměnné . . . . . . . . . . . . . . . . . . . Boolovské hodnoty . . . . . . . . . . . . . . . . . . . . Změna nastavení konfigurace . . . . . . . . . . . . . . . . . . Uspořádání stanz . . . . . . . . . . . . . . . . . . . . . . Konfigurace serveru . . . . . . . . . . . . . . . . . . . . . Registr uživatelů . . . . . . . . . . . . . . . . . . . . . . LDAP . . . . . . . . . . . . . . . . . . . . . . . . Active Directory . . . . . . . . . . . . . . . . . . . . . IBM Lotus Domino . . . . . . . . . . . . . . . . . . . . Protokol SSL (Secure Socket Layer) . . . . . . . . . . . . . . . . Autentizace . . . . . . . . . . . . . . . . . . . . . . . Mechanismy autentizace . . . . . . . . . . . . . . . . . . Knihovny autentizace . . . . . . . . . . . . . . . . . . . Opětovná autentizace . . . . . . . . . . . . . . . . . . . Autentizace při přepnutí při selhání . . . . . . . . . . . . . . . Jednotné přihlášení mezi doménami . . . . . . . . . . . . . . . Jednotné přihlášení pomocí e-community . . . . . . . . . . . . . Úroveň zabezpečení . . . . . . . . . . . . . . . . . . . . Relace . . . . . . . . . . . . . . . . . . . . . . . . . Obsah . . . . . . . . . . . . . . . . . . . . . . . . . Správa obsahu . . . . . . . . . . . . . . . . . . . . . Správa účtů . . . . . . . . . . . . . . . . . . . . . . Automatické přesměrování . . . . . . . . . . . . . . . . . . Lokální CGI . . . . . . . . . . . . . . . . . . . . . . Ikony . . . . . . . . . . . . . . . . . . . . . . . . Ukládání obsahu do paměti cache . . . . . . . . . . . . . . . . Typy MIME obsahu . . . . . . . . . . . . . . . . . . . . Kódování obsahu . . . . . . . . . . . . . . . . . . . . . Spojení. . . . . . . . . . . . . . . . . . . . . . . . . Správa spojení . . . . . . . . . . . . . . . . . . . . . Filtrování dokumentů . . . . . . . . . . . . . . . . . . . Filtrování správce událostí . . . . . . . . . . . . . . . . . . Filtrování schémat . . . . . . . . . . . . . . . . . . . . Filtrování typů MIME a hlaviček . . . . . . . . . . . . . . . . Filtrování skriptů . . . . . . . . . . . . . . . . . . . . . Paměť cache pro GSO (Global Sign-On) . . . . . . . . . . . . . . Paměť cache pro autentizaci pomocí LTPA (Lightweight Third Party Authentication) Protokolování . . . . . . . . . . . . . . . . . . . . . . . Monitorování . . . . . . . . . . . . . . . . . . . . . . . Databáze politik . . . . . . . . . . . . . . . . . . . . . . Služby nároků . . . . . . . . . . . . . . . . . . . . . . Server politik . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

237 237 238 238 238 238 239 239 240 240 241 243 248 248 253 256 259 266 267 271 275 276 278 279 282 284 286 287 288 291 292 294 296 297 298 299 300 304 305 307 308 309 311 313 315 318 321 323 324

Dodatek B. Reference spojení WebSEAL . . . . . . . . . . . . . . . . . . . . . 325 Obsah

ix

Použití programu pdadmin k vytvoření spojení . Příkazy pro spojení . . . . . . . . . Vytvořit nové spojení pro první server . . . Přidání dalšího serveru ke stávajícímu spojení .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

325 326 327 329

Dodatek C. Použití obslužného programu pdbackup pro produkt WebSEAL . . . . . . 331 Funkční vlastnosti . . . . . . . Zálohování dat: . . . . . . . Obnova dat . . . . . . . . Syntaxe . . . . . . . . . . Příklady . . . . . . . . . . Příklady pro operační systém UNIX . Příklady pro operační systém Windows Obsah souboru amwebbackup.lst . . Další data pro zálohování . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

331 331 332 332 333 333 333 334 335

Dodatek D. Poznámky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337 Ochranné známky

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

. 339

Rejstřík . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341

x


Úvod Vítejte v knize IBM® Tivoli® Access Manager WebSEAL: Průvodce administrátora. Produkt IBM Tivoli Access Manager WebSEAL je správce zabezpečení zdrojů pro zdroje založené na webu v rámci zabezpečené domény produktu Tivoli Access Manager. Server WebSEAL je vysoce výkonný vícevláknový webový server, který používá jemně strukturovanou bezpečnostní politiku, aby zabezpečil prostor webových objektů. Server WebSEAL může nabídnout řešení pro jednotné přihlášení a zahrnout zdroje webových aplikačních serverů typu back-end do své bezpečnostní politiky. Tento průvodce administrátora nabízí úplnou sadu procedur a referenčních informací pro správu zdrojů vaší zabezpečené webové domény. Tento průvodce vám dále poskytuje hodnotné informace o prostředí a konceptech řady funkčních vlastností produktu WebSEAL. 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).

Pro koho je určena tato kniha Tento průvodce je určen pro systémové administrátory odpovědné za konfiguraci a správu prostředí produktu Tivoli Access Manager WebSEAL. Čtenáři této knihy by měli znát: v operační systémy na platformě PC a operační systém UNIX® v databázovou architekturu a koncepty v správu zabezpečení ochrany dat v protokoly Internetu, včetně HTTP, TCP/IP, FTP (file transfer protocol) a telnetu 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ů.

Co tato kniha obsahuje v Kapitola 1: Přehled produktu IBM Tivoli Access Manager WebSEAL

© Copyright IBM Corp. 1999, 2002

xi

v

v

v

v

v

v v

v

v v v v

Tato kapitola vám představí důležité koncepty a funkční vlastnosti produktu WebSEAL, jako např.: organizování a zabezpečení vašeho prostoru objektů, autentizaci, získání pověření a spojení WebSEAL. Kapitola 2: Základní konfigurace serveru Tato kapitola je technickou referencí pro obecné úlohy konfigurace produktu WebSEAL, včetně používání konfiguračního souboru produktu WebSEAL, správy webového prostoru, správy certifikátů a konfigurace protokolování. Kapitola 3: Pokročilá konfigurace serveru Tato kapitola je technickou referencí pro pokročilé úlohy konfigurace produktu WebSEAL, včetně konfigurace více instancí serveru WebSEAL, konfigurace funkčnosti pro přepínání uživatelů, správy alokace pracovních vláken a konfigurace aktualizací a systému výzev autorizační databáze. Kapitola 4: Bezpečnostní politika produktu WebSEAL Tato kapitola obsahuje podrobné technické procedury pro přizpůsobení bezpečnostní politiky na WebSEAL serveru, včetně politik ACL a POP, úrovně zabezpečení, politiky zvýšené autentizace, politiky autentizace založené na síti, politiky pro přihlášení ″třikrát a dost″ a politiky odolnosti hesla. Kapitola 5: Autentizace produktu WebSEAL Tato kapitola obsahuje podrobné technické procedury pro nastavení produktu WebSEAL tak, aby mohl spravovat řadu politik autentizace, včetně jména a hesla uživatele, certifikátů klienta, SecurID token passcode, speciálních dat HTTP hlavičky a opětovné autentizace. Kapitola 6: Řešení pro jednotné přihlášení mezi doménami Tato kapitola probírá řešení pro jednotné přihlášení mezi doménami, týkající se vnější strany konfigurace WebSEAL proxy — mezi klientem a serverem WebSEAL. Kapitola 7: Spojení WebSEAL Tato kapitola je úplnou technickou referencí pro nastavení a používání spojení WebSEAL. Kapitola 8: Řešení pro jednotné přihlášení prostřednictvím spojení Tato kapitola probírá řešení pro jednotné přihlášení, týkající se vnitřní strany konfigurace WebSEAL proxy — mezi WebSEAL serverem a spojeným aplikačním serverem typu back-end. Kapitola 9: Integrace aplikací Tato kapitola prozkoumává řadu schopností produktu WebSEAL, týkajících se integrace funkčních vlastností aplikací třetích stran. Dodatek A: Reference konfiguračního souboru WebSEAL Dodatek B: Reference spojení WebSEAL Dodatek C: Použití obslužného programu pdbackup pro produkt WebSEAL Dodatek D: Poznámky

Publikace Knihovna produktu Tivoli Access Manager je rozdělena do následujících kategorií: v “Informace o vydání” na stránce xiii v “Základní informace” na stránce xiii v “Informace o WebSEAL” na stránce xiii v “Informace o zabezpečení Webu” na stránce xiii v “Reference pro vývojáře” na stránce xiv v “Technické dodatky” na stránce xiv

xii


Informace o vydání v IBM Tivoli Access Manager Karta Čtěte jako první GI11-2919-00 (am41_readme.pdf) Obsahuje informace pro instalaci a začátek práce s produktem Tivoli Access Manager. v IBM Tivoli Access Manager Release Notes SC32-1130-00 (am41_relnotes.pdf) 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-1131-01 (am41_install.pdf) Vysvětluje, jak nainstalovat, nakonfigurovat a jak provést aktualizaci softwaru Tivoli Access Manager, včetně rozhraní Web Portal Manager. v IBM Tivoli Access Manager Base: Administrativní příručka SC09-3690-01 (am41_admin.pdf) 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 WebSEAL v IBM Tivoli Access Manager WebSEAL Installation Guide SC32-1133-01 (amweb41_install.pdf) Poskytuje instrukce pro instalaci, konfiguraci a odstranění serveru WebSEAL a sady pro vývoj aplikací WebSEAL. v IBM Tivoli Access Manager WebSEAL: Průvodce administrátora SC09-3686-01 (amweb41_admin.pdf) Poskytuje podkladové materiály, administrativní procedury a informace o technických odkazech, které se používají ke správě zdrojů ve vaší zabezpečené webové doméně pomocí serveru WebSEAL.

Informace o zabezpečení Webu v IBM Tivoli Access Manager for WebSphere Application Server: Průvodce uživatele SC09-3687-01 (amwas41_user.pdf) Poskytuje instrukce pro instalaci, odstranění a administrativu produktu Tivoli Access Manager for IBM WebSphere® Application Server. v IBM Tivoli Access Manager for WebLogic Server User’s Guide SC09-3688-01 (amwls41_user.pdf) Poskytuje instrukce pro instalaci, odstranění a administrativu produktu Tivoli Access Manager for BEA WebLogic Server. v IBM Tivoli Access Manager Plug-in for Edge Server User’s Guide SC32-1138-01 (amedge41_user.pdf) Popisuje, jak nainstalovat, nakonfigurovat a administrovat aplikaci Plug-in for IBM WebSphere Edge Server. v IBM Tivoli Access Manager Plug-in for Web Servers: Průvodce uživatele SC09-3698-01 (amws41_user.pdf) 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 programu pro webové servery. Úvod

xiii

Reference pro vývojáře v IBM Tivoli Access Manager Authorization C API Developer’s Reference SC32-1140-01 (am41_authC_devref.pdf) 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 Authorization Java Classes Developer’s Reference SC32-1141-01 (am41_authJ_devref.pdf) 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 Administration C API Developer’s Reference SC32-1142-01 (am41_adminC_devref.pdf) 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 Administration Java Classes Developer’s Reference SC32-1143-01 (am41_adminJ_devref.pdf) 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 WebSEAL Developer’s Reference SC32-1135-01 (amweb41_devref.pdf) Poskytuje informace o administrativě a programování CDAS (Cross-domain Authentication Service), CDMF (Cross-domain Mapping Framework) a modulu Odolnosti hesla.

Technické dodatky v IBM Tivoli Access Manager Command Reference GC32-1107-01 (am41_cmdref.pdf) 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-1144-01 (am41_error_ref.pdf) Obsahuje vysvětlení a doporučované akce pro zprávy, které vydává produkt Tivoli Access Manager. v IBM Tivoli Access Manager Problem Determination Guide GC32-1106-01 (am41_pdg.pdf) Obsahuje informace napomáhající určení problému pro produkt Tivoli Access Manager. v IBM Tivoli Access Manager Performance Tuning Guide SC32-1145-01 (am41_perftune.pdf) 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,

xiv


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 Toolkit Produkt Tivoli Access Manager umožňuje šifrování dat pomocí produktu IBM Global Security Toolkit (GSKit). GSKit se dodává na CD-ROM IBM Tivoli Access Manager Base pro vaši určitou platformu. Sada programů GSKit instaluje obslužný program pro správu klíčů iKeyman (gsk5ikm), 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 Secure Sockets Layer Introduction and iKeyman User’s Guide (gskikm5c.pdf) Obsahuje informace pro síťové nebo systémové administrátory, kteří chtějí aktivovat SSL komunikaci v prostředí produktu Tivoli Access Manager.

IBM DB2 Universal Database

Produkt IBM DB2® Universal Database™ je vyžadován, pokud instalujete server IBM SecureWay Directory, nebo server z/OS™ a OS/390® SecureWay LDAP. DB2 se dodává na produktových CD-ROM pro následující operační systémy: v IBM AIX® v Microsoft™ Windows™ v Sun Solaris Operating Environment Informace o DB2 jsou k dispozici na následující webové stránce: http://www.ibm.com/software/data/db2/

IBM Directory Server Produkt IBM Directory Server verze 4.1 je součástí CD-ROM s názvem IBM Tivoli Access Manager Base CD, a to pro všechny platformy kromě operačního systému Linux pro platformu zSeries™. Software IBM Directory Server pro operační systém Linux pro platformu S/390 můžete získat na této webové stránce: http://www.ibm.com/software/network/directory/server/download/ Pokud chcete používat IBM Directory Server jako váš registr uživatelů, prohlédněte si informace na této webové stránce: http://www.ibm.com/software/network/directory/library/

IBM WebSphere Application Server IBM WebSphere Application Server, Advanced Single Server Edition 4.0.3 je součástí CD-ROM Web Portal Manager a je nainstalován současně s rozhraním Web Portal Manager. Další informace o produktu IBM WebSphere Application Server najdete na následujícím webovém serveru: http://www.ibm.com/software/webservers/appserv/infocenter.html

Úvod

xv

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 for e-business. Níže uvedené dokumenty, které se týkají produktu IBM Tivoli Access Manager for Business Integration verze 4.1, jsou k dispozici na webové stránce Tivoli Information Center: v IBM Tivoli Access Manager for Business Integration Administrator’s Guide (SC23-4831-00) v IBM Tivoli Access Manager for Business Integration Release Notes (GI11-0957-00) v IBM Tivoli Access Manager for Business Integration Read Me First (GI11-0958-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 for e-business. Níže uvedené dokumenty, které se týkají produktu IBM Tivoli Access Manager for Operating Systems verze 4.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)

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).

xvi


Objednání publikací Mnohé z Tivoli publikací si můžete online objednat na následujícím webovém serveru: http://www.elink.ibmlink.ibm.com/public/applications/ publications/cgibin/pbi.cgi Můžete si je také objednat telefonicky na těchto telefonních číslech: v ve Spojených státech: 800-879-2755 v v Kanadě: 800-426-4968 v seznam telefonních čísel pro ostatní země najdete na této webové stránce:http://www.ibm.com/software/tivoli/order-lit/

Dostupnost Funkce dostupnosti pomáhají uživateli s tělesným postižením, jako např. se sníženou pohyblivostí nebo omezeným viděním, ú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 na stránku podpory softwaru IBM Tivoli na této webové adrese: http://www.ibm.com/software/sysmgmt/products/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 a adresy elektronické pošty 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: 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.

Úvod

xvii

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.

xviii


Kapitola 1. Přehled produktu IBM Tivoli Access Manager WebSEAL Produkt IBM®Tivoli®Access Manager for e-business (Tivoli Access Manager) je robustní a bezpečné řešení centralizované správy politik pro aplikace elektronického obchodu a distribuované aplikace. Produkt IBM Tivoli Access Manager WebSEAL je vysoce výkonný vícevláknový webový server, který aplikuje jemně strukturovanou bezpečnostní politiku na prostor chráněných webových objektů produktu Tivoli Access Manager. Server WebSEAL může nabídnout řešení pro jednotné přihlášení a zahrnout zdroje webových aplikačních serverů typu back-end do své bezpečnostní politiky. Tato přehledová kapitola vám představí hlavní schopnosti serveru WebSEAL. Seznam témat: v “Úvod do produktů IBM Tivoli Access Manager a WebSEAL” na stránce 1 v “Vysvětlení bezpečnostního modelu produktu Tivoli Access Manager” na stránce 3 v “Ochrana webového prostoru pomocí serveru WebSEAL” na stránce 6 v “Plánování a implementace bezpečnostní politiky” na stránce 8 v “Vysvětlení autentizace serveru WebSEAL” na stránce 9 v “Vysvětlení spojení WebSEAL” na stránce 12

Úvod do produktů IBM Tivoli Access Manager a WebSEAL IBM Tivoli Access Manager: Produkt IBM Tivoli Access Manager je úplné řešení správy bezpečnostní politiky autorizace i sítě, které nabízí dosud nepřekonanou ochranu zdrojů typu ″end-to-end″ (tj. ochranu přes všechny úrovně v hierarchii systému) v geograficky rozptýlených intranetech a extranetech. Kromě této nejmodernější funkce pro správu bezpečnostní politiky produkt Tivoli Access Manager podporuje autentizaci, autorizaci, zabezpečení dat a centralizovanou správu zdrojů. Produkt Tivoli Access Manager můžete používat společně se standardními aplikacemi založenými na Internetu, abyste vybudovali vysoce zabezpečené a dobře spravované intranety. Ve svém jádru produkt Tivoli Access Manager poskytuje: v základní strukturu autentizace Produkt Tivoli Access Manager nabízí řadu zabudovaných autentizátorů a podporuje externí autentizátory. v základní strukturu autorizace Autorizační služba produktu Tivoli Access Manager, ke které je možné přistupovat prostřednictvím autorizačního rozhraní API Tivoli Access Manager, poskytuje pro žádosti o přístup ke chráněným zdrojům umístěným v zabezpečené doméně rozhodnutí povolit nebo odepřít přístup. S pomocí produktu Tivoli Access Manager je možné bezpečně řídit přístup k soukromým interním zdrojům umístěným na síti za současného rozšíření o širokou propojitelnost a snadnost použití veřejného Internetu. Produkt Tivoli Access Manager v kombinaci s firemním systémem firewallů může úplně chránit celopodnikovou intranetovou síť před neoprávněným přístupem a narušením. © Copyright IBM Corp. 1999, 2002

1

IBM Tivoli Access Manager WebSEAL: Produkt IBM Tivoli Access Manager WebSEAL je správce zdrojů, který je odpovědný za správu a zabezpečení informací a zdrojů uložených na webu. Server WebSEAL je vysoce výkonný vícevláknový webový server, který aplikuje jemně strukturovanou bezpečnostní politiku na prostor chráněných webových objektů produktu Tivoli Access Manager. Server WebSEAL může nabídnout řešení pro jednotné přihlášení a zahrnout zdroje webových aplikačních serverů typu back-end do své bezpečnostní politiky. Server WebSEAL obvykle vystupuje jako reverzní webová proxy, která přijímá HTTP/HTTPS požadavky od webových prohlížečů a která doručuje obsah, získaný ze svého vlastního webového serveru nebo ze spojených webových aplikačních serverů typu back-end. Požadavky, které procházejí přes server WebSEAL, jsou vyhodnocovány autorizační službou produktu Tivoli Access Manager, aby se určilo, zda má uživatel oprávnění přistupovat k požadovanému zdroji. Server WebSEAL poskytuje tyto funkce: v podporuje více metod autentizace Má oba typy architektury - zabudovanou i plug-in, které podporují řadu mechanismů autentizace. v přijímá požadavky HTTP a HTTPS v integruje a chrání zdroje serverů typu back-end prostřednictvím technologie spojení WebSEAL v spravuje jemně strukturované řízení přístupu pro webový prostor skládající se z lokálních serverů a serverů typu back-end Podporované zdroje zahrnují URL, regulérní výrazy založené na URL, CGI programy, HTML soubory, Java servlety a soubory třídy Javy. v pracuje jako reverzní webová proxy Server WebSEAL vystupuje pro klienty jako webový server a pro spojené servery typu back-end, které chrání, vystupuje jako webový prohlížeč. v nabízí schopnosti jednotného přihlášení

Obrázek 1. Ochrana webového prostoru pomocí serveru WebSEAL

2


Vysvětlení bezpečnostního modelu produktu Tivoli Access Manager Bezpečnostní politika zabezpečené domény produktu Tivoli Access Manager je řízena a ovládána dvěma klíčovými bezpečnostními strukturami: v registr uživatelů Registr uživatelů (jako např. LDAP, Lotus Domino, nebo Microsoft Active Directory) obsahuje všechny uživatele a skupiny, kterým je dovoleno pracovat v zabezpečené doméně produktu Tivoli Access Manager. v hlavní databáze politik autorizace (hlavní autorizační databáze) Autorizační databáze obsahuje znázornění všech zdrojů v doméně (prostor chráněných objektů). Administrátor systému může určit libovolnou úroveň zabezpečení tak, že použije pravidla, známá jako politiky přístupových seznamů (ACL - Access Control List) a politiky chráněného objektu (POP - Protected Object Policy), na ty zdroje, které vyžadují ochranu. Totožnost uživatele je serveru WebSEAL prokázána prostřednictvím procesu autentizace. Uživatel může v zabezpečené doméně pracovat jako autentizovaný nebo neautentizovaný uživatel. Pouze uživatelé, kteří mají záznam v registru uživatelů, se mohou stát autentizovanými uživateli. Pomocí přístupových seznamů a politik POP může administrátor systému nastavit některé veřejné zdroje dostupné i pro neautentizované uživatele. Ostatní zdroje mohou být dostupné pouze pro určité autentizované uživatele. Když se uživatel úspěšně autentizuje na serveru WebSEAL, bude pro tohoto uživatele vytvořena sada informací o totožnosti — známá jako pověření. Pověření obsahuje totožnost uživatele, členství ve všech skupinách a další speciální (″rozšířené″) atributy zabezpečení. Autorizační služba produktu Tivoli Access Manager vynutí uplatnění bezpečnostních politik tak, že porovná autentizační pověření uživatele s oprávněními politiky, která je přiřazena k požadovanému zdroji. Výsledné doporučení se předá správci zdrojů (např. serveru WebSEAL), který dokončí odpověď na původní požadavek. Chce-li se uživatel stát plnoprávným účastníkem zabezpečené domény, jsou pro něj klíčová jeho pověření uživatele.

Prostor chráněných objektů Prostor chráněných objektů je hierarchické zobrazení zdrojů patřících k zabezpečené doméně produktu Tivoli Access Manager. Virtuální objekty, které se objeví v hierarchickém prostoru objektů, představují skutečné síťové zdroje. v Systémový prostředek – skutečný fyzický soubor nebo aplikace. v Chráněný objekt – logické vyjádření skutečného systémového prostředku, který se používá autorizační službou, rozhraním Web Portal Manager nebo jinými obslužnými programy správy produktu Tivoli Access Manager. K objektům v prostoru objektů je možné připojit šablony politik, pomocí kterých bude zdrojům poskytována ochrana. Autorizační služba provede rozhodnutí o autorizaci na základě těchto šablon. Produkt Tivoli Access Manager používá následující kategorie prostoru objektů: v webové objekty Webové objekty představují vše, co je možné adresovat pomocí HTTP URL. To zahrnuje statické webové stránky a dynamická URL, která je možné převést na databázové dotazy nebo jiný typ aplikace. Server WebSEAL je odpovědný za ochranu webových objektů. v objekty správy produktu Tivoli Access Manager Objekty správy představují aktivity správy, které mohou být prováděny prostřednictvím rozhraní Web Portal Manager. Objekty představují úlohy, které jsou nezbytné pro definici Kapitola 1. Přehled produktu IBM Tivoli Access Manager WebSEAL

3

uživatelů a nastavení bezpečnostní politiky. Produkt Tivoli Access Manager podporuje delegaci některých aktivit týkajících se správy a může omezit schopnost administrátora nastavit bezpečnostní politiku pouze na určitou část prostoru objektů. v uživatelsky definované objekty Uživatelsky definované objekty představují úlohy definované zákazníkem nebo síťové zdroje chráněné pomocí aplikací, které používají autorizační službu volanou prostřednictvím autorizačního rozhraní API produktu Tivoli Access Manager.

Obrázek 2. Prostor chráněných objektů produktu Tivoli Access Manager

Definice a použití politik ACL a POP Administrátoři systému chrání systémové prostředky produktu Tivoli Access Manager tak, že nadefinují pravidla, známá jako politiky ACL a POP, a tyto politiky použijí k objektovému znázornění těchto zdrojů v prostoru chráněných objektů. Autorizační služba produktu Tivoli Access Manager provádí rozhodnutí o autorizaci na základě politik, které jsou připojeny k těmto objektům. Je-li požadovaná operace s chráněným objektem povolena, pak aplikace odpovědná za zdroj implementuje danou operaci. Jedna politika může určit parametry zabezpečení pro mnoho objektů. Jakákoliv změna v pravidle ovlivňuje všechny objekty, ke kterým je daná šablona připojena.

Přístupový seznam (ACL - Access Control List) Politika přístupového seznamu, nebo také politika ACL, je nastavení pravidel (oprávnění), která určují podmínky, které je nutné splnit, aby bylo možné provádět určité operace s daným zdrojem. Definice politiky ACL jsou důležitou komponentou bezpečnostní politiky, zavedenou pro zabezpečenou doménu. Politiky ACL, podobně jako všechny politiky, se používají k promítnutí požadavků organizace na zabezpečení zdrojů, znázorněných v prostoru chráněných objektů. Politika ACL konkrétně řídí: 1. jaké operace je možné provádět se zdrojem 2. kdo může tyto operace provádět Politika ACL se skládá z jednoho nebo více záznamů, které obsahují ustanovení uživatele a skupiny a jejich specifická oprávnění nebo práva. Přístupový seznam dále obsahuje pravidla, která platí pro neautentizované uživatele.

4


Obrázek 3. Politika ACL

Politiky chráněného objektu (POP - Protected Object Policies)

Politiky ACL poskytují autorizační službě informace, aby tato služba mohla odpovědět ″ano″ nebo ″ne″ na požadavek na přístup ke chráněnému objektu a na provedení nějaké operace s tímto objektem. Politiky POP obsahují další podmínky, které musí požadavek splňovat, a které autorizační služba předává zpět do produktu Tivoli Access Manager Base a správci zdrojů (jako např. serveru WebSEAL) spolu s rozhodnutím ″ano″ politiky ACL. Produkt Tivoli Access Manager a správce zdrojů jsou odpovědni za to, že vynutí splnění podmínek politiky POP. Níže uvedená tabulka vypisuje atributy, které jsou k dispozici pro politiku POP: Vynucovány produktem Tivoli Access Manager Base Atribut politiky POP

Popis

Jméno

Jméno politiky. Objevuje se jako <jméno_pop> v příkazech pdadmin pop.

Popis

Text popisující politiku. Zobrazí se v příkazu pop show.

Režim varování

Poskytuje administrátorům způsob, jak otestovat politiky ACL a POP.

Úroveň auditu

Určuje typ monitorování: all, none, successful access, denied access, errors.

Denní doba přístupu

Omezení ve dni a čase, kdy je možné úspěšně přistupovat ke chráněnému objektu.

Vynucovány správcem zdrojů (jako např. serverem WebSEAL) Atribut politiky POP

Popis

Úroveň zabezpečení

Určuje úroveň ochrany dat: none, integrity, privacy.

Metoda autentizace pomocí koncového bodu IP

Určuje požadavky autentizace na přístup členů z externích sítí.

Řízení paměti cache pro dokumenty

Uvádí instrukce pro ukládání do paměti cache, které se budou používat při obsluze určitých dokumentů.

Explicitní a zděděná politika Politika může být použita explicitně (přímo) nebo může být zděděna. Prostor chráněných objektů produktu Tivoli Access Manager podporuje dědičnost atributů politik ACL a POP. Tato vlastnost je velmi důležitá v úvahách administrátorů systémů, kteří spravují prostor

Kapitola 1. Přehled produktu IBM Tivoli Access Manager WebSEAL

5

objektů. Administrátor musí použít explicitní politiky pouze v takových bodech hierarchie, kde je nezbytně nutné změnit pravidla.

Obrázek 4. Explicitní a zděděné politiky

Administrativa politiky: rozhraní Web Portal Manager Web Portal Manager je grafická aplikace založená na webu, která se používá ke správě bezpečnostní politiky v zabezpečené doméně produktu Tivoli Access Manager. Obslužný program pdadmin s příkazovým řádkem nabízí stejné schopnosti administrativy uživatelů a skupin jako rozhraní Web Portal Manager, a navíc mnoho příkazů, které nejsou podporovány rozhraním Web Portal Manager. Z rozhraní Web Portal Manager (nebo pdadmin) můžete spravovat registr uživatelů, hlavní databázi politik autorizace a servery produktu Tivoli Access Manager. Můžete také přidávat a odstraňovat uživatele / skupiny a aplikovat politiky ACL a POP na síťové objekty.

Ochrana webového prostoru pomocí serveru WebSEAL Pokud server WebSEAL vynucuje uplatňování bezpečnostní politiky v zabezpečené doméně, pak každý klient musí poskytnout důkaz o své totožnosti. Bezpečnostní politika produktu Tivoli Access Manager dále určuje, zda má tento klient oprávnění provádět nějaké operace s požadovaným zdrojem. Jelikož přístup ke každému webovému zdroji v zabezpečené doméně je řízen serverem WebSEAL, pak požadavky serveru WebSEAL na autentizaci a autorizaci mohou nadefinovat ucelené zabezpečení ochrany dat v síti. V zabezpečených systémech se rozlišuje autorizace od autentizace. Autorizace určuje, zda má autentizovaný klient právo provádět operaci s určitým zdrojem, který je umístěn v zabezpečené doméně. Autentizace může ověřit totožnost klienta, ale neříká nic o tom, zda má klient právo provádět operace s chráněným zdrojem. V modelu autorizace produktu Tivoli Access Manager je autorizační politika implementována nezávisle na způsobu, který je používán pro autentizaci uživatelů. Uživatelé mohou prokázat svou totožnost buď pomocí veřejného/soukromého klíče, tajného klíče, nebo způsobu definovaného zákazníkem. Část procesu autentizace se zabývá vytvořením pověření, které popisuje totožnost klienta. Rozhodnutí o autorizaci, které provádí autorizační služba, jsou založena na pověřeních uživatele.

6


Zdroje v zabezpečené doméně mají nadefinovánu úroveň zabezpečení, která je nařízena bezpečnostní politikou dané domény. Bezpečnostní politika nadefinuje oprávněné účastníky zabezpečené domény a úroveň zabezpečení obklopující každý zdroj, vyžadující zabezpečení. Proces autorizace se skládá z těchto základních částí: v Správce zdrojů je odpovědný za implementaci požadovaných operací, je-li udělena autorizace. Server WebSEAL je správce zdrojů. Součástí správce zdrojů je vymahač politiky, který směruje požadavky na autorizační službu, aby je tato zpracovala. Poznámka: Tradiční aplikace balí vymahač politiky a správce zdrojů do jednoho procesu. Příkladem podobné struktury je např. produkt WebSEAL a aplikace třetích stran. v Autorizační služba, která provádí akce rozhodování pro každý požadavek. Níže uvedený diagram představuje celý proces autorizace:

Obrázek 5. Proces autorizace produktu Tivoli Access Manager

1. Požadavek autentizovaného klienta na zdroj je přesměrován na server správce zdrojů a je zachycen procesem vymahače politiky. Správce zdrojů může být server WebSEAL (pro přístup prostřednictvím protokolu HTTP nebo HTTPS), nebo aplikace jiného dodavatele. 2. Proces vymahače politiky zavolá prostřednictvím autorizačního rozhraní API produktu Tivoli Access Manager autorizační službu a požádá ji o rozhodnutí o autorizaci. 3. Autorizační služba provede kontrolu autorizace pro zdroj, který je v prostoru chráněných objektů představován objektem. Nejprve se zkontrolují základní politiky POP. Pak se zkontroluje politika ACL, která je připojena k objektu, a porovná se s pověřeními klienta. Nakonec jsou zkontrolovány politiky POP vynucované správcem zdrojů. 4. Rozhodnutí, zda požadavek je přijat nebo zamítnut, je navráceno ve formě doporučení správci zdrojů (prostřednictvím vymahače politiky). 5. Je-li požadavek nakonec schválen, správce zdrojů předá požadavek aplikaci, která je za zdroj odpovědná. 6. Klient obdrží výsledky požadované operace.


7

Plánování a implementace bezpečnostní politiky Firemní bezpečnostní politika určuje: v webové zdroje, které vyžadují zabezpečení v úroveň zabezpečení 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. 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 rozšířené atributy Rozšířené atributy jsou další hodnoty, které jsou umístěny na objektu, ACL nebo POP a které mohou číst a interpretovat aplikace třetích stran (jako např. externí autorizační služba). Klíčovou komponentou produktu Tivoli Access Manager je autorizační služba produktu Tivoli Access Manager — která povoluje nebo zamítá přístup ke chráněným objektům (zdrojům) na základě pověření uživatele a řízení přístupu umístěných na objektech. Pokud chcete úspěšně naimplementovat bezpečnostní politiku, musíte logicky zorganizovat různé typy obsahu (jak je popsáno v části “Určení typů obsahu a úrovní zabezpečení” na stránce 8) 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.

Určení typů obsahu a úrovní zabezpečení Jako administrátor systému vašeho webového prostoru musíte správně identifikovat typy obsahů dostupných různým typům uživatelů. Některý obsah musí být velmi dobře zabezpečen a bude dostupný pouze určitým uživatelům. Jiné obsahy bude možné zpřístupnit široké veřejnosti. Každý scénář zabezpečení dat má odlišné požadavky na zabezpečení a jinou konfiguraci serveru WebSEAL. Vaší odpovědností je: v znát obsah vašeho Webu v určit typy uživatelů, kteří budou požadovat přístup k tomuto obsahu v pochopit silné a slabé stránky dostupných možností konfigurace serveru WebSEAL, které je možné použít k zabezpečení tohoto obsahu Ochrana obsahu Webu se rozpadá na tři rozsáhlé kategorie: 1. veřejný obsah – přístup nevyžaduje žádnou ochranu v neautentizovaní klienti přistupují prostřednictvím protokolu HTTP v neautentizovaná pověření se používají k řízení přístupu ke zdrojům

8


v základní požadavky na konfiguraci serveru WebSEAL 2. veřejný obsah – přístup vyžaduje utajení (zašifrování) v neautentizovaní klienti přistupují prostřednictvím protokolu HTTPS v vyžaduje se šifrování, aby bylo možné ochránit citlivá data požadovaná aplikačním serverem (jako např. čísla kreditních karet nebo informace o účtech uživatelů) v neautentizovaná pověření se používají k řízení přístupu ke zdrojům v konfigurace serveru WebSEAL musí garantovat utajení 3. soukromý obsah – přístup vyžaduje autentizaci v autentizovaní klienti přistupují prostřednictvím protokolu HTTP nebo HTTPS v administrátor určuje potřebu šifrování v autentizované pověření se používá k řízení přístupu ke zdrojům. Klienti musí mít účet nadefinovaný v registru uživatelů v konfigurace serveru WebSEAL je komplexní a je nutné pečlivě zvážit všechny možnosti, aby byl určen vliv na bezpečnostní politiku

Vysvětlení autentizace serveru WebSEAL Autentizace je způsob, jak identifikovat jednotlivé procesy nebo jednotky, které se pokouší přihlásit se do zabezpečené domény. Pokud autentizaci vyžaduje jak server, tak i klient, pak se výměna nazývá vzájemná autentizace.

Obrázek 6. Vzájemná autentizace

Server WebSEAL 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. Pro autentizaci serveru WebSEAL platí níže uvedené podmínky: v Server WebSEAL podporuje standardní sadu metod autentizace. Server WebSEAL můžete přizpůsobit podle svých potřeb, aby podporoval i jiné metody autentizace. v Proces serveru WebSEAL je nezávislý na metodě autentizace. v Server WebSEAL vyžaduje totožnost klienta. Z této totožnosti server WebSEAL vytvoří autentizované (nebo neautentizované) pověření, které může použít autorizační služba produktu Tivoli Access Manager k tomu, aby určila, 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ě.


9

Cíle autentizace Přestože je server WebSEAL nezávislý na procesu autentizace, potřebuje výsledek autentizace — totožnost klienta. Proces autentizace má za následek tyto akce: 1. výsledkem procesu autentizace 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, nebo je-li úspěšně zpracován službou CDAS (Cross-domain Authentication Service). Jinak je uživatel označen jako neautentizovaný. Informace o totožnosti specifické pro danou metodu, 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. 2. server WebSEAL používá totožnost k tomu, aby získal pověření pro tohoto klienta Server WebSEAL přiřadí totožnost klienta k registrovanému uživateli produktu Tivoli Access Manager. Server WebSEAL pak vytvoří pověření odpovídající tomuto uživateli. Tomuto procesu se říká získání pověření. Pověření 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í obsahuje totožnost uživatele, členství ve všech skupinách a další speciální ″rozšířené″ atributy zabezpečení. Pokud uživatel není členem registru uživatelů (je ″anonymní″), pak server WebSEAL pro tohoto uživatele vytvoří neautentizované pověření. Pamatujte si, že přístupový seznam může obsahovat speciální pravidla pro neautentizované uživatele. Tato pověření jsou dostupná autorizační službě, která povolí nebo zamítne přístup k požadovaným objektům v prostoru chráněných objektů serveru WebSEAL. 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, aby bezpečně provozoval velké množství služeb, jako např. autorizaci, monitorování a delegaci. 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 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. Další informace o podpoře určitých metod autentizace najdete v části Kapitola 5, “Autentizace produktu WebSEAL”, na stránce 111.

Autentizovaný a neautentizovaný přístup ke zdrojům V prostředí zabezpečené domény produktu Tivoli Access Manager je totožnost uživatele prokázána serveru WebSEAL prostřednictvím procesu autentizace. Uživatel obecně může v zabezpečené doméně pracovat jako autentizovaný nebo neautentizovaný uživatel. V každém případě autorizační služba produktu Tivoli Access Manager vyžaduje pověření uživatele, aby mohla provést rozhodnutí o autorizaci pro požadavky na zdroje v zabezpečené doméně. Server WebSEAL zpracovává pověření autentizovaných uživatelů odlišně od pověření neautentizovaných uživatelů. Pověření pro neautentizovaného uživatele je pouze obecný klíč, který dovolí uživatelům pracovat v zabezpečené doméně a přistupovat ke zdrojům, které jsou neautentizovaným uživatelům k dispozici. Pověření pro autentizovaného uživatele je jedinečný klíč, který popisuje určitého uživatele patřícího do registru uživatelů produktu Tivoli Access Manager (nebo který byl úspěšně

10


zpracován službou CDAS). Pověření autentizovaného uživatele obsahuje totožnost uživatele, členství ve všech skupinách a další speciální (″rozšířené″) atributy zabezpečení. Průběh zpracování autentizovaných uživatelů: v Uživatel vydá požadavek na zdroj chráněný serverem WebSEAL. Ochrana zdroje vyžaduje, aby se uživatel autentizoval. Server WebSEAL vyzve uživatele, aby se přihlásil. v Úspěšná autentizace nastane pouze tehdy, pokud je uživatel členem registru uživatelů produktu Tivoli Access Manager nebo je obsluhován operací CDAS. v Pro tohoto uživatele se vytvoří ID relace WebSEAL. v Pověření pro tohoto uživatele se vytvoří z informací, které byly uvedeny v registru uživatelů o tomto uživateli (jako např. členství ve skupinách). v ID relace a pověření, plus další data, jsou uloženy jako záznam v paměti cache pro relace/pověření serveru WebSEAL. v Během zpracovávání tohoto požadavku serverem WebSEAL (a pro další požadavky během stejné relace) jsou informace o pověření uchovávány. v Kdykoliv bude vyžadována kontrola autorizace, autorizační služba produktu Tivoli Access Manager použije v procesu rozhodování o přístupu informace v pověření. v Když se uživatel odhlásí, záznam v paměti cache pro daného uživatele bude vymazán a relace bude ukončena. Průběh zpracování neautentizovaných uživatelů: v Uživatel vydá požadavek na zdroj chráněný serverem WebSEAL. Ochrana zdroje nevyžaduje, aby se uživatel autentizoval. Server WebSEAL nevyzve uživatele, aby se přihlásil. v Server WebSEAL vytvoří neautentizované pověření pro tohoto uživatele. v V paměti cache pro relace/pověření serveru WebSEAL nebude vytvořen žádný záznam. v Uživatel může přistupovat ke zdrojům, které mají nastaveny správná oprávnění pro neautentizované uživatele. v Pokud uživatel vyžaduje přístup ke zdroji, který není neautentizovaným uživatelům dostupný, server WebSEAL vyzve uživatele, aby se přihlásil. v Úspěšné přihlášení změní stav uživatele na autentizovaného uživatele. v Pokud nebude přihlášení úspěšné, zobrazí se zpráva 403 ″Zakázáno″. Uživatel může i nadále pracovat s dalšími zdroji, které jsou dostupné neautentizovaným uživatelům.

Struktura paměti cache pro relace/pověření serveru WebSEAL Paměť cache pro relace serveru WebSEAL je také známá jako paměť pro pověření serveru WebSEAL. Paměť cache je představována interní tabulkou, do které server WebSEAL ukládá informace o všech relacích, vytvořených autentizovanými uživateli.


11

Obrázek 7. Paměť cache pro relace/pověření serveru WebSEAL

Každá relace uživatele je přestavována záznamem v paměti cache. Každý záznam v paměti cache obsahuje následující typy informací: v ID relace ID relace je jedinečným identifikátorem, který se posílá s každým požadavkem vytvořeným daným uživatelem. ID relace identifikuje určitý záznam v paměti cache tohoto uživatele. v data paměti cache Nejdůležitější data, uložená v záznamu paměti cache, jsou pověření uživatele. Pověření se vyžaduje vždy, když uživatel požaduje chráněný zdroj. Autorizační služba používá informace pověření, aby povolila nebo zamítla přístup k tomuto zdroji. Server WebSEAL může označit, nebo ″signalizovat″, záznam paměti cache, aby podpořil určitou funkční vlastnost. Pokud je například aktivována opětovná autentizace při nečinnosti relace, pak záznam paměti cache ″signalizuje″, že doba nečinnosti relace byla překročena. v časová označení Časové označení vytvoření záznamu paměti cache je referenčním bodem pro hodnotu doby trvání relace. Časové označení ″poslední aktivní″ záznamu paměti cache je referenčním bodem pro časovač nečinnosti relace. Pověření uživatele obsahuje: v jméno uživatele v členství ve skupinách v rozšířené atributy Rozšířené atributy vám dovolují uložit přizpůsobená data v pověření uživatele. Příkladem rozšířeného atributu pověření je atribut tagvalue_user_session_id. Hodnota tohoto atributu může být vložena do HTTP hlavičky. Tak dovolíte spojenému serveru typu back-end udržovat stav relace s uživatelem.

Vysvětlení spojení WebSEAL Produkt Tivoli Access Manager poskytuje služby autentizace, autorizace a správy sítě. V sítích založených na Webu je nejlepší provádět tyto služby pomocí jednoho nebo více předřazených serverů WebSEAL, které integrují a chrání webové zdroje a aplikace umístěné na webových serverech typu back-end.

12


Připojení mezi serverem WebSEAL a webovým aplikačním serverem typu back-end se nazývá spojení WebSEAL. Spojení WebSEAL je připojení TCP/IP mezi předřazeným serverem WebSEAL a serverem typu back-end. Server typu back-end může být další server WebSEAL, nebo častěji webový aplikační server třetí strany. Webový prostor serveru typu back-end je ″spojen″ se serverem WebSEAL ve speciálně označeném bodě spojení (uchycení) webového prostoru WebSEAL.

Obrázek 8. Spojení propojují servery WebSEAL a servery typu back-end

Spojení dovoluje produktu WebSEAL nabízet služby zabezpečení dat v zastoupení serveru typu back-end. Server WebSEAL může provádět kontroly autentizace a autorizace všech požadavků, než předá tyto požadavky na servery typu back-end. Pokud server typu back-end vyžaduje jemně strukturované řízení přístupu pro své objekty, musíte provést další konfigurační kroky, abyste popsali webový prostor třetí strany bezpečnostní službě produktu Tivoli Access Manager (viz “Používání programu query_contents servery třetích stran” na stránce 193). Spojení nabízí škálovatelné a bezpečné prostředí, které dovoluje vyvažování zatížení, vysokou dostupnost a schopnosti správy stavu — a to vše je prováděno pro klienty zcela transparentně. Jako administrátor můžete z této centralizované správy webového prostoru pouze získat. Spojení WebSEAL poskytují přidanou hodnotu díky logické kombinaci webového prostoru serverů typu back-end a webového prostoru serveru WebSEAL. Výsledkem spojení mezi spolupracujícími servery je jednoduchý, unifikovaný a distribuovaný webový prostor, který je pro uživatele souvislý a transparentní. Klient nikdy nemusí znát fyzické umístění webového zdroje. Server WebSEAL přeloží logické adresy URL na fyzické adresy, které očekává server typu back-end. Webové objekty je možné přesunovat ze serveru na server, aniž byste ovlivnili způsob, jakým klient přistupuje k těmto objektům. Jednotný webový prostor zjednodušuje správu všech zdrojů. Dalšími administrativními výhodami je škálovatelnost, vyvažování zatížení a vysoká dostupnost.


13

Obrázek 9. Výsledkem spojení WebSEAL je jednotný webový prostor

Většina komerčních webových serverů nemá schopnost definovat logická jména webových objektů. Namísto toho jejich řízení přístupu je připojeno ke struktuře fyzických souborů a adresářů. Spojení WebSEAL mohou transparentně nadefinovat prostor objektů, který zohledňuje organizační strukturu, namísto fyzických počítačů a adresářové struktury, jejichž definice je možné běžně nalézt na standardních webových serverech. Spojení WebSEAL vám dále umožňují vytvořit řešení pro jednotné přihlášení. Konfigurace jednotného přihlášení dovolí uživateli přistupovat ke zdroji bez ohledu na umístění zdroje, a to pomocí pouze jediného prvního přihlášení. Jakýkoliv další požadavek na přihlášení ze serveru typu back-end je pro uživatele zpracován transparentně. Spojení WebSEAL jsou důležitým nástrojem pro škálovatelnost velikosti vašeho webového prostoru. Spojení vám dovolí odpovídat na zvýšené požadavky na webový server tak, že přidáte další servery.

Spojení WebSEAL a škálovatelnost webového serveru Spojení WebSEAL se používají k vytvoření škálovatelného webového serveru. Jak rostou nároky na webový server, je možné snadno přidávat další servery, aby byly rozšířeny schopnosti tohoto webového serveru. Další servery je možné přidávat z těchto důvodů: v pokud chcete rozšířit webový server o další obsah v pokud chcete duplikovat stávající obsah z důvodu vyvažování zatížení, přepnutí při selhání a vysoké dostupnosti

14


Replikované předřazené servery WebSEAL Podpora spojení začíná pro servery typu back-end minimálně jedním předřazeným serverem WebSEAL. Replikované předřazené servery WebSEAL nabízí webovému serveru vyvažování zatížení během časových intervalů s vysokými nároky. Mechanismus vyvažování zatížení je obsluhován např. produktem IBM Network Dispatcher nebo produktem Cisco Local Director. Replikace předřazených serverů dále poskytuje webovému serveru možnost přepnutí při selhání — pokud server z nějakého důvodu selže, zbývající replikovaný server bude pokračovat v poskytování přístupu k webovému serveru. Výsledkem úspěšné implementace vyvažování zatížení a schopnosti pro přepnutí při selhání je vysoká dostupnost webového serveru pro koncové uživatele.

Obrázek 10. Replikované předřazené servery WebSEAL

Pokud replikujete předřazené servery WebSEAL, pak každý server musí obsahovat naprosto stejnou kopii webového prostoru a databáze spojení. Informace o účtech pro autentizaci jsou umístěny v registru uživatelů, který je nezávislý na předřazených serverech.

Podpora serverů typu back-end Obsah webového serveru může být obsluhován vlastním serverem WebSEAL, servery typu back-end, nebo kombinací obou. Podpora spojení WebSEAL pro servery typu back-end vám dovoluje přizpůsobit webový prostor pro další obsah a zdroje. Každý jedinečný server typu back-end musí být spojen k určitému bodu spojení (uchycení). Jak nároky na další obsah porostou, je možné prostřednictvím spojení přidat více serverů. Tento scénář nabízí řešení pro sítě, kde se masivně investovalo do webových serverů třetích stran.


15

Obrázek 11. Spojení serverů typu back-end

Níže uvedený diagram ukazuje, jak je možné pomocí spojení vytvořit jednotný logický prostor objektů. Tento webový prostor je pro uživatele transparentní a umožňuje centralizovanou správu.

Obrázek 12. Jednotný webový prostor

Replikované servery typu back-end jsou spojeny se stejným bodem spojení, jak bude vysvětleno v následující části.

16


Replikované servery typu back-end Chcete-li rozšířit možnost škálovatelnosti na konfiguraci serverů typu back-end, můžete replikovat i servery typu back-end. V případě replikovaných předřazených serverů musí replikované servery typu back-end obsahovat webové prostory, které jsou vzájemným zrcadlovým obsahem jich samých. Server WebSEAL vyvažuje zatížení mezi replikované servery pomocí plánovacího algoritmu pro ″nejméně-zatíženého″. Tento algoritmus směruje každý nový požadavek na server, který momentálně zpracovává nejméně připojení. Server WebSEAL dále provede správné přepnutí, pokud je server mimo provoz, a začne znovu používat tento server, jakmile se tento server znovu spustí. Pokud aplikace typu back-end vyžaduje, aby byl udržován stav přes několik stránek, pak můžete pomocí stavových spojení zajistit, že každá relace bude vrácena na stejný server typu back-end.

Obrázek 13. Replikované servery typu back-end


17

18


Kapitola 2. Základní konfigurace serveru Tato kapitola obsahuje informace, které popisují základní sadu administrativních a konfiguračních úloh, které můžete provést pro přizpůsobení serveru WebSEAL pro potřeby vaší sítě. Viz též Kapitola 3, “Pokročilá konfigurace serveru”, na stránce 55. Seznam témat: v “Obecné informace o serveru” na stránce 19 v “Používání konfiguračního souboru serveru WebSEAL” na stránce 21 v “Konfigurace komunikačních parametrů” na stránce 23 v “Správa webového prostoru” na stránce 25 v v v v v v v

“Správa přizpůsobených HTTP stránek s chybovými zprávami” na stránce 31 “Správa přizpůsobených stránek správy účtů” na stránce 34 “Podpora více lokalizací pro webové služby” na stránce 35 “Správa certifikátů klienta a serveru” na stránce 37 “Konfigurace předvoleného protokolování HTTP” na stránce 42 “Konfigurace protokolování HTTP pomocí protokolování událostí” na stránce 45 “Protokolování zpráv obslužnosti serveru WebSEAL” na stránce 46

Obecné informace o serveru Níže uvedené části poskytují obecné informace o serveru WebSEAL: v “Kořenový adresář instalace produktu WebSEAL” na stránce 19 v “Spuštění a zastavení serveru WebSEAL” na stránce 20 v “Server WebSEAL znázorněný v prostoru chráněných objektů” na stránce 20 v “Server WebSEAL vrací odpovědi ve formátu HTTP/1.1” na stránce 20 v “Soubor protokolu serveru WebSEAL” na stránce 21

Kořenový adresář instalace produktu WebSEAL Programové soubory produktu WebSEAL jsou nainstalovány do tohoto kořenového adresáře: UNIX: /opt/pdweb/

Windows: C:\Program Files\Tivoli\PDWeb\

Tuto cestu můžete nakonfigurovat při instalaci produktu Tivoli Access Manager na operačním systému Windows. Nakonfigurovat ji nemůžete při instalaci produktu Tivoli Access Manager na operačních systémech UNIX. Tento průvodce používá proměnnou , 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 auditovací soubory, jejichž velikost může v čase významně růst: /var/pdweb/


19

Spuštění a zastavení serveru WebSEAL Pokud chcete spustit nebo zastavit server WebSEAL, použijte příkaz pdweb (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: pdweb {start|stop|restart|status}

Příkaz pdweb je umístěn v následujícím adresáři: /usr/bin/

Chcete-li například zastavit server WebSEAL, a pak jej znovu spustit, použijte: # /usr/bin/pdweb restart

Windows: Označte proces serveru WebSEAL v Services Control Panel (Ovládacím panelu Služby) a použijte odpovídající řídicí tlačítka.

Server WebSEAL znázorněný v prostoru chráněných objektů Parametr server-name v konfiguračním souboru webseald.conf uvádí bod v prostoru chráněných objektů produktu Tivoli Access Manager, který představuje uvedenou instanci serveru WebSEAL. Při jedné instalaci serveru WebSEAL je tato hodnota automaticky nastavena na jméno hostitele počítače, na kterém je tento server WebSEAL nainstalován. Pokud je například jméno počítače (hostitele) obchodnici1, pak bude hodnota tohoto parametru nastavena následovně: [server] server-name = obchodnici1

Znázornění této instance serveru WebSEAL v prostoru chráněných objektů produktu Tivoli Access Manager by mohla vypadat například takto: /WebSEAL/obchodnici1

Viz též: “Replikace předřazených serverů WebSEAL” na stránce 60. Je-li na stejném počítači nadefinováno více instancí serveru WebSEAL, pak je tato hodnota nastavena pomocí volby –i ve skriptu PDWeb_config (UNIX) nebo ivweb_setup (Windows), který se používá k vytvoření více instancí serveru WebSEAL. Viz též: “Konfigurace více instancí serveru WebSEAL” na stránce 61.

Server WebSEAL vrací odpovědi ve formátu HTTP/1.1 Požadavky ve formátu HTTP/1.0 jsou odesílány na spojené servery typu back-end pouze tehdy, pokud tyto servery vrátily stav 400 (Špatný požadavek), stav 504 (verze HTTP není podporována), nebo pokud prohlížeč klienta uvedl v požadavku formát HTTP/1.0. V ostatních případech, pokud servery typu back-end akceptují protokol HTTP/1.1, server WebSEAL odesílá požadavky ve formátu HTTP/1.1. Přestože však server WebSEAL odešle na spojený server typu back-end požadavek ve formátu HTTP/1.0 (a server typu back-end vrátí odpověď ve formátu HTTP/1.0), server WebSEAL vždy vrací prohlížeči klienta odpověď ve formátu HTTP/1.1.

20


Soubor protokolu serveru WebSEAL Soubor protokolu serveru WebSEAL zaznamenává zprávy obslužnosti, jako např. varování serveru nebo chybové zprávy. Jméno a umístění souboru protokolu je nadefinováno pomocí parametru server-log ve stanze [logging] konfiguračního souboru webseald.conf: UNIX: [logging] server-log = /var/pdweb/log/msg_webseald.log

Windows: [logging] server-log = C:/Program Files/Tivoli/PDWeb/log/msg_webseald.log

Viz též “Protokolování zpráv obslužnosti serveru WebSEAL” na stránce 46.

Používání konfiguračního souboru serveru WebSEAL Níže uvedené části poskytují informace o konfiguračním souboru serveru WebSEAL (webseald.conf): v “Konfigurační soubor webseald.conf” na stránce 21 v “Kořenový adresář serveru WebSEAL” na stránce 23

Konfigurační soubor webseald.conf Činnost serveru WebSEAL můžete přizpůsobit tak, že nakonfigurujete parametry v konfiguračním souboru webseald.conf. Soubor je umístěn v následujícím adresáři: UNIX: /opt/pdweb/etc/

Windows: C:\Program Files\Tivoli\PDWeb\etc\

Konfigurační soubory produktu Tivoli Access Manager jsou textové ASCII soubory a je možné je editovat pomocí běžných textových editorů. Konfigurační soubory obsahují záznamy parametrů v následujícím formátu: parametr = hodnota

Výchozí instalace produktu Tivoli Access Manager zavede předvolené hodnoty pro většinu parametrů. Některé parametry jsou statické a nikdy se nemění. Jiné parametry je možné upravovat a tak přizpůsobit funkcionalitu a výkonnost serveru. Každý soubor obsahuje části, nebo také stanzy, které obsahují jeden nebo více parametrů pro určitou kategorii konfigurace. Označení stanzy je v hranatých závorkách: [jméno_stanzy]

Například stanza [junction] v konfiguračním souboru webseald.conf definuje nastavení konfigurace týkající se spojení WebSEAL. Stanza [authentication-mechanisms] definuje mechanismy autentizace podporované serverem WebSEAL spolu s příslušnými přidruženými sdílenými knihovnami. Konfigurační soubory obsahují komentáře, které vysvětlují použití každého parametru. Znak ″#″ se používá k označení řádek, které obsahují komentář. Všechny řádky s komentářem začínají znakem ″#″. Z tohoto důvodu není znak ″#″ platným znakem v hodnotách parametrů. Poznámka: Kdykoliv provedete jakoukoliv změnu v souboru webseald.conf, musíte ručně znovu spustit server WebSEAL, aby byly nově provedené změny tímto produktem zaznamenány. Viz “Spuštění a zastavení serveru WebSEAL” na stránce 20.

Kapitola 2. Základní konfigurace serveru

21

Níže uvedená tabulka podává stručný přehled částí a stanz, které jsou obsaženy v konfiguračním souboru webseald.conf: Části

22

Stanzy

WEBSEAL OBECNÉ

[server]

LDAP

[ldap]

ACTIVE DIRECTORY

[uraf-ad]

DOMINO

[uraf-domino]

SSL

[ssl]

SPOJENÍ

[junction] [filter-url] [filter-events] [filter-schemes] [filter-content-types] [filter-request-headers] [script-filtering] [gso-cache] [ltpa-cache]

AUTENTIZACE

[ba] [forms] [token] [certificate] [http-headers] [auth-headers] [ipaddr] [authentication-levels] [mpa] [cdsso] [cdsso-peers] [failover] [failover-attributes] [e-community-sso] [e-community-domain-keys] [reauthentication] [authentication-mechanisms] [ssl-qop] [ssl-qop-mgmt-hosts] [ssl-qop-mgmt-networks] [ssl-qop-mgmt-default]

RELACE

[session]

OBSAH

[content] [acnt-mgt] [enable-redirects] [cgi] [cgi-types] [cgi-environment-variable] [content-index-icons] [icons] [content-cache] [content-mime-types] [content-encodings]

PROTOKOLOVÁNÍ

[logging]

AUTORIZAČNÍ API

[aznapi-configuration] [aznapi-entitlement-services]


Části POLICY DIRECTOR

Stanzy [policy-director] [manager]

Viz Dodatek A, “Reference konfiguračního souboru serveru WebSEAL”, na stránce 237.

Kořenový adresář serveru WebSEAL Parametr server-root v konfiguračním souboru webseald.conf definuje pro ostatní parametry v tomto souboru umístění kořenového adresáře serveru WebSEAL. Všechna jména relativních cest, uvedená v konfiguračním souboru webseald.conf, se vztahují k tomuto kořenovému adresáři. UNIX: [server] server-root = /opt/pdweb/www

Windows: [server] server-root = C:\Program Files\Tivoli\PDWeb\www

Poznámka: Za normálních podmínek nemusíte tuto cestu měnit.

Konfigurace komunikačních parametrů Níže uvedené části popisují obecné informace o serveru WebSEAL: v “Konfigurace serveru WebSEAL pro požadavky HTTP” na stránce 23 v “Konfigurace serveru WebSEAL pro požadavky HTTPS” na stránce 24 v “Omezení připojení z určitých verzí SSL” na stránce 24 v “Parametry pro nastavení časového limitu komunikace HTTP/HTTPS” na stránce 24 v “Další parametry pro časový limit serveru WebSEAL” na stránce 25

Konfigurace serveru WebSEAL pro požadavky HTTP Server WebSEAL obvykle obsluhuje mnoho požadavků HTTP od neautentizovaných uživatelů. Je například běžné povolit anonymním uživatelům přístup pouze pro čtení k určitým dokumentům, které jsou umístěny ve veřejné části vašeho webového serveru. Parametry, které obsluhují požadavky HTTP obdržené prostřednictvím protokolu TCP, jsou umístěny ve stanze [server] konfiguračního souboru webseald.conf.

Povolit/zakázat přístup HTTP Povolit nebo zakázat přístup HTTP během konfigurace serveru WebSEAL: http = {yes|no}

Servery IBM HTTP Server, WebSphere Application Server (který se nainstaluje jako IBM HTTP Server) a server WebSEAL používají port 80 jako svůj předvolený port. Pokud nainstalujete server WebSEAL na stejném počítači jako server IBM HTTP Server, přesvědčete se, že jste změnili předvolený port na jednom z uvedených serverů. Editujte konfigurační soubor httpd.conf nebo webseald.conf.

Nastavení hodnoty portu pro přístup HTTP Předvolený port pro přístup HTTP je 80: http-port = 80

Chcete-li například změnit port na hodnotu 8080, nastavte: Kapitola 2. Základní konfigurace serveru

23

http-port = 8080

Konfigurace serveru WebSEAL pro požadavky HTTPS Parametry, které obsluhují požadavky HTTP obdržené prostřednictvím SSL (HTTPS), jsou umístěny ve stanze [server] konfiguračního souboru webseald.conf.

Povolit/zakázat přístup HTTPS Povolit nebo zakázat přístup HTTP během konfigurace serveru WebSEAL: https = {yes|no}

Nastavení hodnoty portu pro přístup HTTPS Předvolený port pro přístup HTTPS je 443: https-port = 443

Chcete-li například změnit port na hodnotu 4343, nastavte: https-port = 4343

Omezení připojení z určitých verzí SSL Můžete nezávisle povolit nebo zakázat propojitelnost pro SSL (Secure Sockets Layer) verzi 2, SSL verzi 3 a TLS (Transport Layer Security) verzi 1. Parametry, které řídí připojení pro určité verze protokolů SSL a TLS, jsou umístěny ve stanze [ssl] konfiguračního souboru webseald.conf. Standardně jsou povoleny všechny verze protokolu SSL a TLS. [ssl] disable-ssl-v2 = { yes | no } disable-ssl-v3 = { yes | no } disable-tls-v1 = { yes | no }

Parametry pro nastavení časového limitu komunikace HTTP/HTTPS Server WebSEAL používá implementaci protokolu SSL, která je součástí produktu IBM Global Security Kit (GSKit). Když server WebSEAL obdrží požadavek od klienta HTTPS, SSL protokol produktu GSKit naváže úvodní předávání řídicích signálů (handshake) a udržuje stav relace. Server WebSEAL podporuje níže uvedené parametry pro nastavení časového limitu komunikace HTTP a HTTPS. Tyto parametry jsou umístěny ve stanze [server] konfiguračního souboru webseald.conf. v client-connect-timeout Jakmile se objeví výchozí předávání řídicích signálů (handshake), pak tento parametr určuje serveru WebSEAL, jak dlouho má tento server udržovat dané propojení otevřené pro původní požadavek HTTP nebo HTTPS. Předvolená hodnota je 120 vteřin. [server] client-connect-timeout = 120

v persistent-con-timeout Po prvním požadavku HTTP a odpovědi serveru tento parametr řídí maximální počet vteřin, po který server WebSEAL drží trvalé propojení HTTP otevřené, než bude toto propojení ukončeno. Předvolená hodnota je 5 vteřin. [server] persistent-con-timeout = 5

24


Obrázek 14. Parametry pro časový limit komunikace HTTP a HTTPS

Další parametry pro časový limit serveru WebSEAL Níže uvedené dodatečné parametry pro časový limit jsou nastaveny v konfiguračním souboru webseald.conf. Parametr

Předvolená hodnota (vteřiny)

Popis

[junction] http-timeout

Hodnota časového limitu, týkající se odesílání a čtení ze serveru typu back-end prostřednictvím spojení TCP.

120

[junction] https-timeout

Hodnota časového limitu, týkající se odesílání a čtení ze serveru typu back-end prostřednictvím spojení SSL.

120

[cgi] cgi-timeout

Hodnota časového limitu, týkající se odesílání a čtení z lokálního procesu CGI.

120

[junction] ping-time

Server WebSEAL provádí pravidelné testování spojení pomocí příkazu ping na pozadí pro každý spojený server, aby určil, zda je tento funkční. Server WebSEAL nebude provádět testy častěji než každých 300 vteřin (nebo podle zadané hodnoty).

300

Správa webového prostoru Níže uvedené části popisují úlohy, které se týkají správy webového prostoru: v “Kořenový adresář stromu webových dokumentů” na stránce 26 v “Konfigurace indexování adresářů” na stránce 27 v “Windows: Pojmenování souborů pro programy CGI” na stránce 28 v “Konfigurace ukládání webových dokumentů do paměti cache” na stránce 29 v “Zadání typů MIME dokumentů pro filtrování URL” na stránce 31


25

Kořenový adresář stromu webových dokumentů Umístění stromu webových dokumentů je absolutní cesta ke kořeni stromu dokumentů. To platí pro zdroje dokumentů, které byly zpřístupněny prostřednictvím serveru WebSEAL. Uvedená cesta je zadána v parametru doc-root ve stanze [content] konfiguračního souboru webseald.conf. Předvolené umístění se nastavuje během instalace produktu WebSEAL: UNIX: [content] doc-root = /opt/pdweb/www/docs

Windows: [content] doc-root = C:\Program Files\Tivoli\PDWeb\www\docs

Tuto hodnotu použijete pouze jednou — když poprvé spustíte server WebSEAL po dokončení instalace. Tato hodnota je pak uložena v databázi spojení. Budoucí změny této hodnoty v konfiguračním souboru webseald.conf nemají žádný vliv. Jak změnit kořen dokumentů po dokončení instalace: Chcete-li změnit hodnotu umístění kořenového adresáře dokumentů po dokončení instalace, musíte použít obslužný program pdadmin. Níže uvedený příklad (jméno počítače (nebo také hostitele) je websealA) předvádí potřebnou proceduru: 1. Přihlašte se do obslužného programu pdadmin: # pdadmin pdadmin> login Zadejte ID uživatele: sec_master Zadejte heslo: pdadmin>

2. Použijte příkaz server task list a zobrazí se všechny aktuální body spojení: pdadmin> server task webseald-websealA list /

3. Použijte příkaz server task show a zobrazí se podrobné informace o spojení: pdadmin> server task webseald-websealA show / Bod spojení: / Typ: Lokální Pevný limit spojení: 0 - bude použita globální hodnota Slabý limit spojení: 0 - bude použita globální hodnota Počet aktivních pracovních vláken: 0 Kořenový adresář: /opt/pdweb/www/docs

4. Vytvořte nové lokální spojení, které přepíše aktuální bod spojení (volba -f se vyžaduje, pokud chcete vynutit vytvoření nového spojení, které přepíše stávající spojení): pdadmin> server task webseald-websealA create -t local -f -d /tmp/docs / Vytvořeno spojení na /

5. Vypište nové body spojení: pdadmin> server task webseald-websealA list /

6. Zobrazte podrobné informace o spojení: pdadmin> server task webseald-websealA show / Bod spojení: / Typ: Lokální Pevný limit spojení: 0 - bude použita globální hodnota Slabý limit spojení: 0 - bude použita globální hodnota Počet aktivních pracovních vláken: 0 Kořenový adresář: /tmp/docs

26


Konfigurace indexování adresářů Pokud výraz URL požadavku končí jménem adresáře, můžete uvést jméno předvoleného souboru, který má být v takovém případě vrácen serverem WebSEAL. Pokud tento předvolený soubor existuje, pak server WebSEAL vrátí uvedený soubor klientovi. Pokud tento předvolený soubor neexistuje, server WebSEAL dynamicky vygeneruje index adresářů a vrátí tento seznam klientovi. Parametr pro konfiguraci souboru s indexem adresářů je umístěn ve stanze [content] konfiguračního souboru webseald.conf. Předvolená hodnota indexového souboru je: [content] directory-index = index.html

Toto jméno souboru můžete změnit, pokud váš webový server používá jiné konvence pro pojmenovávání souborů. Například: [content] directory-index = homepage.html

Server WebSEAL dynamicky vygeneruje index adresářů, pokud adresář v požadavku neobsahuje indexový soubor, definovaný parametrem directory-index. Vygenerovaný index obsahuje seznam obsahů adresářů, včetně odkazů na každý záznam v adresáři. Index se vytvoří pouze tehdy, pokud má klient požadující přístup do adresáře uvedeno v přístupovém seznamu pro daný adresář oprávnění pro ″výpis″ (l). Pro každý typ souboru, který je uveden ve vygenerovaném indexu, můžete nakonfigurovat určité grafické ikony. Stanza [content-index-icons] konfiguračního souboru webseald.conf obsahuje seznam typů dokumentů MIME a k nim přidružených souborů .gif, které se budou zobrazovat: [content-index-icons] image/*= /icons/image2.gif video/* = /icons/movie.gif audio/* = /icons/sound2.gif text/html = /icons/generic.gif text/* = /icons/text.gif application/x-tar = /icons/tar.gif application/* = /icons/binary.gif

Poznámka: Klíče (umístěné na levé straně) těchto záznamů stanz uvádějí typ MIME, nebo sadu typů MIME. Znak hvězdičky (*) je zástupným znakem pouze pro uvedený typ MIME druhu adresář. Více informací o konfiguraci typů MIME najdete v části Dodatek A, “Reference konfiguračního souboru serveru WebSEAL”, na stránce 237. Tento seznam můžete nakonfigurovat tak, že zadáte jiné ikony pro každý typ MIME. Ikony mohou být umístěny také na vzdálených počítačích. Například: application/* = http://www.acme.com/icons/binary.gif

Pro ikony můžete dále nakonfigurovat tyto další hodnoty: v ikona, která se bude používat pro znázornění podadresářů: [icons] diricon = /icons/folder2.gif

v ikona, která se bude používat pro znázornění nadřazeného adresáře: [icons] backicon = /icons/back.gif

v ikona, která se bude používat pro znázornění neznámého typu souboru: Kapitola 2. Základní konfigurace serveru

27

[icons] unknownicon = /icons/unknown.gif

Poznámka: Dodávané ikony jsou ve formátu GIF, ale tento formát není povinný. .

Windows: Pojmenování souborů pro programy CGI Parametry uvedené ve stanze [cgi-types] konfiguračního souboru webseald.conf vám dovolují uvést typy přípon souborů Windows, které budou rozeznávány a zpracovávány jako programy CGI. Operační systémy UNIX nemají žádné požadavky na přípony jmen souborů. Typy přípon souborů musí být však nadefinovány v operačních systémech Windows. Stanza [cgi-types] obsahuje seznam všech platných typů přípon a mapuje každou příponu (je-li to nutné) na odpovídající program CGI. [cgi-types] =

Standardně budou jako programy CGI provedeny pouze ty soubory, které mají příponu odpovídající příponám uvedeným v seznamu ve stanze. Pokud program CGI má příponu, která není uvedena v seznamu, tento program nebude spuštěn. Soubory s příponami .exe budou standardně operačním systémem Windows spouštěny jako programy a nevyžadují žádné mapování. Poznámka: Pokaždé, když budete chtít na operačním systému Windows nainstalovat soubor s příponou .exe pro účely stažení, musíte u tohoto souboru přejmenovat příponu nebo nainstalovat tento soubor jako součást archivu (jako např. .zip). Pro přípony, které představují interpretované skriptové soubory, musíte dodat odpovídající interpretační program. Příklady těchto typů přípon zahrnují skripty shellu (.sh a .ksh), skripty jazyka Perl (.pl) a skripty Tcl (.tcl). Níže uvedený příklad ukazuje typickou konfiguraci stanzy [cgi-types]: [cgi-types] bat = cmd cmd = cmd pl = perl sh = sh tcl = tclsh76

Spustitelné UNIXové soubory na hostitelském systému serveru WebSEAL Server WebSEAL podporuje vytváření lokálních spojení. Tato spojení existují na stejném hostitelském systému jako je server WebSEAL. Když přistupujete k lokálnímu spojení na systému s operačním systémem UNIX, server WebSEAL interpretuje soubory jako skripty CGI, má-li soubor přiděleno oprávnění provést operačního systému UNIX. Je-li například stránka HTML umístěna na lokálním spojení WebSEAL a má přiděleno oprávnění pro provádění, pak server WebSEAL bude interpretovat tento soubor jako spustitelný a nezobrazí jej. Chcete-li zajistit, aby byly lokální soubory správně zobrazovány, odstraňte oprávnění pro provádění ze všech souborů, které nejsou skripty CGI a ke kterým bude přistupováno prostřednictvím lokálního spojení.

28


Konfigurace ukládání webových dokumentů do paměti cache Klienti se mohou často setkat s dlouhou dobou přístupu po síti a stahování souboru, která může nastat při špatné výkonnosti získávání webového dokumentu. Špatná výkonnost se může objevit, pokud server WebSEAL čeká na dokumenty, které získává ze spojených serverů typu back-end nebo z velmi pomalé lokální paměti. Ukládání webových dokumentů do paměti cache vám dává větší pružnost při poskytování dokumentů lokálně ze serveru WebSEAL, namísto abyste je získávali ze serverů typu back-end prostřednictvím spojení. Ukládání webových dokumentů do paměti cache vám umožňuje ukládat takové typy webových dokumentů, ke kterým je běžně a často přistupováno, do paměti serveru WebSEAL. Klienti tak mohou získat mnohem rychlejší odpovědi na sledované požadavky na dokumenty, které byly uloženy do paměti cache serveru WebSEAL. Dokumenty uložené do paměti cache zahrnují dokumenty se statickým textem a grafické obrázky. Dynamicky generované dokumenty, jako např. výsledky na databázové dotazy, nejsou do paměti cache ukládány. Ukládání do paměti cache se provádí na základě typu MIME. Pokud chcete nakonfigurovat server WebSEAL tak, aby ukládal dokumenty do paměti cache, musíte určit následující tři parametry: v typ dokumentu MIME v typ paměťového média v velikost paměťového média Ukládání webových dokumentů do paměti cache nakonfigurujete ve stanze [content-cache] konfiguračního souboru webseald.conf. Platí níže uvedená syntaxe: = : Parametr

Popis

typ-mime

Představuje libovolný platný typ MIME, předaný v hlavičce odpovědi HTTP ″Content-Type:″. Tato hodnota může obsahovat hvězdičku ( * ). Hodnota */* představuje předvolenou paměť cache objektů, která může obsahovat libovolný objekt, který neodpovídá explicitně nakonfigurované paměti cache. Všimněte si, že hvězdička zde uvedená je zástupným znakem pouze v případě typu MIME druhu adresář a jeho obsahu. Nejde o zástupný znak pro vyhledávání běžných výrazů.

typ-cache

Uvádí typ paměťového média, který se má použít pro paměť cache. Toto vydání produktu Tivoli Access Manager podporuje pouze typ paměti cache ″memory″.

velikost-cache

Uvádí maximální velikost (v kilobajtech), po kterou může daná paměť cache růst, než z ní začnou být odstraňovány objekty pomocí algoritmu ″Nejdéle nepoužívaný″.

Příklad: text/html = memory:2000 image/* = memory:5000 */* = memory:1000

Podmínky ovlivňující ukládání webových dokumentů do paměti cache Mechanismus ukládání webových dokumentů do paměti cache dodržuje následující podmínky: v Ukládání do paměti cache nastane pouze tehdy, je-li paměť cache nadefinována v konfiguračním souboru webseald.conf. Kapitola 2. Základní konfigurace serveru

29

v Standardně se během instalace nedefinují žádné paměti cache. v Pokud neuvedete předvolenou paměť cache, dokumenty, které neodpovídají explicitní paměti cache, nebudou ukládány do paměti cache. v Pro všechny požadavky na informace uložené do paměti cache je stále prováděna autorizace. v Mechanismus ukládání do paměti cache neukládá do paměti cache odpovědi na požadavky, které obsahují řetězce dotazů. v Mechanismus ukládání do paměti cache neukládá do paměti cache odpovědi na požadavky přes spojení, která jsou nakonfigurována pomocí voleb –c a –C.

Zarovnání všech pamětí cache Chcete-li zarovnat všechny nakonfigurované paměti cache, můžete použít obslužný program pdadmin. Uvedený obslužný program vám nedovolí zarovnat jednotlivé paměti cache. Musíte se přihlásit do zabezpečené domény jako administrátor produktu Tivoli Access Manager sec_master, abyste mohli začít používat obslužný program pdadmin. Chcete-li zarovnat všechny paměti cache s webovými dokumenty, zadejte následující příkaz: UNIX: # pdadmin server task webseald-<jméno-počítače> cache flush all

Windows: MSDOS> pdadmin server task webseald-<jméno-počítače> cache flush all

Řízení ukládání určitých dokumentů do paměti cache Ukládání určitých dokumentů do paměti cache můžete řídit tak, že k těmto objektům připojíte speciální politiku POP (Protected Object Policy). Tato politika POP musí obsahovat rozšířený atribut s názvem document-cache-control. Rozšířený atribut document-cache-control rozeznává tyto dvě hodnoty: Hodnota

Popis

no-cache

Hodnota no-cache informuje server WebSEAL, že se tento dokument nemá ukládat do paměti cache. Pamatujte, že všechny podřízené objekty objektu s POP také přebírají podmínky POP.

public

Hodnota public dovoluje serveru WebSEAL, aby ukládal dokument do paměti cache bez ohledu na fakt, že spojení bylo vytvořeno s volbou –c nebo –C. Tato hodnota dále dovoluje ukládání tohoto dokumentu do paměti cache, i když byl tento požadavek odeslán s autorizační hlavičkou (jako např. při Základní autentizaci). Tato podmínka také zahrnuje požadavky, ve kterých server WebSEAL vloží informaci BA v zastoupení klienta (jako např. při GSO nebo při spojeních –b supply). Proxy servery obvykle neukládají do paměti cache dokumenty s odpovědí na požadavky, které obsahují autorizační hlavičky.

Použijte příkazy pdadmin pop create, pdadmin pop modify a pdadmin pop attach. Níže uvedený příklad demonstruje vytvoření politiky POP s názvem ″doc-cache″ a s rozšířeným atributem document-cache-control a její připojení k objektu (budget.html): pdadmin> pop create doc-cache pdadmin> pop modify doc-cache set attribute document-cache-control no-cache pdadmin> pop attach /WebSEAL/hostA/junction/budget.html doc-cache

Dokument budget.html nebude nikdy serverem WebSEAL uložen do paměti cache. Každý požadavek na tento dokument musí být proveden přímo serverem typu back-end, na kterém je uložen.

30


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.

Zadání typů MIME dokumentů pro filtrování URL Chcete-li zajistit odpovídající propustnost linek přes spojení WebSEAL, může server WebSEAL používat určitá pravidla pro filtrování URL při předávání odpovědí s dokumenty ze spojených serverů typu back-end. Nejprve musíte zadat typy MIME dokumentů, které může server WebSEAL rozeznávat. Parametr type ve stanze [filter-content-types] konfiguračního souboru webseald.conf určuje hodnotu typu MIME. Server WebSEAL je standardně nakonfigurován tak, aby rozeznával dokumenty dvou typů MIME: [filter-content-types] type = text/html type = text/vnd.wap.wml

Server WebSEAL může používat dále uvedenou funkcionalitu filtrování URL na všechny nakonfigurované typy dokumentů: v filtrování schémat URL Server WebSEAL filtruje pouze URL, a to pomocí schémat nadefinovaných ve stanze [filter-schemes] konfiguračního souboru webseald.conf v filtrování atributů URL Viz “Standardní pravidla pro filtrování URL serveru WebSEAL” na stránce 178 v filtrování skriptů pro absolutní URL Viz “Modifikace absolutních URL pomocí filtrování skriptů” na stránce 179.

Správa přizpůsobených HTTP stránek s chybovými zprávami Někdy se server WebSEAL pokusí obsloužit požadavek a to se mu nepodaří. Takové selhání může mít mnoho příčin. Například: v soubor neexistuje v nastavení oprávnění nedovolí přístup v není možné spustit programy CGI, protože jsou nesprávná oprávnění UNIXového souboru nebo něco podobného Pokud se vyskytne selhání při obsluze požadavku, server vrátí prohlížeči chybovou zprávu, jako např. ″403 Zakázáno″, na HTML chybové stránce. Existuje několik chybových zpráv. Každá zpráva je uložena v samostatném HTML souboru. Tyto soubory jsou uloženy v tomto adresáři: UNIX: /www/lib/errors/

Windows: \www\lib\errors\

Adresář errors obsahuje řadu podadresářů pro různé jazyky, které obsahují lokalizované verze souborů chybových zpráv. Například cesta k adresáři se zprávami v americké angličtině je: UNIX: /www/lib/errors/en_US

Windows: \www\lib\errors\en_US Kapitola 2. Základní konfigurace serveru

31

Další informace o podpoře více jazykových mutací najdete v části “Podpora více lokalizací pro webové služby” na stránce 35. Zprávy v tomto adresáři jsou uvedeny ve formátu HTML, takže se v prohlížeči objeví správně. Tyto HTML stránky můžete editovat, abyste přizpůsobili jejich obsah. Jména souborů jsou hexadecimální hodnoty interních chybových kódů, které jsou vráceny při selhání operace. Tato jména souborů by se neměla měnit. Níže uvedená tabulka obsahuje seznam jmen souborů a obsah některých z nich pro nejčastější chybové zprávy: Jméno souboru 132120c8.html

Název Autentizace selhala

Popis

Chybový kód HTTP

Nebylo možné získat pověření pro používaný certifikát klienta. Možné příčiny zahrnují: v uživatel dodal nesprávný certifikát v certifikát byl odvolán v pověření uživatele chybí v autentizační databázi

38ad52fa.html

Adresář není prázdný

Požadovaná operace vyžaduje odstranění adresáře, který není prázdný. Toto je neplatná operace.

38cf013d.html

Selhal požadavek na ukládání do paměti cache

Hodnota request-max-cache nebo request-body-max-read byla překročena.

38cf0259.html

Nebylo možné přihlásit uživatele

Požadovaný zdroj vyžaduje, aby server WebSEAL přihlásil uživatele na jiný webový server. Avšak vyskytl se problém, když se server WebSEAL pokusil načíst informaci.

38cf025a.html

Uživatel nemá informaci pro jednotné přihlášení

Server WebSEAL nemůže nalézt uživatele GSO pro požadovaný zdroj.

38cf025b.html

Žádný jednotlivý cíl přihlášení pro uživatele

Server WebSEAL nemůže nalézt cíl GSO pro požadovaný zdroj.

38cf025c.html

Několik cílů přihlášení pro uživatele

Pro požadovaný zdroj bylo nadefinováno více cílů GSO. Toto je špatná konfigurace.

38cf025d.html

Požaduje se přihlášení

Požadovaný zdroj je chráněn pomocí spojeného webového serveru typu back-end, který vyžaduje, aby server WebSEAL přihlásil uživatele na tento webový server. Aby to však mohl udělat, musíte se nejprve přihlásit k serveru WebSEAL.

38cf025e.html

Nebylo možné přihlásit uživatele

Požadovaný zdroj vyžaduje, aby server WebSEAL přihlásil uživatele na jiný webový server. Avšak přihlašovací informace pro váš účet je nesprávná.

38cf025f.html

Neočekávaná výzva k autentizaci

Server WebSEAL obdržel neočekávanou výzvu k autentizaci od spojeného webového serveru typu back-end.

38cf0421.html

Dočasně přemístěno

Požadovaný zdroj byl dočasně přemístěn. To se obvykle stane, pokud bylo provedeno špatně obsloužené přesměrování.

302

38cf0424.html

Špatný požadavek

Server WebSEAL obdržel neplatný HTTP požadavek.

400

38cf0425.html

Požaduje se přihlášení

Zdroj, který požadujete, je zabezpečen pomocí serveru WebSEAL, a abyste k němu mohli přistoupit, musíte se nejdříve přihlásit.

38cf0427.html

Zakázáno

Uživatel nemá oprávnění k přístupu k požadovanému zdroji.

32


403

Jméno souboru

Název

Chybový kód HTTP

Popis

38cf0428.html

Nenalezen

Požadovaný zdroj není možné najít.

404

38cf0432.html

Služba není k dispozici

Služba, kterou požaduje server WebSEAL, aby dokončil váš požadavek, není momentálně k dispozici.

503

38cf0437.html

Server je pozastaven

Server WebSEAL byl dočasně pozastaven administrátorem systému. Nebudou obsluhovány žádné požadavky, dokud administrátor nevrátí server do provozu.

38cf0439.html

Ztracena informace o relaci

Vaše poslední interakce program/server byla stavová relace se spojeným serverem typu back-end, který již neodpovídá. Server WebSEAL vyžaduje službu, která je umístěna na tomto serveru, aby dokončil váš požadavek.

38cf0442.html

Služba není k dispozici

Služba požadovaná Access Manager WebSEAL je umístěna na spojeném záložním serveru, na kterém selhala vzájemná autentizace SSL.

38cf07aa.html

Selhal program CGI

Program CGI selhal a nelze jej správně provést.

default.html

Chyba serveru

Server WebSEAL nemůže dokončit váš požadavek z důvodu neočekávané chyby.

500

deletesuccess.html

Úspěch

Klientem vyvolaný požadavek DELETE byl dokončen úspěšně.

200

putsuccess.html

Úspěch

Klientem vyvolaná operace PUT byla dokončena úspěšně.

200

relocated.html

Dočasně přemístěno

Požadovaný zdroj byl dočasně přemístěn.

302

websealerror.html

400 Chyba serveru WebSEAL

Interní chyba serveru WebSEAL.

400

Podpora maker pro HTTP stránky s chybovými zprávami Níže uvedená makra je možné používat pro přizpůsobení HTML chybových stránek, uvedených v předchozí části. Makra dynamicky nahrazují odpovídající informace, které jsou dostupné. Makro

Popis

%ERROR_CODE%

Číselná hodnota chybového kódu

%ERROR_TEXT%

Text přiřazený k chybovému kódu v katalogu zpráv

%METHOD%

Metoda HTTP požadovaná klientem

%URL%

URL požadované klientem

%HOSTNAME%

Plně kvalifikované jméno hostitele

%HTTP_BASE%

Základní HTTP URL serveru ″http://:/″

%HTTPS_BASE%

Základní HTTPS URL serveru ″https://:<sslport>/″

%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á


33

Správa přizpůsobených stránek správy účtů Produkt Tivoli Access Manager obsahuje vzorové HTML stránky správy účtů, které je možné přizpůsobit tak, aby obsahovaly zprávy specifické pro danou webovou stránku, nebo aby prováděly akce specifické pro danou webovou stránku. Většina formulářů je vhodná pro Základní autentizaci, autentizaci pomocí formulářů a tokenů, všechny prováděné prostřednictvím protokolů HTTP nebo HTTPS. Umístění souborů s těmito formuláři je nadefinováno v parametru mgt-pages-root stanzy [acnt-mgt] v konfiguračním souboru webseald.conf. mgt-pages-root = lib/html/

Skutečný používaný adresář závisí na lokalizaci. Předvolený adresář pro americkou angličtinu je: lib/html/C

Japonská lokalizace produktu obsahuje soubory v adresáři: lib/html/JP

Další informace o podpoře více jazykových mutací najdete v části “Podpora více lokalizací pro webové služby” na stránce 35.

Parametry a hodnoty přizpůsobené stránky Níže uvedené speciální parametry a hodnoty HTML stránky jsou uvedeny ve stanze [acnt-mgt] konfiguračního souboru webseald.conf. Některé stránky se používají pouze při metodě přihlášení pomocí formulářů, ve kterých budou podány informace o totožnosti. Parametr

Stránka

Použití

login =

login.html

Přihlášení pomocí formulářů

login-success =

login_success.html


logout =

logout.html


account-locked =

acct_locked.html

Libovolná metoda

passwd-expired =

passwd_exp.html

Libovolná metoda

passwd-change =

passwd.html

Libovolná metoda

passwd-change-success =

passwd_rep.html

Libovolná metoda

passwd-change-failure =

passwd.html

Libovolná metoda

help =

help.html

Libovolná metoda

token-login =

tokenlogin.html

Přihlášení pomocí tokenu

next-token =

nexttoken.html

Přihlášení pomocí tokenu

stepup-login =

stepuplogin.html

Zvýšená autentizace

switch-user =

switchuser.html

Libovolná metoda

cert-failure =

certfailure.html

Certifikace přihlášení

Popisy přizpůsobených HTML stránek Formulář

34

Popis

login.html

Standardní formulář požadavku na jméno a heslo uživatele

login_success.html

Stránka, která se zobrazí po úspěšném přihlášení


Formulář

Popis

logout.html

Stránka, která se zobrazí po úspěšném odhlášení

acct_locked.html

Stránka, která se zobrazí, pokud autentizace uživatele selhala, protože jeho účet byl uzamčen

passwd_exp.html

Stránka, která se zobrazí, pokud autentizace uživatele selhala, protože jeho heslu skončila platnost

passwd.html

Formulář pro změnu hesla. Zobrazí se také tehdy, pokud selhal požadavek na změnu hesla.

passwd_rep.html

Stránka, která se zobrazí, pokud požadavek na změnu hesla byl úspěšný

help.html

Stránka, která obsahuje odkazy na platné administrativní stránky

tokenlogin.html

Formulář pro přihlášení pomocí tokenu

nexttoken.html

Formulář pro zadání dalšího tokenu

stepuplogin.html

Formulář pro přihlášení pomocí zvýšené autentizace

switchuser.html

Formulář pro správu přepnutí uživatelů.

certfailure.html

Stránka, která se zobrazí, když selže autentizace klienta pomocí certifikátu, je-li nastaveno accept-client-certs = required.

Podpora maker pro stránky správy účtů Níže uvedená makra je možné používat pro přizpůsobení HTML stránek, uvedených v předchozí části. Tyto řetězce maker je možné umístit do vzorových souborů. Makra dynamicky nahrazují odpovídající informace, které jsou dostupné. Makro %USERNAME%

Popis Jméno přihlášeného uživatele (Viz též “Přizpůsobení formulářů pro přihlášení pro potřeby opětovné autentizace” na stránce 140)

%ERROR%

Pevně naprogramované chybové zprávy, vrácené produktem Tivoli Access Manager

%METHOD%

Metoda HTTP požadovaná klientem

%URL%

URL požadované klientem

%HOSTNAME%

Plně kvalifikované jméno hostitele

%HTTP_BASE%

Základní HTTP URL serveru ″http://:/″

%HTTPS_BASE%

Základní HTTPS URL serveru ″https://:<sslport>/″

%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á

Podpora více lokalizací pro webové služby Produkt Tivoli Access Manager WebSEAL poskytuje webovým službám podporu více lokalizací. Standardní odpovědi serveru WebSEAL (jako např. chybové zprávy, přizpůsobené HTML stránky pro přihlášení a odhlášení, a zprávy obslužnosti), které jsou předávány prohlížečům klientů, je možné dodávat v jazyce, který daný klient upřednostňuje. Kapitola 2. Základní konfigurace serveru

35

Server WebSEAL podporuje schopnost používat více jazykových lokalizací, a to pomocí hodnot uvedených v HTTP hlavičce accept-language. Pomocí této hlavičky je schopen určit správný jazyk, který bude používán ve zprávách generovaných serverem a HTML stránkách. Pro níže uvedené serverové zdroje jsou k dispozici přeložené informace: v HTTP chybové zprávy /www/lib/errors/

v přizpůsobené stránky správy účtů /www/lib/html/

v zprávy týkající se obslužnosti Prohlížeče přebírají standardní nastavení jazykových hodnot. Základní jazykové hodnoty jsou představovány dvěma znaky, které určují daný jazyk. 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 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) es-MX (španělština/Mexiko) pt-BR (portugalština/Brazílie)

Hlavička accept-language může obsahovat více než jeden jazyk. Každý další jazyk je oddělen čárkou. Například: accept-language: es-mx,es,en

Pořadí hodnot, ve kterém se hodnoty objeví v hlavičce, určuje pořadí důležitosti. Server WebSEAL zkontroluje první uvedenou hodnotu, zda ji má obsaženu v nainstalované jazykové sadě. Pokud jazyková sada pro tento jazyk není nainstalovaná, server WebSEAL zkontroluje další jazyk v seznamu, zda pro něj nemá nainstalovánu danou jazykovou sadu. Poznámka: Hlavička accept-language může používat parametr ″q=x.x″, pomocí kterého je možné uvést preferenční úroveň určitého jazyka. Tento parametr není serverem WebSEAL rozeznáván. Pořadí jazyků uvedených v hlavičce určuje serveru WebSEAL pořadí priorit. Je možné nainstalovat několik jazykových sad zpráv serveru WebSEAL. Každá instalace jazykové sady vytvoří podadresář specifický pro danou lokalizaci v cestě pro umístění každého úložiště zpráv. Například španělská jazyková sada vytvoří následující podadresář pro umístění úložiště chybových zpráv serveru: /www/lib/errors/es

Níže uvedená tabulka obsahuje seznam jazyků, které server WebSEAL podporuje, spolu s příslušnými jmény podadresářů: Jazyk

36

Systémový adresář

angličtina (předvolba)

C

čeština

cs

němčina

de

španělština

es


Jazyk

Systémový adresář

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

Dále uvedený příklad průběhu procesu demonstruje, jak server WebSEAL zpracuje hlavičku accept-language: 1. Hlavička accept-language obsahuje pt-br na prvním místě v seznamu. 2. Jazyk pt-br je převeden na hodnotu pt_BR, což představuje podadresář jazykové mutace serveru WebSEAL pro uvedený jazyk. 3. Pokud tento podadresář pro požadovanou zprávu neexistuje (nebyla například pro uvedený jazyk nainstalována jazyková sada), pak server WebSEAL zkontroluje adresář pt. 4. Pokud neexistuje adresář pt, pak se server WebSEAL pokusí nalézt podadresáře zpráv pro další jazyk, uvedený v hlavičce. 5. Pokud nejsou nainstalovány žádné jazykové sady pro všechny zprávy uvedené v hlavičce, server WebSEAL použije předvolené jazykové prostředí, ve kterém je server WebSEAL spuštěn. To je určeno proměnnými prostředí LC_ALL nebo LANG operačního systému. Podmínky ovlivňující podporu více lokalizací na serveru WebSEAL: v podpora více lokalizací je na serveru WebSEAL povolena vždy v instalace určité jazykové sady určuje, které jazyky budou podporovány v server WebSEAL vrací uživateli sadu znaků UTF-8 bez ohledu na nastavení HTTP hlavičky accept-charset v pokud server WebSEAL najde adresář lokalizace pro příslušné přeložené zprávy, ale tento adresář je prázdný (například pokud byl administrátorem vymazán obsah tohoto adresáře), pak bude vrácena chybová stránka serveru

Správa certifikátů klienta a serveru Tato část popisuje úlohy administrativy a konfigurace týkající se nastavení serveru WebSEAL tak, aby obsluhoval digitální certifikáty klienta a serveru, které se používají pro autentizaci prostřednictvím protokolu SSL. Server WebSEAL vyžaduje certifikáty v následujících situacích: v server WebSEAL identifikuje sám sebe vzhledem ke klientům SSL pomocí certifikátu serveru v server WebSEAL identifikuje sám sebe vzhledem ke spojenému serveru typu back-end (nakonfigurovanému pro vzájemnou autentizaci) pomocí certifikátu klienta


37

v server WebSEAL použije svou databázi kořenových certifikátů vydavatele certifikátu (CA - Certificate Authority), aby ověřil klienty, kteří k němu přistupují pomocí certifikátů klienta v server WebSEAL použije svou databázi kořenových certifikátů vydavatele certifikátu (CA), aby ověřil spojené servery typu back-end, které jsou nakonfigurovány pro vzájemnou autentizaci Server WebSEAL používá implementaci protokolu SSL, která je součástí produktu IBM Global Security Kit (GSKit), aby nakonfiguroval a administroval digitální certifikáty. Produkt GSKit obsahuje obslužný program iKeyman, pomocí kterého je možné nastavit a spravovat databázi klíčů certifikátů, jež obsahuje jeden nebo více certifikátů serveru/klienta serveru WebSEAL a kořenové certifikáty vydavatelů certifikátů. Instalace produktu WebSEAL zpřístupní níže uvedené komponenty, pomocí kterých je možné podporovat SSL autentizaci pomocí digitálních certifikátů: v předvolená databáze klíčů (pdsrv.kdb) v předvolený soubor pro uložení databáze klíčů (pdsrv.sth) a pro uložení hesla (″pdsrv″) v několik kořenových certifikátů běžných vydavatelů certifikátů v testovací certifikát s automatickým podpisem, který server WebSEAL může používat k tomu, aby identifikoval sám sebe vzhledem ke klientům SSL Doporučuje se, abyste použili běžně rozeznávané certifikáty od známých vydavatelů certifikátů, a těmi nahradili tento testovací certifikát. Konfigurace pro práci serveru WebSEAL s certifikáty zahrnuje: v “Konfigurace parametrů databáze klíčů” na stránce 39 v “Používání obslužného programu správy certifikátů iKeyman” na stránce 41 v “Konfigurace kontroly CRL” na stránce 41

Typy souborů databáze klíčů produktu GSKit Produkt IBM Key Management tool (iKeyman) používá několik typů souborů, které jsou shrnuty v následující tabulce. Databáze klíčů CMS se skládá ze souboru s příponou .kdb a možná dalších dvou nebo více souborů. Soubor .kdb se vytvoří, jakmile vytvoříte novou databázi klíčů. Záznamy klíčů v souboru .kdb mohou být buď certifikáty nebo certifikáty se zašifrovanou informací o soukromém klíči. Soubory .rdb a .crl se vytvoří, jakmile vytvoříte novou žádost o certifikát. Soubor .rdb je potřeba během procesu žádosti o certifikát vydavatele certifikátů. Typ souboru

Popis

.kdb

Soubor ″databáze klíčů″. Jsou v něm uloženy osobní certifikáty, žádosti o osobní certifikát a certifikáty signatářů. Například předvolený soubor databáze klíčů produktu WebSEAL je pdsrv.kdb.

.sth

Soubor ″pro uložení″. Ukládá zatemněnou verzi hesla databáze klíčů. Přední část jména tohoto souboru je stejná jako přidruženého souboru .kdb. Dále ukládá soukromé klíče, pokud existují.

38


Typ souboru

Popis

.rdb

Databázový soubor pro ″požadavky″. Vytvoří se automaticky, jakmile vytvoříte soubor databáze klíčů .kdb. Přední část jména tohoto souboru je stejná jako přidruženého souboru .kdb. Tento soubor obsahuje žádosti o certifikát, které nejsou dosud provedeny, nebo dosud nebyly obdrženy zpět od vydavatele certifikátů. Když získáte certifikát od vydavatele certifikátů, bude soubor .rdb prohledán, aby byla nalezena odpovídající žádost o certifikát (na základě veřejného klíče). Pokud bude nalezen odpovídající záznam, certifikát bude přijat a odpovídající žádost o certifikát bude vymazána ze souboru .rdb. Pokud nebude nalezen odpovídající záznam, pokus o přijetí certifikátu bude zamítnut. Součástí žádosti o certifikát je běžné jméno, organizace, adresa a další informace, které byly uvedeny během vyplňování žádosti, stejně tak jako veřejný a soukromý klíč přidružený k žádosti.

.crl

Soubor se ″seznamem odvolaných certifikátů″. Tento soubor obvykle obsahuje seznam certifikátů, které byly odvolány z nějakého důvodu. Produkt iKeyman však neposkytuje žádnou podporu pro seznam odvolaných certifikátů, takže je tento soubor prázdný.

.arm

ASCII zakódovaný binární soubor. Soubor .arm obsahuje base-64 zakódované ASCII znázornění certifikátu, včetně jeho veřejného klíče, ale nikoliv jeho soukromého klíče. Originální binární data certifikátu jsou převedena do ASCII znázornění. Když uživatel obdrží certifikát v souboru .arm, produkt iKeyman dekóduje ASCII znázornění a umístí binární znázornění do odpovídajícího souboru .kdb. Podobně pokud uživatel vyjme certifikát ze souboru .kdb, produkt iKeyman převede data z binárního do ASCII znázornění a umístí jej do souboru .arm. Poznámka: Je možné použít libovolný typ souboru (jiný než .arm), pokud je samotný soubor base-64 zakódovaný soubor.

.der

Soubor ″rozlišovacích pravidel pro zakódování″. Soubor .der obsahuje binární znázornění certifikátu, včetně jeho veřejného klíče, ale nikoliv jeho soukromého klíče. Je velmi podobný souboru .arm s výjimkou toho, že znázornění je binární, nikoliv ASCII.

.p12

Soubor ″PKCS 12″, kde PKCS je zkratka ″Public-Key Cryptography Standards″. Soubor .p12 obsahuje binární znázornění certifikátu, včetně veřejného i soukromého klíče. Soubor .p12 může obsahovat více než jeden certifikát. Například celý řetěz na sebe navazujících certifikátů. Protože soubor .p12 obsahuje soukromý klíč, je chráněn heslem.

Konfigurace parametrů databáze klíčů Soubor databáze klíčů serveru WebSEAL: Během instalace produktu WebSEAL se nastaví předvolená databáze klíčů certifikátů. Parametr webseal-cert-keyfile ve stanze [ssl] konfiguračního souboru webseald.conf určuje jméno a umístění tohoto souboru: [ssl] webseal-cert-keyfile = /var/pdweb/www/certs/pdsrv.kdb

Chcete-li vytvořit novou databázi klíčů, můžete použít obslužný program iKeyman. Musíte však zadat jméno a umístění tohoto nového souboru klíčů v parametru webseal-cert-keyfile, takže server WebSEAL bude moci nalézt a používat certifikáty obsažené v této databázi. Heslo souboru databáze klíčů: Během instalace produktu WebSEAL je dále nadefinován předvolený soubor pro uložení, který obsahuje heslo souboru klíčů pdsrv.kdb. Parametr webseal-cert-keyfile-stash informuje server WebSEAL, kde je soubor pro uložení umístěn: webseal-cert-keyfile-stash = /var/pdweb/www/certs/pdsrv.sth

Předvolené heslo zašifrované v tomto souboru pro uložení hesla je ″pdsrv″. Toto heslo můžete také vyjádřit v textové formě v parametru webseal-cert-keyfile-pwd. Například: webseal-cert-keyfile-pwd = pdsrv


39

Během instalace používá server WebSEAL soubor pro uložení hesla k tomu, aby získal heslo souboru klíčů. Parametr webseal-cert-keyfile-pwd je opatřen komentářovou značkou. Pokud budete používat soubor pro uložení, vyvarujete se zobrazení hesla jako textového řetězce v konfiguračním souboru webseald.conf. Poznámka: U toho parametru hesla, který chcete používat, vymažte znak komentáře. Pokud uvedete, že se má používat jak heslo, tak i soubor pro uložení, bude se používat hodnota hesla. Testovací certifikát serveru WebSEAL: Během instalace produktu WebSEAL se nastaví nezabezpečený testovací certifikát s automatickým podpisem. Testovací certifikát, který vystupuje jako certifikát serveru, dovoluje serveru WebSEAL, aby identifikoval sám sebe vzhledem ke klientům SSL. Proto, aby bylo lépe regulováno používání tohoto certifikátu, není tento certifikát nainstalován jako předvolený certifikát. Namísto toho parametr webseal-cert-keyfile-label označuje certifikát jako aktivní certifikát serveru a vyřazuje všechny další certifikáty označené jako ″default″ v databázi souboru klíčů. webseal-cert-keyfile-label = WebSEAL-Test-Only

Poznámka: Server WebSEAL používá funkcionalitu práce s certifikáty produktu GSKit. Produkt GSKit povoluje, ale nevyžaduje, aby certifikát v databázích klíčů byl označen jako předvolený certifikát. Podrobnější informace o práci s certifikáty najdete v dokumentu produktu GSKit: Secure Socket Layer and iKeyman User’s Guide. Přestože tento testovací certifikát dovoluje serveru WebSEAL odpovídat na požadavky prohlížeče s povoleným protokolem SSL, nemůže být ověřen prohlížečem (který neobsahuje odpovídající kořenový certifikát vydavatele certifikátů). Protože soukromý klíč tohoto předvoleného certifikátu je součástí každé distribuce produktu WebSEAL, tento certifikát nenabízí skutečnou bezpečnou komunikaci. Musíte použít obslužný program iKeyman a vygenerovat žádost o certifikát, která bude odeslána vydavateli certifikátů. Pomocí obslužného programu iKeyman nainstalujete a označíte vrácený certifikát serveru. Pokud pro jiné scénáře používáte jiné certifikáty (jako např. pro spojení –K), můžete použít obslužný program iKeyman k vytvoření, instalaci a označení těchto certifikátů. Označení souboru klíčů nesmí obsahovat mezery. Server WebSEAL (který je standardně spuštěn jako user ivmgr) musí mít oprávnění pro čtení (r) pro tyto databázové soubory klíčů. Parametry pro interní komunikaci SSL mezi servery produktu Tivoli Access Manager: Stanza [ssl] konfiguračního souboru webseald.conf obsahuje čtyři další parametry, které se používají ke konfiguraci souboru klíčů, používaného serverem WebSEAL pro interní SSL komunikaci s ostatními servery produktu Tivoli Access Manager. Tyto parametry byste měli měnit pouze prostřednictvím konfiguračního skriptu pdconfig. [ssl] ssl-keyfile = ssl-keyfile-pwd = ssl-keyfile-stash = ssl-keyfile-label =

40


Používání obslužného programu správy certifikátů iKeyman Obslužný program iKeyman je nástroj, který je součástí produktu GSKit a který můžete používat ke správě digitálních certifikátů používaných serverem WebSEAL. Obslužný program iKeyman používejte tehdy, chcete-li: v v v v v v v v

vytvořit jednu nebo více databází klíčů změnit hesla databází klíčů vytvořit nové certifikáty serveru WebSEAL nastavit nový předvolený certifikát serveru WebSEAL vytvořit certifikát s automatickým podpisem pro účely testování požádat a obdržet kořenový certifikát vydavatele certifikátů přidat certifikáty a vymazat certifikáty z databáze překopírovat certifikát z jedné databáze do druhé

Podrobné informace o používání obslužného programu iKeyman najdete v knize Secure Sockets Layer Introduction and iKeyman User’s Guide.

Konfigurace kontroly CRL CRL (Certificate Revocation List) je způsob, jak předcházet ověření platnosti nechtěných certifikátů. CRL obsahuje totožnosti certifikátů, které jsou považovány za nedůvěryhodné. Implementace protokolu SSL v produktu GSKit, kterou používá server WebSEAL, podporuje kontrolu CRL. Produkt GSKit umožňuje serveru WebSEAL, aby prováděl kontroly CRL pro certifikáty klienta a pro certifikáty spojení SSL. Server WebSEAL musí znát umístění uvedeného seznamu, aby mohl provádět kontroly CRL. Parametry umístění serveru LDAP, na který je možné se pro kontrolu CRL odkazovat během autentizace pomocí certifikátů, jsou uvedeny ve stanze [ssl] konfiguračního souboru webseald.conf: [ssl] #crl-ldap-server = <jméno-serveru> #crl-ldap-server-port = #crl-ldap-user = <jméno-administrátora-webseal> #crl-ldap-user-password =

Parametry umístění serveru LDAP, na který je možné se pro kontrolu CRL odkazovat během autentizace pomocí certifikátů, jsou uvedeny ve stanze [junction] konfiguračního souboru webseald.conf: [junction] #crl-ldap-server = <jméno-serveru> #crl-ldap-server-port = #crl-ldap-user = <jméno-administrátora-webseal> #crl-ldap-user-password =

Standardně je kontrola CRL zakázána (parametry jsou zakomentovány). Chcete-li aktivovat kontrolu CRL během autentizace pomocí certifikátů, odstraňte znaky komentáře u každého parametru a uveďte odpovídající hodnoty. Hodnota typu null parametru crl-ldap-user znamená, že mechanismus SSL autentizace by měl být spojen se serverem LDAP jako pro anonymního uživatele. Poznámka: Informace o podpoře seznamů odvolaných certifikátů produktu GSKit najdete v Secure Sockets Layer Introduction and iKeyman User’s Guide.


41

Konfigurace paměti cache CRL Produkt GSKit umožňuje serveru WebSEAL, aby prováděl kontroly CRL pro certifikáty klienta a pro certifikáty spojení SSL. Chcete-li zlepšit výkonnost kontrolování CRL, můžete ukládat CRL od určitých vydavatelů certifikátů do paměti cache. Následující kontroly CRL budou prováděny vzhledem k této verzi seznamu uloženého do paměti cache. Nastavení dvou parametrů konfiguračního souboru webseald.conf, probíraného v této části, je předáno přímo do obslužného programu GSKit. Podrobnější informace o funkčních vlastnostech produktu GSKit najdete v dokumentaci tohoto produktu.

Nastavení maximálního počtu záznamů paměti cache Parametr gsk-crl-cache-size udává maximální počet záznamů v paměti cache CRL produktu GSKit. Každý záznam představuje celý seznam CRL určitého vydavatele certifikátů. Předvolené nastavení je ″0″. Chcete-li aktivovat paměť cache, musíte zadat hodnotu větší než ″0″. Pokud jsou oba parametry gsk-crl-cache-size a gsk-crl-cache-entry-lifetime nastaveny na hodnotu ″0″ (což odpovídá předvolené konfiguraci), ukládání CRL do paměti cache je zakázáno. [ssl] gsk-crl-cache-size = 0

Nastavení časového limitu paměti cache produktu GSKit Parametr gsk-crl-cache-entry-lifetime udává časový limit doby trvání všech záznamů v paměti cache CRL produktu GSKit. Hodnota je vyjádřena ve vteřinách a může být v rozsahu 0-86400 vteřin. Pokud jsou oba parametry gsk-crl-cache-size a gsk-crl-cache-entry-lifetime nastaveny na hodnotu ″0″ (což odpovídá předvolené konfiguraci), ukládání CRL do paměti cache je zakázáno. [ssl] gsk-crl-cache-size = 0

Konfigurace předvoleného protokolování HTTP Server WebSEAL udržuje tři tradiční soubory protokolu HTTP, které zaznamenávají aktivitu a ne zprávy: v request.log v agent.log v referer.log Standardně jsou tyto soubory protokolu umístěny v následujícím adresáři: UNIX: /var/pdweb/www/log/

Windows: C:\Program Files\Tivoli\PDWeb\www\log\

Parametry pro konfiguraci standardního protokolování HTTP jsou ve stanze [logging] konfiguračního souboru webseald.conf. Níže uvedená tabulka zobrazuje vztah mezi soubory protokolu HTTP a parametry konfiguračního souboru: Parametr umístění

Soubory protokolu request.log

42

requests-file


Povolit/zakázat parametr ( = ano nebo ne) requests

Parametr umístění

Soubory protokolu

Povolit/zakázat parametr ( = ano nebo ne)

referer.log

referers-file

referers

agent.log

agents-file

agents

Například záznam pro předvolené umístění souboru request.log bude vypadat následovně: UNIX: requests-file = /var/pdweb/www/log/request.log

Windows: requests-file = \Program Files\Tivoli\PDWeb\www\log\request.log

Aktivace a zakázání protokolování HTTP Standardně je všechno protokolování HTTP aktivováno: [logging] requests = yes referers = yes agents = yes

Každý typ protokolování může být aktivován nebo zakázán nezávisle na ostatních typech. Pokud je některý z parametrů nastaven na hodnotu ″no″, pak je pro daný typ souboru protokolování zakázáno. Jakmile je protokolování aktivováno tak, jak je uvedeno výše, předvolené protokolování HTTP serveru WebSEAL je ve skutečnosti obsluhováno mechanismem protokolování událostí produktu Tivoli Access Manager, které je popsáno v části “Konfigurace protokolování HTTP pomocí protokolování událostí” na stránce 45.

Určení typu časového označení Můžete se rozhodnout, že chcete mít časová označení v každém protokolu zaznamenána v greenwichském čase GMT (Greenwich Mean Time) namísto v lokální časové zóně. Standardně se používá lokální časová zóna: [logging] gmt-time = no

Chcete-li používat časový záznam v greenwichském čase, uveďte: gmt-time = yes

Určení prahových hodnot obnovy souborů protokolu Parametr max-size určuje maximální velikost, po kterou mohou všechny soubory protokolu HTTP růst, a má uvedenou předvolenou hodnotu (v bajtech): [logging] max-size = 2000000

Když soubor protokolu dosáhne uvedené hodnoty — známé také jako prahová hodnota cyklické obnovy — pak je stávající soubor zazálohován do souboru se stejným jménem a připojeným aktuálním datem a časovým označením. Pak se spustí protokolování do nového souboru. Různé možné hodnoty parametru max-size se interpretují následovně:


43

v Pokud hodnota parametru max-size je menší než nula (< 0), pak se nový soubor protokolu vytvoří při každém vyvolání procesu protokolování a po každých 24 hodinách od tohoto okamžiku. v Pokud je hodnota parametru max-size rovna nule (= 0), pak se neprovádí žádné cyklické obnovy a soubor protokolu roste do nekonečna. Pokud soubor protokolu již existuje, budou nová data k němu připojena. v Pokud je hodnota parametru max-size větší než nula (> 0), pak se provede cyklická obnova tehdy, když soubor prověřovacích záznamů dosáhne nakonfigurované prahové hodnoty. Pokud soubor protokolu při spuštění již existuje, budou nová data k němu připojena.

Určení četnosti zarovnávání vyrovnávacích pamětí souboru protokolu Soubory protokolu se zapisují do toků dat, které využívají vyrovnávací paměť. Pokud monitorujete soubory protokolu v reálném čase, můžete chtít změnit četnost, se kterou server nutí zarovnat vyrovnávací paměti souboru protokolu. Standardně jsou soubory protokolu zarovnávány každých 20 vteřin. [logging] flush-time = 20

Pokud uvedete zápornou hodnotu, zarovnání se vynutí při zápisu každého záznamu.

Obecný formát protokolu protokolu HTTP (pro soubor request.log) Každá odpověď (úspěch nebo selhání), která je poslána zpět serverem produktu Tivoli Access Manager, je zaznamenána v jednořádkovém záznamu v souboru request.log, a to pomocí následujícího obecného formátu protokolu protokolu HTTP: hostitel - autuživ [datum] požadavek stav bajty

kde: hostitel

Určuje IP adresu požadujícího počítače.

autuživ

Toto pole obsahuje informace o totožnosti uživatele. Hodnota ″unauth″ se používá pro neautentizovaného uživatele.

datum

Uvádí datum a čas požadavku.

požadavek

Uvádí první řádku požadavku, tak jak přišla od klienta.

stav

Uvádí stavový kód HTTP, který se odešle zpět požadujícímu počítači.

bajty

Uvádí počet bajtů, který se pošle zpět požadujícímu počítači. Tato hodnota — ať už jde o velikost nefiltrovaného obsahu, nebo o velikost nula — se konfiguruje v parametru log-filtered-pages.

Zobrazení souboru request.log Soubor request.log zaznamenává standardní protokolování požadavků HTTP, jako např. informací o URL, které byly požadovány, a informace o klientovi (například IP adresa), který vydal požadavek. Níže uvedený příklad zobrazuje vzorovou verzi souboru request.log: 130.15.1.90 130.15.1.90 130.15.1.90 130.15.1.90 130.15.1.90

44

-

-

[26/Jan/2002:17:23:33 [26/Jan/2002:17:23:47 [26/Jan/2002:17:23:59 [26/Jan/2002:17:24:04 [26/Jan/2002:17:24:11


-0800] -0800] -0800] -0800] -0800]

"GET "GET "GET "GET "GET

/~am/a_html/ HTTP/1.0" 403 77 /icons HTTP/1.0" 302 93 /icons/ HTTP/1.0" 403 77 /~am/a_html/ HTTP/1.0" 403 77 /~am/ HTTP/1.0" 403 77

Zobrazení souboru agent.log Soubor agent.log zaznamenává obsah hlavičky User_Agent: požadavku HTTP. Tento protokol odhaluje informace o prohlížeči klienta, jako např. o architektuře, čísle verze apod., a to pro každý požadavek. Níže uvedený příklad zobrazuje vzorovou verzi souboru agent.log: Mozilla/4.01 Mozilla/4.01 Mozilla/4.01 Mozilla/4.01

[en] [en] [en] [en]

(WinNT; (WinNT; (WinNT; (WinNT;

U) U) U) U)

Zobrazení souboru referer.log Soubor referer.log zaznamenává hlavičku Referer: požadavku HTTP. Pro každý požadavek protokol zaznamenává dokument, který byl součástí odkazu na požadovaný dokument. Protokol používá tento formát: odkazovač -> objekt

Tyto informace jsou užitečné, když sledujete externí odkazy na dokumenty ve vašem webovém prostoru. Protokol odhaluje, že zdroj, který je označen pomocí odkazovač, obsahuje odkaz na stránku objekt. Tento protokol vám dovoluje sledovat prošlé odkazy a nalézt, kdo vytváří odkazy ve vašich dokumentech. Níže uvedený příklad zobrazuje vzorovou verzi souboru referer.log: http://manuel/maybam/index.html -> /pics/tivoli_logo.gif http://manuel/maybam/pddl/index.html -> /pics/tivoli_logo.gif http://manuel/maybam/ -> /pddl/index.html http://manuel/maybam/ -> /pddl/index.html http://manuel/maybam/pddl/index.html -> /pics/tivoli_logo.gif http://manuel/maybam/ -> /pddl/index.html

Konfigurace protokolování HTTP pomocí protokolování událostí Protokolování HTTP serveru WebSEAL je možné nakonfigurovat ve stanze [aznapi-configuration] konfiguračního souboru webseald.conf. Pomocí parametru pro protokolování událostí logcfg nadefinujte jeden nebo více agentů protokolu (protokolovačů), které budou shromažďovat informace z určité kategorie protokolu ze zdroje událostí a přesměrovávat tyto informace na uvedený cíl: [aznapi-configuration] logcfg = :{stdout|stderr|file|pipe|remote} [[<parametr>[=]] [,<parametr>[=]]...]

Podrobné informace o konfigurování protokolování událostí najdete v kapitole ″Používání protokolování událostí″ v knize IBM Tivoli Access Manager Base: Administrativní příručka. Vhodné hodnoty parametru kategorie pro protokolování HTTP jsou: v http Všechny informace týkající se protokolování HTTP v http.clf Informace o požadavcích HTTP v obecném formátu protokolu v http.ref Informace v HTTP hlavičce Referer v http.agent Informace v HTTP hlavičce User_Agent v http.cof Kapitola 2. Základní konfigurace serveru

45

Kombinovaný formát NCSA zachycuje informace o požadavcích HTTP (s časovým označením) a připojuje uvozené řetězce odkazovače (referer) a agenta (agent) ke standardnímu obecnému formátu protokolu. Níže uvedené konfigurace agentů protokolů jsou aktivovány, pokud jsou aktivovány předvolené parametry protokolování HTTP serveru WebSEAL (viz “Konfigurace předvoleného protokolování HTTP” na stránce 42). Všimněte si, že v konfiguraci agentů protokolu je možné použít hodnoty parametrů requests-file, referers-file, agents-file, flush-time a max-size, které jsou uvedeny v konfiguračním souboru webseald.conf ve stanze [logging]: request.log (obecný formát protokolu): logcfg = http.clf:file path=<requests-file>,flush=, \ rollover=<max-size>,log=clf,buffer_size=8192,queue_size=48

referer.log: logcfg = http.ref:file path=,flush=, \ rollover=<max-size>,log=ref,buffer_size=8192,queue_size=48

agent.log (obecný formát protokolu): logcfg = http.agent:file path=,flush=, \ rollover=<max-size>,log=agent,buffer_size=8192,queue_size=48

Jelikož předvolené protokolování HTTP je nakonfigurováno v jiné stanze ([logging]) než konfigurace protokolování událostí ([aznapi-configuration]), je možné, že se v souboru protokolu objeví dva duplicitní záznamy pro každou událost, pokud máte aktivovány oba mechanismy protokolování. Mechanismus protokolování událostí vám nabízí větší pružnost v získávání protokolovacích informací o HTTP a v přizpůsobení jejich výstupu.

Protokolování zpráv obslužnosti serveru WebSEAL Zprávy obslužnosti serveru Tivoli Access Manager WebSEAL jsou řízeny souborem routing produktu Tivoli Access Manager WebSEAL. Soubor routing je umístěn v tomto adresáři: UNIX: /opt/pdweb/etc/

Windows: C:\Program Files\Tivoli\PDWeb\etc\

Soubor routing je ASCII soubor, který obsahuje dodatečnou dokumentaci ve formě komentářových řádků. Záznamy v tomto konfiguračním souboru určují typy zpráv obslužnosti, které budou protokolovány. Libovolný záznam povolíte tak, že odstraníte znak komentáře (#). Soubor routing obsahuje tyto předvolené záznamy: UNIX: FATAL:STDERR:ERROR:STDERR:WARNING:STDERR:#NOTICE:FILE.10.100:/opt/pdweb/log/notice.log #NOTICE_VERBOSE:FILE.10.100:/opt/pdweb/log/notice.log

Windows: FATAL:STDERR:ERROR:STDERR:WARNING:STDERR:#NOTICE:FILE.10.100:%PDWEBDIR%/log/notice.log #NOTICE_VERBOSE:FILE.10.100:%PDWEBDIR%/log/notice.log

Poznámka: V operačních systémech Windows je během zpracování nastavena speciální proměnná prostředí PDWEBDIR na instalační adresář produktu WebSEAL.

46


Standardně, když je spuštěn server WebSEAL v popředí, jsou všechny zprávy odesílány na obrazovku (STDERR). Standardně, když je server WebSEAL spuštěn na pozadí, jsou všechny zprávy přesměrovány ze STDERR a odeslány do souboru protokolu serveru WebSEAL, který je nadefinován ve stanze [logging] konfiguračního souboru webseald.conf: Server WebSEAL (webseald)

Konfigurační soubor webseald.conf

Umístění souboru protokolu UNIX:[logging] server-log=/var/pdweb/log/msg_webseald.log Windows: [logging] server-log= C:\Program Files\Tivoli\PDWeb\log\msg_webseald.log

Chcete-li aktivovat verbose.log, odstraňte komentář na řádce NOTICE_VERBOSE. Syntaxe FILE pro zprávu NOTICE řídí přetočení souboru protokolu a opětovné využití souboru: FILE.<max-souborů>.<max-záznamů>

Hodnota max-souborů určuje počet souborů, které se používají. Hodnota max-záznamů určuje maximální počet záznamů v souboru. Ve výše uvedeném předvoleném příkladě záznam FILE.10.100 znamená, že bude vytvořeno 10 souborů, každý o maximálně 100 záznamech. Soubory jsou pojmenovány: notice.log.1 notice.log.2 . . . notice.log.10

Zprávy se ″cyklicky přetočí″ na první soubor, jakmile poslední soubor dosáhne svého limitu, nebo když se server zastaví a znovu spustí. Když se znovu použije soubor protokolu, stávající záznamy jsou přepsány (vymazány).

Soubory prověřovacích záznamů serveru WebSEAL Monitorování je nadefinováno jako shromažďování dat o aktivitách systémů, které ovlivňují operace zabezpečení autorizačního procesu produktu Tivoli Access Manager. Každý server produktu Tivoli Access Manager (jako např. server WebSEAL) může zachycovat monitorované události, jakmile se vyskytne monitorovaná aktivita související se zabezpečením. Monitorované události jsou uloženy do prověřovacích záznamů, které dokumentují určitou aktivitu serveru. Každá monitorovaná aktivita se nazývá monitorovaná událost. Shromáždění záznamů o monitorovaných událostech, které je uloženo v souboru, se nazývá prověřovací záznam.

Konfigurace souborů prověřovacích záznamů Produkt Tivoli Access Manager nabízí dva způsoby, jak aktivovat a nakonfigurovat monitorování. Oba způsoby zahrnují zadání hodnot klíčů ve stanze [aznapi-configuration] konfiguračního souboru webseald.conf. Tyto dva způsoby jsou: v konfigurace protokolování událostí Kapitola 2. Základní konfigurace serveru

47

Protokolování událostí se nakonfiguruje tak, že zadáte sadu hodnot do klíče logcfg. Tento způsob konfigurace je doporučován, protože konfiguruje protokolování událostí produktu Tivoli Access Manager. Protokolování událostí nabízí strukturovanou hierarchii pro zachycování všech zpráv, určených pro monitorování a pro další účely obslužnosti. Funkce protokolování událostí dále podporuje používání alternativních umístění výstupu protokolování, jako je např. konzole (stdout), propojení procesů (pipe) a vzdálené servery. v konfigurace přejatého monitorování Přejaté monitorování se konfiguruje tak, že zadáte hodnotu do každého z těchto klíčů: [aznapi-configuration] logaudit auditlog auditcfg logsize logflush

Používání tohoto způsobu je porovnatelné se způsobem protokolování událostí, je-li výstup přesměrován do souboru. Všimněte si však, že způsob protokolování událostí nabízí další řízení pro velikost vyrovnávací paměti a pro fronty událostí. Přejaté monitorování dále nepodporuje výstup na konzoli, do propojení procesů nebo na vzdálené servery. Pokud konfigurujete monitorování určitého typu událostí, zvolte si buď protokolování událostí, nebo přejaté monitorování.

Konfigurační úlohy Pro každý soubor prověřovacích záznamů serveru WebSEAL musíte provést tyto konfigurační úlohy: 1. povolit monitorování Povolte vytváření prověřovacích záznamů. 2. zadat typ monitorované události Podporované typy monitorovaných událostí serveru WebSEAL: v autorizace v nabytí pověření pomocí autentizace v požadavky HTTP 3. zadat umístění souboru prověřovacích záznamů Zadejte umístění souboru prověřovacích záznamů v systému souborů. 4. zadat velikost souboru prověřovacích záznamů Zadejte maximální velikost souboru prověřovacích záznamů. Když bude dosaženo uvedené maximální velikost, soubor bude zazálohován a začne se vytvářet nový soubor. 5. zadat interval zarovnávání souboru Zadejte četnost, se kterou bude server zarovnávat vyrovnávací paměti prověřovacích záznamů do souboru. Níže uvedené konfigurační úlohy jsou pro každý soubor prověřovacích záznamů serveru WebSEAL volitelné: v zadat maximální frontu událostí Zadejte maximální počet událostí, které se mají ukládat do paměti. v zadat horní prahovou hodnotu fronty událostí Zadejte počet událostí ve frontě, který spustí zarovnání paměti do souboru. v zadat maximální velikost vyrovnávací paměti Zadejte maximální velikost (v bajtech) vyrovnávací paměti událostí, která bude vytvořena z jednotlivých událostí. v zadat režim souboru

48


Zadejte, zda soubor bude binární nebo textový. Textový režim je k dispozici pouze na platformách s operačním systémem Windows. Volitelné konfigurační úlohy jsou podporovány protokolováním událostí produktu Tivoli Access Manager, nikoliv přejatým monitorováním. Podrobnější informace o těchto úlohách najdete v části IBM Tivoli Access Manager Base: Administrativní příručka.

Příklad konfigurace Syntaxe pro konfiguraci souboru prověřovacích záznamů pomocí logcfg je: logcfg =kategorie:file path=cesta_k_souboru, flush_interval=vteřiny,\ rollover_size=číslo, log_id=logid, queue_size=číslo, hi_water=číslo,\ buffer_size=číslo, mode={text|binary}

Platné hodnoty parametru kategorie jsou: Tabulka 1. Kategorie protokolovaných událostí Typ protokolované události

Nastavení kategorie

Autentizace nabytí pověření

audit.authn

Autorizace

audit.azn

Informace o protokolování HTTP

http

Informace o požadavcích HTTP v obecném formátu protokolu

http.clf

Informace v HTTP hlavičce Referer

http.ref

Informace v HTTP hlavičce User Agent

http.agent

Kombinovaný formát NCSA zachycuje informace http.cof o požadavcích HTTP (s časovým označením) a připojuje uvozené řetězce odkazovače (referer) a agenta (agent) ke standardnímu obecnému formátu protokolu.

Například následující záznam logcfg vytvoří soubor prověřovacích záznamů serveru WebSEAL, který bude shromažďovat informace o událostech týkajících se autentizace: logcfg = audit.authn:file path=/var/pdweb/log/audit.log,flush_interval=20, \ rollover_size=2000000

Poznámka: Výše uvedený příklad je zadán jako jeden nepřerušovaný řádek v konfiguračním souboru webseald.conf. V tomto příkladě je monitorování aktivováno, jakmile produkt Tivoli Access Manager přečte při spuštění záznam logcfg v souboru webseald.conf. Povinná nastavení konfigurace jsou uvedena v těchto parametrech: Tabulka 2. Příklad hodnot povinného nastavení konfigurace Parametr

Povinné nastavení

audit.authn:file

Typ monitorované události

path=/var/pdweb/log/audit.log

Umístění souboru prověřovacích záznamů

rollover_size=2000000

Velikost souboru prověřovacích záznamů

flush_interval=20

Interval zarovnávání souboru

V tomto příkladu nebylo uvedeno žádné s volitelných nastavení konfigurace. Pokud neuvedete žádné z volitelných nastavení, pak produkt Tivoli Access Manager použije pro každé z těchto nastavení příslušnou předvolenou hodnotu:


49

Tabulka 3. Předvolené hodnoty volitelných nastavení konfigurace Parametr

Volitelné nastavení

queue_size=číslo

Maximální velikost fronty událostí. Předvolená hodnota je 0. Tato hodnota znamená, že nebude zavedená žádná maximální velikost.

hi_water=číslo

Horní prahová hodnota fronty událostí. Předvolená hodnota jsou dvě třetiny hodnoty queue_size. Je-li queue_size rovna 0, pak je předvolbou 100.

buffer_size=číslo

Maximální velikost vyrovnávací paměti. Předvolená hodnota je 0, což zakazuje ukládání do vyrovnávací paměti.

mode={text|binary}

Režim souboru. Předvolený režim je binary. Textový režim je podporovaný pouze na platformě Windows.

Záznamy logcfg jsou umístěny v souboru webseald.conf ve stanze [aznapi-configuration]. Pro každý typ monitorované události zadejte samostatný záznam logcfg. Přejaté monitorování Rozhodnete-li se použít přejaté monitorování, abyste dosáhli stejných výsledků jako ve výše uvedeném příkladu s monitorováním autentizace, pak by porovnatelné záznamy v konfiguračním souboru byly: [aznapi-configuration] logaudit = yes auditcfg = authn auditlog = /var/pdweb/log/audit.log logsize = 2000000 logflush = 20

Přejaté monitorování nepodporuje volitelná nastavení konfigurace. Viz též: v “Konfigurace protokolování HTTP pomocí protokolování událostí” na stránce 45 v část týkající se monitorování reference konfiguračního souboru serveru WebSEAL: “Monitorování” na stránce 318 v kapitola pojednávající o protokolování a monitorování knihy IBM Tivoli Access Manager Base: Administrativní příručka

Záznamy monitorování HTTP Protokolování HTTP zachycuje stejné informace jako standardní soubory protokolu HTTP (request.log, referer.log a agent.log). Níže je uveden příklad záznamu monitorování přístupu HTTP: <event rev="1.1"> 2002-11-14-23:04:26.931+00:00I----- 1 http 2 146.84.251.70 <principal auth="IV_DCE_V3.0">cell_admin

50


object>/pics/pd30.gif

Viz též “Konfigurace protokolování HTTP pomocí protokolování událostí” na stránce 45.

Záznamy monitorování autentizace Autentizace objektu se provádí během získávání pověření. Prověřovací záznamy je možné zachycovat produktem Tivoli Access Manager, který zaznamená úspěch nebo selhání podobných pokusů o autentizaci. Monitorování pokusů o autentizaci můžete nakonfigurovat tak, že přidáte “authn” do konfiguračního seznamu monitorování ve stanze [aznapi-configuration] konfiguračního souboru daného serveru. [aznapi-configuration] auditcfg = authn

Níže je uveden příklad autentizační události týkající se neautentizovaného uživatele, která byla zaprotokolována serverem WebSEAL: <event rev="1.1"> 2001-11-14-23:04:26.630+00:00I----- 0 authn 0 phaedrus <principal auth="invalid">

Níže je uveden příklad autentizační události týkající se autentizovaného uživatele, která byla zaprotokolována serverem WebSEAL: <event rev="1.1"> 2001-11-14-15:56:06.551+00:00I----- 0 authn 0 phaedrus <principal auth="IV_LDAP_V3.0" domain="Default">testuser2

Níže je uveden příklad selhání autentizace (z důvodu ukončení platnosti hesla), které bylo zaprotokolováno serverem WebSEAL. <event rev="1.1"> 2001-11-14-16:23:00.294+00:00I----- 0 authn 0 phaedrus Kapitola 2. Základní konfigurace serveru

51

<principal auth="IV_LDAP_V3.0" domain="Default">testuser2

Níže je uveden příklad selhání autentizace z důvodu příliš mnoha neplatných pokusů o přihlášení (politika ″třikrát a dost″), které bylo zaprotokolováno serverem WebSEAL. <event rev="1.1"> 2001-11-14-19:06:00.294+00:00I----- 0 authn 0 phaedrus <principal auth="IV_LDAP_V3.0" domain="Default">testuser2

Níže je uveden příklad úspěšné změny hesla, zaprotokolované serverem WebSEAL. <event rev="1.1">2001-11-14-16:25:54.543+00:00I----- 0 authn 0 phaedrus <principal auth="passwd-ldap" domain="Default">testuser2

Tabulka 4 obsahuje seznam chybových kódů autentizace a jejich strukturu elementu , která je vrácena při selhání pokusu o autentizaci: Tabulka 4. Chyby autentizace Typ chyby

Chybový kód (hexadecimálně)

Chybový kód (desítkově)

Generováno XML

Selhání hesla

132120c8

320938184

Password failure: uživatel

Účet uzamčen

13212132

320938290

Account lock-out: uživatel

Obecné selhání

Vše ostatní

Vše ostatní

<username> uživatel

Chcete-li určit důvod monitorované události, jako např. uzamčení účtu (politika ″třikrát a dost″), získejte chybový kód, jak je ukázáno ve výše uvedené tabulce. Chybový kód je součástí výstupu monitorování v příznaku : "13212132">0

Použijte příkaz pdadmin errtext pro daný chybový kód a získejte důvod selhání. Například:

52


> pdadmin errtext 13212132 Tento účet byl dočasně uzamčen z důvodu příliš mnoha neplatných pokusů o přihlášení

Chybové kódy produktu Tivoli Access Manager jsou popsány v knize IBM Tivoli Access Manager Error Message Reference.


53

54


Kapitola 3. Pokročilá konfigurace serveru Tato kapitola obsahuje informace, které popisují pokročilé administrativní a konfigurační úlohy, které můžete provést pro přizpůsobení serveru WebSEAL pro potřeby vaší sítě. Viz též Kapitola 2, “Základní konfigurace serveru”, na stránce 19. Seznam témat: v “Konfigurace předvolené úrovně zabezpečení” na stránce 55 v “Konfigurace aktualizací a systému výzev autorizační databáze” na stránce 57 v “Správa alokace pracovních vláken” na stránce 57 v “Replikace předřazených serverů WebSEAL” na stránce 60 v “Konfigurace více instancí serveru WebSEAL” na stránce 61 v “Konfigurace přepnutí uživatele” na stránce 73 v “Konfigurace ukládání požadavku na straně serveru do paměti cache serveru WebSEAL” na stránce 84 v “Práce se znaky zakódovanými pomocí UTF-8” na stránce 86 v “Předcházení zranitelnosti způsobené skriptováním napříč stranami” na stránce 88 v “Potlačení totožnosti serveru” na stránce 89 v “Konfigurace kryptografického hardwaru pro šifrování a ukládání klíčů” na stránce 89 v “Nástroje pro určování problémů pro server WebSEAL” na stránce 94

Konfigurace předvolené úrovně zabezpečení Předvolenou úroveň požadovaného zašifrování pro přístup k serveru WebSEAL prostřednictvím protokolu SSL (HTTPS) můžete řídit tak, že nakonfigurujete úroveň zabezpečení (QOP - quality of protection). Správa předvolené úrovně zabezpečení je řízena pomocí parametrů uvedených v části ″SSL QUALITY OF PROTECTION MANAGEMENT (SPRÁVA ÚROVNĚ ZABEZPEČENÍ SSL)″ konfiguračního souboru webseald.conf: v pomocí parametru ssl-qop-mgmt můžete aktivovat nebo zakázat správu QOP v ve stanze [ssl-qop-mgmt-default] můžete uvést povolené úrovně šifrování 1. Aktivace správy úrovně zabezpečení: [ssl-qop] ssl-qop-mgmt = yes

2. Uvedení předvolené úrovně šifrování pro přístup HTTPS: [ssl-qop-mgmt-default] # default = ALL | NONE | <úroveň-šifrování # ALL (povolí všechny šifry) # NONE (zakáže všechny šifry a bude používat MD5 MAC kontrolní součet) # DES-56 # DES-168 # RC2-40 # RC2-128 # RC4-40 # RC4-128 default = ALL

Všimněte si, že můžete také uvést zvolenou skupinu šifer: [ssl-qop-mgmt-default] default = RC4-128 default = RC2-128 default = DES-168


55

Produkt Tivoli Access Manager používá program GSKit 5. Specifikace šifer, podporovaných programem GSKIT5 při současném používání bezpečnostního standardu internetu SSLv2/TLS, jsou: CipherSuite CipherSuite CipherSuite CipherSuite CipherSuite CipherSuite CipherSuite CipherSuite CipherSuite CipherSuite

SSL_RSA_WITH_NUL_MD5 SSL_RSA_WITH_NUL_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA TLS_RSA_EXPORT1024_WITH_RSA_56_SHA

Tyto specifikace šifer TLS jsou podporovány také pro SSLV3.

Konfigurace QOP pro jednotlivé hostitele a sítě Parametr ssl-qop-mgmt = yes také povolí libovolné nastavení, které se objeví ve stanzách [ssl-qop-mgmt-hosts] a [ssl-qop-mgmt-networks]. Tyto stanzy povolí správu úrovně zabezpečení pro určité IP adresy hostitelů/sítí/masek sítí. Stanza [ssl-qop-mgmt-default] obsahuje seznam šifer, které se budou používat pro všechny IP adresy, které neodpovídají stanzám [ssl-qop-mgmt-hosts] a [ssl-qop-mgmt-networks]. Příklad syntaxe konfigurace pro hostitele: [ssl-qop-mgmt-hosts] # = ALL | NONE | <úroveň-šifry> # ALL (povolí všechny šifry) # NONE (zakáže všechny šifry a bude používat MD5 MAC kontrolní součet) # DES-40 # DES-56 # DES-168 # RC2-40 # RC2-128 # RC4-40 # RC4-128 xxx.xxx.xxx.xxx = ALL yyy.yyy.yyy.yyy = RC2-128

Příklad syntaxe konfigurace pro síť/masku sítě: [ssl-qop-mgmt-networks] # <síť/maska-sítě> = ALL | NONE | <úroveň-šifry> # ALL (povolí všechny šifry) # NONE (zakáže všechny šifry a bude používat MD5 MAC kontrolní součet) # DES-40 # DES-56 # DES-168 # RC2-40 # RC2-128 # RC4-40 # RC4-128 xxx.xxx.xxx.xxx/255.255.255.0 = RC4-128 yyy.yyy.yyy.yyy/255.255.0.0 = DES-56

Stanzy [ssl-qop-mgmt-hosts] a [ssl-qop-mgmt-networks] se používají pouze pro účely zpětné kompatibility. Doporučujeme, abyste je již v konfiguraci produktu Tivoli Access Manager nepoužívali.

56


Konfigurace aktualizací a systému výzev autorizační databáze Server politik produktu Tivoli Access Manager (pdmgrd) spravuje hlavní databázi politik autorizace a spravuje informace o umístění, týkající se ostatních serverů produktu Tivoli Access Manager v rámci zabezpečené domény. Administrátor produktu Tivoli Access Manager může kdykoliv provádět změny bezpečnostní politiky v zabezpečené doméně. Server politik provede nezbytné úpravy v hlavní autorizační databázi, kdykoliv je implementována změna bezpečnostní politiky. Když server politik provede změnu v hlavní autorizační databázi, může odeslat upozornění o této změně všem replikám databáze v zabezpečené doméně, které podporují samostatné vymahače politiky (jako např. server WebSEAL). Vymahače politiky musí pak požádat o skutečnou aktualizaci databáze z hlavní autorizační databáze. Server WebSEAL, jako správce zdrojů a vymahač politiky, má tři možnosti, jak získat informace o změnách v autorizační databázi: v naslouchat upozorněním o aktualizaci ze serveru politik (konfigurovatelné, standardně aktivováno) v kontrolovat (vyzývat) hlavní autorizační databázi v pravidelných intervalech (konfigurovatelné, standardně zakázáno) v povolit jak naslouchání, tak i vyzývání Stanza [aznapi-configuration] konfiguračního souboru webseald.conf obsahuje parametry pro konfiguraci naslouchání upozorněním o aktualizaci a systému výzev databáze. Cesta k lokální replice databáze politik autorizace serveru WebSEAL je nadefinována v parametru db-file: [aznapi-configuration] db-file = /var/pdweb/db/webseald.db

Konfigurace naslouchání upozorněním o aktualizaci Parametr listen-flags uvedený ve stanze [aznapi-configuration] aktivuje nebo zakazuje serveru WebSEAL naslouchat upozorněním o aktualizaci. Standardně je naslouchání aktivováno. Chcete-li naslouchání zakázat, zadejte ″disable″. [aznapi-configuration] listen-flags = enable

Parametr ssl-listening-port uvedený ve stanze [ssl] konfiguruje port protokolu SSL pro proces naslouchání: [ssl] ssl-listening-port = 7234

Konfigurace systému výzev autorizační databáze Server WebSEAL 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 hodnotu ″default″, ″disable″, nebo na určitý časový interval (ve vteřinách). Nastavení ″default″ odpovídá hodnotě 600 vteřin. Standardně je vyzývání zakázáno. [aznapi-configuration] cache-refresh-interval = disable

Správa alokace pracovních vláken v “Konfigurace pracovních vláken serveru WebSEAL” na stránce 58 v “Alokace pracovních vláken pro spojení (spravedlnost spojení)” na stránce 58

Kapitola 3. Pokročilá konfigurace serveru

57

Konfigurace pracovních vláken serveru WebSEAL Počet nakonfigurovaných pracovních vláken určuje počet současně obsluhovaných příchozích požadavků, které může server obsloužit. Další připojení, která dorazí v okamžiku, kdy jsou všechna pracovní vlákna obsazená, jsou uložena do vyrovnávací paměti, dokud nebude nějaké pracovní vlákno k dispozici. Počet pracovních vláken určených pro obsluhování příchozích připojení do serveru WebSEAL můžete nastavit. Konfigurace počtu pracovních vláken by měla být prováděna velmi opatrně, neboť ovlivňuje výkonnost serveru. Tento konfigurační parametr nevyužívá horní hranice počtu současných připojení. Tento parametr jednoduše určuje počet vláken, které jsou dány k dispozici pro obsluhu potenciálně nekonečné pracovní fronty. Zvolení optimálního počtu pracovních vláken závisí na porozumění množství a typu provozu ve vaší síti. V každém případě musíte zadat pouze takovou hodnotu, která je menší než omezení počtu pracovních vláken daná vaším operačním systémem. 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. Server WebSEAL spravuje jednoduchý generický pracovní seznam a společnou oblast pracovních vláken, která je určena pro obsluhu požadavků od klientů používajících protokol TCP nebo SSL. Tento rozšířený mechanismus dovoluje serveru WebSEAL využívat méně systémových prostředků během obsluhování výrazně většího zatížení. Velikost společné oblasti pracovních vláken můžete nakonfigurovat tak, že nastavíte parametr worker-threads ve stanze [server] konfiguračního souboru webseald.conf. [server] worker-threads = 50

Poznámka: Tento parametr změňte pouze tehdy, když se snažíte vyřešit problémy s výkonností. Zvolená hodnota musí být v rozmezí limitních hodnot pro pracovní vlákna nastavených operačním systémem. Viz též IBM Tivoli Access Manager Performance Tuning Guide.

Alokace pracovních vláken pro spojení (spravedlnost spojení) Alokaci pracovních vláken serveru WebSEAL, které se používají ke zpracování požadavků prostřednictvím více spojení, můžete nakonfigurovat globálně, nebo po jednotlivých spojeních. Mechanismus konfigurace udržuje ″spravedlivé″ rozdělování pracovních vláken mezi všechna spojení a brání tomu, aby společnou oblast pracovních vláken spotřebovalo pouze jedno spojení.

Prostředí Server WebSEAL si vytáhne ze své společné oblasti pracovních vláken vlákna pro zpracování více požadavků. Počet pracovních vláken, který je k dispozici serveru WebSEAL, je uveden v parametru worker-threads konfiguračního souboru webseald.conf. Hodnotu parametru worker-threads musíte přizpůsobit tak, aby co nejlépe sloužila vaší určité implementaci serveru WebSEAL. Pokud nejsou k dispozici žádná pracovní vlákna, aby obsloužila příchozí požadavky, uživatelé zjistí, že server WebSEAL neodpovídá. Pracovní vlákna se používají k obsluze příchozích požadavků na aplikace, které jsou umístěny na více spojených serverech typu back-end. Společná oblast pracovních vláken

58


může být však rychle vyčerpána, pokud určitá aplikace typu back-end je neobvykle pomalá a pokud je nutné odpovídat na a zpracovávat velké množství požadavků. Vyčerpání společné oblasti pracovních vláken touto jednou aplikací může učinit server WebSEAL neschopným odpovídat na požadavky na služby ostatních spojených aplikačních serverů. Můžete nakonfigurovat globální omezení nebo omezení jednotlivých spojení počtu pracovních vláken, který mohou aplikace používat při více spojeních. Tato omezení zajistí ″spravedlnost″ mezi všemi spojeními a zabrání, aby jakákoliv jedna aplikace zabrala více než svůj podíl počtu pracovních vláken.

Globální alokace pracovních vláken pro spojení Ve stanze [junction] konfiguračního souboru webseald.conf jsou umístěny dva parametry, které řídí globální alokaci pracovních vláken pro všechna spojení určitého serveru WebSEAL. Hodnoty uvedené v těchto parametrech jsou procentuální hodnoty v rozsahu 0 až 100. Předvolená hodnota 100 (%) znamená, že není nastaveno žádné omezení. v worker-thread-soft-limit Tento parametr se nastavuje, aby bylo odesláno varování před dosažením ″hard - pevného″ omezení počtu pracovních vláken. Pokud překročíte worker-thread-soft-limit, pak budou odesílány zprávy (každých 30 vteřin) do souboru protokolu chyb serveru WebSEAL. Je-li například worker-threads=50, pak nastavení tohoto parametru na hodnotu 60 (%) způsobí, že se varovné zprávy začnou vydávat, jakmile spojení spotřebuje více než 30 pracovních vláken. Všechny požadavky nad 30 pracovních vláken budou i nadále zpracovávány, dokud nebude dosaženo ″hard - pevného″ omezení počtu pracovních vláken. v worker-thread-hard-limit Tento parametr vystupuje jako bod přerušení obsluhy požadavku ve spojení. Pokud překročíte worker-thread-hard-limit, pak budou odesílány chybové zprávy (každých 30 vteřin) do souboru protokolu chyb serveru WebSEAL. Navíc je uživateli odeslána zpráva 503 ″Služba není dostupná″. Je-li například worker-threads=50, pak nastavení tohoto parametru na hodnotu 80 (%) způsobí, že se chybové zprávy začnou vydávat, jakmile spojení spotřebuje více než 40 pracovních vláken. Všechny požadavky nad uvedených 40 pracovních vláken na spojení budou vráceny spolu se zprávou 503 ″Služba není dostupná″. Tato globální nastavení platí stejně pro všechna nakonfigurovaná spojení. Při konfiguraci těchto dvou parametrů je logické, že ″soft - slabé″ omezení je nastaveno na nižší hodnotu než ″hard - pevné″ omezení. Informace vedoucí k posouzení výkonnosti najdete v knize IBM Tivoli Access Manager Performance Tuning Guide.

Alokace pracovních vláken po jednotlivých spojeních pro spojení Alternativou výše uvedeného nastavení je omezení spotřeby pracovních vláken na úrovni jednotlivých spojení. Níže uvedené volby příkazu pdadmin server task create vám dovolí uvést pevné a slabé omezení počtu pracovních vláken pro určité spojení: v –l <procentuální-hodnota> Tato volba nastaví hodnotu (v procentech) pro spojení, která určuje slabý limit spotřeby pracovních vláken. Tak jako v globálním nastavení slabého limitu tato volba způsobí, že budou vydávány varovné zprávy, jakmile spojení spotřebuje více pracovních vláken, než je povoleno tímto nastavením. v –L <procentuální-hodnota> Tato volba nastaví hodnotu (v procentech) pro spojení, která určuje pevné omezení spotřeby pracovních vláken. Tak jako v globálním nastavení pevného (hard) omezení tato


59

volba způsobí, že budou vydávány chybové zprávy, jakmile se spojení pokusí spotřebovat více pracovních vláken, než je povoleno tímto nastavením. Navíc je uživateli odeslána zpráva 503 ″Služba není dostupná″. Například: pdadmin> server task webseald-<jméno-serveru> create -t tcp -h <jméno-hostitele> \ -l 60 -L 80

Nastavení na úrovni jednotlivých spojení vyřadí globální nastavení v konfiguračním souboru webseald.conf. Neodpovídající nastavení pro určité spojení může negativně ovlivnit politiku zavedenou pomocí globálních nastavení.

Poznámky týkající se odstraňování problémů v Chcete-li zobrazit počet aktivních pracovních vláken pro určité spojení, můžete použít příkaz pdadmin server task show. pdadmin> server task webseald-<jméno-serveru> show /

Tyto informace mohou být užitečné, pokud chcete určit spojení, které spotřebovává více než svůj podíl zdrojů pracovních vláken. v Pokud uvedete pro určité spojení hodnotu slabého (soft) omezení počtu pracovních vláken větší než hodnotu pevného (hard) omezení, pak takové spojení nebude vytvořeno. v Pro určité spojení musíte uvést obě hodnoty limitů (–l a –L).

Replikace předřazených serverů WebSEAL Poznámka: Níže uvedené informace nahrazují dřívější příkaz pdadmin server modify baseurl, který se používal v předchozích verzích produktu Tivoli Access Manager. V prostředí s velkým zatížením je výhodné replikovat předřazené servery WebSEAL, aby tyto poskytovaly lepší schopnosti vyvažování zatížení a přepnutí při selhání. Pokud replikujete předřazené servery WebSEAL, pak každý server musí obsahovat naprosto stejnou kopii webového prostoru, databáze spojení a databáze dynurl. Tato verze produktu Tivoli Access Manager podporuje ruční konfiguraci replikace předřazených serverů WebSEAL. Příkaz pdadmin se pro danou úlohu již nepoužívá. V níže uvedeném příkladě je ″WS1″ jméno hostitele primárního serveru WebSEAL. ″WS2″ je jméno hostitele replikovaného serveru WebSEAL. 1. Nainstalujte a nakonfigurujte produkt WebSEAL na obou serverech WS1 a WS2. 2. Pomocí příkazu pdadmin vytvořte nový objekt, který se stane kořenem autorizačního prostoru pro oba servery WebSEAL. Například: pdadmin> object create /WebSEAL/newroot

3. Zastavte server WebSEAL na WS1. 4. Na WS1 změňte hodnotu parametru server-name v konfiguračním souboru webseald.conf z hodnoty ″WS1″ na ″newroot″: [server] server-name = newroot

5. Znovu spusťte server WebSEAL na serveru WS1. 6. Pro server WS2 opakujte kroky 3-5. Servery WS1 a WS2 nyní používají objekt /WebSEAL/newroot jako svůj základ pro ohodnocení autorizace. Jak server WS1, tak i server WS2 mohou odpovídat na příkazy object list a object show, které se dotazují na objekty pod objektem /WebSEAL/newroot.

60


Pomocí dále uvedené procedury zrušíte konfiguraci serveru WS1, nebo serveru WS2: 1. Zastavte server WebSEAL. 2. Změňte parametr server-name zpět na jeho původní hodnotu. Například pro server WS1: [server] server-name = WS1

3. Pokračujte dále v normální proceduře zrušení konfigurace. Podmínky: v jednotná správa prostoru objektů: přestože administrátor může vidět hierarchii jednotlivých objektů, všechny replikované servery WebSEAL jsou ovlivněny administrativními příkazy, které se použijí na uvedenou hierarchii objektů a všechny servery jsou schopné odpovídat na tyto příkazy v jednotné ohodnocení autorizace: Oba servery WS1 i WS2 používají objekt /WebSEAL/newroot jako svůj základ pro ohodnocení autorizace v jednotná konfigurace: chcete-li, aby replikace předřazených serverů WebSEAL pracovala správně, konfigurace webového prostoru, databáze spojení a databáze dynurl musí být na všech serverech identická

Konfigurace více instancí serveru WebSEAL Produkt Tivoli Access Manager má schopnost nakonfigurovat více instancí serveru WebSEAL na jednom počítači.

Přehled konfigurace Pro účely konfigurace je instance serveru WebSEAL nadefinována pomocí jedinečné kombinace síťového rozhraní (IP adresy) a čísla portu. Více instancí serveru WebSEAL je možné nakonfigurovat jedním z níže uvedených způsobů, které vytvoří jedinečnou kombinaci síťové rozhraní:port. v použijte jedno síťové rozhraní (IP adresu) a přiřaďte instanci serveru WebSEAL jedinečné naslouchací porty HTTP/HTTPS v přiřaďte instanci serveru WebSEAL jedinečná síťová rozhraní (fyzické síťové karty nebo logické aliasy sítí) a použijte společné naslouchací porty HTTP/HTTPS Poznámka: V obou případech musí být hodnota portu pro interní komunikaci mezi servery — který se používá pro komunikaci mezi instancemi serveru WebSEAL a serverem politik — jedinečná pro všechny instance serveru WebSEAL. Každá nakonfigurovaná instance serveru WebSEAL musí mít jedinečné jméno, jedinečné číslo vnitřního portu (pro interní komunikaci mezi servery produktu Tivoli Access Manager), jedinečné umístění adresáře a jedinečný konfigurační soubor. Více jedinečných konfiguračních souborů se vytvoří pomocí jména instance serveru, před které je předřazen řetězec webseald-. Například: /opt/pdweb/etc/webseald-<jméno-instance>.conf

Jak pro operační systémy UNIX, tak i pro operační systémy Windows použijte pro konfiguraci i odkonfigurování více instancí serveru WebSEAL obslužný program pdconfig. Poznámka: Obslužný program pdconfig můžete také použít k vytvoření první instance serveru WebSEAL.

Poznámky a podmínky v Pokud si přejete používat zabezpečenou komunikaci prostřednictvím protokolu SSL mezi instancí serveru WebSEAL a serverem s registrem LDAP, musíte pro tento účel vytvořit Kapitola 3. Pokročilá konfigurace serveru

61

v

v

v v

v v

a uložit soubor klíčů SSL pomocí obslužného programu iKeyman produktu GSKit. Je-li první server WEbSEAL nastaven tak, aby používal zabezpečenou komunikaci prostřednictvím protokolu SSL s registrem LDAP, pak stejný soubor klíčů používají i ostatní instance. Nově vytvořený konfigurační soubor specifický pro danou instanci se automaticky nakonfiguruje tak, aby nová instance serveru WebSEAL mohla používat komunikaci SSL s interními servery produktu Access Manager (jako např, se serverem politik). Nově vytvořený konfigurační soubor specifický pro danou instanci se dále automaticky nakonfiguruje tak, aby nová instance serveru WebSEAL používala certifikát serveru prvního serveru WebSEAL při autentizaci na prohlížečích klientů. Dále uvedené instrukce předpokládají, že váš počítač má nakonfigurován první server WebSEAL a že má jednu síťovou kartu (s IP adresou). Hodnota portu pro interní komunikaci mezi servery Tivoli Access Manager — určená pro komunikaci mezi instancí serveru WebSEAL a ostatními servery produktu Tivoli Access Manager (jako např. serverem politik) — musí být jedinečná pro všechny instance serveru WebSEAL. Hodnoty portu pro interní komunikaci mezi servery Tivoli Access Manager musí být větší než číslo 1023. Hodnoty menší nebo rovny číslu 1023 jsou rezervovány. Maximální počet povolených instancí serveru WebSEAL je řízen omezením konfigurace systému, jako např. dostupnou pamětí nebo místem na disku. Pokud překročíte některý ze systémových zdrojů, zobrazí se zpráva o chybě konfigurace a selhání spuštění.

Konfigurace více instancí serveru WebSEAL na operačním systému UNIX Předpoklady: v první server WebSEAL byl nakonfigurován Konfigurace více instancí na jedinečných portech HTTP/HTTPS: V tomto případě se stane více instancí serveru WebSEAL jedinečnými tak, že budou na společném síťovém rozhraní určeny různé naslouchací porty HTTP/HTTPS. 1. Předpoklad: OS Windows má nakonfigurován první server WebSEAL (pdconfig) a fyzickou síťovou kartu/IP adresu (v tomto případě: 1.2.3.4). 2. Spusťte obslužný program pdconfig: # pdconfig

Zobrazí se Menu Nastavení Access Manager for e-business. Menu Nastavení Access Manager for e-business 1. 2. 3. x.

Konfigurovat sadu programů Odkonfigurovat sadu programů Zobrazit stav konfigurace Konec

Vyberte prosím položku menu [x]:

3. Zadejte ″1″, čímž zvolíte Konfigurovat sadu programů, a stiskněte klávesu Enter. Zobrazí se menu Konfigurace Access Manager for e-business. Menu Konfigurace Access Manager for e-business 1. Konfigurace Access Manager WebSEAL x. Návrat do Menu Nastavení Access Manager for e-business Vyberte prosím položku menu [x]:

4. Zadejte ″1″, čímž zvolíte Konfigurace Access Manager WebSEAL, a stiskněte klávesu Enter.

62


Zobrazí se menu Nastavení Access Manager WebSEAL for e-business. Menu Nastavení Access Manager WebSEAL for e-business 1. 2. 3. x.

Přidat instanci Odkonfigurovat Zobrazit stav konfigurace Konec


5. Zadejte ″1″, čímž zvolíte Přidat instanci, a stiskněte klávesu Enter. Spustí se skript Konfigurace instance WebSEAL. 6. Zadejte jméno instance (například webseal1) a stiskněte klávesu Enter. Zadejte jméno instance WebSEAL: webseal1

Délka tohoto jména je omezena na 20 znaků. 7. Zadejte port pro Access Manager Listener a stiskněte klávesu Enter. Standardně první server WebSEAL očekává požadavky z interní komunikace mezi servery produktu Access Manager na portu 7234. Toto číslo portu se automaticky zvyšuje o jedničku při každé nové instanci serveru WebSEAL. Takže pro první instanci serveru WebSEAL se objeví číslo portu 7235. Přijměte vypsanou předvolenou hodnotu portu procesu Listener, nebo zadejte jinou (ale jedinečnou) hodnotu. Zadejte port pro Access Manager Listener [7235]:

8. Zadejte ″n″ (ne) do pole Použít logické síťové rozhraní a stiskněte klávesu Enter. Použít logické síťové rozhraní (y/n) [No] n

9. Zadejte heslo administrátora (uživatele sec_master) a stiskněte klávesu Enter. Zadejte heslo administrátora Access Manager:

10. Zadejte ″y″ (yes - ano), nebo ″n″ (no - ne), chcete-li povolit nebo zakázat komunikaci prostřednictvím protokolu SSL mezi serverem Access Manager a serverem LDAP. Chcete povolit komunikaci SSL mezi serverem Access Manager a serverem LDAP (y/n) [Yes]?

Pokud chcete bezpečnou komunikaci SSL mezi instancí serveru WebSEAL a serverem LDAP, přejděte ke kroku 11. Pokud nechcete bezpečnou komunikaci SSL mezi instancí serveru WebSEAL a serverem LDAP, přejděte ke kroku 12. 11. Zadejte ″y″ (yes - ano) pouze tehdy, pokud si přejete zajistit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL. Zadejte následující informace (po zadání každého záznamu stiskněte klávesu Enter): Zadejte Zadejte Zadejte Zadejte

umístění souboru klíčů SSL klienta LDAP: označení certifikátu SSL klienta (je-li požadováno): heslo souboru klíčů SSL klienta LDAP: číslo portu SSL serveru LDAP:

12. Zadejte ″n″ (no - ne), pokud si nepřejete zabezpečit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL. Stiskněte klávesu Enter. 13. Zobrazí se menu pro kontrolu konfigurace webového serveru. Zvolte odpovídající volby v menu, abyste povolili nebo zakázali komunikaci HTTP a HTTPS, změňte předvolené hodnoty portů (pokud to je nutné) a změňte umístění kořenového adresáře dokumentů. Pokud první server WebSEAL používá pro přístup HTTP port 80, pak je číslo portu automaticky zvyšováno o jedničku, tj. pro první instanci na číslo 81. Pokud první server WebSEAL používá pro přístup HTTPS port 443, pak je číslo portu automaticky zvyšováno o jedničku, tj. pro první instanci na číslo 444. Zkontrolujte, prosím, konfiguraci webového serveru: 1. Povolit TCP HTTP?

Ano Kapitola 3. Pokročilá konfigurace serveru

63

2. 3. 4. 5.

Port HTTP 81 Povolit HTTPS? Ano Port HTTPS 444 Kořenový adresář webových dokumentů

/opt/pdweb/www-webseal1/docs

a. Přijmout konfiguraci a pokračovat v konfiguraci x. Ukončit konfiguraci Vyberte položku, kterou chcete změnit: a

14. Až provedete všechny změny v konfiguraci, zadejte ″a″, čímž přijmete hodnoty konfigurace, a stiskněte klávesu Enter. Konfigurace bude pokračovat. 15. Vytvoří se instance serveru WebSEAL (to trvá nějakou dobu). * Konfigurace webového serveru Probíhá konfigurace aplikace "webseal1-webseald". Průběh může trvat několik minut. Konfigurace SSL skončila pro aplikaci úspěšně. * Spouští se server Access Manager WebSEAL, verze 4.1.0 (vypracováno 020730) Copyright (C) IBM Corporation 1994-2002.

Všechna práva vyhrazena.

webseal1 instance byla úspěšně konfigurována. Pro pokračování stiskněte ENTER ...

16. Stiskněte klávesu Enter. Vrátíte se do Menu Nastavení Access Manager WebSEAL for e-business. Menu Nastavení Access Manager WebSEAL for e-business 1. 2. 3. x.



17. Zadejte ″3″, čímž zobrazíte stav serverů WebSEAL. Stiskněte klávesu Enter. Stav konfigurace Access Manager WebSEAL Instance nakonfigurována spuštěna -----------------------------------------webseald ano ano webseald-webseal1 ano ano Pro pokračování stiskněte ENTER ...

18. Stisknutím klávesy Enter se vrátíte do Menu Nastavení Access Manager WebSEAL for e-business. Můžete nakonfigurovat další instanci, nebo ukončit obslužný program pdconfig. Konfigurace více instancí na jedinečných logických síťových rozhraních: V tomto případě se nová instance serveru WebSEAL stane jedinečnou tak, že různá síťová rozhraní budou používat společné určení naslouchacího portu HTTP/HTTPS. 1. Předpoklad: OS Windows má nakonfigurován první server WebSEAL a jednu fyzickou síťovou kartu/IP adresu.

64


2. Standardně první server WebSEAL očekává požadavky na portech HTTP/HTTPS *:80 a *:443 (tj. pro všechna dostupná rozhraní). Než budete moci nakonfigurovat a spustit další instance serveru WebSEAL, musíte prvnímu serveru WebSEAL přiřadit určitou IP adresu pro dané síťové rozhraní. Další servery WebSEAL nebude možné spustit, pokud si první server WebSEAL vyhradí, že bude očekávat požadavky na portech *:80 a *:443 pro všechna síťová rozhraní. 3. Editujte konfigurační soubor webseald.conf a uveďte odpovídající IP adresu prvního serveru WebSEAL tak, že přidáte parametr network-interface do stanzy [server]. Hodnota parametru network-interface musí být IP adresa předvoleného síťového rozhraní. Například: [server] network-interface = 1.2.3.4

4. Znovu spusťte server WebSEAL. # /usr/bin/pdweb restart webseald

Nyní první server WEbSEAL očekává požadavky na portu 80 (HTTP) a na portu 443 (HTTPS), a to pouze přes rozhraní 1.2.3.4. 5. Spusťte obslužný program pdconfig: # pdconfig




6. Zadejte ″1″, čímž zvolíte Konfigurovat sadu programů, a stiskněte klávesu Enter. Zobrazí se menu Konfigurace Access Manager for e-business. Menu Konfigurace Access Manager for e-business 1. Konfigurace Access Manager WebSEAL x. Návrat do Menu Nastavení Access Manager for e-business Vyberte prosím položku menu [x]:

7. Zadejte ″1″, čímž zvolíte Konfigurace Access Manager WebSEAL, a stiskněte klávesu Enter. Zobrazí se menu Nastavení Access Manager WebSEAL for e-business. Menu Nastavení Access Manager WebSEAL for e-business 1. 2. 3. x.



8. Zadejte ″1″, čímž zvolíte Přidat instanci, a stiskněte klávesu Enter. Spustí se skript Konfigurace instance WebSEAL. 9. Zadejte jméno instance (například webseal2) a stiskněte klávesu Enter. Zadejte jméno instance WebSEAL: webseal2

Délka tohoto jména je omezena na 20 znaků. 10. Zadejte port pro Access Manager Listener a stiskněte klávesu Enter. Standardně první server WebSEAL očekává požadavky z interní komunikace mezi servery produktu Access Manager na portu 7234. Toto číslo portu se automaticky


65

zvyšuje o jedničku při každé nové instanci serveru WebSEAL. Takže pro první instanci serveru WebSEAL se objeví číslo portu 7235. Přijměte vypsanou předvolenou hodnotu portu procesu Listener, nebo zadejte jinou (ale jedinečnou) hodnotu. Zadejte port pro Access Manager Listener [7235]:

11. Zadejte ″y″ (yes - ano) do pole Použít logické síťové rozhraní a stiskněte klávesu Enter. Použít logické síťové rozhraní (y/n) [No] y

12. Zadejte logické síťové rozhraní a stiskněte klávesu Enter. (Váš správce sítě by vám měl dát tuto IP adresu). Zadejte logické síťové rozhraní: 1.2.3.5

13. Zadejte heslo administrátora (uživatele sec_master) a stiskněte klávesu Enter. Zadejte heslo administrátora Access Manager:

14. Zadejte ″y″ (yes - ano), nebo ″n″ (no - ne), chcete-li povolit nebo zakázat komunikaci prostřednictvím protokolu SSL mezi serverem Access Manager a serverem LDAP. Chcete povolit komunikaci SSL mezi serverem Access Manager a serverem LDAP (y/n) [Yes]?

Pokud chcete zabezpečit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL, přejděte ke kroku 15. Pokud nechcete zabezpečit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL, přejděte ke kroku 16. 15. Zadejte ″y″ (yes - ano) pouze tehdy, pokud si přejete zajistit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL. Zadejte následující informace (po zadání každého záznamu stiskněte klávesu Enter): Zadejte Zadejte Zadejte Zadejte

umístění souboru klíčů SSL klienta LDAP: označení certifikátu SSL klienta (je-li požadováno): heslo souboru klíčů SSL klienta LDAP: číslo portu SSL serveru LDAP:

16. Zadejte ″n″ (no - ne), pokud si nepřejete zabezpečit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL. Stiskněte klávesu Enter. 17. Zobrazí se menu pro kontrolu konfigurace webového serveru. Zvolte odpovídající volby v menu, abyste povolili nebo zakázali komunikaci HTTP a HTTPS, změňte předvolené hodnoty portů (pokud to je nutné) a změňte umístění kořenového adresáře dokumentů. Porty jsou automaticky nastaveny na hodnoty 80 (HTTP) a 443 (HTTPS). Zkontrolujte, prosím, konfiguraci webového serveru: 1. 2. 3. 4. 5.

Povolit TCP HTTP? Ano Port HTTP 80 Povolit HTTPS? Ano Port HTTPS 443 Kořenový adresář webových dokumentů /opt/pdweb/www-webseal2/docs

a. Přijmout konfiguraci a pokračovat v konfiguraci x. Ukončit konfiguraci Vyberte položku, kterou chcete změnit: a

18. Až provedete všechny změny v konfiguraci, zadejte ″a″, čímž přijmete hodnoty konfigurace, a stiskněte klávesu Enter. Konfigurace bude pokračovat. 19. Vytvoří se instance serveru WebSEAL (to trvá nějakou dobu). * Konfigurace webového serveru Probíhá konfigurace aplikace "webseal2-webseald". Průběh může trvat několik minut. Konfigurace SSL skončila pro aplikaci úspěšně.

66


* Spouští se server Access Manager WebSEAL, verze 4.1.0 (vypracováno 020730) Copyright (C) IBM Corporation 1994-2002.

Všechna práva vyhrazena.

webseal2 instance byla úspěšně konfigurována. Pro pokračování stiskněte ENTER ...

20. Stiskněte klávesu Enter. Vrátíte se do Menu Nastavení Access Manager WebSEAL for e-business. Menu Nastavení Access Manager WebSEAL for e-business 1. 2. 3. x.



21. Zadejte ″3″, čímž zobrazíte stav serverů WebSEAL. Stiskněte klávesu Enter. Stav konfigurace Access Manager WebSEAL Instance nakonfigurována spuštěna -----------------------------------------webseald ano ano webseald-webseal2 ano ano Pro pokračování stiskněte ENTER ...

22. Stisknutím klávesy Enter se vrátíte do Menu Nastavení Access Manager WebSEAL for e-business. Můžete nakonfigurovat další instanci, nebo ukončit obslužný program pdconfig.

Konfigurace více instancí serveru WebSEAL na operačním systému Windows Předpoklady: v první server WebSEAL byl nakonfigurován v popisované procedury platí pro platformu Windows NT a Windows 2000 Konfigurace více instancí na jedinečných portech HTTP/HTTPS: V tomto případě se stane více instancí serveru WebSEAL jedinečnými tak, že budou na společném síťovém rozhraní určeny různé naslouchací porty HTTP/HTTPS. 1. Předpoklad: OS Windows má nakonfigurován první server WebSEAL (pdconfig) a fyzickou síťovou kartu/IP adresu (v tomto případě: 1.2.3.4). 2. Spusťte obslužný program pdconfig: MSDOS> pdconfig

Zobrazí se dialogové okno Konfigurace Access Manager for e-business. Všimněte si, že v okně se seznamem je uvedena komponenta Access Manager WebSEAL. 3. V okně se seznamem zvýrazněte Access Manager WebSEAL a klepněte na tlačítko Konfigurovat. Zobrazí se dialogové okno Konfigurace Access Manager WebSEAL for e-business. V okně se seznamem se zobrazí záznam představující první předvolený server WebSEAL. Kapitola 3. Pokročilá konfigurace serveru

67

4. Klepněte na tlačítko Přidat instanci. Zobrazí se dialogové okno Jméno instance WebSEAL. 5. Zadejte jméno instance (například webseal1) a klepněte na tlačítko OK. Délka tohoto jména je omezena na 20 znaků. Zobrazí se dialogové okno Port pro Access Manager Listener. 6. Přijměte zobrazenou předvolenou hodnotu portu procesu Listener, nebo zadejte jinou (ale jedinečnou) hodnotu. Standardně první server WebSEAL očekává požadavky z interní komunikace mezi servery produktu Access Manager na portu 7234. Toto číslo portu se automaticky zvyšuje o jedničku při každé nové instanci serveru WebSEAL. Takže pro první instanci serveru WebSEAL se objeví číslo portu 7235. 7. Klepněte na tlačítko OK. Zobrazí se dialogové okno Konfigurace instance s logickými síťovými rozhraními. 8. V položce Použít logické síťové rozhraní zvolte hodnotu ″No″ (Ne) a klepněte na tlačítko OK. 9. Pro každou relaci pdconfig musíte zadat heslo administrátora (uživatele sec_master). Pokud jste pro tuto relaci pdconfig dosud nezadali heslo administrátora, zobrazí se dialogové okno Heslo administrátora Access Manager. Pokud jste je již zadali, zobrazí se dialogové okno Komunikace přes SSL se serverem LDAP. Je-li to potřeba, zadejte heslo uživatele sec_master a klepněte na tlačítko OK. 10. Zobrazí se dialogové okno Komunikace přes SSL se serverem LDAP. Pokud chcete bezpečnou komunikaci SSL mezi instancí serveru WebSEAL a serverem LDAP, přejděte ke kroku 11. Pokud nechcete bezpečnou komunikaci SSL mezi instancí serveru WebSEAL a serverem LDAP, přejděte ke kroku 12. 11. Zaškrtněte pole ″ano″ pouze tehdy, pokud si přejete zajistit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL. a. Zadejte informace o protokolu SSL pro klienta LDAP: v Číslo naslouchacího portu SSL v Úplná cesta umístění databázového souboru klíčů v Označení certifikátu v Heslo databázového souboru klíčů b. Klepněte na tlačítko OK. c. Zobrazí se dialogové okno HTTP Properties (Vlastnosti HTTP). Přejděte ke kroku 13. 12. Zaškrtněte pole ″ne″, pokud si nepřejete zabezpečit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL. Klepněte na tlačítko OK. Zobrazí se dialogové okno HTTP Properties (Vlastnosti HTTP). Přejděte ke kroku 13. 13. V dialogovém okně HTTP Properties (Vlastnosti HTTP) povolte HTTP a /nebo HTTPS přístup tak, že zaškrtnete odpovídající zaškrtávací pole. 14. Uveďte odpovídající čísla portů. Pokud první server WebSEAL používá pro přístup HTTP port 80, pak je číslo portu automaticky zvyšováno o jedničku, tj. pro první instanci na číslo 81. Pokud první server WebSEAL používá pro přístup HTTPS port 443, pak je číslo portu automaticky zvyšováno o jedničku, tj. pro první instanci na číslo 444. 15. Klepněte na tlačítko OK. Vytvoří se instance serveru WebSEAL (to trvá nějakou dobu).

68


Nová instance serveru WebSEAL bude vypsána v okně se seznamem dialogového okna Konfigurace Access Manager WebSEAL for e-business. Konfigurace více instancí na jedinečných logických síťových rozhraních: V tomto případě se nová instance serveru WebSEAL stane jedinečnou tak, že různá síťová rozhraní budou používat společné určení naslouchacího portu HTTP/HTTPS. 1. Předpoklad: OS Windows má nakonfigurován první server WebSEAL a jednu fyzickou síťovou kartu/IP adresu. 2. Standardně první server WebSEAL očekává požadavky na portech HTTP/HTTPS *:80 a *:443 (tj. pro všechna dostupná rozhraní). Než budete moci nakonfigurovat a spustit další instance serveru WebSEAL, musíte prvnímu serveru WebSEAL přiřadit určitou IP adresu pro dané síťové rozhraní. Další servery WebSEAL nebude možné spustit, pokud si první server WebSEAL vyhradí, že bude očekávat požadavky na portech *:80 a *:443 pro všechna síťová rozhraní. 3. Editujte konfigurační soubor webseald.conf a uveďte odpovídající IP adresu prvního serveru WebSEAL tak, že přidáte parametr network-interface do stanzy [server]. Hodnota parametru network-interface musí být IP adresa předvoleného síťového rozhraní. Například: [server] network-interface = 1.2.3.4

4. Server WebSEAL znovu spusťte ze Services Control Panel (Ovládacího panelu Služby systému Windows). Nyní první server WEbSEAL očekává požadavky na portu 80 (HTTP) a na portu 443 (HTTPS), a to pouze přes rozhraní 1.2.3.4. 5. Spusťte obslužný program pdconfig: MSDOS> pdconfig

Zobrazí se dialogové okno Konfigurace Access Manager for e-business. Všimněte si, že v okně se seznamem je uvedena komponenta Access Manager WebSEAL. 6. V okně se seznamem zvýrazněte Access Manager WebSEAL a klepněte na tlačítko Konfigurovat. Zobrazí se dialogové okno Konfigurace Access Manager WebSEAL for e-business. V okně se seznamem se zobrazí záznam představující první předvolený server WebSEAL. 7. Klepněte na tlačítko Přidat instanci. Zobrazí se dialogové okno Jméno instance WebSEAL. 8. Zadejte jméno instance (například webseal2) a klepněte na tlačítko OK. Délka tohoto jména je omezena na 20 znaků. Zobrazí se dialogové okno Port pro Access Manager Listener. 9. Přijměte zobrazenou předvolenou hodnotu portu procesu Listener, nebo zadejte jinou (ale jedinečnou) hodnotu. Standardně první server WebSEAL očekává požadavky z interní komunikace mezi servery produktu Access Manager na portu 7234. Toto číslo portu se automaticky zvyšuje o jedničku při každé nové instanci serveru WebSEAL. Takže pro první instanci serveru WebSEAL se objeví číslo portu 7235. Zobrazí se dialogové okno Konfigurace instance s logickými síťovými rozhraními. 10. V položce Použít logické síťové rozhraní zvolte hodnotu ″Yes″ (Ano) a klepněte na tlačítko OK. 11. Zadejte IP adresu logického síťového rozhraní. (Váš správce sítě by vám měl dát tuto IP adresu.) Klepněte na tlačítko OK. Kapitola 3. Pokročilá konfigurace serveru

69

12. Pro každou relaci pdconfig musíte zadat heslo administrátora (uživatele sec_master). Pokud jste pro tuto relaci pdconfig dosud nezadali heslo administrátora, zobrazí se dialogové okno Heslo administrátora Access Manager. Pokud jste je již zadali, zobrazí se dialogové okno Komunikace přes SSL se serverem LDAP. Je-li to potřeba, zadejte heslo uživatele sec_master a klepněte na tlačítko OK. 13. Zobrazí se dialogové okno Komunikace přes SSL se serverem LDAP. Pokud chcete zabezpečit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL, přejděte ke kroku 14. Pokud nechcete zabezpečit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL, přejděte ke kroku 15. 14. Zaškrtněte pole ″ano″ pouze tehdy, pokud si přejete zajistit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL. a. Zadejte informace o protokolu SSL pro klienta LDAP: v Číslo naslouchacího portu SSL v Úplná cesta umístění databázového souboru klíčů v Označení certifikátu v Heslo databázového souboru klíčů b. Klepněte na tlačítko OK. c. Zobrazí se dialogové okno HTTP Properties (Vlastnosti HTTP). Přejděte ke kroku 16. 15. Zaškrtněte pole ″ne″, pokud si nepřejete zabezpečit komunikaci mezi instancí serveru WebSEAL a serverem LDAP pomocí protokolu SSL. Klepněte na tlačítko OK. Zobrazí se dialogové okno HTTP Properties (Vlastnosti HTTP). Přejděte ke kroku 16. 16. Dialogové okno HTTP Properties (Vlastnosti HTTP) ukazuje, že pro přístup prostřednictvím protokolu HTTP je nastaven port 80 a pro přístup prostřednictvím protokolu HTTPS port 443. 17. Přijměte předvolené hodnoty portů, nebo zadejte jiné hodnoty portů, pokud tak potřebujete. Klepněte na tlačítko OK. Vytvoří se instance serveru WebSEAL (to trvá nějakou dobu). Nová instance serveru WebSEAL bude vypsána v okně se seznamem dialogového okna Konfigurace Access Manager WebSEAL for e-business.

Odkonfigurování více instancí serveru WebSEAL První server WebSEAL nemůžete odkonfigurovat, dokud neodkonfigurujete všechny další instance serveru WebSEAL. Pokud se pokusíte odkonfigurovat první server WebSEAL dříve, než odstraníte všechny instance, objeví se chybová zpráva a budete vráceni do konfiguračního menu. UNIX: 1. Spusťte obslužný program pdconfig: # pdconfig




2. Zadejte ″2″, čímž zvolíte Odkonfigurovat sadu programů, a stiskněte klávesu Enter.

70


Zobrazí se menu Odkonfigurování Access Manager for e-business. Menu Odkonfigurování Access Manager for e-business 1. 2. 3. x.

Odkonfigurování Access Manager WebSEAL Odkonfigurování Access Manager Policy Server Odkonfigurování Access Manager Runtime Návrat do Menu Nastavení Access Manager for e-business


3. Zadejte ″1″, čímž zvolíte Odkonfigurování Access Manager WebSEAL. Zobrazí se menu Nastavení Access Manager WebSEAL for e-business. Menu Nastavení Access Manager WebSEAL for e-business 1. 2. 3. x.



4. Zadejte ″2″, čímž zvolíte Odkonfigurovat, a stiskněte klávesu Enter. Zobrazí se menu Odkonfigurování Access Manager WebSEAL for e-business. Menu Odkonfigurování Access Manager WebSEAL for e-business --------------------------------------------------------1. 2. 3. x.

webseald-web1 webseald-web2 webseald Konec


5. Zadejte číslo přidělené v menu instanci serveru WebSEAL, kterou chcete odkonfigurovat (odstranit). Stiskněte klávesu Enter. Vyberte prosím položku menu [x]: 2

6. Zadejte heslo administrátora (uživatele sec_master) a stiskněte klávesu Enter. Instance serveru WebSEAL se odkonfiguruje a odstraní (to trvá nějakou dobu). Odkonfigurovává se instance WebSEAL Zadejte heslo administrátora Access Manager: * Čistí se soubory protokolu Zastavení: webseald-webseal2 * Server se odkonfigurovává Probíhá odkonfigurování aplikace "webseal2-webseald". Průběh může trvat několik minut. Odkonfigurování SSL pro aplikaci "webseal2-webseald" skončilo úspěšně. webseal2 instance byla úspěšně odkonfigurována. Pro pokračování stiskněte ENTER ...

7. Stisknutím klávesy Enter se vrátíte do Menu Odkonfigurování Access Manager WebSEAL for e-business. Můžete odkonfigurovat další instanci serveru WebSEAL a dalším používáním klávesy Enter ukončit obslužný program pdconfig. Windows: 1. Spusťte obslužný program pdconfig: MSDOS> pdconfig

Zobrazí se dialogové okno Konfigurace Access Manager for e-business. Kapitola 3. Pokročilá konfigurace serveru

71

2.

3. 4.

5.

Všimněte si, že v okně se seznamem je uvedena komponenta Access Manager WebSEAL. V okně se seznamem zvýrazněte Access Manager WebSEAL a klepněte na tlačítko Odkonfigurovat. Zobrazí se dialogové okno Konfigurace Access Manager WebSEAL for e-business. V okně se seznamem se objeví záznamy představující první server WebSEAL a všechny nakonfigurované instance serveru WebSEAL. V okně se seznamem zvýrazněte instanci serveru WebSEAL, kterou chcete odkonfigurovat a odstranit. Klepněte na tlačítko Odkonfigurovat. Pro každou relaci pdconfig musíte zadat heslo administrátora (uživatele sec_master). Pokud jste pro tuto relaci pdconfig dosud nezadali heslo administrátora, zobrazí se dialogové okno Heslo administrátora Access Manager. Jinak se provede odkonfigurování zvolené instance serveru WebSEAL. Je-li to potřeba, zadejte heslo uživatele sec_master a klepněte na tlačítko OK. Instance serveru WebSEAL se odkonfiguruje a odstraní (to trvá nějakou dobu). Tato instance serveru WebSEAL se již v okně se seznamem dialogového okna Konfigurace Access Manager WebSEAL for e-business neobjeví.

Příkazy pro spuštění, zastavení, opětovné spuštění a dotaz na stav serveru UNIX: Obslužný program pdweb nabízí způsob, jak spustit, zastavit, opětovně spustit a získat informace o stavu prvního serveru WebSEAL a všech dalších instancí serveru WebSEAL. Tento příkaz můžete také použít pro určitou instanci serveru. pdweb {start|stop|restart|status} [<jméno-instance>]

Příklady: Spusťte první server WebSEAL a všechny nakonfigurované instance serveru WebSEAL: # /usr/bin/pdweb start

Spusťte pouze určitou instanci serveru: # /usr/bin/pdweb start webseal3

Znovu spusťte první server WebSEAL a všechny nakonfigurované instance serveru WebSEAL: # /usr/bin/pdweb restart

Zastavte první server WebSEAL a všechny nakonfigurované instance serveru WebSEAL: # /usr/bin/pdweb stop

Zastavte pouze určitou instanci serveru: # /usr/bin/pdweb stop webseal3

Zobrazte stav všech nakonfigurovaných serverů: # /opt/PolicyDirector/bin/pd_start status Servery Access Manager Server Aktivní Prováděný -----------------------------------------pdmgrd ano ano pdacld ano ano webseald ano ano webseald-webseal2 ano ano webseald-webseal3 ano ano

Windows: Services Control Panel (Ovládací panel Služby) operačního systému Windows dovoluje spustit a zastavit server a poskytuje informace o stavu serveru.

72


Jinou možností, jak spustit a zastavit první server WebSEAL a všechny další instance serveru WebSEAL, je použít příkaz net. net {start|stop} <jméno-instance>

Příklady: Spusťte první server WebSEAL a všechny nakonfigurované instance serveru (uvedený příkaz musíte zopakovat pro každou instanci): MSDOS> net start webseald MSDOS> net start webseal2 MSDOS> net start webseal3

Zastavte první server WebSEAl a všechny nakonfigurované instance serveru (uvedený příkaz musíte zopakovat pro každou instanci): MSDOS> net stop webseald MSDOS> net stop webseal2 MSDOS> net stop webseal3

Zobrazte stav všech nakonfigurovaných serverů: Start > Settings (Nastavení) > Control Panel (Ovládací panel)> Services (Služby)

Konfigurace přepnutí uživatele Funkční vlastnost serveru WebSEAL, nazývající se přepnutí uživatele, umožňuje, aby určití administrátoři přebírali totožnosti uživatele, který je členem zabezpečené domény produktu Tivoli Access Manager. Schopnost přebírat totožnosti uživatele může pomoci administrátorovi v prostředí helpdesku, aby diagnostikoval a vyřešil problém uživatele. Přepnutí uživatele se může také používat k ověření přístupu uživatele ke zdrojům a k provádění testování integrace aplikací. Přečtěte si celou tuto část, abyste si byli jisti, že jste pochopili funkcionalitu přepnutí uživatele, než tuto vlastnost nakonfigurujete a začnete ji používat. Tato část obsahuje následující témata: v “Přehled funkce přepnutí uživatele” v “Procedura konfigurace” na stránce 75 v “Používání přepnutí uživatele” na stránce 80 v “Vývoj přizpůsobené služby CDAS pro přepnutí uživatele” na stránce 82

Přehled funkce přepnutí uživatele Implementace přepnutí uživatele je podobná implementaci příkazu su v prostředí operačního systému Unix. V prostředí serveru WebSEAL administrátor získá pověření uživatele a tak může pracovat se zdroji a aplikacemi typu back-end s naprosto stejnými schopnostmi jako skutečný uživatel. Administrátor používá speciální HTML formulář, aby zadal informace nutné pro přepnutí uživatele. Server WebSEAL zpracuje formulář a aktivuje speciální mechanismus autentizace, který vrátí pověření uvedeného uživatele bez požadavku na zadání hesla uživatele. Níže uvedená posloupnost popisuje proces přepnutí uživatele: 1. Administrátor se autentizuje do serveru WebSEAL. Server WebSEAL vytvoří pro administrátora relaci a v paměti cache pro relace serveru WebSEAL se vytvoří záznam administrátora. Záznam paměti cache pro relace obsahuje datovou strukturu paměti cache. Tato datová struktura obsahuje pověření administrátora. Během procesu přepnutí uživatele bude manipulováno s daty v paměti cache. Podrobnější informace o pamětích cache pro relace serveru WebSEAL najdete v části “Struktura paměti cache pro relace/pověření serveru WebSEAL” na stránce 11. Kapitola 3. Pokročilá konfigurace serveru

73

2. Administrátor se připojí k předkonfigurovanému HTML formuláři pro přepnutí uživatele a vyplní tento formulář. Ve formuláři administrátor zadá: v jméno totožnosti uživatele, kterou potřebuje administrátor získat v cílové URL v politiku autentizace Výsledkem této akce je požadavek POST, který je odeslán na /pkmssu.form. Administrátor serveru WebSEAL může případně upravit obsah HTML formuláře pro přepnutí uživatele, než jej dá k dispozici dalším administrátorům. Viz “Část 3: Konfigurace HTML formuláře pro přepnutí uživatele” na stránce 78. Administrátor může dále případně rozšířit možnosti formuláře. Viz “Část 4: Návrh dalších zadávacích formulářů” na stránce 80. 3. Server WebSEAL určí, zda se má povolit požadavek na přepnutí uživatele tak, že provede následující kontroly: a. Server WebSEAL určí členství ve skupině su-admins produktu Tivoli Access Manager, aby určil, zda administrátor má oprávnění volat funkci přepnutí uživatele. Administrátoři, kteří požadují autentizaci pro přepnutí uživatele musí být členy skupiny su-admins. Členství v této skupině musí být nakonfigurováno dříve, než se začne používat funkce přepnutí uživatele. Podrobnější informace najdete v části “Část 1: Konfigurace přístupu uživatele” na stránce 75. b. Server WebSEAL zkontroluje členství ve skupinách su-admins, securitygroup a su-excluded produktu Tivoli Access Manager, aby se ujistil, že totožnost uživatele zadaná ve formuláři pro přepnutí uživatele není členem některé z těchto skupin. Totožnosti uživatele, které patří do některé z těchto skupin, nelze přebírat pomocí funkce přepnutí uživatele. Administrátor serveru WebSEAL musí členství v těchto skupinách nakonfigurovat dříve, než administrátoři začnou používat funkci pro přepnutí uživatele. Instrukce ke konfiguraci a více informací o těchto skupinách najdete v části “Část 1: Konfigurace přístupu uživatele” na stránce 75. 4. Je-li povolen přístup k funkci přepnutí uživatele, server WebSEAL zavolá odpovídající sdílenou knihovnu pro přepnutí uživatele, aby provedl speciální autentizaci pro přepnutí uživatele. Server WebSEAL podporuje řadu odlišných mechanismů autentizace. Každý mechanismus autentizace má odpovídající mechanismus autentizace pro přepnutí uživatele. Server WebSEAL obsahuje sdílené knihovny, které obsahují speciální mechanismy pro přepnutí uživatele. Než bude možné používat autentizaci pro přepnutí uživatele, administrátor serveru WebSEAL musí nakonfigurovat server WebSEAL tak, aby používal nezbytné sdílené knihovny. Podrobnější informace najdete v části “Část 2: Konfigurace mechanismu autentizace přepnutí uživatele” na stránce 76. Poznámka: Autentizace pro přepnutí uživatele se může také provádět pomocí přizpůsobené knihovny CDAS pro přepnutí uživatele. Podrobnější informace najdete v části “Vývoj přizpůsobené služby CDAS pro přepnutí uživatele” na stránce 82. 5. Je-li autentizace určeného uživatele úspěšná, mechanismus autentizace pro přepnutí uživatele vrátí platné pověření uživatele — aniž by vyžadoval zadání hesla uživatele. 6. Server WebSEAL manipuluje s obsahem odpovídajícího záznamu v paměti cache pro relace serveru WebSEAL tak, že: a. umístí pověření uživatele do nové datové struktury paměti cache b. odstraní data administrátora z paměti cache pro relace serveru WebSEAL a uloží je do jiného místa c. vloží data uživatele do paměti cache, včetně pověření uživatele, na místo dat administrátora

74


7. Server WebSEAL odešle a přesměruje prohlížeč na cílové URL, které bylo zadáno ve formuláři pro přepnutí uživatele. Požadavek se zpracuje obvyklým způsobem pomocí pověření uživatele, a bude přistoupeno k danému URL. 8. Administrátor může pokračovat ve vydávání dalších požadavků. Veškerá rozhodnutí o autorizaci těchto požadavků jsou založena na pověření uživatele. Při používání funkcionality pro přepnutí uživatele by mohli administrátoři potřebovat ustanovit a spravovat relace s dalšími aplikacemi. Tyto relace se musí ustanovit s pomocí totožnosti nového uživatele. Aby to bylo možné, pověření nového uživatele také obsahuje nové ID relace uživatele. Toto ID relace uživatele se například používá při odstraňování problémů ve schopnosti uživatele přistupovat a používat další webové zdroje. Podrobnější informace o pamětech cache pro relace serveru WebSEAL najdete v části “Aktivace správy ID relací uživatelů” na stránce 226 a “Struktura paměti cache pro relace/pověření serveru WebSEAL” na stránce 11. 9. Administrátor ukončí relaci přepnutí uživatele pomocí standardního obslužného programu produktu Tivoli Access Manager /pkmslogout. Po úspěšném odhlášení: a. jsou data uživatele v paměti cache vymazána b. jsou obnovena původní data administrátora (a pověření) v paměti cache c. administrátor se vrátí na původní stránku, ze které si vyžádal formulář pro přepnutí uživatele Autorizační služba použije původní pověření administrátora pro všechny následující požadavky.

Procedura konfigurace Administrátor serveru WebSEAL musí provést několik konfiguračních kroků, než budou ostatní administrátoři používat funkcionalitu pro přepnutí uživatele. Chcete-li nakonfigurovat přepnutí uživatele, postupujte podle instrukcí v každé z následujících částí: 1. “Část 1: Konfigurace přístupu uživatele” 2. “Část 2: Konfigurace mechanismu autentizace přepnutí uživatele” na stránce 76 3. “Část 3: Konfigurace HTML formuláře pro přepnutí uživatele” na stránce 78 Tato část je volitelná. 4. “Část 4: Návrh dalších zadávacích formulářů” na stránce 80 Tato část je volitelná. 5. “Část 5: Zastavení a opětovné spuštění serveru WebSEAL” na stránce 80

Část 1: Konfigurace přístupu uživatele Během instalace serveru WebSEAL proces konfigurace serveru WebSEAL automaticky vytvoří několik skupin, které používá funkcionalita pro přepnutí uživatele. Administrátor serveru WebSEAL řídí schopnost přepnutí uživatele prostřednictvím přidání uživatelů do příslušných skupin. Chcete-li nakonfigurovat přístup uživatele, postupujte podle následujících kroků: 1. Přidejte uživatele do skupiny su-admins. Pokud chce uživatel používat funkci pro přepnutí uživatele, musí být členem administrativní skupiny s názvem su-admins. Tato skupina se automaticky vytvoří během instalace serveru WebSEAL. Standardně nejsou v této skupině žádní uživatelé. Administrátor serveru WebSEAL musí do této skupiny uživatele přidat ručně. Do této skupiny se obvykle přidávají pouze administrátoři. Uživatelé, kterým bylo přiděleno členství ve skupině su-admins se mohou přepnout na uživatele pro většinu totožností uživatele, ale nemohou se přepnout na totožnost uživatele, Kapitola 3. Pokročilá konfigurace serveru

75

který je také členem skupiny su-admins. Takže jakmile je administrátorovi uděleno oprávnění pro přepnutí uživatele tak, že je přidán do skupiny su-admins, je účet administrátora chráněn před přístupem ostatních uživatelů, kteří sdílejí oprávnění pro přepnutí uživatele. 2. Přidejte uživatele do skupiny su-excluded. Tato skupina obsahuje jména uživatelů, k jejichž totožnostem nelze přistupovat prostřednictvím funkcionality přepnutí uživatele. Během instalace serveru WebSEAL proces konfigurace serveru WebSEAL automaticky vytvoří tuto skupinu. Standardně nejsou v této skupině žádní uživatelé. Administrátor serveru WebSEAL obvykle do této skupiny přidá jména uživatelů, kteří nejsou členy administrativní skupiny su-admins, ale kteří by měli být chráněni před přístupem pomocí přepnutí uživatele. Při používání přepnutí uživatele server WebSEAL také kontroluje členství ve skupině produktu Tivoli Access Manager s názvem securitygroup. Tato skupina obsahuje jméno administrátora produktu Tivoli Access Manager s názvem sec_master plus množství procesů serveru WebSEAL, které musí být vyjmuty z přístupu prostřednictvím schopnosti pro přepnutí uživatele. Tato skupina se automaticky vytvoří během instalace serveru WebSEAL. Během instalace jsou do této skupiny automaticky přidány následující totožnosti: v sec_master — administrátor produktu Tivoli Access Manager v acld – démon autorizačního serveru produktu Tivoli Access Manager v webseald — démon serveru WebSEAL Administrátoři serveru WebSEAL by neměli do skupiny securitygroup přidávat žádné uživatele. Chcete-li řídit přístup uživatele k přepnutí uživatele, použijte buď skupinu su-admins, nebo skupinu su-excluded.

Část 2: Konfigurace mechanismu autentizace přepnutí uživatele Produkt Tivoli Access Manager dodává jednoduchou zabudovanou knihovnu pro přepnutí uživatele, která implementuje mechanismus autentizace přepnutí uživatele. Knihovna pro přepnutí uživatele se liší od standardních knihoven pro autentizaci. Knihovna uvádí mechanismus autentizace, který vezme dodanou totožnost uživatele a vrátí platné pověření tohoto uživatele, aniž by vyžadovala zadání hesla. Zabudovaná sdílená knihovna pro přepnutí uživatele, která je dodávána spolu s produktem Tivoli Access Manager se nazývá libsuauthn (na systémech s operačním systémem UNIX) a suauthn (na systémech s operačním systémem Windows). Jména souboru sdílené knihovny jsou specifická pro danou platformu a jsou následující: Solaris Operating Environment (Solaris)

libsuauthn.so

AIX

libsuauthn.a

HP-UX

libsuauthn.sl

Windows

suauthn.dll

Zabudovaná knihovna podporuje následující mechanismy autentizace: v su-password v su-token-card v su-certificate v su-http-request v su-cdsso

76


Mechanismy autentizace jsou uvedeny ve stanze [authentication-mechanisms] konfiguračního souboru webseald.conf. Pro každý podporovaný mechanismus autentizace je uveden samostatný záznam. V konfiguračním souboru jsou standardně zakázány všechny mechanismy autentizace přepnutí uživatele. Například: [authentication-mechanisms] #su-password = #su-token-card = #su-certificate = #su-http-request = #su-cdsso =

Kroky konfigurace týkající se aktivace autentizace se primárně skládají z editování odpovídajících záznamů jméno=hodnota konfiguračního souboru. Když však nasazení serveru WebSEAL podporuje více než jeden mechanismus autentizace, a když administrátor chce používat funkce pro přepnutí uživatele pro více než jeden typ z podporovaných mechanismů, je nutné provést ještě některé další kroky. V takovém případě se musí provést další kopie předvolené sdílené knihovny pro přepnutí uživatele. Následující instrukce jsou rozděleny do dvou částí. První část popisuje, jak nakonfigurovat mechanismus autentizace přepnutí uživatele. Druhá část popisuje, jak nakonfigurovat více mechanismů autentizace přepnutí uživatele. Použijte ty instrukce, které odpovídají vašemu nasazení. Konfigurace jednoho mechanismu autentizace přepnutí uživatele Chcete-li aktivovat jeden mechanismus autentizace přepnutí uživatele, postupujte podle těchto kroků: 1. Editujte odpovídající záznam v souboru webseald.conf. Odstraňte znak komentáře (#) na začátku řádku. 2. Zadejte jméno knihovny autentizace přepnutí uživatele. Například na systému s operačním systémem Solaris by měl soubor webseald.conf na serveru WebSEAL, který je nakonfigurován tak, aby podporoval pouze autentizaci pomocí hesla, vypadat před konfigurací přepnutí uživatele takto: [authentication-mechanisms] passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.so ..... #su-password = #su-token-card = #su-certificate = #su-http-request = #su-cdsso =

Knihovna pro přepnutí uživatel, uvedená v záznamu su-password odpovídá knihovně autentizace, uvedené v passwd-ldap. Níže uvedený záznam, který je zvýrazněn tučným písmem, zobrazuje upravený záznam: [authentication-mechanisms] passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.so ..... su-password = /opt/PolicyDirector/lib/libsuauthn.so #su-token-card = #su-certificate = #su-http-request = #su-cdsso =

Konfigurace více mechanismů autentizace přepnutí uživatele Standardní sdílená knihovna pro přepnutí uživatele libsuauthn (UNIX) nebo suauthn (Windows) podporuje více mechanismů autentizace. V konfiguračním souboru však každý Kapitola 3. Pokročilá konfigurace serveru

77

záznam pro nakonfigurovanou knihovnu autentizace pro přepnutí uživatele musí být jedinečně pojmenován, i když se stejná sdílená knihovna použije pro více metod autentizace. V následujícím příkladu, který je uveden pro platformu Solaris, má stávající prostředí povoleny dvě metody autentizace: v autentizace pomocí formulářů používající zabudovanou knihovnu libldapauthn v autentizace pomocí certifikátů používající zabudovanou knihovnu libsslauthn Záznamy v konfiguračním souboru jsou: [authentication-mechanisms] passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.so cert-ssl = /opt/PolicyDirector/lib/libsslauthn.so

Chcete-li aktivovat mechanismus autentizace přepnutí uživatele pro obě tyto metody autentizace, postupujte takto: 1. Okopírujte sdílenou knihovnu pro přepnutí uživatele pro každý z uvedených mechanismů autentizace. Administrátor si může vybrat libovolné jméno pro každou z kopií, aby každou kopii jedinečně pojmenoval. Chcete-li například, aby přepnutí uživatele bylo podporováno pro obě autentizace, tj. pro autentizaci pomocí formulářů i autentizaci pomocí certifikátů, zadejte: # cp libsuauthn.so libsuformauthn.so # cp libsuauthn.so libsucert.so

2. Editujte odpovídající záznam v souboru webseald.conf. Odstraňte znak komentáře (#) na začátku každého záznamu každého z podporovaných mechanismů autentizace přepnutí uživatele. 3. V každém nezakomentovaném záznamu zadejte jméno jedinečně pojmenované kopie knihovny pro autentizaci přepnutí uživatele. Pro výše uvedený příklad budou aktualizované záznamy v konfiguračním souboru vypadat takto: [authentication-mechanisms] passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.so cert-ssl = /opt/PolicyDirector/lib/libsslauthn.so su-password = /opt/PolicyDirector/lib/libsuformauthn.so su-certificate = /opt/PolicyDirector/lib/libsucert.so

Prostředí je nyní rozšířeno tak, aby podporovalo funkcionalitu pro přepnutí uživatele pro obě metody autentizace. Poznámka: Pokud vaše prostředí obsahuje přizpůsobený mechanismus autentizace CDAS, musíte zajistit stejnou funkcionalitu. Viz “Vývoj přizpůsobené služby CDAS pro přepnutí uživatele” na stránce 82.

Část 3: Konfigurace HTML formuláře pro přepnutí uživatele Tato část je volitelná. Server WebSEAL obsahuje předvolený HTML formulář, ke kterému administrátor přistupuje, aby mohl použít funkci pro přepnutí uživatele. Předvolený formulář je možné používat bez dalších úprav. Volitelně můžete tento formulář editovat a zadat přizpůsobený vzhled a funkcionalitu. Předvolený formulář se jmenuje switchuser.html. Jméno tohoto formuláře je možné změnit. Obsah formuláře a jeho umístění Formulář obsahuje požadavek na: v jméno uživatele

78


Jméno uživatele, jehož pověření chce administrátor převzít. v cílové URL Tato stránka se zobrazí poté, co bude úspěšně provedena operace přepnutí uživatele. v metodu autentizace Parametry metody autentizace určují, který z mechanismů autentizace serveru WebSEAL se bude používat při vytváření pověření uživatele. Každý z těchto záznamů je povinný. Server WebSEAL ověří, že v podávaném formuláři jsou zadána všechna povinná data. Pokud data chybí, formulář je vrácen administrátorovi spolu s popisující zprávou. Pokud jsou zadána všechna povinná data, server WebSEAL předá data z formuláře pro přepnutí uživatele do URL akce /pkmssu.form. Poznámka: Tento formulář mohou volat pouze členové skupiny su-admins. Pro tento soubor není třeba přístupový seznam. Server WebSEAL provede vnitřní pevně naprogramovanou kontrolu členství ve skupině. Server WebSEAL vrátí chybu 404 ″Nenalezen″, pokud kontrola členství ve skupině selže. Úplná cesta k formuláři pro přepnutí uživatele je nadefinována v konfiguračním souboru webseald.conf. Tuto cestu je možné změnit. K v v v

vytvoření úplné cesty se používá kombinace hodnot tří parametrů: Parametr server-root je umístěn ve stanze [server] a uvádí kořen hierarchie serveru. Parametr mgt-pages-root ve stanze [acnt-mgt] uvádí umístění podadresáře. Parametr switch-user ve stanze [acnt-mgt] udává jméno souboru pro přepnutí uživatele.

Například na systému s operačním systémem UNIX by mohly záznamy v souboru webseald.conf vypadat třeba takto: [server] server-root = /opt/pdweb/www .... [acnt-mgt] mgt-pages-root = lib/html/ switch-user = switchuser.html

Hodnota adresáře LANG je specifická pro daný jazyk. Úplnou cestu k formuláři pro přepnutí uživatele můžete určit kombinací hodnot. Například na systému s operačním systémem UNIX a s jazykovým prostředím s americkou angličtinou, ve kterém se adresář LANG nazývá ″C″, bude úplná cesta: /opt/pdweb/www/lib/html/C/switchuser.html

Předvolená hodnota parametru server-root na platformě Windows je: C:\Program Files\Tivoli\PDWeb\www

Úplná cesta na platformě Windows by mohla například být: C:\Program Files\Tivoli\PDWeb\www\lib\html\C\switchuser.html

Jak přizpůsobit HTML formulář Chcete-li přizpůsobit formulář pro přepnutí uživatele, otevřete formulář tak, abyste jej mohli editovat a postupujte podle následujících kroků: 1. Zadejte umístění a obsah cílového URL. Tento parametr můžete nakonfigurovat jako skrytý vstup, který bude obsahovat odpovídající domovskou stránku nebo stránku potvrzující úspěšné provedení přepnutí uživatele. 2. Zadejte metody autentizace. Toto pole můžete nakonfigurovat jako skrytý vstup. Platné hodnoty pro metodu autentizace zahrnují: Kapitola 3. Pokročilá konfigurace serveru

79

su-ba su-forms su-certificate su-token-card su-http-request su-cdsso

Metody vypsané ve výše uvedeném seznamu se mapují přímo na mechanismy autentizace uvedené v konfiguračním souboru webseald.conf. Všimněte si však, že metody su-ba a su-forms jsou namapovány na mechanismus autentizace su-password. Jak Základní autentizace (ba), tak i autentizace pomocí formulářů (forms) používají knihovnu pro autentizaci su-password. Všimněte si, že nasazení serveru WebSEAL může podporovat Základní autentizaci, aniž by podporovalo autentizaci pomocí formulářů. Proto pro každý typ autentizace jsou spravovány samostatné konfigurační hodnoty (su-ba a su-forms).

Část 4: Návrh dalších zadávacích formulářů Tato část je volitelná. Můžete navrhnout další formuláře, pomocí kterých můžete potvrdit nebo zpracovat data, která mají být zadána do formuláře /pkmssu.form. Tyto formuláře je možné používat tehdy, chcete-li pomoci administrátorovi zaplnit některé ze záznamů ve formuláři pro přepnutí uživatele. Některé příklady: v Administrátor by se mohl rozhodnout, že chce mít různá cílová URL, ke kterým bude přistupovat na základě totožnosti uživatele. Měl by být napsán další formulář, který vytvoří a předloží seznam těchto URL, ze kterých si administrátor bude moci vybrat odpovídající záznam. v Mohl by být vytvořen další formulář, který bude volat jiný program, jako např. skript CGI, pomocí něhož bude dodávat seznam totožností uživatele, na které se může administrátor přepnout. Tento seznam by mohl pomoci administrátorům určit, zda je povolen přístup k totožnosti uživatele prostřednictvím přepnutí uživatele. v Mohl by se vytvořit formulář, který zobrazí seznam totožností uživatele, na které se nelze přepnout. Tento seznam by měl být založen na členství ve skupinách su-excluded a securitygroup.

Část 5: Zastavení a opětovné spuštění serveru WebSEAL Chcete-li aktivovat změny v konfiguraci, musíte zastavit a znovu spustit server WebSEAL. Tak povolíte serveru WebSEAL, aby používal nové hodnoty, které jste uvedli v konfiguračním souboru webseald.conf v části “Část 1: Konfigurace přístupu uživatele” na stránce 75 a “Část 2: Konfigurace mechanismu autentizace přepnutí uživatele” na stránce 76. Způsoby zastavení a opětovného spuštění serveru WebSEAL jsou popsány v části “Spuštění a zastavení serveru WebSEAL” na stránce 20.

Používání přepnutí uživatele Po dokončení kroků konfigurace uvedených v předchozí části mohou administrátoři serveru WebSEAL používat funkci pro přepnutí uživatele. Chcete-li používat funkci pro přepnutí uživatele, postupujte takto: 1. Přihlašte se jako uživatel, který má oprávnění volat funkci pro přepnutí uživatele. Tuto funkci obvykle používají administrátoři. Uživatel musí být členem skupiny su-admins. 2. Vyvolejte HTML formulář pro přepnutí uživatele.

80


Předvolené jméno souboru je switchuser.html. Podrobnější informace o úplné cestě najdete v části “Část 3: Konfigurace HTML formuláře pro přepnutí uživatele” na stránce 78. 3. Ve formuláři zadejte: v jméno totožnosti uživatele, kterou chcete přebrat v cílové URL v metodu autentizace Výsledkem této akce je požadavek POST, který je odeslán na /pkmssu.form. Server WebSEAL odešle a přesměruje prohlížeč na cílové URL, které bylo zadáno ve formuláři pro přepnutí uživatele. Požadavek se zpracuje obvyklým způsobem pomocí pověření uživatele, a bude přistoupeno k danému URL. 4. Proveďte další požadavky, je-li to nutné. Veškerá rozhodnutí o autorizaci těchto požadavků jsou založena na pověření uživatele. 5. Až skončíte, ukončete relaci přepnutí uživatele pomocí standardního obslužného programu produktu Tivoli Access Manager /pkmslogout. Podrobnější informace o tom, jak funkce pro přepnutí uživatele pracuje, najdete v části “Přehled funkce přepnutí uživatele” na stránce 73.

Další funkční vlastnosti přepnutí uživatele Tato část popisuje, jaké další funkční vlastnosti, jako např. opětovnou autentizaci, zvýšenou autentizaci, správu relací uživatele a monitorování, podporuje přepnutí uživatele.

Časový limit paměti cache pro relace Funkcionalita nakonfigurovaných hodnot časového limitu pro dobu nečinnosti a dobu trvání paměti cache pro relace serveru WebSEAL není ovlivněna operací pro přepnutí uživatele. Časovače pro dobu nečinnosti a dobu trvání jsou svázány se záznamem administrátora v paměti cache pro relace a nikoliv s daty v paměti cache, která se mění během operace přepnutí uživatele. Časovač doby nečinnosti bude vynulován, když administrátor vydá požadavek jako ″přepnutý″ uživatel. Když administrátor ukončí relaci přepnutého uživatele, nečinnost i nadále platí pro znovu zavedenou relaci administrátora. Hodnota doby trvání se nezvyšuje z důvodu operace přepnutého uživatele. Je možné, že časový limit doby trvání záznamu v paměti cache pro relace vyprší během operace přepnutí uživatele. Pokud se tak stane, paměť cache pro relace je vymazána a administrátor je odhlášen. Administrátor se pak musí opětovně autentizovat a znovu začít operaci přepnutí uživatele.

Zvýšená autentizace Specifikace sdílené knihovny mohou přebírat další parametry ve tvaru: & <arg1> <arg2> .... <argx>

Úrovně zvýšené autentizace můžete označit pomocí volby –l, za kterou bude následovat číslo ú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: Administrátor musí znát heslo uživatele, aby mohl úspěšně provést zvýšenou autentizaci.


81

Opětovná autentizace Funkcionalita opětovné autentizace serveru WebSEAL je operací přepnutí uživatele rozeznávána. Pokud se stane, že během operace přepnutí uživatele je potřeba se opětovně autentizovat, administrátor se musí autentizovat jako ″přepnutý″ uživatel. Poznámka: Administrátor musí znát heslo ″přepnutého″ uživatele, aby mohl úspěšně provést opětovnou autentizaci.

Správa relací uživatele Operace přepnutí uživatele podporuje správu relací uživatele. Administrátor má jedinečné ID relace uživatele. Během operace přepnutí uživatele existuje také jedinečné ID relace uživatele pro ″přepnutého″ uživatele. Úloha ukončení relací jednoho uživatele a úloha ukončení relací všech uživatelů jsou prováděny tak, jak je očekáváno.

Příznak-hodnota Schopnost hodnoty příznaku, která se často používá ve službě CDAS, se ve funkcionalitě přepnutí uživatele rozeznává a podporuje.

Monitorování Během operace přepnutí uživatele je možné monitorovat administrátora. Funkcionalita přepnutí uživatele přidává další atribut do pověření ″přepnutého″ uživatele, který identifikuje administrátora. Rozšířený atribut, který je uložen v pověření, se nazývá tagvalue_su-admin: tagvalue_su-admin = <jméno-su-admin>

Tento rozšířený atribut je dostupný pro každý monitorovací mechanismus.

Vývoj přizpůsobené služby CDAS pro přepnutí uživatele Funkcionalita přepnutí uživatele dále podporuje přizpůsobený mechanismus autentizace CDAS. Tato podpora je důležitá, neboť stávající mechanismus autentizace pomocí CDAS často vrací další informace o uživateli, které jsou zahrnuty do pověření uživatele. Přizpůsobenou službu CDAS je možné používat při provádění dalších kontrol týkajících se schopností uživatele, jako např. určení, kteří uživatelé se mohou přepnout na totožnosti jiných uživatelů, nebo určení časových intervalů, během kterých není povolena schopnost přepnutí se na jiného uživatele. Pokud v takovém prostředí používáte funkci přepnutí uživatele, musíte napsat speciální službu CDAS pro přepnutí uživatele, která bude emulovat chování stávající služby CDAS, zatímco bude podporovat požadavek návratu pověření bez požadavku na zadání hesla uživatele. Rozhraní API služby CDAS produktu Tivoli Access Manager nabízí sadu komponent totožnosti, které je možné použít k předání informací o autentizaci klienta do sdílené knihovny služby CDAS pro přepnutí uživatele. Tyto informace jsou předávány ve formátu seznamu jméno/hodnota, kde jméno je identifikátor, který uvádí typ hodnoty. Informace jsou uloženy v typu xnlist_t data. K hodnotám je možné přistoupit pomocí funkce xnvlist_get() obslužného programu. Komponenty totožnosti, vhodné pro službu CDAS pro přepnutí uživatele, zahrnují: xauthn_su_method xauthn_admin_name xauthn_admin_cred xauthn_existing_cred xauthn_username xauthn_qop xauthn_ipaddr xauthn_browser_info

82


Komponenty totožnosti xauthn_browser_info, xauthn_qop a xauthn_ipaddr představují totožnost administrátora, nikoliv ″přepnutého″ uživatele. Tato data jsou předána každé službě CDAS, která musí provádět další ověření platnosti účtu administrátora. Poznámka: Úplné informace a referenční materiál, týkající se psaní přizpůsobené služby CDAS, najdete v knize IBM Tivoli Access Manager WebSEAL Developer’s Reference. Konfigurace přizpůsobené služby CDAS pro přepnutí uživatele Níže uvedený příklad rozšiřuje příklad uvedený v části “Část 2: Konfigurace mechanismu autentizace přepnutí uživatele” na stránce 76. Tento příklad přidává mechanismus CDAS do seznamu povolených mechanismů autentizace. Příklad, uvedený pro platformu Solaris, zobrazuje stávající prostředí, které má povoleny tři metody autentizace: v autentizace pomocí formulářů používající zabudovanou knihovnu libldapauthn v autentizace pomocí certifikátů používající zabudovanou knihovnu libsslauthn v autentizace pomocí tokenů používající mechanismus přizpůsobené služby CDAS V tomto příkladu chce administrátor být schopen používat autentizaci přepnutí uživatele pro všechny tři metody autentizace. Proto musí být v konfiguračním souboru webseald.conf aktivovány tři další parametry autentizace pro přepnutí uživatele. Třetí parametr představuje novou přizpůsobenou knihovnu CDAS, která byla napsána, aby emulovala stávající službu CDAS využívající tokeny, a která bude podporovat požadavky autentizace pro přepnutí uživatele. Záznamy konfiguračního souboru před aktivací přepnutí uživatele pro uvedené tři mechanismy autentizace jsou: [authentication-mechanisms] passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.so cert-ssl = /opt/PolicyDirector/lib/libsslauthn.so token-cdas = /opt/PolicyDirector/lib/libcustom.so

Všimněte si, že příklad knihovny CDAS využívající tokeny se nazývá libcustom.so. Nová verze této knihovny CDAS využívající tokeny pro přepnutí uživatele se bude nazývat libsucustom.so. Po přidání mechanismů autentizace pro přepnutí uživatele budou záznamy v konfiguračním souboru vypadat takto: [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

Všimněte si těchto změn: v Nový záznam pro službu CDAS se jmenuje su-token-card. Hodnota tohoto záznamu je úplnou cestou ke knihovně CDAS, která byla rozšířena o podporu přepnutí uživatele. v Pro metody autentizace nezaložené na službě CDAS, uvedené v tomto příkladu, si pamatujte: – Metoda autentizace su-forms, která je dodávána s formulářem pro přepnutí uživatele, je namapována na parametr mechanismu autentizace su-password v konfiguračním souboru webseald.conf. – Dodávaná knihovna libsuauthn byla dále přejmenována pro oba mechanismy autentizace pomocí formulářů i certifikátů.


83

Konfigurace ukládání požadavku na straně serveru do paměti cache serveru WebSEAL Prostředí V předchozích verzích serveru WebSEAL se pomocí autentizace pomocí formulářů vytvořil záznam v paměti cache pro URL požadavku uživatele, jakmile byla vyžadována autentizace. Po provedení úspěšné autentizace server WebSEAL odeslal přesměrování HTTP na prohlížeč, který obsahoval uvedené URL. Prohlížeč pak sledoval přesměrování k umístění originálního zdroje. Omezení této implementace jsou zřejmá, jakmile například je požadavek POST přerušen časovým limitem relace, který vyvolá proces opětovné autentizace. Jelikož server WebSEAL ukládal do paměti cache pouze URL původního požadavku, data POST (včetně METHOD a těla zprávy) byla ztracena během přesměrování HTTP. Uživatel musel znovu vytvořit požadavek POST. Server WebSEAL nyní ukládá do paměti cache úplnější sadu dat požadavku a používá tato data uložená do paměti cache k tomu, aby znovu vytvořil požadavek během přesměrování HTTP v případě, že požadavek na opětovnou autentizaci přeruší dokončení zpracování požadavku. Toto řešení částečně těží z požadavků POST a PUT, protože tyto typy požadavků mohou obsahovat řadu informačních polí.

Proces ukládání do paměti cache na straně serveru Pokud požadavek na autentizaci přeruší požadavek, server WebSEAL uloží všechny informace nezbytné pro opětovné vytvoření požadavku během přesměrování HTTP, které následuje po požadavku na opětovnou autentizaci. Uložená data požadavku do paměti cache zahrnují URL, METHOD, tělo zprávy, řetězce dotazů a všechny HTTP hlavičky (včetně cookies). Tato data jsou dočasně uložena do paměti cache pro pověření/relace serveru WebSEAL. Po úspěšném dokončení autentizace (nebo opětovné autentizace) server WebSEAL odešle přesměrování HTTP na prohlížeč. Prohlížeč sleduje přesměrování na původní URL, které je součástí přesměrování. Server WebSEAL zachytí přesměrování a znovu vytvoří požadavek pomocí dat uložených v paměti cache. Znovu vytvořený požadavek je dodán do cíle URL. Níže uvedený diagram zobrazuje typický proces ukládání požadavku do paměti cache na straně serveru: 1. Uživatel se úspěšně přihlásí (pomocí autentizace pomocí formulářů) a podá HTTP požadavek na zdroj zahrnující formulář s CGI generovanými daty. Server WebSEAL vytvoří a uloží do paměti cache ID relace pro tohoto uživatele. 2. Aplikační server typu back-end vrátí uživateli formulář. 3. Během doby, kterou uživatel potřebuje k vyplnění formuláře, vyprší nakonfigurovaný časový limit relace pro tohoto uživatele. Server WebSEAL odstraní záznam v paměti cache o pověření uživatele a ID relace. 4. Uživatel zadá vyplněný formulář (POST). Server WebSEAL nenalezne žádný záznam pro uživatele v paměti cache, vytvoří novou cache a dočasně uloží do paměti cache úplné informace v požadavku POST. 5. Jelikož server WebSEAL nenalezl pro tohoto uživatele žádné pověření, uživatel se musí autentizovat. Server WebSEAL odešle uživateli formulář pro přihlášení. 6. Uživatel vrátí vyplněný formulář pro přihlášení serveru WebSEAL (POST). Autentizace je úspěšná. Paměť cache nyní obsahuje pověření uživatele, a současně i uložený požadavek.

84


7. Server WebSEAL odešle přesměrování HTTP zpět na prohlížeč, který obsahuje URL původně požadovaného zdroje. 8. Prohlížeč postupuje podle přesměrování (GET). Server WebSEAL zachytí přesměrování a znovu vytvoří původní požadavek (formulář), a to pomocí uložených POST dat. Obnovený požadavek (formulář) je dodán do cíle URL.

Obrázek 15. Příklad procesu ukládání požadavku do paměti cache serveru WebSEAL

Konfigurace parametrů pro ukládání do paměti cache na straně serveru Přestože se ukládání požadavku do paměti cache provádí pro autentizaci pomocí formulářů v serveru WebSEAL automaticky, můžete uvést omezení velikosti požadavků, které bude server WebSEAL ukládat do paměti cache. Parametry request-max-cache a request-body-max-read jsou ve stanze [server] konfiguračního souboru webseald.conf. request-max-cache Parametr request-max-cache uvádí maximální množství dat (v bajtech), které bude server WebSEAL pro každý požadavek ukládat. Minimální přijatelná hodnota je 512 bajtů. Pokud je parametr request-max-cache nastaven na nižší hodnotu, server WebSEAL bude používat předvolenou hodnotu 512 bajtů. Například: [server] request-max-cache = 8192

Jak je popsáno níže, musíte během zadávání parametru request-max-cache vzít v úvahu hodnotu parametru request-body-max-read. request-body-max-read Kapitola 3. Pokročilá konfigurace serveru

85

Parametr request-body-max-read uvádí maximální velikost těla zprávy požadavku (v bajtech), kterou bude server WebSEAL pro každý požadavek ukládat. Tento parametr konkrétně ovlivňuje typy požadavků, které obsahují data těla zprávy, jako např. požadavky POST a PUT. Například: [server] request-body-max-read = 4096

Tento parametr je možné nastavit na nulovou hodnotu. Tento parametr neomezuje maximální velikost POST (která je neomezená) požadavků, které nevyžadují autentizaci. Všimněte si, že hodnota parametru request-max-cache musí správně pojmout hodnotu request-body-max-read a navíc ještě velikost dalších komponent požadavku. Například pokud zadáte 2048 bajtů jako omezení paměti cache pro velikost těla zprávy požadavku a očekáváte, že maximální velikost všech dalších komponent požadavku (jako např. hlaviček a cookies) by měla být 4096 bajtů, pak: v nastavte request-body-max-read = 2048 v nastavte request-max-cache = 2048 + 4096 = 6144 Pokud bude během provádění požadavku překročena hodnota jednoho z parametrů request-body-max-read nebo request-max-cache, pak server WebSEAL přeruší proces ukládání požadavku do paměti cache a vrátí prohlížeči chybovou zprávu ″Ukládání požadavku do paměti cache selhalo″ a zapíše tuto chybu do souboru protokolu. Tuto chybovou zprávu si můžete přizpůsobit. Viz “Správa přizpůsobených HTTP stránek s chybovými zprávami” na stránce 31.

Poznámky a omezení v Hodnota request-body-max-read také ovlivňuje požadavky dynamického URL, protože část dotazu v požadavku POST je součástí těla zprávy požadavku. v Hodnota request-body-max-read dále ovlivňuje autentizaci pomocí formulářů, neboť uvádí omezení velikosti POST dat, která jsou zpracovávána během autentizace. v Parametry request-body-max-read a request-max-cache chrání server WebSEAL před takovými typy útoků na službu, které by nutily server WebSEAL ukládat do paměti cache víc dat, než je tento schopen obsloužit. v Ukládání požadavků do paměti cache na straně serveru nepracuje správně, pokud hodnota časového limitu relace uživatele skončí během procesu přihlášení. V takové situaci je záznam paměti cache ztracen. v Ukládání požadavku do paměti cache na straně serveru může způsobit omezení schopnosti prohlížeče manipulovat se zdrojem. Prohlížeč netuší, že server WebSEAL znovu vytváří přesměrování HTTP. Proto si funkce prohlížeče pro opětovné zavedení/obnovu a schopnost ukládání do paměti cache mohou navzájem překážet.

Práce se znaky zakódovanými pomocí UTF-8 V souladu se specifikacemi HTTP jsou prohlížeče omezeny na znakové sady, které je možné legálně používat v URL. Tento rozsah je nadefinován jako tisknutelné znaky v ASCII znakové sadě (mezi hexadecimálními kódy 0x20 a 0x7e). V URLs jsou často vyžadovány znaky mimo tisknutelnou ASCII znakovou sadu, a to především pro jiné než anglické jazyky a z jiných důvodů. Tyto znaky je možné zakódovat pomocí tisknutelných znaků, aby je bylo možné přenést a interpretovat. Existuje množství různých způsobů zakódování pro přenesení znaků mimo povolený rozsah. Navzdory specifikacím HTTP existuje mnoho komerčních webových serverů, které jednoduše tolerují a akceptují znaky mimo povolený rozsah. Server WebSEAL, který vystupuje jako webová proxy, musí být schopen obsloužit všechny tyto uvedené případy.

86


Nejčastěji používaná metoda (″de facto standardní″) pro kódování znaků je UTF-8. Mnoho dnešních komerčních webových serverů je možné nakonfigurovat tak, aby byly schopny přijímat kódování UTF-8. Parametr utf8-url-support-enabled ve stanze [server] konfiguračního souboru webseald.conf řídí, jak server WebSEAL bude interpretovat URLs, přijatá od prohlížeče. Parametr rozeznává tři nastavení: v yes Server WebSEAL rozeznává v řetězcích URL pouze kódování UTF-8 a dekóduje informaci do původní znakové sady (lokální kódové stránky). Jiné techniky kódování, jako např. dvoubajtová znaková sada (DBCS) a Unicode, nejsou přijímány. v no Server WebSEAL nerozeznává v řetězcích URL kódování UTF-8. Žádná informace kódovaná pomocí UTF-8 není správně interpretována. Jiné techniky kódování jsou akceptovány. v auto Server WebSEAL se pokusí rozlišit kódování UTF-8 a další způsoby kódování jazykových znaků (DBCS a Unicode). Server WebSEAL správně zpracuje všechna správně vytvořená kódování UTF-8. Pokud se nezdá, že bylo použito kódování UTF-8, pak je kódování zpracováno jako DBCS nebo Unicode. Pokud je parametr utf8-url-support-enabled nastaven na hodnotu ″yes″ (což je předvolba), pak server WebSEAL předpokládá, že URL může obsahovat znaky zakódované pomocí UTF-8. Tyto UTF-8 znaky budou potvrzeny a vzaty v úvahu při určování práv přístupu k danému URL. URL je normalizováno (tj. zakódované znaky jsou převedeny na své ekvivalenty v lokální kódové stránce) a kontrola ACL se provede až na tomto normalizovaném URL. Předvolené nastavení nepovoluje URLs se znaky DBCS nebo Unicode ve tvaru %uXXXX. Předvolené nastavení je doporučovanou konfigurací pro server WebSEAL. Některé stávající aplikace a webové servery nespolupracují správně se serverem WebSEAL, pokud je povolena podpora UTF-8, neboť tyto aplikace používají DBCS (jako např. Shift-JIS) ve svých URL, nebo jiný mechanismus kódování. Pokud je toto váš případ, musíte provést následující dvě úlohy: 1. Edittujte konfigurační soubor webseald.conf a nastavte nový parametr tak, jak je uvedeno níže: utf8-url-support-enabled = no

2. Ujistěte se, že všechny spojené servery NEAKCEPTUJÍ URL zakódované pomocí UTF-8. Z bezpečnostního hlediska je důležité, aby server WebSEAL interpretoval URL stejným způsobem jako spojené servery. Doporučovaná strategie nasazení je následující: 1. Pokud to není nezbytné pro účely obsahu, okamžitě zkontrolujte a nastavte přístupový seznam default-webseal na stávajících produkčních nasazeních, abyste NEPOVOLILI přístup pro čtení ″r″ neautentizovaným uživatelům. Tato akce omezí bezpečnostní rizika pouze na uživatele, kteří mají platný účet v doméně produktu Tivoli Access Manager. 2. Ujistěte se, že parametr utf8-url-support-enabled je nastaven na předvolenou hodnotu ″yes″. 3. Otestujte vaše aplikace. Pokud pracují správně, použijte toto nastavení. 4. Pokud některá z aplikací bude vracet chybu ″Špatný požadavek″, zkuste danou aplikaci s nastavením parametru utf8-url-support-enabled na hodnotu ″no″. Pokud toto nastavení bude fungovat, můžete nasadit celé prostředí s parametrem nastavením na Kapitola 3. Pokročilá konfigurace serveru

87

hodnotu ″no″. Měli byste se však ujistit, že žádný ze spojených webových serverů není nakonfigurován tak, že bude akceptovat URL zakódovaná pomocí UTF-8.

Předcházení zranitelnosti způsobené skriptováním napříč stranami Skriptování napříč stranami je technika, jejíž použití způsobí zranitelnost webového serveru, neboť vkládá zákeřný kód do URL webového požadavku. Server WebSEAL nabízí určitou zabudovanou ochranu pro tento typ zranitelnosti a dovoluje vám v budoucnosti zpřesnit ochranu tak, že nakonfigurujete filtrování řetězců URL. Poznámka: Termín ″skriptování napříč stranami (cross-site scripting)″, přestože je v oboru běžně používán, přesně nepopisuje problematiku týkající se vloženého zákeřného kódu.

Prostředí Skriptování napříč stranami je určitým druhem zranitelnosti webového serveru, která může nastat, pokud URL požadavku klienta obsahuje vložený zákeřný skript. Například (JavaScript): <script>zákeřný_kód

Jiné příznaky skriptování, pomocí kterých je možné vyvolat zranitelnost, zahrnují

WebSEAL: Průvodce administrátora

Recommend Documents