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 E, “Poznámky”, na stránce 359.
Kapitola 9. Správa politik chráněných objektů . . . . . . . . . . . . . . . . . . . 85 Správa politik chráněných objektů . . . Vytvořit politiku POP . . . . . . Vypsat politiky POP . . . . . . Vymazat politiku POP . . . . . Úprava politiky POP . . . . . . Aplikace atributů POP na chráněné objekty Připojit politiku POP k objektu . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
Obsah
. . . . . . .
86 86 88 88 89 90 90
v
Najít, kde je politika POP připojena . . . . . . . . . Odpojení politiky POP od chráněného objektu . . . . . . Konfigurace atributů politiky POP . . . . . . . . . . . Atribut Režim varování . . . . . . . . . . . . . Atribut Úroveň auditu . . . . . . . . . . . . . . Atribut Denní doba přístupu . . . . . . . . . . . . Politika POP autorizace založené na síti . . . . . . . . . Určení IP adres a rozsahů . . . . . . . . . . . . Zablokování autorizací založených na síti prostřednictvím adresy IP Algoritmus autorizace založené na síti . . . . . . . . . Omezení a poznámky k autorizaci založené na síti . . . . . Politika POP odolnosti autentizace (zvýšení) . . . . . . . . Konfigurace úrovní pro zvýšenou autentizaci . . . . . . . Použití politiky zvýšené autentizace . . . . . . . . . Rozlišení mezi zvýšenou a vícefaktorovou autentizací . . . . Úroveň zabezpečení politiky POP . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . .
90 91 91 91 92 92 93 93 94 94 95 95 95 96 96 97
Kapitola 10. Správa autorizačních pravidel . . . . . . . . . . . . . . . . . . . . 99 Přehled autorizačních pravidel . . . . . . . . . . . . Informace o rozhodnutí o přístupu . . . . . . . . . . . Zdroje pro načtení ADI . . . . . . . . . . . . . Nestálá a stálá data . . . . . . . . . . . . . . Jazyk autorizačních pravidel . . . . . . . . . . . . Model dokumentu XML pro ADI . . . . . . . . . . Informace o rozhodnutí o přístupu do XML . . . . . . . Definování prostoru jmen XML . . . . . . . . . . Program pro vyhodnocování autorizačních pravidel . . . . . Formát a omezení pravidel . . . . . . . . . . . . Příklady pravidel . . . . . . . . . . . . . . . Metody poskytování ADI programům pro vyhodnocování pravidel Kódy příčiny pro selhání pravidel . . . . . . . . . . Konfigurační soubor a inicializační atributy . . . . . . . . resource-manager-provided-adi . . . . . . . . . . dynamic-adi-entitlement-services . . . . . . . . . . input-adi-xml-prolog a xsl-stylesheet-prolog . . . . . . [xmladi-attribute-definitions] . . . . . . . . . . . Správa autorizačního pravidla . . . . . . . . . . . . Tvoření autorizačního pravidla . . . . . . . . . . . Výpis autorizačních pravidel . . . . . . . . . . . Vymazání autorizačního pravidla . . . . . . . . . . Úprava autorizačního pravidla . . . . . . . . . . . Připojení autorizačního pravidla k chráněnému objektu . . . Hledání objektu s připojeným autorizačním pravidlem . . . . Odpojení autorizačního pravidla . . . . . . . . . .
Kapitola 14. Vysoká dostupnost serveru politik . . . . . . . . . . . . . . . . . . 149 Integrita dat . . . . . . . . . . . . . Primární a replikované servery LDAP . . . . . Aktivní a pasivní servery politik . . . . . . . Správa vysoké dostupnosti . . . . . . . . . Ověření nastavení vysoké dostupnosti serverů politik Přehled souborů protokolů . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
149 149 149 150 150 151
Kapitola 15. Server politik s více klienty . . . . . . . . . . . . . . . . . . . . . 153 Kapitola 16. Delegovaná administrativa . . . . . . . . . . . . . . . . . . . . . 155 Přehled delegované administrativy . . . . . Administrativa delegovaných rolí . . . . . . Správa prostoru delegovaných objektů . . . . Členění prostoru objektů pro delegování správy. Předvolení administrátoři a skupiny . . . . Příklad: Delegování správy . . . . . . . Delegovaná správa skupin a uživatelů . . . . Vytvořit objekty typu zásobník pro skupiny . . Vytvořit skupiny . . . . . . . . . . Politiky ACL ovlivňující správu skupin . . . Politiky ACL ovlivňující správu uživatelů . . Bezpečnostní politika delegované administrativy .
Základní soubory směrování . . . . . . . . . Protokoly zpráv obslužnosti . . . . . . . . Výstupní syntaxe souboru směrování . . . . . . Společné adresáře souborů protokolu . . . . . . . Předvolené umístění Tivoli Common Directory . . . Soubor vlastností Tivoli Common Directory . . . . Předvolené umístění produktu Tivoli Access Manager . Prohlížeč protokolů XML . . . . . . . . . . Úlohy souborů protokolu a trasování . . . . . . . Změna umístění souborů protokolu zpráv . . . . Zprávy protokolu ve formátu protokolu XML . . . Aktivace zobrazování záznamů trasování . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
169 169 171 174 174 175 175 176 176 176 177 178
Kapitola 18. Výstup XML pro protokolování a protokoly monitorování . . . . . . . . 179 Pomocný formát DTD . . . Bloky dat a výstupní pole . . Kódy akcí pro příkazy správy . Výstup dat pro chyby autentizace
IBM Tivoli Access Manager: Base: Administrativní příručka
Úvod Kniha IBM Tivoli Access Manager Base: Administrativní příručka obsahuje vyčerpávající přehled procedur a referenčních informací, potřebných ke správě serverů a zdrojů produktu IBM Tivoli Access Manager (Tivoli Access Manager). Tato příručka vám také poskytuje hodnotné výchozí a koncepční informace o široké paletě funkcionalit produktu Tivoli Access Manager.
Pro koho je určena tato kniha Tato příručka je určena pro systémové administrátory, kteří jsou odpovědni za nasazení a administraci základního softwaru Tivoli Access Manager. Čtenáři této knihy by měli znát: v operační systémy na platformě Microsoft® Windows® a UNIX® v databázovou architekturu a koncepty v správu zabezpečení ochrany dat v protokoly Internetu, včetně HTTP a TCP/IP v LDAP (Lightweight Directory Access Protocol) a adresářové služby v autentizaci a autorizaci v model zabezpečení ochrany produktu Tivoli Access Manager a jeho schopnosti Také byste měli 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 Tato příručka obsahuje následující části: v Kapitola 1, “Přehled produktu IBM Tivoli Access Manager”, na stránce 1 Nabízí přehled produktu IBM Tivoli Access Manager. v Kapitola 2, “Web Portal Manager”, na stránce 21 Popisuje dva typy funkcí administrativy produktu Web Portal Manager. v Kapitola 3, “Administrativa produktu Tivoli Access Manager”, na stránce 31 Popisuje administrativu produktu Tivoli Access Manager. v Kapitola 4, “Předvolená bezpečnostní politika”, na stránce 41 Popisuje předvolenou bezpečnostní politiku nabízenou produktem Tivoli Access Manager. v Kapitola 5, “Správa domény”, na stránce 59
v v v v
Popisuje, jak administrátor v doméně správy může vytvořit další domény, a také které administrativní úlohy může administrátor domén provést ve své vlastní doméně. Kapitola 6, “Správa prostoru objektů”, na stránce 63 Popisuje úlohy přidružené ke správě prostorů objektů. Kapitola 7, “Správa chráněných objektů”, na stránce 67 Popisuje úlohy týkající se správy objektů. Kapitola 8, “Správa přístupových seznamů”, na stránce 71 Popisuje úlohy týkající se správy přístupových seznamů (ACL - Access Control List). Kapitola 9, “Správa politik chráněných objektů”, na stránce 85
Popisuje úlohy týkající se správy politik chráněných objektů (POP - Protected Object Policy). v Kapitola 10, “Správa autorizačních pravidel”, na stránce 99 Poskytuje detailní informace o autorizačních pravidlech (AuthzRules), která jsou použita pro provádění rozhodnutí o přístupu. v Kapitola 11, “Správa uživatelů a skupin”, na stránce 123 Popisuje úlohy týkající se správy uživatelů a skupin. v Kapitola 12, “Správa certifikátů a hesel”, na stránce 133 v v
v
v v
v
v v v
v
v
v
xii
Popisuje úlohy týkající se správy certifikátů a hesel. Kapitola 13, “Správa serverů”, na stránce 139 Popisuje úlohy týkající se správy serverů přidružených k produktu Tivoli Access Manager. Kapitola 14, “Vysoká dostupnost serveru politik”, na stránce 149 Popisuje úlohy vztahující se k vytváření prostředí s vysokou dostupností skrz použití proxy serverů politik, více serverů politik a více autorizačních serverů. Kapitola 15, “Server politik s více klienty”, na stránce 153 Popisuje servery s více klienty a jak nastavit server politik s více klienty produktu Tivoli Access Manager. Kapitola 16, “Delegovaná administrativa”, na stránce 155 Popisuje úlohy týkající se delegování administrativy. Kapitola 17, “Soubory protokolu a směrování”, na stránce 169 Popisuje úlohy vztahující se ke správě směrovaných souborů, běžného adresáře pro správu souborů protokolu, a jak rozumět a zobrazit výstup souboru protokolu XML (Extensible Markup Language) pro zprávy a trasování souborů protokolu. Kapitola 18, “Výstup XML pro protokolování a protokoly monitorování”, na stránce 179 Popisuje informace o středním formátu DTD, výstup XML ze souborů protokolu monitorování a příznaků XML použitých pro protokolování a monitorování události produktu Tivoli Access Manager. Kapitola 19, “Zachycení protokolovaných a monitorovaných událostí”, na stránce 197 Popisuje úlohu vztahující se k zachycení protokolovaných a monitorovaných událostí. Kapitola 20, “Protokolování přejatých monitorovaných událostí”, na stránce 221 Popisuje úlohy vztahující se ke spravování přejatého protokolování a monitorování. Dodatek A, “Referenční informace ke konfiguraci serveru”, na stránce 233 Poskytuje podrobné informace o syntaxi konfiguračních souborů používaných servery produktu Tivoli Access Manager. Dodatek B, “Rozdíly v registrech uživatelů”, na stránce 327 Popisuje rozdíly, které existují v aktuálních registrech uživatelů produktu Tivoli Access Manager: LDAP, Microsoft Active Directory a IBM Lotus Domino. Dodatek C, “Ekvivalenty Web Portal Manager a příkazového řádku administrativy”, na stránce 331 Mapuje funkce rozhraní příkazového řádku Tivoli Access Manager pdadmin do grafických funkcí rozhraní uživatele produktu Web Portal Manager Dodatek D, “Správa registrů uživatelů”, na stránce 341 Popisuje podmnožinu úloh registru uživatelů, které jsou specifické pro instalaci produktu Tivoli Access Manager.
IBM Tivoli Access Manager: Base: Administrativní příručka
Publikace Zobrazte si přehled popisů knihoven produktu Tivoli Access Manager, publikace předem požadovaných oprav a vztahující se publikace, abyste určili, které z nich by pro vás mohly být nápomocné. Poté, co určíte, které publikace potřebujete, následujte instrukce pro online přístup k publikacím. Další informace o samotném produktu IBM Tivoli Access Manager for e-business můžete nalézt: http://www.ibm.com/software/tivoli/products/access-mgr-e-bus/ Knihovna produktu Tivoli Access Manager je rozdělena do následujících kategorií: v “Informace o vydání” v “Základní informace” v “Informace o zabezpečení Webu” v “Reference pro vývojáře” na stránce xiv v “Technické dodatky” na stránce xv
Informace o vydání v IBM Tivoli Access Manager for e-business Čtěte jako první (GI11-2930-00) Obsahuje informace pro instalaci a začátek práce s produktem Tivoli Access Manager. v IBM Tivoli Access Manager for e-business Release Notes (GI11-4156-00) Poskytuje nejnovější informace např. o omezeních softwaru, pomocných opravách problémů, nebo o aktualizacích dokumentace.
Základní informace v IBM Tivoli Access Manager Base Installation Guide (SC32-1362-00) Vysvětluje, jak instalovat a konfigurovat základní software produktu Tivoli Access Manager včetně rozhraní produktu Web Portal Manager. Tato kniha je součástí publikace IBM Tivoli Access Manager for e-business Web Security Installation Guide a jejím záměrem je, aby byla používána s dalšími produkty Tivoli Access Manager, jako jsou IBM Tivoli Access Manager for Business Integration a IBM Tivoli Access Manager for Operating Systems. v IBM Tivoli Access Manager Base: Administrativní příručka (SC09-3708-00) Popisuje koncepty a procedury používání služeb produktu Tivoli Access Manager. Poskytuje instrukce pro provádění úloh z rozhraní Web Portal Manager a pro provádění úloh pomocí příkazu pdadmin.
Informace o zabezpečení Webu v IBM Tivoli Access Manager for e-business Web Security Installation Guide (SC32-1361-00) Poskytuje instrukce pro instalaci, konfiguraci a odstranění základního softwaru produktu Tivoli Access Manager stejně jako komponent Web Security. Tato kniha v sobě zahrnuje publikaci IBM Tivoli Access Manager Base Installation Guide. v IBM Tivoli Access Manager Upgrade Guide (SC32-1369-00) Vysvětluje jak povýšit z produktu Tivoli SecureWay Policy Director verze 3.8 nebo předchozích verzí produktu Tivoli Access Manager na produkt Tivoli Access Manager verze 5.1.
Úvod
xiii
v IBM Tivoli Access Manager for e-business WebSEAL: Administrativní příručka (SC09-3709-00) Poskytuje podkladové materiály, administrativní procedury a informace o technických odkazech, které používá produkt WebSEAL ke správě zdrojů ve vaší zabezpečené webové doméně. v IBM Tivoli Access Manager for e-business IBM WebSphere Application Server: Integrační příručka (SC09-3710-00) Poskytuje instrukce pro instalaci, odstranění a administrativu pro integraci produktu Tivoli Access Manager s IBM WebSphere® Application Server. v IBM Tivoli Access Manager for e-business IBM WebSphere Edge Server Integration Guide (SC32-1367-00) Poskytuje instrukce o instalaci, odstranění a administrativě pro integraci produktu Tivoli Access Manager s aplikací IBM WebSphere Edge Server. v IBM Tivoli Access Manager for e-business Plug-in for Web Servers: Integrační příručka (SC09-3712-00) Poskytuje instrukce pro instalaci, administrativní procedury a informace o technických odkazech, týkající se zabezpečení vaší webové domény pomocí plug-in pro webové servery. v IBM Tivoli Access Manager for e-business BEA WebLogic Server: Integrační příručka (SC09-3711-00) Poskytuje instrukce pro instalaci, odstranění a administrativu pro integraci produktu Tivoli Access Manager s BEA WebLogic Server. v IBM Tivoli Access Manager for e-business IBM Tivoli Identity Manager: Příručka k funkci zajištění rychlého spuštění (SC09-3713-00) Poskytuje přehled úloh vztahujících se k integraci produktu Tivoli Access Manager a Tivoli Identity Manager a vysvětluje, jak používat a instalovat kolekci Fast Start.
Reference pro vývojáře v IBM Tivoli Access Manager for e-business Authorization C API Developer Reference (SC32-1355-00) Poskytuje referenční materiály, které popisují, jak používat autorizační C API produktu Tivoli Access Manager a rozhraní plug-inů služeb Tivoli Access Manager, aby bylo možné přidat zabezpečení produktu Tivoli Access Manager do aplikací. v IBM Tivoli Access Manager for e-business Authorization Java Classes Developer Reference (SC32-1350-00) Poskytuje referenční informace, jak pomocí implementace autorizačního rozhraní API v jazyce Java™ povolit, aby aplikace používala zabezpečení produktu Tivoli Access Manager. v IBM Tivoli Access Manager for e-business Administration C API Developer Reference (SC32-1357-00) Poskytuje referenční informace, jak pomocí administrativního rozhraní API povolit, aby aplikace prováděla administrativní úlohy produktu Tivoli Access Manager. Tento dokument popisuje implementaci tohoto administrativního rozhraní API v jazyce C. v IBM Tivoli Access Manager for e-business Administration Java Classes Developer Reference (SC32-1356-00) Poskytuje referenční informace, jak pomocí implementace administrativního rozhraní API v jazyce Java povolit, aby aplikace prováděla administrativní úlohy produktu Tivoli Access Manager. v IBM Tivoli Access Manager for e-business Web Security Developer Reference (SC32-1358-00)
xiv
IBM Tivoli Access Manager: Base: Administrativní příručka
Poskytuje informace o administrativě a programování pro autentizační služby napříč doménami (CDAS), základní strukturu mapování napříč doménami (CDMF) a modul odolnosti hesla.
Technické dodatky v IBM Tivoli Access Manager for e-business Command Reference (SC32-1354-00) Poskytuje informace o obslužných programech příkazového řádku a skriptech, které jsou součástí produktu Tivoli Access Manager. v IBM Tivoli Access Manager Error Message Reference (SC32-1353-00) Obsahuje vysvětlení a doporučované akce pro zprávy, které vydává produkt Tivoli Access Manager. v IBM Tivoli Access Manager for e-business Problem Determination Guide (SC32-1352-00) Obsahuje informace napomáhající určení problému pro produkt Tivoli Access Manager. v IBM Tivoli Access Manager for e-business Performance Tuning Guide (SC32-1351-00) Poskytuje informace o ladění výkonu pro prostředí skládající se z produktu Tivoli Access Manager se serverem IBM Tivoli Directory jako registrem uživatelů.
Související publikace Tato část obsahuje seznam publikací, souvisejících s knihovnou produktu Tivoli Access Manager. Tivoli Software Library obsahuje celou řadu publikací týkajících se produktů Tivoli, jako např. dokumenty typu white paper, základní informace o produktech, demonstrační materiály, tzv. redbooks a informace o ohlášení. Tivoli Software Library je k dispozici na této webové adrese: http://www.ibm.com/software/tivoli/library/ Obsahem Tivoli Software Glossary jsou definice mnoha technických termínů, vztahujících se k softwaru Tivoli. Tivoli Software Glossary je k dispozici pouze v anglickém jazyce na odkazu Glossary v levé části webové stránky Tivoli Software Library http://www.ibm.com/software/tivoli/library/
IBM Global Security Kit Produkt Tivoli Access Manager poskytuje šifrování dat skrz použití IBM Global Security Kit (GSKit) verze 7.0. GSKit je součástí CD IBM Tivoli Access Manager Base pro vaši danou platformu, stejně jako CD IBM Tivoli Access Manager Web Security, CD IBM Tivoli Access Manager Web Administration Interfaces a CDIBM Tivoli Access Manager Directory Server. Sada programů GSKit poskytuje obslužný program správy klíčů iKeyman, gsk7ikm, který je použitý pro vytvoření databází klíčů, veřejných-soukromých párů klíčů a požadavků o certifikát. Následující dokument je k dispozici na webovém serveru Tivoli Information Center, a to ve stejné části jako dokumentace produktu IBM Tivoli Access Manager: v IBM Global Security Kit Secure Sockets Layer and iKeyman User’s Guide (SC32-1363-00) Obsahuje informace pro síťové nebo systémové administrátory, kteří chtějí aktivovat SSL komunikaci v prostředí produktu Tivoli Access Manager.
IBM Tivoli Directory Server IBM Tivoli Directory Server, verze 5.2 je součástí CD IBM Tivoli Access Manager Directory Server pro požadovaný operační systém. Poznámka: IBM Tivoli Directory Server je nové jméno pro předešlý software vydaný pod jmény: v IBM Directory Server (verze 4.1 a verze 5.1) Úvod
xv
v IBM SecureWay Directory Server (Verison 3.2.2) IBM Directory Server verze 4.1, IBM Directory Server verze 5.1, a IBM Tivoli Directory Server verze 5.2 jsou všechny podporované produktem IBM Tivoli Access Manager verze 5.1. Další informace o IBM Tivoli Directory Server můžete nalézt na: http://www.ibm.com/software/network/directory/library/
IBM DB2 Universal Database IBM DB2® Universal Database™ Enterprise Server Edition, verze 8.1 je poskytovaná na CDIBM Tivoli Access Manager Directory Server a je instalovaná se softwarem IBM Tivoli Directory Server. DB2 je požadovaná, když používáte servery IBM Tivoli Directory Server, z/OS™ nebo OS/390® LDAP jako registry uživatelů pro produkt Tivoli Access Manager. Všimněte si, že servery z/OS a OS/390 nejsou poskytované produktem IBM Tivoli Access Manager verze 5.1. Další informace o DB2 lze nalézt na: http://www.ibm.com/software/data/db2/
IBM WebSphere Application Server IBM WebSphere Application Server, Advanced Single Server Edition 5.0 je součástí CD IBM Tivoli Access Manager Web Administration Interfaces pro požadovaný operační systém. WebSphere Application Server umožňuje podporu pro obojí, rozhraní Web Portal Manager, které je použité pro administrativu produktu Tivoli Access Manager, a IBM Directory Server Web Administration Tool Web Administration Tool, který je použitý pro administrativu serveru IBM Tivoli Directory Server. IBM WebSphere Application Server Fix Pack 2 je také požadovaný produktem Tivoli Access Manager a je poskytovaný na CD IBM Tivoli Access Manager WebSphere Fix Pack. Další informace o IBM WebSphere Application Server lze nalézt na: http://www.ibm.com/software/webservers/appserv/infocenter.html
IBM Tivoli Access Manager for Business Integration IBM Tivoli Access Manager for Business Integration, který je možné si objednat jako zvláštní produkt, poskytuje bezpečnostní řešení pro zprávy IBM MQSeries®, Version 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. Jako WebSEAL a IBM Tivoli Access Manager for Operating Systems, IBM Tivoli Access Manager for Business Integration je jeden ze správců zdrojů, který používá služby produktu IBM Tivoli Access Manager. Další informace o produktu IBM Tivoli Access Manager for Business Integration lze nalézt na: http://www.ibm.com/software/tivoli/products/access-mgr-bus-integration/ Následující dokumenty vztahující se k produktu IBM Tivoli Access Manager for Business Integration verze 5.1 jsou dostupné na webovém serveru Tivoli Information Center: v IBM Tivoli Access Manager for Business Integration Administration Guide (SC23-4831-01)
xvi
IBM Tivoli Access Manager: Base: Administrativní příručka
v IBM Tivoli Access Manager for Business Integration Problem Determination Guide (GC23-1328-00) v IBM Tivoli Access Manager for Business Integration Release Notes (GI11-0957-01) v IBM Tivoli Access Manager for Business Integration Read This First (GI11-4202-00)
IBM Tivoli Access Manager for WebSphere Business Integration Brokers Produkt IBM Tivoli Access Manager for WebSphere Business Integration Brokers dostupný jako součást IBM Tivoli Access Manager for Business Integration poskytuje zabezpečovací řešení pro WebSphere Business Integration Message Broker, verze 5.0 a WebSphere Business Integration Event Broker, verze 5.0. Produkt IBM Tivoli Access Manager for WebSphere Business Integration Brokers funguje ve spojení s produktem Tivoli Access Manager jako zabezpečení aplikací publikování/podpisů JMS tím, že poskytuje heslo a autentizaci založenou na pověřeních, centrálně definovanou autorizaci a služby monitorování. Další informace o produktu IBM Tivoli Access Manager for WebSphere Integration Brokers lze nalézt na: http://www.ibm.com/software/tivoli/products/access-mgr-bus-integration/ Následující dokumenty vztahující se k produktu IBM Tivoli Access Manager for WebSphere Integration Brokers, verze 5.1 jsou dostupné na webovém serveru Tivoli Information Center: v IBM Tivoli Access Manager for WebSphere Business Integration Brokers Administration Guide (SC32-1347-00) v IBM Tivoli Access Manager for WebSphere Business Integration Brokers Release Notes (GI11-4154-00) v IBM Tivoli Access Manager for Business Integration Read This First (GI11-4202-00)
IBM Tivoli Access Manager for Operating Systems Produkt IBM Tivoli Access Manager for Operating Systems je k dispozici jako samostatně objednatelný produkt. Pro UNIXové systémy nabízí další úroveň pro vymáhání politiky autorizace k původní úrovni vlastního operačního systému. Produkt IBM Tivoli Access Manager for Operating Systems, stejně jako WebSEAL a produkt IBM Tivoli Access Manager for Business Integration, je jeden ze správců zdrojů, kteří používají služby produktu IBM Tivoli Access Manager. Další informace o produktu IBM Tivoli Access Manager for Operating Systems lze nalézt na: http://www.ibm.com/software/tivoli/products/access-mgr-operating-sys/ Následující dokumenty vztahující se k produktu IBM Tivoli Access Manager for Operating Systems verze 5.1 jsou dostupné na webovém serveru Tivoli Information Center: v IBM Tivoli Access Manager for Operating Systems Installation Guide (SC23-4829-00) v IBM Tivoli Access Manager for Operating Systems Administration Guide (SC23-4827-00) v IBM Tivoli Access Manager for Operating Systems Problem Determination Guide (SC23-4828-00) v IBM Tivoli Access Manager for Operating Systems Release Notes (GI11-0951-00) v IBM Tivoli Access Manager for Operating Systems Read Me First (GI11-0949-00)
IBM Tivoli Identity Manager IBM Tivoli Identity Manager verze 4.5, který si lze objednat jako zvláštní produkt, vám umožňuje centrálně spravovat uživatele (jako jsou ID a hesla uživatelů) a zajišťovat jej (tj. poskytovat nebo odvolávat přístup do aplikací, zdrojů nebo operačních systémů). Tivoli Identity Manager lze integrovat s produktem Tivoli Access Manager skrze použití Úvod
xvii
produktuTivoli Access Manager Agent. Kontaktujte svého představitele účet IBM, chcete-li získat více informací o nákupu produktu Agent. Další informace o IBM Tivoli Identity Manager lze nalézt na: http://www.ibm.com/software/tivoli/products/identity-mgr/
Online přístup k publikacím Publikace pro tento produkt jsou dostupné pouze online ve formátu PDF (Portable Document Format) nebo HTML (Hypertext Markup Language) nebo obojí v softwarové knihovně Tivoli: http://www.ibm.com/software/tivoli/library Abyste zjistili umístění publikací v knihovně, klepněte na odkaz Product manuals (Manuály produktu) na levé straně stránky knihovny. Potom zjistěte umístění a klepněte na jméno produktu na stránce softwarového informačního centra Tivoli. Publikace produktu obsahují poznámky k jednotlivým vydáním, průvodce instalací, průvodce uživatele, průvodce administrátora a reference pro vývojáře. Poznámka: Pokud chcete vytisknout PDF publikace, zaškrtněte pole Fit to page v dialogu Print produktu Adobe Acrobat (ke kterému se dostanete, pokud klepnete na File → Print).
Dostupnost Funkce dostupnosti pomáhají uživateli 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ž s problémem kontaktujete IBM Tivoli Software Support, vyhledejte odkaz serveru IBM Tivoli Software Support klepnutím na odkaz Tivoli support (Podpora Tivoli) na následujícím webovém serveru: http://www.ibm.com/software/support/ Pokud budete potřebovat další pomoc, obraťte se na softwarovou podporu způsobem, který je popsán v příručce IBM Software Support Guide na této webové adrese: http://techsupport.services.ibm.com/guides/handbook.html Průvodce poskytuje následující informace: v požadavky na registraci a způsobilost pro obdržení podpory v Telefonní čísla v závislosti na zemích, ve kterých se nacházíte 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:
xviii
IBM Tivoli Access Manager: Base: Administrativní příručka
tučné písmo Příkazy uvedené malými písmeny nebo smíšeně malými i velkými písmeny, které je těžké odlišit od okolního textu, klíčová slova, parametry, volby a jména tříd Javy a objekty jsou uvedeny tučným písmem. kurzíva Proměnné, názvy publikací a speciální slova nebo fráze, které je nutné zdůraznit, jsou vyznačeny kurzívou. monospace Příklady kódů, příkazové řádky, výstupy na obrazovku, jména souborů a adresářů, která je těžké odlišit od okolního textu, systémové zprávy, text, který musí uživatel správně zadat, a hodnoty argumentů nebo voleb příkazů jsou vyznačeny pomocí monospace.
Rozdíly v operačních systémech Tato kniha používá konvence operačního systému UNIX ve specifikacích proměnných prostředí a v zápisu adresářů. Když používáte příkazová řádek Windows, nahraďte $proměnnou s%proměnnou%, pro proměnné prostředí nahraďte v cestách adresářů každé lomítko po směru (/) zpětným lomítkem (\). Pokud používáte nadstavbu bash v operačním systému Windows, můžete používat konvence operačního systému UNIX.
Úvod
xix
xx
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 1. Přehled produktu IBM Tivoli Access Manager Produkt IBM Tivoli Access Manager (Tivoli Access Manager) je řešení autentizace a autorizace pro firemní webové aplikace, aplikace typu klient/server a stávající aplikace. Produkt Tivoli Access Manager vám umožňuje řídit přístup uživatelů ke chráněným informacím a zdrojům. Vytvoření centralizovaného, flexibilního a přizpůsobitelného řešení pro řízení přístupu pomocí produktu Tivoli Access Manager vám dovolí vybudovat zabezpečené a snadno spravovatelné aplikace založené na síti a infrastrukturu pro elektronické podnikání. Produkt Tivoli Access Manager podporuje autentizaci, autorizaci, zabezpečení dat a 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 a extranety. Produkt Tivoli Access Manager nabízí: základní strukturu autentizace Tivoli Access Manager nabízí řadu zabudovaných autentizátorů a podporuje externí autentizátory. základní strukturu autorizace Autorizační služba produktu Tivoli Access Manager, ke které je možné přistupovat prostřednictvím standardního autorizačního rozhraní aplikačních programů (autorizačního rozhraní API), nabízí pro žádosti o přístup vlastních serverů produktu Tivoli Access Manager a aplikací třetích stran rozhodnutí povolit nebo odepřít. Autorizační služba společně se správcem zdrojů poskytuje standardní mechanismus autorizace pro systémy obchodních sítí. Produkt Tivoli Access Manager se integruje do stávajících přejatých a vyvíjejících se infrastruktur a poskytuje schopnost zabezpečené a centralizované správy politik. Někteří stávající správci zdrojů jsou: IBM Tivoli Access Manager WebSEAL Spravuje a chrání informace a zdroje založené na Webu. WebSEAL je součástí produktu Tivoli Access Manager. IBM Tivoli Access Manager for Business Integration Poskytuje řešení zabezpečení produktu IBM MQSeries a zpráv IBM WebSphere MQ. IBM Tivoli Access Manager for Operating Systems Poskytuje další úroveň pro vymáhání politiky autorizace k původní úrovni vlastního operačního systému pro operační systémy UNIX. Stávající aplikace mohou využívat výhod autorizační služby produktu Tivoli Access Manager, jakož i mohou poskytovat společnou bezpečnostní politiku pro celou firmu.
Klíčové technologie Řešení produktu Tivoli Access Manager pro správu zabezpečení sítě nabízí a podporuje následující klíčové technologie: v autentizace v autorizace v úroveň zabezpečení v škálovatelnost v prokazatelnost přístupu v centralizovaná správa
Autentizace Autentizace je prvním krokem, který musí uživatel provést, když vydává požadavek na zdroj v síti, který je chráněn produktem Tivoli Access Manager. Během autentizace se potvrzuje totožnost uživatele. Proces autentizace je obvykle závislý na specifických požadavcích aplikace poskytující dané služby. Produkt Tivoli Access Manager umožňuje velmi pružný přístup k autentizaci, a to díky použití autorizačního rozhraní API. Produkt Tivoli Access Manager poskytuje zabudovanou podporu pro autentizaci pomocí jména uživatele a hesla, a to prostřednictvím autorizačního rozhraní API. Aplikace mohou vybudovat libovolný uživatelský mechanismus autentizace, který bude používat autorizační rozhraní API.
Autorizace Autorizace vynucuje uplatňování bezpečnostní politiky tak, že určí, ke kterým objektům může uživatel přistupovat a které akce s těmito objekty může uživatel provádět, a pak uživateli zaručí odpovídající přístup. Produkt Tivoli Access Manager obsluhuje proces autorizace pomocí následujících komponent: v autorizační služba produktu Tivoli Access Manager, v přístupové seznamy (ACL), politiky chráněných objektů (POP) a autorizační pravidla pro jemnozrnnou kontrolu přístupu, v autorizační API založená na standardech, používající aznAPI pro aplikace jazyka C a JAAS (Java Authentication and Authorization Service) pro aplikace jazyka Java, v schopnost použití externí autorizační služby
Úroveň zabezpečení Úroveň zabezpečení určuje míru, po kterou produkt Tivoli Access Manager chrání všechny informace přenášené mezi klientem a serverem. Úroveň zabezpečení dat je určena kombinovaným účinkem šifrovacích standardů a algoritmů pro detekci modifikací. Správce zdrojů je odpovědný za zajištění, že bude vynucena požadovaná úroveň zabezpečení dat. Úrovně zabezpečení zahrnují: v standardní komunikaci TCP (Transmission Control Protocol) - žádná ochrana v integritu dat – zabezpečuje zprávy (toky dat), aby nebyly modifikovány během komunikace po síti v utajení dat – zabezpečuje zprávy, aby nebyly modifikovány nebo prohlíženy během komunikace po síti Produkt Tivoli Access Manager podporuje integritu a utajení dat, které jsou zajišťovány prostřednictvím komunikačního protokolu SSL (Secure Sockets Layer). Podporované šifrovací algoritmy jsou následující:
2
IBM Tivoli Access Manager: Base: Administrativní příručka
v v v v v v v
40bitové RC2 128bitové RC2 40bitové RC4 128bitové RC4 40-Data Encryption Standard (DES) 56bitové DES 168bitové triple DES
Škálovatelnost Škálovatelnost je schopnost odpovídat na zvyšující se počet uživatelů, kteří přistupují ke zdrojům v doméně. Produkt Tivoli Access Manager pro zajištění škálovatelnosti používá následující techniky: v replikaci služeb – autentizační služby – autorizační služby – bezpečnostní politiky – služby pro šifrování dat – monitorovací služby v předřazené replikované servery – zrcadlené zdroje pro zajištění vysoké dostupnosti – vyvažování zatížení způsobeného požadavky klientů v replikované servery typu back-end – servery typu back-end mohou být Tivoli Access Manager WebSEAL, Tivoli Access Manager for Operating Systems, Tivoli Access Manager for Business Integration nebo jiné servery aplikací – zrcadlené zdroje (jednotný prostor objektů) pro zajištění vysoké dostupnosti – další obsah a zdroje – vyvažování zatížení způsobeného příchozími požadavky v optimalizovaná výkonnost, které je dosaženo zamezením provádění autentizačních a autorizačních služeb na samostatných serverech v postupné nasazování služeb bez zvyšování režie pro správu
Prokazatelnost přístupu Produkt Tivoli Access Manager poskytuje řadu schopností pro protokolování a monitorování. Soubory protokolu zachycují veškeré chybové a varovné zprávy generované servery produktu Tivoli Access Manager. Monitorovací soubory monitorují aktivitu serveru produktu Tivoli Access Manager.
Centralizovaná správa Při správě bezpečnostní politiky a při správě serverů produktu Tivoli Access Manager se používají tři metody: v obslužný program pdadmin s rozhraním příkazového řádku v grafické uživatelské rozhraní (GUI) Web Portal Manager v administrativní rozhraní API Většinu úloh můžete provádět pomocí libovolné z uvedených metod. Některé úlohy ale není možné provádět pomocí rozhraní Web Portal Manager.
Kapitola 1. Přehled produktu IBM Tivoli Access Manager
3
Obslužný program pdadmin s rozhraním příkazového řádku Obslužný program pdadmin s rozhraním příkazového řádku se používá k administrativě produktu Tivoli Access Manager. Tento obslužný program nabízí rozhraní příkazového řádku, pomocí kterého je možné spravovat uživatele, skupiny, role, oprávnění, politiky, domény a servery, jakož i provádět další úlohy. Příkaz je možné používat ve skriptech nebo dávkových souborech a tak automatizovat zpracování. Obslužný program pdadmin s rozhraním příkazového řádku se nainstaluje jako součást sady programů Tivoli Access Manager Runtime. Informace specifické pro určitou úlohu najdete v kapitolách této knihy pojednávajících o těchto úlohách. Podrobné informace o syntaxi vlastního příkazu pdadmin najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Web Portal Manager Rozhraní Web Portal Manager je volitelné grafické uživatelské rozhraní (GUI) založené na webových technologiích, které se používá k administrativě produktu Tivoli Access Manager. Rozhraní Web Portal Manager nabízí grafické rozhraní, pomocí kterého je možné spravovat uživatele, skupiny, role, oprávnění, politiky, domény a servery, jakož i provádět další úlohy. Rozhraní Web Portal Manager je k dispozici pouze na operačních systémech AIX, Solaris a Microsoft Windows. Toto volitelné grafické uživatelské rozhraní se musí samostatně nainstalovat pomocí CD-ROM s názvem Tivoli Access Manager Web Portal Manager CD pro vaši určitou platformu. Klíčovou výhodou používání rozhraní Web Portal Manager je, že uvedené úlohy můžete provádět vzdáleně pomocí libovolného podporovaného webového prohlížeče — bez jakékoliv speciální konfigurace sítě. Informace specifické pro určitou úlohu najdete v kapitolách této knihy pojednávajících o těchto úlohách. Podrobnější informace o používání rozhraní Web Portal Manager najdete v online nápovědě rozhraní Web Portal Manager.
Administrativní rozhraní API Administrativní rozhraní API je komponentou produktu Tivoli Access Manager, která poskytuje sadu programovatelných rozhraní, které vám umožňují napsat aplikace pro správu uživatelů, skupin, pravidel, oprávnění, politik, domén a serverů. K dispozici je verze v programovacím jazyce C a v programovacím jazyce Java. Podrobné informace o administrativním rozhraní API najdete v knize IBM Tivoli Access Manager for e-business Administration C API Developer Reference a IBM Tivoli Access Manager for e-business Administration Java Classes Developer Reference.
Přehled bezpečnostní politiky Cílem každé bezpečnostní politiky je adekvátně chránit obchodní aktiva a zdroje s minimálním množstvím vynaložené administrativy. Nejprve musíte nadefinovat, které zdroje musí být chráněny. Tyto zdroje mohou mít libovolný typ datového objektu, jako např. soubory, adresáře, síťové servery, zprávy, databáze nebo webové stránky. Pak musíte rozhodnout, kteří uživatelé a skupiny uživatelů mohou přistupovat k těmto chráněným zdrojům. Musíte také rozhodnout, jaký typ přístupu k těmto zdrojům by měl být povolen. Nakonec musíte aplikovat na tyto zdroje odpovídající bezpečnostní politiku, abyste zajistili, že pouze správní uživatelé k nim budou moci přistupovat. Vymáhání bezpečnostní politiky je prací správce zdrojů. Správce zdrojů volá autorizační službu produktu Tivoli Access Manager a předává jí pověření uživatele provádějícího požadavek, požadovaným typem přístupu a objekt, ke kterému je přistupováno. Pověření poskytuje detailní informace získané během autentizace, které popisují uživatele, libovolné
4
IBM Tivoli Access Manager: Base: Administrativní příručka
sdružování skupin a další atributy identity vztahující se k zabezpečení. Pověření je možné používat k provozování velkého množství služeb, jako např. autorizace, monitorování a delegace. Autorizační služba, známá také jako prostředek autorizace, používá bezpečnostní politiku k určení, zda je možné požadavek povolit, zamítnout nebo podmínečně povolit a čekat na vyřízení dalšího ověření správcem zdrojů. Správce zdrojů použije doporučení autorizační služby, provede případné další ověřovací akce a nakonec buď zamítne požadavek, nebo povolí zpracování požadavku. Předpokládejme například, že Tomáš chce přistoupit k určité webové stránce, která je umístěna na webovém serveru chráněném produktem IBM Tivoli Access Manager WebSEAL. WebSEAL je správce zdrojů, který je odpovědný za správu a ochranu informací a zdrojů založených na webu a který musí rozhodnout, zda Tomáš k této stránce může nebo nemůže přistoupit. Správce zdrojů obdrží pověření Tomáše a pak se zeptá autorizační služby, zda má Tomáš oprávnění pro čtení této webové stránky. Autorizační služba zkontroluje bezpečnostní politiku a určí, že Tomášovi by přístup mohl být povolen a tak doporučí správci zdrojů, že požadavek o přístup může být udělen. Správce zdrojů pak přesměruje požadavek Tomáše na odpovídající webový server typu back-end, který poskytuje požadovanou webovou stránku. Bezpečnostní politika v produktu Tivoli Access Manager je definovaná skrz použití ACL, POP a autorizačních pravidel.
Standard autorizačního rozhraní API Autorizační služby jsou rozhodující částí architektury zabezpečení aplikací. Jakmile uživatel projde procesem autentizace, autorizační služby podniknou kroky, aby vynutily provedení obchodní politiky, tak, že určí, ke kterým službám a ke kterým informacím může uživatel přistupovat. Například uživatel, který přistoupil k důchodovému fondu založenému na webových technologiích, by měl být schopen prohlédnout si informace o osobním účtu, jakmile autorizační server ověří totožnost, pověření a atributy oprávnění tohoto uživatele. Autorizační rozhraní API založené na standardech (aznAPI) umožňuje aplikacím, aby volaly centralizovanou autorizační službu, takže není nezbytné, aby vývojáři psali autorizační kód pro každou novou aplikaci. Autorizační rozhraní API dovoluje standardizovat všechny aplikace do ověřené základní struktury autorizace. S pomocí autorizačního rozhraní API je možné poskytnout větší možnost řízení přístupu ke zdrojům v obchodních sítích.
Autorizace: koncepční model Pokud servery vyžadují zajištění zabezpečení ochrany dat v doméně, pak každý klient musí poskytnout důkaz o své totožnosti. Bezpečnostní politika 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 zdroji v doméně je řízen serverem, pak požadavky serveru 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 doméně. Autentizace zajišťuje, že jedinec je tím, za koho se prohlašuje, ale neříká nic o jeho schopnosti a možnosti provádět operace s chráněným zdrojem.
Kapitola 1. Přehled produktu IBM Tivoli Access Manager
5
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 autentizovat svou totožnost buď pomocí veřejného/soukromého klíče, pomocí tajného klíče, nebo způsobem definovaným 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. Zdroje v 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 domény. Tato politika dále nadefinuje stupeň zabezpečení, která obklopuje každý zdroj vyžadující zabezpečení. Obrázek 1 představuje základní komponenty procesu autorizace, které zahrnují: v Správce zdrojů je odpovědný za implementaci požadovaných operací, je-li udělena autorizace. Komponentou správce zdrojů je vymahač politiky, který směruje požadavky na autorizační službu, aby je tato zpracovala. v Autorizační služba provádí akce rozhodování pro každý požadavek.
Obrázek 1. Obecný model autorizace
Tradiční aplikace balí vymahač politiky a správce zdrojů do jednoho procesu. Příkladem podobné struktury je např. Tivoli Access Manager WebSEAL, Tivoli Access Manager for Operating Systems a Tivoli Access Manager for Business Integration. Nezávislá funkcionalita těchto komponent autorizace dovoluje větší flexibilitu v návrhu strategie vymáhání zabezpečení ochrany dat. Taková nezávislost například dovoluje administrátorovi systému řídit: v kde budou umístěny procesy v kdo napíše kód pro dané procesy v jak budou procesy provádět jejich úlohy
6
IBM Tivoli Access Manager: Base: Administrativní příručka
Prospěchy ze standardní autorizační služby Autorizace ve většině systémů, jak přejatých, tak i nových, je těsně svázána s jednotlivými aplikacemi. Společnosti obvykle vytvoří v průběhu času aplikace, které slouží jejich obchodním potřebám. Mnohé z těchto aplikací vyžadují nějaké specifické formy autorizace. Výsledkem je často široká paleta aplikací s různými implementacemi autorizace. Tyto soukromé implementace autorizace vyžadují oddělenou administrativu, je náročné je zaintegrovat a výsledkem jsou vysoké náklady na vlastnictví. Distribuovaná autorizační služba může nabídnout těmto nezávislým aplikacím standardní mechanismus rozhodnutí o autorizaci. Výhody takové standardní autorizační služby zahrnují: v snížení nákladů na vývoj a správu přístupu k aplikacím v snížení nákladů na vlastnictví a správu samostatných autorizačních systémů v vliv stávající bezpečnostní infrastruktury v umožnění, aby se nové obchody otevíraly bezpečněji v umožnění novějších a rozdílných typů aplikací v umožnění kratších vývojových cyklů v bezpečnější sdílení informací
Přehled autorizační služby produktu Tivoli Access Manager Produkt Tivoli Access Manager se integruje do stávajících přejatých a vyvíjejících se infrastruktur a poskytuje schopnost zabezpečené a centralizované správy politik. Autorizační služba Tivoli Access Manager společně se správci zdrojů poskytuje standardní autorizační mechanismus pro systémy obchodních sítí, jak uvádí Obrázek 2:
Obrázek 2. Serverové komponenty produktu Tivoli Access Manager
Stávající aplikace mohou využívat výhod autorizační služby. Autorizační politika je založena na rolích uživatele a skupiny, které je možné aplikovat na síťové servery, jednotlivé transakce nebo databázové požadavky, určité informace založené na webu, aktivity týkající se správy a uživatelsky definované objekty. Autorizační rozhraní API umožňuje stávajícím aplikacím provádět volání autorizační služby, která následně provádí rozhodování založené na firemní bezpečnostní politice. Bližší informace o autorizačním rozhraní API najdete v části “Autorizační API Tivoli Access Manager” na stránce 12. Kapitola 1. Přehled produktu IBM Tivoli Access Manager
7
Autorizační služba produktu Tivoli Access Manager je také rozšiřitelná a je možné ji nakonfigurovat tak, aby volala další autorizační služby, je-li nutné další zpracování pomocí plug-in rozhraní externí autorizační služby. Autorizační služba nabízí následující výhody: v služba je nezávislá na aplikaci v služba používá standardní styl autorizačního kódu, který je nezávislý na jazyku (autorizační rozhraní API) v služba je centrálně spravována a proto je snadno administrovatelná — například přidání nového zaměstnance vyžaduje změnu databáze oprávnění na jednom centrálním místě, namísto změny na více systémech v služba určuje použití bezpečnostních služeb v heterogenních prostředích s více platformami v služba se integruje do stávajících autorizačních systémů, nezávislých na produktu Tivoli Access Manager, prostřednictvím schopnosti externí autorizační služby v služba má škálovatelnou a flexibilní architekturu, kterou je možné snadno zaintegrovat do stávající infrastruktury v služba umožňuje vícestupňovou autorizaci — paket s pověřeními může procházet více úrovněmi aplikačního procesu nebo transakce v služba používá běžný a efektivní model pro monitorování v služba je nezávislá na jakémkoliv mechanismu autentizace
Autorizační služby Tivoli Access Manager Autorizační služba produktu Tivoli Access Manager odpovídá za proces rozhodnutí o autorizaci, který pomáhá vymáhat uplatňování síťové bezpečnostní politiky. Výsledkem rozhodnutí o autorizaci, provedeném autorizační službou, je povolení nebo zakázání požadavků klienta, požadujících provádět operace s chráněnými zdroji v doméně.
Komponenty Autorizační služba se skládá ze tří základních komponent: v hlavní databáze politik autorizace v serveru politik v programu pro vyhodnocování rozhodnutí o autorizaci
Databáze politik Databáze politik, často také označovaná jako hlavní databáze politik autorizace a hlavní autorizační databáze, obsahuje informace o bezpečnostní politice všech zdrojů v doméně. Každá doména má vlastní databázi politik. S obsahem této databáze můžete pracovat pomocí rozhraní Web Portal Manager, obslužného programu pdadmin s rozhraním příkazového řádku a pomocí administrativního rozhraní API.
Server politik Server politik (pdmgrd) udržuje databázi politik, replikuje informace o politice v celé doméně a aktualizuje repliky databáze, kdykoliv jsou provedeny změny v hlavní databázi. Server politik dále spravuje informace o umístění dalších správců zdrojů Tivoli Access Manager i jiných správců zdrojů než Tivoli Access Manager, kteří pracují v doméně.
Program pro vyhodnocování rozhodnutí o autorizaci Program pro vyhodnocování rozhodnutí o autorizaci je rozhodovací proces, který na základě bezpečnostní politiky určuje schopnost klienta přistupovat ke chráněnému zdroji. Program pro vyhodnocování předává svá doporučení správci zdrojů, který pak podle nich odpovídá.
8
IBM Tivoli Access Manager: Base: Administrativní příručka
Parametry replikace databáze registrů jsou pro každý program pro vyhodnocování konfigurovatelné. Obrázek 3 představuje hlavní komponenty autorizační služby:
Obrázek 3. Komponenty autorizační služby
Rozhraní autorizační služby Autorizační služba má dvě rozhraní, na kterých probíhá výměna informací: v Rozhraní správy — správce zabezpečení spravuje bezpečnostní politiku prostřednictvím rozhraní Web Portal Manager nebo pomocí obslužného programu pdadmin s rozhraním příkazového řádku a tak aplikuje pravidla politiky na zdroje v doméně. Bezpečnostní politika je spravována servery politik v databázi politik. Toto rozhraní je komplexní a vyžaduje podrobné znalosti o prostoru objektů, politikách a pověřeních. v Autorizační rozhraní API — autorizační rozhraní API předává požadavky na rozhodnutí o autorizaci ze správce zdrojů do programu pro vyhodnocování rozhodnutí o autorizaci, který předává zpět svá doporučení, zda má být požadavek povolen nebo zamítnut.
Replikace pro zajištění škálovatelnosti a výkonnosti Komponenty autorizační služby je možné replikovat, a tak zvýšit dostupnost v prostředí s vysokými nároky. Hlavní databázi politik autorizace, která obsahuje pravidla politik a informace o pověřeních, můžete nakonfigurovat tak, aby byla automaticky replikována. Správci zdrojů, kteří volají autorizační služby, mají dvě možnosti jak získat informace o této databázi: v Pokud je aplikace konfigurovaná, aby pracovala s autorizačním programem pro vyhodnocování, používá lokální paměť cache databáze. Databáze je replikovaná pro každého správce zdrojů, který používá autorizační službu v režimu lokální paměti cache. v Aplikace používá sdílenou repliku, která je uložena do paměti cache komponentou vzdáleného autorizačního serveru. Databáze je replikována pro každou instanci autorizačního serveru. Mnoho aplikací může přistupovat k jednomu autorizačnímu serveru.
Kapitola 1. Přehled produktu IBM Tivoli Access Manager
9
Oznámení o aktualizaci, zasílané serverem politik (kdykoliv je provedena změna v hlavní databázi politik autorizace) spouští proces ukládání do paměti cache, aby všechny repliky byly aktualizovány, jak ilustruje Obrázek 4:
Obrázek 4. Komponenty replikované autorizační služby
Poznámky o výkonnosti v Navíc k aktualizaci upozornění směrovaných ze serveru politik lze konfigurovat správce zdrojů, aby kontroloval verze hlavních autorizačních databází politik po několika minutách. Tak je zajištěno, že neminuly oznámení o aktualizaci. Tento proces je znám jako systém výzev a není standardně aktivován. Pokud oznámení o aktualizaci nelze serveru doručit, je vytvořen záznam do protokolu. V obou případech mechanismus opětovného pokusu zajišťuje, že v budoucnosti bude provedena aktualizace replik. v Následkem ukládání informací o politice autorizace do paměti cache je vysoká výkonnost systému. Například pokud server WebSEAL provádí kontrolu autorizace, kontroluje politiku ve své vlastní verzi databáze uložené do paměti cache. Server WebSEAL nemusí přistupovat prostřednictvím sítě k hlavní databázi, aby získal potřebné informace. Výsledkem jsou velmi rychlé odpovědi (výkonnost) na kontroly autorizace. v Výsledky jednotlivých autorizací nejsou uloženy do paměti cache volajícím aplikačním serverem.
Implementace síťové bezpečnostní politiky Bezpečnostní politika domény je určena řízením zapojení uživatelů a skupin do domény a aplikací pravidel na zdroje, které vyžadují ochranu. Tyto pravidla jsou definovaná skrz použití ACL, POP a autorizačních pravidel. Autorizační služba vynutí používání uvedených politik tak, že porovná pověření uživatele s oprávněními uvedenými v politice přiřazené k požadovanému zdroji. Výsledné doporučení je předáno správci zdrojů, který dokončí odpověď na původní požadavek.
Definice a aplikace bezpečnostní politiky Systémové zdroje chráníte definicí bezpečnostní politiky. Tato bezpečnostní politika se vytvoří definováním ACL, POP a autorizačních pravidel a poté aplikuje tyto politiky na znázornění objektů zdrojů v prostoru objektů. ACL, POP a autorizační pravidla můžete použít
10
IBM Tivoli Access Manager: Base: Administrativní příručka
na stejný objekt. Při definici této politiky můžete použít obslužný program pdadmin s rozhraním příkazového řádku, grafické rozhraní Web Portal Manager a administrativní rozhraní API. Autorizační služba provádí rozhodnutí o autorizaci na základě politik, které jsou připojeny k těmto objektům. Je-li požadovaná operace na chráněném objektu (na který se také odkazuje jako na chráněný zdroj) povolena, správce zdrojů odpovědný za zdroje dokončí tuto operaci. Jedna politika může určit parametry zabezpečení pro mnoho objektů. Libovolná změna politiky v bezpečnostní politice ovlivní všechny objekty, ke kterým je tato politika připojená.
Explicitní a zděděná politika Bezpečnostní politiku můžete aplikovat explicitně, nebo ji můžete zdědit. Chráněný prostor objektů Tivoli Access Manager podporuje dědičnost ACL, POP a autorizačních pravidel. Tato vlastnost je velmi důležitá v úvahách administrátorů systémů, kteří spravují prostor objektů. Administrátor musí použít explicitní politiky pouze v takových bodech hierarchie, kde je nezbytně nutné změnit pravidla, jak ilustruje Obrázek 5:
Obrázek 5. Explicitní a zděděné politiky
Příklady pro typy politik zahrnují: v pevně naprogramovaná pravidla v schopnost použití externí autorizační služby v speciální bezpečné označování návěštím v ACL, POP a autorizační pravidla
Přístupové seznamy Politika přístupového seznamu (ACL), nebo také politika ACL, je sada akcí, řízení nebo oprávnění, která určuje podmínky, které je nutné splnit, aby určitý uživatel nebo skupina mohli provádět určité operace s daným zdrojem. Definice politiky ACL jsou důležitou komponentou bezpečnostní politiky zavedenou v doméně. Politika ACL konkrétně určuje, které operace je možné se zdrojem provádět a 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.
Politiky chráněného objektu Politiky chráněného objektu (POP) obsahují další podmínky, které musí být splněny, aby byl udělen přístup. Na rozdíl do přístupových seznamů, které jsou závislé na tom, který uživatel nebo skupina se pokouší o určitou akci, politiky POP ovlivňují všechny uživatele a skupiny. Kapitola 1. Přehled produktu IBM Tivoli Access Manager
11
Politiky POP dále určují, které z požadavků by měly být monitorovány. Produkt Tivoli Access Manager a správce zdrojů jsou odpovědni za to, že vynutí splnění podmínek politiky POP.
Autorizační pravidla Autorizační pravidla jsou definované, aby uváděli další podmínky, které musí být splněné před povolením vstupu do zdroje. Pravidla vám umožní provádět rozhodnutí o autorizaci založené na kontextu a prostředí obklopujícím požadavek, stejně jako kdo se snaží o přístup a o jaký typ akce byl provedený pokus. Tyto podmínky jsou vyhodnocené jako výrazy Boolean, které mají zjistit, zda by měla být žádost povolená nebo odepřená.
Autorizační proces: krok-za-krokem Obrázek 6 představuje celý proces autorizace:
Obrázek 6. Proces autorizace produktu Tivoli Access Manager
Poznámky: 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. Například, správce zdrojů může být WebSEAL pro protokol HTTP (Hypertext Transfer Protocol), přístup HTTPS nebo jiná aplikace. 2. Proces vymahače politiky zavolá prostřednictvím autorizačního rozhraní API autorizační službu a požádá ji o rozhodnutí o autorizaci. Bližší informace o autorizačním rozhraní API najdete v části “Autorizační API Tivoli Access Manager”. 3. Autorizační služba provede kontrolu autorizace zdroje. Podrobné informace o používaném algoritmu najdete na stránce 35. 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.
Autorizační API Tivoli Access Manager Autorizační rozhraní API (application programming interface) produktu Tivoli Access Manager umožňuje aplikacím Tivoli Access Manager a aplikacím jiných dodavatelů, aby žádaly autorizační službu o provedení rozhodnutí o autorizaci.
12
IBM Tivoli Access Manager: Base: Administrativní příručka
Autorizační rozhraní API je rozhraní mezi správcem zdrojů (který požaduje kontrolu autorizace) a vlastní autorizační službou. Autorizační API umožňuje správcům zdrojů Tivoli Access Manager a jiným správcům zdrojů žádat rozhodnutí o autorizace, ale kryje aplikaci před složitostmi skutečného procesu provádění rozhodnutí. Autorizační rozhraní API nabízí standardní programovací model pro kódovaní autorizačních požadavků a rozhodnutí o autorizaci. Autorizační rozhraní API vám umožní posílat standardizované žádosti na centrálně spravovanou autorizační službu z jakékoliv přejaté nebo nově vyvíjené aplikace. Autorizační rozhraní API je možné používat v jednom z níže uvedených dvou režimů: v režim vzdálené paměti cache V tomto režimu je rozhraní API inicializováno tak, aby volalo (vzdálený) autorizační server (pdacld), který bude provádět rozhodnutí o autorizaci v zastoupení aplikace. Autorizační server spravuje svou vlastní paměť cache, která obsahuje repliku databáze politik autorizace. Tento režim se doporučuje pro obsluhu požadavků na autorizaci klientů aplikace. Bližší informace o režimu vzdálené paměti cache najdete v části “Autorizační rozhraní API: režim vzdálené paměti cache” na stránce 14. v režim lokální paměti cache V tomto režimu je rozhraní API inicializováno tak, aby stáhlo a spravovalo lokální repliku autorizační databáze pro danou aplikaci. Režim lokální paměti cache poskytuje lepší výkonnost, protože aplikace provádí veškerá rozhodnutí o autorizaci lokálně, namísto toho, aby o tato rozhodnutí žádala přes síť. Avšak režie na replikaci databáze a dopady na zabezpečení ochrany dat, vzniklé při používání tohoto režimu, vedou k doporučení, aby tento režim byl používán pouze na ověřených aplikačních serverech. Bližší informace o režimu lokální paměti cache najdete v části “Autorizační rozhraní API: režim lokální paměti cache” na stránce 15. Jedna z primárních hodnot a prospěchů z autorizační API je jeho schopnost krýt správce zdrojů před složitostmi samotného mechanismu autorizačních služeb. Otázky správy, zálohování, ukládání do paměti cache, replikace, formátů pověření a politik autentizace - to vše je skryto za autorizačním rozhraním API. Autorizační rozhraní API také pracuje nezávisle na základních bezpečnostních infrastrukturách, formátu pověření a vyhodnocovacím mechanismu. Autorizační rozhraní API umožňuje požádat o kontrolu autorizace a získat zpět jednoduché doporučení ano nebo ne. Podrobnosti mechanismu kontroly autorizace nejsou pro uživatele viditelné.
Použití autorizačního rozhraní API: dva příklady Aplikace mohou používat autorizační rozhraní API, aby prováděly řízení přístupu pro velmi specifické a specializované procesy. Příklad 1: Grafické uživatelské rozhraní je možné navrhnout tak, aby dynamicky zobrazovalo tlačítka úloh jako aktivní nebo neaktivní v závislosti na výsledcích kontroly autorizace. Příklad 2: Obrázek 7 na stránce 14 demonstruje jiné použití autorizačního rozhraní API. Jde o požadavek na transakci CGI požadovanou webovou aplikací. Nejnižší úroveň autorizace, jak je zobrazeno na Obrázku A (viz Obrázek 7 na stránce 14), vyžaduje řízení přístupu k URL “všechno-nebo-nic”. Tato hrubě členěná úroveň autorizace
Kapitola 1. Přehled produktu IBM Tivoli Access Manager
13
pouze určuje, zda klient může spustit program CGI. Je-li povolen přístup k aplikaci CGI, není k dispozici žádné další řízení zdrojů, které jsou ovládány aplikací CGI. Na Obrázku B (viz Obrázek 7) je zobrazeno řízení přístupu, které bylo nastaveno na zdrojích, které ovládá program CGI. Webová aplikace je nakonfigurována tak, aby používala autorizační rozhraní API. Nyní může program CGI požádat autorizační službu, aby provedla rozhodnutí o autorizaci pro zdroje, se kterými pracuje — na základě totožnosti požadujícího klienta.
Obrázek 7. Příklad použití autorizačního rozhraní API
Autorizační rozhraní API: režim vzdálené paměti cache V režimu vzdálené paměti cache používají správci zdrojů volání funkcí poskytované autorizační API pro komunikaci s (vzdáleným) autorizačním serverem (pdacld). Autorizační server vystupuje jako program pro vyhodnocování rozhodnutí o autorizaci a spravuje svou vlastní repliku databáze politik autorizace. Autorizační server se rozhodne a prostřednictvím rozhraní API vrátí aplikaci doporučení učiněné na základě tohoto rozhodnutí. Server může také zapsat prověřovací záznam, který obsahuje podrobné informace o požadavku na rozhodnutí o autorizaci. V případě, že používáte režim vzdálené paměti cache, musí být někde v doméně spuštěn autorizační server, jak ilustruje Obrázek 8 na stránce 15. Autorizační server může být umístěn na stejném počítači jako aplikace, nebo na jiném počítači. Autorizační server můžete také nainstalovat na více než jeden počítač v doméně a tak zajistit vysokou dostupnost tohoto serveru. Autorizační rozhraní API se automaticky přepne při selhání určitého autorizačního serveru.
14
IBM Tivoli Access Manager: Base: Administrativní příručka
Obrázek 8. Autorizační rozhraní API: režim vzdálené paměti cache
Autorizační rozhraní API: režim lokální paměti cache V režimu lokální paměti cache API ukládá a udržuje repliky databází autorizačních politik na lokálním systému souborů správce zdrojů. Toto API provádí veškerá rozhodnutí o autorizaci přímo ve vlastní paměti, čehož následkem je vyšší výkonnost a lepší spolehlivost. Lokální replika je trvalá během vyvolání aplikace. Když se rozhraní API spustí v replikovaném režimu, zkontroluje všechny aktualizace, které mohly nastat v hlavní databázi politik autorizace od doby, kdy byla vytvořena lokální replika.
Kapitola 1. Přehled produktu IBM Tivoli Access Manager
15
Obrázek 9. Autorizační rozhraní API: režim lokální paměti cache
Schopnost externí autorizace V některých situacích by standardní implementace politik Tivoli Access Manager —ACL, POP a autorizační pravidla nemusely být schopné vyjádřit všechny podmínky požadované bezpečnostní politikou organizace. Produkt Tivoli Access Manager nabízí volitelnou možnost využití schopnosti externí autorizace, do které je možné začlenit další požadavky na autorizaci. Externí služba autorizace vám umožňuje zavést další řízení a podmínky autorizace, které jsou určovány odděleným, externím modulem autorizační služby.
Rozšíření autorizační služby Schopnost externí autorizace je automaticky zabudována do autorizační služby produktu Tivoli Access Manager. Pokud nakonfigurujete externí autorizační službu, pak autorizační služba produktu Tivoli Access Manager jednoduše zahrne cesty rozhodující o přístupu do svého vyhodnocovacího procesu. Správci zdrojů, kteří používají autorizační služby jako WebSEAL a aplikace používající autorizační API mají přínos z přídavných příspěvků konfigurovaných vnějších autorizačních služeb. Jakékoliv rozšíření bezpečnostní politiky prostřednictvím použití externí autorizační služby je pro takové aplikace transparentní a nevyžaduje žádné změny v aplikacích. Architektura externí autorizační služby dovoluje plnou integraci do stávajících služeb zabezpečení ochrany dat organizace. Externí autorizační služba chrání původní investice společnosti do mechanismů zabezpečení ochrany dat a umožňuje, aby byly přejaté servery začleněny do procesu rozhodování o autorizaci produktu Tivoli Access Manager.
16
IBM Tivoli Access Manager: Base: Administrativní příručka
Prosazení podmínek požadavkům na zdroj Externí autorizační službu je možné použít k prosazení přesnějších podmínek nebo vedlejších efektů specifických pro daný systém při úspěšných nebo neúspěšných pokusech o přístup. Takové podmínky zahrnují: v zajistit, aby externí monitorovací mechanismus zaznamenal úspěšný nebo neúspěšný pokus o přístup v aktivně monitorovat pokusy o přístup a vyvolat upozornění nebo poplach, jakmile bude detekováno nepřijatelné chování v řídit transakce fakturace nebo malých zálohových plateb v prosadit přidělování kapacit přístupů u chráněného zdroje
Proces vyhodnocování autorizace Rozhodnutí o autorizaci, které probíhá na externím autorizačním serveru, probíhá následujícím způsobem: 1. Je-li splněna podmínka spouštěcího impulsu v průběhu rozhodnutí o autorizaci, pak budou zavolány externí autorizační služby, které byly nakonfigurovány pro tuto podmínku, aby vyhodnotily svá vlastní externí omezení autorizace. Vyvolání externí autorizační služby se provede bez ohledu na to, zda budou nebo ne udělena potřebná oprávnění uživateli autorizační službou produktu Tivoli Access Manager. 2. Každá externí autorizační služba vrátí rozhodnutí povoleno, odepřeno nebo neutrální. Je-li vrácena odezva neutrální, pak externí autorizační služba určila, že její vlastní funkcionalita není potřeba pro proces rozhodování a že se z tohoto důvodu nebude účastnit. 3. Každému rozhodnutí autorizační služby je přidělena váha na základě úrovně důležitosti, kterou toto rozhodnutí vnáší do procesu rozhodování. Váhové koeficienty jednotlivých externích autorizačních služeb jsou nakonfigurovány během načítání plug-in programu služby. 4. Rozhodnutí všech autorizačních služeb jsou shrnuta a sečtena s rozhodnutím provedeným autorizační službou produktu Tivoli Access Manager. Výsledné rozhodnutí je vráceno volajícímu.
Příklad Obrázek 10 na stránce 18 zobrazuje rozhodnutí o autorizaci, do kterého je zapojen aplikační server a externí autorizační služba.
Kapitola 1. Přehled produktu IBM Tivoli Access Manager
17
Obrázek 10. Externí autorizační služba spolu s aplikačním serverem
V tomto příkladu je účelem externí autorizační služby prosadit omezení přidělené kapacity pro to, jak často je možné přistupovat k tiskárně s fotografickou kvalitou výstupu. Implementace služby prosazuje omezení počtu zadaných úloh, které může jedna osoba poslat na tuto tiskárnu za týden. Podmínka spouštěcího impulsu externí autorizační služby je připojena ke zdroji tiskárny s fotografickou kvalitou výstupu, takže tato externí autorizační služba je vyvolána vždy, když je přistupováno k této tiskárně s fotografickou kvalitou výstupu. Externí autorizační služba byla načtena se standardní hodnotou váhy rozhodnutí 101, která potlačuje všechna rozhodnutí provedená autorizační službou produktu Tivoli Access Manager, je-li to třeba. 1. Server správce zdrojů obdrží žádost od klienta o přístup do online zdroje pro tisk fotografií. Klient je členem odpovídající skupiny GraphicArtists a je tak normálně oprávněn posílat úlohy na tuto tiskárnu. 2. Aplikační server se nejprve obrátí na autorizační službu produktu Tivoli Access Manager, aby určila, zda požadující uživatel má oprávnění posílat úlohy na tiskárnu. 3. Autorizační služba zkontroluje oprávnění k přístupu k cílovému požadovanému objektu a porovná tato oprávnění se schopnostmi požadujícího uživatele: group GraphicArtists rx
V přístupovém seznamu pro zdroj tiskárny oprávnění označené znakem x uděluje přístup k zařízení všem uživatelům ve skupině GraphicArtists. Z tohoto důvodu autorizační služba udělí uživateli oprávnění odeslat úlohu. 4. Jelikož bylo přistoupeno ke zdroji tiskárny s fotografickou kvalitou výstupu a tak byla splněna podmínka spouštěcího impulsu autorizační služby, jež byla připojena k tomuto objektu, je poslán také požadavek na autorizační službu, která byla nakonfigurována pro tuto podmínku spouštěcího impulsu.
18
IBM Tivoli Access Manager: Base: Administrativní příručka
Vnější autorizační služba obdrží všechny ADI (Access Decision Information), které prošly společně s původní kontrolou rozhodnutím o přístupu provedenou serverem správce zdrojů. 5. Externí autorizační služba konzultuje záznam předchozích přístupů provedených tímto uživatelem. Pokud požadující uživatel dosud nevyčerpal celý svůj limit pro tento týden, pak tato služba vrátí rozhodnutí o přístupu “neutrální”. Důsledkem je, že tato externí autorizační služba se nezajímá o daný požadavek a nemá žádnou vůli účastnit se v procesu rozhodování o přístupu, neboť její podmínky pro zamítnutí žádosti o přístup nebyly splněny. Avšak pokud uživatel již vyčerpal svůj limit přístupů, pak externí autorizační služba vrátí rozhodnutí “přístup odepřen”. V tomto příkladu se předpokládá, že žadatel vyčerpal svůj limit přístupů a že externí autorizační služba tento fakt zjistila a vrátila rozhodnutí “přístup odepřen”. 6. Autorizační služba produktu Tivoli Access Manager obdrží od externí autorizační služby rozhodnutí “přístup odepřen”. Převezme toto rozhodnutí a ohodnotí ho pomocí standardní váhové hodnoty 101 externí autorizační služby. Výsledky rozhodnutí externí autorizační služby a rozhodnutí provedených autorizační službou Tivoli Access Manager jsou kombinované. Výsledkem je “přístup odepřen”, protože výsledek externí autorizační služby (-101) má větší váhu než výsledek autorizační služby produktu Tivoli Access Manager (100). 7. Server správce zdrojů zamítá postoupení úlohy zdroji pro tisk fotografií. 8. Server správce zdrojů vrátí odpověď, odkud byla vyvolaná, čímž označí, že úloha byla zamítnutá.
Implementace externí autorizační služby Při nastavení externí autorizační služby je nutné provést dva hlavní kroky: 1. Zapište režim plug-inu externí služby správce zdrojů s rozhraním autorizace, na které se můžete odkazovat během rozhodnutí o autorizaci. 2. Registrujte vnější autorizační služby se správcem zdrojů, takže správce zdrojů může zavést služby plug-inů v čase inicializace. Registrace služby nastaví podmínku spouštěcího impulsu, která vyvolá externí autorizační službu. Bude-li během kontroly autorizace splněna podmínka spouštěcího impulsu, bude vyvoláno rozhraní externí autorizační služby, aby tato mohla provést své dodatečné rozhodnutí o autorizaci.
Strategie nasazení Produkt Tivoli Access Manager vám dovoluje naimplementovat externí autorizační službu několika způsoby: v Aplikacemi správce zdrojů lze registrovat libovolný počet vnějších autorizačních služeb. Aplikace, které mohou zavádět vnější autorizační služby zahrnují autorizační server (pdacld), jiné správce zdrojů Tivoli Access Manager a libovolné další aplikace správce zdrojů, které vytvoříte. v Klienti autorizačního rozhraní API ve vzdáleném režimu, kteří žádají autorizační server o rozhodnutí o autorizaci, automaticky používají jakoukoliv externí autorizační službu, která je načtena autorizačním serverem. v Pro libovolnou jednu podmínku spouštěcího impulsu je možné vyvolat více než jednu externí autorizační službu. V takovém případě se výsledky všech externích autorizačních služeb ohodnotí váhami a výsledky jsou zkombinovány spolu s výsledkem autorizační služby produktu Tivoli Access Manager.
Kapitola 1. Přehled produktu IBM Tivoli Access Manager
19
v Podmínky spouštěcího impulsu je možné umístit na objekty pomocí spouštěcího impulsu politiky chráněného objektu (POP - Protected Object Policy), takže každý požadavek na objekt bez ohledu na operaci, která je požadována, spustí volání externí autorizační služby, která byla nakonfigurována pro daný spouštěcí impuls. v Podmínky spouštěcího impulsu je možné také umístit na operace, které jsou požadovány uživatelem. Například externí autorizační služba může být spouštěna pouze tehdy, pokud uživatel žádá o operaci zápisu do chráněného zdroje, ale nemusí být spuštěna žádnou jinou operací. Je možné vyvinout sadu operací, pro které bude spuštěna jedna nebo kombinace více externích autorizačních služeb, a to v závislosti na sadě požadovaných operací. v Externí autorizační služby se implementují jako moduly knihoven DLL (dynamically loadable library). To významně zjednodušuje úlohu vývoje externí autorizační služby. Není třeba splnit požadavky na vytvoření vzdálených požadavků na externí autorizační službu, takže režie na vytvoření volání odpovídá režii na volání funkce. v Kombinace autorizačního rozhraní API a externí autorizační služby nabízí velmi rozšiřitelné a flexibilní řešení pro implementaci komplexní bezpečnostní politiky.
20
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 2. Web Portal Manager Produkt Tivoli Access Manager nabízí dva typy uživatelských rozhraní: v Web Portal Manager, rozhraní založené na webu Toto rozhraní je použité pro poskytování správy a administrativy domén, uživatelů, skupin, oprávnění, přístupových seznamů, politik chráněných objektů, autorizačních pravidel, prostorů chráněných objektů, chráněných objektů a jiných zdrojů v zabezpečené doméně. v Příkaz pdadmin, rozhraní příkazového řádku Toto rozhraní poskytuje stejné úlohy pro spravování bezpečnostních politik pro zabezpečenou doménu. Obslužný program příkazového řádku je instalovaný jako součást běhové sady programů Tivoli Access Manager. Můžete zautomatizovat také některé funkce správy tím, že napíšete skripty, které používají příkazy pdadmin. Publikace IBM Tivoli Access Manager for e-business Command Reference poskytuje detailní informace o rozhraní příkazového řádku pdadmin a o jiných obslužných programech příkazového řádku. Jeden z faktorů, který byste si měli zapamatovat při rozhodování, které rozhraní použít, je že s použitím Web Portal Manager můžete provést cílovou podmnožinu příkazů pdadmin. Abyste srovnali mapování, které existuje mezi rozhraním příkazového řádku (CLI) administrativy pdadmin a Web Portal Manager, viz Dodatek C, “Ekvivalenty Web Portal Manager a příkazového řádku administrativy”, na stránce 331. Další rozdíl mezi těmato dvěma typy rozhraní je, že s použitím příkazu pdadmin můžete uvést soubor. Použijete-li rozhraní Web Portal Manager, nemůžete uvést jméno souboru, ale v některých případech jej můžete vyjmout a vložit, abyste mohli použít obsah souboru (například autorizační pravidla). Tato kapitola obsahuje následující části: v “Typy administrativy” v “Funkce delegované administrativy” na stránce 22 v “Vlastní podpora” na stránce 22 v “Vlastní registrace” na stránce 22 Procedury rozhraní Web Portal Manager jsou zahrnuté pro: v “Společné úlohy rozhraní Web Portal Manager” na stránce 23 v “Úprava rozhraní Web Portal Manager podle uživatele” na stránce 26 v “Úlohy vlastní registrace” na stránce 27
Typy administrativy Produkt Tivoli Access Manager nabízí dva typy administrativy: v administrativa rozhraní Web Portal Manager v delegovaná administrativa rozhraní Web Portal Manager Administrativa rozhraní Web Portal Manager poskytuje rozhraní založené na webu podobné základním funkcím pdadmin. Administrativa rozhraní Web Portal Manager nezahrnuje funkce delegované administrativy.
Funkce delegované administrativy Delegovaná administrativa rozhraní Web Portal Manager poskytuje rozhraní založené na webu, které zahrnuje sadu služeb delegované správy. Funkce delegované administrativy rozhraní Web Portal Manager jsou pokládané za zvláštní aplikaci od funkcí administrativy. Služby delegované správy umožňují obchodu delegovat administrativu uživatele a skupiny nebo rolovat administrativu, administrativu zabezpečení a zajištění přístupu do aplikace do účastníků (poddoménám) v obchodním systému. Tyto poddomény mohou následně delegovat správu a administrativu na ověřené (důvěryhodné) poddomény, které mají pod svou kontrolou, a tím podporovat víceúrovňovou hierarchii delegování a správy založenou na rolích. Delegovaná administrativa podporuje: v vytváření více celopodnikových domén v přiřazení uživatelů k administrátorům domény v přiřazení typů administrátorů (jako např. Administrátor produktu Tivoli Access Manager, Administrátor domény, Pokročilý administrátor, Administrátor a Pomocný administrátor) a prosazování administrativních funkcí, které může provádět každý typ administrátora v používání vlastní registrace, což je proces, jak se stát registrovaným uživatelem produktu Tivoli Access Manager bez účasti administrátora, a používání vlastní podpory, která snižuje zatížení administrátorů Viz Kapitola 16, “Delegovaná administrativa”, na stránce 155, chcete-li získat podrobný popis funkcí delegované administrativy produktu Tivoli Access Manager.
Vlastní podpora Rozhraní Web Portal Manager může být nasazeno tak, aby podporovalo velký počet uživatelů. Se zvyšujícím se počtem uživatelům roste také počet administrátorů, kteří jsou potřeba ke správě těchto uživatelů. Funkce rozhraní Web Portal Manager s názvy vlastní registrace a vlastní podpora se používají ke snížení požadavků na administrativu. Rozhraní Web Portal Manager podporuje operace vlastní podpory tím, že umožňuje uživatelům produktu Tivoli Access Manager měnit svá hesla do produktu Tivoli Access Manager přes rozhraní Web Portal Manager. Uživatelé mohou přejít na stránku delegované administrativy rozhraní Web Portal Manager a spravovat svá hesla. Po přihlášení může uživatel přejít do úlohy Change My Password (Změnit mé heslo).
Vlastní registrace Vlastní registrace je proces, jímž uživatel zapisuje požadovaná data, aby se stal registrovaným uživatelem produktu Tivoli Access Manager bez účasti administrátora. Rozhraní Web Portal Manager obsahuje vzorovou aplikaci, která dovoluje koncovým uživatelům, aby prováděli vlastní registraci. Všimněte si, že tento příklad podporuje pouze registr LDAP, nikoliv Domino nebo Active Directory. Součástí rozhraní Web Portal Manager je vzorový kód, který implementuje stránku s vlastní registrací. Vzorový kód demonstruje, jak používat administrativní rozhraní API implementace jazyku Java produktu Tivoli Access Manager spolu s platformou Java 2, servlety Java Enterprise Edition (J2EE) a Java Server Pages (JSPs) při implementaci vlastní registrace. Viz “Úlohy vlastní registrace” na stránce 27.
22
IBM Tivoli Access Manager: Base: Administrativní příručka
Společné úlohy rozhraní Web Portal Manager Tato kapitola poskytuje procedury pro více společných úloh Web Portal Manager, jako jsou: v “Spuštění administrativy rozhraní Web Portal Manager” v “Spuštění delegované administrativy rozhraní Web Portal Manager” v “Přihlášení a odhlášení” na stránce 24 v “Získání online nápovědy” na stránce 24 v “Hledání” na stránce 24 v “Zobrazení seznamů” na stránce 24
Spuštění administrativy rozhraní Web Portal Manager Než spustíte rozhraní Web Portal Manager, přesvědčte se, že je spuštěn proces WebSphere Application Server. Potom použijte jednu z následujících URL, čímž spustíte administrativu rozhraní Web Portal Manager: v Pokud jste nainstalovali, nakonfigurovali a aktivovali SSL, zadejte ve vašem webovém prohlížeči následující adresu URL: https://jméno_hostitele/pdadmin
kde jméno_hostitele je jméno počítače, na kterém je spuštěn IBM HTTP server a WebSphere. v Pokud nemáte instalovanou, konfigurovanou a aktivovanou SSL, zapište ve svém prohledávacím programu webu následující URL: http://jméno_hostitele/pdadmin
Spuštění delegované administrativy rozhraní Web Portal Manager Funkce delegované administrativy rozhraní Web Portal Manager lze vytvořit přístup z různých URL než jsou základní příkazové funkce pdadmin rozhraní Web Portal Manager. Funkce delegované administrativy Web Portal Manager jsou považované za zvláštní aplikaci. Použijte jednu z následujících URL, abyste spustili delegovanou administrativu rozhraní Web Portal Manager a vytvořili přístup k základním funkcím pdadmin rozhraní Web Portal Manager: v Pokud nemáte instalovanou, konfigurovanou a aktivovanou SSL, zapište ve svém prohledávacím programu webu následující URL: http://jméno_hostitele/delegate
v Pokud jste nainstalovali, nakonfigurovali a aktivovali SSL, zadejte ve vašem webovém prohlížeči následující adresu URL: https://jméno_hostitele/delegate
kde jméno_hostitele je jméno počítače, na kterém je spuštěn IBM HTTP server a WebSphere. Například: https://testgroup.austin.ibm.com/delegate
Uživatelé jsou schopni přihlásit se do rozhraní Web Portal Manager na stránku delegované administrativy a spravovat svá hesla. Po přihlášení by měl uživatel přejít k úloze Change My Password (Změna mého hesla). Kapitola 2. Web Portal Manager
23
Přihlášení a odhlášení Abyste se přihlásili do rozhraní Web Portal Manager: 1. Spusťte administrativu pomocí rozhraní Web Portal Manager. 2. Poskytněte nutné autentizační informace pro rozhraní Web Portal Manager, jako např. jméno uživatele a heslo. 3. Až se objeví logo produktu Tivoli Access Manager, vyberte a proveďte úlohy, které potřebujete. 4. Klepnutím na tlačítko Odhlásit na dolním stavovém řádku ukončíte administrativu pomocí rozhraní Web Portal Manager.
Získání online nápovědy Úlohy, které je možné provádět pomocí rozhraní Web Portal Manager, jsou popsány v systému online nápovědy. Pokud zadáváte informace do polí nebo pokud volíte nebo rušíte volby z rozhraní Web Portal Manager, odkazujeme vás na systémovou nápovědu. Chcete-li používat online nápovědu rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Vyberte úlohu jako Group (Skupina)→ Import Group (Import skupiny). 3. Klepněte na ikonu otazníku na pravé straně okna v titulkovém řádku úlohy. Zobrazí se okno nápovědy, které poskytuje online informace pro dokončení úlohy. 4. Uzavřete okno nápovědy, jakmile skončíte úlohu.
Hledání Funkci hledání použijte k zobrazení seznamu položek (jako jsou ID uživatele nebo jména skupin), které se shodují se zadanými kritérii pro hledání. Pro hledání s použitím rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Zvolte úlohy hledání. Například, klepněte na User (Uživatel)→ Search Users (Hledat uživatele). 3. Zadejte ID uživatele a použijte zástupný znak (*), abyste omezili hledání. Zástupný znak (*) se může objevit kdekoli v ID uživatele. Například: v Abyste prohledali všechny ID uživatelů, zapište *. Tato kritéria hledání by nalezla ibm, IBM a IbM, protože hledání je citlivé na velikost písmen. v Chcete-li hledat ID uživatele začínající písmeny ibm, zapište ibm*. v Chcete-li hledat ID uživatele končící písmeny ibm, zapište *ibm. v Chcete-li nalézt ID uživatele začínající písmeny ib a končící písmeny m, zapište ib*m. Tato kritéria hledání by nalezla ibm, IBM a IbM, protože hledání je citlivé na velikost písmen. Nalezlo by také IB.com a Ibstam. 4. Zapište maximální počet ID uživatele nebo jmen skupin, který chcete zobrazit. Všimněte si, že zapsání počtu vyššího než je předvolená hodnota 100 může vyústit v pomalou odezvu. 5. Uzavřete okno nápovědy, jakmile skončíte úlohu.
Zobrazení seznamů Funkci výpis použijte k zobrazení tabulky položek, které se shodují s uvedenými kritérii výběru.
24
IBM Tivoli Access Manager: Base: Administrativní příručka
Abyste zobrazili seznam položek s použitím rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Zvolte úlohu výpis. Například, klepněte na ACL → List ACL (Výpis ACL), abyste zobrazili tabulku vypisující ACL. Ze seznamu můžete vytvořit novou ACL, smazat jednu nebo víc existujících ACL, zobrazit vlastnosti zvolené ACL, měnit volby a měnit fitry.
Změna voleb Abyste změnili volby zobrazování s použitím rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Zvolte úlohu výpis. Například, klepněte na ACL → List ACL (Výpis ACL), abyste zobrazili tabulku vypisující ACL. 3. Klepněte na tlačítko Options (Volby) pro přepnutí a zobrazení pole Entries Per Page (Záznamy na stránku). Pro ID uživatelů se zobrazí také zaškrtávací okénko Show Entry Details (Zobrazení podrobností záznamu). Pokud jej zvolíte, v tabulce se zobrazí tyto dodatečné sloupce: v Křestní jméno v Příjmení v Platné heslo v Platný účet Zrušením volby v zaškrtávacím okénku odstraníte tyto sloupce ze zobrazení. 4. Abyste zobrazili určitý počet záznamů na stránku, přijměte předvolenou hodnotu nebo zapište počet v poli Entries Per Page (Záznamy na stránku) a potom klepněte na tlačítko OK. 5. Pokud je počet záznamů na stránku překročen, zobrazí se víc než jedna stránka záznamů, dodatečné položky navigace jsou přidané na konec tabulky na každé stránce. Můžete navigovat mezi stránkami tím, že klepněte na přepínací ikonu na stránce nebo zapíšete číslo stránky a potom klepněte na tlačítko Go (Jít na). Celkový počet záznamů v tabulce se zobrazí také (například, Total: 65, Filtered: 65). 6. Klepněte na tlačítko Close (Zavřít), abyste skryli pole Entries Per Page (Záznamy na stránku).
Změna filtrů Abyste změnili filtrování s použitím rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Zvolte úlohu výpis. Například, klepněte na ACL → List ACL (Výpis ACL), abyste zobrazili tabulku vypisující ACL. 3. Klepněte na tlačítko Filters (Filtry), abyste přepnuli a zobrazili odkaz. Nejsou-li použité žádné filtry, pro sloupec se zobrazí odkaz None (Žádné). 4. Klepněte na odkaz filtru. Pro ID uživatele se každý sloupec zobrazí s vlastním odkazem filtru. 5. V poli Text zapište text, který chcete použít k filtrování, jako Luca. 6. Zvolte jedno z kritérií filtrování ze seznamu: v Obsah v Začíná s v Končí s 7. Klepněte na tlačítko OK, čímž spustíte proces filtrování.
Kapitola 2. Web Portal Manager
25
Pokud je počet záznamů na stránku překročen, zobrazí se víc než jedna stránka záznamů, dodatečné položky navigace jsou přidané na konec tabulky na každé stránce. Můžete navigovat mezi stránkami tím, že klepněte na přepínací ikonu na stránce nebo zapíšete číslo stránky a potom klepněte na tlačítko Go (Jít na). Celkový počet záznamů a počet filtrovaných záznamů v tabulce se zobrazí také (například, Total: 65, Filtered: 65). 8. Klepněte na tlačítko Close (Zavřít), čímž skryjete volby filtrování. Odkaz filtrování se změní z None (Žádné) na text, který jste zapsali pro filtrování (například, Luca).
Úprava rozhraní Web Portal Manager podle uživatele Rozhraní Web Portal Manager počítá s přizpůsobením rozhraní pro uživatele produktu Tivoli Access Manager. Uživatel produktu Tivoli Access Manager může upravit rozhraní Web Portal Manager tak, že změní konfiguraci určení, která stránka HTML nebo soubor GIF se má načíst během spouštění rozhraní Web Portal Manager.
Přizpůsobení obrázků Abyste mohli přizpůsobit obrázek: 1. Změňte hodnotu voleb obrázku v konfiguračním souboru pdwpm.conf, abyste uvedli různé obrázky. Existují čtyři oblasti obrázků, které lze přizpůsobit v rozhraní Web Portal Manager změnou voleb: a. loginGif — tento soubor zobrazuje přihlašovací stránku b. splashGif — tento soubor zobrazuje uvítací stránku, která následuje po přihlašovací stránce c. infoBarGif — tento soubor zobrazuje logo IBM v pravém dolním rohu stránky d. bannerFile — tento soubor zobrazuje banner v horní části každé stránky 2. Umístěte nové obrázky v jednom z následujících adresářů: v pro operační systémy UNIX: instalační_adresář_websphere/WebSphere/AppServer/installedApps/jméno_serveru/ TAMWPM.ear/pdadmin.war/images
v pro operační systémy Windows: instalační_adresář_websphereProgram Files\WebSphere\AppServer\installedApps\ jméno_serveru\TAMWPM.ear\pdadmin.war\images
3. Pro obrázky, jejichž verze jsou specifické pro různé jazykové mutace, vytvořte podadresáře v následujících adresářích, a to pro každou požadovanou jazykovou mutaci, a do těchto podadresářů umístěte nové obrázky: v pro operační systémy UNIX: instalační_adresář_websphere/WebSphere/AppServer/installedApps/jméno_serveru/ TAMWPM.ear/pdadmin.war/images/myImage.gif
v pro operační systémy Windows: instalační_adresář_websphereProgram Files\WebSphere\AppServer\installedApps\ jméno_serveru\TAMWPM.ear\pdadmin.war\images\lokální\myImage.gif
Vytvoření přizpůsobitelného horního banneru Abyste mohli vytvořit přizpůsobitelný horní banner pro rozhraní Web Portal Manager: 1. Vytvořte soubor JSP nebo HTML. 2. Vytvořený soubor JSP nebo HTML vložte do stejného adresáře, ve kterém je soubor top_banner.jsp. 3. Změňte hodnotu volby bannerFile, jejíž předvolená hodnota je bannerFile=top_banner.jsp, tak, aby se odkazovala na jméno nového souboru JSP nebo HTML.
26
IBM Tivoli Access Manager: Base: Administrativní příručka
Rozvržení okna je uvedeno v souboru pdmainframe.jsp, který nastavuje okno na stránku o výšce 50 pixelů.
Úlohy vlastní registrace Produkt Tivoli Access Manager nabízí příklad vlastní registrace, aby představil, jak tento proces pracuje. Poznámka: Tento příklad je podporovaný pouze pro registr uživatelů LDAP, ne pro IBM Lotus Domino nebo Microsoft Active Directory.
Provedení vlastní registrace Jeden z možných skriptů pro provedení vlastní registrace je tam, kde uživatel otevírá prohledávací program webu, aby si zobrazil webové stránky pro vlastní registraci. Na této webové stránce uživatel zadá požadované informace o totožnosti (specifické buď pro společnost, nebo pro uživatele) spolu s ID uživatele produktu Tivoli Access Manager a heslem. Informace o totožnosti poskytnuté uživatelem jsou pak potvrzeny a uživatel je zadán do registru produktu Tivoli Access Manager. Protože uživatelé nemívají obvykle oprávnění vytvářet objekty v prostředí produktu Tivoli Access Manager, vyžaduje příklad vlastní registrace ID a heslo administrátora, který má oprávnění vytvářet uživatele. Tyto informace o přihlášení se pak použijí k vytvoření uživatelů, jakmile někdo zadá požadovanou informaci na stránce pro registraci. Níže uvedené informace je nezbytné zadat při prvním použití příkladu vlastní registrace. Tato data budou uložena pomocí servletu do paměti a pak se budou používat při vytváření uživatelů, kteří budou žádat o registraci. v jméno administrátora v heslo v zásobník registru Jméno a heslo administrátora by mělo být shodné s administrátorem, který má oprávnění vytvářet uživatele v prostředí produktu Tivoli Access Manager. Standardně má správný přístup administrátor sec_master. Do pole Zásobník registru byste měli zadat základní jméno v registru LDAP, kam by měly být zadávány záznamy o uživateli. Tato hodnota se použije k vytvoření rozlišovacího jména (DN) pro uživatele, kteří se sami zaregistrovali. Zadejte například o=ibm,c=us a zaregistrovaní uživatelé budou vytvořeni v registru LDAP jako cn=JmenoPrijmeni,o=ibm,c=us. Uživatel nebude přidán do žádné ze skupin. Ve skutečné aplikaci by měl být uživatel nejspíše přidán do některé ze skupin, které mají přístup k některé z aplikací. Po zadání informací o administrátorovi se tato stránka již nikdy nezobrazí. Pokud použijete příklad, bude vám zobrazena pouze stránka pro registraci, do které můžete zadat jméno, příjmení a heslo. Všimněte si, že informace o přihlášení administrátora jsou uloženy v relaci servletu. Každý uživatel, který použije příklad vlastní registrace ze stejného prohlížeče, bude moci vytvořit uživatele v produktu Tivoli Access Manager. Chcete-li vymazat informace o přihlášení administrátora, musíte znovu spustit aplikační server. V tomto příkladě není ID a heslo uloženo bezpečným způsobem. Pokud použijete tento příklad jako základ pro reálnou aplikaci vlastní registrace, měli byste zvážit způsoby, jak zabezpečit informace o přihlášení administrátora.
Kapitola 2. Web Portal Manager
27
Změna stránek serveru Java Ve vzorové aplikaci se používají tři stránky JSP: v regAdmin.jsp je stránka, která se zobrazí při shromažďování informací o přihlášení administrátora, v regProp.jsp je stránka, která se zobrazí při shromažďování informací o jméně, příjmení a hesle uživatele, v regControl.jsp obsahuje kód, který vytvoří uživatele. Tato stránka přijímá a zpracovává požadavky na registraci. Mohla by se také použít třída servletu (servlet class). Tyto soubory jsou nainstalovány v následujícím adresáři: v pro operační systémy UNIX: instalační_adresář_websphere:/WebSphere/AppServer/installedApps/ jméno_serveru/TAMWPM.ear/register.war/register
v pro operační systémy Windows: instalační_adresář_websphere:\Program Files\WebSphere\AppServer\installedApps\ jméno_serveru\TAMWPM.ear\register.war\register
kde instalační_adresář_websphere je adresář, kde je instalovaný WebSphere. Po zadání informací o přihlášení administrátora se vytvoří JRTE PDContext a uloží se do relace uživatelského servletu, jak je zobrazeno níže: String adminid = request.getParameter("admin"); String adminPassword = request.getParameter("password"); String ldapSuffix = request.getParameter("suffix"); ... // Try a login (Pokus o přihlášení) try { ctx = new PDContext(adminid, adminPassword.toCharArray(), url); // Save the PDcontext and the LDAP Suffix (Uložení PDcontext a přípony LDAP) session.setAttribute("regAdminCtx", ctx); session.setAttribute("ldapSuffix", ldapSuffix); } catch(PDException e) { // process exception (zpracování výjimky) ... }
Až uživatel zadá informace o novém uživateli, načte se z relace PDContext a použije se k vytvoření nového uživatele, jak je ukázáno níže: // Creating the PD User (Vytvoření uživatele PD) pwd = request.getParameter("password"); ldapcn = request.getParameter("ldapcn"); ldapsn = request.getParameter("ldapsn"); ldapdn = "cn=" + ldapcn + ldapsn + "," + ldapSuffix; userid = ldapcn + ldapsn; desc = ldapcn + " " + ldapsn; ctx = (PDContext)session.getAttribute("regAdminCtx"); // Make sure the session has not timed out (Ujistit se, že relaci neskončila platnost) if ( ctx == null ) { %> <%@ include file="regAdmin.jsp" %> <%
ID nového uživatele je jméno a příjmení spojené dohromady.
Kapitola 2. Web Portal Manager
29
30
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 3. Administrativa produktu Tivoli Access Manager Administrativa produktu Tivoli Access Manager zahrnuje následující hlavní úlohy: 1. Vytvořit doménu, je-li to nutné. 2. Instalovat a konfigurovat správce zdrojů. Všichni správci zdrojů Tivoli Access Manager jako WebSEAL a jiné komponenty procesu blade jako Plug-in for Web Server automaticky vytvoří prostor chráněných objektů a požadované chráněné zdroje (také známé jako chráněné objekty), když jsou konfigurované. v Pokud je to nutné, vytvořit prostor objektů. v Pokud je to nutné, definovat chráněné objekty v prostorách objektů, které představují zdroje, které mají být chráněné. 3. Nadefinovat uživatele a skupiny, kteří vyžadují přístup ke chráněným zdrojům. 4. Pro chráněné objekty můžete nadefinovat: v Komu je povolen přístup. v Jaký typ přístupu je povolen. v Kdy je přístup dovolen. v Jaké podmínky musí být splněny, aby byl přístup povolen. v Zda bude požadavek na přístup monitorován. 5. Dokončit vaši bezpečnostní politiku připojením ACL (access control list), POP (protected object policy) a autorizační pravidla k objektům v prostoru chráněných objektů.
Například, předpokládejme, že uživatel pojmenovaný jako John Doe je definovaný jako JohnDoe v doméně Sales (Prodej) a jako JDoe v doméně Advertising (Reklama). Přestože se jedná o stejnou osobu, ID uživatele je jedinečné pro každou doménu. Proto prostředkům dostupným pro uživatele JohnDoe lze udělit přístup pouze skrz tuto jedinečnou totožnost, jak je definována v doméně (Sales (Prodej)), nebo skrz skupiny, které jsou definované v doméně Sales (Prodej) a jejíchž členem je JohnDoe. Podobně uživateli JDoe, přestože se jedná o stejnou osobu, může být udělen přístup pouze skrz jeho jedinečnou totožnost definovanou v doméně Advertising (Reklama). v Zjednodušená administrativa Abyste obsloužili úlohy spravování politik pro každou doménu, můžete k nim přiřadit nezávislé administrátory. Například, předpokládejme, že jste specialista na IT pro velké korporace, kterému je zadáno nasadit Tivoli Access Manager z jednoduchého datového centra. Mohli byste vytvořit zvláštní doménu (s jedinečnou databází politik a administrátorem) pro každou organizaci, oddělení nebo geografickou oblast ve vaší společnosti. Jak se uživatelé, skupiny nebo prostředky mění, je přidělený administrátor odpovědný za aktualizaci bezpečnostní politiky pro danou doménu. Tento administrátor domény může také přidělovat úlohy administrativy jiným v té určité doméně. Administrátor přiřazený k určité doméně vlastní oprávnění pouze v této doméně. Ale, pokud je tak nastaveno v předvolbě, administrátor si může zobrazit uživatele a skupiny definované v registru uživatelů, kteří nemusí být nutně uživatelem nebo skupinou Tivoli Access Manager. Toto je přínosné, pokud chce administrátor například importovat uživatele nebo skupinu z jiné domény. Naopak, pokud jste administrátorem domény správy a chcete omezit data registru, ke kterým může mít administrátor domény přístup, můžete přidat záznam objektu stanza allowed-registry-substrings do objektu stanza [domains] v konfiguračním souboru serveru politik (ivmgrd.conf). Abyste získali další informace o správě domén, viz Kapitola 5, “Správa domény”, na stránce 59.
Prostor chráněných objektů Produkt Tivoli Access Manager znázorňuje zdroje v doméně pomocí virtuálního znázornění, které se nazývá prostor chráněných objektů. Prostor chráněných objektů je logickým a hierarchickým znázorněním zdrojů patřících do domény. Prostor chráněných objektů se skládá ze dvou typů objektů: objekty typu prostředek Objekty typu prostředek jsou logickým znázorněním skutečných fyzických prostředků v doméně, jako jsou soubory, služby, webové stránky, fronty zpráv apod. objekty typu zásobník Objekty typu zásobník jsou strukturální označení, která vám umožní hierarchicky organizovat prostor objektů do zvláštních funkcionálních oblastí. Bezpečnostní politiku lze použít pro oba typy objektů. Obrázek 11 na stránce 33 zobrazuje logické znázornění prostoru chráněných objektů s více objekty typu zásobník a typu prostředek.
32
IBM Tivoli Access Manager: Base: Administrativní příručka
Obrázek 11. Prostor chráněných objektů produktu Tivoli Access Manager
Vrchol struktury, nebo také začátek, prostoru chráněných objektů je objekt typu zásobník root (kořen), který je představován znakem lomítko (/). Pod kořenovým objektem typu zásobník je jeden nebo více objektů typu zásobník. Každý objekt typu zásobník představuje prostor objektů skládající se ze sady souvisejících zdrojů. Tyto zdroje mohou být objekty typu prostředek nebo jiné objekty typu zásobník. Produkt Tivoli Access Manager vytváří prostor objektů s názvem /Management, který obsahuje objekty, které používá produkt Tivoli Access Manager k vlastní správě. Každý správce zdrojů, který chrání související sadu prostředků, si vytváří svůj vlastní prostor objektů. Například komponenta WebSEAL, která chrání informace a zdroje založené na Webu, vytváří prostor objektů s názvem /WebSEAL. Těmto společným aplikacím se říká procesy blade. Obrázek 12 zobrazuje prostor objektů /Management v prostoru chráněných objektů.
Obrázek 12. Oblasti prostoru chráněných objektů Tivoli Access Manager
Uživatelé a skupiny Produkt Tivoli Access Manager spravuje informace o uživatelích a skupinách produktu Tivoli Access Manager v registru uživatelů. Uživatelé a skupiny, které již v registru uživatelů existují, mohou být do produktu Tivoli Access Manager naimportováni. Pokud v registru uživatelů uživatel nebo skupina dosud neexistuje, může být vytvořen přímo produktem Tivoli Access Manager. Kapitola 3. Administrativa produktu Tivoli Access Manager
33
Když se vytvoří domény, vytvoří se současně speciální uživatel známý jako administrátor domény. V doméně správy se administrátoru domény nastaví ID uživatele (sec_master) a heslo během konfigurace serveru politik produktu Tivoli Access Manager. Pro další domény se ID uživatele a heslo administrátora domény nastaví při jejich vytvoření. Administrátor domény má téměř naprostou kontrolu nad doménou. Myslete si, že administrátor domény je ekvivalentem produktu Tivoli Access Manager účtu uživatele root v prostředí operačního systému Unix, nebo uživatele Administrátor v prostředí operačního systému Microsoft Windows. Administrátor domény se do domény přidá jako člen skupiny produktu Tivoli Access Manager s názvem iv-admin. Skupina iv-admin přestavuje uživatele, kteří mají oprávnění administrátora domény. Měli byste opatrně přidávat uživatele do této skupiny, abyste zajistili, že nebude prozrazeno zabezpečení vaší domény.
Bezpečnostní politika Přístup do objektů v doméně je řízený použitím bezpečnostní politiky (politika POP, ACL a pravidla) na objekt typu zásobník a prostředek v prostoru chráněných objektů. Bezpečnostní politika může být také explicitně použitá pro objekty nebo děděná objektem z objektů, které se v hierarchii nachází výš. Explicitní bezpečnostní politiku musíte aplikovat v prostoru chráněných objektů pouze v takových místech hierarchie, ve kterých se musí změnit pravidla.
Obrázek 13. Explicitní a zděděné politiky
Bezpečnostní politika je definovaná s použitím kombinace: v přístupových seznamů (ACLs - Access Control Lists) Přístupový seznam nebo ACL uvádí, kterou sadu předdefinovaných akcí může provádět určitá sada uživatelů a skupin s objektem. Například můžete určité sadě skupin nebo uživatelů udělit přístup ke čtení objektu. v politik chráněných objektů (POP) Politika chráněného objektu nebo POP uvádí podmínky přístupu, které jsou přidruženy k objektu a které ovlivňují všechny uživatele a skupiny. Například k objektu můžete připojit omezení přístupu během dne, které zakazuje všem uživatelům a skupinám přistupovat k objektu v jiné době, než je přesně vymezeno touto podmínkou. v pravidla autorizace Pravidlo autorizace uvádí komplexní stav, který je vyhodnocený pro určování povolení přístupu. Data použitá pro toto určení mohou být založená na kontextu požadavku, aktuálním prostředí nebo jiných vnějších faktorech. Například, požadavek upravit objekt více než pětkrát během osmihodinového období by mohl být odepřený.
34
IBM Tivoli Access Manager: Base: Administrativní příručka
Bezpečnostní politika je implementovaná strategickým použitím ACL, politik POP a pravidel autorizace pro prostředky požadující ochranu. Autorizační služba produktu Tivoli Access Manager provádí rozhodnutí o povolení nebo odepření přístupu k prostředkům založeným na pověření uživatele provádějícího tento požadavek a určitých oprávněních a podmínkách nastavených v ACL, politikách POP a pravidlech autorizace. Prostředek autorizace používá ke zpracování podmínek v politice připojené ke chráněnému objektu následující algoritmus: 1. Zkontroluje oprávnění v ACL. Více informací o procesu ohodnocení přístupového seznamu najdete v části “Vyhodnocování ACL” na stránce 36. ACL se také kontroluje, aby bylo zjištěno, zda uživatel (pro kterého se kontrola autorizace provádí) vlastní přídavnou imunitu, aby nebyl ovlivněný politikou POP nebo politikou autorizačních pravidel. Tuto imunita je udělená, pokud ACL uživatele s vlivem na přístup do objektu obsahuje oprávnění B znamenající, že politika POP bude ignorovaná, nebo oprávnění R znamenající, že politika autorizačních pravidel je ignorovaná. 2. Pokud je autorizační pravidlo připojeno k objektu a uživatel nemá imunitu proti ovlivnění autorizačními pravidly, ověřte, že pro nadcházející vyhodnocení pravidel jsou přítomné všechny ADI. Pokud nejsou, najděte je pomocí dotazu na jeden z dostupných zdrojů. 3. Pokud je připojená politika POP, zkontrolujte politiku metody autentizace pomocí koncového bodu IP (Internet Protocol). 4. Pokud je připojená politika POP, zkontrolujte politiku denní doby v POP. 5. Pokud je připojená politika POP, zkontroluje politiku audit-level (úrovně auditu) v POP a proveďte audit rozhodnutí o přístupu, jak je nařízeno. 6. Pokud je připojeno autorizační pravidlo k objektu a uživatel nemá imunitu proti ovlivnění autorizačními pravidly, zkontrolujte politiku autorizačního pravidla. 7. Pokud je pro toto rozhodnutí o přístupu použitá operace externí autorizační služby EAS (external autorization service) nebo trigger POP, vyvolejte vhodné externí autorizační služby. Pokud dojde k selhání vyhodnocení ACL, POP nebo autorizačních pravidel, bude požadavek o přístup odepřen. Externí autorizační služba EAS může přepsat toto rozhodnutí na svoje vlastní, pokud byla takto navržená, nebo by se na rozhodnutí o autorizaci nemusela účastnit vůbec. Všechny ACL, POP nebo autorizační pravidla lze chápat jako politiky. Politiku vyplníte zadáním odpovídajících podmínek přístupu. Po dokončení politiky ji můžete použít u libovolného počtu zdrojů v doméně. Následné změny v politice se automaticky zohlední v celé doméně.
Politiky ACL Politika, která definuje, kdo má přístup k objektu a jaké operace je možné s objektem provádět, je známá jako politika ACL. Každá politika ACL má jedinečné jméno a je možné ji použít u více objektů v doméně. Politika ACL se skládá z jednoho nebo více záznamů, které popisují: v jména uživatelů a skupin, jejichž přístup je explicitně řízen v pro každého uživatele, skupinu, nebo roli povolené specifické operace v povolené specifické operace pro speciální kategorie uživatelů ostatní (any-other) a neautentizovaný (unauthenticated)
Kapitola 3. Administrativa produktu Tivoli Access Manager
35
Použití politik ACL autorizační službou Produkt Tivoli Access Manager spoléhá na politiky ACL při určení podmínek, které musí určitý uživatel splňovat, aby mohl provádět operace s chráněným objektem. Je-li ACL připojen k objektu, záznamy v ACL určují, jaké operace je povoleno provádět s daným objektem a kdo je oprávněn provádět tyto operace. Produkt Tivoli Access Manager používá předvolenou sadu oprávnění, která pokrývá široký rozsah operací. Akce, nebo také oprávnění, jsou představovány jedním abecedním znakem ASCII (a-z, A-Z). Každé oprávnění je zobrazeno (pomocí programu pdadmin nebo rozhraní Web Portal Manager) spolu s označením, které popisuje jím ovládanou operaci. Kromě toho rozhraní Web Portal Manager seskupuje přístupové seznamy podle jejich použití v určité části prostoru objektů (jako např. WebSEAL), nebo jejich použití v celém prostoru objektů (Základní, Generické). Software správce zdrojů běžně obsahuje jednu nebo více operací, které jsou prováděné v chráněných zdrojích. Produkt Tivoli Access Manager vyžaduje na těchto aplikacích, aby volaly nejprve autorizační službu, a teprve pak bude požadovaná operace povolena. Toto volání je prováděno prostřednictvím autorizačního rozhraní API, a to jak pro služby produktu Tivoli Access Manager, tak i pro jiné aplikace. Autorizační služba použije informace obsažené v přístupovém seznamu, aby vytvořila jednoduchou odpověď ano nebo ne na otázku: Má tento uživatel (skupina) oprávnění (například) r, aby mohl ‘zobrazit’ požadovaný objekt? Autorizační služba neví nic o operaci, která vyžaduje oprávnění r. Vše, o co se stará, je přítomnost nebo nepřítomnost oprávnění r v záznamu ACL požadujícího uživatele nebo skupiny. Autorizační služba je zcela nezávislá na operacích, které jsou požadovány. To je proto, aby bylo možné snadno rozšířit výhody autorizační služby na jiné aplikace.
Vyhodnocování ACL Produkt Tivoli Access Manager se řídí určitým vyhodnocovacím procesem, který určí oprávnění udělená určitému uživateli prostřednictvím přístupového seznamu. Pokud porozumíte tomuto procesu, pak můžete určit, jak nejlépe držet nežádoucí uživatele stranou od přístupu ke zdrojům.
Vyhodnocování autentizovaných požadavků Produkt Tivoli Access Manager vyhodnocuje požadavky autentizovaných uživatelů v následujícím pořadí: 1. Spáruje ID uživatele se záznamy uživatele v přístupovém seznamu. Udělená oprávnění jsou ta, která jsou uvedena v odpovídajícím záznamu. Úspěšná shoda: vyhodnocování zde končí. Neúspěšná shoda: pokračujte dalším krokem. 2. Určí skupiny, jejichž členem je uživatel, a spáruje je se záznamy skupiny přístupového seznamu: Odpovídá-li více než jeden záznam skupiny, pak výsledná oprávnění jsou výsledkem logické operace “or” (poskytující maximum oprávnění) pro oprávnění, poskytovaná všemi odpovídajícími záznamy. Úspěšná shoda: vyhodnocování zde končí. Neúspěšná shoda: pokračujte dalším krokem. 3. Udělí oprávnění záznamu any-other (pokud existuje). Úspěšná shoda: vyhodnocování zde končí. Neúspěšná shoda: pokračujte dalším krokem. 4. Implicitní entita any-other existuje, pokud neexistuje záznam přístupového seznamu any-other. Tento implicitní záznam neuděluje žádná oprávnění.
36
IBM Tivoli Access Manager: Base: Administrativní příručka
Úspěšná shoda: nebyla udělena žádná oprávnění. Konec procesu vyhodnocování.
Vyhodnocování neautentizovaných požadavků Produkt Tivoli Access Manager provede hodnocení neautentizovaného uživatele tak, že mu udělí oprávnění ze záznamu přístupového seznamu unauthenticated. Záznam unauthenticated je maska (logická operace “and”) pro záznam any-other, jsou-li určena oprávnění. Oprávnění pro unauthenticated je uděleno pouze tehdy, je-li oprávnění současně i u záznamu any-other. Poněvadž unauthenticated závisí na any-other, má malý význam, aby ACL obsahoval unauthenticated bez any-other. Pokud ACL obsahuje unauthenticated bez any-other, pak předvolenou odpovědí je neudělit žádná oprávnění pro unauthenticated.
Politiky POP Politika POP (protected object policy) uvádí bezpečnostní politiku, která je použitá pro objekt bez ohledu na to, který uživatel nebo operace se provádí. Každá politika POP má jedinečné jméno a lze ji použít pro více objektů v doméně. Cílem politiky POP je zavést podmínky přístupu k objektu na základě doby přístupu a určit, zda by měl být požadavek na přístup monitorován. Konkrétní podmínky, které můžete aplikovat, jsou: v atributy POP, jako je režim varování, úroveň auditu, denní doba přístupu Podrobnější informace najdete v části “Konfigurace atributů politiky POP” na stránce 91. v Politika POP odolnosti autentizace (zvýšení). Podrobnější informace o této politice najdete v části “Politika POP odolnosti autentizace (zvýšení)” na stránce 95. v Politika POP úrovně zabezpečení. Podrobnější informace o této politice najdete v části “Úroveň zabezpečení politiky POP” na stránce 97. v Politika POP autentizace založené na síti. Podrobnější informace o této politice najdete v části “Politika POP autorizace založené na síti” na stránce 93.
Autorizační pravidla Politika autorizačních pravidel uvádí bezpečností politiku, která je použitá pro objekt založený na rozmanitých podmínkách jako kontext a prostředí. Každá politika autorizačních pravidel má jedinečné jméno a lze ji použít pro více objektů v doméně. Stejně jako ACL a POP, autorizační pravidla jsou definovaná, aby uváděla podmínky, které musí být splněné před povolením přístupu k chráněnému objektu. Autorizační pravidlo se vytvoří s použitím množství podmínek, které se zakládají na datech poskytnutých autorizačnímu jádru v uživatelském pověření z aplikace správce zdrojů nebo z obklopujícího obchodního prostředí. Tyto podmínky se vyhodnotí jako výraz Boolean, aby bylo zjištěno, má-li být přístup k objektům udělený nebo odepřený. Jazyk autorizačních pravidel vám umožňuje práci s komplexními strukturovanými daty. Můžete prověřit hodnotu v datech pravidel a vytvořit informované rozhodnutí o přístupech. Data použitá v rozhodnutí o přístupu lze definovat staticky v systému nebo v průběhu obchodního procesu. Pravidla vám poskytují flexibilitu politiky definované externí autorizační službou, aniž byste požadovali rozvoj či výstavbu logiky externí autorizační služby do sdíleného plug-inu knihovny. Kapitola 3. Administrativa produktu Tivoli Access Manager
37
Jak se autorizační pravidla liší od politik ACL a POP Politiky ACL nesou danou předdefinovanou sadu operací a kontrolují, kteří uživatelé a skupiny mají oprávnění provádět tyto operace v chráněném objektu. Například, schopnost uživatele číst data vztahující se k objektu je buď udělená nebo odepřená politikou ACL. Politiky POP se týkají všech uživatelů a skupin a kontrolují podmínky, které jsou specifické pro daný chráněný objekt. Například, denní doba přístupu vylučuje všem uživatelům a skupinám přístup k objektu mimo časy nastavené v politice denní doby. Pravidla vám umožňují provádět rozhodnutí založená na atributech osoby nebo objektu a na kontextu a prostředí obklopující rozhodnutí o přístupu. Například, pravidlo můžete použít pro dokončení politiky denní doby, která závisí na uživateli a skupině. Pravidlo můžete použít také pro rozšíření schopností přístupového ovladače, které poskytují politiky ACL tak, že dokončí více rozšířených politik jako je jedna založená na přidělené kapacitě. Zatímco politika ACL uděluje skupině povolení zapisovat do zdroje, pravidlo může jít o krok dál a umožní vám zjistit, překročila-li skupina určitou přidělenou kapacitu pro daný týden dříve, než bylo této skupině uděleno oprávnění zapisovat do zdroje.
Kdy používat autorizační pravidla V procesu autorizace Tivoli Access Manager musí všechny tři objekty politik–ACL, POP a autorizační pravidla–povolovat přístup k chráněnému objektu dříve, než je k tomuto objektu udělen přístup. Autorizační pravidla poskytují flexibilitu potřebnou k rozšíření ACL nebo POP přizpůsobením bezpečnostní politiky vašim potřebám. Přestože lze autorizační pravidla použít pro rozšíření politiky dokončené jiným typem politiky Tivoli Access Manager, nejsou zde pouze rozšíření existujících typů politik. Autorizační pravidlo je typ politiky, který je dostatečně bohatý na funkčnost, aby mohl nahradit politiky ACL a POP. Avšak použití politik ACL a POP všeobecně poskytuje lepší výkon. Proto pro doplnění těchto politik použijte pravidlo místo jejich nahrazení.
Pokyny pro zabezpečení prostoru objektů Níže uvedené pokyny jsou vhodné pro zabezpečení prostoru objektů: v Nastavte nejvyšší úroveň bezpečnostní politiky na objektech typu zásobník na vrcholu prostoru objektů. Nastavte výjimky z této politiky pomocí explicitních politik ACL, POP a autorizačních pravidel v objektech, které jsou níže v hierarchii. v Uspořádejte váš prostor chráněných objektů tak, že většina objektů bude chráněná spíše děděnými než explicitními politikami ACL, POP a autorizačními pravidly. Tato jednodušší správa snižuje riziko chyby, která by mohla ohrozit vaši síť. Děděná bezpečnostní politika snižuje údržbu, protože omezuje počet politik ACL, POP a autorizačních pravidel, které musíte udržovat. v Umístěte nové objekty ve stromu do místa, kde mohou dědit odpovídající oprávnění. Uspořádejte váš strom objektů do množiny podstromů, kde každý podstrom bude spravován určitou politikou přístupu. Politiku přístupu pro celý podstrom určíte nastavením explicitních politik ACL, POP a autorizačních pravidel v kořenu tohoto podstromu. v Vytvořte základní sadu politik ACL, POP a autorizačních pravidel a používejte tyto politiky, kdykoli to bude potřeba. Protože politiky ACL, POP a autorizační pravidla jsou definicí jednoho zdroje, libovolná úprava politiky ovlivní všechny objekty vztahující se k politikám ACL, POP nebo autorizačnímu pravidlu. v Ovládejte přístup uživatelů prostřednictvím používání skupin. Je možné, aby se politika ACL skládala pouze ze záznamů skupiny. V politice ACL nejsou požadované záznamy určitého uživatele, pokud lze místo toho uživatele zařadit podle
38
IBM Tivoli Access Manager: Base: Administrativní příručka
kategorií do skupin. Autorizační pravidla lze zapsat také, pokud si přejete uvážit spíše skupinu jednotlivce než specifického jednotlivce. Toto může značně omezit složitost logiky pravidla. Přístup k objektu jednotlivých uživatelů je možné efektivně řídit přidáním uživatelů nebo odstraněním uživatelů z těchto skupin.
Kapitola 3. Administrativa produktu Tivoli Access Manager
39
40
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 4. Předvolená bezpečnostní politika Produkt Tivoli Access Manager zavádí předvolenou bezpečnostní politiku, pomocí které chrání všechny objekty v doméně. Je nastavena sada administrativních uživatelů a skupin a těmto uživatelům a skupinám je udělena předdefinovaná sada oprávnění. V této kapitole je popsána předvolená bezpečnostní politika.
Předvolení administrátoři a skupiny Během instalace produktu Tivoli Access Manager se vytvoří několik důležitých administrativních skupin. Standardně jsou těmto uživatelům a skupinám udělena určitá oprávnění pro řízení a správu všech operací v doméně. (Tato předvolená politika zabezpečení je definovaná přístupovými seznamy (ACL) vytvořenými během konfigurace.) Následující část podrobně popisuje určité role přiřazené ke každému z těchto uživatelů a skupin během instalace, a vysvětluje, jak vytvořit administrátory.
Skupina iv-admin Tato skupina představuje skupinu administrátorů. Všichni členové této skupiny jsou předvolenou politikou považováni za administrátory domény. Z uživatelů můžete snadno udělat administrátory tak, že je přidáte do skupiny iv-admin. Nebezpečí tohoto kroku spočívá ve skutečnosti, že jakmile se uživatel stane členem této skupiny (s předvolenými přístupovými seznamy), tak má tento uživatel v rámci předvolené politiky úplná práva dělat administrativní úkony na libovolném objektu v celém prostoru jmen. Během konfigurace serveru politik se vytvoří administrátor (sec_master) a přidá se do skupiny iv-admin. Kombinace se členstvím ve skupině uděluje administrátorovi sec_master úplná práva pro všechny operace v doméně správy, ale pouze v rámci předvolené politiky. Uživatel sec_master nemá právo spravovat nové skupiny vytvořené mimo předvolenou politiku, pokud není do takové skupiny přidán jako uživatel nebo člen.
Uživatel sec_master Uživatel sec_master se vytvoří při první instalaci a konfiguraci produktu Tivoli Access Manager. Předvolená politika učiní uživatele sec_master členem skupiny iv-admin, a tak mu povolí provádět všechny akce v rámci produktu Tivoli Access Manager. Myslete si, že tento účet je ekvivalentem účtu uživatele root v operačních systémech Unix, nebo účtu uživatele Administrátor v operačních systémech Microsoft Windows.
Skupina ivmgrd-servers Tato skupina obsahuje servery politik a proxy servery politik. Standardně jsou členové této skupiny autorizováni delegovat požadavky na jiné servery produktu Tivoli Access Manager v zastoupení toho, kdo vydal požadavek.
v Administrátor bezpečnostní politiky Administrátor bezpečnostní politiky je zodpovědný za definovaní a organizaci bezpečnostní politiky v doméně. Administrátor musí být schopen vytvořit, upravit a vymazat bezpečnostní politiku. Oprávnění k překročení (T), procházení (b), zobrazení (v), úpravě (m) a vymazání (d) jsou požadovaná ve zdrojích /Management/ACL, /Management/POP a /Management/Rule. Administrátor potřebuje také oprávnění k překročení (T), procházení (b) a zobrazení (v), aby mohl navigovat podstrom chráněných zdrojů, za které je zodpovědný. Navíc administrátor potřebuje schopnost připojovat (a) a odpojovat (a) bezpečnostní politiky od stejného podstromu. Administrátor by měl mít také oprávnění k vynechání POP (B) a vynechání Pravidla (R), aby tak nebyl ovlivněný bezpečnostními politikami, které se týkají všech uživatelů pro stejný podstrom. v Administrátor chráněného zdroje Administrátor chráněného zdroje je zodpovědný za poskytování a odstraňování přístupu uživatele k jednomu nebo více chráněným zdrojům. Tyto úlohy s sebou přinášejí přidávání a odstraňování uživatelů ze skupin, které je mají definované ve vlastnictví, nebo přidávání a odstraňování oprávnění s ohledem na zdroj. Administrátor musí mít oprávnění k překročení (T), procházení( b), zobrazování (v) a přidávání (A) v chráněném zdroji /Management/Groups nebo v individuální skupině, které je definovaná v podstromu /Management/Groups. v Administrátor nasazování Administrátor nasazování je zodpovědný za instalaci a konfiguraci správců zdrojů v doméně. Administrátor musí mít oprávnění pro překročení (T), procházení (b), zobrazení (v), upravení (m) a mazání (d) v chráněném zdroji /Management/Server. Tato oprávnění poskytují schopnost konfigurovat správce zdrojů do a z domény, stejně jako aktualizace jejich konfigurace.
Příklad administrativních politik ACL Následující příklad ukazuje, jak uživatel získá administrativní oprávnění. Níže uvedený přístupový seznam u objektu /WebSEAL dává administrativní práva uživateli adam: user sec_master group iv-admin group webseal-servers group ivmgrd-servers user adam any-other unauthenticated
abcTdmlrx abcTdmlrx gTdmlrx Tl abcTdmlrx Trx Trx
Definice a aplikace bezpečnostní politiky Administrátoři zabezpečení chrání systémové zdroje pomocí definice bezpečnostní politiky. Bezpečnostní politiky se skládají z přístupových seznamů (ACL), politik chráněných objektů (POP) a autorizačního pravidla, které jsou aplikované na zobrazeni objektů systémových zdrojů, které mají být chráněné v prostoru objektů. ACL, POP a autorizační pravidla můžete aplikovat na stejný objekt. Autorizační služba provádí rozhodnutí o autorizaci na základě politik, které jsou připojeny k těmto objektům. Je-li požadovaná operace v chráněném objektu povolená, správce zdrojů zodpovědný za zdroj provede tuto operaci.
42
IBM Tivoli Access Manager: Base: Administrativní příručka
Jedna politika může určit parametry zabezpečení pro mnoho objektů. Kterákoliv změna politik ACL, POP nebo autorizačního pravidla ovlivní všechny objekty, ke kterým je politika připojená.
Přístupový seznam Politika přístupového seznamu, nebo také politika ACL, je sada řízení (oprávnění), která určuje podmínky, které je nezbytné 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 v doméně. Politiky ACL, stejně jako všechny politiky, se používají k označení bezpečnostních standardů organizace ve zdroji představovaném prostorem chráněných objektů. Politika ACL konkrétně řídí: v jaké operace je možné provádět se zdrojem v 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.
Obrázek 14. Politika ACL
Předvolené administrativní politiky ACL Následující předvolené politiky ACL administrativy jsou navrhované pro spouštěcí body pro zabezpečení operací správy v doméně. Můžete přidávat záznamy pro uživatele (user), skupiny (group), záznam typu ostatní (any-other, any-authenticated) a neautentizovaný (unauthenticated), abyste zajistili široký rozsah řízení a přesněji splnili potřeby vašeho prostoru chráněných objektů. Všimněte si uživatelů a skupin v každém přístupovém seznamu, kteří obsahují oprávnění pro řízení (c). Uživatelé a skupiny s oprávněním pro řízení vlastní daný přístupový seznam a mají moc měnit záznamy ACL. Detailní popis oprávnění lze nalézt v části “Předvolená oprávnění (akce) produktu Tivoli Access Manager” na stránce 73.
Předvolená kořenová politika ACL Uživatelé a oprávnění pro předvolený kořenový ACL, default-root, zahrnují: Group iv-admin Any-other Unauthenticated
TcmdbvaBR T T
Kořenový přístupový seznam je skutečně základní – každý může procházet prostorem objektů, ale nikdo nemůže provádět žádné další akce. S největší pravděpodobností ho budete
Kapitola 4. Předvolená bezpečnostní politika
43
chtít změnit. Jednu užitečnou funkci kořenový přístupový seznam však má - může rychle odepřít přístup do celého prostoru objektů určitému uživateli nebo skupině. Představte si, že následující záznam je součástí kořenového ACL: user jan -----------------
Důsledkem tohoto záznamu (který nedává žádná oprávnění) je to, že uživatel user jan nemůže ani projít přes kořenový objekt typu zásobník. Tento uživatel nemůže získat vůbec žádný přístup do prostoru chráněných objektů — bez ohledu na všechna další oprávnění, která mu byla udělena níže ve stromu.
Předvolená politika ACL pro /Management Uživatelé a oprávnění pro ACL pro správu, default-management, zahrnují: Group iv-admin Group ivmgrd-servers Any-other
TcmdbsvaBtNWAR Ts Tv
Při instalaci je tento ACL připojen k objektu typu zásobník /Management v prostoru objektů.
Předvolená politika ACL pro /Replica Uživatelů a oprávnění pro ACL pro správu replikace, default-replica, zahrnují: Group Group Group Group
Předvolená politika ACL pro /Config Uživatelé a oprávnění pro ACL pro správu konfigurace, default-config, zahrnují: Group iv-admin Any-other Unauthenticated
TcmdbsvaBR Tv Tv
Předvolená politika ACL pro /GSO Uživatelé a oprávnění pro ACL pro správu GSO, default-gso, zahrnují: Group iv-admin Any-other Unauthenticated
TcmdbvaBNR Tv Tv
Předvolená politika ACL pro /Policy Uživatelé a oprávnění pro ACL pro správu politik, default-policy, include: Group iv-admin Any-other Unauthenticated
TcmdbvaBNR Tv Tv
Předvolená politika ACL pro /Domain Uživatelé o oprávnění pro ACL pro správu domény, default-domain, zahrnují: Group iv-admin Group ivmgrd-servers
TcmdbvaBNR v
Předvolená politika ACL /Proxy Uživatelé a oprávnění pro ACL pro správu proxy serveru, default-management-proxy, zahrnují: Group iv-admin Group ivmgrd-servers
44
Tcbv Tg
IBM Tivoli Access Manager: Base: Administrativní příručka
Oprávnění správy Oblast správy (Management) prostoru chráněných objektů obsahuje několik objektů typu zásobník týkajících se podřízených oblastí správy (submanagement), které vyžadují specifická nastavení svých oprávnění: v v v v v v v v v v v v v
“Oprávnění /Management/ACL” na stránce 45 “Oprávnění /Management/Action” na stránce 46 “Oprávnění /Management/POP” na stránce 46 “Oprávnění /Management/Server” na stránce 47 “Oprávnění /Management/Config” na stránce 47 “Oprávnění /Management/Policy” na stránce 48 “Oprávnění /Management/Replica” na stránce 48 “Oprávnění /Management/Users” na stránce 48 “Oprávnění /Management/Groups” na stránce 50 “Oprávnění /Management/GSO” na stránce 50 “Oprávnění /Management/Rule” na stránce 51 “Oprávnění /Management/Domain” na stránce 51 “Oprávnění /Management/Proxy” na stránce 52
Následující kritéria bezpečnosti platí pro oblast /Management prostoru chráněných objektů: v Objekt /Management začíná řetěz dědičnosti ACL pro celou oblast /Management prostoru objektů. v Pokud nebudete používat žádný další explicitní přístupový seznam, tento objekt definuje (prostřednictvím dědičnosti) bezpečnostní politiku celého prostoru objektů /Management. v Přístup k objektu /Management a ke všem objektům pod tímto bodem vyžaduje oprávnění pro přechod.
Oprávnění /Management/ACL Tento objekt umožňuje administrátorům provádět úlohy správy přístupových seznamů na vysoké úrovni, které mohou ovlivnit bezpečnostní politiku domény. Operace d
vymazat
Popis Vymazat stávající politiku ACL. pdadmin acl delete
m
upravit
Vytvořit novou politiku ACL. pdadmin acl create
v
zobrazit
Vypsat seznam a vyhledat zobrazení přístupových seznamů. Zobrazit podrobnosti o ACL. Toto oprávnění musí být v záznamu přístupového seznamu připojeného k /Management/ACL. pdadmin acl find pdadmin acl list pdadmin acl show
Příkaz acl find zobrazuje seznam chráněných zdrojů, kde je připojen tento ACL. Musíte mít v těchto objektech zobrazení oprávnění (v) dříve, než si je budete moci zobrazit. Musíte vytvořit záznamy ACL administrátora v politice ACL, která ovlivňuje objekt /Management/ACL. Záznam ACL administrátora může obsahovat libovolné z výše uvedených oprávnění. Tato oprávnění poskytují administrátorovi moc pro vytváření, zobrazování a mazání politik ACL.
Kapitola 4. Předvolená bezpečnostní politika
45
Administrátor ACL nemůže měnit stávající přístupový seznam, pokud v daném ACL neexistuje záznam pro uvedeného administrátora, který obsahuje oprávnění pro řízení (c). Pouze vlastník přístupového seznamu může měnit jeho záznamy. Všimněte si, že tvůrce nové politiky ACL (m v /Management/ACL) se stává prvním záznam v této ACL—s oprávněním TcmdbsvaBIR nastaveným předvolbou. Je-li například záznam administrátora sec_master v přístupovém seznamu default-management s oprávněním m, pak administrátor sec_master může vytvořit novou politiku ACL. Uživatel sec_master se stane prvním záznamem v novém přístupovém seznamu a to s oprávněními TcmdbsvaBIR. Vlastnictví samotné ACL default-management je poskytováno skupině iv-admin předvolbou.
Oprávnění /Management/Action Tento objekt dovoluje administrátorům spravovat přizpůsobené akce a skupiny akcí. Úlohy akcí a přidružená oprávnění zahrnují: Operace d
vymazat
Popis Vymazat stávající akci nebo skupinu akcí. pdadmin action delete pdadmin action group delete
m
upravit
Vytvořit novou akci nebo skupinu akcí. pdadmin action create pdadmin action group create
Poznámka: Následující příkazy nevyžadují žádná speciální oprávnění: pdadmin action list pdadmin action group list
Produkt Tivoli Access Manager poskytuje autorizační služby správci zdrojů. Například, správcové zdrojů, kteří jsou součástí skupiny Tivoli Access Manager zahrnují WebSEAL (pro webové správce zdrojů) a Tivoli Access Manager for Business Integration (pro rychlé posílání zpráv aplikacím). Správcové zdrojů mohou provádět volání do autorizačních služeb přes autorizační API. Tři nezbytné kroky povinné pro začlenění správce zdrojů s autorizací do autorizační služby zahrnují: v Definování prostoru objektů správce zdrojů. v Definování akcí a skupin akcí správců zdrojů. v Použití oprávnění na zdroje (objekty), které potřebují ochranu. Administrátor prostoru objektů správce zdrojů může použít obslužný program pdadmin pro definování nových oprávnění a akcí. Správce zdrojů obvykle definuje akce a skupiny akcí použitelné pro zdroje, které chrání. Administrátor musí mít oprávnění m a d v oblasti Management/Action, pokud chce vytvářet a mazat tato oprávnění nebo akce.
Oprávnění /Management/POP Tento objekt dovoluje administrátorům spravovat politiky chráněných objektů (POP Protected Object Policy). Veškerá oprávnění se musí objevit v záznamech přístupových
46
IBM Tivoli Access Manager: Base: Administrativní příručka
seznamů v oblasti /Management/POP. Úlohy akcí a přidružená oprávnění zahrnují: Operace d
vymazat
Popis Vymazat politiku POP. pdadmin pop delete
m
upravit
Vytvořit politiky POP a změnit atributy politiky POP. pdadmin pop create pdadmin pop modify
v
zobrazit
Vyhledat a vypsat seznam politik POP a zobrazit podrobnosti politiky POP. pdadmin pop find pdadmin pop list pdadmin pop show
B
vynechat POP
Potlačuje politiku POP připojenou k objektu.
Příkaz pop find zobrazuje seznam chráněných zdrojů, kde jsou připojené tyto ACL. Musíte mít v těchto objektech zobrazení oprávnění (v) dříve, než si je budete moci zobrazit.
Oprávnění /Management/Server Objekt typu zásobník /Management/Server prostoru chráněných objektů dovoluje administrátorům provádět úlohy správy serveru (mají-li nastavena odpovídající oprávnění). Ovladače správy serverů jsou použité pro určení, zda uživatel má oprávnění k zobrazování konfigurovaných správců zdrojů, dále pro iniciaci replikace pro jeden nebo více správců zdrojů a pro aktivaci funkcí běhového trasování za správce zdrojů. Správci zdrojů se stanou dostupnými v seznamu správců zdrojů poté, co byli konfigurovaní v doméně. Správci zdrojů jsou po konfiguraci odstranění. Zobrazitelné informace o správcích zdrojů obsahují informace, které umožňují jiným serverům Tivoli Access Manager, obzvláště serveru politik (pdmgrd), zjistit umístění a komunikovat s daným serverem. Operace s
server
Popis Replikovat autorizační databázi. pdadmin server replicate
v
zobrazit
Vypsat zaregistrované servery a zobrazit vlastnosti serveru. pdadmin server list pdadmin server show
t
trasovat
Povolit dynamické trasování nebo administrativu statistik. pdadmin server task jméno_serveru trace pdadmin server task jméno_serveru stats
Oprávnění /Management/Config Objekt typu zásobník /Management/Config prostoru chráněných objektů dovoluje administrátorům provádět úlohy týkající se správy konfigurace (mají-li nastavena odpovídající oprávnění). Ovladače správy konfigurace jsou použité pro určení, jestli má uživatel oprávnění pro konfiguraci, zrušení konfigurace a aktualizaci konfigurace správce zdrojů.
Kapitola 4. Předvolená bezpečnostní politika
47
Definice serveru je vytvořená pro daného správce zdrojů (jako je WebSEAL) nebo autorizační server(pdacld) jako součást procesu konfigurace. Definice pro server se smaže, pokud zrušíte konfiguraci serveru. Definice serveru obsahují informace, které dovolují dalším serverům Tivoli Access Manager, zejména serveru politik (pdmgrd) nalézt daný server a navázat s ním komunikaci. Operace m
upravit
Popis Konfigurace do domény. svrsslcfg -config svrsslcfg -modify
d
vymazat
Odkonfigurování. svrsslcfg -unconfig
Oprávnění /Management/Policy Objekt typu zásobník /Management/Policy prostoru chráněných objektů dovoluje administrátorům autorizovat příkazy policy get a policy set (mají-li nastavena odpovídající oprávnění). Operace
Popis
v
zobrazit
Vyžadováno operacemi policy get.
m
upravit
Vyžadováno operacemi policy set.
Oprávnění /Management/Replica Objekt typu zásobník /Management/Replica prostoru chráněných objektů řídí replikaci autorizační databáze. Řízení tohoto objektu na vysoké úrovni ovlivňuje operace serveru politik a správců zabezpečení v doméně. Ovladače správy replikace jsou použité pro určení, kteří správci zdrojů dostanou povolení pro stahování hlavní autorizační databáze politik do svých lokálních systémů souborů. Ovladače a přidružená oprávnění zahrnují: Operace v
zobrazit
Popis Číst hlavní autorizační databázi.
Všem serverům Tivoli Access Manager, které udržují lokální replikaci autorizační databáze, která zahrnuje všechny správce zdrojů a autorizační servery, musí být uděleno oprávnění pro zobrazování (v) v objektu /Management/Replica. Proces replikace vyžaduje, aby těmto procesům bylo dovoleno zobrazovat a přistupovat k záznamům mimo hlavní databázi politik autorizace. Instalace produktu Tivoli Access Manager automaticky udělí oprávnění pro čtení všem serverům, které vyžadují přístup do databáze politik autorizace. Když se správce zdrojů konfiguruje do domény, je automaticky přidaný jako člen skupiny ivacld-servers. Této skupině je dle předvolby uděleno oprávnění pro stahování hlavní autorizační databáze politik.
Oprávnění /Management/Users Tento objekt dovoluje administrátorům spravovat účty uživatelů. Úlohy akcí a přidružená oprávnění zahrnují:
48
IBM Tivoli Access Manager: Base: Administrativní příručka
Operace d
vymazat
Popis Vymazat účet uživatele. pdadmin user delete
m
upravit
Upravit podrobnosti o účtu uživatele. pdadmin pdadmin pdadmin pdadmin
Vytvořit nového uživatele a volitelně ho přiřadit do jedné nebo více skupin. Naimportovat data skupiny z registru uživatelů. pdadmin user create pdadmin user import
v
zobrazit
Vypsat účty uživatelů a zobrazit podrobnosti o účtu uživatele. pdadmin pdadmin pdadmin pdadmin pdadmin pdadmin
W
heslo
user user user user user user
list list-dn list-gsouser show show-dn show-groups
Znovu nastavit a potvrdit heslo uživatele. pdadmin user modify password pdadmin user modify password-valid
Oprávnění pro heslo (W) umožňuje vynulování hesla a je poskytováno administrátorům helpdesku, takže mohou pomáhat uživatelům, kteří zapomněli své heslo. Toto oprávnění dovoluje administrátorovi, aby znovu nastavil zapomenuté heslo a pak použil příkaz user modify password-valid, aby nastavil platnost hesla na hodnotu no. Tímto způsobem umožní uživateli, aby se přihlásil, a současně uživatele donutí, aby okamžitě použil nové heslo. Všimněte si, že nastavením user modify password-valid na hodnotu no u daného uživatele neoznačíte, zda je heslo neplatné z důvodu uplatnění politiky max-password-age, což je globálním nastavením. Příkaz politiky set max-password-age nastaví maximální dobu, za kterou dojde k ukončení platnosti hesla. Schopnost administrátorů spravovat všechny účty uživatelů je ovládaná oprávněními v objektu /Management/Users. Například, vlastní-li administrátor oprávnění pro zobrazování (v) v objektu /Management/Users, je schopen zobrazit si informace o všech uživatelích. Abyste omezili rozsah řízení administrátora na určitou skupinu uživatelů, odstraňte oprávnění administrátora z objektu /Management/Users a použijte oprávnění na objekt /Management/Groups vztahující se ke skupině, která má být spravovaná místo toho. Například, je-li administrátorovi poskytnuto oprávnění pro zobrazování (v) v objektu /Management/Groups/Accounting, je schopen si zobrazit informace o uživatelích ve skupině Accounting. Má-li administrátor oprávnění pro zobrazování (v) do libovolné skupiny, ve které je uživatel členem, je schopen si zobrazit informace o tomto uživateli. Přidání oprávnění pro zobrazování (v) do samotného objektu /Management/Groups umožní administrátorovi zobrazit si informace o libovolném uživateli, který je členem dané skupiny. Přístup udělený objektem /Management/Users potlačuje veškerá omezení přístupu politiky ACL “delegované administrativy” pod objektem /Management/Groups/jméno_skupiny. Podrobnější informace o delegování administrativy najdete v části Kapitola 16, “Delegovaná administrativa”, na stránce 155.
Kapitola 4. Předvolená bezpečnostní politika
49
Oprávnění /Management/Groups Tento objekt dovoluje administrátorům spravovat skupiny a členství ve skupinách. Úlohy akcí a přidružená oprávnění zahrnují: Oprávnění d
Operace vymazat
Popis Vymazat skupinu. pdadmin group delete
m
upravit
Upravit popis skupiny. Odstranit jednoho nebo více uživatelů, kteří jsou členy skupiny. pdadmin group modify description pdadmin group modify remove
N
vytvořit
Vytvořit novou skupinu. Naimportovat data skupiny z registru uživatelů. pdadmin group create pdadmin group import
v
zobrazit
Vypsat seznam skupin a zobrazit podrobnosti o skupině. pdadmin pdadmin pdadmin pdadmin pdadmin
A
přidat
group group group group group
list list-dn show show-dn show-members
Přidat jednoho nebo více uživatelů do skupiny. pdadmin group modify add
Oprávnění pro přidání (A) je požadované ve vašem záznamu do ACL ve skupině, aby vám bylo umožněno přidávat existující uživatele do vaší skupiny. Použijte příkaz pdadmin user create (který požaduje oprávnění N), abyste vytvořili nové uživatele a volitelně je umístili do jedné nebo více existujících skupin. Schopnost přidávat stávající uživatele do vaší skupiny je skutečně mocná, protože vlastník skupiny ovládá všechny uživatele své skupiny. Pokud vy, jako vlastník skupiny, máte také oprávnění pro vymazání (d), pak můžete také daného uživatele vymazat z celé domény. Schopnost administrátora spravovat všechny skupiny je řízená oprávněním v objektu /Management/Groups. Například, má-li administrátor oprávnění pro mazání (d) v objektu /Management/Groups, je schopen mazat libovolné skupiny. Abyste omezili rozsah moci administrátora na určitou skupinu, použijte místo toho oprávnění na objekt vztahující se ke skupině. Například, je-li administrátorovi uděleno oprávnění pro mazání (d) v objektu /Management/Groups/Travel/Europe, je schopen vymazat danou skupinu. Podobně, je-li administrátorovi uděleno oprávnění pro mazání (d) v zásobníku objektu /Management/Groups/Travel, je schopen mazat libovolné skupiny v zásobníku objektu. Oprávnění v objektech /Management/Groups jsou také ovlivněné schopností administrátora spravovat uživatele, kteří jsou členy těchto daných skupin. Tím, že poskytnete administrátorovi oprávnění pro mazání (d) v skupině, umožníte mu mazat uživatele, kteří jsou členem té skupiny. Podobně, má-li administrátor oprávnění pro zobrazování (v), může si zobrazit informace o uživatelích vztahující se k této skupině.
Oprávnění /Management/GSO Objekt typu zásobník /Management/GSO prostoru chráněných objektů dovoluje administrátorům provádět úlohy týkající se správy globálního přihlášení (GSO - Global Sign-On) (mají-li nastavena odpovídající oprávnění).
50
IBM Tivoli Access Manager: Base: Administrativní příručka
Operace N
vytvořit
Popis pdadmin rsrc create pdadmin rsrcgroup create pdadmin rsrccred create (Všechny výše uvedené příkazy vyžadují také oprávnění m)
d
vymazat
pdadmin rsrc delete pdadmin rsrcgroup delete pdadmin rsrccred delete (Všechny výše uvedené příkazy vyžadují také oprávnění m)
m
upravit
pdadmin rsrcgroup modify pdadmin rsrccred modify
v
zobrazit
pdadmin pdadmin pdadmin pdadmin pdadmin pdadmin
rsrc list rsrcgroup list rsrccred list rsrc show rsrcgroup show rsrccred show
Oprávnění /Management/Rule Tento objekt umožňuje administrátorům spravovat politiky autorizačních pravidel. Všechna oprávnění se musí objevit v záznamech v ACL v /Management/Rule. Úlohy akcí a přidružená oprávnění zahrnují: Operace
Vytvoření autorizačního pravidla a úprava atributů autorizačního pravidla. pdadmin authzrule create pdadmin authzrule modify
v
zobrazit
Nalezení seznamu autorizačních pravidle a zobrazení podrobností autorizačních pravidel. pdadmin authzrule find pdadmin authzrule list pdadmin authzrule show
Příkaz authzrule find zobrazí seznam chráněných zdrojů, ke kterým je připojeno pravidlo. Musíte mít oprávnění pro zobrazení (v) k těmto chráněným zdrojům, abyste si je mohli zobrazit.
Oprávnění /Management/Domain Objekt zásobníku /Management/Domain prostoru chráněných objektů umožňuje administrátorům vykonávat úlohy správy domén (jsou-li nastavená odpovídající oprávnění). Operace m
upravit
Popis pdadmin domain create pdadmin domain modify
Kapitola 4. Předvolená bezpečnostní politika
51
Operace
Popis
v
zobrazit
pdadmin domain list pdadmin domain show
d
vymazat
pdadmin domain delete
Oprávnění /Management/Proxy Objekt typu zásobník /Management/Proxy prostoru chráněných objektů dovoluje administrátorům nebo správcům zdrojů provádět úlohy delegované správy (mají-li nastavena odpovídající oprávnění). Operace g
delegování
Popis Umožňuje administrátorům a správcům zdrojům jednat jménem uvedených pověření.
Řídký model bezpečnostní politiky Abyste zabezpečili prostředky v síti v prostoru chráněných objektů, každý objekt musí být chráněný bezpečnostní politikou. Přiřadit bezpečnostní politiku k objektu můžete dvěma způsoby: v Připojit explicitní bezpečnostní politiku v objektu. v Umožnit objektu převzít svou bezpečnostní politiku z předcházejícího objektu zásobníku v hierarchii. Adopce převzatého schématu zabezpečení může hodně omezit úlohy administrátora pro doménu. Tato sekce se zabývá koncepty převzatých nebo řídkých bezpečnostních politik.
Dědičnost bezpečnostních politik Síla dědičnosti bezpečnostních politik je založená na tomto principu: libovolný objekt bez explicitně připojené bezpečnostní politiky dědí politiku ze svého nejbližšího objektu typu zásobník s explicitně nastavenou bezpečnostní politikou. Jinými slovy, všechny objekty bez explicitně připojené bezpečnostní politiky je dědí z objektů typu zásobník s explicitně připojenými bezpečnostními politikami. Určitý řetězec dědičnosti se přeruší, když explicitní bezpečnostní politiku připojíte k objektu. Dědičnost bezpečnostních politik ulehčuje úlohu nastavení a údržby přístupových ovladačů ve velkých prostorách chráněných objektů. V typickém prostoru objektů potřebujete připojit pouze několik ACL na klíčová místa, abyste zabezpečili celý prostor objektů; nazývá se tedy řídký model bezpečnostní politiky. Typický prostor objektů začíná jednoduchou explicitní bezpečnostní politikou připojenou k objektu typu zásobník root. Kořenový přístupový seznam musí vždy existovat a nemůže být nikdy vymazán. Obvykle má tento přístupový seznam velmi malá omezení. Všechny objekty umístěné v prostoru objektů pod tímto objektem dědí uvedený přístupový seznam. Jsou-li pro oblast nebo podstrom prostoru objektů potřebná různá omezení přístupových ovladačů, připojíte explicitní bezpečnostní politiku ke kořenu daného podstromu. Toto přeruší tok děděných bezpečnostních politik z primárního prostoru objektů root do podstromu. Nový řetězec dědičnosti začíná z této nově vytvořené explicitní bezpečnostní politiky.
52
IBM Tivoli Access Manager: Base: Administrativní příručka
Předvolená kořenová politika ACL Produkt Tivoli Access Manager kontroluje dědičnost počínaje kořenem prostoru chráněných objektů. Pokud explicitně nenastavíte přístupové seznamy na jiných objektech ve stromové struktuře, pak celý strom zdědí tento kořenový přístupový seznam. Ke kořeni prostoru chráněných objektů je vždy připojena explicitní politika ACL. Administrátor může nahradit tento přístupový seznam jiným přístupovým seznamem, který bude obsahovat jiné záznamy a nastavení oprávnění. Ale kořenový přístupový seznam není možné nikdy úplně odstranit. Politika kořenového ACL je explicitně nastavena během výchozí instalace a konfigurace produktu Tivoli Access Manager. Uživatelé a oprávnění pro předvolené kořenové ACL — default-root — zahrnují: Group iv-admin Any-other Unauthenticated
TcmdbvaB T T
Oprávnění pro řízení (c) Oprávnění pro řízení je mocné oprávnění, které vám umožňuje vlastnit politiku ACL. Oprávnění pro řízení vám dovoluje měnit záznamy v přístupovém seznamu. To znamená, že máte moc vytvářet záznamy, mazat záznamy, udělovat oprávnění a odebírat oprávnění. Administrátor, který chce odstranit ACL ze seznamu politik ACL, musí mít záznam v tomto ACL a v tomto záznamu musí mít nastaveno oprávnění pro řízení. Oprávnění pro řízení vám dovoluje udělit moc administrátora jinému uživateli, stejně jako schopnost připojit (a) tento přístupový seznam k objektům. Oprávnění pro řízení musíte používat velmi opatrně, neboť jde o prostředek s opravdu mocnými vlastnostmi.
Oprávnění pro přechod (T) Řízení přístupu produktu Tivoli Access Manager závisí na dvou podmínkách. v Přístupový seznam, který řídí požadovaný objekt, musí obsahovat odpovídající přístupová oprávnění pro požadujícího uživatele. v Požadovaný objekt musí být přístupný požadujícímu uživateli. Přístupnost chráněných objektů je řízena oprávněním pro přechod (T). Oprávnění pro přechod se používá pouze u objektů typu zásobník v prostoru chráněných objektů. Oprávnění pro přechod určuje, že uživatel (user), skupina (group), ostatní (any-other) nebo neautentizovaný (unauthenticated) uživatel uvedený v odpovídajícím záznamu přístupového seznamu má oprávnění projít tímto objektem typu zásobník, aby získal přístup k objektu chráněného zdroje v nižší úrovni hierarchie. Všimněte si, že pro uživatele nejsou definovaná žádná oprávnění, uživatel nemůže přenést ani kořenový objekt typu zásobník. Tento uživatel nemůže opět vytvořit přístup do všech prostorů chráněných objektů bez ohledu na jakákoliv oprávnění, která by mohla být udělená níže ve stromu. Chráněný objekt je žadateli přístupný, pokud žadatel vlastní oprávnění pro přechod pro každý přístupový seznam připojený k objektům typu zásobník v hierarchii nad požadovaným zdrojem směrem ke kořeni a včetně kořene. Obrázek 15 na stránce 54 ukazuje, jak oprávnění pro přechod pracuje. Ve společnosti ABCD je objekt typu zásobník (adresář) s názvem Technici, který také obsahuje objekt typu zásobník (podadresář) s názvem TechPublikace. Uživatel Kateřina - člen prodejního Kapitola 4. Předvolená bezpečnostní politika
53
oddělení - potřebuje přejít do adresáře Technici/TechPublikace, aby si prohlédl soubor s poznámkami k vydání. Administrátor poskytl oprávnění pro přechod uživateli typu any-other v kořeni prostoru objektů. Dále administrátor udělil oprávnění pro přechod skupině obchodníků (group sales) pro adresář Technici. Adresář TechPublikace zdědil přístupový seznam z adresáře Technici. Přestože Kateřina nemá žádná další oprávnění k těmto dvěma adresářům, může projít (přejít) přes tyto adresáře, aby přistoupila k souboru info_o_vydání. Jelikož tento soubor má oprávnění pro čtení pro uživatele Kateřina (user katerina), může si také tento soubor prohlédnout.
Obrázek 15. Oprávnění pro přechod
Přístup k hierarchii pod daným objektem typu zásobník můžete omezit snadno, aniž byste museli znovu nastavovat jednotlivá oprávnění k těmto objektům. Jednoduše odstraňte oprávnění pro přechod z odpovídajícího záznamu přístupového seznamu. Odstraněním oprávnění pro přechod z adresářového objektu chrání všechny objekty níže v hierarchii, i když tyto objekty obsahují méně omezující přístupové seznamy. Například pokud skupina group obchodnici nebude mít oprávnění pro přechod pro adresář Technici, pak Kateřina nebude moci přistupovat k souboru s informacemi o vydání, přestože má oprávnění číst tento soubor.
Vyřešení požadavku na přístup Dědičnost začíná u kořenového přístupového seznamu a ovlivňuje všechny objekty v prostoru objektů, dokud nenarazí na objekt s explicitně nadefinovaným přístupovým seznamem. Od tohoto bodu se začne vytvářet nový řetěz dědičnosti. Objekty pod explicitně nastaveným přístupovým seznamem dědí nová řízení přístupu. Pokud odstraníte explicitní přístupový seznam, řízení přístupu se pro všechny objekty vrátí zpět k nejbližšímu adresáři nebo objektu typu zásobník s explicitně nastaveným přístupovým seznamem. Když se uživatel pokusí přistoupit k zabezpečenému objektu (jako např. webovému dokumentu), produkt Tivoli Access Manager zkontroluje, zda má uživatel oprávnění přistupovat k danému objektu. To provede tak, že zkontroluje všechny objekty v hierarchii objektů, zda jejich zděděná anebo explicitně nastavená oprávnění jsou odpovídající.
54
IBM Tivoli Access Manager: Base: Administrativní příručka
Uživateli je přístup k objektu odepřen, pokud kterýkoli adresář nebo objekt typu zásobník v hierarchii nad daným objektem neobsahuje oprávnění pro přechod pro daného uživatele. Přístup je dále odepřen tehdy, pokud cílový objekt nemá dostatečná oprávnění provádět požadovanou operaci. Pokud žadatel chce projít kontrolou přístupu, pak musí mít následující oprávnění: v Oprávnění procházet cestou k požadovanému objektu. v Odpovídající oprávnění na požadovaném objektu. Následující příklad demonstruje proces, jak je řešeno, zda uživatel může číst (prohlížet si) daný objekt: /abcd/technici/projekt_Y/aktuální/report.html
Produkt Tivoli Access Manager zkontroluje následující: v Oprávnění pro přechod v explicitně nastaveném kořenovém přístupovém seznamu (/). v Oprávnění pro přechod ve všech explicitně nastavených přístupových seznamech připojených k adresářům: abcd, technici, projekt_Y a aktuální. v Oprávnění ke čtení pro vlastní soubor (report.html). Uživateli je přístup odepřen, pokud kontrola přístupu uživatele selže ve kterémkoliv z těchto bodů v průběhu procházení celou hierarchií objektů.
Použití politik ACL na různé typy objektů V politice ACL je možné nastavit různé typy operací. Pouze určitá podmnožina těchto možných operací může být použitelná pro určitý objekt, ke kterému se přístupový seznam připojí. Toto chování je svázáno se dvěma vlastnostmi produktu Tivoli Access Manager, které byly navrženy s cílem usnadnit administrativu: v Politiky ACL v Dědičnost ACL Politiky ACL vám umožňují připojit stejnou definici ACL k více objektům v prostoru chráněných objektů. Definice ACL se skládají z tolika záznamů, aby splňovaly požadavky všech objektů, u kterých se bude daný přístupový seznam používat. Každý jednotlivý objekt však může používat pouze několik záznamů. V modelu dědičnosti ACL každý objekt bez vlastní explicitně připojené politiky ACL “dědí” definice politiky z nejbližšího ACL použitého u objektu výše v hierarchii. Stručně řečeno, politika ACL musí popisovat nezbytná oprávnění pro všechny typy objektů, které ji budou používat — a ne pouze pro objekt, ke kterému je připojena.
Příklad dědičnosti politiky ACL Obrázek 16 na stránce 56 zobrazuje vliv směsi děděných a explicitních přístupových seznamů na prostor objektů společnosti. Prostor objektů společnosti má obecnou bezpečnostní politiku nastavenu na kořenovém objektu. Za kořenem následuje objekt typu zásobník s názvem /WebSEAL a individuálně řízené podstromy jednotlivých oddělení. V tomto příkladu je skupině obchodnici dáno vlastnictví podstromu jejich oddělení. Všimněte si, že přístupový seznam pro tento podstrom již neuznává typy záznamů unauthenticated nebo any-other. Kapitola 4. Předvolená bezpečnostní politika
55
Soubor ytd.html (Year-to-Date) má explicitně nastavený přístupový seznam, který uděluje oprávnění pro čtení členům skupiny obchodnici-vp (jejíž členové jsou také členy skupiny obchodnici). Poznámka: Toto schéma ACL nemusí být změněno přidáním nebo odečtením uživatelů na úrovni domény. Noví uživatelé jsou jednoduše přidáni do odpovídajících skupin. Podobně je možné uživatele jednoduše z těchto skupin odstranit.
Obrázek 16. Příklad dědičnosti ACL
Politiky chráněného objektu 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. Na rozdíl od politik ACL, politiky POP obsahují další podmínky na požadavky, které jsou odeslané zpět do Base Tivoli Access Manager a současně do správce zdrojů s rozhodnutím politiky ACL yes a autorizační služby. Produkt Tivoli Access Manager a správce zdrojů jsou odpovědni za to, že vynutí splnění podmínek politiky POP. Níže jsou uvedeny dostupné atributy politiky POP: Vynucovány produktem Tivoli Access Manager Base Atribut POP
56
Popis
Jméno
Jméno politiky. Toto je vydáno do proměnné jméno-pop v online příkaze pdadmin pop.
Popis
Text popisující politiku. Ten se zobrazí v příkazu pdadmin pop show.
Režim varování
Poskytuje administrátorům způsoby jak testovat ACL, POP a autorizační pravidla.
IBM Tivoli Access Manager: Base: Administrativní příručka
Vynucovány produktem Tivoli Access Manager Base Atribut POP
Popis
Ú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.
Politika autentizace koncového bodu IP
Určuje požadavky autentizace na přístup členů z externích sítí.
Atributy spouštěcího impulsu EAS
Určuje plug-in program externí autorizační služby EAS (External Authorization Service), která bude vyvolána, aby provedla rozhodnutí o autorizaci pomocí logiky politiky realizované zákazníkem.
Vynucovány správcem zdrojů (jako např. WebSEAL nebo jiné procesy blade) Atribut POP
Popis
Úroveň zabezpečení
Určuje úroveň ochrany dat: none, integrity, privacy.
Politika autentizace koncového bodu IP
Určuje požadavky autentizace na přístup členů z externích sítí.
Koncept děděného, nebo řídkého modelu ACL, který je popsán v části “Řídký model bezpečnostní politiky” na stránce 52, platí stejným způsobem i pro politiky POP.
Autorizační pravidla Politika autorizačních pravidel uvádí bezpečnostní politiku, která se vztahuje k objektům založeným na různých podmínkách jako kontext a prostředí. Každá politika autorizačního pravidla má jedinečné jméno a lze ji aplikovat na více objektů v doméně. Jako politiky ACL a POP, autorizační pravidla jsou definována, aby uváděla podmínky, které musí být splněné, než je povolený přístup do chráněného objektu. Pravidlo je vytvořené s použitím množství booleovských podmínek, které jsou založené na datech poskytovaných do autorizačního jádra v pověření uživatele ze správce zdrojů nebo z obklopujícího obchodního prostředí. Jazyk autorizačního pravidla umožňuje zákazníkům pracovat se složitými, strukturovanými daty tím, že prověří hodnoty v těchto datech a informují rozhodnutí o připojení. Tato informace může být definovaná staticky v systému nebo v průběhu obchodního procesu. Pravidla mohou být použitá také pro zavedení rozložitelné autorizační politiky založené na atributech s použitím atributů v obchodním prostředí nebo atributech z důvěryhodných externích zdrojů. Pravidlo je uložené jako textové pravidlo v objektu politiky pravidla a připojené k chráněnému objektu stejným způsobem a se stejnými omezeními jako politiky ACL a POP.
Kapitola 4. Předvolená bezpečnostní politika
57
58
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 5. Správa domény Administrátor může v doméně správy vytvořit další domény. Doméně je dáno jedinečné jméno a administrátor domén musí uvést, kdy byla doména poprvé vytvořená. Administrátoři domén mohou provádět úlohy administrativy pouze ve svých vlastních doménách a nemají oprávnění provádět úlohy v jiných doménách. V doméně lze vytvořit uživatele, skupiny a další objekty. Uživatelé a skupiny jsou pro své domény specifické a není jim povoleno vytvářet přístup ke zdrojům obsaženým v jiných doménách. Pokud jsou uživatelé a skupiny vytvořeni mimo produkt Tivoli Access Manager, tito mohou být importováni do jiné domény. Zdroje jsou definované, kontrola přístupu pro zdroje chráněné produktem Tivoli Access Manager je udržovaná na bázi domén a nelze je sdílet mezi doménami.
Vytvoření domény K doméně správy lze vytvořit libovolný počet dodatečných domén. Pouze jeden administrátor, který je připojený k doméně správy, je oprávněný k tvoření domén. Doménu může vytvořit pouze administrátor s odpovídajícími privilegii v doméně správy. Abyste vytvořili doménu používající Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do domény správy jako administrátor domén.
Web Portal Manager Abyste vytvořili doménu používající Web Portal Manager: 1. Přihlaste se do domény správy. 2. Klepněte na Secure Domain (Zabezpečená doména)→ Create Secure Domain (Vytvořit zabezpečenou doménu). 3. Zapište Secure Domain Name (Jméno zabezpečené domény), kterou chcete vytvořit (například, Domain-ABC). Toto pole je povinné. Omezení pro jméno domény: v Omezení na délku 64 znaků. v Může obsahovat a–z, A–Z, 0–9, mezislovní pomlčku ( - ), podtržítko ( _ ), tečku ( . ), zavináč ( @ ) nebo ampersand ( & ). v Může obsahovat libovolný znak z dvoubajtové znakové sady. 4. Zapište Description (Popis) domény jako například: Test Domain. 5. Zapište New Domain Administrator Id (ID nového administrátora domény) (například, myadmin_id). Toto pole je povinné. Poznámka: Musíte vytvořit ID administrátora pro doménu. 6. Zapište New Administrator Password (Nové heslo administrátora) (například, 12A345). Hesla musí odpovídat politikám hesel nastaveným administrátorem domény. Toto pole je povinné. 7. Zapište znova heslo v Confirm Password (Potvrdit heslo). Toto pole je povinné. 8. Klepněte na tlačítko Create (Vytvořit). Abyste se mohli přihlásit do vámi právě vytvořené domény používající Web Portal Manager:
1. z přihlašovací obrazovky, zapište jméno domény, kterou jste právě vytvořili. Předvolené jméno domény je Default (Předvolba). 2. Zapište ID uživatele, který byl vytvořený pro tuto doménu. Předvolené ID uživatele je sec_master. 3. Zapište heslo vztahující se k ID uživatele.
pdadmin Abyste vytvořili doménu používající obslužný program pdadmin, přihlaste se do domény správy a použijte příkaz pdadmin domain create (vytvořit doménu pdadmin). Například, abyste vytvořili doménu pojmenovanou Domain-ABC, zadejte na jeden řádek následující: domain create Domain-ABC myadmin_id 12A345 -desc "Test Domain"
Například, aby se mohl administrátor myadmin_id interaktivně přihlásit do domény Domain-ABC používající příkaz pdadmin login (přihlášení pdadmin), zadejte: pdadmin login -a myadmin_id -p 12A345 -d Domain-ABC
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Výpis domén Abyste zobrazili výpis domén, kromě domény správy, používající Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do domény správy jako administrátor domén. Pouze jeden administrátor, který je připojený k doméně správy, je oprávněný k zobrazování výpisu domén. Administrátor musí vlastnit odpovídající privilegia, aby mohl zobrazit výpis domén bez domény správy.
Web Portal Manager Abyste zobrazili všechny domény, kromě domény správy, používající Web Portal Manager: 1. Přihlaste se do domény správy. 2. Klepněte na Secure Domain (Zabezpečená doména)→ List Secure Domain (Výpis zabezpečených domén). Okno Manage Secure Domains (Správa zabezpečených domén) zobrazuje všechna jména domén, kromě domény správy, jako odkazy. Navíc, můžete filtrovat jména domén, abyste zobrazili pouze ta, která splňují vámi uvedená kritéria.
pdadmin Abyste zobrazili všechny domény, kromě domény správy, používající obslužný program pdadmin, přihlaste se do domény správy a použijte příkaz pdadmin domain list. pdadmin sec_master> domain list
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Výmaz domén Pouze administrátor, který je připojení do domény správy, je oprávněný mazat domény. Doménu může smazat pouze administrátor s odpovídajícími privilegii v doméně správy.
60
IBM Tivoli Access Manager: Base: Administrativní příručka
Výmaz domény smaže uvedené skupiny produktu Tivoli Access Manager a volitelně, použijete-li volbu pdadmin group delete (vymazat skupinu pdadmin)–registry (registr), smaže informace o skupině z registru uživatelů. Záznamy ACL vztahující se ke skupině jsou vymazané také. Poznámka: Operaci výmaz nelze zrušit. Abyste smazali doménu používající Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do domény správy jako administrátor domén.
Web Portal Manager Abyste smazali doménu používající Web Portal Manager: 1. Přihlaste se do domény správy. 2. Klepněte na Secure Domain (Zabezpečená doména)→ List Secure Domain (Výpis zabezpečených domén). 3. Z okna Domain List (Výpis domén) zvolte doménu, kterou chcete smazat. 4. Z okna Domain Properties (Vlastnosti domén) klepněte na Delete (Výmaz). Abyste trvale odstranili informace o doméně a registru uživatelů, klepněte na Delete Registry Entry (Výmaz záznamu v registru). Jinak informace o uživateli a skupině pro doménu zůstanou v registru uživatelů a lze je opět použít pro opětně tvoření domény.
pdadmin Abyste smazali doménu používající obslužný program pdadmin, přihlaste se do domény správy a použijte příkaz pdadmin domain delete. Abyste trvale odstranili informace o doméně z registru uživatelů, uveďte volbu –registry. Jinak informace o uživateli a skupině pro doménu zůstanou v registru uživatelů a lze je opět použít pro opětně tvoření domény. Například, abyste smazali doménu pojmenovanou Domain-ABC a trvale odstranili informace o doméně z registru uživatelů, zadejte: pdadmin sec_master> domain delete Domain-ABC –registry
Poznámka: Pokud zrušíte konfiguraci domény správy používající obslužný program pdconfig místo použití příkazu pdadmin domain delete, libovolné další domény, které také existují, budou vymazané. Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Úprava domény Pouze administrátor, který je připojený k doméně správy, má oprávnění upravovat popis domény. Doménu může upravovat pouze administrátor s odpovídajícími privilegii v doméně správy. Abyste upravili popis domény používající Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do domény správy jako administrátor domén.
Web Portal Manager Abyste upravili popis domény používající Web Portal Manager: 1. Přihlaste se do domény správy. 2. Klepněte na Secure Domain (Zabezpečená doména)→ List Secure Domain (Výpis zabezpečených domén). Kapitola 5. Správa domény
61
3. Z okna Manage Secure Domains (Správa zabezpečených domén) klepněte na jméno domény, kterou chcete změnit (například Domain-ABC). 4. Z okna Secure Domain Properties (Vlastnosti zabezpečených domén) editujte pole Description (Popis), abyste přidali nový popis nebo změnili ten existující. Například, zadejte new test domain description, abyste změnili existující popis. 5. Klepněte na Apply (Použít).
pdadmin Abyste změnili popis domény používající obslužný program pdadmin, přihlaste se do domény správy a zadejte na jeden řádek příkaz pdadmin domain modify. pdadmin sec_master> domain modify Domain-ABC description "new test domain description"
62
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 6. Správa prostoru objektů Tivoli Access Manager představuje zdroje, které mají být ochráněné s použitím virtuálního znázornění nazývaného prostor objektů nebo chráněný prostor objektů. Prostor objektů se skládá z objektů typu zdroj a objektů typu zásobník. Objekty zdrojů jsou logická znázornění zdrojů, které mají být ochráněné. Objekty zásobníků vám umožňují seskupovat objekty zdroj a jiné objekty zásobníků hierarchicky v logických skupinách a oblastech. Seskupení podobných objektů vám umožní jednodušší administrativu konzistentní bezpečnostní politiky. Bezpečnostní politika je použitá připojením přístupových seznamů (ACLs), politik chráněných objektů (POPs) a autorizačních pravidel k objektům v prostoru objektů, které představují fyzické zdroje, které mají být chráněné. Autorizační služba produktu Tivoli Access Manager provádí rozhodnutí o tom, zda povolit nebo zakázat přístup ke zdrojům, na základě pověření uživatele a na základě podmínek uvedených v bezpečnostní politice. Model zabezpečení produktu Tivoli Access Manager závisí na ACL, POP a autorizačních pravidlech, které mají poskytovat jemnozrnnou ochranu pro tyto zdroje. Společná bezpečnostní politika je naimplementována použitím přizpůsobených politik ACL a POP u těch zdrojů, které vyžadují ochranu. Autorizační služba produktu Tivoli Access Manager provádí rozhodnutí o tom, zda povolit nebo zakázat přístup ke zdrojům, na základě pověření uživatele a na základě určitých oprávnění a podmínek, které jsou nastaveny v politikách ACL a POP. Abyste použili ACL, POP a autorizační pravidla a umožnili autorizačním službám provést své kontroly zabezpečení, produkt Tivoli Access Manager používá virtuální znázornění objektů zdrojů domény nazývaných chráněný prostor objektů. Jako administrátor domén můžete používat Web Portal Manager nebo obslužné programy příkazového řádku pdadmin, abyste připojili ACL, POP nebo autorizační pravidla k objektům v prostoru objektů.
Vytvořit prostor objektů Abyste vytvořili prostor objektů používající produkt Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste vytvořili prostor objektů používající produkt Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Object Space (Prostor objektů) → Create Object Space (Vytvořit prostor objektů). 3. Zapište Object Name (Jméno objektu). Toto pole je povinné. Například: /Test-Space 4. Zapište Description (Popis) pro prostor objektů. Například: New Object Space 5. Klepněte na Create (Vytvořit). Abyste si mohli prohlédnout prostor objektů /Test-Space v hierarchické struktuře, procházejte prostor objektů. Viz “Procházení prostorů objektů” na stránce 65. Protože se prostor objektů skládá z objektů typu zdroj a zásobník, nemusíte uvádět žádný typ objektu používající rozhraní Web Portal Manager.
pdadmin Chcete-li vytvořit prostor objektů v doméně pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin objectspace create. Poznámka: Nepoužívejte příkaz pdadmin objectspace pro prostory objektů vytvořené nebo vyvinuté s použitím produktu Tivoli Access Manager. Prostory objektů produktu Tivoli Access Manager zahrnují /Management, /WebSEAL, /OSSEAL a /PDMQ. Chcete-li například vytvořit prostor objektů se jménem /Test-Space, který je umístěn v objektu typu zásobník aplikací, zadejte následující: pdadmin sec_master> objectspace create /Test-Space "New Object Space" 14
Při tvoření prostoru objektů musíte uvést typ objektu. Tento příklad prostoru objektů přiřazuje číslo kategorie 14, což je pro objekt typu zásobník aplikace. “Prostor chráněných objektů” na stránce 32 se zabývá dvěma hlavními typy objektů: objekty typu zdroj a zásobník. Můžete si zvolit libovolný z vypsaných typů prostorů objektů, nebo použít číslo kategorie unused vypsané v následující tabulce, která označuje typ prostoru objektů a přiřazuje mu význam. Tyto typy prostorů objektů jsou platné pro produkt Tivoli Access Manager: Typy objektů 0 1 2 3 4 5 6 7 8
– – – – – – – – –
neznámý zabezpečená doména soubor spustitelný program adresář spojení server WebSEAL nepoužíváno nepoužíváno
9 – server HTTP 10 – neexistující objekt 11 – objekt typu zásobník 12 – koncový objekt 13 – port 14 – objekt typu zásobník aplikace 15 – objekt typu koncová aplikace 16 – objekt správy 17 – nepoužíváno
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Vytvořit objekt Abyste vytvořili objekt používající rozhraní Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Chcete-li vytvořit objekt používající rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Object Space (Prostor objektů) → Create Object (Vytvořit objekt). 3. Zapište Object Name (Jméno objektu). Toto pole je povinné. Zapište plnou cestu do jména objektu. Například: /Management/Groups/Travel 4. Zapište Description (Popis) pro prostor objektů. Například: Travel Container Object 5. Klepněte na Create (Vytvořit).
64
IBM Tivoli Access Manager: Base: Administrativní příručka
6. Chcete-li si zobrazit nový objekt v hierarchické struktuře, procházejte prostor objektů. Klepněte na Object Space (Prostor objektů) → Browse Object Space (Procházet prostor objektů) → a rozbalte, pokud je to nutné. 7. Chcete-li zvolit zaškrtávací okénko Can Policy be attached to this object (Lze k tomuto objektu přiřadit politiku) v okně Protected Object Properties (Vlastnosti chráněných objektů), nejdříve zvolte objekt. Protože objekt produktu Tivoli Access Manager už má definované objekty typu zdroj a zásobník, nemusíte uvádět žádný typ objektu při používání rozhraní Web Portal Manager. Pro znázornění různých typů objektů jsou použité různé ikony.
pdadmin Abyste vytvořili objekt v prostoru objektů používajícím obslužný program pdadmin, přihlaste se do domény a použijte příkaz pdadmin object create. Chcete-li například vytvořit objekt pojmenovaný /Travel, který je objektem typu zásobník aplikace, zadejte na jeden řádek následující příkaz: pdadmin sec_master> object create /Management/Groups/Travel "Travel Container Object" 14 ispolicyattachable yes
Při tvoření objektu používajícího obslužný program pdadmin musíte uvést typ objektu. Tento příklad objektu přiřazuje číslo kategorie 14, což je pro objekt typu zásobník aplikace. “Prostor chráněných objektů” na stránce 32 se zabývá dvěma hlavními typy objektů: objekty typu zdroj a zásobník. Můžete si zvolit libovolný z vypsaných typů prostorů objektů, nebo použít číslo kategorie unused vypsané v následující tabulce, která označuje typ prostoru objektů a přiřazuje mu význam. Typy objektů 0 1 2 3 4 5 6 7 8
– – – – – – – – –
neznámý zabezpečená doména soubor spustitelný program adresář spojení server WebSEAL nepoužíváno nepoužíváno
9 – server HTTP 10 – neexistující objekt 11 – objekt typu zásobník 12 – koncový objekt 13 – port 14 – objekt typu zásobník aplikace 15 – objekt typu koncová aplikace 16 – objekt správy 17 – nepoužíváno
Parametr ispolicyattachable {yes|no} určuje, zda lze připojit politiku ACL k tomuto objektu. Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Procházení prostorů objektů Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin vypsat všechny prostory objektů, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Abyste zobrazili výpis všech prostorů objektů používajících produkt Web Portal Manager: 1. Přihlaste se do domény. Kapitola 6. Správa prostoru objektů
65
2. Klepněte na Object Space (Prostor objektů) → Browse Object Space (Procházet prostor objektů). Okno Browse Object Space (Procházet prostor objektů) zobrazuje všechny prostory objektů v doméně v hierarchické struktuře. Všechny prostory objektů se objevují na stejné úrovni hierarchické struktury jako předvolený prostor objektů/Management. Každý prostor objektů se zobrazuje jako odkaz. Pokud jej zvolíte, odkaz zobrazí okno Protected Object Properties (Vlastnosti chráněných objektů).
pdadmin Chcete-li vypsat všechny prostory objektů v doméně pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin objectspace list. pdadmin sec_master> objectspace list
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Vymazat prostor objektů Abyste smazali objekt z prostoru objektů používajících produkt Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste smazali objekt z prostoru objektů používajícího produkt Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Object Space (Prostor objektů) → Browse Object Space (Procházet prostor objektů). 3. Z okna Browse Object Space (Procházet prostor objektů) rozbalte a klepněte na chráněný objekt, který chcete smazat. 4. V okně Protected Object Properties (Vlastnosti chráněných objektů) je jméno prostoru objektů zobrazeno v poli Object Name (Jméno objektu). Klepněte na tlačítko Delete (Vymazat). 5. Abyste potvrdili výmaz, klepněte opět na tlačítko Delete (Vymazat). Pokud je vše úspěšně provedeno, zobrazí se zpráva indikující, že objekt byl vymazaný.
pdadmin Chcete-li vymazat prostor objektů z domény pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin objectspace delete. Chcete-li například vymazat prostor objektů se jménem /Test-Space, zadejte následující: pdadmin sec_master> objectspace delete /Test-Space
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
66
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 7. Správa chráněných objektů Chráněný objekt je logické znázornění skutečného systémového zdroje, který je použitý pro použití přístupových seznamů (ACLs), chráněných politik objektů (POPs) a autorizačních pravidel pro autorizaci přístupů uživatelů. Jako administrátor domény můžete používat rozhraní Web Portal Manager nebo obslužný program s příkazovým řádkem pdadmin k vytvoření a vymazání objektů. Jakmile byl prostor objektů vytvořen, můžete ho zaplnit objekty. Informace o vytváření prostoru objektů najdete v části “Vytvořit prostor objektů” na stránce 63.
Vytvořit objekt Chcete-li vytvořit objekt pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin, přihlaste se do určené domény jako administrátor domény.
Web Portal Manager Jak vytvořit nový objekt pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Object Space (Prostor objektů) → Create Object (Vytvořit objekt). 3. Zapište plnou cestu objektu k poli Object Name (Jméno objektu) (například, /Management/Groups/test-object). Toto pole je povinné. 4. Volitelně zapište popis objektu (například, Test Object (Testovací objekt)). 5. Klepněte na tlačítko Create (Vytvořit). 6. Pokud chcete aktivovat připojení politiky k tomuto chráněnému objektu, klepněte na Object Space (Prostor objektů) → Browse Object Space (Procházet prostor objektů). Okno Browse Object Space (Procházet prostor objektů) poskytuje zobrazení hierarchie všech objektů v doménách jako odkazy. Klepněte na objekt, abyste se dostali do okna Protected Object Properties (Vlastnosti chráněných objektů) a zvolte zaškrtávací okénkoCan Policy be attached to this object (Lze k tomuto objektu připojit politiku).
pdadmin Chcete-li vytvořit objekt v doméně pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin object create. Chcete-li například vytvořit objekt se jménem /Management/test-object, který je umístěn v objektu zásobníku aplikací, zadejte následující: pdadmin object create /Management/test-object “Test Object” 14 ispolicyattachable yes
Typ může být jedna z následujících kategorií: Typy objektů 0 1 2 3 4 5 6 7 8
– – – – – – – – –
neznámý zabezpečená doména soubor spustitelný program adresář spojení server WebSEAL nepoužíváno nepoužíváno
9 – server HTTP 10 – neexistující objekt 11 – objekt typu zásobník 12 – koncový objekt 13 – port 14 – objekt typu zásobník aplikace 15 – objekt typu koncová aplikace 16 – objekt správy 17 – nepoužíváno
Při vytváření objektu musíte zadat typ. Můžete si zvolit odpovídající kategorii, nebo použít libovolné číslo, a tak určíte typ objektu a přiřadíte mu jeho význam. Je-li pole ispolicyattachable vynecháno v příkazu pdadmin object create, pak obslužný program předpokládá, že jste zamýšleli použít příkaz objectspace create. Bude vytvořen prostor objektů namísto objektu. Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Vypsat objekty Abyste si zobrazili výpis domén používajících Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste si zobrazili výpis domén používajících Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Object Space (Prostor objektů) → Browse Object Space (Procházet prostor objektů). Okno Browse Object Space (Procházet prostor objektů) poskytuje zobrazení hierarchie všech objektů v doménách jako odkazy.
pdadmin Chcete-li vypsat všechny objekty v doméně pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin object list. Například, abyste zobrazili výpis objektů pod prostorem objektů /Management, zadejte: pdadmin sec_master> object list /Management
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Vymazat objekt Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem vymazat objekt pdadmin, přihlaste se do určené domény jako administrátor domény.
68
IBM Tivoli Access Manager: Base: Administrativní příručka
Web Portal Manager Jak vymazat objekt pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Object Space (Prostor objektů) → Browse Object Space (Procházet prostor objektů). Okno Browse Object Space (Procházet prostor objektů) poskytuje zobrazení hierarchie všech objektů v doménách jako odkazy. 3. Klepněte na odkaz pro objekt (například, /Management/test-object), abyste si mohli prohlédnout vlastnosti, jako jestli ACL, POP a autorizační pravidla jsou připojené k objektu a jestli má objekt nějaké rozšířené atributy. 4. Z okna Protected Object Properties (Vlastnosti chráněných objektů) zajistěte, že pojmenovaný objekt je ten, který chcete vymazat, potom klepněte na Delete (Výmaz).
pdadmin Chcete-li vymazat objekt z domény pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin object delete. Chcete-li například vymazat objekt se jménem /Management/test-object, zadejte následující: pdadmin object delete /Management/test-object
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Kapitola 7. Správa chráněných objektů
69
70
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 8. Správa přístupových seznamů Pomocí politik přístupových seznamů (ACL - Access Control List) můžete řídit přístup ke zdrojům domény. Administrátor domény může pomocí obslužného programu s příkazovým řádkem pdadmin nebo pomocí rozhraní Web Portal Manager vytvořit politiky ACL, které se skládají ze záznamů ACL chránících zdroje definované v doméně administrátora. Administrátor domény může dále zvolit jiného uživatele a přidělit mu oprávnění administrátora tak, že nastaví záznamy ACL pro tohoto uživatele, aby odpovídaly záznamům ACL administrátora domény. Nyní bude mít uživatel stejná oprávnění jako administrátor.
Politiky ACL Politika ACL se skládá z jednoho nebo více záznamů ACL, které popisují: v jména uživatelů a skupin, jejichž přístup je explicitně řízen, v pro každého uživatele, skupinu, nebo roli povolené specifické operace, v povolené specifické operace pro speciální kategorie uživatelů ostatní (any-other) a neautentizovaný (unauthenticated).
Obrázek 17. Přístupový seznam pro objekt webové stránky
Chcete-li vytvářet, měnit, nebo odstraňovat záznamy ACL, můžete použít obslužný program s příkazovým řádkem pdadmin nebo rozhraní Web Portal Manager.
Záznamy ACL Záznam ACL obsahuje buď dva nebo tři atributy závisející na typu záznamu ACL a objeví se v následujícím formátu:
Obrázek 18. Atributy záznamu ACL
v typ – kategorie entity (uživatel nebo skupina), pro kterou byl přístupový seznam vytvořen v ID (totožnost - identity) – jedinečný identifikátor (jméno) jednotky
Atribut ID se nepožaduje pro typy záznamu ACL ostatní (any-other) a neautentizovaný (unauthenticated) v oprávnění (nebo akce) – sada operací, které lze provádět v objektu daným uživatelem nebo skupinou Většina oprávnění určuje schopnost klienta provádět určité operace ve zdroji. Ve výše uvedeném příkladu uživatel adam (typ = user, ID = adam) má oprávnění číst (zobrazovat) objekt chráněný touto politikou ACL. Oprávnění ke čtení r povoluje operace čtení. Oprávnění pro přechod T vynucuje pravidlo pro přechod.
Atribut Typ Typ záznamu ACL určuje uživatele, skupinu nebo speciální entitu určitého záznamu ACL. Existují čtyři typy záznamů ACL. Typ user
Popis Nastavuje oprávnění pro určitého uživatele v doméně. Uživatel musí být členem domény a musí mít účet v registru. Typ záznamu user vyžaduje jméno uživatele (ID). Formát záznamu je: user ID oprávnění Například: user antonín -------T-----r-
group
Nastavuje oprávnění pro všechny členy určité skupiny v doméně. Typ záznamu group vyžaduje jméno skupiny (ID). Formát záznamu je: group ID oprávnění Například: group technici -------T-----r-
any-other Nastavuje oprávnění pro všechny autentizované uživatele. Nevyžaduje se (znám také jako žádné určení ID. Formát záznamu je: any-other oprávnění any-authenticated, ostatní) Například: any-other -------T-----runauthenticated
Nastavuje oprávnění pro ty uživatele, kteří nebyli autentizováni serverem politik. Nevyžaduje se žádné určení ID. Formát záznamu je: unauthenticated oprávnění Například: unauthenticated -------T-----rTento záznam ACL je maska (logická operace “and”) pro záznam ACL any-other, aby bylo možné určit nastavení oprávnění. Oprávnění pro unauthenticated je uděleno pouze tehdy, je-li oprávnění současně i u záznamu any-other. Například následující záznam ACL unauthenticated: unauthenticated -------------rw je maskou pro tento záznam ACL any-other: any-other -------T-----ra výsledkem jsou tato oprávnění: -------------r- (pouze pro čtení).
72
IBM Tivoli Access Manager: Base: Administrativní příručka
Atribut ID ID záznamu ACL je jedinečným identifikátorem, nebo jménem typu záznamu uživatel (user) nebo skupina (group). ID musí představovat platné uživatele, skupiny nebo obojí, které jsou vytvořené v doméně Tivoli Access Manager. Příklady: user michal user antonín group technici group dokumentace group účetní
Poznámka: Atribut ID se nepoužívá u typů záznamu ACL ostatní (any-other) a neautentizovaný (unauthenticated).
Atribut oprávnění (akce) Každý záznam ACL obsahuje sadu oprávnění (nebo akcí), které popisují specifické operace, které může uživatel nebo skupina provádět s objektem. Politiky ACL řídí chráněné zdroje následujícími způsoby: v schopností uživatele provádět operace s chráněnými objekty, v schopností administrátora měnit pravidla kontroly přístupu v objektech a podobjektech, v schopností produktu Tivoli Access Manager delegovat pověření uživatele. Poznámka: Oprávnění ACL jsou citlivá na kontext — chování některých oprávnění se mění v závislosti na oblasti prostoru chráněných objektů, na kterou jsou použity. Například, oprávnění upravit (m) znamená něco jiného pro chráněné zdroje v prostoru objektů /WebSEAL než pro chráněné zdroje v prostoru objektů /Management.
Předvolená oprávnění (akce) produktu Tivoli Access Manager Produkt Tivoli Access Manager definuje sedmnáct předvolených oprávnění (akcí). Rozhraní Web Portal Manager rozděluje tato oprávnění do tří kategorií. Základní aAbBcgNtTWR
Bit akce
Generická dmsv
Aplikační lrx
Popis
Kategorie
a
Připojit
Základní
A
Přidat
Základní
b
Procházet
Základní
B
Vynechat politiku POP (Protected Object Policy)
Základní
c
Řídit
Základní
d
Vymazat
Generická
g
Delegovat
Základní
l
Vypsat adresář
Aplikační
m
Upravit
Generická
N
Vytvořit
Základní
r
Číst
Aplikační Kapitola 8. Správa přístupových seznamů
73
Bit akce
Popis
Kategorie
s
Administrativa serveru
Generická
t
Trasovat
Základní
T
Přejít
Základní
v
Zobrazit
Generická
W
Heslo
Základní
x
Provést
Aplikační
R
Pravidlo vynechání
Základní
Produkt Tivoli Access Manager poskytuje schopnost nadefinovat mnohem více dalších akcí, neboli oprávnění, které mohou používat aplikace třetích stran. Podrobnější informace najdete v části “Správa skupin akcí” na stránce 79.
Správa přístupových seznamů Přístupový seznam vytvoříte a nakonfigurujete a pak ho můžete připojit k objektům v prostoru chráněných objektů. Politiky ACL jsou umístěné v hlavní databázi autorizace na doménové bázi, která je kontrolovaná serverem politik. Můžete provádět následující úlohy ACL: v “Vytvořit ACL” v v v v
“Vypsat ACL” na stránce 75 “Vymazat ACL” na stránce 75 “Upravit ACL” na stránce 76 “Použití atributu ACL pro chráněný objekt” na stránce 76 – “Připojit ACL k objektu” na stránce 76 – “Najít, kde je politika ACL připojena” na stránce 77 – “Odpojení politiky ACL” na stránce 77
Politiky POP (Protected object policies) fungují stejně jako politiky ACL. Politiky POP jsou děděny stejným způsobem jako politiky ACL. Další informace o politikách POP vám poskytne “Správa politik chráněných objektů” na stránce 86.
Vytvořit ACL Chcete-li vytvořit ACL pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak vytvořit ACL pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → Create ACL (Vytvořit ACL). 3. Zapište ACL Name (Jméno ACL) (například, Test-ACL). Toto pole je povinné. 4. Volitelně zapište Description (Popis) ACL (například, Test nové ACL). 5. Klepněte na tlačítko Create (Vytvořit). Pokud vše proběhlo úspěšně, bude při zobrazení seznamu všech ACL dostupný odkaz na tuto ACL.
74
IBM Tivoli Access Manager: Base: Administrativní příručka
pdadmin Chcete-li vytvořit nový ACL v doméně pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin acl create. Chcete-li například vytvořit ACL se jménem Test-ACL, zadejte následující: pdadmin sec_master> acl create Test-ACL
Další informace najdete v publikaci IBM Tivoli Access Manager for e-business Command Reference.
Vypsat ACL Chcete-li vypsat všechny přístupové seznamy ACL pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak vypsat všechny ACL v doméně pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → List ACL (Vypsat ACL). Okno Manage ACL (Správa ACL) zobrazí všechny ACL v doménách.
pdadmin Chcete-li vypsat všechny přístupové seznamy ACL v doméně pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin acl list. pdadmin sec_master> acl list
Další informace najdete v publikaci IBM Tivoli Access Manager for e-business Command Reference.
Vymazat ACL Chcete-li vymazat ACL pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin, přihlaste se do určené domény jako administrátor domény.
Web Portal Manager Jak vymazat ACL pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → List ACL (Vypsat ACL). 3. V okně Manage ACL (Správa ACL) zvolte jedno nebo více zaškrtávacích polí ACL, které chcete vymazat. 4. Klepněte na Delete (Vymazat) a potom potvrďte výmaz klepnutím na Delete (Vymazat) v potvrzovacím okně Delete ACL (Vymazat ACL). Pokud vše proběhlo úspěšně, daná ACL už nebude součástí seznamu ACL v okně Manage ACL (Správa ACL).
pdadmin Chcete-li vymazat ACL z domény pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin acl delete. Chcete-li například vymazat ACL se jménem Test-ACL, zadejte následující: pdadmin sec_master> acl delete Test-ACL
Další informace najdete v publikaci IBM Tivoli Access Manager for e-business Command Reference.
Kapitola 8. Správa přístupových seznamů
75
Upravit ACL Chcete-li změnit ACL pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin, přihlaste se do určené domény jako administrátor domény.
Web Portal Manager Jak změnit ACL pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → List ACL (Vypsat ACL). 3. Klepněte na odkaz ACL, který chcete změnit (například, Test-ACL). 4. V okně ACL Properties (Vlastnosti ACL) klepněte na ouško General (Obecné), abyste zobrazili nebo změnili popis ACL, zobrazili seznam záznamů ACL a vytvořili nebo vymazali záznamy ACL. Například, abyste změnili popis Test ACL, zapište Test 1 pro ACL a potom klepněte na Set (Nastavit) vedle pole Description (Popis). Pro nápovědu online klepněte na otazník, čímž otevřete zvláštní okno nápovědy pro aktuální okno. 5. Klepněte na odkaz oprávnění, abyste zobrazili seznam aktivačních nebo deaktivačních oprávnění, která se vztahují ke zvolené ACL. Zobrazí se okno ACL Entry Properties (Vlastnosti záznamů ACL). V tomto okně můžete zvolit nebo vyčistit zaškrtávací pole oprávnění pro ACL, potom klepněte na Apply (Použít). 6. Klepněte na ouško Attach (Připojit), abyste zobrazili seznam připojení a odpojení ACL od chráněných objektů. 7. Klepněte na ouško Extended Attributes (Rozšířené atributy), abyste zobrazili seznam vytvoření nebo výmazů rozšířených atributů pro uvedený ACL.
pdadmin Chcete-li pomocí obslužného programu pdadmin změnit záznam ACL v doméně, přihlaste se do domény a použijte příkaz pdadmin acl modify. Chcete-li například změnit ACL se jménem Test-ACL tak, aby uživatel marie měl oprávnění r (číst), zadejte následující: pdadmin sec_master> acl modify Test-ACL set user maryj r
Pro zobrazení úprav v ACL použijte příkaz pdadmin acl show: pdadmin sec_master> acl show Test-ACL Jméno ACL: Test-ACL Popis: Záznamy: User maryj r
Další informace najdete v publikaci IBM Tivoli Access Manager for e-business Command Reference.
Použití atributu ACL pro chráněný objekt Politiky ACL můžete použít připojením ACL k chráněnému objektu. ACL lze od chráněného objektu také odpojit.
Připojit ACL k objektu Chcete-li připojit ACL ke chráněnému objektu pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin, přihlaste se do požadované domény jako administrátor domény.
76
IBM Tivoli Access Manager: Base: Administrativní příručka
Web Portal Manager Jak připojit ACL ke chráněnému objektu pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. 3. 4. 5. 6.
Klepněte na ACL → List ACL (Vypsat ACL). Klepněte na odkaz pro jméno ACL, který chcete změnit (například Test-ACL). V okně ACL Properties (Vlastnosti ACL) klepněte na ouško Attach (Připojit). Klepněte na Attach (Připojit), abyste zobrazili okno Attach ACL (Připojit ACL). Zapište Protected Object Path (Cestu chráněného objektu) (například /Management/test-object). Objekt už musí existovat. 7. Klepněte na tlačítko Attach (Připojit). Pokud vše proběhlo úspěšně, zobrazí se chráněný objekt jako odkaz chráněného objektu pro jmenovaný ACL.
pdadmin Chcete-li připojit seznam ACL ke chráněnému objektu v doméně pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin acl attach. Chcete-li například připojit seznam ACL se jménem Test-ACL ke chráněnému objektu /Management/test-object, zadejte následující: pdadmin sec_master> acl attach /Management/test-object Test-ACL
Další informace najdete v publikaci IBM Tivoli Access Manager for e-business Command Reference.
Najít, kde je politika ACL připojena Chcete-li vyhledat, kde je daná politika ACL připojena, pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Jak najít, kde je seznam ACL připojen, pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → List ACL (Vypsat ACL). Zobrazí se seznam jmen ACL. Každé jméno ACL je odkaz, na který můžete klepnout, a zobrazí se okno vlastností ACL. 3. Klepněte na ouško Attach (Připojit).
pdadmin Chcete-li nalézt, kde v doméně je přístupový seznam připojen, pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin acl find. Chcete-li například najít, kde je připojen přístupový seznam se jménem Test-ACL, zadejte následující: pdadmin sec_master> acl find Test-ACL
Další informace najdete v publikaci IBM Tivoli Access Manager for e-business Command Reference.
Odpojení politiky ACL Chcete-li pomocí rozhraní Web Portal Manager nebo obslužného programu s příkazovým řádkem pdadmin odpojit ACL od objektu, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Chcete-li odpojit ACL od chráněného objektu v doméně s pomocí Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → List ACL (Vypsat ACL). Kapitola 8. Správa přístupových seznamů
77
3. V okně Modify ACL (Upravit ACL) klepněte na odkaz pro danou ACL (například Test-ACL). 4. V okně ACL Properties (Vlastnosti ACL) klepněte na ouško Attach (Připojit). 5. Pokud jsou ACL momentálně připojené k chráněným objektům, zvolte jeden nebo víc zaškrtávacích polí pro objekty ACL, které chcete odpojit. 6. Klepněte na tlačítko Detach (Odpojit). Budete požádáni o potvrzení odpojení.
pdadmin Chcete-li pomocí obslužného programu pdadmin odpojit ACL od chráněného objektu v doméně, přihlaste se do domény a použijte příkaz pdadmin acl detach. Chcete-li například odpojit ACL od chráněného objektu se jménem /Management/test-object, zadejte následující: pdadmin sec_master> acl detach /Management/test-object
Další informace najdete v publikaci IBM Tivoli Access Manager for e-business Command Reference.
Příklad záznamů ACL Oprávnění určitých uživatelů a skupin nastavíte uvedením odpovídajícího typu záznamu ACL. V následujícím příkladu bude mít skupina dokumentace oprávnění pro úplný přístup: group dokumentace --bcg--Tdmsv--lrx
Pro ostatní autentizované uživatele v doméně (kteří nepatří do skupiny dokumentace) můžete omezit přístup pomocí typu záznamu any-other: any-other -------T-------rx
Dále můžete omezit přístup pomocí typu záznamu unauthenticated uživatelům, kteří nejsou členy domény. unauthenticated -------T-------r-
Poznámka: Pokud by nebyl vytvořen záznam ACL unauthenticated, pak by neautentizovaní uživatelé nemohli přistupovat k žádným zabezpečeným dokumentům v doméně.
Politiky ACL a prostor chráněných objektů Objekty typu zásobník představují určité oblasti v prostoru chráněných objektů a obsluhují dvě důležité bezpečnostní funkce: v Přístupový seznam objektu typu zásobník můžete používat tehdy, chcete-li nadefinovat politiku na vysoké úrovni pro všechny podobjekty v oblasti, pokud zde nejsou použity žádné explicitně nastavené přístupové seznamy. v Můžete rychle odepřít přístup ke všem objektům v oblasti tak, že odstraníte oprávnění pro přechod z přístupového seznamu objektu typu zásobník.
Kořenový ( / ) objekt typu zásobník Pro objekt root (kořen) platí následující kritéria bezpečnosti: v Kořenový objekt začíná řetěz dědičnosti ACL pro celý prostor chráněných objektů. v Pokud nebudete používat žádný další explicitní přístupový seznam, pak kořenový objekt definuje (prostřednictvím dědičnosti) bezpečnostní politiku celého prostoru objektů. v Přístup ke všem objektům pod kořenovým objektem vyžaduje oprávnění pro přechod (T).
78
IBM Tivoli Access Manager: Base: Administrativní příručka
Oprávnění pro přechod Oprávnění pro přechod je generické oprávnění, které se používá v celém prostoru chráněných objektů. Operace T
přechod
Popis Je-li aplikováno na objekt typu zásobník, pak umožňuje žadateli, aby v hierarchii prošel přes objekt typu zásobník na cestě k požadovanému zdrojovému objektu. Neumožňuje žádný jiný typ přístupu k objektu typu zásobník. Přechod není požadován na vlastním požadovaném zdrojovém objektu.
Oprávnění objektu a prostoru objektů Příkazy uvedené v následující tabulce dovolují administrátorům spravovat nové objekty a prostory objektů. Úlohy akcí a přidružená oprávnění zahrnují: Operace a
připojit
Popis Připojí politiky ACL nebo POP k objektům; odstraní politiky ACL nebo POP z objektů. pdadmin pdadmin pdadmin pdadmin
b
procházet
acl acl pop pop
attach detach attach detach
objectspace list object list object listandshow (navíc vyžaduje oprávnění v)
d
vymazat
objectspace delete object delete object modify set name (navíc vyžaduje oprávnění m)
m
upravit
objectspace create object create object modify
v
zobrazit
object show object listandshow (navíc vyžaduje oprávnění b)
Poznámka: Následující operace vyžadují obojí, jak oprávnění pro procházení (b), tak oprávnění pro zobrazení (v): pdadmin object listpdadmin object listandshow
Správa skupin akcí Akce se používají k udělení oprávnění provádět určité operace na zdrojích chráněných produktem Tivoli Access Manager. Pro okamžité použití je předdefinováno sedmnáct akcí ,viz “Předvolená oprávnění (akce) produktu Tivoli Access Manager” na stránce 73). Tivoli Access Manager poskytuje schopnost zobrazit správce zdrojů - specifické akce. Například Kapitola 8. Správa přístupových seznamů
79
produkt Tivoli Access Manager for Business Integration definuje oprávnění Enqueue (zařadit do fronty) a Dequeue (vyřadit z fronty) pro ukládání zpráv do fronty zpráv nebo pro získání zpráv z fronty.
Skupiny akcí Tato část popisuje, jak nadefinovat skupiny akcí, které slouží jako zásobníky pro přídavnou sadu přizpůsobených akcí: v Každá skupina akcí je schopná pojmout až 32 bitů akcí. v Bit akce se skládá z písmen: a-z, A-Z. v Každý znak bitu akce může být použit pouze jednou v rámci dané skupiny akcí. v V jiných skupinách akcí můžete daný bit akce znovu použít. v Předvolené akce produktu Tivoli Access Manager jsou uloženy ve výchozí předdefinované skupině akcí s názvem primary, jak zobrazuje Obrázek 19:
Obrázek 19. Primární skupina akcí
Produkt Tivoli Access Manager podporuje celkově 32 skupin akcí (včetně primární skupiny akcí), což dává celkový počet 1024 jednotlivých akcí.
Obrázek 20. Více skupin akcí
Vytvořit novou skupinu akcí Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin vytvořit skupinu akcí, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak vytvořit skupinu akcí pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → Create Action Group (Vytvořit skupiny akcí).
80
IBM Tivoli Access Manager: Base: Administrativní příručka
3. Zapište nové Action Group Name (Jméno skupiny akcí) (například test-group). Toto pole je povinné. Klepněte na tlačítko Create (Vytvořit). Budete-li úspěšní, zobrazí se po vytvoření skupiny akcí zpráva.
pdadmin Chcete-li pomocí obslužného programu pdadmin vytvořit skupinu akcí v doméně, přihlaste se do domény a použijte příkaz pdadmin action group create. Chcete-li například vytvořit novou skupinu akcí se jménem test-group, zadejte následující: pdadmin sec_master> action group create test-group
Předvolená primární skupina akcí se vždy objeví ve výpisu skupin a nelze ji vymazat. V přístupovém seznamu objektu /Management/ACL musíte mít záznam s oprávněním pro změny (m), abyste byli schopni vytvářet skupiny akcí, a záznam s oprávněním pro mazání (d), abyste byli schopni vymazat skupiny akcí. Další informace najdete v publikaci IBM Tivoli Access Manager for e-business Command Reference.
Vypsat skupiny akcí Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin vypsat všechny skupiny akcí, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak vypsat skupiny akcí pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → List Action Groups (Vypsat skupiny akcí). Okno Manage Action Groups (Spravovat skupiny akcí) zobrazí seznam všech skupin akcí v doméně.
pdadmin Chcete-li pomocí obslužného programu pdadmin vypsat všechny skupiny akcí v doméně, přihlaste se do domény a použijte příkaz pdadmin action group list. pdadmin sec_master> action group list
Další informace najdete v publikaci IBM Tivoli Access Manager for e-business Command Reference.
Vymazat skupinu akcí Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin vymazat skupinu akcí, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak vymazat skupinu akcí pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → List Action Groups (Vypsat skupiny akcí). 3. V okně Manage Action Groups (Spravovat skupiny akcí) zvolte jedno nebo více zaškrtavacích polí pro skupiny akcí, které chcete vymazat. 4. Klepněte na tlačítko Delete (Vymazat).
Kapitola 8. Správa přístupových seznamů
81
5. Potvrďte výmaz klepnutím na Delete (Vymazat) v okně Delete Action Groups (Vymazat skupiny akcí).
pdadmin Chcete-li pomocí obslužného programu pdadmin vymazat skupinu akcí z domény, přihlaste se do domény a použijte příkaz pdadmin action group delete. pdadmin sec_master> action group delete test-group
Další informace najdete v publikaci IBM Tivoli Access Manager for e-business Command Reference.
Vytvořit novou akci ve skupině akcí Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin vytvořit akci ve skupině akcí, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Jak vytvořit akci ve skupině akcí pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → List Action Groups (Vypsat skupiny akcí). 3. Klepněte na odkaz pro jméno skupiny akcí (například Test-Group), ve které chcete vytvořit akci. Zobrazí se okno Action Group Properties (Vlastnosti skupiny akcí) a Action Group Name (Jméno skupiny akcí) se vyplní automaticky. 4. V okně Action Group Properties (Vlastnosti skupiny akcí) klepněte na Create (Vytvořit), čímž zobrazíte okno Create Action (Vytvořit akce). Action Group Name (Jméno skupiny akcí) se vyplní automaticky. 5. Zapište jedním znakem Action Name (Jméno akce) (například x). Toto pole je povinné. 6. V poli Action Label (Označení akce) zapište krátký popis akce (například Execute). Toto pole je povinné. 7. V poli Action Type (Typ akce) zapište popis akce jako, pro kterou aplikaci je akce specifická (například WebSEAL). Toto pole je povinné. 8. Klepněte na tlačítko Create (Vytvořit). Bude-li vše provedeno úspěšně, zobrazí se po vytvoření akce zpráva.
pdadmin Chcete-li pomocí obslužného programu pdadmin vytvořit akci ve skupině akcí domény, přihlaste se do domény a použijte příkaz pdadmin action create. Vytvořte akci x ve skupině akcí pojmenované Test-Group a zadejte následující pdadmin sec_master> action create x Execute WebSEAL Test-Group
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Přizpůsobené akce Předvolené akce produktu Tivoli Access Manager jsou dostupné všem aplikacím. Pokud bude aplikace používat předvolené akce produktu Tivoli Access Manager, pak by přidružená operace měla velmi věrně odpovídat skutečné operaci obvykle prováděné produktem Tivoli Access Manager. Například r by se mělo používat pouze pro operace, které vyžadují přístup pouze pro čtení ke chráněnému objektu. Poznámka: Aplikace mohou používat předvolená oprávnění produktu Tivoli Access Manager pro naprosto nezávislé operace, protože autorizační služba neví nic o
82
IBM Tivoli Access Manager: Base: Administrativní příručka
těchto operacích a ani se o to nezajímá. Podobná situace však může znamenat pro administrátora určité komplikace, protože ten musí rozlišovat mezi dvěma rozdílnými použitími stejné akce. Pokud aplikace používá operaci, kterou není možné dobře znázornit nějakou z předvolených akcí, produkt Tivoli Access Manager vám umožní, abyste nadefinovali novou akci, kterou bude tato aplikace používat a která bude rozeznávána autorizační službou. Viz “Správa skupin akcí” na stránce 79.
Příklad přizpůsobené akce V tomto příkladě, který zobrazuje Obrázek 21, se objevil požadavek na ochranu určitého zařízení tiskárny před neoprávněným použitím. Služba souběžného tisku byla napsána spolu s autorizačním rozhraním API, takže může volat autorizační službu, aby prováděla kontroly ACL pro požadavky vydané na tuto tiskárnu. Standardní akce produktu Tivoli Access Manager neobsahují evidentní oprávnění pro ochranu tiskáren. Tiskárnu je však možné ochránit pomocí nově vytvořené akce (v tomto příkladě p). Politika ACL je připojena k objektu tiskárny. Pokud uživatel požádá o použití chráněné tiskárny, pak tento uživatel musí mít záznam ACL, který obsahuje oprávnění p. Autorizační služba vrátí příznivou odpověď, pokud oprávnění p je součástí oprávnění uživatele, a pak bude operace tisku pokračovat. Pokud autorizační služba nenalezne oprávnění p pro daného uživatele, pak nebude operaci tisku povoleno pokračovat.
Obrázek 21. Přizpůsobená akce souběžného tisku
Zadání přizpůsobených akcí do záznamů ACL Jak bylo vysvětleno v části “Záznamy ACL” na stránce 71, záznamy ACL obsahují typ záznamu, ID typu (pro typy uživatel a skupina) a sadu povolených bitů akcí. Musíte použít speciální syntaxi, pokud chcete označit přizpůsobené bity akcí patřící do skupin akcí odlišných od “primární” skupiny akcí. Řetězce akcí, které představují bity akce z více skupin akcí, se zobrazují v následujícím formátu: action...action[action-group]action...action,,,
Například: abgTr[groupA]Pq[groupB]Rsy[groupC]ab v První sada bitů akcí (abgTr) představuje akce z “primární” (Tivoli Access Manager předvolené) skupiny akcí. v Skupina akcí A obsahuje akce P a q. v Skupina akcí B obsahuje akce R, s a y. v Skupina akcí C obsahuje akce a a b. Kapitola 8. Správa přístupových seznamů
83
v Všimněte si, že skupina akcí C obsahuje bity akcí, které používají stejná písmena jako bity akcí v “primární” skupině akcí. Protože bity akcí jsou přidruženy k určité skupině akcí (C), pak bity akcí a a b mají jedinečnou totožnost a mohou představovat velmi odlišné akce než bity akcí a a b v “primární” skupině akcí.
Příklad Zobrazit skupiny akcí pdadmin sec_master> action group list primary test-group
Vypsat seznam akcí ve skupině “test-group” pdadmin sec_master> action list test-group P Test-Action Special S Test-Action2 Special
Vypsat politiky ACL pdadmin sec_master> acl list default-webseal default-root default-gso default-policy default-config test default-replica default-management
Zobrazit podrobné informace o přístupovém seznamu “test” pdadmin sec_master> acl show test Jméno ACL: test Popis: Záznamy: User sec_master Tcmdbva Group ivmgrd-servers Tl Any-other r
Přidat záznam ACL pro uživatele Kateřina, který bude obsahovat akce ze skupin akcí “primary” a “test-group” pdadmin sec_master> acl modify test set user kathy brT[test-group]PS pdadmin sec_master> acl show test Jméno ACL: test Popis: Záznamy: User sec_master Tcmdbva Group ivmgrd-servers Tl Any-other r User katerina Tbr[test-group]PS
84
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 9. Správa politik chráněných objektů Zatímco politiky ACL poskytují služby autorizace s informacemi, jestli na žádost o připojení do chráněného objektu odpovědět yes nebo no a zda v tomto objektu provést nějakou operaci, politika chráněného objektu (POP) obsahuje další podmínky, které projdou zpět do správce zdrojů společně s rozhodnutím politiky ACL yes ze služeb autorizace. Produkt Tivoli Access Manager a správce zdrojů jsou odpovědni za to, že vynutí splnění podmínek politiky POP. Tabulka 1 obsahuje seznam dostupných atributů politiky POP produktu Tivoli Access Manager, a splnění podmínek této politiky je vynucováno produktem Tivoli Access Manager: Tabulka 1. Podmínky vynucované produktem Tivoli Access Manager Vynucovány produktem Tivoli Access Manager Base Atribut politiky POP
Popis
Příkazy pdadmin pop
Jméno
Jméno politiky. Z toho vznikne jméno-pop v online příkazech pdadmin pop.
create vymazat
Popis
Text popisující politiku. Zobrazí se v příkazu pop show.
modify set description
Režim varování
Poskytuje administrátorům způsoby, modify set warning jak otestovat bezpečnostní politiku.
Úroveň auditu
Určuje typ monitorování: all, none, successful access, denied access, errors.
modify set audit-level
Denní doba přístupu
Omezení ve dni a čase, kdy je možné úspěšně přistupovat ke chráněnému objektu.
modify set tod-access
Rozšířené atributy
Uvádí doplňková datová pole.
modify set attribute modify delete attribute list attribute show attribute
Tabulka 2 obsahuje seznam dostupných atributů politiky POP produktu Tivoli Access Manager, a splnění podmínek této politiky je vynucováno správcem zdrojů (například WebSEAL): Tabulka 2. Podmínky vynucované správcem zdrojů Vynucovány správcem zdrojů (jako např. serverem WebSEAL) Atribut politiky POP
Popis
Příkazy pdadmin pop
Úroveň zabezpečení
Určuje stupeň zabezpečení dat: none, integrity, privacy.
modify set qop
Politika autentizace koncového bodu IP
Určuje požadavky autentizace na přístup členů z externích sítí.
modify set ipauth add modify set ipauth remove modify set ipauth anyotherw
2. Pro podporu adresy IP produktu Tivoli Access Manager: v Můžete udělit vstup do chráněného zdroje založeném na adrese IP, která je používaná totožností. Například, pouze uživatelů z adresy IP 9.18.n.n jsou oprávnění k přístupu do chráněného zdroje. v Můžete definovat, že jsou požadované další úrovně autentizace k umožnění přístupu do chráněného zdroje založeném na adrese IP, které je používaná pro totožnost. Autentizace spouštěcí úrovně je popsaná v publikacích“Konfigurace úrovní pro zvýšenou autentizaci” na stránce 95 a IBM Tivoli Access Manager for e-business WebSEAL: Administrativní příručka. 3. Denní doba přístupu a politika autentizace koncového bodu IP nastavují omezení přístupu k objektu. 4. Úroveň auditu a úroveň zabezpečení informují autorizační službu, že při přístupu k objektu se vyžadují další služby. 5. Varovný režim poskytuje způsob, jak otestovat bezpečnostní politiky před jejich aktivací.
Správa politik chráněných objektů Vytvoříte a konfigurujete politiky POP a potom ji připojíte k objektům v prostoru chráněných objektů. Politiky POP jsou umístěné v hlavní autorizační databázi na doménové bázi, která je řízená serverem politik. Je možné provádět níže uvedené úlohy POP: v “Vytvořit politiku POP” v “Vypsat politiky POP” na stránce 88 v “Vymazat politiku POP” na stránce 88 v “Úprava politiky POP” na stránce 89 Následující úlohy se týkají atributů POP pro ochranu objektů a lze je provést: v “Připojit politiku POP k objektu” na stránce 90 v “Najít, kde je politika POP připojena” na stránce 90 v “Odpojení politiky POP od chráněného objektu” na stránce 91 Politiky ACL fungují stejným způsobem jako politiky POP. Jak politiky POP tak ACL jsou převzaté stejným způsobem. Viz “Správa přístupových seznamů” na stránce 74, chcete-li získat více informací o tom, jak fungují politiky ACL.
Vytvořit politiku POP Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin vytvořit politiku POP, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak vytvořit politiku POP pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na POP → Create POP (Vytvořit POP), čímž se vám zobrazí okno Create POP. 3. Zapište POP Name (Jméno POP) (například, poptest1). Toto pole je povinné. 4. Volitelně můžete zapsat Description (Popis) politiky POP.
86
IBM Tivoli Access Manager: Base: Administrativní příručka
5. Zvolte jedno nebo více zaškrtávacích okének pro odpovídající úrovně auditu. Audit Level (Úroveň auditu) je úroveň monitorování, které se používá při vytváření přístupu do zdroje, ke kterému je připojená politika POP. Můžete zvolit více než jednu úroveň auditu. Úrovně auditu jsou následující: v Permit Auditují se všechny požadavky na chráněný objekt, jejichž výsledkem je úspěšný přístup. v Deny Auditují se všechny požadavky na chráněný objekt, jejichž výsledkem je zamítnutí přístupu. v Error Auditují se všechny vnitřně generované chybové zprávy vzniklé při zamítnutí přístupu ke chráněnému objektu. v Admin Audity nejsou produktem Tivoli Access Manager použité. Ale tuto volbu lze použít uživatelskými aplikacemi. Chcete-li získat více informací, viz “Atribut Úroveň auditu” na stránce 92 6. Zvolte zaškrtávací okénko pro Warn Only On Policy Violation (Varování pouze při narušení politik), abyste aktivovali atributy varovného režimu. Atributy varovného režimu označují, zda narušení politik, které se vztahuje ke zdroji, má za následek odepření přístupu nebo monitorované selhání. Monitorované selhání je pokus o připojení ke zdroji, ke kterému je vztažená politika POP, které vyústí v monitorování přístupu, ne jeho odepření. Chcete-li získat více informací, viz “Atribut Režim varování” na stránce 91. 7. Zvolte typ Quality of Protection (Úrovně zabezpečení). Úroveň zabezpečení, která se používá při vytváření přístupu ke zdroji, ke kterému je připojená politika POP. Volby úrovně zabezpečení jsou: v None Nepožaduje žádnou úroveň zabezpečení. v Integrity Používá mechanismus k zajištění, že se nezmění žádná data. v Privacy Požaduje šifrování dat pro SSL (Secure Sockets Layer). Chcete-li získat více informací, viz “Úroveň zabezpečení politiky POP” na stránce 97. 8. Pro Time of Day Access (Denní doba přístupu) uveďte dny a denní doby, kdy lze do zdroje vytvořit přístup. v Zvolte zaškrtávací okénka pro dny v týdnu, kdy lze zdroj zpřístupnit. v Pro přístupové doby, kdy bude možné vytvořit přístup ke zdroji, zvolte buď All Day (Celý den) nebo Between hours of (V hodinách od - do). v
Zvolíte-li Between hours of (V hodinách od - do), musíte uvést také Start time (Počáteční doba) a End time (Koncová doba). v Zvolíte-li Between hours of (V hodinách od - do), musíte uvést také Local Time (Místní čas) nebo UTC Time (Univerzální souřadnicový čas) (coordinated universal time). Chcete-li získat více informací, viz “Atribut Denní doba přístupu” na stránce 92. 9. Klepněte na tlačítko Create (Vytvořit). Pokud je toto úspěšné, zobrazí se vám zpráva potvrzující vytvoření politiky POP. 10. Klepněte na tlačítko Create Another (Vytvořit další), pokud chcete vytvořit další POP, jinak klepněte na Done (Hotovo). Kapitola 9. Správa politik chráněných objektů
87
pdadmin Chcete-li pomocí obslužného programu pdadmin vytvořit politiku POP v doméně, přihlaste se do domény a použijte příkaz pdadmin pop create. Například, abyste vytvořili politiku POP pojmenovanou poptest1, zadejte následující: pdadmin sec_master> pop create poptest1
Nová politika POP obsahuje následující předvolená nastavení: pdadmin sec_master> pop show poptest1 POP: poptest1 Popis: Varování: ne Úroveň auditu: žádná Úroveň zabezpečení: žádná Přístup během dne: ne, po, út, st, čt, pá, so: kdykoliv:lokální Politika autentizace koncového bodu IP Libovolná jiná síť 0
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Vypsat politiky POP Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin vypsat všechny politiky POP, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Abyste si zobrazili seznam všech POP s použitím Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na POP → List POP (Seznam POP), čímž zobrazíte okno Manage POP (Správa POP). Všechny POP pro doménu se zobrazí jako odkazy.
pdadmin Chcete-li pomocí obslužného programu pdadmin vypsat všechny politiky POP v doméně, přihlaste se do domény a použijte příkaz pdadmin pop list. pdadmin sec_master> pop list
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Vymazat politiku POP Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin vymazat politiku POP, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak vymazat politiku POP pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na POP → List POP (Seznam POP), čímž zobrazíte okno Manage POP (Správa POP). 3. Zvolte jedno nebo více zaškrtávacích polí POP, které chcete vymazat. 4. Klepněte na tlačítko Delete (Vymazat).
88
IBM Tivoli Access Manager: Base: Administrativní příručka
5. Potvrďte výmaz v okně Delete Pop (Vymazat POP) klepnutím na tlačítko Delete (Vymazat).
pdadmin Chcete-li pomocí obslužného programu pdadmin vymazat politiku POP z domény, přihlaste se do domény a použijte příkaz pdadmin pop delete. Například, abyste vymazali POP pojmenovanou poptest2, zadejte následující: pdadmin sec_master> pop delete poptest2
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Úprava politiky POP Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin změnit politiku POP, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak změnit politiku POP pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na POP → List POP (Seznam POP), čímž zobrazíte okno Manage POP (Správa POP). 3. Klepněte na odkaz pro POP (například, poptest1, čímž zobrazíte okno POP Properties (Vlastnosti POP). 4. V oušku General (Obecné) změňte informace týkající se POP, jak potřebujete. Například, změňte popis z Test POP na Test 1 for POP, a potom klepněte na tlačítko Apply (Použít). Chcete-li získat online nápovědu por libovolné okno Web Portal Manager, klepněte na otazník, čímž se vám otevře zvláštní okno nápovědy. 5. Klepněte na ouško Attach (Připojit), čímž se vám zobrazí seznam chráněných objektů, ke kterým má být připojená nebo odpojená uvedená politika POP. 6. Klepněte na ouško IP Auth (Autorizace IP), čímž zobrazíte seznam autentizací IP, které mají být vytvořené nebo vymazané. 7. Klepněte na ouško Extended Attributes (Rozšířené atributy), čímž zobrazíte seznam rozšířených atributů, které můžete vytvořit nebo vymazat.
pdadmin Chcete-li pomocí obslužného programu pdadmin změnit politiku POP v doméně, přihlaste se do domény a použijte příkaz pdadmin pop modify. Například, abyste upravili POP pojmenovanou poptest1, zadejte následující: pdadmin sec_master> pop modify poptest1 set description “Test 1 for POP”
Poznámka: Popis vždy uzavřete dvojitými uvozovkami, pokud používáte více než jedno slovo. Chcete-li zobrazit provedené změny v politice pop, použijte příkaz pdadmin pop show. pdadmin sec_master> pop show poptest1 POP: poptest1 Popis: Test 1 pro POP Varování: ne Úroveň auditu: žádná Úroveň zabezpečení: žádná
Kapitola 9. Správa politik chráněných objektů
89
Přístup během dne: ne, po, út, st, čt, pá, so: kdykoliv:lokální Politika autentizace koncového bodu IP Libovolná jiná síť 0
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Aplikace atributů POP na chráněné objekty Politiky POP se na objekty aplikují stejným způsobem jako politiky ACL.
Připojit politiku POP k objektu Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin připojit politiku POP k objektu, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak připojit politiku POP k objektu pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na POP → List POP (Seznam POP), čímž zobrazíte okno Manage POP (Správa POP). 3. Klepněte na odkaz pro POP. 4. V okně POP Properties (Vlastnosti POP) klepněte na ouško Attach (Připojit). 5. Klepněte na Attach (Připojit), abyste zobrazili okno Attach POP (Připojit POP). 6. Zapište Protected Object Path (Cesta chráněného objektu) toho chráněného objektu, ke kterému chcete připojit POP. Vyjádřete cestu jako jméno plné cesty (například, /WebSEAL/serverA/index.html). 7. Klepněte na tlačítko Attach (Připojit). Pokud je toto úspěšné, chráněný objekt bude přidán do seznamu v okně POP Properties–Attach (Vlastnosti POP–Připojit).
pdadmin Chcete-li pomocí obslužného programu pdadmin připojit politiku POP ke chráněnému objektu v doméně, přihlaste se do domény a použijte příkaz pdadmin pop attach. Chcete-li například připojit politiku POP se jménem test ke chráněnému objektu se jménem /WebSEAL/serverA/index.html, zadejte následující: pdadmin sec_master> pop attach /WebSEAL/serverA/index.html test
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Najít, kde je politika POP připojena Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin najít, kde je politika POP připojena, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak najít, kde je politika POP připojena, pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na ACL → List POP (Vypsat POP). Zobrazí se seznam jmen POP. Pro každé jméno POP je vytvořený odkaz, na který můžete klepnout a zobrazí se vám okno vlastností POP. 3. Klepněte na ouško Attach (Připojit).
90
IBM Tivoli Access Manager: Base: Administrativní příručka
pdadmin Chcete-li pomocí obslužného programu pdadmin najít, kde v doméně je připojena určitá politika POP, přihlaste se do domény a použijte příkaz pdadmin pop find. Chcete-li například najít, kde je připojena politika POP se jménem test, zadejte následující: pdadmin sec_master> pop find test /WebSEAL/serverA/index.html
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Odpojení politiky POP od chráněného objektu Chcete-li pomocí rozhraní Web Portal Manager nebo pomocí obslužného programu s příkazovým řádkem pdadmin odpojit politiku POP od chráněného objektu, přihlaste se do požadované domény jako administrátor domény.
Web Portal Manager Jak odpojit politiku POP od chráněného objektu pomocí rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Object Space (Prostor objektů)→ Browse (Procházet) a zobrazí se vám okno Browse Object Space (Procházet prostorem objektů). 3. Klepněte na odkaz politiky POP. 4. V okně POP Properties (Vlastnosti POP) klepněte na ouško Attach (Připojit). 5. Zvolte jedno nebo více zaškrtávacích polí pro chráněné objekty, od kterých chcete odpojit POP. 6. Klepněte na tlačítko Detach (Odpojit), čímž se vám zobrazí okno Detach POP from Object (Odpojit POP od objektu), kde budete vyzvaní k potvrzení nebo zrušení odpojení.
pdadmin Chcete-li pomocí obslužného programu pdadmin odpojit politiku POP od chráněného zdroje v doméně, přihlaste se do domény a použijte příkaz pdadmin pop detach. Chcete-li například odpojit politiku POP od chráněného objektu se jménem /WebSEAL/serverA/index.html, zadejte následující: pdadmin sec_master> pop detach /WebSEAL/serverA/index.html
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Konfigurace atributů politiky POP Atributy politiky POP zavádějí podmínky přístupu k objektu na základě doby přístupu a určují, zda by měl být požadavek na přístup monitorován.
Atribut Režim varování Účelem atributu Režim varování je umožnit administrátorovi systému vyladit nebo vyřešit problémy s přesností autorizační politiky, která je nastavena v prostoru chráněných objektů. Pokud nastavíte atribut Režim varování na hodnotu yes, pak všichni uživatelé mohou provádět všechny akce s objektem, ke kterému je daná politika POP připojena. Kterýkoliv přístup do objektu je povolený, i když je bezpečnostní politika připojená k objektu nastavená na odepření tohoto přístupu.
Kapitola 9. Správa politik chráněných objektů
91
Záznamy auditu jsou generované, aby zachycovaly výsledky všech bezpečnostních politik s varovným režimem nastaveným přes prostor objektů. Protokol monitorování zobrazuje výsledek rozhodnutí o autorizaci, jako by bylo provedené, byl li atribut varování nastavený na no. Administrátor může tudíž určit, jestli je politika nastavená a vynucovaná správně. Například: pdadmin sec_master> pop modify test set warning yes
Podrobnější informace o příkazech pdadmin pop najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Atribut Úroveň auditu Úroveň auditu POP má rozšířenou schopnost uvádět úrovně monitorování. Je-li například monitorování nastaveno tak, aby zaznamenávalo neúspěšné události, můžete výsledky použít k detekci nezvyklého počtu špatných pokusů o přístup k určitému zdroji. Záznamy auditu se zapisují ve standardním formátu XML, který umožňuje snadnou analýzu, aby bylo možné vyjmout požadované informace. Viz “Přehled monitorování” na stránce 221. Například: pdadmin sec_master> pop modify test set audit-level permit,deny Seznam úrovní auditu Hodnota
Popis
permit
Auditují se všechny požadavky na chráněný objekt, které skončí povolením přístupu.
deny
Auditují se všechny požadavky na chráněný objekt, které skončí zamítnutím přístupu.
error
Auditují se všechny vnitřní chybové zprávy vzniklé při zamítnutí přístupu ke chráněnému objektu.
Můžete použít kombinaci těchto tří hodnot. Pokud zadáte více než jednu hodnotu, jako oddělovací znak použijte čárku. Podrobnější informace o příkazech pdadmin pop najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Atribut Denní doba přístupu Atribut politiky POP Denní doba přístupu (TOD - time-of-day) vám dovoluje zadat podmínky pro určitý den a čas, kdy je možné přistupovat ke chráněnému objektu. Tento typ podmínky může být vhodné používat tehdy, pokud potřebujete omezit přístup k informacím, které pravidelně vyžadují, aby k nim nikdo nepřistupoval a tak mohly být upraveny a aktualizovány. pdadmin sec_master> pop modify jméno_pop set tod-access řetězec_denní_doby_přístupu
Parametr řetězec_denní_doby_přístupu obsahuje seznam dnů a časový rozsah a používá se v následujícím formátu: {anyday|weekday|seznam_dní}: {anytime|uvedená_doba-uvedená_doba} [:{utc|local}]
Proměnná seznam_dní může být libovolná kombinace následujícího:
92
IBM Tivoli Access Manager: Base: Administrativní příručka
mon, tue, wed, thu, fri, sat, sun
Proměnná řetězce uvedená_doba musí být vyjádřená (s použitím doby 24 hodin) v následujícím formátu: hhmm-hhmm
Například: 0700-1945
Volitelná časová zóna [:{utc|local}] pro server (ne pro klienta) je local podle předvolby. Například: pdadmin sec_master> pop modify test set tod-access mon,tue,fri:1315-1730
Podrobnější informace o příkazech pdadmin pop najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Politika POP autorizace založené na síti Politika POP autorizace založené na síti umožňuje řízení přístupu do objektů založených na adrese IP uživatele. Tuto funkcionalitu můžete použít k tomu, abyste zabránili určitým IP adresám (nebo rozsahům IP adres) v přístupu ke všem zdrojům ve vaší doméně. Pro tuto politiku můžete také použít konfiguraci zvýšené autentizace a dále můžete vyžadovat určitou politiku autentizace pro každý uvedený rozsah IP adres. Politika autorizace založené na síti je nastavená koncovým atributem metody autentizace IP politiky POP. Musíte uvést dvě části tohoto atributu: v úrovně autentizace Bližší informace týkající se úrovní autentizace najdete v části “Politika POP odolnosti autentizace (zvýšení)” na stránce 95. v povolené sítě
Určení IP adres a rozsahů Příkaz pdadmin pop modify set ipauth add určuje jak síť (nebo rozsah sítí), tak i požadovanou úroveň autentizace atributu Politiky autentizace koncového bodu IP. Podrobnější informace o příkazech pdadmin pop modify set ipauth add najdete v knize IBM Tivoli Access Manager for e-business Command Reference. Nakonfigurované úrovně autentizace jsou propojeny na rozsahy IP adres. Cílem této politiky je pružnost. Pokud není důležité filtrovat uživatele podle IP adresy, můžete nastavit jeden záznam pro anyothernw (libovolná další síť). Toto nastavení ovlivní všechny přistupující uživatele bez ohledu na jejich IP adresy a vyžaduje, aby se všichni autentizovali na zadané úrovni. Naopak, pokud si přejete ignorovat úrovně autentizace a chcete pouze povolit nebo zakázat přístup na základě IP adresy, můžete použít úroveň 0 pro rozsahy IP adres, které chcete povolit a zakázáno pro rozsahy, které chcete zakázat. Záznam anyothernw se používá pro rozsah sítí, které odpovídají každé síti, která nebyla jinak určena v politice POP. Tato politika se používá k vytvoření předvoleného záznamu, který by mohl buď zakázat všechny neodpovídající IP adresy, nebo povolit přístup každému, kdo může splňovat požadavky na úroveň autentizace. Kapitola 9. Správa politik chráněných objektů
93
Standardně se anyothernw objevuje v politice POP spolu s indexem úrovně autentizace o hodnotě 0. Záznam se ve výstupu příkazu pop show zobrazí jako Libovolná jiná síť: pdadmin sec_master> pop show test Politika chráněného objektu: test Popis: Test POP Varování: ne Úroveň auditu: žádná Úroveň zabezpečení: žádná Přístup během dne: ne, po, út, st, čt, pá, so: kdykoliv:lokální Politika autentizace koncového bodu IP Libovolná jiná síť 0
Podrobnější informace o příkazech pdadmin pop modify set ipauth anyothernw najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Udělování přístupu identifikátorům Tento příklad uděluje přístup identifikátorům z adres IP, které začínají 9. pdadmin sec_master> pop modify test set ipauth add 9.0.0.0 255.0.0.0 0
Tento příklad uděluje přístup identifikátorům z adres IP 9.1.2.3. pdadmin sec_master> pop modify test set ipauth add 9.1.2.3 255.255.255.255 0
Tento příklad zabraňuje všem uživatelům (jiným než těm, kteří jsou uvedení v příkladech nad) v přístupu do objektu: pdadmin sec_master> pop modify test set ipauth anyothernw forbidden
Chcete-li získat více informací o příkazech pdadmin pop modify set ipauth add a pdadmin pop modify set ipauth forbidden, viz publikace IBM Tivoli Access Manager for e-business Command Reference.
Zablokování autorizací založených na síti prostřednictvím adresy IP Tento příklad odstraňuje přístup pro identifikátory z adresy IP, který začíná 9. pdadmin sec_master> pop modify test set ipauth remove 9.0.0.0 255.0.0.0
Podrobnější informace o příkazech pdadmin pop modify set ipauth remove najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Algoritmus autorizace založené na síti Prostředek autorizace používá ke zpracování podmínek v politice POP následující algoritmus: 1. Zkontroluje oprávnění v ACL. Poznámka: Existuje oprávnění pro vynechání politiky ACL (B), které přepíše podmínky autorizace POP v objektu. Toto oprávnění by mělo být používáno pouze administrátory na vysoké úrovni v hierarchii, kteří potřebují plný přístup k prostoru chráněných objektů, a to kdykoliv. 2. Zkontrolujte, jestli je pravidlo připojené k objektu, potom ověřte, že všechny ADI jsou přítomné pro nadcházející vyhodnocování pravidel. Pokud nejsou, najde je pomocí dotazu na jeden z dostupných zdrojů. 3. Zkontroluje politiku politiky autentizace pomocí koncového bodu IP v politice POP. 4. Zkontroluje politiku přístupu během dne v politice POP. 5. Zkontroluje politiku úrovně auditu v politice POP.
94
IBM Tivoli Access Manager: Base: Administrativní příručka
6. Zkontroluje politiku pravidla, zda je k objektu připojeno pravidlo. 7. Vztahuje-li se operace vnější autorizační služby (EAS) nebo spouštěcí impuls POP k tomuto rozhodnutí o přístupu, potom vyvolejte vztahující se EAS.
Omezení a poznámky k autorizaci založené na síti Adresa IP je použitá správcem zdrojů pro vynucení politiky autorizace založené na síti by měla být adresa IP odesílatele zprávy o připojení. Pokud vaše topologie sítě využívá proxy, adresa, kterou uvidí správce zdrojů, může být IP adresou proxy serveru. V takovém případě nebude správce zdrojů s určitostí identifikovat pravou IP adresu klienta. Při nastavování politiky autorizace založené na síti musíte dávat pozor, který klienti sítě se mohou přímo připojit do správce zdrojů.
Politika POP odolnosti autentizace (zvýšení) Politiku chráněného objektu (POP) můžete používat k vynucení některých podmínek přístupu k určitým zdrojům. Politika POP odolnosti autentizace umožňuje řídit přístup k objektům na základě politiky autentizace. Tuto funkcionalitu, někdy známou také jako zvýšenou autentizaci, můžete používat, abyste se ujistili, že uživatelé, kteří přistupují k citlivějším zdrojům, používají silnější mechanismus autentizace. Můžete chtít používat tuto podmínku, jelikož u podobných zdrojů existuje velká hrozba nezákonného přístupu. Můžete například zajistit větší bezpečnost spojené oblasti prostoru chráněných objektů pomocí zvýšené politiky POP, která vyžaduje vyšší úroveň autentizace, než kterou používají klienti při prvním vstupu do domény. Politika odolnosti autentizace se nastavuje v atributu Politika autentizace koncového bodu IP politiky POP.
Konfigurace úrovní pro zvýšenou autentizaci Prvním krokem v konfiguraci přístupu specifického pro danou autentizaci je nakonfigurovat podporované politiky autentizace a určit pořadí, ve kterém se dá předpokládat, že tyto politiky autentizace budou nejodolnější. Každý klient, který přistupuje ke správci zdrojů, má nějakou úroveň autentizace, jako např. “neautentizovaný” nebo “heslo”, která označuje politiku, pomocí níž se klient naposledy autentizoval prostřednictvím správce zdrojů. V některých situacích může být nezbytné vynutit minimální bezpečné úrovně autentizace, které budou vyžadovány pro přístup k některým zdrojům. Například, v jednom prostředí by mohla být autentizace prostřednictvím kódu tokenu, který projde, považovaná za bezpečnější než autentizace prostřednictvím uživatelského jména a hesla. Jiné prostředí může potřebovat jiné standardy. Spíše než nucení klientů správcem zdrojů k restartování jejich relací, když nevyhovují požadované úrovni autentizace, mechanismus zvýšen autentizace poskytuje klientovi druhou šanci na opětnou autentizace s použitím požadované metody (úroveň). Zvýšená autentizace dovoluje správcům zdrojů řídit způsob, jak budou uživatelé přistupovat ke chráněným zdrojům. Pokud se vyžaduje použití zvýšené autentizace, neboť uživatel se neautentizoval pomocí dostatečné politiky, pak je rozhodnutí o přístupu i nadále povoleno prostřednictvím mechanismu autorizace, ale správci zdrojů bude toto rozhodnutí předloženo spolu s požadovanou úrovní autentizace jako výstup rozhodnutí o autorizaci. Správce zdrojů Kapitola 9. Správa politik chráněných objektů
95
pak může rozhodnout, jak bude dále autentizovat uživatele, aby získal požadovanou úroveň autentizace, která je potřebná k tomu, aby uživatel mohl přistoupit k danému objektu. Jak budou určité politiky autentizace mapovány na úrovně autentizace je plně určeno aplikací správce zdrojů. V každém případě by měla být minimální akceptovatelná politika autentizace nastavena jako úroveň 0 a bezpečnější politiky by měly být namapovány na celá čísla ve vzestupném pořadí (1..x).
Použití politiky zvýšené autentizace Zvýšená autentizace je implementována pomocí politiky POP uložené na objektech, které vyžadují autorizace pomocí citlivé autentizace. Používáte atribut politiky POP s názvem Politika autentizace koncového bodu IP. Příkaz pdadmin pop modify set ipauth určuje jak povolené sítě, tak i požadované úrovně autentizace v atributu Politika autentizace koncového bodu IP. Nakonfigurované úrovně autentizace mohou být propojeny do oblastí IP adres. Cílem této politiky je pružnost správy. Pokud není důležité filtrovat uživatele podle IP adresy, můžete nastavit jeden záznam pro anyothernw (libovolná další síť). Toto nastavení ovlivní všechny přistupující uživatele bez ohledu na jejich IP adresy a vyžaduje, aby se všichni autentizovali na zadané úrovni. Toto je nejčastější způsob implementace zvýšené autentizace. Záznam anyothernw se používá pro rozsah sítí, které odpovídají každé síti, která nebyla jinak určena v politice POP. Tato politika se používá k vytvoření předvoleného záznamu, který by mohl buď zakázat všechny neodpovídající IP adresy, nebo povolit přístup každému, kdo může splňovat požadavky na úroveň autentizace. Standardně se anyothernw objevuje v politice POP spolu s indexem úrovně autentizace o hodnotě 0. Záznam se ve výstupu příkazu pdadmin pop show zobrazí jako Libovolná jiná síť: pdadmin sec_master> pop show test Politika chráněného objektu: test Popis: Test POP Varování: ne Úroveň auditu: žádná Úroveň zabezpečení: žádná Přístup během dne: ne, po, út, st, čt, pá, so: kdykoliv:lokální Politika autentizace koncového bodu IP Libovolná jiná síť 0
Podrobnější informace o příkazech pdadmin pop modify set ipauth najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Rozlišení mezi zvýšenou a vícefaktorovou autentizací Zvýšená autentizace produktu Tivoli Access Manager a vícefaktorová autentizace jsou dva rozdílné a zvláštní mechanismy, které řídí přístup ke zdrojům. Produkt Tivoli Access Manager poskytuje pouze funkcionalitu zvýšené autentizace, která byla popsána v této kapitole. Vícefaktorová autentizace nutí uživatele, aby se autentizoval pomocí dvou nebo více úrovní autentizace. Řízení přístupu ke chráněnému zdroji může například vyžadovat, aby se uživatel autentizoval jak pomocí jména uživatele/hesla, tak i pomocí jména uživatele/token passcode. Zvýšená autentizace produktu Tivoli Access Manager se vztahuje k předkonfigurované hierarchii úrovní autentizace a vynucuje určitou úroveň autentizace podle politiky nastavené ve zdroji. Zvýšená autentizace nenutí uživatele, aby se autentizoval pomocí více úrovní
96
IBM Tivoli Access Manager: Base: Administrativní příručka
autentizace, chce-li získat přístup k danému zdroji. Namísto toho zvýšená autentizace vyžaduje, aby se uživatel autentizoval na úrovni, která je minimálně tak vysoká, jako požadovaná úroveň politiky chránící daný zdroj. Níže je uveden příklad zvýšené autentizace: Úrovně autentizace jsou nakonfigurovány takto: v úroveň autentizace 1 = autentizace pomocí jména uživatele/hesla v úroveň autentizace 2 = autentizace pomocí jména uživatele/token passcode Následující objekt je chráněn politikou POP, která vyžaduje úroveň autentizace 1: /WebSEAL/hostA/junction
Následující objekt je chráněn politikou POP, která vyžaduje úroveň autentizace 2: /WebSEAL/hostA/junction/aplikaceA
Při použití zvýšené autentizace se autentizace pomocí jména uživatele/hesla požaduje, aby bylo možné přistoupit k /WebSEAL/hostA/junction. Avšak autentizace pomocí jména uživatele/token passcode (úroveň 2) je nezbytná, aby bylo možné přistoupit k /WebSEAL/hostA/junction/aplikaceA. Pokud uživatel je momentálně přihlášen pomocí jména uživatele a hesla a pokud bude chtít přistoupit k tomuto objektu, zobrazí se mu výzva, aby zadal informace o jménu uživatele a token passcode (zvýšení autentizace). Pokud se však uživatel do produktu WebSEAL přihlásil pomocí jména uživatele a token passcode, pak přístup k aplikaci aplikaceA je okamžitý (pokud předpokládáme kladnou kontrolu ACL). Vícefaktorová autentizace by mohla vyžadovat jak úroveň 1, tak i úroveň 2 autentizace, aby bylo možné přistoupit k objektu aplikaceA.
Úroveň zabezpečení politiky POP Atribut úroveň zabezpečení politiky POP vám umožňuje určit, jakou úroveň zabezpečení dat vyžadujete při provádění operací s objektem. Atribut úroveň zabezpečení politiky POP povoluje jednoduchou transakci, pokud odpověď ano na rozhodnutí ACL současně obsahuje také požadovanou úroveň zabezpečení dat. Pokud správce zdrojů nemůže zaručit požadovanou úroveň zabezpečení, požadavek se zamítne. Syntaxe: pdadmin sec_master> pop modify jméno-pop set qop {none|integrity|privacy} Úroveň QOP
Popis
Privacy
SSL (Secure Sockets Layer) vyžaduje šifrování dat.
Integrity
Použijí se některé mechanismy, které zajistí, že se data nezmění.
Například: pdadmin sec_master> pop modify test set qop privacy
Kapitola 9. Správa politik chráněných objektů
97
98
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 10. Správa autorizačních pravidel Tato kapitola poskytuje detailní informace o autorizačních pravidlech (AuthzRules) produktu Tivoli Access Manager. Autorizační pravidla jsou podmínky obsažené v autorizační politice, které jsou použité pro provádění rozhodnutí založených na atributech jako uživatel, aplikace a kontext prostředí. Tato kapitola obsahuje následující části: v “Přehled autorizačních pravidel” v “Informace o rozhodnutí o přístupu” v “Jazyk autorizačních pravidel” na stránce 101 v v v v v v
“Program pro vyhodnocování autorizačních pravidel” na stránce 107 “Příklady pravidel” na stránce 110 “Metody poskytování ADI programům pro vyhodnocování pravidel” na stránce 113 “Kódy příčiny pro selhání pravidel” na stránce 114 “Konfigurační soubor a inicializační atributy” na stránce 115 “Správa autorizačního pravidla” na stránce 117
Přehled autorizačních pravidel Autorizační pravidla jsou definovaná, aby uváděla podmínky, které musí být splněné dříve, než je povolený přístup k chráněnému objektu. Pravidlo se vytvoří s použitím počtu booleovských podmínek, které jsou založené na datech poskytovaných do autorizačního jádra pověřením uživatele, z aplikace správce zdrojů nebo z obklopujícího obchodního prostředí. Jazyk autorizačního pravidla umožňuje zákazníkům práci s komplexními, strukturovanými daty prověřením hodnot v těchto datech a provedením informovaných rozhodnutí o přístupu. Tato informace může být statisticky definovaná v systému nebo v průběhu obchodního procesu. Pravidla mohou být použitá také pro dokončení autorizační politiky založené na atributech s použitím atributů v obchodním prostředí nebo atributů z důvěryhodného vnějšího zdroje. Autorizační pravidlo produktu Tivoli Access Manager je typ politiky shodující se s ACL nebo POP. Pravidlo je uložené jako textové pravidlo v objektu politik pravidel a je připojené k chráněnému objektu stejným způsobem a se stejnými omezeními jako ACL a POP.
Informace o rozhodnutí o přístupu Data a atributy, které jsou společně použité v podmínkách pravidel, jsou nazývané ADI (access decision information). Atributy autorizační API, což jsou páry jmen a hodnot, tvoří základ všech ADI, na které může pravidlo odkazovat nebo mohou být předložené autorizačnímu jádru.
Nároky pověření uživatele Další data nároků lze vložit jako páry atribut jména - hodnota (odkazuje se na ně jako příznak_hodnota) do pověření klienta autorizačním klientem produktu Tivoli Access Manager během procesu autentizace klienta nebo kdykoli během procesu transakce. Například, produkt Tivoli Access Manager lze konfigurovat s použitím podpory hodnota-příznaku pro seskupení nároků v čase ověřování identity uživatele. Můžete konfigurovat služby nároků, které mají být spuštěné během získání pověření, sbírat data nároků a potom je připojovat k pověřením. Produkt Tivoli Access Manager poskytuje služby nároků atributů pověření, které načítají data nároků z registru uživatelů. Nebo můžete definovat své vlastní služby nároků. Chcete-li získat více informací o definování služeb nároků a podpory příznak-hodnota, viz publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Libovolné atributy přidané k pověření uživatele mohou být použité jako ADI v definici pravidla. Existují také atributy, které jsou vystavěné do pověření uživatele Tivoli Access Manager, když je tvořeno autorizačním jádrem. Stejně jako atributy, které lze přidat do pověření správcem zdrojů, vestavěné atributy pověření lze použít v autorizačních pravidlech. Vestavěné atributy pověření zahrnují položky informací, jako jsou jméno uživatele (nebo UUID objektu) a skupiny (nebo UUID skupin), jejichž je uživatel členem. Viz publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference, pokud chcete vidět tabulku platných jmen atributů pověření. Všechna jména atributů pověření začínají azn_cred_ (například, azn_cred_principal_uuid). Tato tabulka zobrazuje výpis jmen atributů dostupných v pověření autentizovaného uživatele produktu Tivoli Access Manager, jejich hodnotu a popis. Mnoho atributů v této tabulce je dostupných také v pověřeních neautentizovaných uživatelů, ale ty, které se vztahují identitě uživatelů dostupné nejsou. Například, atributy jako jméno uživatele, UUID objektu, jméno skupiny a UUID skupiny, stejně jako DN LDAP pro konfigurace LDAP nejsou k dispozici v pověření, u kterého nebyla prověřená identita. Pamatujte si, že při vývoji pravidel, které používají tyto dané atributy, vyžaduje autorizační jádro, aby byly všechny ADI přítomné před vyhodnocováním pravidla. Není-li ADI dostupná, rozhodnutí o autorizaci bude navráceno s chybovým stavem. Požadavek o autentizaci uživatele před přístupem do chráněného objektu s takovýmto pravidlem zajišťuje, že je dostupná informace o pověření s ověřenou identitou. Tohoto požadavku lze dosáhnout s použitím záznamu ACL v objektu, který vyžaduje autentizovaný přístup.
Informace o kontextu aplikace Autorizační pravidla by mohla požadovat informace o kontextu aplikace pro dokončení vyhodnocení. Informace o kontextu zahrnují informace, které nejsou nároky, ale jsou specifické pro aktuální transakce a operace. Příkladem je množství transakcí, jako je nákupní cena nebo množství přenosů. Tato informace projde k rozhodnutí přes výpis atributů app_context volání azn_decision_access_allowed_ext(). Produkt Tivoli Access Manager WebSEAL také používá tento mechanismus, aby tak předat hodnoty určitých příznaků HTML a data požadavků HTML (ze získaných nebo zapsaných požadavků) do rozhodnutí o přístupu pro použití při vyhodnocování pravidel.
Informace o kontextu autorizačního jádra Informace o kontextu autorizačního jádra je poskytovaná automaticky autorizačním jádrem, je-li požadovaná, před vyhodnocením autorizačního pravidla. ADI poskytnutá autorizačním jádrem zahrnuje jméno chráněného objektu, který je cílem rozhodnutí o přístupu, a řetězec operací, které žadatel chce provést v chráněném objektu. Následující jména atributů jsou vyhrazené pro tyto datové položky: v azn_engine_target_resource v azn_engine_requested_actions
100
IBM Tivoli Access Manager: Base: Administrativní příručka
Služby nároků na vyvolání dynamické ADI Konečný zdroj pro načtení ADI je služba nároků vyvolání dynamické ADI. Tato třída služeb nároků autorizace je určená pro načtení ADI z vnějšího zdroje. Tyto služby mohou být vyvinuté pro načtení ADI z databáze podniku obsahující informace o zaměstnancích, zákaznících, partnerech nebo soupisech. Služba vyvolání dynamické ADI se volá pro načtení ADI v čase, kdy se provádí rozhodnutí o připojení. Přínosem volání obojího současně je schopnost načíst nestálá data, jako jsou přidělené kapacity, v čase, kdy je jejich hodnota nejaktuálnější. AMWebARS (Attribute Retrieval Service) produktu Tivoli Access Manager je příklad služby, která může načíst ADI z vnějších zdrojů. AMWebARS je oficiální jméno sady programů pro službu Tivoli Access Manager J2EE Web, která dokončí službu vyvolání dynamické ADI. Abyste usnadnili komunikaci mezi správcem zdrojů, který vyvolává jádro pravidel, a AMWebARS, který je provedený s použitím SOAP přes HTTP, běhové prostředí Access Manager (sada programů PDRTE) poskytuje služby nároků autorizace nazývanou azn_ent_amwebars. Viz publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference, chcete-li získat více informací o vývoji a použití služeb nároků na vyvolání dynamické ADI pro načtení ADI ve stejném čase, kdy dochází k vyhodnocování pravidla. Také viz publikaceIBM Tivoli Access Manager for e-business Administration C API Developer Reference, která se do hloubky zabývá seznamy atributů a jejich formátem a autorizační API, které jsou použité pro manipulaci s atributy. Abyste získali další informace o omezeních a formátech pro ADI, viz “Formát a omezení pravidel” na stránce 108.
Nestálá a stálá data Obecně zdroj pro jakoukoliv danou součást ADI závisí na typu dat. Nejdůležitější otázkou je, jsou-li data nestálá. Například, je možné měnit data během doby trvání relace uživatele, a pokud ano, je důležité používat ty nejaktuálnější informace, když je toto možné? Nestálá data by měla být načtená s použitím služby vyvolání dynamické ADI, pokud může aplikace správce zdrojů tyto data poskytnout. Data specifická pro aplikaci, která nejsou nestálá ani specifická pro uživatele, jsou poskytovaná aplikací správce zdrojů. Data, která nejsou nestálá ani specifická pro uživatele jsou zavedená do uživatelského pověření při autentizaci uživatele a jeho uchování s pověřením po dobu trvání relace uživatele. Sada dat poskytovaná jádrem autentizace včetně cílového chráněného objektu a povolení je pevná a nelze ji měnit.
Jazyk autorizačních pravidel XLS (eXtensible Stylesheet Language) je jazyk použitý pro uvedení pravidel a XML (eXtensible Markup Language) je jazyk použitý pro data, která tvoří vstup do pravidel. Kombinace jazyků XML a XSL poskytuje nezávislou cestu platformy pro vyjádření vstupů do programu pro vyhodnocování pravidel i do samotných pravidel. XML také poskytuje schopnost vyjádřit typy komplexních dat strukturovaným a standardním způsobem v textovém formátu. Tento textový formát umožňuje pravidlům pro zpracování dat XML pro zápis bez toho, aby bylo nutné shromažďovat v platformě a specifikách programovacího jazyka. XSL je funkční jazyk stylového papíru, který je možné použít pro jednoduché úlohy platformy nebo pro komplexní úlohy závisející na vašich potřebách. XSL vlastní zděděnou schopnost analyzovat a vyhodnocovat data XML, což se stává standardem pro znázornění dat Kapitola 10. Správa autorizačních pravidel
101
v modelech elektronického obchodování. XSL je postavený na jiných standardech založených na XML jako XPath, což je výrazový jazyk v jádru autorizačního pravidla. Abyste dokončili autorizační politiky založené na pravidlech, je nutné vystavit řadu omezení pro pravidla XSL včetně požadavků, že výstupem vyhodnocení pravidla musí být jednoduchý text a výstup se musí podřizovat jednomu ze známých sad řetězů výsledků. Abyste získali další informace o formátu a omezení autorizačních pravidel, viz “Formát a omezení pravidel” na stránce 108. Je také nutné vystavit omezení pro vstupní dokument XML, který je postavený jako vstup do vyhodnocení pravidla. Model dokumentu XML pro ADI umožňuje autorizačnímu jádru odhalit, když chybí ADI a kdy je třeba ji požadovat ze správce zdrojů nebo vnější entity přes rozhraní služby vyvolání dynamické ADI.
Model dokumentu XML pro ADI Model dokumentu XML pro ADI (nebom model XML pro ADI) je sada omezení umístěných implementací autorizačních pravidel na model XSL/XML, aby tak byla umožněná jednoduchost rozhraní a současně jeho funkčnost pro účely autorizace. Model omezuje autorizační pravidla, aby pracovala v předurčeném formátu dokumentu XML se stejnou maximální úrovní prvku dokumentu XML pro všechna pravidla. XML pro ADI, který je importovaný programem pro vyhodnocení pravidel z atributů pověření, z kontextu aplikace nebo a jiných zdrojů dat musí být vložený do tohoto dokumentu XML předtím, než je autorizačním pravidlům umožněno tyto data používat. Shodně pro zjednodušení procesu definování pravidel musí tato pravidla fungovat v rámci omezení modelu XML pro ADI. Model XML pro ADI požaduje, aby dokument XML obsahovat následující prvky maximální úrovně XML, do kterých jsou vložené všechny ADI pro dané vyhodnocení autorizačních pravidel. Prvek XMLADI se vytvoří automaticky autorizačním jádrem jako součást procesu vyhodnocování pravidel. <XMLADI>
-->
Jako výsledek tohoto omezení musí XPath do dat použitých v autorizačním pravidle zahrnovat prefix /XMLADI pro přístup do daného prvku dat v modelu. Například, přidáte-li do dokumentu položku ADI JohnSmith pro přístup do polí JohnSmith v dokumentu XML pro ADI, budete muset uvést XPath /XMLADI/JohnSmith, aby vám byl umožněný přístup do dat obsažených v objektu XML JohnSmith. XPath je cesta do daného podřízeného prvku v hierarchii strukturovaného objektu dat XML. Podobně jako se cesta k adresáře na pevné jednotce používá pro vytvoření přístupu do určitého souboru, cíl XPath začíná od kořene dokumentu (v tomto případě /XMLADI) a sleduje cestu z tohoto kořene přes jeho podřízené prvky až do určitého prvku, ke kterému je odkazováno. Například použijete-li nárok JohnSmith, viz “Příklad nároku XML” na stránce 105, objekt XML JohnSmith má podřízené prvky nazývané CreditCard. Podřízené prvky prvku CreditCard jsou atributy, které jsou společné pro většinu kreditních karet. Abyste vytvořili přístup do prvku Balance pod prvkem CreditCard objektu JohnSmith, museli byste použít tuto XPath: "/XMLADI/JohnSmith/CreditCard/Balance"
XPaths podobné tomuto příkladu jsou prostředky, jakými autorizační pravidla vytvářejí přístup k hodnotám dat ADI, které jsou potřebné pro vytvoření rozhodnutí o autorizaci založených na atributech. Protože jsou všechny prvky dat omezeny pro práci v modelu XML pro ADI, autorizační pravidla musí být také omezená, aby fungovala nebo se shodovala s cestami XPaths v
102
IBM Tivoli Access Manager: Base: Administrativní příručka
modelu. Příkazy odpovídající šabloně XSL jsou tedy také omezené, aby se shodovaly s cestami XPaths, které začínají jako /XMLADI v dokumentu XML pro ADI. Abyste získali další informaci, viz “Formát a omezení pravidel” na stránce 108.
Zásobníky a jména zásobníků ADI pro XML Jsou-li data požadovaná ze správce zdrojů, nespojitost libovolných navrácených dat XML je na úrovni jednoduchého zásobníku informací. Zásobník je normálně také nejmenším prvkem dat (například, prvky, které by mohly být zvažované pro účely billing). Tato konvence byla převzatá také pro modly XML pro ADI. ADI, která je použitý v autorizačních pravidlech, je také definovaná a je s ní zacházeno jako se zásobníky dat XML. Například, objekt XML JohnSmith, jak jej definuje “Příklad nároku XML” na stránce 105, je příkladem zásobníku ADI. Na nejvyšší prvek definice položky ADI se odkazuje jako na jméno zásobníku té položky ADI. Když definujete autorizační pravidlo, XPath do definice XML dat v libovolném zásobníku ADI musí obsahovat jméno zásobníku jako první prvek následující /XMLADI v specifikaci XPath pro prvek dat. Návratem do příkladové položky ADI JohnSmith můžete předpokládat, že se zde bude nacházet zásobník přijatý z poskytovatele dat pojmenovaného JohnSmith. Abyste vytvořili přístup k libovolnému prvku v zásobníku JohnSmith, specifikace XPath musí mít prefix JohnSmith. Například, JohnSmith/CreditCard/AcctNumber odkazuje na hodnotu AcctNumber. Abyste vytvořili přístup k této informaci z autorizačního pravidla, tato XPath musí mít také prefix prvku maximální úrovně dokumentu XML pro vstup do cílové ADI, což je XMLADI (například, /XMLADI/JohnSmith/CreditCard/AcctNumber). Avšak obě tyto cesty XPaths jsou platné, když jsou použité v autorizačních pravidlech kvůli předvolenému příkazu odpovídajícímu šabloně, který je přidaný do všech autorizačních pravidel, které jej neobsahují explicitně. Protože se předvolený příkaz odpovídající šabloně shoduje s dokumentem XML pro ADI z /XMLADI, na JohnSmith lze odkazovat buď relativním odkazem nebo absolutním odkazem, který má prefix /XMLADI. Chcete-li získat více informací, viz “Formát a omezení pravidel” na stránce 108.
Omezení pro jména zásobníků Jedno omezení vystavené modelem dokumentu XML pro ADI je, že každý položka ADI, která může být spotřebovaná programem pro vyhodnocení pravidel, musí mít jedinečné jméno zásobníku, které si nebude možné splést se zásobníky poskytovanými jinými poskytovateli dat nároků. Například, poskytují-li dva různí poskytovatelé datovou položku nazývanou TxInfo, nebude žádný způsob, jak by mohl program pro vyhodnocování dat vědět, ke kterému poskytovateli má odesílat svou žádost o tuto položku dat. Aby bylo umožněno snadnější rozlišení ADI se stejnými jmény, poskytuje XML schopnost definovat prostory jmen pro dat. ID prostorů jmen lze potom použít pro rozlišení jednoho prvku ADI od druhého. V případě TxInfo bychom mohli definovat prostory jmen companyA a vytvořit odkaz pro tento příklad AID companyA:TxInfo. Chcete-li získat více informací o definicích prostorů jmen, viz “Definování prostoru jmen XML” na stránce 106. Toto omezení pro zásobník, který mezi daty jmenuje poskytovatele, není specificky vynuceno autorizačním jádrem. Naopak, setká-li se jádro s více příklady stejné položky ADI (například TxInfo), jednoduše je přidá do všech dokumentů XML pro ADI, aby tam mohly být použité při vyhodnocení. V dokumentu XML pro ADI mohou být dvě položky dat ADI se stejným jménem zásobníku ve vstupním dokumentu XML pro ADI. Pot om se předpokládá, že jsou strukturované přesně stejným způsobem. Například, určitý požadavek aplikace by mohl zahrnovat množství individuálních transakcí, z nichž každý by měla své vlastní množství transakcí. Autorizační pravidlo může být formulované, aby sčítalo všechny tyto položky a porovnávalo sumu položek s předdefinovaným celkovým limitem transakcí nebo s limitem na transakci používajícím příkaz s volbou uzlu XSL. “Příklad 3” na stránce 112 v sekci
Kapitola 10. Správa autorizačních pravidel
103
“Příklady pravidel” na stránce 110 v této kapitole zobrazuje příkladové pravidlo, které sčítá více prvků transakcí tímto způsobem a dokonce počítá množství určitých prvků ADI.
Informace o rozhodnutí o přístupu do XML Dle předvolby, program pro vyhodnocování pravidla automaticky transformuje do formátu XML libovolné atributy páru jméno/hodnota, které mu byly předané volající aplikací, která byla identifikovaná jako cílová ADI pro aktuální vyhodnocení. Při transformaci atributu do formátu XML je jeho jméno použité jako jméno zásobníku datové položky XML a hodnota atributu je převedená na hodnotu XML. Jméno zásobníku položky ADI se srovná se jménem prvku XML v definici XML. Například, následující data XML jsou generovaná pro jméno atributu VPS_CREDIT_CARD s hodnotou atributu řetězce 5517 3394 8324 0965: 5517 3394 8324 0965
Jméno zásobníku a jméno prvku XML je v tomto případě VPS_CREDIT_CARD. Grafické rozhraní uživatele, rozhraní příkazového řádku a rozhraní seznamů atributů autorizačních API produktu Tivoli Access Manager nepovolují administrátorovi definovat pravidla, která obsahují platná jména zásobníků XML. Projdou-li aplikací nároky nebo kontext aplikace, které už byly změněné do formátu XML pro rozhodnutí o přístupu, program pro vyhodnocení autorizačních pravidel bude předpokládat, že data budou typu azn_string_t a formát řetězce bude XML. Jméno atributu se musí shodovat se jménem zásobníku datové položky XML. Pokud se jména neshodují, program pro vyhodnocování pravidel nevykonává svou práci správně. Program pro vyhodnocování identifikuje formát dat XML zjištěním místa znaku < na začátku hodnoty atributu. Nezačíná-li hodnota atributu znakem <, data nejsou považovaná za datovou položku XML a program pro vyhodnocení se pokusí o její převedení do formátu XML automaticky. Tento způsob identifikace se používá pouze pro atributy nebo kontext aplikace identifikovaný jako cílová ADI pro rozhodnutí o přístupu. Tedy hodnoty atributů, které nejsou typu XML, začínající znakem < nelze použít aplikací a výsledky v chybovém stavu se navrátí z rozhodnutí o autorizaci. Nejsou-li data správného typu XML, procesor XSL selže a vrátí chybu, která selhání pojmenovává. Datové položky, které by měly být definované v XML, musí být celé definované v XML a měly by se spoléhat na translační mechanismus pro položky, které nejsou typu XML, aby tam mohly být generované odpovídající jména prvků XML automaticky. Například, abyste definovali atribut, aby obsahoval definici XML MY_CREDIT_CARD_NUM, musíte přidat atribut se jménem atributu MY_CREDIT_CARD_NUM. Hodnota atributu pro MY_CREDIT_CARD_NUM je následující: <MY_CREDIT_CARD_NUM>5517 3394 8324 0965
Kompletním definováním prvku XML, v protikladu k pouhému definování jeho hodnoty, mohou být atributy XML přidané k definici prvku bez ovlivnění jména, kterým se odkazuje na ADI při komunikaci s poskytovateli dat. Například, v následující definici položky XML MY_CREDIT_CARD_NUM jsme definovali atribut XML CardType hodnotou "visa". Atributy XML jsou definované v příznaku prvního prvku toho prvku, kterého se týkají. Funkčně jsou atributy XML rovné libovolným jiným podřízeným prvkům první úrovně objektu XML. Abyste vytvořili odkaz na atribut CardType, požadovaná cesta XPath by byla: /XMLADI/MY_CREDIT_CARD_NUM/CardType
104
IBM Tivoli Access Manager: Base: Administrativní příručka
Atributy XML by se neměly plést s atributy autorizační API a seznamy atributů, které jsou použité pro přenos dat do a z autorizačních procesů. <MY_CREDIT_CARD_NUM CardType="visa"> 5517 3394 8324 0965
Schopnost přidávat atributy XML do definice prvku je částečně užitečná, když dojde na definování prostoru jmen pro datovou položku. Chcete-li získat více informací o prostoru jmen XML, viz “Definování prostoru jmen XML” na stránce 106. Obsahuje-li atribut ADO více hodnot atributů (řetězec, XML nebo jejich libovolnou kombinaci), program pro vyhodnocení převede každou hodnotu atributu jako zvláštní příklad ADI. Například, pro atribut pojmenovaný TxData s hodnotami atributů 100 a 500 vloží program pro vyhodnocení následující deklarace položek XML do dokumentu XML pro ADI: 100500
Administrátor politik může potom navrhovat autorizační pravidla, které používají příkazy s volbou uzlu jazyka XSL pro práci nezávisle s dvěma hodnotami nebo pro přidání hodnot a porovnání jejich celkového součtu s některými předdefinovanými limity. Je-li hodnota TxData porovnaná s jinou hodnotou, je s ní zacházeno jako s porovnáním sady uzlů a každá hodnota TxData je zase porovnaná s daty, přičemž rovná-li se libovolná hodnota TxData s cílovými daty, je označená jako úspěšná. Porovnání sady uzlů má ve většině případů trochu rozdílné chování, než jaké se předpokládá při použití operátoru ″!=″, a místo toho je nutné použít funkci not(). Chcete-li si prohlédnout příklad pro použití operátoru ″!=″ a not() při porovnání sady uzlů, viz “Příklad 3” na stránce 112.
Příklad nároku XML Následující příklad je dokument XML pro ADI, který by mohl projít do procesoru XSL z programu pro vyhodnocení pravidel během vyhodnocení autorizačního pravidla. Dokument obsahuje dva zásobníky: JohnSmith a AmountReqd. Hodnota atributu zásobníku JohnSmith je definovaná v XML. Zásobník AmountReqd se přeložený do XML z příchozího atributu kontextu aplikace řetězce. Zásobník JohnSmith je nárok a zásobník AmountReqd je položka kontextu transakce. Program pro vyhodnocení autorizačních pravidel automaticky zahrne všechna data pod deklarací nejvyššího uzlu XML XMLADI při vytvoření dokumentu XML pro ADI, takže tento nejvyšší prvek byl přidaný pro lepší srozumitelnost. Dokument XML, který projde do rutin vyhodnocování programem pro vyhodnocení autorizačních pravidel je následující: <XMLADI> <JohnSmith> 012345677654321010000.002000.00 <MileagePlus> <MemberStatus>100k 12345678 <MileagePlus> <JohnSmith>
Kapitola 10. Správa autorizačních pravidel
105
500.00
Když se odkazujete na určitou položku ADI v dokumentu XMLADI dostupném pro pravidlo, specifikátor cesty XPath může začínat od jména zásobníku prvku XML, například JohnSmith, neboť předvolené pravidlo šablony se shoduje s prvkem /XMLADI automaticky. Pokud chtějí volající uvést svůj vlastní příkaz odpovídající šabloně explicitně, mohou tak učinit. V tomto příkladu jsou jména zásobníků ADI JohnSmith a AmountReqd. Abyste získali další informace, viz “Formát a omezení pravidel” na stránce 108.
Definování prostoru jmen XML Prostory jmen XML jsou použité pro rozlišení mezi položkami XML se stejným jménem nebo dat XML skupiny se stejným typem nebo funkcí. Stejné principy lze použít s ADI, která je definovaná pro použití s autorizačními pravidly. Například, databáze zákazníka a databáze soupisu produktů by mohly obě definovat ADI nazývanou name, která by mohla být použitá v autorizačních pravidlech. Definováním prostorů jmen XML s ID item, můžete rozlišit tyto dva příklady name tak, že budete ADI z databáze produktů volat jako item:name. Tento příklad poskytuje definici pro prostor jmen item: xmlns:item="http://mycompany/namespaces/items
kde xmlns je standardní jméno atributu XML a item je ID zvolené pro prostor jmen. URI následující = je použité pro rozlišení jednoho ID prostoru jména od druhého. Tato deklarace prostoru jmen vztahuje ID prostoru jmen item k řetězci URI: http://mycompany/namespaces/items
Hodnota řetězce URI není následkem XML a procesorů XSL, ale musí být jedinečná. Na rozdíl od XML a procesorů XSL, autorizační jádro Tivoli Access Manager nepovoluje, aby byly dvěma ID prostorům jmen přiřazené stejné hodnoty URI, protože URI se používají pro jedinečné označení samotného prostoru jména. Definováním dvou prostorů jmen se stejnými URI má za následek chybu inicializace, autorizační aplikace se nespustí a chyba bude zaprotokolovaná do chybového protokolu aplikace. Zdroj, ze kterého má být zasláno jméno položky, si musí být vědom tohoto vztahu. Zdroj musí být schopen vytvářet spojení mezi požadovanou item:name autorizačním jádrem a daty name uloženými v databázi produktů. Zdroj musí být také schopen poskytnout tato data autorizačnímu jádru v atributu nazývaném item:name, když je to potřeba. Například, služba vyvolání dynamické ADI musí být srozuměná s tím, že když je požádaná o item:name, měla by načíst požadovanou hodnotu tak, že bude hledat name v databázi produktů. Služba musí navrátit data do autorizačního jádra v atributu nazývaném item:name. Používá-li aplikace prostor jmen, aby tak rozlišila nebo seskupila položky ADI, je od ní požadováno, aby definovala prostor jmen pro XML i procesory XSL. Abyste definovali prostor jmen pro procesor XSL, přidejte definici prostoru jmen do záznamu konfiguračního souboru xsl-stylesheet-prolog, kterým se zabývá “input-adi-xml-prolog a xsl-stylesheet-prolog” na stránce 116. Následující je příklad, jak přidat definici prostoru jmen pro prostor jmen položky do záznamu xsl-stylesheet-prolog: xsl-stylesheet-prolog = <xsl:stylesheet xmlns:xsl=’http://www.w3.org/1999/XSL/Transform’ xmlns:item="http://mycompany/namespaces/items" version=’1.0’> <xsl:output method = ’text’ omit-xml-declaration=’yes’ encoding=’UTF-8’ indent=’no’/> <xsl:template match=’text()’>
106
IBM Tivoli Access Manager: Base: Administrativní příručka
Jsou dva způsoby jak definovat prefix prostoru jmen do procesoru XML: v Definuje prostor jmen globálně pro celý dokument XMLADI. v Definujte jej individuálně v těch položkách ADI, které používají tento prefix. V obou případech musí být deklarace prostor jmen zahrnutý ve spouštěcím příznaku prvku XML. První a nejjednodužší metoda jak definovat prostor jmen pro procesor XML je přidat definici prostoru jmen do spouštěcího příznaku prvku dokumentu XMLADI. Přidání definice do spouštěcího příznaku prvku dokumentu XMLADI je nejjednodužší, protože toto automaticky definuje prostor jmen pro celý dokument. Libovolné položky ADI v dokumentu, jejíchž jméno mají prefix s tímto ID prostoru jmen, tedy nemají definici prostoru jmen přidanou do jejich vlastního spouštěcího příznaku prvku. Tato metoda netrpí na žádné z nedostatků definování prostorů jmen s použitím druhé metody. Objekt stanza [xmladi-attributedefinitions] byl přidaný do konfiguračního souboru, aby tak byla zákazníkům umožněno definovat prostory jmen globálně pro použití v dokumentu XMLADI. Chcete-li získat informace, jak přidávat definice prostorů jmen do objektu stanza [xmladi-attributedefinitions], viz “[xmladi-attribute-definitions]” na stránce 116. Druhá metoda zadávání definice prostoru jmen XML do procesoru XML je přidat definici do hodnoty XML samotného prvku ADI. Například, je-li dáno jméno zásobníku ADI item:name a hodnota řetězce pro položku Widget A, abyste přidali definici prostoru jmen XML do položky XML item:name, museli byste definovat item:name v XML následujícím způsobem: Widget A
Položka item:name ADI musí být přidaná do seznamu atributů se jménem atributu item:name a hodnota atributu by byla celá definice prvku XML uvedená nad jako jednoduchý souvislý textový řetězec. Existuje několik vad při definování prostorů jmen XML v definici XML každé položky ADI spíše než při globálním definování pro celý dokument XMLADI. Například, hodnota libovolných položek ADI, které používají prefix ID prostoru jmen musí být v XML, protože definice prostoru jmen může být přidaná pouze do definice XML hodnoty položky, jak je znázorněno pro item:name výše. Toto má za výsledek, že položky ADI prefixů prostorů jmen nemohou mýt jednoduše hodnotu 100. Hodnota položky musí být fragment XML, jako je řetězec <prefix:adi_name>100. Libovolný zdroj ADI, který může poskytovat hodnoty pro proložky ADI s prefixy prostorů jmen, by potřeboval zajistit, že odpovídající definice prostorů jmen pro danou položku jsou přidané pro každou navrácenou formátovanou hodnotu XML. Nena vrátí-li služba formátovaná data XML a není-li si vědoma prefixů prostorů objektů, musí být změněna, aby takto prováděla. Takto přepíná na zvýšenou aktivity požadované pro provedení úlohy pro služby vyvolání dynamické ADI. Definováním prostorů jmen globálně se lze vyhnout všem podobným komplikacím. Nebyl-li prostor jmen definovaný pro buď XML nebo procesor XSL, pak se do chybového protokolu zaprotokoluje chyba, což má vliv na to, že ID prostoru jmen nemá vztahující se mapování URI. Toto se může stát během tvorby pravidla, nebyl-li procesoru XSL oznámen nový prostor jmen, nebo během vyhodnocování pravidla, nebylo-li toto oznámeno procesoru XML.
Program pro vyhodnocování autorizačních pravidel Program pro vyhodnocování autorizačních pravidel vyhodnocuje autorizační pravidla v rámci omezení požadovaných autorizačním jádrem.
Kapitola 10. Správa autorizačních pravidel
107
Program pro vyhodnocování autorizačních pravidel se řídí politikou pravidel, která je připojená k cílovému chráněnému objektu a vyhodnocuje pravidla voláním procesoru XSL. Vstupní dokument XML pro transformaci vytváří obrazec z dat nároků definovaných v pověření uživatele, který žádá o autorizaci, z kontextu aplikace zaslaného společně s voláním o rozhodnutí o přístupu, z požadované ADI a autorizačního jádra a z ADI načtené z volání do služeb nároků vyvolání dynamické ADI. Autorizační jádro předpokládá, že pravidla vyhodnocení budou mít za výsledek návrat jednoho z identifikátorů řetězců, jak uvádí Tabulka 3. Identifikátory byly zvolené, aby zajišťovaly jedinečnost v událostech, kde je pravidlo nesprávně zapsané. Vyhodnocování navrátí nesprávnou informaci. Oddělení identifikátorů vykřičníkem (!) umožňuje programu pro vyhodnocování označit případy typu errant. Tabulka 3. Identifikátory řetězců navrácené vyhodnocováním pravidel Oddělovač
Význam
!TRUE!
Přístup je povolen.
!FALSE!
Přístup je odepřen.
!INDIFFERENT!
Jádro pravidel nemá žádnou volbu.
Identifikátory by měly být jediným textem ve výstupním dokumentu, přestože mohou být ohraničené neviditelnými znaky. Je-li hodnota (jiná než definované platné hodnoty nebo prázdný dokument) navrácená, rozhodnutí o přístupu selže a do správce zdrojů bude navrácen chybový kód, který označí, že pravidlo není vyhovující. Formát autorizačního pravidla je nastíněný v části “Formát a omezení pravidel”. Navíc, maximální délka jakéhokoliv výsledného textu navráceného vyhodnocováním pravidel je omezeno na 1023 znaků. Pravidla, která navrátí větší textový výstup než tento způsobí selhání rozhodnutí o přístupu v běhovém čase s vedlejším chybovým kódem ivacl_s_rule_result_string_too_large.
Formát a omezení pravidel Tato sekce se zabývá omezeními, která jsou uvalená na pravidla XSL modelem XML pro ADI XML. Tato sekce se nezabývá detaily vysvětlujícími programovací jazyk XSL, jeho syntaxi nebo sadu standardních podporovaných funkcí. Šířka funkčnosti procesoru XSL a schopnosti jazyka provést dokumentaci dělají z tohoto jazyka příliš složitou úlohu pro tento dokument. Existuje počet průvodců programátora XSL (XSLT) dostupných v knihkupectvích, které se pro tento úkol hodí lépe. Autorizační pravidlo musí být definované jako šablona XSL v rámci stylového papíru XSL používajícího prolog stylového papíru uvedeného v konfiguračním souboru. Pravidlo musí být zapsané v platném formátu pravidla pro šablony XSL a musí navrátit textový výstupový dokument, který obsahuje jeden z následujících identifikátorů řetězce: !TRUE!, !FALSE!, or !INDIFFERENT!. Chcete-li získat více informací o identifikátorech řetězců, viz “Program pro vyhodnocování autorizačních pravidel” na stránce 107. Pro rozhodnutí o autorizace musí pravidlo do programu pro vyhodnocování pravidel navrátit předpokládaná data rozhodnutí. Data, která jsou navrácená z rozhraní nároků řízených pravidly musí být schopné vyjádření jako textový pár atributů jména/hodnoty ve výstupním parametru nároků volání azn_entitlement_get_entitlements(). Mnoho poskytovatelů dat vrací data nároků do formátu XML; takto nejsou požadované žádné další transformace, aby tyto požadavky prošly do programu pro vyhodnocování pravidel jako ADI.
108
IBM Tivoli Access Manager: Base: Administrativní příručka
Všechny ADI, které projdou do programu pro vyhodnocování pravidel musí být uvedené v XMLa a ADI, která projde do rozhodnutí o přístupu nebo načtená z pověření, které není v XML, jsou formátované jako takové programem pro vyhodnocování pravidel předtím, než lze vyhodnotit autorizační pravidlo. Výsledkem transformace XSL provedené autorizačním pravidlem XSL musí být textový výstupní dokument obsahující pouze jeden z identifikátorů řetězců, které jsou vypisuje Tabulka 3 na stránce 108. Identifikátory musí být jediným textem ve výstupním dokumentu, ale mohou být obklopené neviditelnými znaky. Identifikátory nejsou citlivé na velikost písmen. Je-li navrácena hodnota jiná, než jsou ty vypsané na seznamu, nebo prázdný dokument, dojde k selhání rozhodnutí o přístupu kvůli autorizačnímu jádru a do správce zdrojů označujícího, že pravidlo není vyhovující, bude navrácen chybový kód. Následující příklad odkazuje k datové položce XML definované v JohnSmith. Následující je podmínka, že příkladové vyhodnocování pravidel je vyjádřené: if ((AmountReqd + Credit Card Balance) < Credit Card Limit && MileagePlus Status is "100k")
Toto příkladové pravidlo je ta nejjednodušší forma pro uvedení autorizačního pravidla. Nezahrnuje svůj vlastní příkaz odpovídající šabloně a přijímá předvolený příkaz odpovídající šabloně, který je nastavený na /XMLADI. Příkazy odpovídající šabloně jsou postavené na jazyce XSL, který se používá pro zvolení bodu v hierarchii dokumentů XML, na které budou aplikovaná pravidla XSL, která jsou obsažený v příkazech odpovídajících šablonám. Předvolený příkaz odpovídající šabloně modelu XML pro ADI se shoduje od shora dokumentu XMLADI uvedením cesty XPath /XMLADI. Abyste přidali váš vlastní příkaz odpovídající šabloně do definice pravidel, potřebujete další řádky. Například, abyste přepsali příklad tak, aby obsahoval váš vlastní explicitní příkaz odpovídající šabloně, který se shoduje od kořene dokumentu XMLADI, upravili byste pravidlo následujícím způsobem: <xsl:template match="/XMLADI"> <xsl:if test="(AmountReqd + JohnSmith/CreditCard/Balance) < JohnSmith/CreditCard/Limit and JohnSmith/MileagePlus/MemberStatus = ’100k’) !TRUE!
Abyste se mohli odkazovat na libovolné datové položky v dokumentu, cesta XPath do každého uzlu musí obsahovat uzel XMLADI. Například, abyste vytvořili přístup do podadresáře Balance v adresáři CreditCard, plná cesta by byla /XMLADI/JohnSmith/CreditCard/Balance. Je-li vystavováno pravidlo, zapisovatel pravidla musí rozumět, jaká je správná cesta XPath z aktuálního bodu stromu, použitá pro přístup k datovým uzlům a poduzlům XML. Aktuální bod stromu se zvolí použitím příkazu odpovídajícímu šabloně. Příkaz odpovídající šabloně umožňuje programátorovi XSL zkrátit cestu XPath do každého datového prvku tím, že uvede, že zpracování cesty XPath se vyskytuje níž od stromu dokumentu XML. Příkaz <xsl:template match="/XMLADI"> nařídí procesoru XSL, že všechny relativní cesty XPaths v připojeních příkazu odpovídajícímu šabloně by měly být nadále relativní také ve Kapitola 10. Správa autorizačních pravidel
109
vztahu k uzlu XMLADI. Abyste zkrátili cestu XPaths ještě víc, příkaz odpovídající šabloně by mohl být nastavený v /XMLADI/JohnSmith, přičemž byste odkaz na cestu do podadresáře Balance v adresáři CreditCard zapsali jako CreditCard/Balance. Administrátoři politik musí také provádět následující předpoklady o dokumentu stylového papíru XSL, který je vytvořený programem pro vyhodnocování pravidel tak, aby obsahoval to pravidlo, které vytvoří: v Je-li uvedený prolog stylového papíru v konfiguračním souboru klienta azn, tento prolog je importovaný do prázdného stylového papíru. Není-li uvedený žádný, bude použit následující předvolený prolog: <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0"> <xsl:output method="text" omit-xml-declaration="yes" encoding=’UTF=8’ indent="no"/> <xsl:template match="text()">
v Mimo jiné, tento prolog nastavuje syntaxi stylového papíru na verzi 1.0, která je podporovaný vloženým procesorem XSL. Prolog nastaví prostor jmen pro dokumenty XSL do xsl, což vyžaduje, aby všechny totožnosti specifické pro jazyk XSL měly prefix xsl:. Tento prefix je standardní režim operace pro stylové papíry XSL. Nejvíce atributů v tomto prologu musí být ve stylovém papíru nebo, není-li tomu tak, výsledky, které budou navrácené z programu pro vyhodnocování pravidel, nebudou vyhovovat očekávaným výsledkům. v Všechna autorizační pravidla musí být ohraničená následovně: xsl:příkaz odpovídající šabloně. Je-li pravidlo definované se svým vlastním xsl:příkaz odpovídající šabloně, bude přijato takové, jaké je. Toto přijetí umožňuje tvůrci pravidel uvést úroveň v dokumenty XML pro ADI, na které se pravidlo shoduje s datovými položkami. Avšak v tomto případě musí být odpovídající příkaz prvním příkaze, se kterým se program pro vyhodnocování pravidel setká pří potvrzení pravidla, nebo se jinak předpokládá, že neexistuje žádný příkaz odpovídající šabloně. Existuje-li odpovídající příkaz, ale nezačíná-li absolutní cestou /XMLADI, pravidlo bude navráceno jako neplatné. Relativní odpovídající příkazy nejsou na této úrovni přijaté. v Není-li v pravidle uvedený žádný odpovídající příkaz, pravidlo je automaticky ohraničeno následujícím odpovídajícím příkazem: <xsl:template match="/XMLADI"> ... <xsl:template>
v Tudíž, všechna pravidla vytvořená bez explicitního příkazu odpovídajícímu šabloně musí používat výrazy cesty XPath, které předpokládají, že uzel kontextu XML je /XMLADI. Výrazy cesty XPath pro libovolnou položku ADI musí začínat jménem zásobníku dané položky a musí být plně kvalifikované.
Příklady pravidel Následující příklady pravidel demonstrují, jak lze dokončit pravidla. v “Příklad 1” na stránce 111 v “Příklad 2” na stránce 111 v “Příklad 3” na stránce 112
110
IBM Tivoli Access Manager: Base: Administrativní příručka
Příklad 1 Tento příklad je jednoduché pravidlo, které se většinou spoléhá na ADI, která projde do volání rozhodnutí o připojení, ale také požaduje, aby byl zásobník ADI nazývaný printQuota uložený v pověření žádajícího uživatele, nebo aby prošel jako kontext aplikace. Logika rozhodnutí o připojení definovaná tímto pravidlem má povolit přístup, požádal-li tento uživatel ve skupině printUsers group o operaci tisk (p) nebo požádal-li o zařazení do fronty na tiskové úlohy pro pozdější tisk (q) a přidělená kapacita zadaných tiskových úloh na den je méně než 20. <xsl:if test=’azn_cred_groups = "cn=printUsers,o=ibm,c=us" and (contains(azn_engine_requested_actions,"p") or contains(azn_engine_requested_actions,"q")) and printQuota <20’> !TRUE!
Všechny další žádosti jsou odepřené. Všimněte si, že testovací podmínka pro jméno skupiny vrátí odpovídající výsledek bez ohledu na počet skupin, ve kterých je žádající uživatel. Podmínka je test uzlu XSL, který srovnává každou hodnotu v prvku XML azn_cred_groups s řetězcem DN. Je důležité si všimnout, že syntaxe pro určení protikladných případů (například, že žádající uživatel není ve skupině printUsers) požaduje trochu jiný výraz, protože se nejedná o test uzlu. Viz “Příklad 2”, chcete-li si prohlédnout příklad toho, zda test zjišťující, jestli sada hodnot jako atribut azn_cred_group_names obsahuje určitého člena.
Příklad 2 V následujícím příkladu pravidlo pracuje s daty, která jsou v autorizačním pověření. Vyhodnocuje následující atributy: v azn_cred_principal_name v azn_cred_groups v azn_cred_registry_id Každý z příkazů xsl:when je vyhodnocený. První příkaz s podmínkami, které jsou všechny pravdivé, vrátí výsledek. Každá testovaná podmínka má komentář, který vysvětluje její akci. <xsl:choose> <xsl:when test="azn_cred_principal_name = ’myuser0’"> !TRUE! <xsl:when test="azn_cred_principal_name = ’myuser1’"> !FALSE!
-->
<xsl:when test="azn_cred_registry_id = ’cn=myuser3,secAuthority=Default’"> !TRUE! <xsl:when test="azn_cred_groups = ’mygroup1’ and not (azn_cred_groups = ’mygroup2’)"> !TRUE!
Kapitola 10. Správa autorizačních pravidel
111
<xsl:otherwise> !FALSE!
Čtvrtý příkaz xsl:when používá funkci not(), aby negoval booleovský výsledek následujícího testu: azn_cred_groups = ’mygroup2’
Funkce not() se používá místo platného operátoru autorizačních pravidel !=, protože v tomto případě je atribut azn_cred_groups atributem s více hodnotami. Atributy s více hodnotami jako azn_cred_groups vrátí k otestování podmínkou sadu hodnot, na kterou se odkazuje jako sada-uzlů v XSL. Každá hodnota uzlu v sadě je testovaná proti podmínce individiálně a vrátí se hodnota !TRUE!, je-li nějaká z podmínek vyhodnocená jako pravdivá. V dalších případech, kdy je uživatel ve více než jedné skupině jiné než mygroup2, je výsledek testu uzlů vždy !TRUE!. Abyste otestovali existenci něčeho v sadě-uzlů, použijte funkci not() místo operátoru !=. Například, můžete otestovat, že podmínka group is mygroup2 (skupina je mygroup2) není pravdivá.
Příklad 3 Tento příklad vyhodnocuje data XML definovaná aplikací. Předpokládaný objekt XML je objekt dávkového zpracování obsahující seznam operací, které se mají dohromady vykonat. Objekt dávkového zpracování se skládá s libovolného počtu transakčních prvků, které se skládají s položky a množství položek k seřazení. <max_tx_count>5 <max_tx_amount>150 customerAwidgetA10widgetB20widgetC30widgetD40widgetE50
Autorizační pravidlo kontroluje, že žádající uživatel je členem skupiny, jejíž jméno se shoduje se jménem účtu v transakci (v tomto příkladu to je customerA). Není-li žádající uživatel členem této skupiny, nebude mu poskytnuto oprávnění k zadání požadavků o dávkové
112
IBM Tivoli Access Manager: Base: Administrativní příručka
zpracování za customerA. Potom pravidlo kontroluje, že celkový počet transakcí v dávkovém zpracování je menší nebo rovný prvku max_tx_count objektu dávkového zpracování a že celkový počet položek objednaných v celé žádosti je menší než prvek max_tx_amount objektu dávkového zpracování. Pravidlo volá funkce count() a sum(). Funkce count() sčítá počet instancí transakčních prvků v dávce. Funkce sum() vyhodnotí celkovou hodnotu všech množství prvků ve všech transakčních prvcích v dávce. Pravidlo je následující: <xsl:if test="azn_cred_groups = batch/account and count (batch/transaction) <= batch/max_tx_count and sum (batch/transaction/amount) <= batch/max_tx_amount"> !TRUE!
Metody poskytování ADI programům pro vyhodnocování pravidel Aplikace správce zdrojů může poskytnout ADI ze správce zdrojů do programu pro vyhodnocování pravidel následujícími způsoby: v Přidáním atributů do parametru kontextu aplikace. v Konfigurací na dodávání chyvějící ADI do autorizačního jádra pouze tehdy, je-li žádáno explicitně. První metoda poskytuje ADI přidání atributů do parametru kontextu aplikace, který projde do volání azn_decision_access_allowed_ext(). Problém s touto metodou je, že správce zdrojů musí buď znát, kterou ADI bude potřebovat libovolné rozhodnutí o připojení, nebo spíš musí poskytnout všechny ADI pro všechna známá pravidla do autorizačního jádra pro každé volání o rozhodnutí o přístupu bez ohledu na to, je-li pravidlo vyvolané v rozhodnutí. První metoda by mohla být přijatelná a dokonce požadovaná pro menší sadu ADI. Avšak pro delší a členitější sady možných ADI je potřebná druhá metoda. Můžete konfigurovat správce zdrojů tak, aby dodávat chybějící ADI do autorizačního jádra pouze tehdy, je-li o to explicitně žádáno. S touto metodou lze autorizační jádro konfigurovat se sadou prefixů ADI, které mohou být poskytnuté na požadavek správce zdrojů. V autorizačním jádru dojde k selhání rozhodnutí o přístupu a upozorní správce zdrojů na ADIm kterou potřebuje v atributu informace o oprávnění vrácené voláním azn_decision_access_allowed_ext(). Atribut obsahuje seznam ADI, které byly potřebné pro úspěšné vyhodnocení pravidla. ADI nebyla nalezena v kontextu aplikace, která prošla dovnitř a neměla prefix shodující se s těmi, které správce zdrojů identifikoval jako své vlastní. Atribut informací o oprávnění se jmenuje azn_perminfo_rules_adi_request a obsahuje hodnotu textového atributu pro každou položku požadované ADI. Správce zdrojů hledá atribut, dojde-li k selhání rozhodnutí o připojení, a v aktuální události skenuje seznam jmen ADI v atributu a shromažďuje požadovaná data, aby mohl provést nový pokus o rozhodnutí o připojení s těmito dodatečnými daty. Nelze-li poskytnout požadovaná data, správce zdrojů by měl odepřít přístup a protokolovat problém jako selhání kvůli nedostatečným datům pravidel. Požadovaný seznam obsahuje pouze položky ADI, které jsou označené jako poskytované správcem zdrojů. Jedinečný prefix přidaný ke jménu atributu je použitý pro označení ADI. Všichni správci zdrojů poskytující data do procesu vyhodnocení tímto způsobem musí definovat jedinečný prefix, kterými je označená jejich sada dat ADI. Informace o oprávnění jsou navrácené do aplikace správce zdrojů pouze tehdy, nebyl-li klient autorizace konfigurovaný tímto způsobem. Abyste aktivovali návrat atributu informací o oprávnění azn_perminfo_rules_adi_request, jméno tohoto atributu musí být buď přidané Kapitola 10. Správa autorizačních pravidel
113
do inicializačního atributu azn_init_set_perminfo_attrs nebo ekvivalentní záznam objektu stanza konfiguračního souboru permission-info-returned v objektu stanza [aznapi-configuration]. Prefixy ADI, které jsou rozeznané správcem zdrojů, mohou být konfigurované s použitím záznamu konfiguračního souboru resource-manager-provided-adi nebo inicializačního atributu azn_init_resource_mgr_provided_adi. Viz 253, chcete-li vědět víc o záznamech objektů stanza konfiguračních souborů nebo pro další vysvětlení viz “resource-manager-provided-adi” na stránce 115. Inicializačním atributem azn_init_resource_mgr_provided_adi se podrobněji zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Autorizační jádro se pokusí anticipovat potřebu požadovat informaci od správce zdrojů tím, že obdrží objekt politiky pravidla na chráněném objektu na počátku procesu rozhodnutí o přístupu. Autorizační jádro potom porovná požadovanou ADI v pravidle se jmény ADI v parametru kontextu aplikace, který je dodaný správcem zdrojů. Jména ADI, která chybí v kontextu aplikace a která jsou specifická pro správce zdrojů, jsou přidaná do navráceného objektu informací o oprávnění. Prefixy ADI musí být jedinečné, aby se označovaly jako ADI správců zdrojů a aby se tak vyhnuly konfliktu s ADI poskytovanou v pověření a autorizačního jádra a jinými externími poskytovateli dat.
Kódy příčiny pro selhání pravidel Je-li zvolen tento režim operace, autorizační jádro zpracuje všechny politiky pro rozhodnutí o přístupu jako obvykle, ale dojde-li k selhání vyhodnocování pravidla, jádro navrátí v seznamu atributů informací oprávnění hodnotu access denied spolu s kódem příčiny pro selhání pravidla. Jméno atributu informace o oprávnění je azn_perminfo_reason_rule_failed. Tato funkce umožňuje cílové aplikace selhat nebo povolit k žádost o přístup založenou na kód příčiny selhání pravidla, který je poskytnutý správcem zdrojů. Je-li přístup odepřený, aplikace musí zkontrolovat seznam atributů permission_info navrácený z volání o rozhodnutí o přístupu, aby tak bylo zjištěno, byl-li kód příčiny selhání pravidla navrácený z rozhodnutí o přístupu. Správce zdrojů nepotřebuje kontrolovat atributy, je-li volání o rozhodnutí o připojení úspěšné. Aplikace IBM Tivoli Access Manager for e-business je příkladem správce zdrojů aznAPI, který může využít kódu příčiny selhání pravidla. Je-li takto konfigurovaný, aplikace IBM Tivoli Access Manager for e-business postoupí kód příčiny selhání pravidla chráněné webové aplikace v proměnné prostředí HTML. Chráněná webová aplikace musí být připojená přes zabezpečené spojení, aby měla přístup do kódu příčiny selhání pravidla definovaném pro autorizační pravidlo. Použití kódu příčiny selhání pravidla v aplikaci IBM Tivoli Access Manager for e-business je omezeno na prostory chráněných objektů spojených webových aplikací. Hodnota atributu (kód příčiny) atributu azn_perminfo_reason_rule_failed je jednoduchý řetězec, jehož hodnota je určená a definovaná administrátorem politik a nastavená v objektu politiky pravidla při jeho vytvoření. Jediné omezení v hodnotě kódu příčiny je, že musí být řetězec. Následující podmínky musí být splněné než se kód příčiny selhání pravidla navrátí do volajícího: v Kód příčiny se navrátí pouze, když je žádost o přístup odepřená a vyhodnocování politiky pravidel odepře přístup, ale ne pro každý případ, ve kterém je přístup odepřený. Kód příčiny není navrácený, pokud je vyhodnocování pravidel úspěšné. Kód příčiny selhání pravidla nebude navrácený, selhalo-li pravidlo kvůli chybě v syntaxi pravidla nebo byla-li
114
IBM Tivoli Access Manager: Base: Administrativní příručka
ADI nedostačující, aby mohlo být provedené vyhodnocování pravidel. V těchto pozdějších případech došlo k selhání rozhodnutí o autorizaci se chybovým stavem. v V připojeném objektu politik pravidel musí být nastavený kód příčiny. Tato hodnota je nastavená v politice pravidel s použitím API administrátora nebo příkazu pdadmin. v Aplikace aznAPI musí být aktivovaný, aby navrátila příčinu selhání pravidla jako informaci o oprávnění. Aby se tak dělo, buď inicializační parametr azn_init_set_perminfo_attrs nebo ekvivalentní záznam konfiguračního souboru v objektu stanza [aznapi-configuration] (záznam objektu stanza permission-info-returned) musí obsahovat jméno atributu azn_perminfo_reason_rule_failed. Toto umožňuje atributu, aby byl navrácen autorizačním jádrem ve výstupním parametru informace o oprávnění (perminfo) azn_decision_access_allowed_ext(). Chcete-li získat více informací o informacích o oprávnění a jak konfigurovat autorizační jádro tak, aby je navracelo, viz publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference.
Konfigurační soubor a inicializační atributy Několik záznamů konfiguračních souborů a inicializačních atributů bylo definováno, aby kontrolovaly aspekty inicializace programu pro vyhodnocování pravidel v autorizačním jádře. Konfigurační záznamy jsou umístěné v konfiguračním souboru správce zdrojů. Příklad takového konfiguračního souboru aznAPI.conf je poskytnutý v adresáři example/authzn_demo/cpp sady programů ADK (Application Developer Kit) produktu Tivoli Access Manager. Konfigurační soubory jsou používané také aplikacemi správce zdrojů produktu Tivoli Access Manager, jako je IBM Tivoli Access Manager for e-business, a tyto konfigurační záznamy mohou být přidané do konfiguračních souborů těchto aplikací. Chcete-li vědět víc o konfiguračních souborech aplikací, odkazujeme vás na dokumentaci pro specifické aplikace produktu Tivoli Access Manager. Inicializační atributy jsou programovým ekvivalentem konfiguračních atributů a jsou zamýšlené, aby byly použité k vývoji přizpůsobených aplikací správců zdrojů. Chcete-li získat více informací o inicializačních atributech specifických pro autorizační pravidla a o procesu vývoje přizpůsobených aplikací správce zdrojů aznAPI, viz publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference.
resource-manager-provided-adi Konfigurační záznam objektu stanza resource-manager-provided-adi definuje prefixy, které autorizační jádro používá pro určení sady chybějících ADI, které jsou poskytované správcem zdrojů. Tento záznam používá prefix řetězce jako svou hodnotu. Abyste mohli uvést více než jeden prefix, musíte přidat více záznamů objektů stanza jako v následujících příkladech: resource-manager-provided-adi = sales_customer_ resource-manager-provided-adi = sales_item_
Tyto příklady oznamují autorizačnímu jádru, že aplikací správce zdrojů musí být poskytnutá libovolná ADI, kterou požaduje a začíná sales_customer_ nebosales_item_. Položky ADI pojmenované sales_customer_name, sales_customer_address, sales_item_count a sales_item_price jsou příklady ADI, kterou by autorizační jádro žádalo ze správce zdrojů.
dynamic-adi-entitlement-services Konfigurační záznam dynamic-adi-entitlement-services vypisuje ID služeb dynamických služeb nároků načtení ADI, které by měly být volané autorizační jádrem při události zjištění chybějící ADI v pověření žádajícího uživatele nebo v kontextu aplikace, a nelze ji shromáždit ze správce zdrojů. Libovolné služby nároků konfigurované pod tímto záznamem jsou volané autorizačním jádrem používajícím rozhraní azn_entitlement_get_entitlements() a projdou Kapitola 10. Správa autorizačních pravidel
115
do atributu azn_perminfo_rules_adi_request. Hodnoty řetězce tohoto atributu jsou jména zásobníků ADI, které jsou stále požadované. Může-li dynamická služba načtení ADI naplnit požadavek, navrátí požadované data do autorizačního jádra v parametru entitlements. Příklady služeb nároků, které mohou být použité v tímto způsobem, jsou Cred Attributes Entitlement Service a Entitlement Service Demo, jež jsou oba poskytované produktem Tivoli Access Manager. Chcete-li získat více informací o tom, jak konfigurovat a používat tyto služby nároků, viz publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Abyste uvedli, že autorizační jádro by mělo volat více dynamických služeb načtení ADI, musíte uvést více záznamů. Následující příklady demonstrují jak uvést ID služeb dvou různých služeb nároků pro použití jako dynamické služby nároků ADI. ID služeb musí odpovídat platným definicím služeb nároků v objektu stanza [aznapi-entitlement-service]. dynamic-adi-entitlement-services = ent_cred_attrs_id dynamic-adi-entitlement-services = ent_svc_demo_id
input-adi-xml-prolog a xsl-stylesheet-prolog Konfigurační záznamy input-adi-xml-prolog a xsl-stylesheet-prolog byly definované tak, aby umožňovaly přírůstek příkazů prologu XML a XSL, které jsou připojené před dokument XML pro ADI a stylový papír autorizačního pravidla, než projdou do programu pro vyhodnocování pravidel ke zpracování. Formát a předvolby pro každý z těchto záznamů jsou: input-adi-xml-prolog=
Kvůli omezením vystaveným modelem autorizačního pravidla zde je řada atributů prologu, které jsou požadované autorizačním jádrem (všechny z nich jsou uvedené v předvolených záznamech prologu). Jsou-li libovolné z těchto atributů změněné nebo vynechané ze záznamu, dojde k selhání spuštění klienta autorizace a bude navrácena chyba. Poznámka: Ujistěte se, že jste se seznámili s procesorem XSL Xalan, procesorem XML Xerces a použitím příkazů prologu dříve, než je proveden pokus o změnu těchto záznamů, které jsou poskytnuté jako předvolba.
[xmladi-attribute-definitions] Objekt stanza [xmladi-attribute-definitions] umožňuje zákazníkům přidávat definice atributů XML jako definice prostoru jmen XML do spouštěcího příznaku dokumentu XMLADI. Například, chce-li aplikace použít prostor jmen, aby tak rozlišila nebo seskupila položky ADI, čímž se zabývá “Definování prostoru jmen XML” na stránce 106, procesor XML musí být upozorněný v prostoru jmen s použitím definice prostoru jmen XML. Definice prostoru jmen lze přidat do tohoto objektu stanza a je automaticky přidaná do spouštěcího příznaku prvku dokumentu XMLADI. Přínos přidání definic, jako jsou tyto do spouštěcího příznaku dokumentu XMLADI používajícího tento mechanismus, je, že definice atributů jsou potom dostupné pro všechny položky ADI definované v dokumentu XMLADI, nezáleží na tom, jestli jsou jejich hodnoty načtené z pověření, generované autorizačním jádrem nebo načtené dynamickou službou nároků ADI. Například: [xmladi-attribute-definitions] xmlns:myNS = "http://myURI.mycompany.com" appID = ’"Jupiter" - Account Management Web Portal Server #1.’
116
IBM Tivoli Access Manager: Base: Administrativní příručka
Spouštěcí příznak prvku XMLADI, který je výsledkem těchto definic, je: <XMLADI xmlns:myNS="http://myURI.mycompany.com" \ appID=’"Jupiter" - Account Management Web Portal Server #1.’>
Jak ID prostoru jmen myNS tak atribut appID jsou nyní definované globálně v dokumentu XMLADI.
Správa autorizačního pravidla Lze provést následující úlohy vztahující se k autorizačním pravidlům: v “Tvoření autorizačního pravidla” v “Výpis autorizačních pravidel” na stránce 118 v “Vymazání autorizačního pravidla” na stránce 118 v “Úprava autorizačního pravidla” na stránce 119 v “Připojení autorizačního pravidla k chráněnému objektu” na stránce 120 v “Hledání objektu s připojeným autorizačním pravidlem” na stránce 120 v “Odpojení autorizačního pravidla” na stránce 121 Poznámka: Když zapisujete text pravidla do příkazového řádku pdadmin, je nutné vložit text pravidla do dvojitých uvozovek (″). Výsledkem je, že všechny dvojité uvozovky v textu pravidla musí následovat po zpětném lomítku, takže budou ignorované procesorem příkazového řádku pdadmin. Procesor XSL zachází s jednoduchými a dvojitými uvozovkami stejně za účelem definování textových řetězců, takže mohou být zaměňovány, ale musíte je vždy správně párovat. Například: pdadmin sec_master> authzrule create testrule1 "<xsl:if test=’some_piece_of_ADI =\"any string\"’>!TRUE!
Tvoření autorizačního pravidla Abyste vytvořili autorizační pravidlo s použitím Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste vytvořili nové pravidlo s použitím Web Portal Manager, proveďte následující: 1. Přihlaste se do domény. 2. Klepněte na AuthzRule → Create (Vytvořit) AuthzRule, aby se zobrazilo okno Create AuthzRule. 3. Zapište AuthzRule Name (Jméno AuthzRule) pro autorizační pravidlo, které chcete vytvořit (například, r2). Toto pole je povinné. Poznámka: Je doporučeno, abyste nepoužívali ve jménu pravidla následující znaky: ! " # & ( ) * + , ; : < > = @ \ |
4. Zapište popis autorizačního pravidla v poli Description (Popis). Například: time-of-day rule for engineering object space
5. Zapište text politiky pravidla v poli AuthzRule Text (Text AuthzRule). Toto pole je povinné. Například byste mohli kopírovat text, který je obsažený v poli pojmenovaném engineering.xsl do tohoto pole. 6. Zapište text, který chcete navrátit do správce zdrojů, pokud pravidlo popře přístup do chráněného objektu v poli Fail Reason (Příčina selhání) (například error).
Kapitola 10. Správa autorizačních pravidel
117
7. Klepněte na Create (Vytvořit). Je-li toto úspěšné, nové pravidlo se zobrazí jako odkaz na okno Manage AuthzRules (Správa AuthzRules). Zvolíte-li odkaz autorizačního pravidla, zobrazí se vlastnosti daného pravidla.
pdadmin Abyste vytvořili autorizační pravidlo s použitím obslužného programu pdadmin, přihlaste se do domény a použijte příkaz authzrule create. Například, abyste vytvořili pravidlo pojmenované r2 se souborem pravidla pojmenovaným engineering.xsl, který realizuje pravidlo denní doby pro inženýrský prostor objektů a navrací kód příčiny selhání error, zadejte následující: pdadmin sec_master> authzrule create r2 -rulefile engineering.xsl -desc "time-of-day rule for engineering object space" -failreason error
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Výpis autorizačních pravidel Abyste mohli vypsat autorizační pravidla, která byla vytvořená prostřednictvím Web Portal Manager nebo obslužného programu příkazového řádku pdadmin přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste vypsali všechny existující autorizační pravidla s použitím Web Portal Manager, proveďte následující: 1. Přihlaste se do domény. 2. Klepněte na AuthzRule → List AuthzRule (Výpis AuthzRule), abyste zobrazili okno Manage AuthzRules (Správa AuthzRule). Výpis jmen pro autorizační pravidla, která byla vytvořená v produktu Tivoli Access Manager, je zobrazený jako odkaz. Zvolíte-li odkaz autorizačního pravidla, zobrazí se vám vlastnosti daného pravidla.
pdadmin Abyste si mohli zobrazit výpis autorizačních pravidel v doméně s použitím obslužného programu pdadmin, přihlaste se do domény a použijte příkaz authzrule list. pdadmin sec_master> authzrule list
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Vymazání autorizačního pravidla Abyste mohli vymazat autorizační pravidlo s použitím Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste mohli vymazat autorizační pravidlo s použitím Web Portal Manager, proveďte následující: 1. Přihlaste se do domény. 2. Klepněte na AuthzRule → List AuthzRule (Výpis AuthzRule), abyste zobrazili okno Manage AuthzRules (Správa AuthzRule). Výpis autorizačních pravidel, která byla vytvořená v produktu Tivoli Access Manager, je zobrazený. Každé pravidlo je odkaz, který, pokud ho zvolíte, zobrazí vlastnosti pro dané pravidlo.
118
IBM Tivoli Access Manager: Base: Administrativní příručka
3. Zvolte jedno nebo více zaškrtávacích polí pro odkazy, které chcete vymazat. Například, mohli byste zvolit zaškrtávací pole pro autorizační pravidlo pojmenované r2. 4. Klepněte na Delete (Vymazat), abyste zobrazili okno Delete AuthzRules (Vymazání AuthzRule), kde budete vyzváni, abyste potvrdili nebo zrušili výmaz.
pdadmin Abyste vymazali autorizační pravidlo v doméně s použitím obslužného programu pdadmin, přihlaste se do domény a použijte příkaz authzrule delete. Například, abyste smazali pravidlo pojmenované r2, zadejte následující: pdadmin sec_master> authzrule delete r2
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Úprava autorizačního pravidla Abyste upravili autorizační pravidlo s použitím Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste mohli upravit autorizační pravidlo s použitím Web Portal Manager, proveďte následující: 1. Přihlaste se do domény. 2. Klepněte na AuthzRule → List AuthzRule (Výpis AuthzRule), abyste zobrazili okno Manage AuthzRules (Správa AuthzRule). Výpis autorizačních pravidel, která byla vytvořená v produktu Tivoli Access Manager, je zobrazený. Každé pravidlo je odkaz, který, pokud ho zvolíte, zobrazí vlastnosti pro dané pravidlo. 3. Klepněte na odkaz autorizačního pravidla pro to pravidlo, které chcete změnit. Zobrazí se okno AuthzRule Properties (Vlastnosti AuthzRule)–General (Obecné). 4. Následující informace měňte podle potřeby: v popis, v text autorizačního pravidla, v příčinu selhání. Například, neexistuje-li momentálně žádný popis, přidejte jej. Pokud popis autorizačního pravidla existuje, změňte jej tak, že zapíšete nový popis v poli Description (Popis) (například můžete přidat následující: updated June 23 2003): updated June 23 2003 time-of-day rule for engineering object space
5. Klepněte na tlačítko Apply (Použít), aby byly změny účinné.
pdadmin Abyste upravili autorizační pravidlo v doméně s použitím obslužného programu pdadmin, přihlaste se do domény a použijte příkaz authzrule modify. Například, abyste změnili pravidlo pojmenované r2 tak, aby navracelo kód příčiny warning, zadejte následující: pdadmin sec_master> authzrule modify r2 failreason warning
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Kapitola 10. Správa autorizačních pravidel
119
Připojení autorizačního pravidla k chráněnému objektu Abyste mohli připojit autorizační pravidlo k chráněnému objektu s použitím Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste připojili pravidlo k chráněnému objektu s použitím Web Portal Manager, proveďte následující: 1. Přihlaste se do domény. 2. Klepněte na AuthzRule → List AuthzRule (Výpis AuthzRule), abyste zobrazili okno Manage AuthzRules (Správa AuthzRule). Výpis autorizačních pravidel, která byla vytvořená v produktu Tivoli Access Manager, je zobrazený. Každé pravidlo je odkaz, který, pokud ho zvolíte, zobrazí vlastnosti pro dané pravidlo. 3. Klepněte na odkaz pro autorizační pravidlo, které chcete připojit k objektu (například autorizační pravidlo r2). Zobrazí se okno AuthzRule Properties (Vlastnosti AuthzRule)–General (Obecné). 4. Klepněte na ouško Attach (Připojit), abyste si zobrazili výpis chráněných objektů, ke kterých je již autorizační pravidlo připojeno, pokud vůbec nějaké takové jsou. 5. Klepněte na tlačítko Attach (Připojit), abyste si zobrazili okno Attach AuthzRule (Připojení AuthzRule). 6. Zapište Protected Object Path (Cesta chráněného objektu) toho chráněného objektu, ke kterému chcete připojit autorizační pravidlo. Toto pole je povinné. Ujistěte se, že jste zapsali úplné jméno cesty. Například: /WebSEAL/tivoli.com/w3junction/index.html
7. Klepněte na tlačítko Attach (Připojit). Je-li toto provedeno úspěšně, nový chráněný objekt bude přidaný jako odkaz do seznamu objektů s připojeným autorizačním pravidlem v okně AuthzRule Properties–Attach (Vlastnosti AuthzRule–Připojit).
pdadmin Abyste připojili autorizační pravidlo k chráněnému objektu s použitím obslužného programu pdadmin, přihlaste se do domény a použijte příkaz authzrule attach. Například, abyste připojili pravidlo pojmenované r2 k chráněnému objektu pojmenovanému /WebSEAL/tivoli.com/w3junction/index.html, zadejte následující: pdadmin sec_master> authzrule attach /WebSEAL/tivoli.com/w3junction/index.html r2
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Hledání objektu s připojeným autorizačním pravidlem Abyste našli chráněný objekt s připojeným autorizačním pravidlem s použitím Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste našli chráněný objekt s připojeným pravidlem s použitím Web Portal Manager, proveďte následující: 1. Přihlaste se do domény. 2. Klepněte na tlačítka AuthzRule → List AuthzRule (Výpis AuthzRule). Zobrazí se výpis jmen autorizací. Každé jméno autorizačního pravidla je odkaz, na který můžete klepnout a zobrazí se vám okno AuthzRule Properties (Vlastnosti AuthzRule). 3. Klepněte na ouško Attach (Připojit).
120
IBM Tivoli Access Manager: Base: Administrativní příručka
pdadmin Abyste našli chráněný objekt s připojeným autorizačním pravidlem v doméně tak, že použijete obslužný program pdadmin, přihlaste se do domény a použijte příkaz authzrule find. Například, abyste našli chráněný objekt s připojeným pravidlem pojmenovaným r2, zadejte následující: pdadmin sec_master> authzrule find r2
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Odpojení autorizačního pravidla Abyste odpojili autorizační pravidlo od chráněného objektu s použitím Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste odpojili pravidlo od chráněného objektu s použitím Web Portal Manager, proveďte následující: 1. Přihlaste se do domény. 2. Klepněte na AuthzRule → List AuthzRule (Výpis AuthzRule), abyste zobrazili okno Manage AuthzRules (Správa AuthzRule). Výpis autorizačních pravidel, která byla vytvořená v produktu Tivoli Access Manager, je zobrazený. Každé pravidlo je odkaz, který, pokud ho zvolíte, zobrazí vlastnosti pro dané pravidlo. 3. Klepněte na odkaz pro autorizační pravidlo, které chcete odpojit od objektu (například autorizační pravidlo r2). Zobrazí se okno AuthzRule Properties–General (Vlastnosti AuthzRule–Obecné). 4. Klepněte na ouško Attach (Připojit), abyste si zobrazili výpis chráněných objektů, ke kterých je již autorizační pravidlo připojeno, pokud vůbec nějaké takové jsou. 5. Zvolte jedno nebo více zaškrtávacích polí pro chráněné objekty, od kterých chcete odpojit autorizační pravidlo. 6. Klepněte na tlačítko Detach (Odpojit), abyste si zobrazili okno Detach AuthzRule from Object (Odpojit AuthzRule od objektu), kde budete vyzvání, abyste potvrdili nebo zrušili požadavek.
pdadmin Abyste odpojili pravidlo od chráněného objektu v doméně s použitím obslužného programu pdadmin, přihlaste se do domény a použijte příkaz authzrule detach. Například, abyste odpojili pravidlo od chráněného objektu pojmenovaného /WebSEAL/tivoli.com/w3junction/index.html, zadejte následující: pdadmin sec_master> authzrule detach /WebSEAL/tivoli.com/w3junction/index.html
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Kapitola 10. Správa autorizačních pravidel
121
122
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 11. Správa uživatelů a skupin Výchozí administrátor domény se vytvoří vždy, když je vytvořena nová doména. Administrátor domény má od začátku nezbytná oprávnění ke správě domény. Administrátora domény můžete použít k vytvoření a konfiguraci uživatelů, skupin, zdrojů a aplikací a k delegování administrativních úloh v doméně podle potřeby. Uživatel představuje libovolnou autentizovanou totožnost Tivoli Access Manager. Obvykle uživatelé představují síťové uživatele nebo správce zdrojů. Skupina je množinou jednoho nebo více uživatelů.Administrátor může použít záznamy skupiny ACL k snadnému přiřazení stejných oprávnění pro více uživatelů. Noví uživatelé v zabezpečené doméně získávají přístup k objektům tak, že se stanou členy odpovídajících skupin. Členství ve skupině eliminuje potřebu tvořit nové záznamy ACL pro každého nového uživatele. Skupiny mohou představovat divize nebo oddělení společnosti uvnitř domény. Používat skupiny je také vhodné při definici rolí nebo funkčních sdružení. Účty odkazují na uživatele a skupiny kolektivně. UID registru (jedinečný identifikátor registru) uvádí umístění v databázi registrů, kde byl vytvořený nový uživatel. Podobně GID registru (jedinečný identifikátor skupiny registru) uvádí umístění v databázi registrů, kde byla vytvořená nová skupina. Pro UID a GID registrů musíte zapsat jméno plné cesty nového uživatele nebo skupiny. Formát cesty závisí na typu registru, který produkt používá: LDAP: cn=IBM-Support,o=ibm,c=us Active Directory: cn=IBM-Support,dc=Austin,dc=US Domino: IBM-Support/Austin/US
UID nebo GID registru poskytuje další zabezpečení pro případ, že by uživatel nebo skupina byli smazaní z domény a potom znova vytvoření se stejným jménem. Například, přestože má nový uživatel stejné jméno jako smazaný uživatel, produkt Tivoli Access Manager alokuje nové UID registru pro tohoto uživatele. Protože UID registru je nové, stávající záznamy ACL, které odkazují na staré jméno uživatele, neposkytují žádná práva pro nového uživatele. Prošlé UID z vymazaných uživatelů a skupin jsou odstraněné serverem politik (pdmgrd).
Hledání uživatelů Abyste mohli hledat uživatele s pomocí Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste mohli hledat seznam maximálně se 100 uživateli s pomocí Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Search Users (Hledat uživatele). 3. Na stránce User Search (Hledání uživatelů) použijte zástupný znak *, čímž profiltrujete jména ID uživatelů. Toto pole je povinné. 4. Použijte předvolenou hodnotu 100 nebo zapište počet Maximum Results (Maximální výsledky), čímž omezíte počet ID uživatelů, které chcete zobrazit. 5. Klepněte na tlačítko Search (Hledat), čímž zobrazíte tabulku ID uživatelů. Každé ID uživatele se zobrazí jako odkaz.
Z okna User Search (Hledání uživatelů) můžete provádět tyto úlohy: vytvářet nové uživatele, mazat jednoho nebo více stávajících uživatelů a klepnout na odkaz, čímž zobrazíte vlastnosti uživatele. 6. Použijte předvolenou hodnotu ID uživatele 15 na stránku. Nebo klepněte na tlačítko Options (Volby), kde uvedete počet ID uživatele, které chcete zobrazit na stránku; zpět přepnete klepnutím na tlačítko Hide Options (Skrýt volby). 7. Použijte předvolenou hodnotu None (Žádný), který znamená, že pro filtrování není použitý žádný text. Neb o klepněte na Filters (Filtry), abyste mohli najít ID uživatele, které začíná nebo končí textem, který uvedete; zpět přepnete klepnutím na Hide Filters (Skrýt filtry).
pdadmin Abyste našli seznam uživatelů s pomocí obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén. Například, abyste našli seznam s maximální počtem 100 uživatelů, zadejte: pdadmin sec_master> user list * 100
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Vytvoření uživatele Abyste vytvořili uživatele s pomocí Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén. Poznámka: Je-li vytvořený uživatel, administrátor domén přiřadí user name (jméno uživatele) (někdy se na něj odkazuje také jako jméno objektu). Jméno uživatele musí být jedinečné pro doménu, protože produkt Tivoli Access Manager je používá k označení tohoto uživatele. Identifikátor uživatele registru známý jako odlišené jméno (DN) je také přiřazené, aby jedinečně označovalo definici uživatele v registru uživatelů. Formát DN závisí na použitém typu registru. Přiřazené jsou také společné jméno (CN) a příjmení (SN) definovaného uživatele.
Web Portal Manager Abyste vytvořili uživatele do domény s pomocí Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na User (Uživatel)→ Create User (Vytvořit uživatele). 3. Zapište User ID (ID uživatele) (například maryj). Toto pole je povinné. 4. Klepněte na Group Membership (Členství ve skupině), abyste mohli najít skupiny, ve kterých může být uživatel členem. 5. Zapište First Name (Křestní jméno) uživatele (například Mary). Toto pole je povinné. 6. Zapište Last Name (Příjmení) uživatele (například Jones). Toto pole je povinné. 7. Zapište Password (Helso). Toto pole je povinné. Hesla musí odpovídat politikám hesla, které jsou nastavené administrátorem domén. 8. Zapište heslo znova do pole Confirm Password (Potvrdit heslo). Toto pole je povinné. 9. Zapište Description (Popis) pro ID uživatele (například Member of Marketing Group. 10. Zapište Registry UID (UID registru). Toto pole je povinné. UID registru uvádí umístění v databázi registru, kde je umístěný nově vytvořený uživatel. Například: cn=maryj,o=ibm,c=us,dc=mkt. Uživatelé Lotus Notes požadují jméno plné cesty pro vytvořeného uživatele. Například: Mary Jones/IBM/US
124
IBM Tivoli Access Manager: Base: Administrativní příručka
11. Zvolte zaškrtávací okénko Account Valid (Platný účet), čímž označíte, že nový uživatel má schopnost účastnit se v doméně. Není-li tato volba uvedená, účet nového uživatele nebude platný a tento uživatel nebude schopen se přihlásit. 12. Zvolte zaškrtávací okénko GSO User (Uživatel GSO), čímž označíte použití schopnosti Global Sign-on (Globální přihlášení) (single signon - jednoduché přihášení) produktu Tivoli Access Manager. 13. Zvolte zaškrtávací okénko Password Valid (Platné heslo), čímž vynutíte změnu hesla při příštím přihlášení uživatele do domény. Není-li tato volba uvedená, uživatel bude informovaný o tom, že jeho heslo vypršelo. 14. Klepněte na No Password Policy (Žádná politika hesla), čímž označíte, že nechcete, aby výchozí heslo podléhalo politikám hesla, které jsou nastavené administrátorem domén. 15. Klepněte na tlačítko Create (Vytvořit). Při vytvoření ID uživatele se zobrazí zpráva.
pdadmin Abyste vytvořili uživatele s pomocí Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén. Například, abyste vytvořili uživatele pojmenovaného maryj se schopností Global Sign-on (Globální přihlášení), zadejte následující na příkazový řádek pdadmin: pdadmin sec_master> user create –gsouser maryj "cn=Mary Jones,o=IBM,c=us,dc=mkt" "Mary" "Jones" pwd2pwd2
Pamatujte si, že formát odlišeného jména závisí na typu používaného registru. Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Naimportovat uživatele Abyste importovali uživatele, který už existuje v registru uživatelů, a udělali z něj uživatele produktu Tivoli Access Manager s pomocí Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén. Poznámka: Když je uživatel importovaný, administrátor domén přiřadí jméno domény (na které je někdy odkazováno jako jméno objektu). Jméno uživatel musí být v doméně jedinečné, protože je produktem Tivoli Access Manager po užívané k označení daného uživatele.
Web Portal Manager Abyste importovali uživatele, který již existuje v registru uživatelů, a udělali z něj uživatele produktu Tivoli Access Manager s použitím Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na User (Uživatel)→ Import User (Import uživatele). 3. Zapište User ID (ID uživatele) (například maryj). Toto pole je povinné. 4. Klepněte na Group Membership (Členství ve skupině), abyste mohli najít skupiny, ve kterých může být uživatel členem. 5. Zapište Registry UID (UID registru). Toto pole je povinné. UID registru uvádí umístění v databázi registru, které má být importováno. Například: cn=maryj,o=ibm,c=us,dc=mkt. Uživatelé Lotus Notes požadují jméno plné cesty pro uživatele, který má být importovaný. Například: Mary Jones/IBM/US
Kapitola 11. Správa uživatelů a skupin
125
6. Zvolte zaškrtávací okénko Account Valid (Platný účet), čímž označíte, že nový uživatel má schopnost účastnit se v doméně. Není-li tato volba uvedená, účet nového uživatele nebude platný a tento uživatel nebude schopen se přihlásit. 7. Zvolte zaškrtávací okénko GSO User (Uživatel GSO), čímž označíte schopnosti schopnost tohoto uživatele použít Global Sign-on (Globální přihlášení) produktu Tivoli Access Manager. 8. Zvolte zaškrtávací okénko Password Valid (Platné heslo), čímž vynutíte změnu hesla při příštím přihlášení uživatele do domény. Není-li tato volba uvedená, uživatel bude informovaný o tom, že jeho heslo vypršelo. 9. Klepněte na tlačítko Create (Vytvořit). Při vytvoření ID uživatele se zobrazí zpráva.
pdadmin Abyste importovali uživatele, který už existuje v registru uživatelů, a udělali z něj uživatele produktu Tivoli Access Manager s pomocí obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén. Například, abyste importovali informace o uživateli pro uživatele pojmenovaného maryj z existující definice registru uživatelů, zadejte: pdadmin sec_master> user import –gsouser maryj "cn=Mary Jones,o=IBM,c=us,dc=mkt"
Poznámka: Informace o uživateli, která byla do domény naimportována, může být znovu naimportována do jiné domény. Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Nastavení globálních politik uživatele Můžete změnit nastavení uživatele jako politiky hesel, politiky selhání přihlášení, přístupové politiky a politiky vypršení účtů. Poznámka: Platné je číslo z libovolného rozsahu. Ale pro úlohu, kterou chcete vykonat, byste měli zvolit nějaké rozumné číslo. Například, minimální délka hesla by měla by měla být dostatečná, aby ochránila váš systém a aby nebylo jednoduché heslo odhalit zadáváním různých nahodilých kombinací.
Web Portal Manager Abyste změnili globální nastavení uživatele s pomocí Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na User (Uživatel)→ Show Global User Policy (Zobrazit globální politiku uživatele). 3. Zvolte Unset (Zrušit nastavení) nebo Set (Nastavit) pro Max Login Failures (Maximální počet selhání přihlášení), čímž zrušíte nastavení nebo nastavíte maximální počet selhání přihlášení, než bude účtu zablokována účast v zabezpečené doméně. Zvolíte-li Set (Nastavit), přijměte buď předvolenou hodnotu 10 nebo ji změňte na číslo rovné nebo větší než nula. 4. Zvolte Unset (Zrušit nastavení), Disable (Zablokovat) nebo Set (Nastavit) pro Disable Time Interval (Časový interval zablokování), čímž nastavíte čas ve vteřinách, nebo zablokujete účet každého uživatele, je-li překročen maximální počet selhání přihlášení. Zvolíte-li Set (Nastavit), přijměte buď předvolenou hodnotu 180 nebo ji změňte na číslo rovné nebo větší než nula. 5. Zvolte Unset (Zrušit nastavení) nebo Set (Nastavit) pro Minimum Password Length (Maximální délka hesla), čímž nastavíte minimální počet znaků požadovaných pro
126
IBM Tivoli Access Manager: Base: Administrativní příručka
6.
7.
8.
9.
10.
11.
12.
13.
heslo. Zvolíte-li Set (Nastavit), přijměte buď předvolenou hodnotu 8 alfanumerických znaků nebo změňte hodnotu na číslo větší než nula. Zvolte Unset (Zrušit nastavení) nebo Set (Nastavit) pro Maximum Password Age (Maximální stáří hesla), čímž nastavíte maximální dobu před vypršením platnosti hesla. Maximální stáří hesla se vztahuje k poslední změně hesla. Zvolíte-li Set (Nastavit), přijměte buď předvolenou hodnotu 91 dní (91-00:00:00) nebo změňte hodnotu na číslo větší než nula. Zvolte Unset (Zrušit nastavení) nebo Set (Nastavit) pro Minimum Password Alphas (Minimální počet písmen hesla), čímž nastavíte minimiální počet abecedních znaků požadovaných pro heslo. Zvolíte-li Set (Nastavit), přijměte buď předvolenou hodnotu čtyř abecedních znaků nebo změňte hodnotu na číslo větší než nula. Zvolte Unset (Zrušit nastavení) nebo Set (Nastavit) pro Minimum Password Non-Alphas (Minimální počet nepísmenných znaků hesla), čímž nastavíte minimální počet neabecedních znaků požadovaných pro heslo. Zvolíte-li Set (Nastavit), přijměte buď předvolenou hodnotu neabecedních znaků nebo ji změňte na číslo větší než jedna. Zvolte Unset (Zrušit nastavení) nebo Set (Nastavit) pro Max Password Repeated Characters (Maximální počet opakujících se znaků hesla), čímž nastavíte maximální počet znaků, které se mohou v heslu opakovat. Zvolíte-li Set (Nastavit), přijměte buď předvolenou hodnotu dva předvolené znaky nebo ji změňte na číslo větší než dva. Zvolte Unset (Zrušit nastavení), Yes nebo No pro Password Spaces Allowed (Povolit mezery v hesle), čímž určíte, jestli jsou v hesle povolené mezery. Můžete přijmout předvolené nastavení Unset (Zrušit nastavení). Nebo můžete změnit hodnotu na Yes pro umožnění mezer v hesle nebo na No, aby se mezery v hesle nevyskytovaly. Zvolte Unset (Zrušit nastavení), Unlimited (Neomezené) nebo Set (Nastavit) pro Account Expiration Date (Datum vypršení hesla), čímž nastavíte datum vypršení hesla. Můžete přijmout předvolené nastavení Unset (Zrušit nastavení). Nebo jej můžete změnit na Unlimited (Neomezené) nebo Set (Nastavit). Zvolíte-li Set (Nastavit), zapište rok čtyřmi číslicemi v poli Year (Rok). Buď přijměte předvolenou hodnotu Jan 01-00:00:00 nebo ji změňte na datum a čas uvedený ve tvaru Month DD:hh:mm:ss. Hodiny musí být uvedené pomocí 24-hodinového rozsahu (například, 09 pro 9:00 ráno nebo 14 pro 2:00 odpoledne).. Zvolte Unset (Zrušit nastavení) nebo Set (Nastavit) pro Time of Day Access (Denní doba přístupu), čímž nastavíte politiky denní doby přístupu. Zvolíte-li Set (Nastavit), přijměte buď předvolené nastavení nebo jej změňte. Můžete změnit tyto hodnoty: v Můžete zvolit dny v týdnu, které poskytují volby. v Můřete zvolit All Day (Všechny dny) nebo Between hours of (V hodinách od - do). Zvolíte-li Between hours of (V hodinách od - do), zvolte také Start Time (Čas spuštění). Formát času spuštění je uvedený v hodinách a minutách. Doba spuštění je vyjádřená s použitím 24-hodinového rozsahu. Zvolíte-li Between hours of (V hodinách od - do), zvolte také End Time (Čas ukončení). Formát času ukončení je uvedený v hodinách a minutách. Čas ukončení je vyjádřený s pomocí 24-hodinového rozsahu. Zvolíte-li Between hours of (V hodinách od - do), zvolte také Local Time (Místní čas) nebo UTC Time (Čas UTC). Podle předvolby je časová zóna určená jako místní; UTC je univerzální souřadnicový čas (coordinated universal time). Klepněte na tlačítko Apply (Použít), čímž se změny stanou účinné.
Kapitola 11. Správa uživatelů a skupin
127
pdadmin Abyste změnili nebo nastavili informace o globálním nastavení uživatele s pomocí obslužného programu pdadmin, přihlaste se do domény jako administrátor domén a použijte příkazy pdadmin policy set. Například, abyste nastavili globální politiku uživatele na maximální stáří hesla 31 dní 8 hodin a 30 minut, zadejte: pdadmin sec_master> policy set max-password-age 031-08:30:00
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Změna hesla uživatele Abyste změnili heslo uživatele s pomocí Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén. Nové heslo musí odpovídat politikám hesla, které jsou právě účinné. Viz “Nastavení globálních politik uživatele” na stránce 126.
Web Portal Manager Abyste změnili heslo pro uvedené ID uživatele s pomocí Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na User (Uživatel)→ Change My Password (Změna mého hesla). 3. Ověřte, že User ID (ID uživatele) označuje identifikátor přihlášení pro uživatele, jehož heslo chcete změnit. 4. Zapište Current Password (Aktuální heslo) pro uvedené ID uživatele. Toto pole je povinné. 5. Zapište New Password (Nové heslo) pro uvedené ID uživatele. Toto pole je povinné. 6. Zapište heslo znova v poli Confirm New Password (Potvrzení nového hesla). Toto pole je povinné. 7. Klepněte na tlačítko Apply (Použít), čímž se nové heslo stane účinné.
pdadmin Abyste změnili heslo pro uživatele s pomocí obslužného programu pdadmin, přihlaste se do domény jako administrátor domén a použijte příkaz pdadmin user modify jméno_uživatele password. Například, abyste změnili heslo na newpasswd pro účet uživatele dlucas, zadejte: pdadmin sec_master> user modify dlucas password newpasswd
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Hledání skupin Abyste mohli hledat jména skupin s pomocí Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste našli seznam s maximálním počtem 100 skupin s pomocí Web Portal Manager: 1. Přihlaste se do domény.
128
IBM Tivoli Access Manager: Base: Administrativní příručka
2. Klepněte na Search Groups (Hledat skupiny). 3. Na stránce Group Search (Hledání skupin) použijte zástupný znak * pro filtrování jmen skupin. Toto pole je povinné. 4. Použijte předvolenou hodnotu 100 nebo zapište číslo Maximum Results (Maximální počet výsledků), abyste omezili počet jmen skupin, které chcete zobrazit. 5. Klepněte na tlačítko Search (Hledat), čímž zobrazíte tabulku jmen skupin. Každé jméno skupiny se zobrazí jako odkaz. Z okna Group Search (Hledání skupin) můžete provádět následující úlohy: vytvářet nové skupiny, mazat jednu nebo více existujících skupin a klepnout na odkaz, čímž se vám zobrazí vlastnosti dané skupiny. 6. Použijte předvolenou hodnotu 15 jmen skupin na stránku. Nebo klepněte na tlačítko Options (Volby) a zadejte počet jmen skupin, které chcete zobrazit na stránku; zpět přepnete klepnutím na tlačítko Hide Options (Skrýt volby). 7. Použijte předvolenou hodnotu None (Žádný), což znamená, že na filtrování nebude použitý žádný text. Nebo klepněte na Filters (Filtry), abyste nalezli jména skupin, které začínají nebo končí vámi uvedeným textem; zpět přepnete klepnutím na Hide Filters (Skrýt filtry).
pdadmin Abyste mohli hledat seznamy skupin s pomocí obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén. Například, abyste našli seznam s maximálním počtem 100 skupin, zadejte pdadmin sec_master> group list * 100
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Vytvoření skupiny Abyste vytvořili skupiny s použitím Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén. Poznámka: Po vytvoření skupiny přiřadí administrátor domén jméno skupiny. Jméno skupiny musí být jedinečné pro doménu, protože je produktem Tivoli Access Manager identifikaci pro označení těchto skupin. Podrobnější informace o skupinách najdete v části “Vytvořit skupiny” na stránce 162.
Web Portal Manager Abyste vytvořili skupinu v doméně s použitím Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Group (Skupina) → Create Group (Vytvořit skupinu). 3. Zapište Group Name (Jméno skupiny) pro skupinu (například, sales). Toto pole je povinné. 4. Volitelně můžete zapsat Description (Popis) pro skupinu (například, Sales). 5. Zapište Registry GID (GID registru). Toto pole je povinné. GID registru uvádí umístění v databázi registrů, kde je vytvořená nová skupina. Například: cn=Sales,o=ibm,c=us,dc=mkt. Uživatelé Lotus Notes požadují jméno plné cesty pro vytvořeného uživatele. Například: Sales/IBM/US. 6. Volitelně můžete zapsat cestu v poli Object Container (Objekt typu zásobník) pro prostor objektů produktu Tivoli Access Manager, kde se má vytvořit skupina. Kapitola 11. Správa uživatelů a skupin
129
7. Klepněte na tlačítko Create (Vytvořit). Nová skupina se zobrazí jako odkaz. Označte odkaz a zobrazí se vlastnosti nové skupiny.
pdadmin Abyste vytvořili skupinu v doméně s pomocí obslužného programu pdadmin, přihlaste se do domény jako administrátor domén a použijte příkaz pdadmin group create, čímž vytvoříte novou skupinu a libovolně ji umístíte v objektu typu zásobník skupin. Pokud objekt typu zásobník dosud neexistuje, je automaticky vytvořen. Například, abyste vytvořili skupiny pojmenovanou sales, zadejte: pdadmin sec_master> group create sales "cn=sales,o=IBM,c=us,dc=mkt" Sales
Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Naimportovat skupinu Abyste mohli importovat existující skupinu z registru uživatelů do domény a udělali z ní skupinu produktu Tivoli Access Manager s pomocí Web Portal Manager nebo obslužného programu příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén. Poznámka: Když je skupina importovaná, administrátor domén přiřadí jméno skupiny. Jméno skupiny musí být jedinečné pro doménu, protože je produktem Tivoli Access Manager identifikaci pro označení těchto skupin. Podrobnější informace o skupinách najdete v části “Vytvořit skupiny” na stránce 162.
Web Portal Manager Abyste mohli importovat existující skupinu z registru uživatelů do domény a udělali z ní skupinu produktu Tivoli Access Manager s pomocí Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Group (Skupina)→ Import Group (Importovat skupinu). 3. Zapište Group Name (Jméno skupiny) pro skupinu (například, sales). Toto pole je povinné. 4. Zapište Registry GID (GID registru). Toto pole je povinné. GID registru uvádí umístění databáze registrů skupiny, která se má importovat. Například: cn=sales,o=ibm,c=us,dc=mkt. Uživatelé Lotus Notes požadují jméno plné cesty pro uživatele, který má být importovaný. Například: sales/IBM/US. 5. Volitelně můžete zapsat cestu v poli Object Container (Objekt typu zásobník) pro prostor objektů produktu Tivoli Access Manager, kde se má vytvořit skupina. 6. Klepněte na tlačítko Import (Importovat). Nová skupina se zobrazí jako odkaz. Označte odkaz a zobrazí se vlastnosti nové skupiny.
pdadmin Abyste importovali existující skupiny z registru uživatelů do domény a udělali z ní skupinu produktu Tivoli Access Manager s pomocí obslužného programu pdadmin, přihlaste se do domény jako administrátor domén. Použijte příkaz pdadmin group import, čímž importujete existující skupinu a libovolně ji umístíte do objektu zásobníku skupin. Pokud objekt typu zásobník dosud neexistuje, je automaticky vytvořen. Například, abyste importovali existující skupinu pojmenovanou "cn=sales,o=IBM,c=us,dc=mkt" z registru uživatelů, zapište: pdadmin sec_master> group import sales "cn=sales,o=IBM,c=us,dc=mkt"
130
IBM Tivoli Access Manager: Base: Administrativní příručka
Poznámka: Informace o skupině, která byla do domény naimportována, může být znovu naimportována do jiné domény. Další informace najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Kapitola 11. Správa uživatelů a skupin
131
132
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 12. Správa certifikátů a hesel Tato kapitola popisuje, jak Tivoli Access Manager používá certifikáty pro autorizaci. Zabývá se jak certifikáty ze strany serveru tak certifikáty ze strany klienta. Navíc jsou zde popsané soubory klíčů a soubory pro uložení. Nastavení konfigurace pro předvolenou dobu trvání pro obojí, jak certifikáty a hesla souborů klíčů tak výchozí nastavení konfigurace, jsou definované. Všimněte si, že tato kapitola popisuje správu certifikátů a hesla z běhového pohledu C API administrace. Tivoli Access Manager také poskytuj dobu běhu Java pro provedení stejných úloh. Viz IBM Tivoli Access Manager for e-business Administration Java Classes Developer Reference a IBM Tivoli Access Manager for e-business Authorization Java Classes Developer Reference, chcete-li více informací o administraci doby běhu a tříd programu Java. Tato kapitola zahrnuje: v “Výchozí konfigurace” na stránce 134 v “Informace o obnově souboru klíčů a souboru pro uložení” na stránce 135 v “Rozhodnutí o důvěře” na stránce 136 v “Odvolání certifikátu serveru” na stránce 136 v “Další pokyny pro soubory klíčů a soubory pro uložení” na stránce 137 Komponenty produktu Tivoli Access Manager používají protokol SSL pro šifrování, systémovou autentizaci a autentizaci na úrovni aplikací. Protokol SSL používá pro svou práci certifikáty. V zabezpečeném prostředí jedná server politik jako vydavatel certifikátu (CA) a je zodpovědný za tvoření a obnovení certifikátů. Sada programů Access Manager Runtime (PDRTE) spoléhá pouze na autentizace ze strany serveru SSL a nepožaduje certifikát ze strany klienta. Ale všechny servery Tivoli Access Manager, jako je server politik (pdmgrd), autorizační server (pdacld), proxy server politik ( pdmgrproxyd) a servery správců zdrojů, spoléhají na certifikáty ze strany klienta, aby mohly fungovat. Servery Tivoli Access Manager používají certifikáty k vlastní autentizaci. Například pokud server pdacld komunikuje se serverem pdmgrd, pak mu předloží svůj certifikát klienta. V tomto příkladě server pdmgrd může být považován za server a pdacld za klienta. Serverpdmgrd ověří, že je certifikát platný a je podepsaný důvěryhodným signatářem. V tomto případě je důvěryhodný signatář sám server pdmgrd používající certifikát PDCA (certifikát vydavatele certifikátu Tivoli Access Manager). Server pdacld provede to samé pro certifikát předložený serverem pdmgrd. Další částí autentizace produktu Tivoli Access Manager na úrovni aplikace je, že poté co server pdmgrd určí, že certifikát serveru pdacld je v pořádku, se tento server pokusí namapovat daný certifikát na uživatele produktu Tivoli Access Manager.Pokud je autentizace úspěšná, pak servery začnou spolu komunikovat. Certifikáty použité produktem Tivoli Access Manager jsou uchované v souborech klíčů. Soubory klíčů mají příponu.kdb (nebo příponu .ks pro ukládání klíčů v programu Java). Tyto soubory klíčů by měly být zabezpečené a ochráněné nejpřísnějšími dostupnými ovladači operačního systému, protože obsahují soukromé klíče pro dotazovaný certifikát. Například, soubor klíčů pro server pdmgrd je ivmgrd.kdb a, jak je dáno předvolbou, může z něj číst a zapisovat do něj pouze uživatel ivmgr.
Soubory certifikátů v adresáři musí být přístupné pro uživatele serveru politik ivmgr (nebo pro všechny uživatele). Ujistěte se, že uživatel ivmgr (nebo všichni uživatelé) mají povolení k přístupu do souboru .kdb a adresáře nebo složky, které obsahují soubor .kdb. Navíc, abyste usnadnili nečekanou operaci serveru, existují zde soubory, které obsahují zmatenou (ne zašifrovanou) verzi hesla pro soubory klíčů. Tyto verze se nazývají soubory pro uložení a jsou označené souborovou příponou .sth. Všimněte si, že soubory klíčů programu Java generované produktem Tivoli Access Manager nemají odpovídající soubory pro uložení. Tyto soubory pro uložení by opět měly být zabezpečené použitím původních standardních opatření operačního systému. Soubor pro uložení hesla pro server pdmgrd je ivmgrd.sth a jeho oprávnění jsou stejná jako souboru ivmgrd.kdb. Z bezpečnostních důvodů lze obojí, jak certifikáty tak hesla souborů klíčů, nastavit tak, že vyprší po nakonfigurovaném časovém období. Standardní doba platnosti certifikátu je 365 dnů. Předvolená doba trvání hesla soubore klíčů je 183 dní. Pevná doba trvání certifikátu PDCA je 20 let. Komponenty produktu Tivoli Access Manager také standardně provádějí vlastní podporu. To znamená, že během svého provozu automaticky obnovují certifikáty a hesla. Proces obnovy znovu vydá nový certifikát s novou dobou trvání a generuje nové heslo s nakonfigurovanou dobou trvání. Všimněte si, že certifikáty nejsou automaticky obnovované pro Java servery Tivoli Access Manager. Pokud však servery nejsou spuštěny během určeného časového intervalu, jejich certifikátům anebo heslům může skončit platnost. V takovém případě je nezbytná ruční obnova. Navíc, je-li certifikát, heslo nebo celý soubor klíčů znehodnocen, manuální obnova zaručuje uchování domény Tivoli Access Manager zabezpečené. Podrobnější informace o ručním obnovení najdete v části “Informace o obnově souboru klíčů a souboru pro uložení” na stránce 135.
Výchozí konfigurace Certifikáty používané komponentami produktu Tivoli Access Manager se vytvářejí během výchozí konfigurace těchto komponent. Ve zcela nových instalacích produktu Tivoli Access Manager se nejprve konfiguruje server pdmgrd. Jako součást své konfigurace se vytvoří certifikát PDCA a osobní certifikát, který je použitý serverem pdmgrd, je vytvořen také a podepsán certifikátem PDCA. Oba tyto certifikáty jsou umístěné v souboru klíčů ivmgrd.kdb. Jako součást konfigurace pdmgrd se vytvoří soubor klíčů Access Manager Runtime pd.kdb a je do něj vložený certifikát PDCA jako důvěryhodný certifikát. Když jsou k doméně Tivoli Access Manager přidané nové systémy, sada programů Access Manager Runtime (PDRTE) je konfigurovaná první. Opět jako součást konfigurace jsou vytvořené systémové soubory pd.kdb a pd.sth a je do nich vložen certifikát PDCA jako důvěryhodný certifikát. Když jsou konfigurované nové servery správců zdrojů (jako WebSEAL), spustí se nástroj svrsslcfg nebo ekvivalentní rozhraní aplikačních programů (API). Tento nástroj vytvoří soubory klíčů (jako pdacld.kdb) a umístí do něj osobní certifikát pro server. Nástroj do souboru klíčů vloží také certifikát PDCA jako důvěryhodný certifikát. Tyto dva certifikáty si lze obstarat od pdmgrd a do počítače klienta jsou transportované přes SSL s použitím souboru klíčů Access Manager Runtime. Konfiguračními soubory a záznamy objektů stanza vztahujícím se k certifikátu, jako jsou konfigurované soubory klíčů a soubory pro uložení, se zabývá Dodatek A, “Referenční informace ke konfiguraci serveru”, na stránce 233.
134
IBM Tivoli Access Manager: Base: Administrativní příručka
Informace o obnově souboru klíčů a souboru pro uložení Následující tabulka vypisuje komponenty a jejich přiřazené soubory klíčů a soubory pro uložení. Tato tabulka dále popisuje, jak byly tyto soubory vytvořeny a jak jsou aktualizovány. Tabulka 4. Soubory klíčů a soubory pro uložení komponent
Komponenty
Soubor klíčů/pro uložení
Jak byl vytvořen
Procesy, které automaticky aktualizují soubor klíčů, heslo nebo obojí
Nástroj pro ruční aktualizaci
PDRTE
pd.kdb a pd.sth (neobsahují certifikát za strany klienta)
Během konfigurace PDRTE
Vyvolání pdadmin1
bassslcfg –chgpwd
pdmgrd
ivmgrd.kdb a ivmgrd.sth
Během konfigurace pdmgrd
Spuštěním pdmgrd1,2
mgrsslcfg –chgpwd3a mgrsslcfg –chgcert3
pdmgrproxyd
pdmgrproxyd.kdb Během a konfigurace pdmgrproxyd.sth pdmgrproxyd
Během zpracování pdmgrproxyd 1
svrsslcfg –chgpwd ⁴ a svrsslcfg –chgcert ⁵
pdacld
ivacld.kdb ivacld.sth
Spuštěním pdacld1
svrsslcfg –chgpwd4 a svrsslcfg –chgcert5
Správce zdrojů6
Jména souborů Zpracování klíčů a souborů pro svrsslcfg –config uložení jsou závislá na správci zdrojů a jména souborů lze konfigurovat.
Okamžik zpracování správce zdrojů1
svrsslcfg –chgpwd7a svrsslcfg –chgcert8
Během konfigurace pdacld
Poznámky: v 1 - Automatickou obnovu certifikátu a hesla lze vypnout nastavením záznamu objektu stanza ssl-auto-refresh na no (ne) v objektu stanza [ssl] v příslušném konfiguračním souboru. v 2 - Protože server pdmgrd jedná také jako certifikát CA pro zabezpečenou doménu, musí být po obnově recyklován. Pokračuje v normálním fungování, kromě toho, že nemůže vydávat nebo obnovovat certifikáty pro další servery, dokud není recyklován. Soubor protokolu serveru politik obsahuje zprávu, která sděluje, kdy je třeba restartovat server. v 3 - Než spustíte tento příkaz, server pdmgrd musí být zastaven. v 4 - Než spustíte tento příkaz, server pdacld musí být zastaven. v 5 - Než spustíte tento příkaz, server pdmgrd musí být spuštěn a server pdacld musí být zastaven. v 6 - Správci zdrojů Javy mají ekvivalent k souborům klíče, kde osobní certifikát aplikace a certifikát PDCA jsou obnovené, ale nemají ekvivalent k souborům pro uložení. Jméno souborů klíčů (nebo ukládání klíčů v Javě) jsou závislé na správci zdrojů a lze je konfigurovat. Jména souborů klíčů se vytvoří spuštěním třídy Javy SvrSslCfg s –action config. Pro ukládání klíčů v Javě se vyskytují automatické obnovy. Abyste aktualizovali ukládání klíčů v Javě manuálně, použijte metodu PDAppSvrConfig.replaceAppSvrCert().
Kapitola 12. Správa certifikátů a hesel
135
v v
7
- Než spustíte tento příkaz, musíte zastavit správce zdrojů. - Než spustíte tento příkaz, server pdmgrd musí běžet a manažer zdrojů musí být zastavený. 8
Rozhodnutí o důvěře Každý ze souborů klíčů obsahuje také seznam důvěryhodných certifikátů CA. Pro Tivoli Access Manager má každý soubor klíčů, kromě ivmgrd.kdb, certifikát PDCA jako důvěryhodný certifikát CA. Toto je certifikát CA, který je použitý pro podepsání všech ostatních certifikátů Tivoli Access Manager. Tento certifikát CA je vytvořen během konfigurace serveru pdmgrd a je uložen do souboru ivmgrd.kdb. Je mimořádně důležité chránit soubor ivmgrd.kdb, aby bylo zamezeno vyzrazení soukromého klíče certifikátu PDCA. Je-li tento certifikát ohrožen, musí být znovu vytvořen. Pokud se toto stane, je nutné znovu vytvořit také každý soubor klíčů a každý certifikát v doméně. Tuto akci provedete takto: 1. Znovu vytvořte certifikát PDCA (a certifikát serveru pdmgrd) tím, že generujete nový soubor ivmgrd.kdb s použitím mgrsslcfg –unconfig a potom mgrsslcfg –config (pdmgrd musí být zastavený.) 2. Znovu vytvořte všechny certifikáty Access Manager Runtime (PDRTE) v doméně tím, že nejprve spustíte bassslcfg –unconfig. Pak získejte certifikát CA. Můžete si zvolit automatické stažení certifikátu CA nebo ruční kopírování souboru, záleží, jak důvěřujete své síti. v Pokud je spuštěné automatické stahování (enabled) a server pdmgrd běží, certifikát CA obdržíte automaticky. Automatické stahování se aktivuje předvolbou. v Pokud je automatické stahování v pozici off (disabled), musí být do počítače kopírovaná zakódovaná verze base-64 DER certifikátu PDCA. Tento soubor je uložen pod jménem pdcacert.b64 na počítači pdmgrd. 3. Spusťte bassslcfg –config pro dokončení konfigurace Access Manager Runtime (PDRTE). 4. Znovu generujte soubory klíčů pdacld v doméně spuštěním svrsslcfg –unconfig a svrsslcfg –config (pdmgrd musí běžet). Tyto příkazy aktualizují jak certifikát serveru pro pdacld, tak i jeho ověřený certifikát (nový certifikát PDCA). 5. Znovu generujte libovolné jiné soubory klíčů správce zdrojů v doméně spuštěním svrsslcfg –unconfig nebo svrsslcfg–config (pdmgrd musí běžet). Tyto příkazy aktualizují jak certifikát serveru pro pdacld, tak i jeho ověřený certifikát (nový certifikát PDCA). Z pohledu programu Java, Access Manager Runtime také ukládá certifikát PDCA. Je-li certifikát PDCA ohrožený a musí být znovu generován, konfigurace všech Access Manager Runtime (AMJRTEs) musí být zrušená a znovu nastavená. Všichni správci zdrojů, kteří byli předtím konfigurovaní třídou SvrSslCfg musí být také znova nakonfigurovaní.
Odvolání certifikátu serveru Je-li certifikát správce zdrojů založený na jazyce C ohrožený, můžete provést příkaz svrsslcfg -chgcert, abyste nahradili existující certifikát serveru a aktualizovali certifikát PDCA. Pro správce zdrojů založené na Javě musíte použít metodu PDAppSvrConfig.replaceAppSvrCert(). Přestože je toto obtížnější, můžete také zrušit a znovu nastavit konfiguraci serveru spuštěním svrsslcfg –unconfig a svrsslcfg –config. Ujistěte se, že běží pdmgrd. Tyto příkazy
136
IBM Tivoli Access Manager: Base: Administrativní příručka
aktualizují jak certifikát serveru pro pdacld, tak i jeho ověřený certifikát (nový certifikát PDCA).Podobně lze zrušit a znova nastavit konfiguraci správce zdrojů založeného na Javě s použitím třídy SvrSslCfg programu Javy.
Další pokyny pro soubory klíčů a soubory pro uložení Další pokyny pro obnovu souborů klíčů a souborů pro uložení obsahují: v Jsou-li certifikát a heslo pro soubor klíčů, který obsahuje daný certifikát, oba vypršené, je třeba nejprve obnovit heslo. Například, pro server pdacld spusťte příkazy svrsslcfg –chgpwd a potom svrsslcfg –chgcert. Toto je nutné, protože je potřebné platné heslo k otevření souboru klíčů, aby byl umožněn přístup k certifikátu. v Hodnota doby trvání certifikátu je řízená hodnotou objektu stanza ivmgrd.conf, [ssl] a atributem záznamu objektu stanza ssl-cert-life, když je spuštěný server pdmgrd. Tuto hodnotu používají všechny vydané nebo obnovené certifikáty. Pokud chcete tuto hodnotu snížit nebo zvýšit, změňte uvedenou hodnotu a znovu spusťte server pdmgrd. Nová hodnota začne platit pouze pro certifikáty, které byly vydány nebo obnoveny po této změně. Skutečný použitý čas bude nižší než hodnota uvedená v konfiguračním souboru ivmgrd.conf a počet dní kratší, než vyprší certifikát CA serveru. v Hodnota doby platnosti hesla je při automatickém obnovování hesla řízena hodnotou atributu [ssl], ssl-pwd-life, která začne platit po spuštění serveru. Pro ruční obnovování hesla je tato hodnota řízena hodnotou dodanou příkazem –chgpwd. Tato hodnota je také zapsána do odpovídajícího konfiguračního souboru. v Servery produktu Tivoli Access Manager mohou komunikovat také se serverem LDAP (Lightweight Directory Access Protocol) pomocí protokolu SSL. Ve standardních konfiguracích tato komunikace používá pouze autentizaci ze strany serveru. Z tohoto důvodu server produktu Tivoli Access Manager potřebuje pouze certifikát CA, který je podepsán certifikátem serveru LDAP, nebo vlastní certifikát serveru LDAP. Ukončení platnosti a správa těchto certifikátů není obsluhována produktem Tivoli Access Manager. Ale je možné zahrnout certifikát LDAP do souboru klíčů pro správce zdrojů spuštěním příkazu svrsslcfg –config a použitím volby –C. Pro certifikáty, které nejsou spravované Tivoli Access Manager; tyto certifikáty musí být obnovené s použitím stejného mechanismu, jaký byt použitý pro výchozí certifikát. Nový certifikát lze nahradit v souboru klíčů spuštěním příkazu svrsslcfg –modify –C jméno_souboru_nového_certifikátu. v Po spuštění příkazu bassslcfg –config by mohlo být nutné změnit oprávnění v pd.kdb a pd.sth. v Zmiňované konfigurační soubory je obvykle možné nalézt v adresáři instalační_adresář/etc. Například v operačním systému AIX je možné nalézt konfigurační soubory serverů pdmgrd, pdacld a runtime jako soubory /opt/PolicyDirector/etc/ivmgrd.conf, /opt/PolicyDirector/etc/ivacld.conf a /opt/PolicyDirector/etc/pd.conf. Podobně lze nalézt soubory klíčů a soubory pro uložení v adresáři instalační_adresář/keytabs. v Produkt Tivoli Access Manager nerozlišuje mezi exportovaným a vnitřním šifrováním. Pro šifrování založené na programu Java je síla chráněná licenčním klíčem jurisdikčních souborů, které jsou přítomné v běhovém prostředí Java. Neexistuje žádná nastavená délka pro klíče generované Access Manager Runtime. v Jak veřejné klíče, které jsou zahrnuté v certifikátech, tak soukromé klíče, které mohou být uložené v souborech klíčů, mají délky klíčů. Maximální délka klíče je 2048 bitů. Veřejné klíče mající délky klíče 2048 bitů lze generovat s použitím konfiguračních obslužných programů (bassslcfg, mgrsslcfg nebosvrsslcfg).
Kapitola 12. Správa certifikátů a hesel
137
138
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 13. Správa serverů Tato kapitola podává podrobné informace o provádění obecných úloh týkajících se administrativy a konfigurace serverů produktu Tivoli Access Manager. Tato kapitola obsahuje následující části: v “Servery produktu Tivoli Access Manager” v “Obslužné programy produktu Tivoli Access Manager” na stránce 142 v “Úlohy serveru produktu Tivoli Access Manager” na stránce 142 v “Úlohy konfiguračních souborů serveru” na stránce 144 v “Úlohy administrativy serveru politik” na stránce 145
Servery produktu Tivoli Access Manager Produkt Tivoli Access Manager se skládá z následujících serverových procesů, nebo také démonů: v server politik (pdmgrd) v autorizační server (pdacld) v proxy server (pdmgrproxyd)
Obrázek 22. Serverové komponenty produktu Tivoli Access Manager
Server politik (pdmgrd) spravuje databázi politik, na kterou se odkazuje jeho původním jménem hlavní databáze organizace, a udržuje informace o umístění dalších serverů produktu Tivoli Access Manager v doméně. V každé doméně musí být nadefinován minimálně jeden server politik. Autorizační server (pdacld) dovoluje jiným aplikacím podávat žádosti o autorizaci do produktu Tivoli Access Manager prostřednictvím autorizačního rozhraní API. Autorizační server dále vystupuje jako server pro shromažďování informací z protokolování a monitorování a ukládají se na něm záznamy o aktivitě serveru.
Proxy server (pdmgrproxyd) pomáhá podporovat několik strategií nasazení sítě pro server politik a správce zdrojů. Správce zdrojů může být libovolný server nebo aplikace, která používá autorizační API pro provádění žádostí klienta o přístup do zdrojů jako servery WebSEAL nebo aplikace autorizační API.
Proxy server Proxy server je server, který jedná jako prostředek mezi méně důvěryhodnou sítí a důvěryhodnější sítí, takže podnik může zajistit bezpečnosti, řízení administrativy a služby ukládání do paměti cache. Proxy server se vztahuje k části serveru komunikační brány, který odděluje síť podniku od venkovní sítě, a k serveru firewall, který ochraňuje síť podniku od nežádoucích venkovních vstupů. V prostředí produktu Tivoli Access Manager zastupuje proxy server běh serveru politik pro daný počet správců zdrojů a funkcí administrativy jako příkazy pdadmin. Proxy server slouží k mnoha důležitým funkcím v prostředí produktu Tivoli Access Manager. Proxy server lze použít pro ukončení jakéhokoliv spojení z méně důvěryhodné sítě a tyto žádosti předat do serveru politik v důvěryhodnější síti s použitím jiného spojení. Toto ochraňuje server politik v důvěryhodnější síti před napadením kvůli odepření služeb a jinými podobnými útoky. V tomto scénáři nasazení je proxy server nasazen na to, co se běžně nazývá odzbrojená oblast (DMZ). Proxy server je užitečný také pro nasazení sítě široké oblasti, kde server politik a server aplikací jsou nasazené na oddělených místech přes pomalé připojení. Toto se obvykle děje, když jsou server politik a server aplikací nasazené na různých geografických místech. Je-li proxy server nasazený na stejné síti jako server aplikací a server aplikací je konfigurovaný tak, aby procházel přes proxy server, potom bude proxy server kontaktovat pouze server politik a ne každou server aplikace. Toto je důležité v mnoha ohledech. v Proxy server může být konfigurovaný tak, aby ukládal do paměti cache bezpečnostní politiku jako v případech, kdy dojde k aktualizaci politiky v serveru politik server a pouze jedna kopie politiky je přenesená ze serveru politik do proxy serveru. Proxy server potom poskytuje tuto politiku všem aplikacím. Pokud nebyl proxy server přítomný, individuální aplikace by požadovaly a nechaly si odesílat politiky ze serveru politik, čímž by se podstatně zvyšoval přenos na síti. v Tato konfigurace může také vylepšit zabezpečení, protože firewally mezi umístěními mohou být konfigurované tak, aby umožňovaly proxy serveru kontaktovat pouze server politik a ne servery aplikací. Obrázek 23 na stránce 141 ukazuje interakci mezi aplikacemi, proxy serverem a serverem politik.
140
IBM Tivoli Access Manager: Base: Administrativní příručka
Obrázek 23. Proxy server
Závislosti serverů Ujistěte se, že následující závislosti vezmete do úvahy při konfiguraci serveru: v Musí existovat minimálně jedna instance serveru politik. v Musí být definovaný alespoň jeden server politik. Můžete mít jeden server politik a vytvořit libovolný počet domén. Vytvoříte-li doménu, vznikne pro každou také oddělená databáze politik. Jeden server politk může vytvořit přístup k libovolné odlišené databázi politik. v Server politik (pdmgrd) spravuje databázi politik. v Musí existovat pouze jedna databáze politik (hlavní autorizační databáze) pro doménu. v Databáze politik by měla být umístěná na vysoce dostupném serveru pdmgrd s robustním systémem souborů. v Velmi doporučujeme, abyste každou databázi politik začlenili do pravidelného procesu zálohování dat. Administrátor může uvést umístění pro zálohované soubory. v Servery politik poskytují služby replikace autorizační databáze všem dalším serverům produktu Tivoli Access Manager v doméně, které jsou spuštěny v režimu lokální paměti cache. v Každý správce zdrojů, jako např. Tivoli Access Manager WebSEAL, Tivoli Access Manager for Business Integration, nebo Tivoli Access Manager for Operating Systems, používá bezpečnostní politiku založenou na informacích získaných buď z databáze politik nebo z replikované autorizační databáze.
Kapitola 13. Správa serverů
141
Obslužné programy produktu Tivoli Access Manager Obslužnými programy produktu Tivoli Access Manager se podrobně zabývá publikace IBM Tivoli Access Manager for e-business Command Reference. Tabulka na začátku sekce obslužných programů vypisuje dostupné obslužné programy a jejich účely. Všimněte si, že rozhraní příkazového řádku pdadmin, kterým se zabývá také publikace IBM Tivoli Access Manager for e-business Command Reference, poskytuje příkazy, které pomáhají při odstraňování problémů. Například, příkaz pdadmin zahrnuje volby server task stats (statistiky úloh serveru) a server task trace (trasování úloh serveru), které vám umožní obrátit se na statistiky shromažďující a zachycující informace o chybových stavech. Navíc, publikace IBM Tivoli Access Manager for e-business Problem Determination Guide poskytuje další diagnostické informace pro použití příkazu pdadmin Tivoli Access Manager a dalších obslužných programů.
Úlohy serveru produktu Tivoli Access Manager Tato část popisuje, jak spustit a zastavit serverové procesy: v “Spuštění a zastavení serverů v systémech UNIX” v “Spuštění a zastavení serverů v systémech Windows” na stránce 143
Spuštění a zastavení serverů v systémech UNIX Procesy serveru se obvykle aktivují a zastavují prostřednictvím automatizovaných skriptů, které se spouští během spuštění a ukončování práce systému. V prostředí operačních systémů UNIX můžete také používat skript pd_start, pokud chcete ručně spustit a zastavit procesy serveru. Tento způsob se vám bude hodit tehdy, když budete potřebovat přizpůsobit instalaci nebo když budete potřebovat provádět úlohy týkající se odstraňování problémů. Tyto skripty můžete spouštět pouze na lokálním počítači. Obecná syntaxe příkazu pd_start je: # pd_start {start|restart|stop|status}
Obslužný program pd_start můžete spouštět z libovolného adresáře. Skript je umístěn v tomto adresáři: /opt/PolicyDirector/bin/
Spuštění serverů produktu Tivoli Access Manager pomocí obslužného programu pd_start Chcete-li spustit všechny servery produktu Tivoli Access Manager, které momentálně nejsou na určitém počítači spuštěny, použijte obslužný program pd_start: # pd_start start
Tento skript čeká, dokud nebudou spuštěny všechny servery, než zobrazí náznak.
Ruční spuštění jednotlivých serverů Jednotlivé servery můžete ručně spustit tak, že spustíte přímo daný server. Příkazy pro spuštění musíte provádět jako administrátor, např. jako root. Spusťte servery produktu Tivoli Access Manager v následujícím pořadí: 1. Chcete-li spustit server politik (pdmgrd), zadejte následující: instalační_cesta/bin/pdmgrd
2. Pro proxy server politik (pdmgrproxyd), zadejte následující:
142
IBM Tivoli Access Manager: Base: Administrativní příručka
instalační_cesta/bin/pdmgrproxyd
3. Chcete-li spustit autorizační server (pdacld), zadejte následující: instalační_cesta/bin/pdacld
Opětovné spuštění serverů produktu Tivoli Access Manager pomocí obslužného programu pd_start Chcete-li zastavit všechny servery produktu Tivoli Access Manager na určitém počítači a pak tyto servery znovu spustit, použijte obslužný program pd_start: pd_start restart
Tento skript čeká, dokud nebudou spuštěny všechny servery, než zobrazí náznak.
Zastavení serverů produktu Tivoli Access Manager pomocí obslužného programu pd_start Chcete-li zastavit všechny servery produktu Tivoli Access Manager na určitém počítači ve správném pořadí, použijte obslužný program pd_start: pd_start stop
Tento skript čeká, dokud nebudou všechny servery zastaveny, než zobrazí náznak.
Zobrazení stavu serveru pomocí obslužného programu pd_start Chcete-li zobrazit informace o stavu serveru, použijte obslužný program pd_start: pd_start status Servery Tivoli Access Manager: Server Aktivní Prováděný pdmgrd webseald pdacld pdmgrproxyd
ano ne ano ne
ano ne ne ne
Spuštění a zastavení serverů v systémech Windows V operačních systémech Microsoft Windows použijte okno Services (Služby), které najdete v okně Control Panel (Ovládací panel), k ručnímu spuštění a zastavení procesů serverů. Tento způsob je vhodný, pokud přizpůsobujete instalaci nebo když provádíte odstraňování problémů. Chcete-li tento obslužný program používat, musíte mít oprávnění administrátora. Servery produktu Tivoli Access Manager můžete spustit a zastavit buď najednou, nebo samostatně. Servery musí být zastavovány a spouštěny ve správném pořadí.
Použití Ovládacího panelu Služby pro zastavení a spuštění serverů AutoStart Service (Služba automatického spouštění) automaticky spustí každý ze serverů produktu Tivoli Access Manager, je-li konfigurační parametr Startup (Spouštění) nastaven na Automatic (Automaticky). Jakmile se server spustí, AutoStart Service (Služba automatického spouštění) se ukončí. Services Control Panel (Ovládací panel Služby) můžete také použít k ručnímu spuštění a zastavení jednotlivých serverů: 1. Otevřete Control Panel (Ovládací panel) systému Windows. 2. Klepněte dvakrát na tlačítko Administrative tools (Nástroje administrativy), čímž se vám zobrazí složka nástrojů administrativy. 3. Dvakrát klepněte na ikonu Services (Služby). Zobrazí se dialogové okno Services (Služby). Kapitola 13. Správa serverů
143
4. Z okna se seznamem vyberte servery produktu Tivoli Access Manager v pořadí, které je doporučováno v krocích 5 a 6. 5. Stop (Zastavte) servery produktu Tivoli Access Manager v následujícím pořadí: v autorizační server v proxy server v server politik 6. Start (Spusťte) servery produktu Tivoli Access Manager v následujícím pořadí: v server politik v proxy server v autorizační server 7. Klepněte na odpovídající tlačítko volby ovládání Startup Type (Typ spuštění) (Start (Spustit), Stop (Zastavit), Restart (Restartovat)) na pravé straně okénka. 8. Abyste zabránili automatickému spuštění serveru Tivoli Access Manager službou AutoStart Service, použijte vlastnosti spouštění k nastavení serveru Startup Type (Typ spouštění) na Disabled (Zablokováno).
Úlohy konfiguračních souborů serveru Konfigurační soubory serverů můžete použít pro přizpůsobení fungování produktu Tivoli Access Manager a jeho serverů: různými konfiguracemi serveru se zabývá Dodatek A, “Referenční informace ke konfiguraci serveru”, na stránce 233.
Změna nastavení konfigurace Konfigurační soubory, objekty stanza a záznamy objektů stanza popisuje Dodatek A, “Referenční informace ke konfiguraci serveru”, na stránce 233. Abyste mohli změnit nastavenou konfigurace serveru, proveďte následující: 1. Proveďte záložní kopii konfiguračního souboru, který hodláte změnit. To vám dovolí vrátit konfigurační soubor do známého funkčního stavu, pokud by se později objevily chyby. 2. Zastavte dotčené servery produktu Tivoli Access Manager. 3. Proveďte změny některým z následujících způsobů: v Použijte textový ASCII editor a editujte konfigurační soubor. Proveďte všechny nezbytné změny. Uložte vaše změny. v Použijte příkazy pdadmin config, abyste upravili konfigurační soubory. v Použijte odpovídající nástroj pro konfiguraci vašeho serveru a tak změňte nastavení konfigurace: – pro ivmgrd.conf použijte obslužný program mgrsslcfg, – pro pd.conf použijte obslužný program bassslcfg, – pro ostatní konfigurační soubory použijte obslužný program svrsslcfg. v Mnoho objektů stanza nebo hodnot je vytvořených nebo upravených pouze s pomocí konfiguračních obslužných programů produktu Tivoli Access Manager. Některé hodnoty jsou automaticky vyplněny po dokončení konfigurace. Poznámka: Needitujte ručně tyto hodnoty. 4. Spusťte ovlivněné servery Tivoli Access Manager. Například pokud chcete změnit soubor ivmgrd.conf, musíte zastavit servery politik, provést změny a pak znovu spustit všechny servery politik, aby došlo k uplatnění změn.
144
IBM Tivoli Access Manager: Base: Administrativní příručka
Automatizace spuštění serveru v čase zavádění systému Záznamy stanzy pro automatické spouštění serveru jsou umístěny ve stanze [pdrte] konfiguračního souboru pd.conf. Podle předvolby je soubor pd.conf instalovaný do následujícího umístění pro UNIX: /opt/PolicyDirector/etc/pd.conf
Podle předvolby je soubor pd.conf instalovaný do následujícího umístění pro Windows: c:\Program files\tivoli\Policy Director\etc\pd.conf
Server politik Jakmile je nainstalována sada programů PDMgr, server politik se automaticky začne spouštět při každém opětovném spuštění systému: [pdrte] boot-start-ivmgrd = yes
Chcete-li zabránit automatického spouštění serveru pdmgrd, nastavte: boot-start-ivmgrd = no
Autorizační server Jakmile je nainstalována sada programů PDAcld, démon autorizačního serveru se automaticky spouští při každém opětovném spuštění systému: [pdrte] boot-start-ivacld = yes
Chcete-li zabránit automatickému spouštění serveru pdacld, nastavte: boot-start-ivacld = no
Proxy server Při instalaci sady programů PDMgrProxyd se démon proxy serveru automaticky nastartuje poté, co se znova spustí každý server: [pdrte] boot-start-pdmgrproxyd = yes
Abyste předešli automatickému spuštění pdmgrproxyd, nastavte: boot-start-pdmgrproxyd = no
Úlohy administrativy serveru politik Server politik spravuje databázi politik (nebo databáze) a udržuje informace o umístění jiných serverů Tivoli Access Manager v každé doméně. Server politik je obvykle málo náročný na administrativu a konfiguraci. Tato část popisuje úlohy konfigurace, které může administrátor provádět. v “Replikace autorizační databáze” na stránce 145 v “Nastavení počtu vláken oznámení o aktualizaci” na stránce 147 v “Nastavení doby prodlevy oznámení” na stránce 147
Replikace autorizační databáze Administrátor domény produktu Tivoli Access Manager může kdykoliv provádět změny bezpečnostní politiky v doméně. Primární odpovědností serveru politik je provádět nezbytná přizpůsobení hlavní autorizační databáze domény, aby tato reflektovala provedené změny.
Kapitola 13. Správa serverů
145
Provede-li server politik změnu v hlavní autorizační databázi, může odeslat oznámení o této změně všem serverům správců zdrojů (s replikovanými databázemi). Autorizační servery pak musí požádat o aktualizaci databáze ze serveru politik. Poznámka: Navíc, servery správců zdrojů mohou kontrolovat aktualizace databází tím, že server politik odesílají výzvy v pravidelných intervalech. Konfigurace systému výzev pro klienta WebSEAL je například vysvětlena v knize IBM Tivoli Access Manager for e-business WebSEAL: Administrativní příručka. Produkt Tivoli Access Manager vám umožňuje nakonfigurovat oznámení o aktualizaci ze serveru politik tak, aby celý proces byl plně automatizován, nebo aby šlo o ručně řízenou úlohu. Záznam objektu stanza auto-database-update-notify je umístěný v objektu stanza [ivmgrd] konfiguračního souboru ivmgrd.conf. Podle předvolby je hodnota záznamu objektu stanza nastavená na yes (oznámení o aktualizaci je provedené automaticky serverem politik): [ivmgrd] auto-database-update-notify = yes
Toto automatické nastavení je vhodné pro prostředí, ve kterých je změn v databázi málo a jsou prováděny zřídka. Konfigurujete-li oznámení o aktualizaci tak, aby bylo prováděné automaticky, musíte také správně konfigurovat záznamy objektů stanza max-notifier-threads a notifier-wait-time. Chcete-li získat více informací o záznamech objektů stanza max-notifier-threads a notifier-wait-time, viz “Nastavení počtu vláken oznámení o aktualizaci” na stránce 147 a “Nastavení doby prodlevy oznámení” na stránce 147. Konfigurujete-li oznámení o aktualizaci, aby bylo manuální, bude tuto událost řídit manuální aplikace příkazu server replicate. [ivmgrd] auto-database-update-notify = no
Toto ruční nastavení je vhodné pro prostředí, ve kterých je změn v databázi skutečně hodně a jsou prováděny často. V některých případech může několik změn v databázi vygenerovat tolik oznámení o aktualizaci, že se tato brzy stanou zastaralými, neboť v hlavní databázi probíhají stále další změny. Tato zastaralá upozornění způsobují zbytečné zatížení sítě a zhoršují výkonnost správců zdrojů, neboť jsou neustále nuceni žádat a zpracovávat aktualizace politik. Ruční ovládání oznámení o aktualizaci vám umožňuje dokončit proces úpravy hlavní autorizační databáze, než odešlete oznámení o aktualizaci všem autorizačním serverům s replikou databáze. V ručním režimu používají oznámení o aktualizaci společnou oblast vláken procesu pro upozorňování (stejně jako v automatickém režimu). Manuální nastavení režimu je tedy ovlivněné hodnotou záznamu objektu stanza max-notifier-threads. Chcete-li získat více informací o záznamu objektu stanza max-notifier-threads, viz “Nastavení počtu vláken oznámení o aktualizaci” na stránce 147.
Používání příkazu pdadmin server replicate Konfigurujete-li oznámení o aktualizaci, aby bylo manuální, bude tuto událost řídit manuální aplikace příkazu server replicate. pdadmin_secmaster> server replicate -server test_server
Je-li uvedený volitelný argument server-name (jméno-serveru) (test_server), je o změnách v hlavní autorizační databázi upozorněn pouze tento server. Odpovědí na tento příkaz je oznámení o úspěšném nebo selhaném provedení upozornění a replikace. Není-li argument server-name (jméno-serveru) uveden, všechny konfigurované servery správce zdrojů obdrží upozornění o aktualizaci. Úspěšná odpověď v tomto případě znamená
146
IBM Tivoli Access Manager: Base: Administrativní příručka
pouze, že server politik začal odesílat oznámení o aktualizaci. Odpověď neobsahuje označení, zda vlastní oznámení a replikace skončily úspěšně či nikoliv. Autorizace požadovaná pro provedení tohoto příkazu je bit akce s v objektu /Management/Server. Chcete-li získat více informací o příkazu server replicate, viz publikace IBM Tivoli Access Manager for e-business Command Reference.
Nastavení počtu vláken oznámení o aktualizaci Server politik je odpovědný za synchronizaci všech replik databáze v doméně. Jakmile je provedena změna v hlavní databázi, vlákna procesu pro oznámení o aktualizaci odešlou oznámení této změny všem replikám. Každá replika má pak povinnost načíst nové informace z hlavní databáze. Konfigurační soubor serveru politik, ivmgrd.conf, obsahuje záznam objektu stanza pro nastavení maximálního počtu vláken oznámení o aktualizaci. Tato společná oblast vláken dovoluje simultánní (paralelní) odesílání oznámení o aktualizaci. Chcete-li například současně upozornit 30 replik, že byly provedeny změny v databázi, pak by společná oblast vláken měla být nastavena na minimální hodnotu 30. Pokud máte nadefinováno více než 30 replik, pak budou oznámení odesílána ve více vlnách (v tomto příkladě bude odesíláno současně 30 oznámení najednou). Všem replikám je garantováno oznámení, bez ohledu na hodnoty těchto záznamů objektů stanza. Cílem výkonu hodnot vláken oznámení o aktualizaci je oznámit změnu databáze tak rychle, jak je to jen možné. Obecně by tato hodnota měla být nastavena na počet stávajících replik. Výkonnostní výhodou jednoho běhu oznámení o aktualizaci díky dostatečně velké oblasti vláken je rychlé vykonání úlohy upozornění všech replik. Předvolená hodnota společné oblasti vláken procesu pro oznámení o aktualizaci je: [ivmgrd] max-notifier-threads = 10
Je-li záznam objektu stanza auto-database-update-notify nastaven na yes, musíte správně konfigurovat tento záznam objektu stanza a také záznam objektu stanza notifier-wait-time. Viz též “Nastavení doby prodlevy oznámení”.
Nastavení doby prodlevy oznámení Když je serveru politik oznámeno, aby provedl změny v hlavní autorizační databázi, čeká po předvolenou dobu, než odešle oznámení o aktualizaci všem replikám databáze. Předvolená hodnota časové prodlevy je 15 vteřin. Tato časová prodleva je znovu nastavena při každé následující změně databáze. Účelem časové prodlevy je zabránit serveru politik odesílat jednotlivým replikám upozornění o aktualizaci pro každou databázovou změnu v rámci určité série. Časová prodleva pomáhá nastavit optimální výkonnost systému Tivoli Access Manager. Tato výkonnostní vlastnost je obzvláště důležitá v prostředích, ve kterých se provádí dávkové změny v autorizační databázi. Není efektivní, aby změny politiky byly odeslány replikám databáze dříve, než budou dokončeny všechny změny. Můžete přepsat tuto předvolenou dobu prodlevy oznámení tak, že změníte hodnotu záznamu objektu stanza notifier-wait-time (ve vteřinách) umístěnou v objektu stanza [ivmgrd] konfiguračního souboruivmgrd.conf. Například: Kapitola 13. Správa serverů
147
[ivmgrd] notifier-wait-time = 20
Standardně je hodnota nastavena na 15 vteřin. Je-li záznam objektu stanza auto-database-update-notify nastavený na hodnotu yes, musíte jej správně konfigurovat a také záznam objektu stanza max-notifier-threads. Viz též “Nastavení počtu vláken oznámení o aktualizaci” na stránce 147.
148
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 14. Vysoká dostupnost serveru politik Tato kapitola poskytuje informace pro zajištění, že produkt Tivoli Access Manager poskytuje vysokou dostupnost pro server politik, v případě, že dojde k selhání. Tato kapitola také popisuje, jak Tivoli Access Manager podporuje schopnost replikace adresáře LDAP zajistit stálou dostupnost dat adresáře. Tato kapitola obsahuje informace o: v “Integrita dat” v “Primární a replikované servery LDAP” v “Aktivní a pasivní servery politik” v “Správa vysoké dostupnosti” na stránce 150
Integrita dat Měli byste zajistit, že potřebná data pro produkt Tivoli Access Manager jsou vždy dostupná. Abyste zajistili nadbytek dat, všechna data by měla být uložená na datových zařízeních, která jsou zabezpečená RAID (Redundant Array of Independent Disks). Informace o autorizaci a provádění rozhodnutí mohou být převedené do autorizačních serverů. Všechna data by také měla být podrobená velkému procesu zálohovaní, abyste zajistili obnovu dat při výskytu chyby hardwaru nebo softwaru. Obslužný program pdbackup poskytuje možnost zálohovat, obnovovat a extrahovat data Tivoli Access Manager. Více informací o tomto obslužném programu najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Primární a replikované servery LDAP Tivoli Access Manager umožňuje primární a replikované serveru LDAP. Replikovaný server LDAP na jiném uzlu může přebírat operace serveru LDAP, dojde-li k selhání primárního serveru LDAP. Je důležité poznamenat, že během přepnutí při selhání se nevyskytne žádná operace zápis. Během přepnutí při selhání jsou povolené pouze operace četní serveru LDAP. Viz dokumentace serveru LDAP pro kompletní informace o vysoké dostupnosti serverů LDAP.
Pokud plánujete nastavení primárního a pomocného serveru, musíte zohlednit tyto tato pravidla: v Prostředí 2-uzlové IBM AIX HACMP (High-Availability Cluster Multiprocessing) skládající se z aktivního serveru a jednoho pomocného serveru bylo testováno. Tudíž, IBM podporuje pouze IBM AIX HACMP verzi 4.4.1 nebo pozdější 2-uzlová prostředí pro toto vydání. v Primární a pomocné servery politik musí být instalované a konfigurované na zvláštních počítačích a oba servery politik musí být v prostředí klastrů AIX HACMP. v Servery registrů uživatelů (jako server LDAP, Microsoft Active Directory nebo IBM Lotus Domino) musí být na jiném počítači, než jsou ty, na kterých je instalovaný primární a pomocný server politik. v Je důležité zálohovat všechna sdílená data nebo sdílené databáze politik než začnete konfiguraci primárního a pomocného serveru do sdílených systémů souborů. v Každý systém AIX musí mít přístup do sdíleného diskového pole, který je konfigurovaný pro nadbytek dat. v Primární a pomocný server musí být konfigurované do sdíleného systému souborů a tento systém souborů musí být možné nasadit každým serverem. v Jak databáze politik tak konfigurační soubory, které jsou použité serverem politik, musí být umístěné ve sdíleném diskovém poli. Chcete-li nastavit pomocný server politik, následujte proceduru v publikaci IBM Tivoli Access Manager Base Installation Guide.
Správa vysoké dostupnosti Procedurou nastavení pomocného serveru politik se zabývá publikace IBM Tivoli Access Manager Base Installation Guide. Následující úlohy jsou procedury zajišťující, že jste správně následovali výchozí konfigurační procedury Tivoli Access Manager pro nastavení primárních a pomocných serverů HACMP Tivoli Access Manager.
Ověření nastavení vysoké dostupnosti serverů politik Abyste ověřili, že instalační a konfigurační procedury byly správně následované, zajistěte dokončení třech hlavních úloh: 1. Ujistěte se, že jste nastavili požadovaná softwarová spojení z aktivního primárního serveru do pomocného serveru. 2. Ujistěte se, že jste upravili odpovídající volby konfigurace v konfiguračních souborech ivmgrd.conf a pd.conf na primárním i pomocném serveru a že konfigurační soubory mají stejné předvolené hodnoty pro ID požadovaných uživatelů a skupin: v ID uživatele ivmgr v ID skupiny ivmgr v ID uživatele tivoli v ID skupiny tivoli 3. Ujistěte se, že jste zkopírovali soubory z lokálního systému souborů AIX pro primární server a server politik do sdíleného systému souborů, že tento sdílený systém souborů je umístěný ve společném adresáři a že každý uživatel a skupina vlastní nezbytná oprávnění pro vstup. Pokud je libovolná z těchto položek nastavená nesprávně, vraťte se do procedury nastavení pomocného serveru politik v publikaci IBM Tivoli Access Manager Base Installation Guide a zajistěte, že procedura bude provedená správně.
150
IBM Tivoli Access Manager: Base: Administrativní příručka
Přehled souborů protokolů Můžete monitorovat proces přechodu primárního serveru do pomocného tím, že budete kontrolovat soubor hacmp.log, abyste ověřili, že se vyskytly všechny operace přepnutí při selhání HACMP. Proceduru přehledu protokolů HACMP lze nalézt v dokumentaci HACMP. Tento protokol lze obvykle nalézt v adresáři /tmp. Dojde-li k výskytu chyby libovolné operace Read (čtení) nebo Write (zápis) během přepnutí serveru politik při selhání, můžete si zobrazit přehled souborů protokolů primárního serveru politik. Umístění souborů protokolů Tivoli Access Manager je závislé na tom, jestli je nebo není použitý Tivoli Common Directory. Viz Kapitola 17, “Soubory protokolu a směrování”, na stránce 169, chcete-li více informací o souborech protokolů Tivoli Access Manager. Publikace IBM Tivoli Access Manager for e-business Problem Determination Guide také popisuje soubory protokolů a prohlížeč souborů protokolů XML.
Kapitola 14. Vysoká dostupnost serveru politik
151
152
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 15. Server politik s více klienty Server s více klienty odkazuje na server, který povoluje mít jako hostitele více zákazníků na jednom serveru místo na více klientských počítačích. Například, vaše společnost by mohla sdílet aplikace nebo data na serveru vaší společnosti s vašimi zákazníky (například, Smith-Davis Enterprises). Než přidáte data a informace, které náleží jinému zákazníkovi (například, Systems, Inc.), musíte zajistit, že tito dva zákazníci nebudou mít umožněný přístup k jiným datům nebo aplikacím jiné společnosti. Použitím serveru s více klienty (více doménami) můžete spustit každou aplikaci nebo data společnosti v prostředí izolovaného serveru. Spuštění prostředí izolovaného nebo odděleného serveru nahradí potřebné použití více fyzických serverů pro každého zákazníka a jeho aplikace. V závislosti na požadavcích vašich zákazníků a jejich aplikací nemůžete hostit více klientů na jednom serveru. Nahrazením více serverů jedním serverem omezíte náklady vaší společnosti na služby, které poskytujete zákazníkům. Například, méně serverů redukuje náklady na hardware, břemeno personálu IT a navíc, jeden server není náročný na správu. Toto neznamená, že server s více klienty je méně bezpečný než tradiční jeden server s přístupem jednoho klienta. Použitím technologií jako je SSL a omezené přístupy můžete ochránit od sebe navzájem dva zákazníky na stejném serveru. Další vrstvy zabezpečení pro aplikace s více uživateli byly navržené do produktu Tivoli Access Manager. Produkt Tivoli Access Manager rozdělí každou doménu na oddíly, aby tak od sebe pevně oddělil uživatele, spíše než aby použil zabezpečovací opatření pro více uživatelů UNIXu nebo Windows NT. Běhoví klienti produktu Tivoli Access Manager musí být konfigurovaní do specifických domén v čase instalace. Informace o členství v doméně doprovází každou následnou žádost od klienta do serveru politik. Objekt stanza [domains] v konfiguračním souboru ivmgrd.conf pro servery politik s více zákazníky (pdmgrd) obsahuje seznam platných existujících domén. Viz “stanzy [domains] a [domain=jméno_domény]” na stránce 270, chcete li další vysvětlení každého záznamu objektu stanza. Každá doména musí vlastnit svůj vlastní objekt stanza [domain=jméno_domény]. Například, abyste nastavili zvlášť domény pro Smith-Davis Enterprises a Systems, Inc., měli byste vytvořit současně dvě jedinečně pojmenované domény smithdavis a systemsinc: [domains] domain = smithdavis domain = systemsinc [domain=smithdavis] [domain=systemsinc]
Domény s více klienty dokončené produktem Tivoli Access Manager mají za následek vytvoření zvláštních databází pro každý prostor chráněných objektů. Všechny tyto databáze mohou používat stejný základní registr uživatelů (jeden registr LDAP s odlišnými a oddělenými odlišenými jmény). Například, pokud byste chtěli uvést soubor sde0001.db, uvedli byste jméno souboru a adresář v tomto záznamu objektu stanza: [domain=smithdavis] database-path = D:\smithdavis\sde0001.db
user name (sdeuser1) for K.L. Logan company/organization (sde) for Smith-Davis Enterprises division (mkt) for Marketing Group country (US) for United States
Pokud byste chtěli omezit, aby byly účty uživatelů tvořené v zásobníku adresáře dc=mkt,o=US pro doménu smithdavis, uvedli byste umožnění tohoto podřetězce registru v tomto záznamu objektu stanza: [domain=smithdavis] allowed-registry-substrings = "dc=mkt,o=US"
Pokud byste chtěli omezit, aby se účty uživatelů tvořili v zásobníku adresáře dc=mkt pro doménu smithdavis bez ohledu na to, kde v registru tento zásobník existuje, uvedli byste: [domain=smithdavis] allowed-registry-substrings = "dc=mkt"
Dokončený objekt stanza [domains] v konfiguračním souboru ivmgrd.conf pro server politik (pdmgrd) by mohl vypadat takto: [domains] domain = smithdavis domain = systemsinc [domain=smithdavis] database-path = D:\smithdavis\sde0001.db allowed-registry-substrings = "dc=mkt,o=US" [domain = systemsinc] database-path = D:\systemsinc\sysinc0001.db allowed-registry-substrings = "dc=sales,o=US"
154
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 16. Delegovaná administrativa Produkt Tivoli Access Manager umožňuje administrátorům na vysoké úrovni v hierarchii delegovat odpovědnosti za správu domény na administrátory na nižších úrovních. Tato schopnost je životně důležitá pro úspěšnou správu velmi velkých domén, skládajících se z množství oddělení. Produkt Tivoli Access Manager podporuje delegování administrativy v těchto oblastech: v delegovanou správu zdrojů v podoblastech prostoru objektů Administrativní schopnosti jsou vyhrazeny na část prostoru objektů. v delegovanou správu skupin a uživatelů Administrativní schopnosti jsou omezeny na část populace uživatelů. Tato kapitola obsahuje následující části: v “Přehled delegované administrativy” v “Administrativa delegovaných rolí” na stránce 157 v “Správa prostoru delegovaných objektů” na stránce 158 v “Delegovaná správa skupin a uživatelů” na stránce 160 v “Bezpečnostní politika delegované administrativy” na stránce 166
Přehled delegované administrativy Delegovaná administrativa poskytuje administrátorovi produktu Tivoli Access Manager schopnost vytvářet domény delegovaných uživatelů, vytvářet nové uživatele, přidávat existující uživatele do dalších doména a přiřazovat doménám různé typy administrátorů. Tito delegovaní administrátoři mohou provádět podmnožinu administrativních funkcí v závislosti na svém typu a na uživatelích ve své přiřazené doméně. Tento koncept delegování administrativy uživatelů je možné použít u všech uživatelů produktu Tivoli Access Manager, čímž se vytvoří hierarchie domén uživatelů. V tomto hierarchickém uspořádání může být každý uživatel produktu Tivoli Access Manager spravován pouze administrátory domény, jejímž členem je uživatel, nebo administrátory nadřazených domén - také nazývanými super doménami (bude vysvětleno později v této kapitole). Skutečné funkce, které administrátoři mohou provádět, závisí na jejich přiřazeném typu administrátora. Administrátor produktu Tivoli Access Manager jako sec_master může vytvářet řadu domén podniků a přiřazovat jeden nebo více typů administrátorů pro každou doménu podniku. Administrátor celopodnikové domény může vytvořit nové uživatele v doméně a přidat stávající uživatele produktu Tivoli Access Manager do domény. Navíc k těmto funkcím vztahujícím se k uživateli, administrátoři produktu Tivoli Access Manager mohou vytvářet nové domény pod úrovní domén podniku (poddomény) a udělat uživatele administrátory těchto nových domén (administrátoři domén). Administrátoři nových domén mohou vytvářet nové uživatele ve svých vlastních doménách. Administrátor produktu Tivoli Access Manager celopodnikové domény (superdomény domény) má také oprávnění administrovat doménu. Administrátoři produktu Tivoli Access Manager mohou v rámci svých oprávnění vytvářet a spravovat tolik domén, kolik je nezbytné pro splnění jejich jedinečných obchodních cílů.
Poznámka: Doména podniku je v zásadě doména nejvyšší úrovně a jiná doména vytvořená pod úrovní domény podniku je nazývaná pouze jako doména. Příklad tohoto typu vícedoménové administrativy je na obrázku Obrázek 24, kde administrátor produktu Tivoli Access Manager může vytvořit celopodnikové domény A a B a přiřadit každé z těchto domén vlastního administrátora. Administrátor domény pro celopodnikovou doménu B může vytvořit nové uživatele P, Q. Administrátor produktu Tivoli Access Manager může vytvořit domény C a D pod úrovní celopodnikových domén A a B a přiřadit administrátory domén doménám C a D. Administrátor produktu Tivoli Access Manager pak může vytvořit doménu E pod úrovní domény D a přiřadit administrátora domény doméně E. Administrátor domény E může pak v rámci své domény vytvořit nové uživatele X, Y a Z. Jelikož administrátor domény může současně spravovat poddomény své domény, tak jak administrátor domény D, tak i administrátor domény B může vytvářet uživatele (nebo provádět další administrativní funkce) v doméně E.
Obrázek 24. Delegovaní administrátoři
Pro každou doménu delegovaného uživatele (včetně domény podniku) mohou být předdefinované typy administrátorů přiřazené k dané doméně. Následující jsou různé typy administrátorů a nastavení funkcí administrativy, které mohou být prováděné administrátory přiřazenými ke každému z těchto typů: v Administrátor produktu Tivoli Access Manager. Administrátor produktu Tivoli Access Manager je členem skupiny iv-admin. Administrátor produktu Tivoli Access Manager může provádět všechny delegované administrativní funkce. v Administrátor domény. Administrátor domény může provádět administrativní funkce pro uživatele ve své doméně. Administrátoři domény mohou ve svých vlastních doménách vytvářet nové uživatele a administrátory a mohou pro svou doménu přidělovat stávajícím uživatelům domény práva administrátora (jakéhokoliv typu kromě administrátora domény). v Pokročilý administrátor. Pokročilý administrátor má stejná oprávnění jako administrátor domény kromě toho, že pokročilý administrátor nemůže určit další administrátory. v Administrátor. Administrátor má stejná oprávnění jako pokročilý administrátor kromě toho, že administrátor nemůže vytvářet nové uživatele domény. Administrátor může upravovat vlastnosti stávajících uživatelů.
156
IBM Tivoli Access Manager: Base: Administrativní příručka
v Pomocný administrátor. Pomocný administrátor slouží uživateli v roli helpdesku a je schopen prohlížet vlastnosti uživatele, měnit hesla uživatelů a měnit příznaky Je heslo platné? uživatelů. Prostředek pro delegování administrativy uživatelů prosazuje administrativní funkce, které je možné provádět každým typem administrátora. Pokud se administrátor přihlásí, jsou mu zpřístupněny administrativní funkce v závislosti na typu administrátora, kterým daný administrátor je.
Administrativa delegovaných rolí Další součástí systému delegované administrativy produktu Tivoli Access Manager je administrativa rolí. Abyste úspěšně nasadili produkt Tivoli Access Manager, musí být definovaná bezpečnostní politika, která chrání licenčním klíčem přístup do objektů a akce, které lze provádět v těchto objektech. Provádění této politiky je obvykle obtížné, protože bezpečnostní politika je často nadefinována členy na nejvyšší úrovni v organizaci s důrazem na globální cíle zabezpečení ochrany dat. Takovou politiku pak musí aplikovat lokální členové organizace, kteří znají podrobnosti na nižší úrovni organizace a záležitosti vlastní implementace. Tyto dvě skupiny mívají často podobné cíle pro všeobecné zabezpečení ochrany dat organizace, ale propojit tyto dva nesourodé pohledy je náročné. Administrativa založená na rolích nabízí dodatečnou schopnost pro zajištění zabezpečení ochrany dat na úrovni organizace, která splní současné požadavky na komplexní zabezpečení ochrany dat z hlediska škálovatelnosti, jednoduchosti a pružnosti. Chcete-li porozumět administrativě rolí, prvním pojmem, který musíte nadefinovat, je role. Role se skládá z počtu úloh, zodpovědností a dovedností požadovaných k naplnění požadavků určité úlohy. Když je definice v kontrastu s modelem přístupového seznamu (ACL) produktu Tivoli Access Manager, role se stane seznamem jednoho nebo více párů objektů a jednoho nebo více oprávnění k přístupu, které se vztahují k danému objektu. Například: v objekt 1: oprávnění 1 v objekt 2: oprávnění 2, 3 a 4 v objekt 3: oprávnění 5 Chcete-li roli používat, musíte ji aktivovat. Role se aktivuje tak, že administrátor produktu Tivoli Access Manager aktivuje její definici v prostoru jmen produktu Tivoli Access Manager. Poté, co je role aktivována a k roli je přiřazen uživatel, má uživatel oprávnění 1 pro objekt 1, oprávnění 2, 3 a 4 pro objekt 2 a oprávnění 5 pro objekt 3. Oprávnění přístupu k těmto objektům umožňují uživateli přistupovat k objektům, a tak provádět pracovní odpovědnosti, které jsou nadefinovány rolí. Například role účetního může být nadefinována tak, aby se skládala z níže uvedených dvou párů objektů a oprávnění: v Objekt kontroly výplatní listiny: vytvořit/upravit/smazat v Objekt požadavku o odškodnění: schválit Až bude tato role aktivována a této roli bude přiřazen zaměstnanec účetního oddělení, pak bude tento zaměstnanec schopen vytvářet, měnit nebo mazat kontroly výplatních listin a povolovat požadavky na náhradu, a tak provádět práci, která se od účetního očekává. Chcete-li úspěšně spravovat role, pak musí být administrátor schopen provádět tři typy úloh: v vytvoření role v přiřazení role v aktivaci role Vytvoření role se týká definice role, takže tato obsahuje seznam jednoho nebo více párů objektů produktu Tivoli Access Manager a oprávnění, která je možné použít u příslušných Kapitola 16. Delegovaná administrativa
157
objektů. Při vytvoření role se vytvoří skupina Tivoli Access Manager, která představuje tuto roli. Dále se vytvoří odpovídající objekt skupiny v prostoru objektů správy. Informace o páru objekt/oprávnění dané role je uložen v rozšířených atributech přiřazených k objektu skupiny. Pouze administrátor produktu Tivoli Access Manager je schopen vytvářet role. Přiřazení role se skládá z přiřazení uživatele k roli, která byla již vytvořena. Účel skrytý za přiřazením uživatelů k rolím je umožnit těmto uživatelům získat oprávnění přístupu k objektům nadefinovaných v roli. Tato funkce snižuje vytížení vzniklé spravováním vztahů uživatel-oprávnění-objekt, protože přiřazení rolí je odděleno od správy oprávnění objekt/přístup. Když je uživateli přiřazena role v rozhraní Web Portal Manager, je tento uživatel přidán do skupiny, která přestavuje tuto roli. Administrátoři domény, pokročilí administrátoři a administrátoři v dané doméně mohou přiřazovat uživatele ve své doméně k roli. Aktivace role umožňuje nově vytvořeným rolím, aby začaly fungovat. Po vytvoření role a přiřazení uživatele k této roli nemá uživatel oprávnění přístupu k objektům definovaným v této roli, dokud není role aktivována. Jakmile je role aktivována v rozhraní Web Portal Manager, do přístupového seznamu každého objektu definovaného v roli se přidá záznam ACL, který obsahuje skupinu, představující roli, a oprávnění přístupu, definovaná v roli. Protože uživatel byl přidán do skupiny, je-li tento uživatel přiřazen k roli, má tento uživatel oprávnění přistupovat k objektům pouze tehdy, je-li role aktivní. Pouze administrátor produktu Tivoli Access Manager může aktivovat roli. Role je jednotka, která může být delegována a spravována. Jakmile je role vytvořena, je možné ji přiřadit k celopodnikové doméně. Administrátoři domény následně mohou přiřadit libovolnou roli ve své doméně jiné poddoméně. Jakmile je role přiřazena poddoméně, administrátor této poddomény může dané roli přiřadit libovolného uživatele poddomény. Tento proces přiřazování rolí k poddoménám je možné opakovat podle potřeby, takže je možné role zpřístupnit odpovídajícím uživatelům. Přiřazení rolí k celopodnikové doméně může provádět pouze administrátor produktu Tivoli Access Manager. Administrátoři domény mohou přiřadit roli pouze svým poddoménám.
Správa prostoru delegovaných objektů Distribuce odpovědností administrativy v doméně se nazývá delegování správy. Potřeba delegování správy se obvykle objevuje při rostoucích potřebách velké implementace, která obsahuje hodně rozdílných oddělení nebo divizí. Velký prostor objektů lze obvykle rozdělit na oblasti, které představují tato oddělení nebo divize. Každá zvláštní oblast domény je obvykle lépe organizována a spravována správcem, který je lépe obeznámen s cíli a potřebami dané větve.
Členění prostoru objektů pro delegování správy Rozčleňte váš prostor objektů tak, aby obsahoval zvláštní oblasti, nebo větve, na které bude možné přenést odpovědnosti za část správy specifické pro danou větev. Obrázek 25 na stránce 159 ukazuje, že obě oblasti prostoru objektů s názvy Engineering a Publications vyžadují samostatné řízení správy. Kontrola těchto oblastí začíná kořenem každé oblasti a šíří se do všech objektů spadajících do kořenu.
158
IBM Tivoli Access Manager: Base: Administrativní příručka
Obrázek 25. Členění prostoru objektů pro delegování správy
Předvolení administrátoři a skupiny Produkt Tivoli Access Manager během instalace nastaví několik důležitých administrativních skupin. Informace o těchto uživatelích a skupinách najdete v části “Předvolení administrátoři a skupiny” na stránce 41.
Příklad: Delegování správy Rozsáhlý prostor objektů může potřebovat mnoho administrátorů, kteří by spravovali množství podřízených větví. V tomto scénáři musí přístupové seznamy pro adresáře na cestě ke každé z těchto větví obsahovat záznamy pro každý účet spolu s oprávněním pro přechod. Pro počítač s mnoha administrátory by tyto přístupové seznamy obsahovaly dlouhý seznam záznamů představujících všechny tyto administrativní účty. Následující technika řeší problém velkého počtu záznamů pro administrátory v přístupovém seznamu: 1. Vytvořte účet pro administrativní skupinu. 2. Přidejte všechny nové administrátory do této skupiny. 3. Přidejte tuto skupinu jako záznam ACL (s oprávněním pro přechod) do adresářů vedoucích ke každé podřízené větvi, která vyžaduje delegování správy. 4. Pro každou z vedlejších větví vytvořte administrativní skupinu a do každé z této administrativních skupin vedlejších větví přidejte odpovídajícího uživatele (s oprávněními b, c, T plus dalšími odpovídajícími oprávněními, a to vše zaneste do kořenového přístupového seznamu každé větve. 5. Administrátor nyní může vymazat záznam ACL pro administrativní skupinu (a všechny další záznamy) z kořene. Nyní má pouze tento uživatel kontrolu nad kořenem a všemi objekty pod ním. Obrázek 26 na stránce 160 ukazuje, že skupina iv-admin obsahuje všechny administrátory. Uživatel pub-manager je členem této skupiny a má tedy nezbytné oprávnění pro přechod, potřebné pro průchod k adresáři Publications. Adresář Publications obsahuje ve svém přístupovém seznamu záznam pro uživatele pub-manager. Poněvadž pub-manager je delegovaným administrátorem této větve (s odpovídajícími oprávněními), pak pub-manager může vymazat skupinu iv-admin (a všechny
Kapitola 16. Delegovaná administrativa
159
další záznamy ACL) z přístupového seznamu adresáře Publications, a tak získá úplnou kontrolu nad danou větví webového prostoru.
Obrázek 26. Příklad delegování správy
Delegovaná správa skupin a uživatelů Chcete-li být schopni spravovat velkou nebo komplexní sadu uživatelů, můžete nadelegovat správu určitých skupin uživatelů na administrátory na nižší úrovni. Je-li administrátorovi uděleno řízení správy politik skupiny, pak tento administrátor má řízení správy politik pro všechny uživatele této skupiny. Delegovaná správa skupin definuje: v kdo má odpovědnost za administrativu určité skupiny (a členů této skupiny) v jaká je přidělená úroveň řízení uživatelů a skupin tomuto administrátorovi V tomto pojednání se termín administrátor vztahuje k odpovědnostem a ovladačům, které byly uděleny jinak obvyklému uživateli. Administrátor s delegovanými pravomocemi je normální uživatel s přidanou schopností provádět určité úlohy správy. Nastavení delegované správy skupin vyžaduje provedení následujících kroků: 1. Určete logickou a praktickou hierarchii uživatelů a typů uživatelů, kteří jsou členy domény. 2. Vytvořte objekty typu zásobník pro skupiny, které budou odrážet tuto hierarchii. 3. Vytvořte odpovídající administrativní skupiny v těchto objektech typu zásobník. 4. Přiřaďte odpovídající uživatele do příslušných administrativních skupin spolu s určitými oprávněními, které budou potřeba k provádění požadovaných úloh.
Vytvořit objekty typu zásobník pro skupiny Dle předvolby, oblast /Management prostoru objektů produktu Tivoli Access Manager má objekt typu zásobník Groups (skupiny), který můžete použít pro organizaci hierarchie skupin ve vaší doméně.
160
IBM Tivoli Access Manager: Base: Administrativní příručka
Objekty typu zásobník jsou strukturovaná pojmenování, která umožňují organizovat prostory objektů do rozlišených a hierarchických funkčních oblastí. Objekty typu zásobník skupin umožňují definovat rozlišené kategorie typů skupin. Abyste vytvořili aktuální skupiny v každém specifickém objektu kontejnerů skupin používajícím Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste vytvořili nový objekt kontejnerů skupin používající rozhraní Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Object Space (Prostor objektů) → Create Object (Vytvořit objekt). 3. Zapište Object Name (Jméno objektu). Toto pole je povinné. Zapište plnou cestu do jména objektu. Například: /Management/Groups/Travel 4. Zapište Description (Popis) pro prostory objektů. Například: Travel Container Object 5. Klepněte na Create (Vytvořit). Abyste si zobrazili nový objekt v hierarchické struktuře, procházejte prostor objektů. Viz “Procházení prostorů objektů” na stránce 65.
Obrázek 27. Objekt typu zásobník pro skupiny
pdadmin Abyste vytvořili nový objekt typu zásobník pro skupiny pomocí obslužného programu pdadmin, přihlaste se do domény a použijte příkaz pdadmin object create (vytvořit objekt pdadmin). Například, chcete-li vytvořit nový objekt typu zásobník pro skupiny: pdadmin>object create jméno-objektu popis typ ispolicyattachable {yes|no} Tabulka 5. Parametry vytváření objektu Parametr
Popis
jméno_objektu
Úplná cesta a jméno nového objektu typu zásobník pro skupinu. Cesta musí začínat jako/Management/Groups.
popis
Libovolný textový řetězec popisující objekt. Tato informace se zobrazí v příkazu object show.
typ
Parametr typu označuje typ objektu. Rozsah typů je 0-17 (viz Tabulka 6 na stránce 162).
ispolicyattachable
Určuje, zda můžete připojit politiku ACL k tomuto objektu.
Kapitola 16. Delegovaná administrativa
161
Tabulka 6. Typy objektů Typy objektů 0 1 2 3 4 5 6 7 8 9
– – – – – – – – – –
neznámý zabezpečená doména soubor spustitelný program adresář spojení server WebSEAL nepoužíváno nepoužíváno server HTTP
10 11 12 13 14
– – – – –
neexistující objekt objekt typu zásobník koncový objekt port objekt typu zásobník aplikace (vyžaduje delegovaná administrativa) 15 – objekt typu koncová aplikace 16 – objekt správy 17 – nepoužíváno
Chcete-li například vytvořit objekt typu zásobník pro skupiny, můžete použít také příkaz pdadmin group create. Viz “Vytvořit skupiny”. Podrobnější informace o příkazu pdadmin object create najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Vytvořit skupiny Abyste vytvořili novou skupinu a libovolně umístili tuto skupinu do objektu typu zásobník pro skupiny používajícím Web Portal Manager nebo obslužný program příkazového řádku pdadmin, přihlaste se do požadované domény jako administrátor domén.
Web Portal Manager Abyste vytvořili novou skupinu a libovolně ji umístili do objektu typu zásobník pro skupiny používajícím Web Portal Manager: 1. Přihlaste se do domény. 2. Klepněte na Group (Skupina) → Create Group (Vytvořit skupinu). 3. Zapište Group Name (Jméno skupiny) pro skupinu (například, group1). Toto pole je povinné. 4. Volitelně můžete zapsat Description (Popis) pro skupinu (například, Travel group 1). 5. Zapište Registry GID (GID registru). Toto pole je povinné. GID registru uvádí umístění v databázi registrů, kde je vytvořená nová skupina. Například: cn=travel,c=us. Uživatelé Lotus Notes požadují jméno plné cesty pro uživatele, který je právě tvořen. Například: travel/US. 6. Volitelně můžete zapsat cestu v poli Object Container (Objekt typu zásobník) pro prostor objektů produktu Tivoli Access Manager, kde se má vytvořit skupina. Ujistěte se, že jste zapsali plnou cestu: /Management/Groups/Travel
7. Klepněte na Create (Vytvořit). Nová skupina se zobrazí jako odkaz. Označte odkaz a zobrazí se vlastnosti nové skupiny.
162
IBM Tivoli Access Manager: Base: Administrativní příručka
Obrázek 28. Vytvoření nových skupin pod určitým zásobníkem skupin
pdadmin Abyste vytvořili novou skupinu a libovolně ji umístili v objektu typu zásobník pro skupiny používajícím obslužný program pdadmin, přihlaste se do domény a použijte příkaz pdadmin group create (vytvořit skupinu pdadmin). Například, abyste vytvořili novou skupinu a libovolně ji umístili v objektu typu zásobník pro skupiny. Pokud objekt typu zásobník dosud neexistuje, je automaticky vytvořen: pdadmin>group create jméno_skupiny dn cn [zásobník_pro_skupiny] Parametr
Popis
jméno_skupiny
Jméno nového objektu skupiny.
dn
Rozlišovací jméno nové skupiny.
cn
Běžné jméno nové skupiny.
zásobník_skupin
Relativní cesta k objektu typu zásobník pro skupiny, do kterého má být nová skupina umístěna. Pokud nebyl zadán žádný objekt typu zásobník, skupina bude umístěna do /Management/Groups.
Poznámky: 1. Všechny nové objekty typu zásobník pro skupiny, které vytvoříte, se objeví pod předvoleným zásobníkem /Management/Groups. Chcete-li vytvořit zásobník na jiné podúrovni, použijte relativní cestu v proměnné zásobník_skupin. 2. Příkaz group create vám nedovoluje vytvořit objekt typu zásobník pro skupiny, aniž byste vytvořili i skupinu. 3. Chcete-li přidat novou skupinu do prostoru objektů, administrátor musí mít oprávnění pro vytváření (N) v přístupovém seznamu spravujícím přidružený objekt typu zásobník pro skupiny. Pokud nezadáte žádný objekt typu zásobník pro skupiny, v přístupovém seznamu spravujícím zásobník /Management/Groups musí být určen záznam ACL pro administrátora (spolu s oprávněním pro vytváření). Při instalaci definuje oprávnění na všech skupinách a zásobnících pro skupiny jediná předvolená ACL (default-management), která je připojená k /Management. Musíte přidat odpovídající explicitní přístupové seznamy, abyste přizpůsobili uvedené ovládání. Kapitola 16. Delegovaná administrativa
163
4. Do jednoho zásobníku skupin můžete přidat více skupin. Přístupový seznam objektu typu zásobník pro skupiny řídí (prostřednictvím dědičnosti) všechny skupiny, které jsou umístěny pod objektem typu zásobník. Objekt typu zásobník a jeho skupiny jsou nyní doménou administrátorů, kteří mají delegované odpovědnosti. 5. Umístění nové skupiny do prostoru objektů je upevněno během jejího vytváření. Jakmile je skupina vytvořena, můžete její umístění měnit pouze tak, že tuto skupinu vymažete z prostoru objektů (ale ne z LDAP) a pak ji naimportujete do nového umístění (uživatelé ve skupině jsou udržováni). Podrobnější informace o příkazu pdadmin group create najdete v knize IBM Tivoli Access Manager for e-business Command Reference.
Politiky ACL ovlivňující správu skupin Autorizace pro řízení skupin uživatelů je přidělena připojením odpovídajícího přístupového seznamu k objektu skupiny nebo objektu typu zásobník pro skupiny. Přístupový seznam, který byl vytvořen a připojen administrátorem na vysoké úrovni v hierarchii, by měl obsahovat odpovídající oprávnění pro akce, které musí delegovaný administrátor dané skupiny (nebo skupin) provádět. Pokud je skupina umístěna pod částí /Management/Groups prostoru objektů, pak přístupový seznam musí být připojen ke /Management/Groups nebo k vlastní skupině. Pokud je skupina umístěna pod objektem typu zásobník pro skupiny, přístupový seznam musí být připojen k objektu typu zásobník pro skupiny nebo vlastní skupině. Pokud připojíte ACL k objektu typu zásobník /Management/Groups, ovlivnila vy všechny další objekty typu zásobník pro skupiny umístěné pod /Management/Groups v prostoru objektů. Přístupový seznam, který je připojen k jednomu z těchto umístění (nebo děděn z vyšších úrovní), určuje: v kdo řídí objekty skupin a uživatele ve skupině v které akce je možné provádět ve skupině a s jejími uživateli Například Obrázek 28 na stránce 163 obsahuje přístupový seznam pro /Management/Groups/Travel, který definuje oprávnění pro řízení skupin group1 a group2. Následující operace a oprávnění ACL jsou vhodná pro správu skupin: Operace
Oprávnění
vytvořit (novou skupinu) importovat (data skupiny z registru uživatelů)
N (vytvořit)
vymazat (skupinu)
d (vymazat)
zobrazit (podrobnosti o skupině)
v (zobrazit)
upravit (popis skupiny)
m (upravit)
přidat (stávajícího uživatele do skupiny)
A (přidat)
vymazat (uživatele ze skupiny)
A (přidat)
Chcete-li provádět uvedené operace, použijte buď odpovídající příkazy obslužného programu pdadmin, nebo rozhraní Web Portal Manager.
164
IBM Tivoli Access Manager: Base: Administrativní příručka
Upozornění Oprávnění (A) má velkou moc, protože dovoluje přidat libovolného stávajícího uživatele do vašich skupin. Pokud umístíte do skupiny vnějšího uživatele, administrátor takové skupiny může nyní řídit tohoto uživatele (a může sdílet kontrolu nad uživatelem s administrátory dalších skupin, ve kterých je daný uživatel členem). Toto oprávnění je nejlépe udělit pouze administrátorům na vysoké úrovni v hierarchii, kteří jsou odpovědní za organizaci uživatelů a skupin a firemní politiku. Vzhledem k velkému dosahu oprávnění A buďte velmi opatrní při udělování tohoto oprávnění administrátorovi. Delegovaný administrátor s oprávněním A by neměl mít současně oprávnění m, W, N, nebo d.
Poznámky: v Oprávnění pro vytvoření (N) musí být uvedeno v přístupovém seznamu, který je připojen k /Management/Groups nebo k objektu typu zásobník pro skupiny. v Všechna ostatní vypsaná oprávnění mohou být uvedena v přístupovém seznamu připojenému k /Management/Groups, k objektu typu zásobník pro skupiny, nebo k vlastnímu objektu skupiny.
Politiky ACL ovlivňující správu uživatelů Administrátor skupin může provést akci v uživateli, má-li administrátor odpovídající oprávnění definované v libovolné ze skupin, kde je tento uživatel členem. Následující operace a oprávnění ACL jsou vhodná pro správu uživatelů: Operace
Oprávnění
vytvořit (nového uživatele v jedné nebo více uvedených skupinách) naimportovat (data uživatele z registru uživatelů)
N (vytvořit)
vymazat (uživatele)
d (vymazat)
zobrazit (podrobnosti o uživateli)
v (zobrazit)
upravit (popis uživatele)
m (upravit)
platný účet
m (upravit)
znovu nastavit heslo
W (heslo)
platné heslo
W (heslo)
Chcete-li provádět uvedené operace, použijte buď odpovídající příkazy obslužného programu pdadmin, nebo rozhraní Web Portal Manager.
Poznámky: v Oprávnění pro vytvoření (N) (v přístupovém seznamu skupiny nebo přístupovém seznamu zásobníku skupin) vám dovoluje vytvářet nebo importovat uživatele a zadávat tyto uživatele do skupin, které řídíte. user create uživatel1 “cn=uživatel1,c=us” uživatel1 uživatel1 adcde skupina1 user import uživatel2 “cn=uživatel2,c=us” skupina1
v Můžete také vytvořit uživatele, aniž byste určili skupinu. V takovém případě však oprávnění pro vytvoření (N) musí být uvedeno v přístupovém seznamu objektu typu zásobník /Management/Users.
Kapitola 16. Delegovaná administrativa
165
v v
v
v
Přístupový seznam připojený k /Management/Users definuje oprávnění pro všechny uživatele (ať už jsou členy skupiny nebo ne). Administrátor skupiny může provádět určité akce s uživatelem, pokud má nadefinována odpovídající oprávnění v nějaké ze skupin, jejichž členem uživatel je. Pokud uživatel není členem žádné skupiny, administrátor musí mít odpovídající oprávnění v přístupovém seznamu pro /Management/Users, aby mohl provádět operace s tímto uživatelem. Oprávnění pro heslo (W) je vhodné pro operátory na helpdesku, kteří musí pomáhat uživatelům, kteří zapomněli nebo ztratili svá hesla. Operátor může znovu nastavit ztracené heslo na nějakou známou hodnotu, a pak nastavit user modify password-valid (pdadmin) na hodnotu no. Tato akce by měla donutit uživatele, aby si změnil při nejbližším přihlášení své heslo. Všimněte si, že nastavení user modify password-valid na hodnotu no neoznačuje pro uživatele, jestli je heslo neplatné kvůli politice max-password-age, což je globální nastavení. Příkaz politiky set max-password-age nastaví maximální dobu, za kterou dojde k ukončení platnosti hesla. Oprávnění pro zobrazení (v) se používá k ovládání výstupu příkazů user list, user list-dn, user show groups, group list a group list-dn. Oprávnění pro zobrazení se používá k filtraci výstupu těchto příkazů. Pokud uživatel nemá oprávnění pro zobrazení v oprávnění skupiny nebo uživatele, která byla vrácena příkazem, pak tato skupina nebo uživatel je odfiltrován z výstupu.
Bezpečnostní politika delegované administrativy Předchozí sekce popisovaly zvlášť, jak delegovat administrativa bezpečnostní politiky pro ochranu zdrojů ve vaší doméně a také jak delegovat správy uživatelů, který si vytvoří přístup k těmto zdrojům. Tyto dva individuální aspekty delegované administrativy je často nutné zkombinovat, aby bylo možné vytvořit bezpečnostní politiku s kompletně delegovanou administrativou. Při takové akci však musíte dávat skutečně velký pozor. Konkrétně musíte být opatrní, jaká oprávnění udělujete ve vzájemných kombinacích. Například oprávnění A by nikdy nemělo být uděleno dohromady s oprávněními m, W nebo d, s výjimkou skutečně prověřených a zkušených administrátorů (a možná, že vůbec ne). Následkem udělení obou oprávnění A a W jednomu administrátorovi je, že tento administrátor může přidat libovolného uživatele do skupiny, ke které má uvedená oprávnění a pak změnit tomuto uživateli heslo. Může být zvolen skutečně libovolný uživatel, včetně pokročilých administrátorů, dokonce včetně administrátora sec_master. Tímto způsobem zlovolný administrátor může získat úplný přístup k systému tak, že se přihlásí jako uvedený pokročilý uživatel. Následky přidělení oprávnění A a m dohromady jsou podobné, s výjimkou toho, že administrátor s oběma těmito oprávněními může používat jejich kombinaci k pouhému zablokování libovolného účtu. Následky přidělení oprávnění A a d dohromady jsou podobné, s výjimkou toho, že administrátor s oběma těmito oprávněními může díky této kombinaci pouze vymazat ID libovolného uživatele ve skupině. Pokud definujete politiku úplně delegované administrativy, výsledkem těchto omezení je určitá struktura a její použití ve vašich skupinách uživatelů. Musíte vytvořit skupiny, které používáte, abyste na ně mohli delegovat úlohy správy uživatelů — jako např. vytváření nových uživatelů, odstraňování uživatelů a opětovná nastavování hesel uživatelů. Administrátoři, kteří provádějí úlohy administrativy uživatelů, by měli mít oprávnění N, d, m, W a v, aby mohli vytvářet, odstraňovat, upravovat (blokovat nebo měnit popis), znovu nastavovat nebo nastavovat jako neplatná hesla a zobrazovat uživatele, za
166
IBM Tivoli Access Manager: Base: Administrativní příručka
jejichž správu jsou odpovědní. Tyto skupiny se používají pouze pro delegování správy uživatelů. Neměly by se používat pro ochranu jiných zdrojů v doméně. Musíte také zavést skupiny, které používáte k delegování správy bezpečnostní politiky pro chráněné zdroje v rámci domény. Administrátoři, kteří řídí bezpečnostní politiku těchto skupin, by měli mít oprávnění A a v, ale žádné z oprávnění N, d, m nebo W. Tyto skupiny se používají k řízení přístupu ke skutečným zdrojům, které vyžadují ochranu. Příklad: Za předpokladu, že vlastníte webový prostor s přístupem k Internetu se zdroji, které vy měly být: v veřejně přístupné v přístupné pouze pro zákazníky a zaměstnance v přístupné pouze pro zaměstnance Prostor je možné rozčlenit následovně: /WebSEAL/ www.company_ibm.com/ zákazníci/ obchodníci/
ACL v kořenu webového prostoru www.company_ibm.com umožňuje veřejný přístup k všemu v tomto prostoru. Přístupový seznam o objektu zákazníci dovoluje přístup zákazníkům a obchodníkům. Jiný přístupový seznam u objektu obchodníci dovoluje přístup pouze obchodníkům.Tyto přístupové seznamy by mohly vypadat třeba takto: veřejný-přístup user sec_master any-other unauthenticated přístup-zákazníků user sec_master group zakaznici group obchodnici ostatní unauthenticated user sec_master group obchodnici ostatní unauthenticated
Tyto přístupové seznamy by měly být připojeny v uvedeném pořadí k: /WebSEAL/www.company_ibm.com /WebSEAL/www.company_ibm.com/customers /WebSEAL/www.company_ibm.com/sales
Předpokládejme, že máte následující politiku delegované administrativy uživatelů. Obchodníkům (členům skupiny obchodníci) je povoleno vytvářet nové účty pro zákazníky a udělovat těmto zákazníkům přístup do části zákazníci webového prostoru. Pouze administrátoři (členové skupiny obchodníci-admin) mají oprávnění spravovat účty nových obchodníků. Uvedená struktura skupin implementuje tuto politiku: /Management/ Groups/ obchodníci
Přístupový seznam obchodníci-admin je určen pro administrativu členství ve skupině obchodníci, která se naopak používá k řízení přístupu části webového prostoru pouze-pro-obchodníky. Jediné oprávnění, které je potřeba, musí mít skupina obchodníci-admin, aby byla schopná přidávat a mazat uživatele z této skupiny. Oprávnění pro zobrazení (v) je také vhodné pro administrátory, neboť jim dovoluje zobrazovat členství ve skupinách a uživatele ve skupině. obchodníci-admin group super-admin group admin
Tabc TAv
Přístupový seznam obchodníci-uživ-admin, je-li připojen ke skupině obchodníci-uživ řídí, kdo může spravovat uživatele, kteří jsou členy skupiny obchodníci-uživ (to je opět skupina obchodníci-admin). obchodníci-uživ-admin group super-admin group admin
Tabc TNWdmv
Podobně přístupový seznam zákazníci-admin se používá k administrativě členství skupiny zákazníci, která je naopak používána k řízení přístupu do části webového prostoru pouze-pro-zákazníky. zákazníci-admin group super-admin group obchodníci
Tabc TAv
Přístupový seznam zákazníci-uživ-admin, je-li připojen ke skupině zákazníci-uživ, řídí, kdo může spravovat členy skupiny zákazníci-uživ (to je opět skupina obchodníci). Dále umožníme členům skupiny obchodníci-admin spravovat zákazníky. zákazníci-uživ-admin group super-admin group obchodníci group admin
Tabc TNWdmv TNWdmv
Všimněte si, že každý přístupový seznam obsahuje záznam skupiny super-admin, který této skupině uděluje oprávnění připojovat, procházet a řídit. Členové skupiny super-admin jsou odpovědni za administrativu těchto přístupových seznamů.
168
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 17. Soubory protokolu a směrování Obsah souborů protokolu může být užitečným zdrojem informací při monitorování a odstraňování problémů aktivity serverů produktu Tivoli Access Manager. Soubory protokolu zachycují veškeré chybové a varovné zprávy generované servery produktu Tivoli Access Manager. Umístění adresáře pro soubory protokolu zpráv o obslužnosti jsou různé v závislosti na tom, je-li Tivoli Common Directory konfigurovaný. Soubory směrování kontrolují umístění a konfigurace souborů protokolu zpráv obslužnosti. Tato kapitola popisuje syntaxi konfigurace použitou v souborech směrování a definuje předvolené jméno a umístění souborů protokolů zpráv. Publikace IBM Tivoli Access Manager for e-business Problem Determination Guide popisuje jak se obrátit na trasování a protokolování včetně protokolování serveru Tivoli Common Directory. Tato kapitola obsahuje následující části: v “Základní soubory směrování” v “Společné adresáře souborů protokolu” na stránce 174 v “Prohlížeč protokolů XML” na stránce 176 v “Úlohy souborů protokolu a trasování” na stránce 176
Základní soubory směrování Soubor směrování je soubor ASCII, který obsahuje příkazy řídicí konfiguraci zpráv. Každý server produktu Tivoli Access Manager má svůj vlastní soubor směrování. pdmgrd_routing pro server politik produktu Tivoli Access Manager (pdmgrd) pdacld_routing pro autorizační server produktu Tivoli Access Manager (pdacld) pdmgrproxyd_routing pro proxy server politik produktu Tivoli Access Manager (pdmgrproxyd) routing pro směrování obslužnosti produktu Tivoli Access Manager
Protokoly zpráv obslužnosti Zprávy obslužnosti Base produktu Tivoli Access Manager jsou řízené soubory směrování Base produktu Tivoli Access Manager. Soubory směrování jsou soubory ASCII, které obsahují dodatečné informace ve formě komentářů. Záznamy v souboru směrování serveru určí typy zpráv obslužnosti, které jsou protokolované. Můžete zablokovat nebo aktivovat libovolný typ protokolování zpráv tím, že přidáte nebo odstraníte současně znak komentáře (#) na začátku řádku v souboru směrování.
Tabulka 7. Soubory směrování pro UNIX a Windows server pdmgrd UNIX: FATAL:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrd_utf8.log :644:ivmgr:ivmgr ERROR:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrd_utf8.log :644:ivmgr:ivmgr WARNING:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrd_utf8.log :644:ivmgr:ivmgr NOTICE:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrd_utf8.log :644:ivmgr:ivmgr #NOTICE_VERBOSE:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/ msg__pdmgrd_utf8.log:644:ivmgr:ivmgr Windows: FATAL:STDERR:-;FILE:%PDDIR%\log\msg__pdmgrd_utf8.log ERROR:STDERR:-;FILE:%PDDIR%\log\msg__pdmgrd_utf8.log WARNING:STDERR:-;FILE:%PDDIR%\mog\msg__pdmgrd_utf8.log NOTICE:FILE:%PDDIR%\log\msg__pdmgrd_utf8.log Poznámka: V systému Windows je speciální proměnná prostředí PDDIR nastavená na dobu běhu instalačního adresáře produktu Tivoli Access Manager. server pdacld UNIX: FATAL:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdacld_utf8.log :644:ivmgr:ivmgr ERROR:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdacld_utf8.log :644:ivmgr:ivmgr WARNING:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdacld_utf8.log :644:ivmgr:ivmgr NOTICE:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdacld_utf8.log :644:ivmgr:ivmgr #NOTICE_VERBOSE:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/ msg__pdacld_utf8.log:644:ivmgr:ivmgr Windows: FATAL:STDOUT:-;UTF8FILE:%PDDIR%\log\msg__pdacld_utf8.log ERROR:STDOUT:-;UTF8FILE:%PDDIR%\log\msg__pdacld_utf8.log WARNING:STDOUT:-;UTF8FILE:%PDDIR%\log\msg__pdacld_utf8.log NOTICE:STDOUT:-;UTF8FILE:%PDDIR%\log\msg__pdacld_utf8.log #NOTICE_VERBOSE:STDOUT:-;UTF8FILE:%PDDIR%\log\msg__pdacld_utf8.log Poznámka: V systému Windows je speciální proměnná prostředí PDDIR nastavená na dobu běhu instalačního adresáře produktu Tivoli Access Manager.
170
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 7. Soubory směrování pro UNIX a Windows (pokračování) server pdmgrproxyd UNIX: FATAL:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrproxyd_utf8.log :644:ivmgr:ivmgr ERROR:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrproxyd_utf8.log :644:ivmgr:ivmgr WARNING:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrproxyd_utf8.log :644:ivmgr:ivmgr NOTICE:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrproxyd_utf8.log :644:ivmgr:ivmgr #NOTICE_VERBOSE:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/ msg__pdmgrproxyd_utf8.log:644:ivmgr:ivmgr Windows: FATAL:STDOUT:-;UTF8FILE:%PDDIR%\log\msg__pdmgrproxyd_utf8.log ERROR:STDOUT:-;UTF8FILE:%PDDIR%\log\msg__pdmgrproxyd_utf8.log WARNING:STDOUT:-;UTF8FILE:%PDDIR%\log\msg__pdmgrproxyd_utf8.log NOTICE:STDOUT:-;UTF8FILE:%PDDIR%\log\msg__pdmgrproxyd_utf8.log #NOTICE_VERBOSE:STDOUT:-;UTF8FILE:%PDDIR%\log\msg__pdmgrproxyd_utf8.log Poznámka: V systému Windows je speciální proměnná prostředí PDDIR nastavená na dobu běhu instalačního adresáře produktu Tivoli Access Manager.
Konfigurační soubory serveru sesbírají informace ze souborů směrování. Avšak, byl-li z jakéhokoliv důvodu vymazaný soubor směrování, záznam objektu stanza log-file pro odpovídající server bude použit místo něj. Předvolené umístění konfigurace je následující: UNIX: /var/PolicyDirector/log/ Windows: adresář_pd\log\ Například, konfigurovaný záznam objektu stanza log-file v konfiguračním souboru autentizačního serveru ivacld.conf by byl stejný jako následující: UNIX: [ivacld] logfile = /var/PolicyDirector/log/msg__pdacld_utf8.log
Výstupní syntaxe souboru směrování Podle předvolby, je-li spuštěná Base produktu Tivoli Access Manager v popředí, se zprávami se zachází jedním z následujících způsobů: v Zprávy jsou odesílané na obrazovku jako STDOUT nebo STDERR. v Zprávy jsou odesílané do odpovídajících záznamů souborů protokolu v adresáři protokolu.
Kapitola 17. Soubory protokolu a směrování
171
Podle předvolby, je-li Base produktu Tivoli Access Manager spuštěná na pozadí, zprávy jsou odesílané do souborů protokolu uvedených v souborech směrování serveru. V tomto příkladu předvolených záznamů šablon souborů směrování řídí syntaxe výstup protokolu. Formát syntaxe používá dvojtečku (:) jako oddělovač: FATAL:STDOUT:-;FILE:/var/PolicyDirector/log/msg__fatal_utf8.log:666:ivmgr:ivmgr
Kde: typ_zprávy Typy zpráv protokolu obslužnosti zahrnují: v Fatal Ukončeno fatální chybou. Vyskytla se neodstranitelná chyba (jako porušení databáze), kde oprava bude s velkou pravděpodobností vyžadovat manuální zásah. Program je obvykle ihned ukončen po výskytu této chyby. v Error Detekována chyba. Vyskytla se neočekávaná událost, která není konečná (jako překročení časového limitu) a kterou lze snadno napravit vaším zásahem. Program pokračuje v operaci, přestože některé funkce nebo služby už nemusely být dostupné. Tato úroveň závažnosti také indikuje, že určitá žádost nebo akce nemusely být dokončeny. v Warning Napravitelná chyba. Vyskytla se chyba, u které došlo k automatické nápravě (například, nebyl nalezen konfigurační souboru a místo něj byla použitá hodnota předvolby). Tato úroveň závažnosti indikuje stav, který by se mohl stát chybovým, pokud by jeho účinky byly nežádoucí, nebo indikuje stav, který by mohl vyústit v chybu, pokud nebude okamžitě napraven. v Notice Informační upozornění: vyskytla se význačná rutinní hlavní událost. Například, došlo ke spuštění serveru. v Notice_verbose Komentované informační upozornění. Vyskytla se význačná rutinní událost. Například, došlo k odstranění záznamu z adresáře. výstup_do_popředí Když je Base produktu Tivoli Access Manager spuštěná na popředí, lze právy protokolování odesílat na obrazovku jako STDOUT nebo STDERR. výstup_na_pozadí Je-li Base produktu Tivoli Access Manager spuštěná na pozadí, uvádí, jak by měly být zprávy dané úrovně závažnosti zpracovávané a jakým způsobem uskutečnit výstup těchto zpráv do těchto typů souborů protokolu: FILE nebo TEXTFILE jméno_souboru Předvolený záznam FILE nebo TEXTFILE pro konfigurované soubory protokolu, které uvádějí, že soubory protokolu nejsou recyklované ani překryté. Tyto volby vám umožní uvést, který výstup protokolu bude nasměrovaný do jména souboru, které ihned následuje. Další parametr určí, jestli souboru protokolu narůstá nekonečně nebo jestli může obsáhnout jen omezený počet generací. UTF8FILE Výstupní záznam UTF8FILE je ekvivalentní se záznamem TEXTFILE až na fakt, že data jsou zakódovaná ve formátu UTF-8.
172
IBM Tivoli Access Manager: Base: Administrativní příručka
XMLSTDERR Záznam, který je ekvivalentní s STDERR kromě toho, že data budou zapsaná ve formátu Log XML a zakódované v UTF-8. XMLSTDOUT Záznam, který je ekvivalentní se STDOUT až na fakt, že data budou zapsaná ve formátu Log XML a zakódovaná v UTF-8. XMLFILE Záznam je ekvivalentní s TEXTFILE kromě toho, že data budou zapsaná ve formátu Log XML a zakódovaná v UTF-8. DISCARD Tento záznam uvádí, že nechcete zaznamenávat zprávy uvedených typů zpráv (úroveň závažnosti). Tyto soubory jsou konfigurované, aby narůstaly postupně bez omezení. Pokud soubor nakonfigurujete tak, aby rostl bez omezení, musíte sledovat prostor na disku. Pokud už nebudete mít místo na disku, budete muset pravidelně mazat nebo omezovat stávající soubory protokolu. cesta_směrování Předvolené adresáře pro soubory směrování serveru jsou: UNIX: /opt/PolicyDirector/etc/ Windows: C:\Program Files\Tivoli\Policy Director\etc\ Tato kapitola používá proměnnou cesta_směrování jako konvenci pro předvolenou cestu souborů směrování. jméno_souboru_protokolu Předvolená šablona souboru protokolu zprávy používá tyto jména souborů pro soubory protokolu ve formátu UTF–8: msg__fatal_utf8.log msg__error_utf8.log msg__warning_utf8.log msg__notice_utf8.log msg__verbose_utf8.log
Všimněte si, že se ve jménu souboru protokolu zprávy vyskytují dvě podtržítka za msg. Soubory protokolu zpráv serveru Tivoli Access Manager používají různá jména souborů protokolu, které se vztahují spíše ke jménům serverů. Viz jména souborů protokolu, kterými se zabývá Tabulka 7 na stránce 170. jméno_souboru_oprávnění Přípony oprávnění v souboru (například, 666). Přípony oprávnění jsou platné pouze v UNIXu. jméno_uživatele Uživatel, který vlastní soubor (například, ivmgr). Tato volba se týká pouze UNIXu. jméno_skupiny Skupina, která vlastní soubor (například, ivmgr). Tato volba se týká pouze UNIXu. Uvádí-li záznam FILE pro konfigurované soubory protokolu hodnoty n a m jako: NOTICE:FILE.10.1000:/var/PolicyDirector/log/msg__syslog.log
Kapitola 17. Soubory protokolu a směrování
173
Znak n představuje počet souborů a znak m představuje počet přidaných položek povolených pro soubor. Například FILE.10.1000 uvádí, že může mít maximálně 10 souborů protokolu zpráv s tím, že každý soubor obsahuje ne víc než 1000 záznamů protokolu na jeden soubor. Soubory protokolu zpráv se zalamují do prvních souborů poté, co poslední soubor dosáhne svůj limit, nebo je-li restartovaný nebo zastavený server. Používáte-li soubor protokolu zpráv znova, existující záznamy budou přepsané (vymazané). msg__notice_utf8.log.1 msg__notice_utf8.log.2 . . . msg__notice_utf8.log.10
Společné adresáře souborů protokolu Produkt Tivoli Access Manager poskytuje schopnosti protokolování Tivoli Common Directory. Aktivujete-li jej, společný adresář protokolování Tivoli Common Directory se nachází tam, kde jsou všechny soubory protokolu zpráv obslužnosti produktu Tivoli Access Manager. Jiné typy souborů protokolu aplikací se nadále nacházejí ve svých instalačních umístěních. Produkty a aplikace Tivoli, které poskytují podporu Common Directory, ukládají své soubory vztahující se k obslužnosti (jako protokoly, data o zachycení dat prvního selhání (data FFDC) a skripty obslužnosti) na stejném centrálním umístění. Uložením všech souborů protokolu produktu Tivoli na stejné místo usnadníte hledání a vyšetřování ne jenom pro soubory produktu Tivoli Access Manager, je-li nutné určit příčinu problému, ale také pro soubory protokolu jiných produktů Tivoli.
Předvolené umístění Tivoli Common Directory Následující struktura společného adresáře soustřeďuje soubory protokolu, soubory zachycení dat prvního selhání a skripty obslužnosti pro všechny produkty Tivoli. Struktura adresáře zahrnuje: společný_adresář_tivoli/XXX/podadresář/[kvalifikátor]
kde: společný_adresář_tivoli Představuje centrální umístění pro soubory Tivoli Common Directory. Během konfigurace bude požádáni o poskytnutí umístění Tivoli Common Directory pouze, pokud jste ještě nikdy nepoužívali Tivoli Common Directory pro kterýkoliv produkt Tivoli. XXX
Představuje 3písmenný identifikátor, který má být použitý pro soubory protokolu zpráv produktu.
podadresář Představuje podadresář, který rozděluje soubory protokolu zpráv na kategorie. Podadresáře zahrnují: logs pro soubory protokolu, ffdc pro soubory zachycení dat prvního selhání, scripts pro skripty obslužnosti. datum
174
Představuje podadresář závislý na datumu (ve formátu rrrrmmdd) pro data FFDC zachycené v uvedeném datumu.
IBM Tivoli Access Manager: Base: Administrativní příručka
[kvalifikátor] Představuje volitelné podadresáře pro specificky pojmenované úrovně nebo komponenty produktu. Možná bude nutné, aby se kvalifikátor vyhnul kolizi, kdykoliv dojde k výskytu více komponent nebo úrovní pokoušejících se uložit různé soubory s použitím stejné plně kvalifikované cesty. Předvolené instalační umístění pro Tivoli Common Directory (tivoli_common_dir) je: UNIX: /var/ibm/tivoli/common Windows: C:\Program Files\ibm\tivoli\common\ V UNIXu by měl Tivoli Common Directory vlastnit oprávnění 771 a být ve vlastnictví skupiny tivoli. Poznámka: Poté, co jste definovali umístění Tivoli Common Directory nebo přijali předvolené umístění, nelze jej měnit.
Soubor vlastností Tivoli Common Directory Aktuální umístění Tivoli Common Directory je uvedené v souboru log.properties. Předvolená cesta do tohoto konfiguračního souboru je: UNIX: /etc/ibm/tivoli/common/cfg/log.properties Windows: C:\Program Files\ibm\tivoli\common\cfg\log.properties V UNIXu by měl file Common Directory vlastnit oprávnění 664 a být ve vlastnictví skupiny tivoli.
Předvolené umístění produktu Tivoli Access Manager Nebylo-li umístění Tivoli Common Directory uvedeno během doby běhu C nebo běhové konfigurace Javy produktu Tivoli Access Manager, budete požádáni o definování umístění Tivoli Common Directory (TCD) pro vaše zprávy obslužnosti a soubory protokolu trasování produktu Tivoli Access Manager. Produkt Tivoli Access Manager definuje předvolené umístění souboru protokolu Tivoli Common Directory a používá podadresář logs pro ukládání zpráv a protokolů trasování. Předvolené umístění se zobrazí a vy jej můžete změnit, pokud jste Tivoli Common Directory neinstalovali ještě nikdy předtím. Předvolená syntaxe instalačního umístění je: TCD/XXX/protokoly/
kde: TCD
Představuje příponu adresáře tivoli_common_dir uvedenou produktem Tivoli Access Manager, nebyl-li Tivoli Common Directory ještě definovaný instalací jiného produktu Tivoli.
XXX
Představuje 3písmenný identifikátor, který má být použitý soubory protokolu zpráv produktu. Pro produktu Tivoli Access Manager identifikátory zahrnují: HPD pro IBM Tivoli Access Manager Base, HPW pro IBM Tivoli Access Manager WebSEAL, AMZ pro IBM Tivoli Access Manager Web Security plug-ins, AWX pro IBM Tivoli Access Manager WebSphere Application Server, AWL pro IBM Tivoli Access Manager BEA WebLogic Server, AWD pro Tivoli Access Manager Edge Server, Kapitola 17. Soubory protokolu a směrování
175
AOS pro IBM Tivoli Access Manager for Operating Systems, DRQ pro IBM Tivoli Access Manager for Business Integration. protokoly Podadresář použitý pro produkt Tivoli Access Manager. Všimněte si, že je definovaný pouze jeden podadresář (logs) pro soubory protokolu zpráv a trasování. Je-li Tivoli Common Directory konfigurovaný, cesta společného adresáře protokolování je umístěná v záznamu objektu stanza tivoli_common_dir v konfiguračním souboru pd.conf. Například: [pdrte] tivoli_common_dir = C:\Program Files\Policy Director\TAMBase\
Je-li konfigurovaný pro Tivoli Common Directory, bude v sobě konfigurovaný záznam objektu stanza log-file v konfiguračním souboru serveru odrážet instalační umístění Tivoli Common Directory. Například, je-li Tivoli Common Directory aktivovaný pro autorizační server (pdacld), záznam objektu stanza log_file se bude shodovat s následujícím: UNIX používá umístění Tivoli Common Directory: [ivacld] log-file = /PolicyDirector/TAMBase/HPD/logs/msg__pdacld_utf8.log
Windows používá umístění Tivoli Common Directory: [ivacld] log-file = C:\Program Files\PolicyDirector\TAMBase\HPD\logs\msg__pdacld_utf8.log
Prohlížeč protokolů XML Abyste si mohli snadněji zobrazit výstup XML, použijte nástroj Tivoli XML Log Viewer (Prohlížeč protokolů XML Tivoli), který je poskytovaný produktem Tivoli Access Manager. Klíčová slova XMLFILE, XMLSTDERR a XMLSTDOUT v souborech směrování probíraná v části “Výstupní syntaxe souboru směrování” na stránce 171 jsou použitá pro produkci protokolů zpráv XML a protokolů trasování XML. Viz publikace IBM Tivoli Access Manager for e-business Problem Determination Guide, chcete-li se dozvědět víc o zobrazování formátu XML a prověření krok za krokem protokolování zpráv a výstupů XML souborů protokolování trasování.
Úlohy souborů protokolu a trasování Tato sekce popisuje úlohy souborů protokolu a trasování dostupné pro administrátora. v “Změna umístění souborů protokolu zpráv” v “Zprávy protokolu ve formátu protokolu XML” na stránce 177 v “Aktivace zobrazování záznamů trasování” na stránce 178
Změna umístění souborů protokolu zpráv Abyste změnili adresář pro soubory protokolu zpráv specifických pro server Tivoli Access Manager: 1. Přejděte do adresáře, kde jsou umístěné soubory směrování. Předvolené umístění adresáře je jedno z následujících: UNIX : /opt/PolicyDirector/etc/ Windows : C:\Program Files\Tivoli\Policy Director\etc\ 2. Zvolte jeden z odpovídajících souborů směrování vztahujících se k serveru, které chcete editovat:
176
IBM Tivoli Access Manager: Base: Administrativní příručka
v pdmgrd_routing pro server politik produktu Tivoli Access Manager (pdmgrd), v pdacld_routing pro autorizační server produktu Tivoli Access Manager (pdacld), v pdmgrproxyd_routing pro proxy server politik produktu Tivoli Access Manager (pdmgrproxyd), v routing pro obecné informace o obslužnosti produktu Tivoli Access Manager. 3. Editujte soubor a zjistěte umístění sekce nazvané Sequential Logging (Postupné protokolování). 4. Změňte předvolené umístění pro soubory protokolu zpráv jako odpovídající. V následujícím příkladu serveru politik (pdmgrd) můžete změnit předvolené instalační umístění cesta_směrování /var/PolicyDirector/log/: FATAL:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrd_utf8.log :644:ivmgr:ivmgr ERROR:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrd_utf8.log :644:ivmgr:ivmgr WARNING:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrd_utf8.log :644:ivmgr:ivmgr NOTICE:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/msg__pdmgrd_utf8.log :644:ivmgr:ivmgr #NOTICE_VERBOSE:STDOUT:-;UTF8FILE:/var/PolicyDirector/log/ msg__pdmgrd_utf8.log:644:ivmgr:ivmgr
na jiné umístění adresáře /myTAMlogs/: FATAL:STDOUT:-;UTF8FILE:/myTAMlogs/msg__pdmgrd_utf8.log:644:ivmgr:ivmgr ERROR:STDOUT:-;UTF8FILE:/myTAMlogs/msg__pdmgrd_utf8.log:644:ivmgr:ivmgr WARNING:STDOUT:-;UTF8FILE:/myTAMlogs/msg__pdmgrd_utf8.log:644:ivmgr:ivmgr NOTICE:STDOUT:-;UTF8FILE:/myTAMlogs/msg__pdmgrd_utf8.log:644:ivmgr:ivmgr #NOTICE_VERBOSE:STDOUT:-;UTF8FILE:/myTAMlogs//msg__pdmgrd_utf8.log :644:ivmgr:ivmgr
5. Ukončete a uložte soubor směrování. Pamatujte, že musíte soubory protokolu pravidelně čistit, abyste tak předešli jejich přílišnému nárůstu.
Zprávy protokolu ve formátu protokolu XML Zprávy protokolu ve formátu XML: 1. Přejděte do adresáře, kde jsou umístěné soubory směrování. Předvolené umístění adresáře je jedno z následujících: UNIX : /opt/PolicyDirector/etc/ Windows : C:\Program Files\Tivoli\Policy Director\etc\ 2. Zvolte jeden z odpovídajících souborů směrování vztahujících se k serveru, které chcete editovat: v pdmgrd_routing pro server politik produktu Tivoli Access Manager (pdmgrd), v pdacld_routing pro autorizační server produktu Tivoli Access Manager (pdacld), v pdmgrproxyd_routing pro proxy server politik produktu Tivoli Access Manager (pdmgrproxyd), v routing pro obecné informace o obslužnosti produktu Tivoli Access Manager. 3. Vyhledejte řádek stejný jako následující soubor směrování: ERROR:STDOUT:-;XMLFILE:%PDDIR%/log/msg__error.log
Například, abyste změnili řádek tak, aby uváděl, že zprávy ERROR by měly být protokolované ve formátu XML místo textového formátu, pro obojí STDOUT a soubor msg__error.log: ERROR:XMLSTDOUT:-;XMLFILE:%PDDIR%/log/msg__error.log Kapitola 17. Soubory protokolu a směrování
177
kde %PDDIR% je proměnná UNIXového adresáře produktu Tivoli Access Manager. Viz “Výstupní syntaxe souboru směrování” na stránce 171, chcete-li získat více podrobností o tom, jak uvádět další změny.
Aktivace zobrazování záznamů trasování Jméno každé kategorie události je zapsané do záznamu události trasování, jakmile je konkretizováno. Abyste umožnili trasování během spuštění a mohli si zobrazit záznamy trasování: 1. Editujte odpovídající soubory směrování pro server. Jména souborů trasování zahrnují: v pdmgrd_routing pro server politik produktu Tivoli Access Manager (pdmgrd), v pdmgrd_routing pro autorizační server produktu Tivoli Access Manager (pdacld), v pdmgrproxyd_routing pro proxy server politik produktu Tivoli Access Manager (pdmgrproxyd). 2. Přidejte řádek podobný následujícímu řádku směrování: *:*.9:TEXTFILE:%PDDIR%/log/trace_%ld.log
Nebo odstraňte znak komentáře (#) na začátku tohoto řádku, pokud už existuje v souboru směrování, abyste tak umožnili zobrazování záznamů trasování. 3. Změňte tento řádek, chcete-li protokolovat tato data trasování ladění ve formátu protokolu XML. Například, můžete změnit řádek, aby odesílal výstup do souboru XML místo textového souboru: *:*.9:XMLFILE.10.1000:%PDDIR%/log/trace__%ld.log;XMLSTDERR:-
kde %PDDIR% je proměnná UNIXového adresáře produktu Tivoli Access Manager. Syntaxe XMLFILE.10.1000 je vysvětlená v části “Výstupní syntaxe souboru směrování” na stránce 171. Viz publikace IBM Tivoli Access Manager for e-business Problem Determination Guide, která se zabývá záznamy trasování podrobněji.
178
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 18. Výstup XML pro protokolování a protokoly monitorování Monitorované události se zachycují v monitorování ve standardním formátu používajícím příznaky XML (Extensible Markup Language). XML je pouze pomocný krok pro doručení zobrazení prezentace dat. Soubor XML je ve formátu ASCII a lze jej přečíst přímo nebo pro další rozbor ho lze předat jiným externím analyzátorům.
Pomocný formát DTD Jestliže jste administrátorem monitorování, očekává se od vás, že vyberete a vyjmete události na základě vašich vlastních kritérií. Tato aktivita by mohla zahrnovat přeformátování všech událostí s použitím odpovídajícího formátu DTD (Document Type Definition) nebo schématu pro analýzu nástrojů, které používáte. Definice DTD je zprostředkovaný formát, který poskytuje popis dat, která je možné zachycovat.
Bloky dat a výstupní pole Celý prověřovací záznam nepředstavuje jeden XML dokument. Každá monitorovaná událost v souboru je zapsána jako samostatný datový blok XML. Každý datový blok se podřizuje pravidlům standardní syntaxe XML. Například, následující blok dat je záznam auditu, aby uživatel mohl získat pověření pro autorizaci: <event rev="1.2"> 2003-11-14-16:25:08.341+00:00I-----0azn0phaedrus <principal auth="IV_LDAP_V3.0">sec_master azn_id_get_creds
Tabulka 8 na stránce 180 popisuje výstupní pole XML, které jsou možné s použitím předvolených prvků DTD Tivoli Access Manager. Pokud vytvoříte váš vlastní DTD, každé pole musí představovat události, které jste zvolili a vyjmuli podle vašich vlastních kritérií.
Tabulka 8. Jména a popisy pro výstupní pole XML Jméno výstupního pole <event> ...
Popis Monitorovaná událost. Každá monitorovaná událost zachycuje výsledek akce, o kterou se objekt pokusí na cílovém objektu. Pole event může obsahovat tato pole: v date (datum) v outcome (výsledek) v accessor (přistupující objekt) v target (cíl) v data (data) Protože monitorování produktu Tivoli Access Manager používá standardní formát záznamu, ne všechna pole mají nějaký význam pro každou zaznamenanou monitorovanou událost. Pole, která nejsou významná pro určitou událost, mohou obsahovat předvolenou hodnotu. Atributy pro toto pole mohou zahrnovat: v rev v link Příklad: <event rev="1.2"> 2003-11-14-16:25:08.341+00:00I-----0 ... <principal auth="IV_LDAP_V3.0">sec_master azn_id_get_creds
...
Aktuální datum a časové označení. Formát pro datum a časové označení je: yyyy-mm-dd-hh:mm:ss.000+00:00I----Kde: yyyy-mm-ddse vztahuje k roku (yyyy), měsíci (mm) a dni (dd), hh:mm:ss. se vztahuje k hodinám (hh), minutám (mm) a sekundám (ss), 000+00: se vztahuje k časové zóně, 00I----- se vztahuje k časové nepřesnosti v milisekundách. Toto se používá pouze pro účely přejímání. Příklad: <event rev="1.2"> 2003-11-14-16:25:08.341+00:00I----- ...
180
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 8. Jména a popisy pro výstupní pole XML (pokračování) Jméno výstupního pole ...
Popis Výsledek události. Možné hodnoty pole outcome jsou: 0 Úspěšná 1 Selhání 2 Nevyřízená 3 Neznámá Informace o výsledku společně s akcí, pověřením objektu a cílovým objektem jsou zachycené v hlavičce běžného formátu záznamu auditu. Atributy pro toto pole vždy zahrnují: v status (stav) Příklad události selhání: 1 Použijte příkaz pdadmin errtext, aby vám byl poskytnutý výklad pro stavový kód (412668954) události selhání. Pokud chyba není označená v příkazu pdadmin errtext, potom stavový kód nemá původ v podstavci produktu IBM Tivoli Access Manager for e-business. Chcete-li zjistit další definice stavových kódů, viz průvodce určováním problémů aplikace. Příklad úspěšné události: <event rev="1.2"> ... 0 ...
...
Server, který je odesílatelem právě protokolované události. Pole originator může obsahovat tato pole: v component (komponenta) v action (akce) v location (umístění) Platné atributy zahrnují: v blade (rozřazovač) Procesy blade představují server, který byl odesílatelem události. Například, pdmgrd je server politik Tivoli Access Manager. Příklady: <event rev="1.2"> ... azn0phaedrus ...
Kapitola 18. Výstup XML pro protokolování a protokoly monitorování
181
Tabulka 8. Jména a popisy pro výstupní pole XML (pokračování) Jméno výstupního pole ...
Popis Monitorované události jsou rozdělené do kategorií podle funkčnosti serveru, který je generuje. Některé funkcionality jsou společné všem serverům produktu Tivoli Access Manager, zatímco jiné jsou specifické pro daný server. Platné hodnoty zahrnují: azn Zachycuje události autorizace. authn Zachycuje události autentizace. mgmt Zachycuje události správy. http Zachycuje události HTTP WebSEAL. Chcete-li získat více informací o této hodnotě, obraťte se na IBM Tivoli Access Manager for e-business WebSEAL: Administrativní příručka. Platné atributy jsou: v rev Příklad: <event rev="1.2"> ... azn0phaedrus ...
...
Kód akce záznamu auditu. Jsou dvě skupiny událostí v Pro události autentizace nebo autorizace Záznamy auditů pro události autentizace nebo autorizace zahrnují kód akce, který rozlišuje mezi: 0 Události autentizace nebo autorizace. 1 Události změny hesla. 2 Události WebSEAL. v Pro události správy Záznamy auditů pro události správy obsahují kód akce, který označuje příkaz správy pdadmin Tivoli Access Manager. Například, kód akce 13702 se vztahuje k akci POP_MODIFY pro příkaz správy pdadmin pop modify. Viz Tabulka 9 na stránce 190, který udává referenční číslo kódu akce pro každý příkaz správy. Informace o akci společně s pověřením objektu, cílovým objektem a výsledkem jsou zachycené v hlavičce běžného formátu v záznamu auditu. Příklady: <event rev="1.2"> ... azn0phaedrus ...
182
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 8. Jména a popisy pro výstupní pole XML (pokračování) Jméno výstupního pole ...
Popis Umístění (jméno hostitele) počítače. Není-li uvedeno žádné jméno hostitele, bude v poli umístění záznam zaměněn za location not specified. Příklad: <event rev="1.2"> ... azn0phaedrus ...
...
Jméno užívatele, který je původcem události. Není-li uvedeno žádné uživatelské jméno, bude v poli přistupujícího objektu záznam zaměněn za name="user not specified" nebo name="". Pole accessor může obsahovat: v principal (objekt) Platné atributy pro pole accessor zahrnují: v name (jméno) Příklad: <event> ... <principal auth="IV_LDAP_V3.0">sec_master ...
<principal> ...
Pověření uživatelské autorizace. Obecně každá událost zachycuje výsledek akce, o kterou se uživatel (objekt) pokusí v cílovém objektu. Není-li uvedeno žádné jméno uživatele, záznam auth="invalid" nahradí záznam v poli principal (objekt). Platné atributy pro pole principal zahrnují: v auth v domain Informace o pověření objektu společně s akcí, cílovým objektem a výsledkem jsou zachycené v hlavičce běžného formátu záznamu auditu. Příklady: <principal auth="IV_LDAP_V3.0" domain="Default">testuser2
Kapitola 18. Výstup XML pro protokolování a protokoly monitorování
183
Tabulka 8. Jména a popisy pro výstupní pole XML (pokračování) Jméno výstupního pole ...
Popis Informace o cíli. Pole target může obsahovat tato pole: v object (objekt) v process (proces) v azn Platné atributy pro pole target zahrnují: v resource (zdroj) Atribut resource pole target představuje širokou kategorizaci cílových objektů: 0 1 2 3 5 6 7
= = = = = = =
AUTORIZACE ZPRACOVÁNÍ TCB POVĚŘENÍ OBECNÉ APLIKACE AUTENTIZACE
Příklady: <event> ... ... ...
Cílový objekt. Záznamy monitorování autorizace je možné zachycovat tehdy, když má cílový objekt v databázi politik autorizace produktu Tivoli Access Manager (prostoru chráněných objektů) připojenu politiku POP, která umožňuje funkci monitorování. Například: Informace o cílovém objektu společně s akcí, pověřeními objektu a výsledkem jsou zachycené v hlavičce běžného formátu záznamu auditu. Příklady: ...
184
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 8. Jména a popisy pro výstupní pole XML (pokračování) Jméno výstupního pole ...
Popis Informace o autorizační službě. Autorizační služba kontroluje oprávnění k přístupu do požadovaných cílových objektů a porovnává je se schopnostmi uživatele, který je žadatelem. Pole azn může obsahovat tato pole: v perm (oprávnění) v result (výsledek) v qualifier (kvalifikátor) ... 6400 ...
...
Sada ovladačů (oprávnění), která uvádí stavy nezbytné pro provádění určitých operací v daném zdroji. Oprávnění může být uvedené v tomto poli s použitím buď binárního čísla, jako je 64, nebo písmen pro uvedená oprávnění k akci, jako je Tr. Příklad: ... 6400 ...
...
Výsledky kontroly autorizační služby. Příklad: ... 6400 ...
...
Informace o kvalifikátoru. Příklad: ... 6400 ...
Kapitola 18. Výstup XML pro protokolování a protokoly monitorování
185
Tabulka 8. Jména a popisy pro výstupní pole XML (pokračování) Jméno výstupního pole <process> ...
Popis Typ procesu. Pole process může zahrnuvat tyto pole: v pid (ID procesu) v uid (ID uživatele) v eid (ID činného uživatele) v gid (ID skupiny) v egid (ID činné skupiny) Platné atributy pro pole process zahrnují: v architecture (architektura) Platné hodnoty atributů architecture zahrnují: 0 Pro operační systémy UNIX. 1 Pro operační systémy Win32. Příklad: <process architecture="0"> ...
<eid> <egid>
Typy procesů. Pole process může obsahovat tato pole: pid ID procesu eid ID činného uživatele uid Identifikátor uživatele (ID) gid Identifikátor skupiny (ID) egid ID činné skupiny Příklad: <process architecture="unix"> ... packet_id
<policy> ...
Informace o bezpečnostní politice. Pole policy může obsahovat tato pole: v name (jméno) v type (typ) v description (popis) Příklad pole name pro pole policy: <policy> real-traders-onlyrule
...
Jméno atributu policy, který chcete monitorovat. Jméno atributu policy se shoduje s tím, které jste uvedli v seznamu atributů v objektu stanza [aznapi-configuration] odpovídajícího konfiguračního souboru. Například: [aznapi-configuration] audit-attribute = real-traders-only Příklad pole name pro pole policy: <policy> real-traders-onlyrule
186
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 8. Jména a popisy pro výstupní pole XML (pokračování) Jméno výstupního pole ...
Popis Typ monitorované bezpečnostní politiky. Platné hodnoty zahrnují: v ACL v POP v rule (pravidlo) pobj odkazuje na typ bezpečnostní politky používané pro chráněný objekt. Příklady: <policy>traders-popPOP
<descr> ...
Popis bezpečnostní politiky. Toto pole nebude vyplněné, pokud pro danou politiku nebyl vytvořen žádný popis. <policy>traders-aclACL <descr>traders that have ACL security policies
...
Jméno atributu ADI (access decision information) k monitorování. Atribut může zavést prokazatelnost přístupu poskytnutím informací, aby tak pomohl označit možné neoprávněné přístupy přínosů. Vy můžete udělit nebo odmítnout přístup založený na pravidlech platných pro atributy. Pole attribute může obsahovat tato pole: v name (jméno) v source (zdoj) v type (typ) v value (hodnota) Příklad: tagvalue_su-admin <source>cred stringtest_customer_service_rep_1
Kapitola 18. Výstup XML pro protokolování a protokoly monitorování
187
Tabulka 8. Jména a popisy pro výstupní pole XML (pokračování) Jméno výstupního pole ...
Popis Jméno ADI, které chcete monitorovat. Atribut může být pro minotorování buď pověřením uživatele, pokud je pro komponentu authn, nebo app_context, pokud je pro komponentu azn. Jméno atributu autorizace se shoduje se jménem, které jste uvedli v seznamu atributů v objektu stanza [aznapi-configuration] odpovídajícího konfiguračního souboru. Například: [aznapi-configuration] audit-attribute = AZN_CRED_AUTH_METHOD Příklad pole name pro pole attribute: AZN_CRED_AUTH_METHOD <source>credADI stringsu-forms
<source> ...
Událost source může být jedna z následujících: cred
Platná pro libovolnou komponentu Tivoli Access Manager.
app
Platná pouze pro autorizační komponentu (azn).
credADI Platná pouze pro autorizační komponentu (azn) při vyhodnocování pravidla Boolean. appADI Platná pouze pro autorizační komponentu (azn) při vyhodnocování pravidla Boolean. engineADI Platná pouze pro autorizační komponentu (azn) při vyhodnocování pravidla Boolean. dynADI Platná pouze pro autorizační komponentu (azn) při vyhodnocování pravidla Boolean. Pokud má atribut ADI více hodnot, pro každou hodnotu bude zapsaný prvek odlišeného atributu. Příklad: AZN_CRED_AUTH_METHOD <source>credADI stringsu-forms
188
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 8. Jména a popisy pro výstupní pole XML (pokračování) Jméno výstupního pole ...
Popis Typ monitorované bezpečnostní politiky. Platné hodnoty zahrnují: v string (řetězec) v ulong v pobj Je-li pobj, hodnotou bude jméno chráněného objektu. Příklad: AZN_CRED_AUTH_METHOD <source>credADI stringsu-forms
...
Hodnota pro atribut aznAPI. Pokud atribut ADI nemá více hodnot, potom bude pro každou hodnotu zapsán prvek zvláštního atributu. Příklad: AZN_CRED_AUTH_METHOD <source>credADI stringsu-forms
...
Data specifické události. Pole attribute může obsahovat tato pole: v audit Další informace o specifické události jsou zaznamenané v datové oblasti uvolněného formátu na konci záznamu události. Například, Tabulka 10 na stránce 196 poskytuje informace o datech, které jsou navrácené při selhání pokusu o autentizaci. Poznámka: Dekódování významu určitých hodnot dat v záznamu vy mohlo požadovat rozšířené znalosti kódu a architektury Tivoli Access Manager. Argumenty příkazu jsou vypsané v poli data záznamu události ve svém vnitřním formátu. Například: azn_id_get_creds Všimněte si, že příkazy, jejichž výsledkem není efektivní změna stavu databáze (jako např. list a show), nejsou nikdy zachycovány. Příklad 1: <event> ... POST /pkmspasswd.form HTTP/1.1 0 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) https://c03comcrit2.somecompany.com/pkmspasswd Příklad 2: "2019" "1002" "pop1" "0" "" Kapitola 18. Výstup XML pro protokolování a protokoly monitorování
189
Tabulka 8. Jména a popisy pro výstupní pole XML (pokračování) Jméno výstupního pole ...
Popis Začátek a konec monitorované události. Hodnoty platných atributů zahrnují: v Start (Spustit) v Stop (Zastavit) Příklad: <event rev="1.2"> ... . . . <event rev="1.2"> ...
Kódy akcí pro příkazy správy Kód akce identifikuje jeden z příkazů pdadmin produktu Tivoli Access Manager. Tabulka 9 udává referenční číslo kódu akce pro každý příkaz správy. Například kód akce 13702 se vztahuje k příkazu akce POP_MODIFY (příkaz pdadmin pop modify). Argumenty příkazu jsou vypsány ve svém interním formátu v části data prověřovacího záznamu. Všimněte si, že příkazy, jejichž výsledkem není efektivní změna stavu databáze (jako např. list a show), nejsou nikdy zachycovány. Tabulka 9. Příkazy správy ACL Příkazy pro správu ACL
190
ACL_LIST
13000
ACL_GET
13001
ACL_SET_LEGACY
13002
ACL_DELETE
13003
ACL_FIND
13005
ACTION_LIST
13006
ACTION_SET
13007
ACTION_DELETE
13008
ACTION_GROUPLIST
13009
ACTION_GROUPCREATE
13010
ACTION_GROUPDELETE
13011
ACTION_LISTGROUP
13012
ACTION_CREATEGROUP
13013
ACTION_DELETEGROUP
13014
ACL_CREATE
13020
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 9. Příkazy správy ACL (pokračování) ACL_SET
13021
ACL_CREATE_ATTR (neschválený, viz 13134)
13150
Příkazy pro správu objektů OBJ_GET
13100
OBJ_ACL_SET (neschválený)
13101
OBJ_GET_OBJ
13102
OBJSPC_CREATE
13103
OBJSPC_DELETE
13104
OBJSPC_LIST
13105
OBJ_CREATE
13106
OBJ_DELETE
13107
OBJ_MOD_SET_NAME
13110
OBJ_MOD_SET_DESC
13111
OBJ_MOD_SET_TYPE
13112
OBJ_MOD_SET_ISLF
13113
OBJ_MOD_SET_ISPOL
13114
OBJ_MOD_SET_ATTR
13115
OBJ_MOD_DEL_ATTR
13116
OBJ_MOD_DEL_ATTRVAL
13117
OBJ_SHOW_ATTR
13118
OBJ_LIST_ATTR
13119
ACL_ATTACH
13120
ACL_DETACH
13121
ACL_MOD_SET_ATTR
13123
ACL_MOD_DEL_ATTR
13124
ACL_MOD_DEL_ATTRVAL
13125
ACL_SHOW_ATTR
13126
ACL_LIST_ATTR
13127
POP_MOD_SET_ATTR
13128
POP_MOD_DEL_ATTR
13129
POP_MOD_DEL_ATTRVAL
13130
POP_SHOW_ATTR
13131
POP_LIST_ATTR
13132
OBJ_SHOW_ATTRS
13133
ACL_SHOW_ATTRS
13134
POP_SHOW_ATTRS
13135
OBJ_SHOW_V417
13136
OBJ_LIST
13137
OBJ_LISTANDSHOW_V417
13138
OBJ_EXISTS (neschválený)
13139
OBJ_ACCESS_CHECK
13140 Kapitola 18. Výstup XML pro protokolování a protokoly monitorování
191
Tabulka 9. Příkazy správy ACL (pokračování) OBJ_SHOW
13141
OBJ_LISTANDSHOW
13142
ACL_CREATE_ATTR (neschválený, viz 13134)
13150
Příkazy pro správu serveru
192
SERVER_GET
13200
SERVER_RESTORE
13201
SERVER_DELETE (neschválený)
13202
SERVER_LIST
13203
SERVER_PERFORMTASK
13204
SERVER_GETTASKLIST
13205
SERVER_REPLICATE
13206
SERVER_ACTION
13207
SERVER_STATUS_GET
13208
SERVER_ENABLE (neschválený)
13209
SERVER_DISABLE (neschválený)
13210
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 9. Příkazy správy ACL (pokračování) Příkazy pro správu administrativy, uživatelů a skupin ADMIN_SHOWCONF
13400
USER_CREATE
13401
USER_IMPORT
13402
USER_MODDESC
13403
USER_MODPWD
13404
USER_MODAUTHMECH
13405
USER_MODACCVALID
13406
USER_MODPWDVALID
13407
USER_DELETE
13408
USER_SHOWGROUPS
13409
USER_SHOW
13410
USER_SHOWDN
13411
USER_LIST
13412
USER_LISTDN
13413
GROUP_CREATE
13414
GROUP_IMPORT
13415
GROUP_MODDESC
13416
GROUP_MODADD
13417
GROUP_MODREMOVE
13418
GROUP_DELETE
13419
GROUP_SHOW
13420
GROUP_SHOWDN
13421
GROUP_LIST
13422
GROUP_LISTDN
13423
GROUP_SHOWMEMB
13424
USER_MODGSOUSER
13425
USER_SET (neschválený)
13426
GROUP_SET (neschválený)
13427
GROUP_MODADD2
13428 Zdrojové příkazy GSO
GSO_RESOURCE_CREATE
13500
GSO_RESOURCE_DELETE
13501
GSO_RESOURCE_LIST
13502
GSO_RESOURCE_SHOW
13503 Příkazy pro pověření zdroje GSO
GSO_RESOURCE_CRED_CREATE
13504
GSO_RESOURCE_CRED_DELETE
13505
GSO_RESOURCE_CRED_MODIFY
13506
GSO_RESOURCE_CRED_LIST
13507
GSO_RESOURCE_CRED_SHOW
13508
Kapitola 18. Výstup XML pro protokolování a protokoly monitorování
193
Tabulka 9. Příkazy správy ACL (pokračování) Příkazy pro skupinu zdrojů GSO GSO_RESOURCE_GROUP_CREATE
13509
GSO_RESOURCE_GROUP_DELETE
13510
GSO_RESOURCE_GROUP_ADD
13511
GSO_RESOURCE_GROUP_REMOVE
13512
GSO_RESOURCE_GROUP_LIST
13513
GSO_RESOURCE_GROUP_SHOW
13514 Příkazy politiky
194
POLICY_SET_MAX_LOGIN_FAILURES
13600
POLICY_GET_MAX_LOGIN_FAILURES
13601
POLICY_SET_DISABLE_TIME_INTERVAL
13602
POLICY_GET_DISABLE_TIME_INTERVAL
13603
POLICY_SET_MAX_ACCOUNT_AGE
13604
POLICY_GET_MAX_ACCOUNT_AGE
13605
POLICY_SET_ACCOUNT_EXPIRY_DATE
13606
POLICY_GET_ACCOUNT_EXPIRY_DATE
13607
POLICY_SET_MAX_INACTIVITY_TIME
13608
POLICY_GET_MAX_INACTIVITY_TIME
13609
POLICY_GET_ACCOUNT_CREATION_DATE
13610
POLICY_GET_LAST_LOGIN_ATTEMPT_DATE
13611
POLICY_SET_MAX_PASSWORD_AGE
13612
POLICY_GET_MAX_PASSWORD_AGE
13613
POLICY_SET_MIN_PASSWORD_AGE
13614
POLICY_GET_MIN_PASSWORD_AGE
13615
POLICY_SET_MAX_PASSWORD_REPEATED_CHARS
13616
POLICY_GET_MAX_PASSWORD_REPEATED_CHARS
13617
POLICY_SET_MIN_PASSWORD_ALPHAS
13618
POLICY_GET_MIN_PASSWORD_ALPHAS
13619
POLICY_SET_MIN_PASSWORD_NON_ALPHAS
13620
POLICY_GET_MIN_PASSWORD_NON_ALPHAS
13621
POLICY_SET_MIN_PASSWORD_DIFFERENT_CHARS
13622
POLICY_GET_MIN_PASSWORD_DIFFERENT_CHARS
13623
POLICY_SET_PASSWORD_SPACES
13624
POLICY_GET_PASSWORD_SPACES
13625
POLICY_SET_MIN_PASSWORD_LENGTH
13626
POLICY_GET_MIN_PASSWORD_LENGTH
13627
POLICY_SET_MIN_PASSWORD_REUSE_TIME
13628
POLICY_GET_MIN_PASSWORD_REUSE_TIME
13629
POLICY_GET_PASSWORD_FAILURES
13630
POLICY_GET_LAST_PASSWORD_CHANGE_DATE
13631
POLICY_SET_NUMBER_WARN_DAYS
13632
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 9. Příkazy správy ACL (pokračování) POLICY_GET_NUMBER_WARN_DAYS
13633
POLICY_SET_PASSWORD_REUSE_NUM
13634
POLICY_GET_PASSWORD_REUSE_NUM
13635
POLICY_SET_TOD_ACCESS
13636
POLICY_GET_TOD_ACCESS
13637
POLICY_GET_ALL_POLICY
13638 Příkazy politiky POP
POP_CREATE
13700
POP_DELETE
13701
POP_MODIFY
13702
POP_SHOW
13703
POP_LIST
13704
POP_ATTACH
13705
POP_DETACH
13706
POP_FIND
13707 Příkazy konfigurace
CFG_CONFIG
13800
CFG_UNCONFIG
13801
CFG_RENEWCERT
13802
CFG_SETPORT
13803
CFG_SETLISTENING
13804
CFG_SETKEYRINGPWD
13805
CFG_SETSSLTIMEOUT
13806
CFG_SETAPPLCERT
13807
CFG_ADDREPLICA
13808
CFG_CHGREPLICA
13809
CFG_RMVREPLICA
13810
CFG_GETVALUE
13811
CFG_SETVALUE
13812
CFG_RMVVALUE
13813
CFG_SETSVRPWD
13814 Příkazy domén
DOMAIN_CREATE
13900
DOMAIN_DELETE
13901
DOMAIN_MODIFY_DESC
13902
DOMAIN_SHOW
13903
DOMAIN_LIST
13904
Kapitola 18. Výstup XML pro protokolování a protokoly monitorování
195
Tabulka 9. Příkazy správy ACL (pokračování) Příkazy pravidel AUTHZRULE_CREATE
13950
AUTHZRULE_DELETE
13951
AUTHZRULE_MODIFYTEXT
13952
AUTHZRULE_MODIFYREASON
13953
UTHZRULE_MODIFYDESC
13954
AUTHZRULE_SHOW
13955
AUTHZRULE_LIST
13956
AUTHZRULE_ATTACH
13957
AUTHZRULE_DETACH
13958
AUTHZRULE_FIND
13959
AUTHZRULE_MOD_SET_ATTR
13960
AUTHZRULE_MOD_DEL_ATTR
13961
AUTHZRULE_MOD_DEL_ATTRVAL
13962
AUTHZRULE_SHOW_ATTRS
13963
AUTHZRULE_SHOW_ATTR
13964
AUTHZRULE_LIST_ATTR
13965
Výstup dat pro chyby autentizace Tabulka Tabulka 10 vypisuje kódy chyb autentizace a struktury prvků výstupních polí , které jsou navrácené při selhání pokusu o autentizaci: Tabulka 10. Chyby autentizace Typ chyby
196
Chybový kód (hexadecimálně)
Chybový kód (desítkově)
Generováno XML
Selhání hesla
132120c8
320938184
Password failure: user
Účet uzamčen
13212132
320938290
Account lock-out: user
Obecné selhání
Vše ostatní
Vše ostatní
<username>user
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 19. Zachycení protokolovaných a monitorovaných událostí Produkt Tivoli Access Manager poskytuje dvě metody zachycení monitorovaných událostí. Jedna metoda je použitá pro zachycení monitorovaných událostí pro aktuální verzi produktu Tivoli Access Manager a druhá metoda je použitá pro zachycení monitorovaných událostí pro účely přejímání. Použijte tuto metodu pro zachycení monitorovaných událostí pro aktuální verzi produktu Tivoli Access Manager. Pro monitorování a jiné účely obslužnosti kromě některých zpráv, které jsou vytvářené při spouštění programu, jsou všechny zprávy generované produktem Tivoli Access Manager vytvářené ve strukturované hierarchii událostí produktu Tivoli Access Manager. Kategorizace událostí po pořádku v této hierarchii umožňuje provádět běhové sdružování mezi třídami událostí a agenty protokolů, kteří mají být použiti pro zaznamenání těchto událostí. Tato kapitola popisuje konfigurační záznamy objektů stanza pro každý typ agentů protokolů. Tato kapitola obsahuje následující části: v “Agenti protokolů” v “Kategorie událostí” v “Konfigurační parametry pro společné oblasti událostí” na stránce 200 v “Úlohy protokolování událostí” na stránce 213
Agenti protokolů Při protokolování události koncept agenti protokolů zahrnuje zachycení událostí, které jsou přesměrované do míst určení jiných, než je lokální systém souborů. Protokolování událostí používá tyto typy agentů protokolů, z nichž každý představuje místo určení pro záznam události: v Agent protokolu konzole v Agent protokolu souboru v Agent protokolu propojení procesů v Vzdálený agent protokolů
Kategorie událostí Hierarchie událostí se dynamicky vytváří během provádění programu. Zatímco lze očekávat, že některé dobře známé kategorie událostí budou předložené během spuštění programu produktu Tivoli Access Manager, jiné kategorie mohou být specifické pro programy a některé mohou být přechodné.
Kategorie události specifická pro program Určitá kategorie událostí je určena seznamem jmen oddělených tečkami. První úroveň jména v rámci kategorie má speciální význam. Toto jméno kategorie nejvyšší úrovně by také mohlo odpovídat událostem, které se předtím vztahovaly k přejatým souborům protokolů produktu Tivoli Access Manager, které popisuje “Přehled monitorování” na stránce 221. Předpokládejme například, že jméno kategorie událostí bylo vytvořeno následovně: kategorie_domény.pod_kategorie.pod_kategorie...pod_kategorie
Poznámka k implementaci: Je efektivnější, není-li událost vytvořena, pokud nejsou zapsáni žádní agenti protokolu, kteří by zaznamenávali události dané kategorie. V případě, že je vygenerována událost, ale není zapsán žádný agent protokolu, aby ji zaznamenal, pak je tato událost vyřazena.
Hierarchie společné oblasti události Tato sekce protokolování události popisuje, jak můžete přidružovat agenty protokolů k bodu v hierarchii společné oblasti události, abyste mohli vytvářet záznamy událostí. Například: [aznapi-configuration] logcfg = EventPool:file queue_size=číslo, hi_water=číslo,flush_interval=počet_vteřin
Popis charakteristik všech možných událostí v hierarchii zde ale není poskytnut. Popis dobře známých událostí, jako např. těch, které se generují pro monitorování, najdete v odpovídající dokumentaci specifické pro daný produkt. Obecně se dá říci, že hierarchie událostí se podobá tomuto zobrazení:
198
IBM Tivoli Access Manager: Base: Administrativní příručka
Obrázek 29. Hierarchie událostí
Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
199
Konfigurační parametry pro společné oblasti událostí Navíc ke zpětně kompatibilní metodě přejímání monitorovaných událostí a událostí odesílání do souborů protokolů monitorování (záznam objektu stanza auditcfg =) můžete konfigurovat zachycení událostí produktu Tivoli Access Manager pomocí záznamu objektu stanza logcfg = . Abyste konfigurovali zachycení událostí produktu Tivoli Access Manager, můžete uvést odpovídající záznamy objektů stanza v objektu stanza [aznapi-configuration] konfiguračního souboru serveru (jméno_serveru.conf). Pro uvedení protokolování události použijte parametr logcfg. Parametry a hodnoty se liší v závislosti na kategorii, místě určení událostí a typu protokolování událostí, které si přejete provést. Obecný formát záznamu (zadaný na řádku), který je potřebný pro protokolování událostí do agentů protokolů je: [aznapi-configuration] logcfg = kategorie:{stdout|stderr|file|pipe|remote} [[parametr[=hodnota]] [parametr[=hodnota]]]
Chcete-li aktivovat zaznamenávání událostí produktu Tivoli Access Manager pomocí rozhraní, musíte přiřadit cíl protokolování ke kategorii událostí ve zdroji událostí. V současné době jsou podporovány čtyři typy cílů, určených k zachycování událostí: v agent protokolu konzole (stdout|stderr), v agent protokolu typu soubor, v agent protokolu typu propojení procesů, v vzdálený agent protokolu. Podrobnější příklady parametru logcfg najdete v některém z následujících cílů protokolování událostí: Parametry těchto typů agentů protokolu je možné uvést v libovolném pořadí a jsou obvykle volitelné. Platné parametry pro každý typ agenta protokolu jsou popsány dále. V záznamu konfigurace jsou názvy parametrů citlivé na velikost písmen a je možné je zkrátit na libovolnou zkrácenou délku plného jména parametru, ale tato zkratka musí zůstat jedinečná. Jméno kategorie může ukazovat na libovolný uzel v hierarchii zdroje událostí. Zvažte například následující zjednodušený tvar: [aznapi-configuration] logcfg = kategorie:agent-protokolu
Zachycování událostí pro danou kategorii zahrnuje všechny podkomponenty v hierarchii. To znamená, že pro kategorii foo.bar bude také zachycována událost foo.bar.fred. Ke stejné kategorii můžete připojit více agentů protokolu. Následující konfigurace například okopíruje události monitorování autorizace do souboru a předá je programu, očekávajícímu vstupy na začátku propojení procesů: [aznapi-configuration] logcfg = audit.azn:file path=/var/PolicyDirector/log/audit.azn logcfg = audit.azn:pipe path=/bin/analyse.exe
Níže uvedený diagram znázorňuje vztahy mezi kroky v procesu protokolování. Horní třetina diagramu představuje kód serveru produktu Tivoli Access Manager. Programátor přidal do kódu testovací body a v těchto bodech se mohou generovat události určitých typů.
200
IBM Tivoli Access Manager: Base: Administrativní příručka
Vygenerované události jsou následně předány do zdroje událostí serveru, kde je možné je zaznamenat prostřednictvím bodu zachycení (sink), který definuje kategorii událostí. Během zpracování programu může uživatel zapsat agenta protokolu k libovolnému bodu v hierarchii zdroje událostí, aby výběrově zaznamenával události, generované v testovacích bodech programu. To je zobrazeno ve střední části diagramu. Jedním agentem protokolu, kterého můžete zapsat, aby zachycoval události, je vzdálený klient protokolu. Tento klient postupuje vybrané události vzdálenému serveru pdacld. Spodní část diagramu zobrazuje tento vzdálený server. Všimněte si, že spodní část s v podstatě stejná jako horní část s předanými událostmi umístěnými ve společné oblasti událostí ve vzdálených bodech sondy pdacld.
Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
201
Obrázek 30. Body sondy specifické pro aplikaci
202
IBM Tivoli Access Manager: Base: Administrativní příručka
Společná oblast událostí Události se předávají zapsaným agentům protokolu asynchronně vzhledem k požadavkům aplikací, které vytvářejí zaznamenávané události. Události nejprve projdou přes společnou frontu propagace, a pak jsou odeslány na různé zapsané agenty protokolu. Obsluhující profil této fronty propagace je možné nakonfigurovat. Chcete-li konfigurovat frontu propagace, musíte uvést zkrácený formát záznamu objektu stanza logcfg. Zkrácený záznam konfigurace používá EventPool pro jméno kategorie a určuje volby ukládání do paměti bez uvedení typu místa určení protokolu. Měli byste spravovat frontu propagace, abyste byli schopní podporovat konfiguraci agentů protokolů. Například, když omezíte množství paměti použité pro umístění žádostí protokolů do fronty pro vzdáleného agenta protokolu, měli byste také omezit queue_size (velikost_fronty) propagace události: [aznapi-configuration ] logcfg = EventPool:file queue_size=číslo,hi_water=číslo, flush_interval=počet_vteři logcfg = EventPool:remote buffer_size=číslo,path=jméno_cesty, server=jméno_hostitele,queue_size=číslo
queue_size Proto, abyste mohli řídit množství paměti, které je možné spotřebovat pro události ve frontě propagace, musíte nastavit omezení maximální velikosti, po kterou tato fronta může růst. Když fronta dosáhne své maximální velikosti a je vygenerována nová událost, pak vlákno, které se pokusilo zařadit do fronty, je zablokováno, dokud ve frontě není zase volné místo. Následkem je snížení výkonnosti vlákna produkujícího událost na rychlost vláken protokolování, pokud tato nemůže být zvýšena. Tento příklad zobrazuje, jak uvést maximální počet událostí, které mají být zařazené do fronty v paměti: [aznapi-configuration] logcfg = EventPool:queue_size=číslo, hi_water=číslo,flush_interval=počet_vteřin
Předvolená hodnota pro velikost fronty je 0. Velikost fronty nula označuje, že není nastavený žádný limit pro růst fronty událostí. Pamatujte si, že používání předvolené hodnoty může způsobit, že fronta nezpracovaných událostí poroste na nekontrolovatelnou velikost, pokud budou události produkovány rychleji, než je budou moci zapsaní agenti protokolu mazat.
hi-water Zpracování fronty událostí je naplánováno tak, aby se provádělo pravidelně v nakonfigurovaných intervalech zarovnání. Toto zpracování je také spouštěno asynchronně tehdy, když velikost fronty dosáhne své horní hranice. Tento příklad zobrazuje, jak uvést vysoké hladiny fronty událostí: [aznapi-configuration] logcfg = EventPool:queue_size=číslo, hi_water=číslo,flush_interval=počet_vteřin
Předvolená hodnota pro označení výšky hladiny je 1024. Pokud uvedete hodnotu pro queue_size, ale ne hodnotu pro hi_water, předvolená hodnota pro označení výšky hladiny bude vypočítaná jako dvě třetiny z maximální konfigurované velikosti fronty.
Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
203
Například, pokud je maximální velikost fronty 0, označení výšky hladiny bude nastaveno na předvolbu 100. Je-li označení výšky hladiny front událostí nastaveno na 1, každá událost ve frontě bude předaná do libovolného zapsaného agenta protokolu, jak jen to bude možné. Všimněte si, že nastavení spodní hodnoty označení výšky hladiny může mít nepříznivý vliv na celkový výkon. Pro více informací viz publikace IBM Tivoli Access Manager for e-business Performance Tuning Guide.
flush_interval Interval zarovnání použijte pro uvedení limitu času, po který událost čeká ve frontě propagace, než je postoupená agentu protokolu. Pokud jsou události generovány tak pomalu, že se včas nespouští ovládání pomocí horní hranice fronty událostí, pak jsou události předávány z fronty propagace s touto četností. Tento příklad zobrazuje jak nastavit frekvenci pro zarovnávání vyrovnávacích pamětí souborů protokolu: [aznapi-configuration] logcfg = EventPool:queue_size=číslo,hi_water=číslo, flush_interval=počet_vteřin
Předvolená hodnota pro interval zarovnání je 10 vteřin. Hodnota 0 parametru četnosti zarovnávání není dovolena. Pokud přesto uvedete hodnotu 0, pak fronta bude zarovnána každých 600 vteřin.
Konfigurační parametry pro agenta protokolu konzole Protokolování do konzole je jednodušší volba protokolování událostí, které mají být konfigurované. Jednoduše přidružte místo určení výstupu standardního výstupu (stdout) nebo standardní chyby (stderr) ke kategorii událostí ve společné oblasti událostí pro zachycování: [aznapi-configuration] logcfg = kategorie:{stdout|stderr}
Protokolování na konzoli samo o sobě nepoužívá žádné řazení do front. Události jsou zapisovány na konzole, jakmile jsou obdrženy z fronty propagace. Všimněte si však, že události mohou mít zpoždění ve frontě propagace, které je závislé na nastavení této fronty. Pokud používáte výstup na konzoli a server je spuštěn na popředí, abyste mohli provádět jeho ladění, můžete požadovat nastavení fronty propagace podle tohoto nastavení. Nastavte například parametr hi_water na nižší hodnotu. Následuje příklad konfigurací stdout a stderr.
stdout Abyste zachytili všechny monitorované výstupy do stdout, uveďte následující záznamy objektů stanza v konfiguračním souboru: [aznapi-configuration] logcfg = kategorie:stdout
stderr Abyste zachytili pouze autorizační (azn) monitorované události do stderr, uveďte následující záznam objektu stanza v konfiguračním souboru: [aznapi-configuration] logcfg = kategorie:stderr
204
IBM Tivoli Access Manager: Base: Administrativní příručka
Konfigurační parametry pro agenta protokolu souboru Chcete-li zaznamenávat události do souboru, uveďte konfiguraci souboru protokolu: [aznapi-configuration] logcfg = kategorie:soubor path=jméno_cesty_souboru, flush_interval=počet_vteřin, rollover_size=číslo,log_id=id_protokolu,queue_size=číslo,hi_water=číslo, buffer_size=číslo,mode={text|binary}
Jména argumentů mohou být zkrácená na jednoznačný prefix plného jména. Například, argument hi_water= lze zkrátit na hi=. Soubor je otevřen pouze jednou. Pokud je zadáno více záznamů konfigurace, aby bylo možné selektivně zachycovat události na různých bodech v hierarchii zdroje událostí do stejného souboru, soubor se otevře v souladu s parametry, které byly nalezeny při prvním zpracování konfiguračního záznamu. Jakmile byl soubor otevřen, další konfigurace souboru mohou jednoduše používat následující zkrácený zápis zaznamenávání událostí do stejného souboru: [aznapi-configuration] logcfg = kategorie:file log_id=logid
Jelikož zapisování do souboru může být výrazně pomalejší operací v porovnání s úlohami generujícími události, jsou události předávány do agenta protokolu pro soubor prostřednictvím další úrovně front. Tato druhá úroveň zařazování událostí do front je nakonfigurována podobně jako centrální fronta propagace událostí, ale má jiné předvolené hodnoty.
path Parametr path uvádí jméno a umístění souboru protokolu. Předvolená hodnota pro cestu k souboru neexistuje, protože hodnota parametru log_id má přednost. Příkladem hodnoty parametru path pro soubor prověřovacích záznamů serveru WebSEAL na operačním systému UNIX je: [aznapi-configuration] logcfg = kategorie:file path=/var/pdweb/log/audit.log
Část adresáře tohoto jména cesty musí existovat. Soubor protokolu se vytvoří, pokud dosud neexistuje.
logcfg Otevřený soubor protokolu je přidružen k identifikátoru zkráceného jména, aby bylo možné usnadnit zaznamenávání událostí z jiných kategorií do stejného souboru. Chcete-li nastavit ID souboru protokolu explicitně, použijte parametr log_id. Pokud tento parametr nezadáte, bude mu přidělena předvolená hodnota.Je-li volba path= uvedená, předvolená hodnota je konfigurované jméno cesty. Není-li hodnota path= uvedená, ID protokolu se předvolí na komponentu domény právě zachycené kategorie události. Například: logcfg = audit.azn:file
znamená log_id=audit
Chcete-li zachycovat události do společného souboru, nastavte ID souboru protokolu na vhodnou hodnotu v konfiguračním souboru se všemi parametry. Dále použijte variantu zkrácené konfigurace, abyste zachycovali události z dalších kategorií: Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
Protože platí pravidla pro předvolby, tato konfigurace je také ekvivalentní následující specifikaci: [aznapi-configuration] logcfg = audit.azn:file path=/opt/PolicyDirector/log/audit.log, rollover_size=-1, ... logcfg = audit.authn:file
Pokud vytvoříte obrazec konfigurace, kde hodnota ID protokolu se neshoduje s žádným otevřeným souborem protokolu, nejsou zachycené žádné události. Například níže uvedená konfigurace nebude zaznamenávat žádné události, protože konfigurační řádek, který označuje jméno souboru protokolu, byl opatřen komentářem: [aznapi-configuration] #logcfg = audit.azn:file path=/tmp/azn.log,log_id=azn, ... logcfg = audit.authn:file log_id=authn
rollover_size Chcete-li zadat maximální velikost, po kterou soubor protokolu může růst, použijte parametr rollover_size.Tento parametr má následující předvolenou hodnotu (v bajtech). [aznapi-configuration] logcfg = audit.azn:file... rollover_size=2000000...
Když velikost souboru 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 časovou značkou. Pak se spustí protokolování do nového souboru protokolu. Různé možné hodnoty velikosti obnovy jsou vykládané následujícím způsobem: v Je-li hodnota velikosti obnovy menší než nula (< 0), vytvoří se nový soubor protokolu s každým vyvoláním procesu a dále co 24 hodin od tohoto okamžiku. v Je-li hodnota velikosti obnovy rovna nule (= 0), nejsou provedené žádné obnovy a soubor protokolu nekonečně narůstá. Pokud soubor protokolu již existuje, budou nová data k němu připojena. v Je-li hodnota velikosti obnovy větší než nula (> 0), obnova je provedená, dosáhne-li soubor protokolu konfigurovanou prahovou hodnotu. Pokud soubor protokolu při spuštění již existuje, budou nová data k němu připojena.
buffer_size Chcete-li snížit fragmentaci paměti a zlepšit výkonnost zapisování do souboru, pak spíše než abyste zařazovali do fronty agenta protokolu mnoho malých událostí samostatně, ukládejte tyto události do vyrovnávací paměti do bloků o určité velikosti a teprve poté tyto větší bloky událostí zapisujte do souboru. Parametr buffer_size určuje maximální velikost zprávy, kterou se program pokusí vytvořit kombinací menších událostí ve velké vyrovnávací paměti.
206
IBM Tivoli Access Manager: Base: Administrativní příručka
Vyrovnávací paměti se skládají z celého počtu událostí. Události nelze rozdělit mezi jednotlivými vyrovnávacími paměťmi. Pokud další událost přesáhne nakonfigurovanou maximální velikost, pak je velká událost zaznamenána do vyrovnávací paměti samostatně, přestože přesáhne nakonfigurovanou hodnotu. [aznapi-configuration] logcfg = audit.azn:file... buffer_size={0|číslo} ...
Předvolená velikost vyrovnávací paměti pro protokolování do souboru je nastavena na hodnotu 0 bajtů. Tato hodnota brání ukládání do vyrovnávacích pamětí a každá událost je zpracovávána samostatně. Je-li zadána hodnota parametru buffer_size, pak jsou události ukládány do vyrovnávacích pamětí o uvedené velikosti, a teprve poté jsou předávány agentu protokolu pro soubor. Například, je-li hodnota buffer_size nastavená na 2 KB , předpokládá se, že události jsou velké asi 256 bajtů, do každé vyrovnávací paměti zapsané do souboru je napakováno asi deset událostí. Toto omezuje počet vstupů/výstupů (I/O) do disku, které jsou provedené během protokolování na 10 procent ekvivalentního případu bez vyrovnávací paměti. Všimněte si, že předvolená velikost fronty 200 s buffer_size nastavenou na 2 KB také spotřebuje asi desetkrát víc paměti předvolené konfigurace, které neměla zahrnutou vyrovnávací paměť (za předpokladu, že velikost události je okolo 200 bajtů). To je výsledkem toho, že hodnota maximální velikosti fronty nebyla změněna, ale velikost událostí, které se zapisují, byla zvýšena 10krát.
queue_size Mezi událostmi, které byly umístěny do fronty, a agentem protokolu pro soubor, který je z této fronty odstraňuje, existuje určitá prodleva. Parametr queue_size určuje maximální velikost, po kterou je frontě dovoleno růst.Když fronta dosáhne své maximální velikosti a je připravena nová událost pro umístění do fronty, pak požadující vlákno je zablokováno, dokud není ve frontě zase volné místo. To má vliv na snížení výkonnosti vlákna produkujícího událost na rychlost vláken protokolování do souboru, pokud tato nemůže být zvýšena. Omezení velikosti fronty pro agenta protokolu by mělo být konfigurované ve spojení s nastavením velikosti fronty pro centrální fronty propagace událostí. Není-li queue_size propagace událostí správně vymezená, spotřeba paměti může stále růst bez omezení. [aznapi-configuration] logcfg = audit.azn:file... queue_size=počet_událostí, ...
Předvolená hodnota pro queue_size je 0. Velikost fronty nula znamená, že pro růst fronty nezpracovaných událostní není vymezen žádný limit. Současně vlákno propagující událost není omezováno rychlostí vlákna protokolování. Pamatujte si, že používání předvoleb může vést k neočekávanému růstu fronty událostí na nekontrolovatelnou velikost, pokud budou události generovány rychleji, než je bude možné zapisovat do souboru.
hi_water Zpracování fronty událostí je naplánováno tak, aby se provádělo pravidelně v nakonfigurovaných intervalech zarovnání. Toto zpracování je také spouštěno asynchronně tehdy, když velikost fronty dosáhne své horní hranice.
Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
Předvolená hodnota parametru hi_water jsou dvě třetiny nakonfigurované maximální velikosti fronty.Je-li maximální velikost fronty nula, pak je hodnota horní hranice fronty nastavena standardně na hodnotu 100. Přenosové rychlosti a hodnoty těchto parametrů určují maximální množství paměti, které bude spotřebováno, pokud aktivujete protokolování událostí do souboru. Je-li hodnota horní hranice fronty událostí nastavena na hodnotu 1, pak je každá událost zařazená do fronty předána agentu protokolu co nejdříve. Toto nastavení není optimální. Přesto se může stát, že je budete chtít použít, a to v případě, kdy budete chtít zajistit, že události budou zapsány na disk co nejrychleji i za cenu snížení celkové výkonnosti.
flush_interval Volba flush_interval je volba s vícenásobným využitím. Parametr flush_interval protokolování do souboru má následující předvolenou hodnotu (v bajtech): [aznapi-configuration] logcfg = audit.azn:file... flush_interval={0|< 0|počet_vteřin}, ...
Soubory protokolu se zapisují do toků dat, které využívají vyrovnávací paměť. Abyste zajistili, že proudové vyrovnávací paměti jsou pravidelně zarovnané do disku, frekvence, se kterou si server asynchronně vynutí zarovnání proudu souborů na disk, je konfigurovatelná s použitím volby intervalu zarovnání. Hodnota 0 parametru četnosti zarovnávání není dovolena. Pokud uvedete hodnotu 0, výsledkem bude použití hodnoty 600 vteřin. Uvedete-li zápornou hodnotu (< 0), absolutní hodnota bude použitá jako asynchronní frekvence vyrovnání, ale zarovnání proudů je vynucené také synchronně po zápisu každého záznamu. Pokud jsou události stlačované do velkých vyrovnávacích pamětí uvedením hodnoty pro volbu buffer_size, volba flush_interval by mohla ovlivnit také velikost zapsané vyrovnávací paměti. Je-li v paměti částečně zaplněná vyrovnávací paměť v době, kdy je naplánováno zarovnání, pak bude tato vyrovnávací paměť zařazena do fronty pro zápis, přestože není dosud zcela zaplněna. Fronta událostí je spuštěná pro zpracování přenosové rychlosti intervalu zarovnání. To brání tomu, aby události čekaly na zpracování maximálně po naplánovanou dobu zarovnání, pokud nelze dosáhnout horní hranice fronty mezi dvěma naplánovanými zarovnáními.
208
IBM Tivoli Access Manager: Base: Administrativní příručka
mode Parametr mode použijte k otevření souboru v textovém, nebo binárním režimu. Například: [aznapi-configuration] logcfg = audit.azn:file... mode={text|binary}, ...
Textový režim není schválen na platformách operačního systému UNIX a nemá žádný význam. Na 32–bitových platformách Microsoft Windows umožní otevření souboru v textovém režimu překlady znaků konců řádků v souboru protokolů. Binární režim na platformě Windows zapisuje soubor protokolu ve formátu kompatibilním s operačním systémem Unix.
Konfigurační parametry pro agenty protokolu propojení procesů Chcete-li zapsat výstup do standardního vstupu dalšího programu, použijte parametr pipe. Například: [aznapi-configuration] logcfg = kategorie:pipe path=jméno_cesty_programu, \ queue_size=číslo, \ hi_water=číslo, \ flush_interval=počet_vteřin
Jména argumentů lze zkrátit na libovolné jednoznačné prefixy plného jména. Například, argument hi_water= lze zkrátit na hi=. Jmenovaný program musí existovat a být spustitelný. Administrátor je odpovědný za to, že zajistí zabezpečení programu, který má být spuštěn. Každý výskyt agenta propojení procesů v konfiguračním souboru vyvolá novou kopii programu propojení procesů. Na rozdíl od protokolování do souboru nejsou události posílané na propojení procesů kombinovány z různých zachycovacích bodů kategorií do jediné kopie programu.
path Chcete-li zadat umístění programu, který získá výstup protokolu na svém standardním vstupu, použijte parametr path. Například: [aznapi-configuration] logcfg = kategorie:pipe path=/opt/risk_analyser/bin/my_log_watcher
Všimněte si, že pro cestu k souboru neexistuje žádná předvolená hodnota.
queue_size Správu fronty událostí pro protokolování do propojení procesů nakonfigurujte stejným způsobem, jako jste konfigurovali protokolování do souboru. Volba queue_size má stejný význam pro volbu popsanou pro protokolování události. queue_size={0|počet_událostí}
Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
209
hi_water Správu fronty událostí pro protokolování do propojení procesů nakonfigurujte stejným způsobem, jako jste konfigurovali protokolování do souboru. Volba hi_water má stejný význam pro volbu popsanou pro protokolování události. hi_water={0|1|číslo}
flush_interval Správu fronty událostí pro protokolování do propojení procesů nakonfigurujte stejným způsobem, jako jste konfigurovali protokolování do souboru. Volba flush_interval má stejný význam pro volbu popsanou pro protokolování události. flush_interval={0|<0|počet_vteřin}
Konfigurační parametry pro vzdáleného agenta protokolu Chcete-li odesílat události na vzdálený server, kde se budou zaznamenávat, použijte parametr remote. Například: [aznapi-configuration] logcfg = kategorie:remote buffer_size=velikost, compress={yes|no},error_retry=časový_limit,path=jméno, flush_interval=počet_vteřin,rebind_retry=časový_limit, server=jméno_hostitele,port=číslo,dn=id, queue_size=číslo,hi_water=číslo
Jména argumentů lze zkrátit na libovolné jednoznačné prefixy plného jména. Například, argument hi_water= lze zkrátit na hi=. Požadavky na to, aby se událost protokolovala vzdáleně, jsou přijímány pouze na základě nejlepšího pokusu. Pokud není vzdálený server dostupný, zachycované události jsou lokálně ukládány do paměti cache a budou předány později, až bude vzdálený server opět dostupný. Ke vzdálenému serveru je zavedeno pouze jedno připojení pro vzdálené protokolování. Pokud je provedeno více záznamů konfigurace, aby bylo možné selektivně zachycovat události na různých místech hierarchie zdroje událostí na jeden vzdálený server, pak se vzdálené spojení nastaví podle parametrů prvního záznamu konfigurace pro vzdálené protokolování. Více vzdálených připojení je možné nakonfigurovat, pokud chcete protokolovat na různé vzdálené servery. Události, které byly přijaty vzdáleným serverem, jsou uloženy do zdroje událostí tohoto serveru, a to do odlišného místa od toho, kde byly původně zachyceny klientským systémem. Všechny události vstupují na hostitele prostřednictvím služby vzdáleného protokolování a jsou uloženy do kategorie vytvořené následujícím způsobem: remote.doména_kategorie_klienta.jméno_hostitele.program
Vnitřní kód protokolování na klientovi vždy poskytuje jméno hostitele prostřednictvím systémového volání gethostname(). Přijímající hostitel může vždy rozlišit jméno hostitele odesílatele, protože na klientovi je systémové volání gethostname() vždy k dispozici. Proto nejsou žádné speciální požadavky na rozlišení síťového jména hostitele. Toto volání vrátí interní jméno hostitele lokálního hostitele — a to vždy ve tvaru krátkého jména. Například všechny monitorované události protokolované vzdáleně z programu pdmgrd na hostiteli amazon se objeví na vzdáleném protokolovacím serveru ve zdroji událostí remote.audit.amazon.pdmgrd.To, že se vše objevuje v jednom zdroji událostí umožňuje vzdálenému serveru, aby selektivně zaznamenával události z množství cílů pomocí standardních konfigurací. Všechny monitorované události z hostitele amazon mohou být centrálně zaznamenány na hostiteli timelord pomocí konfigurace podobné té níže uvedené.
210
IBM Tivoli Access Manager: Base: Administrativní příručka
Na hostiteli amazon, který vzdáleně předává události, můžete použít následující příklad: [aznapi-configuration] logcfg = audit:remote buffer=2000,compress=y,error=2, \ path=/opt/PolicyDirector/log/remote.cache,rebind=600,server=timelord,port=7136
Na hostiteli timelord, který zaznamenává události do souboru, můžete použít: [aznapi-configuration] logcfg = remote.audit:file path=consolidated_audit.log logcfg = remote.audit.amazon.pdmgrd:file path=amazon_pdmgrd_audit.log
buffer_size Z důvodu snížení provozu po síti jsou události ukládány do vyrovnávacích pamětí v blocích o nominované velikosti, než jsou předány vzdálenému serveru. Parametr buffer_size určuje maximální velikost zprávy, kterou se pokusí lokální program vytvořit pomocí kombinace menších událostí do jedné velké vyrovnávací paměti.Vyrovnávací paměti se skládají pouze z celých událostí. Události nelze rozdělit mezi více vyrovnávacích pamětí. Pokud jakákoliv událost přesáhne nakonfigurovanou maximální velikost, pak je tato velká událost odeslána ve své vlastní vyrovnávací paměti, protože přesahuje nakonfigurovanou hodnotu. buffer_size=počet_bajtů
Předvolená hodnota velikosti vyrovnávací paměti je 1024 bajtů.
flush_interval Pokud jsou události slučovány do velmi velkých vyrovnávacích pamětí a pokud aktivita protokolování není příliš vysoká, je možné, že události budou zůstávat v paměti po dlouhou dobu, než budou předány vzdálenému serveru nebo budou zapsány do souboru paměti cache. Parametr flush_interval omezuje dobu, po kterou proces čeká na zaplnění slučovací vyrovnávací paměti.Například: flush_interval={0|počet_vteřin}
Předvolený interval zarovnání je 20 vteřin. Hodnota 0 parametru četnosti zarovnávání není dovolena. Pokud přesto uvedete hodnotu 0, pak bude vyrovnávací paměť zarovnávána každých 600 vteřin.
queue_size a hi_water Hodnoty queue_size a hi_water pro vzdálené spojení protokolování jsou stejné jako ty, které jsou uvedené pro protokolování do souboru. queue_size={0|počet_událostí} hi_water={0|1|číslo}
Předvolená hodnota pro velikost fronty je 0 událostí a předvolená hodnota pro označení výšky hladiny fronty událostí je 100
compress Události produktu Tivoli Access Manager jsou především textové zprávy. Abyste omezili přenos na síti, použijte volbu compress, čímž zmenšíte velikost vyrovnávacích pamětí před přenosem a rozbalením při přijetí. Například: compress={yes|no}
Předvolená hodnota komprimace je no.
Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
211
error Dojde-li k selhání odeslání do vzdálené služby, je proveden nový pokus poté, co se čeká na překročení časového limitu pro nový pokus po chybě (ve vteřinách). Dojde-li k selhání nového pokusu, spojení bude označeno a tato událost a budoucí události budou uložené v lokálním souboru paměti cache událostí, dokud nebude znovu navázáno spojení se vzdálenou službou. error=vteřiny
Předvolený časový limit pro nový pokus po selhání je 2 vteřiny.
path Parametr path určuje umístění souboru paměti cache na lokálním hostiteli.Předvolené jméno souboru paměti cache je ./server.cache, kde server je jméno vzdáleného serveru, na který se protokoluje. Pokud probíhající proces nemůže navázat komunikaci se vzdáleným serverem, nebo pokud selže spojení během práce, pak se zaznamenávání událostí přepne tak, aby události byly ukládány do určeného souboru, dokud vzdálený server nebude opět k dispozici. Jakmile bude opět navázáno spojení se vzdáleným serverem, je dokončeno zpracování události v diskové paměti cache a události jsou předány vzdálenému serveru. Předpokládejme například, že hodnota parametru path pro server pdmgrd na operačním systému UNIX je následující: path=/var/PolicyDirector/log/pdmgrd_remote.cache
Část adresáře tohoto jména cesty musí existovat. Soubor protokolu se vytvoří, pokud dosud neexistuje. Velikost tohoto souboru není určena a tento soubor nemá schopnost cyklické obnovy. Pokud není vzdálený server dostupný po dlouhou dobu, nemusí vám stačit místo na disku.
rebind_retry Pokud není vzdálený server dostupný, agent protokolu se pokusí znovu připojit k tomuto serveru v této frekvenci (ve vteřinách). rebind_retry=počet_vteřin
Předvolená hodnota časového limitu pro nový pokus o připojení je 300 vteřin.
server Služby vzdáleného protokolování jsou nabízeny programem pdacld. Vzdálené protokolování je rozšířeno o nastavení certifikátů pro autorizační službu, které je inicializováno voláním funkce azn_initialize(). Tato volba server jmenuje, ke kterým hostitelům je připojený proces pdacld pro vytváření záznamů o událostech. server=jméno_hostitele
port Pro uvedení portu, kterému naslouchá pdacld pro vzdálené požadavky o protokolování, použijte volbu port. port=pdacld_port
Předvolená hodnota portu je 7136.
212
IBM Tivoli Access Manager: Base: Administrativní příručka
dn Chcete-li ustanovit vzájemnou autentizaci se vzdáleným serverem, musíte nakonfigurovat rozlišovací jméno (DN - Distinguished Name), které je možné porovnat se jménem vráceným certifikátem vzdáleného serveru. dn="rozlišené_jméno"
Předvolená hodnota pro DN je řetězec null. Explicitní uvedení prázdného řetězce nebo použití předvolené hodnoty umožní klientům protokolování požadovat spojení se vzdáleným serverem při naslouchání libovolnému serveru. Uvádí hodnoty pro úspěšné spojení limitů DN s určitými servery, jako jsou: dn="cn=ivacld/timelord.testnet.tivoli.com,o=policy director,c=us"
DN musíte zadat jako řetězec uzavřený dvojitými uvozovkami.
Úlohy protokolování událostí Konfigurační pár hodnota-klíč použitý pro konfiguraci souborů protokolu serveru produktu Tivoli Access Manager je umístěný v objektu stanza [aznapi-configuration] každého z těchto konfiguračních souborů: v ivacld.conf pro autorizační server pdacld, v ivmgrd.conf pro server politik pdmgrd, v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd, v aznAPI.conf pro konfigurované plug-iny služeb. Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor. Vývojáři plug-inů služeb by měli poskytnout standardní funkce protokolování a monitorování. Než dokončíte externí plug-iny služeb autorizace, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference.
Odesílání záznamů událostí do souborů protokolů Než začnete tuto úlohu, zobrazte si přehled informací v části “Konfigurační parametry pro agenta protokolu souboru” na stránce 205. Chcete-li konfigurovat produkt Tivoli Access Manager na odesílání záznamů událostí do souborů protokolu: 1. Editujte odpovídající konfigurační soubor serveru. Každý server poskytuje svoje vlastní hodnoty záznamů objektů stanza ve svém konfiguračním souboru. 2. Zjistěte umístění objektu stanza [aznapi-configuration]. 3. Uveďte, že kategorie má odesílat záznamy událostí do souboru protokolů používající formát kategorie:file. Například, kategorie by mohla monitorovat autorizační události (audit.azn): logcfg = audit.azn:file
4. Uveďte umístění souboru protokolů: path=plně_kvalifikovaná_cesta
Předvolené adresáře jsou: UNIX
/opt/PolicyDirector/log
Windows C:\Program Files\Tivoli\Policy Director\log\ Předvolené jméno souboru závisí na typu prováděného protokolování, jako je audit.log Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
213
5. Uveďte ID souboru protokolu: log_id=id_protokolu
Chcete-li nastavit ID souboru protokolu explicitně, použijte parametr log_id. Pokud tento parametr nezadáte, bude mu přidělena předvolená hodnota.Je-li uvedena volba path=, předvolená hodnota je konfigurované jméno cesty. Není-li uvedena hodnota path=, ID protokolu je předvoleno na komponentu domény právě zachycené kategorie události. Například, logcfg = audit.azn:file znamená log_id=audit 6. Uveďte maximální velikost souboru protokolů: rollover_size= {<0|=0|>0}
Podle předvolby, rollover_size=2000000. Hodnoty velikosti obnovy jsou vykládané jako: v <0 — Je-li hodnota menší než nula, vytvoří se nový soubor protokolu s každým vyvoláním procesu a od tohoto okamžiku co 24 hodin. v =0 — Je-li hodnota rovna nule, obnova není provedená a soubor protokolu nekonečně narůstá. Pokud soubor protokolu již existuje, budou nová data k němu připojena. v >0 — Je-li hodnota větší než nula, obnova je provedená, když soubor protokolu dosáhne konfigurované prahové hodnoty. Pokud soubor protokolu při spuštění již existuje, budou nová data k němu připojena. 7. Uveďte maximální velikost vyrovnávací paměti: buffer_size={0|počet_kb}
Podle předvolby je velikost vyrovnávací paměti pro protokolování do souboru 0 bajtů, což zabraňuje ukládání do vyrovnávací paměti, takže každá událost je obsluhovaná individuálně. Je-li hodnota počet_kb uvedená, události jsou pakované do vyrovnávacích pamětí uvedené velikosti před zařazením do fronty pro agenty protokolu souborů . Vyrovnávací paměti se skládají z celého počtu událostí. Události nelze rozdělit mezi jednotlivými vyrovnávacími paměťmi. Pokud další událost přesáhne nakonfigurovanou maximální velikost, pak je velká událost zaznamenána do vyrovnávací paměti samostatně, přestože přesáhne nakonfigurovanou hodnotu. 8. Uveďte maximální počet událostí, které mohou být zařazené do fronty v paměti queue_size={0|počet_událostí}
Předvolená hodnota pro velikost fronty je 0. Velikost fronty nula znamená, že není nastavený žádný limit pro růst fronty událostí. Je-li uvedená a dosažená maximální hodnota počet_událostí a je-li nová událost připravená pro umístění do fronty, požadující vlákno bude blokované, dokud se ve frontě neuvolní místo. 9. Uveďte označení výše hladiny fronty událostí: hi_water={0|1|číslo}
Podle předvolby je označení výše hladiny fronty událostí dvě třetiny maximální konfigurované velikosti fronty. Je-li maximální velikost fronty 0, označení výšky hladiny bude nastaveno na předvolbu 100. Přenosové rychlosti a hodnoty těchto parametrů určují maximální množství paměti, které bude spotřebováno, pokud aktivujete protokolování událostí do souboru. Je-li označení výšky hladiny fronty událostí nastaveno na 1, každá událost ve frontě bude předaná do libovolného zapsaného agenta protokolu, jak jen to bude možné. Toto nastavení není optimální. 10. Uveďte frekvenci pro zarovnání vyrovnávacích pamětí souborů protokolu: flush_interval={0|počet_vteřin}
11. Uveďte režim souboru: mode={text|binary}
214
IBM Tivoli Access Manager: Base: Administrativní příručka
Na 32–bitových platformách Microsoft Windows umožní otevření souboru v textovém režimu překlady znaků konců řádků v souboru protokolů. Binární režim na platformě Windows zapisuje soubor protokolu ve formátu kompatibilním s operačním systémem Unix. Textový režim není schválen na platformách operačního systému UNIX a nemá žádný význam. 12. Uložte a ukončete konfigurační soubor. Příklad zobrazuje konfigurační parametry pro agenta protokolu souboru: [aznapi-configuration] logcfg=audit.azn:file path=/opt/PolicyDirector/log/audit.log, flush_interval=20,rollover_size=2000000,log_id=audit,queue_size=200, hi_water=100,buffer_size=2,mode=text
Všimněte si, že sladění velikosti vyrovnávací paměti s velikostí fronty a označením výše hladiny fronty událostí může vylepšit výkon.
Záznamy událostí propojení procesů do jiných programů Než začnete tuto úlohu, zobrazte si přehled informací v části “Konfigurační parametry pro vzdáleného agenta protokolu” na stránce 210. Chcete-li konfigurovat produkt Tivoli Access Manager na odesílání záznamů událostí do vzdáleného serveru: 1. Editujte odpovídající konfigurační soubor serveru. Každý server poskytuje svoje vlastní hodnoty záznamů objektů stanza ve svém konfiguračním souboru. 2. Zjistěte umístění objektu stanza [aznapi-configuration]. 3. Uveďte kategorii používající formát kategorie:pipe. Například, kategorie by mohla monitorovat autorizační události (audit): logcfg = audit:pipe
4. Uveďte, že chcete propojení procesů záznamů událostí do jiného programu (:pipe): logcfg = audit:pipe
5. Uveďte cestu do umístění programu, který má přijmout výstup protokolu na standardním vstupu: path=plně_kvalifikovaná_cesta
Neexistuje žádný předvolená hodnota pro jméno cesty. 6. Uveďte maximální počet událostí, které mohou být zařazené do fronty v paměti queue_size={0|počet_událostí}
Předvolená hodnota pro velikost fronty je 0. Velikost fronty nula znamená, že není nastavený žádný limit pro růst fronty událostí. Je-li uvedená a dosažená maximální hodnota počet_událostí a je-li nová událost připravená pro umístění do fronty, požadující vlákno bude blokované, dokud se ve frontě neuvolní místo. 7. Uveďte označení výše hladiny fronty událostí: hi_water={0|1|číslo}
Podle předvolby je označení výše hladiny fronty událostí dvě třetiny maximální konfigurované velikosti fronty. Je-li maximální velikost fronty 0, označení výšky hladiny bude nastaveno na předvolbu 100. Přenosové rychlosti a hodnoty těchto parametrů určují maximální množství paměti, které bude spotřebováno, pokud aktivujete protokolování událostí do souboru. Je-li označení výšky hladiny fronty událostí nastaveno na 1, každá událost ve frontě bude předaná do libovolného zapsaného agenta protokolu, jak jen to bude možné. Toto nastavení není optimální. Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
215
8. Uveďte frekvenci pro zarovnání vyrovnávacích pamětí souborů protokolu: flush_interval={0|<0|počet_vteřin}
Hodnota 0 parametru četnosti zarovnávání není dovolena. Uvedení hodnoty nula bude mít za výsledek použití hodnoty 600 vteřin. Uvedete-li zápornou hodnotu ((<0>), absolutní hodnota bude použitá jako asynchronní frekvence vyrovnání, ale zarovnání proudů je vynucené také synchronně po zápisu každého záznamu. Abyste zajistili, že vyrovnávací paměti proudů jsou pravidelně zarovnávané do disků, frekvence, se kterou server asynchronně nutí zarovnání proudů souboru do disku, je konfigurovatelná s použitím volby flush_interval=počet_vteřin. 9. Uložte a ukončete konfigurační soubor. Tento příklad propojuje procesy záznamů událostí do souborů pojmenovaných my_log_watcher: [aznapi-configuration] logcfg = audit:pipe path=/opt/risk_analyser/bin/my_log_watcher,queue_size=0,hi_water=100, flush_interval=300
Odeslání záznamů událostí do konzole Než začnete tuto úlohu, zobrazte si přehled informací v části “Konfigurační parametry pro agenta protokolu konzole” na stránce 204. Chcete-li konfigurovat produkt Tivoli Access Manager na zachycení všech výstupů monitorování do standardních výstupů: 1. Editujte odpovídající konfigurační soubor serveru. Každý server poskytuje svoje vlastní hodnoty záznamů objektů stanza ve svém konfiguračním souboru. 2. Zjistěte umístění objektu stanza [aznapi-configuration]. 3. Uveďte kategorii pro zachycování záznamů událostí. Například, kategorie by mohla monitorovat autorizační události (audit): logcfg = audit:cíl
4. Uveďte zachycení všech záznamů událostí do jednoho z následujích: a. Do standardního výstupu používajícího formát kategorie:stdout. logcfg = kategorie:stdout
b. Do standardní chyby používající formát logcfg = kategorie:stderr
5. Uložte a ukončete konfigurační soubor. Tento příklad zachycuje monitorování autorizačních událostí a odesílá je do konzole používající standardní výstup: [aznapi-configuration] logcfg = audit:stdout
Odesílání záznamů událostí do vzdáleného serveru Než začnete tuto úlohu, zobrazte si přehled informací v části “Konfigurační parametry pro vzdáleného agenta protokolu” na stránce 210. Abyste konfigurovali produkt Tivoli Access Manager na odesílání záznamů událostí do vzdáleného serveru: 1. Editujte odpovídající konfigurační soubor serveru. Každý server poskytuje svoje vlastní hodnoty záznamů objektů stanza ve svém konfiguračním souboru.
216
IBM Tivoli Access Manager: Base: Administrativní příručka
2. Zjistěte umístění objektu stanza [aznapi-configuration]. 3. Uveďte, že kategorie má odesílat záznamy událostí do vzdáleného serveru používajícího formát kategorie:remote. Například, kategorie by mohla monitorovat autorizační události (audit): logcfg=audit:remote
4. Uveďte maximální velikost vyrovnávací paměti, která je zpráva maximální velikosti, kterou se lokální program pokusil sestavit do obrazce kombinací menších událostí do větších vyrovnávacích pamětí: buffer_size={0|počet_bajtů}
Je-li hodnota počet_bajtů uvedená, události jsou pakované do vyrovnávacích pamětí této velikosti předtím, než jsou předané do vzdálených serverů. Podle předvolby je velikost vyrovnávací paměti před předáním do vzdáleného serveru 1024 bajtů. Vyrovnávací paměti se skládají z celého počtu událostí. Události nelze rozdělit mezi jednotlivými vyrovnávacími paměťmi. Pokud další událost přesáhne nakonfigurovanou maximální velikost, pak je velká událost zaznamenána do vyrovnávací paměti samostatně, přestože přesáhne nakonfigurovanou hodnotu. 5. Uveďte frekvenci pro zarovnání vyrovnávacích pamětí souborů protokolů: flush_interval={0|počet_vteřin}
Parametr flush_interval omezuje dobu, po kterou proces čeká na zaplnění slučovací vyrovnávací paměti. Předvolený interval zarovnání je 20 vteřin. Hodnota 0 parametru četnosti zarovnávání není dovolena. Pokud přesto uvedete hodnotu 0, pak bude vyrovnávací paměť zarovnávána každých 600 vteřin. 6. Uveďte maximální počet událostí, které mohou být zařazené do fronty: queue_size={0|počet_událostí}
Předvolená hodnota pro velikost fronty je 0. Velikost fronty nula znamená, že není nastavený žádný limit pro růst fronty událostí. Je-li uvedená a dosažená maximální hodnota počet_událostí a je-li nová událost připravená pro umístění do fronty, požadující vlákno bude blokované, dokud se ve frontě neuvolní místo. 7. Uveďte označení výše hladiny fronty událostí: hi_water={0|1|číslo}
Podle předvolby je hodnota označení výše hladiny fronty událostí číslo, které představuje dvě třetiny maximální konfigurované velikosti fronty. Je-li maximální velikost fronty 0, označení výšky hladiny bude nastaveno na předvolbu 100. Přenosové rychlosti a hodnoty těchto parametrů určují maximální množství paměti, které bude spotřebováno, pokud aktivujete protokolování událostí do souboru. Je-li označení výšky hladiny fronty událostí nastaveno na 1, každá událost ve frontě bude předaná do libovolného zapsaného agenta protokolu, jak jen to bude možné. Toto nastavení není optimální. 8. Uveďte, zda chcete zmenšit velikost vyrovnávacích pamětí před přenosem a rozbalením při příjmu: compress={yes|no}
Předvolbou je hodnota komprese no pro zablokování. 9. Uveďte čas, po který se má čekat, kdykoli dojde k selhání odeslání do vzdálené služby a vyskytne se chyba: error=vteřiny
Předvolený časový limit pro nový pokus po chybě je 2 vteřiny. 10. Uveďte umístění souboru paměti cache: path=plně_kvalifikovaná_cesta
Jméno souboru je jméno_serveru_remote.cache. Například: pdmgrd_remote.cache Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
217
Předvolené adresáře jsou: UNIX
/opt/PolicyDirector/log
Windows C:\Program Files\Tivoli\Policy Director\log\ Předvolené jméno souboru závisí na typu prováděného protokolování, jako je audit.log 11. Uveďte čas mezi pokusy z nové navázaní připojení (přihlášení): rebind_retry=počet_vteřin
Předvolená hodnota časového limitu pro nový pokus o připojení je 300 vteřin. 12. Uveďte jméno hostitele vzdáleného serveru: server=jméno_hostitele
13. Uveďte číslo portu vzdáleného serveru: port=pdacld_port
Předvolená hodnota čísla portu je 7136. 14. Uveďte rozlišené jméno vzdáleného serveru, abyste zavedli vzájemnou autentizaci vzdálených serverů: dn="rozlišené_jméno"
Předvolená hodnota pro DN je řetězec null. Explicitní uvedení prázdného řetězce nebo použití předvolené hodnoty umožní klientům protokolování požadovat spojení se vzdáleným serverem při naslouchání libovolnému serveru. Uvádí hodnoty pro úspěšné spojení limitů DN s určitými servery, jako jsou: dn="cn=ivacld/timelord.tivoli.com,o=policy director,c=us"
DN musíte zadat jako řetězec uzavřený dvojitými uvozovkami. 15. Uložte a ukončete konfigurační soubor. Tento příklad odesílá záznamy událostí do vzdálených serverů timelord: [aznapi-configuration] logcfg = audit:remote buffer=2000,compress=y,error=2, \ path=/opt/PolicyDirector/log/remote.cache,rebind=600,server=timelord,port=7136, dn="cn=ivacld/timelord.tivoli.com,o=policy director,c=us"
Výkon fronty protokolování monitorování Profily zařazování do front, které byly nakonfigurovány pro hlavní frontu propagace (a pro každého agenta protokolu souboru, vzdáleného protokolování a propojení procesů), jsou upraveny pro monitorování pomocí statistického rozhraní. Každá fronta je dokončená doložením příkladu objektu EventQueue, který sám sebe registruje jako podsystém statistiky používající jméno kategorie vytvořené z typu agenta protokolování a řetězce, pd.log. Statistiky front událostí je možné si prohlédnout pomocí příkazů pdadmin server task. Chcete-li uvést, které fronty budou na serveru implementovány, vydejte příkaz server task jméno_serveru stats list. Objeví se hlášení podobné tomu následujícímu: pdadmin sec_master> server task ivacld-barra.surf.ap.tivoli.com stats list pd.ras.stats.monitor pd.log.EventPool.queue // Main event propagation queue pd.log.file.audit // Audit log queue pdadmin sec_master>
Abyste prověřili statistiky pro frontu, zadejte na jeden řádek příkaz stats get: pdadmin sec_master> server task ivacld-barra.surf.ap.tivoli.com stats get pd.log.EventPool.queue
218
IBM Tivoli Access Manager: Base: Administrativní příručka
Objeví se hlášení podobné tomu následujícímu: dispatcher wakes on timeout(20) : 3617 dispatcher wakes by notify : 0 notifies above highwater (100) : 0 notifies below highwater : 0 spurious notifies : 0 total events processed : 24 average number of events handled per activation : 1 greatest number of events handled per activation : 7 blocks in queue requests : 0 pdadmin sec_master>
Četnost zarovnávání fronty je uvedena v závorkách za slovem timeout. Nastavení horní hranice fronty je uvedeno v závorkách za slovem highwater. Nastavení vybraná z různých parametrů konfigurace fronty je možné použít při pokusu o vyvážení maximálního množství spotřebované paměti mezi aktivacemi fronty a přenosovou rychlostí určitého agenta protokolu, kterou mohou používat události. Optimálně byste měli nastavit horní hranici fronty na takový počet událostí zpracovaných během aktivace fronty, který vyplní přidělený čas zpracování. Tím se vyvarujete zbytečného přepínání vláken dle kontextu. Všimněte si však, že jednoduché nastavení těchto parametrů na vysoké hodnoty není pravděpodobně produktivní, protože zpracování protokolů událostí musí být prováděno v určitém okamžiku a není je možné odkládat do neurčita. Spotřebování velkých množství paměti má také své vlastní nevýhody.
Kapitola 19. Zachycení protokolovaných a monitorovaných událostí
219
220
IBM Tivoli Access Manager: Base: Administrativní příručka
Kapitola 20. Protokolování přejatých monitorovaných událostí Tivoli Access Manager poskytuje dvě metody jak zachytit monitorované události. Jedna metoda je používaná pro zachycení monitorovaných událostí pro aktuální verzi Tivoli Access Manager, druhá metoda je používaná pro zachycení monitorovaných událostí pro účely přejímání. Použijte tuto metodu pro zachycení monitorovaných událostí pro verze před a včetně verze 3.8 produktu Tivoli Access Manager. Tato kapitola obsahuje následující části: v “Přehled monitorování” v “Koncepty souboru prověřovacích záznamů” na stránce 222 v “Záznamy objektu stanza přejatého konfiguračního souboru pro monitorování” na stránce 227 v “Protokolování a monitorování úloh” na stránce 230
Pro aplikace vyvinuté s použitím Authorization ADK vytvoří aplikace správce zdrojů konfigurační soubor a je obsazen jako součást procesu konfigurace. Konfigurační soubor obsahuje parametry konfigurace monitorování. Každým parametrem konfigurace monitorování se individuálně zabývá část “Záznamy objektu stanza přejatého konfiguračního souboru pro monitorování” na stránce 227.
Koncepty souboru prověřovacích záznamů Tato část popisuje obsah souboru prověřovacích záznamů: v “Příklady záznamů auditu autorizace” v “Příklady záznamů auditu autentizace” na stránce 223 v “Příklady záznamů auditu správy” na stránce 225
Příklady záznamů auditu autorizace Autorizace je primární funkcí serverů produktu Tivoli Access Manager. Záznamy monitorování autorizace je možné zachycovat tehdy, když má cílový objekt v databázi politik autorizace produktu Tivoli Access Manager (prostoru chráněných objektů) připojenu politiku POP, která umožňuje funkci monitorování. Viz Kapitola 9, “Správa politik chráněných objektů”, na stránce 85. Konfigurovat monitorování pro určitý server můžete přidáním “azn” do konfiguračního seznamu auditu v objektu stanza [aznapi-configuration] konfiguračního souboru serveru: [aznapi-configuration] auditcfg = azn
Níže uvedený záznam je příkladem prověřovacího záznamu týkajícího se získání autorizačního pověření uživatele: <event rev="1.2"> 2003-11-14-16:25:08.341+00:00I-----0azn0phaedrus <principal auth="IV_LDAP_V3.0">sec_master azn_id_get_creds
Níže uvedený záznam je příkladem prověřovacího záznamu týkajícího se selhání pokusu o získání autorizačního pověření uživatele fred: <event rev="1.2"> 2003-11-14-16:25:08.341+00:00I-----1azn0phaedrus <principal auth="IV_LDAP_V3.0">fred 6400
222
IBM Tivoli Access Manager: Base: Administrativní příručka
Níže je uveden příklad záznamu události začátku a konce události komponenty autorizace (azn): Výpustky představují další události, které byly zaprotokolovány mezi začátkem a koncem monitorování: <event rev="1.2"> 2003-11-14-16:25:08.341+00:00I-----0azn0phaedrusinvalid . . . <event rev="1.2"> 2003-12-10-20:58:16.584+00:00I-----0azn0phaedrusinvalid
Příklady záznamů auditu autentizace Autentizace objektu se provádí během získávání pověření mimo produkt Tivoli Access Manager. Prověřovací záznamy je možné zachycovat produktem Tivoli Access Manager, který zaznamená úspěch nebo selhání podobných pokusů o autentizaci. Konfigurovat monitorování pokusů o autentizaci můžete přidáním "authn" do konfiguračního seznamu auditu v objektu stanza [aznapi-configuration] konfiguračního souboru 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.2"> 2003-11-14-23:04:26.630+00:00I-----0authn0phaedrus <principal auth="invalid">
Kapitola 20. Protokolování přejatých monitorovaných událostí
223
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.2"> 2003-11-14-15:56:06.551+00:00I-----0authn0phaedrus <principal auth="IV_LDAP_V3.0" domain="Default">testuser2
Následující je ukázka autentizační události, která je způsobená vypršením hesla, a je protokolovaná z WebSEAL: <event rev="1.2"> 2003-11-14-16:23:00.294+00:00I-----0authn0phaedrus <principal auth="IV_LDAP_V3.0" domain="Default">testuser2
Všimněte si, že WebSEAL vydává výsledek 0 místo 1, i když narazil na heslo, které vypršelo. Toto je považováno za úspěšné, protože bylo zadáno správné heslo. Následující je ukázka autentizační události WebSEAL, která je způsobená zadáním špatného hesla: <event rev="1.2"> 2003-10-21-17:23:29.250-07:00I——-1authn0 location>testsit <principal auth="password" domain="Default">testuser Password Failure: testuser
Následující je ukázka události úspěšné změny hesla protokolované z WebSEAL. Všimněte si, že výsledným stavem je 0. <event rev="1.2"> 2003-07-02-23:59:00.068+00:00I——-0
224
IBM Tivoli Access Manager: Base: Administrativní příručka
authn1 location>c03comcrit2 invalid
Následující je ukázka události selhání autentizace kvůli příliš mnoha neplatným pokusům o přihlášení (politika třech pokusů) protokolované z WebSEAL. <event rev="1.2"> 2003-11-14-19:06:00.294+00:00I-----1authn0phaedrus <principal auth="password" domain="Default">testuser2 Account Lock-out: testuser2
Abyste zjistili příčinu monitorované události jako uzamčení účtu (politika třech pokusů), opatřete si chybový kód, jak je zobrazeno v části Tabulka 10 na stránce 196. Chybový kód je obsažený ve výstupu auditu v příznaku (výsledný stav): "320938290">0
Použijte příkaz pdadmin errtext pro daný chybový kód a získejte důvod selhání. Například: pdadmin>errtext 320938290 Tento účet byl dočasně uzamčen z důvodu příliš mnoha neplatných pokusů o přihlášení
Příklady záznamů auditu správy Mezi odpovědnosti serveru politik patří správa hlavní databáze politik autorizace. Tato databáze zahrnuje popis prostoru chráněných objektů pro doménu, přístupové seznamy (ACL), politiky chráněných objektů (POP) a autorizační pravidla, také kde jsou tyto politiky připojené k objektům. Konfigurovat monitorování aktivity serveru politik můžete přidáním "mgmt" do konfiguračního seznamu auditu v objektu stanza [aznapi-configuration] konfiguračního souboru serveru (ivmgrd.conf): [aznapi-configuration] auditcfg = mgmt
Níže je uveden příklad záznamu událostí následujícího příkazu pdadmin: pdadmin> pop modify pop1 set audit-level all <event rev="1.2"> 2003-11-14-16:25:54.543+00:00I-----0mgmt13702location not specified <principal auth="IV_DCE_V3.0">cell_admin Kapitola 20. Protokolování přejatých monitorovaných událostí
225
"2019" "1002" "pop1" "0" ""
Níže je uveden příklad záznamu události následujícího příkazu pdadmin, který vydal uživatel sec_master, aby vytvořil nového uživatele Tivoli Access Manager s příjmením sngsouser1: pdadmin> user create sngsouser1 "cn=sngsouser1,o=Tivoli,c=us" test user1 password12 <event rev="1.2"> 2003-07-02-23:35:05.723+00:00I——-0mgmt13401c03comcrit1 <principal auth="IV_LDAP_V3.0">sec_master "13401" "false" "false" "sngsouser1" "cn=sngsouser1,o=Tivoli,c=us" "test" "user1"
Níže je uveden příklad záznamu události následujícího příkazu pdadmin, který zablokoval účet určeného uživatele (sngsouser1). Hodnota false zablokuje účet uživatele a vztahuje se k parametru account-valid no. Podobně hodnota true aktivuje účet uživatele a vztahuje se k parametru account-valid yes. pdadmin> user modify sngsouser1 account-valid no <event rev="1.2"> 2003-11-14-23:01:37.078+00:00I-----0mgmt13406phaedrus <principal auth="IV_LDAP_v3.0">dlucas "false" "sngsouser1"
226
IBM Tivoli Access Manager: Base: Administrativní příručka
Záznamy objektu stanza přejatého konfiguračního souboru pro monitorování Záznamy objektu stanza pro konfiguraci souborů monitorování auditu serveru Tivoli Access Manager jsou umístěné v objektu stanza [aznapi-configuration] každého ze souborů server-jméno.conf. Každý správce zdrojů jmenuje konfigurační soubor. Pro aplikace vyvinuté s použitím Authorization ADK vytvoří aplikace správce zdrojů konfigurační soubor a je obsazen jako součást procesu konfigurace. Konfigurační soubor obsahuje parametry konfigurace monitorování. Servery produktu Tivoli Access Manager zahrnují: Server
jméno_serveru
Konfigurační soubor
server politik
pdmgrd
ivmgrd.conf
proxy server politik
pdmgrproxyd
pdmgrproxyd.conf
Autorizační server
pdacld
ivacld.conf
Například: Například, následující záznamy jsou potřebné pro monitorování: [aznapi-configuration] logaudit = {yes|no} auditlog = fully_qualified_path auditcfg = azn auditcfg = authn #auditcfg = mgmt logsize = {-num|+num|byte_size of log prior to rollover} logflush = num_seconds to flush event queue
logaudit Zaznamenávání prověřovacích záznamů se aktivuje na úrovni jednotlivých serverů. Zaznamenávání prověřovacích záznamů se aktivuje nastavením hodnoty záznamu logaudit ve stanze [aznapi-configuration] konfiguračního souboru určitého serveru. Standardně je monitorování zablokováno: [aznapi-configuration] logaudit = no
Hodnota yes aktivuje monitorování pro daný server. Například: [aznapi-configuration] logaudit = yes
auditcfg Monitorované události jsou rozděleny podle funkcionality serveru, který je generuje. Některé funkcionality jsou společné všem serverům produktu Tivoli Access Manager, zatímco jiné jsou specifické pro daný server. Každý typ funkcionality serveru je přidružen k monitorovacímu příznaku: Monitorovací příznak
Funkcionalita serveru
authn
Monitorování nabytí pověření pomocí autentizace
azn
Monitorování autorizačních událostí
mgmt
Monitorování příkazů správy
Kapitola 20. Protokolování přejatých monitorovaných událostí
227
Každý server produktu Tivoli Access Manager můžete nakonfigurovat tak, aby výběrově zachycoval monitorované události podle kategorií. Následující konfigurace například zachycuje pouze události týkající se autentizace a zakazuje zachycování všech dalších událostí, včetně potlačení jakéhokoli monitorování autorizace, které je aktivováno v nastaveních politiky POP. [aznapi-configuration] auditcfg = authn
Níže uvedené nastavení aktivuje monitorování autentizace a autorizace. Všechny ostatní kategorie monitorování jsou zakázány pomocí umístění znaku komentáře (#) na začátek řádku: [aznapi-configuration] auditcfg = azn auditcfg = authn #auditcfg = mgmt
Příznakem auditu http, který je použitý pro zachycení událostí HTTP WebSEAL, se zabývá IBM Tivoli Access Manager for e-business WebSEAL: Administrativní příručka. Následující nastavení umožňuje monitorování HTTP WebSEAL: [aznapi-configuration] auditcfg = http
Standardně, když je monitorování aktivováno tak, aby zpracování probíhalo bez nakonfigurovaných monitorovacích příznaků, pak jsou zachycovány všechny monitorovatelné události. Níže uvedená tabulka označuje monitorované události (označené monitorovacím příznakem), které je možné zachycovat pro každý určitý server produktu Tivoli Access Manager. Monitorovací příznak
pdmgrd
pdacld
pdmgrproxyd
správce zdrojů
authn
X
X
X
X
azn
X
X
mgmt
X
X
auditlog Standardně se soubor prověřovacích záznamů každého serveru nazývá audit.log a je umístěn v adresáři log daného serveru. Hodnota záznamu auditlog v konfiguračním souboru každého serveru určuje umístění souboru prověřovacích záznamů. Server server politik
Umístění souboru protokolu UNIX: auditlog = /var/PolicyDirector/audit/pdmgrd.log
(pdmgrd) Windows: auditlog = instalační_adresář\audit\pdmgrd.log proxy server politik
logsize Hodnota záznamu logsize určuje maximální velikost, po kterou mohou soubory prověřovacích záznamů růst, a na začátku je nakonfigurována na následující předvolenou hodnotu (v bajtech): [aznapi-configuration] logsize = 2000000
Když soubor prověřovacích záznamů dosáhne uvedené hodnoty, známé také jako prahová hodnota 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 časovou značkou. Spustí se protokolování do nového souboru prověřovacích záznamů. Různé možnosti pro hodnoty velikostí protokolů jsou vykládány následujícím způsobem: v Pokud je hodnota velikosti protokolu záporné číslo menší než nula (<0), vytvoří se nový soubor monitorování při každém vyvolání procesu monitorování a protokoly jsou obnovovány denně bez ohledu na jejich velikost. v Pokud je hodnota velikosti protokolu rovná nule (= 0), nedojde k žádnému obnovení a nevytvoří se žádné monitorování. Pokud soubor monitorování už existuje, bude nekonečně narůstat s novými připojovanými daty. v Pokud je hodnota velikosti protokolu větší než nula (> 0), bude obnova provedená, když soubor monitorování dosáhne konfigurované prahové hodnoty. Přípustný rozsah je od 1 bajtu do 2 megabajtů. Pokud soubor prověřovacích záznamů při spuštění již existuje, pak jsou k němu nová data připojena.
logflush Soubory prověřovacích záznamů se zapisují do toků dat, které využívají vyrovnávací paměť. Pokud monitorujete soubory prověřovacích záznamů v reálném čase, můžete chtít změnit četnost, se kterou server nutí zarovnat vyrovnávací paměti souboru prověřovacích záznamů. Standardně je nakonfigurováno, aby se soubory prověřovacích záznamů zarovnávaly každých 20 vteřin: [aznapi-configuration] logflush = 20
Pokud uvedete záporné číslo, pak se jeho absolutní hodnota použije k určení okamžiku, kdy má být provedeno zarovnání souborů prověřovacích záznamů.
audit-attribute Můžete uvést jména jednoho nebo více atributů informací rozhodnutí o přístupu (ADI - access decision information) pro audit. Atribut zavede prokazatelnost přístupu tím, že poskytne informace, aby pomohl označit potenciální nesprávný přístup přínosů. Můžete udělit nebo odmítnout přístup založený na pravidlech, které se týkají atributů. Například, funkce autentizace switch-user (přepnout uživatele) WebSEAL poskytuje mechanismus, který umožňuje určitým uživatelům vtělit se do jiného uživatele. Pokud je Kapitola 20. Protokolování přejatých monitorovaných událostí
229
použita funkce switch-user, požadavek o autorizaci je vyhodnocený spíše proti předpokládané identitě než proti momentální identitě uživatele. Je vhodné, aby bylo administrátorům umožněno zachytit momentální identitu uživatele. Například, vy můžete monitorovat jména nebo popisy politik Tivoli Access Manager (ACL, POP a autorizační pravidla), které jsou použité pro objekt, ke kterému je právě vytvořený přístup. [aznapi-configuration] audit-attribute = tagvalue_su-admin
Neexistují žádné předvolené hodnoty.
Protokolování a monitorování úloh Server politik spravuje databázi politik nebo databáze a udržuje informace o umístění dalších serverů Tivoli Access Manager v každé doméně. Server politik je obvykle málo náročný na administrativu a konfiguraci. Pár klíč-hodnota, který se používá při konfiguraci souborů prověřovacích záznamů serveru Tivoli Access Manager, je umístěn ve stanze [aznapi-configuration] každého z těchto konfiguračních souborů: v ivacld.conf pro autorizační server pdacld, v ivmgrd.conf pro server politik pdmgrd, v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd, v aznAPI.conf pro konfigurované plug-iny služeb. Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor. Vývojáři plug-inů služeb by měli poskytnout standardní protokolování a funkce monitorování. Než dokončíte externí plug-iny služeb autorizace, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Tato část popisuje úlohy konfigurace, které může administrátor provádět. v “Aktivace monitorování” v “Uveďte, které atributy ADI mají být monitorované” na stránce 231 v “Údržba souborů protokolu auditu” na stránce 231
Aktivace monitorování Abyste konfigurovali soubory monitorování serveru Tivoli Access Manager: 1. Editujte odpovídající konfigurační soubor serveru. Každý server poskytuje svoje vlastní hodnoty záznamů objektů stanza ve svém konfiguračním souboru. 2. Zjistěte umístění objektu stanza [aznapi-configuration]. 3. Aktivujte monitorování tak, že uvedete yes (ano) nebo true (pravdivý): logaudit = {yes|true}
Monitorování je zablokované předvolbou. Pokud se zablokuje, jsou požadované také záznamy objektů stanza auditcfg a auditlog. 4. Zvolte typ záznamů auditu specifický pro komponentu podle toho, které záznamy chcete zachytit: auditcfg = azn #auditcfg = authn #auditcfg = mgmt
230
IBM Tivoli Access Manager: Base: Administrativní příručka
Standardně, když je monitorování aktivováno tak, aby zpracování probíhalo bez nakonfigurovaných monitorovacích příznaků, pak jsou zachycovány všechny monitorovatelné události. Další záznam objektu stanza je auditcfg=http, což je použito pro komponenty jiné než Base, jako například WebSEAL. Každý server poskytuje vlastní hodnotu ve svém konfiguračním souboru. 5. Uveďte jméno a umístění souboru monitorování pro lokálního klienta: auditlog = fully_qualified_path
Pokud neuvedete jméno a umístění, monitorování nebude prováděno. Každý server provádí vlastní nastavení prověřovacích záznamů ve svém konfiguračním souboru. Následující adresáře a jméno souborů jsou předvolenými hodnotami pro každý server: Windowsinstall_dir\audit\ivacld.log install_dir\audit\pdmgrd.log install_dir\audit\pdmgrproxyd.log UNIX/var/PolicyDirector/audit/pdmgrd.log /var/PolicyDirector/audit/ivacld.log /var/PolicyDirector/audit/pdmgrproxyd.log
6. Uložte a ukončete konfigurační soubor. Tento příklad zobrazuje záznamy objektu stanza potřebné pro zachycení autorizačních událostí pro proxy server politik a pro přesměrování výstupu protokolování do pdmgrproxyd.log: [aznapi-configuration] logaudit = yes auditlog = /var/PolicyDirector/audit/pdmgrproxyd.log auditcfg = azn #auditcfg = authn #auditcfg = mgmt
Uveďte, které atributy ADI mají být monitorované Abyste uvedli jméno atributů ADI, které chcete monitorovat: 1. Editujte odpovídající konfigurační soubor serveru. 2. Zjistěte umístění objektu stanza [aznapi-configuration]. 3. Přidejte záznam objketu stanza do každého atributu ADI, který chcete monitorovat: audit-attribute = azn-attr1 audit-attribute = azn-attr2
Neexistují žádné předvolené hodnoty. Hodnota atributu autorizační API (azn_attr) představuje alfanumerický řetězec citlivý na velikost písmen. 4. Uložte a ukončete konfigurační soubor. Tento příklad zobrazuje konfigurované záznamy objektů stanza, které mají zachytit události pro atributy WebSEAL: [aznapi-configuration] logaudit = yes auditlog = c:\myaudit.log auditcfg = azn audit-attribute = tagvalue_su-admin
Údržba souborů protokolu auditu Abyste mohli udržovat soubory protokolu auditu: 1. Editujte odpovídající konfigurační soubor serveru. 2. Zjistěte umístění objektu stanza [aznapi-configuration].
Kapitola 20. Protokolování přejatých monitorovaných událostí
231
3. Uveďte v bajtech maximální velikost pro soubor protokolu auditu dřív, než dojde k obnově: logsize = {0|neg_number_bytes|number_bytes}
Přípustný rozsah je od 1 bajtu do 2 megabajtů. Předvolená hodnota je 2000000. Nula označuje, že nedošlo k obnově a nebyl vytvořený žádný soubor obnovy. Záporné číslo znamená, že se soubory budou cyklicky přetáčet každý den bez ohledu na velikost. Pokud soubor protokolu auditu dosáhne prahové hodnoty, původní soubor protokolu auditu se přejmenuje a vytvoří se nový soubor protokolu s originálním jménem. 4. Uveďte frekvenci pro zarovnání vyrovnávacích pamětí souborů auditu. Tato hodnota bude použitá jako počet sekund povolených pro zarovnání mezi protokoly. Platný rozsah je od 1 sekundy do 6 hodin. logflush = number_seconds
Předvolená hodnota je 20. Pokud uvedete záporné číslo, pak se jeho absolutní hodnota použije k určení okamžiku, kdy má být provedeno zarovnání souborů prověřovacích záznamů. 5. Uložte a ukončete konfigurační soubor. Tento příklad zobrazí záznamy objektů stanza potřebné pro uvedení 2000000 bajtů jako maximální velikost pro soubor protokolu a 20 sekund mezi zarovnáním vyrovnávacích pamětí souborů protokolu: [aznapi-configuration] logsize = 2000000logflush = 20
232
IBM Tivoli Access Manager: Base: Administrativní příručka
Dodatek A. Referenční informace ke konfiguraci serveru Činnost serverů produktu Tivoli Access Manager je řízena prostřednictvím konfiguračních souborů. Každý konfigurační soubor obsahuje sekce, které se nazývají stanzy.
Konfigurační soubory Konfigurační soubory serverů jsou textové ASCII soubory a obsahují záznamy stanz. Konfigurační soubory jsou zpracované pouze při spuštění serveru. Následující tabulka obsahuje seznam aktuálních konfiguračních souborů produktu Tivoli Access Manager. Konfigurační soubor
Účel
Server
“pd.conf” na stránce 237
Běhová konfigurace Tivoli Access Manager
Používá autorizační server (pdacld)
“ivacld.conf” na stránce 235
Konfigurace autorizačního serveru
Autorizační server Tivoli Access Manager (pdacld)
“ivmgrd.conf” na stránce 236
Konfigurace serveru politik
Server politik Tivoli Access Manager (pdmgrd)
“pdmgrproxyd.conf” na stránce 237
Konfigurace proxy serveru politik
Proxy server politik Tivoli Access Manager (pdmgrproxyd)
“activedir_ldap.conf” na stránce 234
Konfigurace registru uživatelů založeného na Microsoft Active Directory
Server Microsoft Active Directory
“ldap.conf” na stránce 236 Konfigurace registru uživatelů založeného na LDAP
Server založený na LDAP
“activedir.conf” na stránce Konfigurace registru uživatelů 234 založeného na Active Directory
Server Microsoft Active Directory
“domino.conf” na stránce 235
Server IBM Lotus Domino
Konfigurace registru uživatelů založeného na Domino
Pokud nezměníte při instalaci produktu Tivoli Access Manager instalační adresáře, konfigurační soubory zůstanou v následujících předvolených adresářích: UNIX
activedir.conf Pokud jako váš registr uživatelů produktu Tivoli Access Manager používáte server Microsoft Active Directory, musíte mít konfigurační soubor serveru activedir.conf. Pomocí tohoto konfiguračního souboru přizpůsobíte činnost každého serveru registrů Active Directory. Poznámka: Active Directory je podporován serverem politik pouze na platformě Microsoft Windows. Stanzy, které jsou součástí tohoto konfiguračního souboru, jsou: v [uraf-registry] v [meta-info] v [ssl] v [configuration-database] Zrušení konfigurace tohoto serveru s použitím souboru activedir.conf také dotazuje informace z tohoto konfiguračního souboru. Také můžete nastavit hodnoty pro záznamy objektu stanza Active Directory v objektu stanza [uraf-registry] v konfiguračního souborech ivmgrd.conf a ivacld.conf.
activedir_ldap.conf Pokud používáte klienta LDAP pro načítání dat pro registr uživatelů Active Directory, na který je server Tivoli Access Manager konfigurovaný, musíte vlastnit konfigurační soubor serveru activedir_ldap.conf. Pomocí tohoto konfiguračního souboru přizpůsobíte činnost každého serveru registrů Active Directory. Například byste mohli mít více platforem; když je server politik konfigurovaný pro použití registru uživatelů Active Directory a dalších procesů blades jako WebSEAL na jedné platformě a autorizační server je konfigurovaný pro použití klienta LDAP pro načtení dat z registru uživatelů Active Directory na jiné platformě. Stanzy, které jsou součástí tohoto konfiguračního souboru, jsou: v [uraf-registry]
234
IBM Tivoli Access Manager: Base: Administrativní příručka
domino.conf Pokud jako váš registr uživatelů produktu Tivoli Access Manager používáte server Lotus Domino, musíte mít konfigurační soubor serveru domino.conf. Pomocí tohoto konfiguračního souboru přizpůsobíte činnost každého serveru registrů Domino. Stanzy, které jsou součástí tohoto konfiguračního souboru, jsou: v [uraf-registry] Zrušení konfigurace serveru s použitím souboru domino.conf také dotazuje informace z tohoto konfiguračního souboru. Můžete hodnoty nastavit také na záznamy objektů stanza Domino v objektu stanza [uraf-registry] v konfiguračního souborech ivmgrd.conf a ivacld.conf.
ivacld.conf Pokud používáte autorizační server pdacld produktu Tivoli Access Manager, musíte mít konfigurační soubor serveru ivacld.conf. Pomocí tohoto konfiguračního souboru přizpůsobíte činnost každého autorizačního serveru. Stanzy, které jsou součástí tohoto konfiguračního souboru, jsou: v [meta-info] v [ivacld] v [ldap] v [uraf-registry] v [ssl] v [manager] v v v v v v v v v
Zrušení konfigurace serveru s použitím souboru ivacld.conf také dotazuje informace z tohoto konfiguračního souboru.
Dodatek A. Referenční informace ke konfiguraci serveru
235
ivmgrd.conf Pokud používáte server politik pdmgrd produktu Tivoli Access Manager, musíte mít konfigurační soubor serveru ivmgrd.conf. Pomocí tohoto konfiguračního souboru přizpůsobíte činnost každého serveru politik. Stanzy, které jsou součástí tohoto konfiguračního souboru, jsou: v [meta-info] v [ivmgrd] v [ldap] v [uraf-registry] v [ssl] v [authentication-mechanisms] v [aznapi-configuration] v [xmladi-attribute-definitions] v [aznapi-entitlement-services] v [aznapi-pac-services] v [aznapi-cred-modification-services] v [aznapi-external-authzn-services] v v v v
Zrušení konfigurace serveru s použitím souboru ivmgrd.conf také dotazuje informace z tohoto konfiguračního souboru.
ldap.conf Pokud používáte LDAP jako registr uživatelů produktu Tivoli Access Manager, použijte konfigurační soubor ldap.conf k přizpůsobení záznamů stanz založených na LDAP. Objekty stanza zahrnuté v tomto konfiguračním souboru obsahují: v [ldap] v [meta-info] v [ssl] Všimněte si, že obsah objektu stanza [ldap] se liší, když se objeví v konfiguračních souborech activedir.conf a domino.conf.
236
IBM Tivoli Access Manager: Base: Administrativní příručka
pd.conf Chcete-li používat produkt Tivoli Access Manager, musíte mít konfigurační soubor pd.conf. Pomocí tohoto konfiguračního souboru můžete automatizovat spouštění serveru, určit, zda je nakonfigurována sada programů Tivoli Access Manager Runtime, a určit informace o registru uživatelů. Záznamy stanzy pro automatické spouštění serveru jsou umístěny ve stanze [pdrte] konfiguračního souboru pd.conf. Stanzy, které jsou součástí tohoto konfiguračního souboru, jsou: v [meta-info] v [pdrte] v [ssl] v [manager] Zrušení konfigurace serveru s použitím souboru pd.conf také dotazuje informace z tohoto konfiguračního souboru.
pdmgrproxyd.conf Pokud používáte server politik pdmgrproxyd produktu Tivoli Access Manager, musíte mít konfigurační soubor serveru pdmgrproxyd.conf. Použijte tento konfigurační soubor pro přizpůsobení operací každého proxy serveru politik. Stanzy, které jsou součástí tohoto konfiguračního souboru, jsou: v [meta-info] v [pdmgrproxyd] v [ldap] v [uraf-registry] v [ssl] v [manager] v [authentication-mechanisms] v [aznapi-configuration] v [xmladi-attribute-definitions] v [aznapi-admin-services] v [configuration-database] Zrušení konfigurace serveru s použitím souboru pdmgrproxyd.conf také dotazuje informace z tohoto konfiguračního souboru.
Dodatek A. Referenční informace ke konfiguraci serveru
237
pdwpm.conf Pokud používáte Web Portal Manager Tivoli Access Manager, musíte vlastnit konfigurační soubor pdwpm.conf. Použijte tento konfigurační soubor pro uvedení, jestli se stránky změny hesla mají zobrazit, a k označení umístění souboru pdwpm.properties. Tento konfigurační soubor můžete použít k označení, který typ metody přihlášení autentizace použít, pokud máte spojených několik WebSEAL. Stanzy, které jsou součástí tohoto konfiguračního souboru, jsou: v [meta-info] v [pdwpm] Zrušení konfigurace serveru s použitím souboru pdwpm.conf také dotazuje informace z tohoto konfiguračního souboru.
238
IBM Tivoli Access Manager: Base: Administrativní příručka
Konfigurační soubory správce zdrojů Tivoli Access Manager poskytuje ukázkový soubor obsahující víc běžných objektů stanza konfiguračního souborů. Vaše zdroje dokumentace, při zahrnování vašich vlastních plug-inů nebo aplikací rozšířených o zabezpečení, zahrnují publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference nebo IBM Tivoli Access Manager for e-business Authorization Java Classes Developer Reference. Když tvoříte vašeho vlastního zabezpečeného správce zdrojů nebo rozšiřujete funkce poskytované Tivoli Access Manager, můžete použít konfigurační soubor aznAPI.conf. Tento soubor je zahrnutý jako ukázkový v autorizační sadě programů ADK v podadresáři example/authzn/demo/cpp. Stanzy, které jsou součástí tohoto konfiguračního souboru, jsou: v [aznapi-configuration] v [xmladi-attribute-definitions] v [ssl] v [ldap] v [uraf-registry] v [aznapi-entitlement-services] v [aznapi-pac-services] v [aznapi-cred-modification-services] v [aznapi-external-authzn-services] v [aznapi-admin-services] v [manager] v [authentication-mechanisms]
Dodatek A. Referenční informace ke konfiguraci serveru
239
Pokyny pro konfiguraci stanz Tyto pokyny vám pomohou provádět změny v konfiguračních souborech produktu Tivoli Access Manager. Pokyny jsou rozděleny na tyto typy: v Obecné pokyny v Předvolené hodnoty v Řetězce v Definované řetězce v Jména souborů v Celočíselné proměnné v Booleovské hodnoty Instrukce najdete v části “Změna nastavení konfigurace” na stránce 144.
Obecné pokyny Při provádění změn v nastaveních konfigurace se řiďte těmito obecnými pokyny: v V konfiguračním souboru neplatí žádná závislost na pořadí nebo umístění stanz. v Záznamy stanz jsou označeny jako povinné nebo volitelné. Je-li záznam povinný, záznam musí obsahovat platný klíč a hodnotu. v Neměňte jména klíčů v konfiguračních souborech. Změna jména klíče může vést k nepředvídatelnému chování serverů. v Záznamy objektů stanza a jména klíčů jsou citlivá na velikost písmen. Například, usessl a UseSSL jsou dva odlišné záznamy. v Ve jménech klíčů nejsou povoleny mezery. v Pro formát páru klíč-hodnota klíč = hodnota nejsou mezery obklopující znak rovná se (=) povinné, ale jsou doporučené. v Znaky, které nelze tisknout (jako tabelátory, vracení vozíku a posuny řádků), které se objevují na konci záznamu objektů stanza, jsou ignorované. Znaky, které nelze tisknout, jsou znaky ASCII s desítkovou hodnotou menší než 32.
Předvolené hodnoty Při změně předvolených nastavení konfigurace se řiďte následujícími pokyny: v Mnoho hodnot je vytvořeno nebo měněno pouze pomocí konfiguračních programů. Needitujte ručně tyto stanzy nebo hodnoty. v Některé hodnoty jsou vyplněny automaticky během konfigurace. Tyto hodnoty jsou nezbytné pro inicializaci serveru po dokončení konfigurace. v Předvolené hodnoty záznamu stanzy mohou být různé. To závisí na konfiguraci serveru. Některé páry klíč-hodnota nelze u některých serverů použít a jsou v předvoleném konfiguračním souboru takového serveru vynechány.
240
IBM Tivoli Access Manager: Base: Administrativní příručka
Řetězce Některé hodnoty akceptují hodnotu řetězce. Když ručně editujete konfigurační soubor, řiďte se při změnách nastavení konfigurace vyžadující řetězec následujícími pokyny: v Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. v Je možné, že budou zavedena další nebo odlišná omezení sady povolených znaků řetězce. Například mnoho řetězců smí používat pouze ASCII znaky. Kontrolujte popis každé stanzy, zda neobsahuje nějaká omezení. v V některých případech, ale ne vždy, jsou v případě, že v hodnotách používáte mezery nebo více než jedno slovo, vyžadovány dvojité uvozovky. Jste-li na pochybách, prohlédněte si popis nebo příklady záznamu stanzy. v Minimální a maximální délky hodnot řetězce vztahujícího se k registru uživatelů, pokud takové limity existují, jsou určeny příslušným registrem. Například maximální délka pro Active Directory je 256 alfanumerických znaků.
Definované řetězce Některé hodnoty akceptují hodnotu řetězce, ale hodnota musí být jednou ze sady nadefinovaných řetězců. Pokud ručně editujete konfigurační soubor, ujistěte se, že hodnota vámi zapsaného řetězce odpovídá některé z platných hodnot nadefinovaných řetězců. Například část stanzy [aznapi-configuration] obsahuje následující záznam: auditcfg = {azn|authn|mgmt}
Předpokládá se, že hodnota pro auditcfg bude buď azn, authn nebo mgmt. Jakákoliv jiná hodnota je neplatná a jejím výsledkem je chyba.
Jména souborů Některé hodnoty jsou jmény souborů. Každý záznam stanzy, který očekává, že jeho hodnotou bude jméno souboru, obsahuje popis záznamu stanzy, ve kterém je uvedena jedna z následujících platných konstrukcí: v jméno_souboru Cesta k adresáři není součástí. v relativní jméno_souboru Cesta k adresáři je povolena, ale není povinná. Očekává se obvykle, že tyto soubory jsou umístěny relativně k umístění standardního adresáře produktu Tivoli Access Manager. Záznam stanzy jména každé relativní cesty obsahuje kořenový adresář, ke kterému je jméno souboru relativní. v plně kvalifikovaný absolutní cesta Je povinné uvedení absolutní cesty k adresáři. Poznámka: Některé záznamy stanz dovolují více než jednu z výše uvedených možností. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).
Dodatek A. Referenční informace ke konfiguraci serveru
241
Celočíselné proměnné Mnoho záznamů stanz očekává, že hodnota záznamu bude vyjádřena celým číslem. v Záznamy stanz, které přijímají hodnotu celočíselné proměnné, očekávají, že tyto hodnoty budou v platném rozsahu. Rozsah je popsán ve tvaru minimální hodnota a maximální hodnota. Například stanza [logging] obsahuje záznam logflush, jehož minimální hodnotou je 1 vteřina a maximální hodnotou je 600 vteřin. v Některé záznamy vyžadují, aby hodnota celočíselné proměnné byla kladným číslem a minimální hodnotou byla 1. Jiné záznamy dovolují minimální hodnotu celočíselné proměnné 0. Dávejte si pozor, když nastavujete hodnotu 0 celočíselné proměnné. Například hodnota 0 celočíselné proměnné může zablokovat funkci, která je řízena tímto záznamem stanzy. Například když stanza [ivacld] obsahuje záznam tcp-req-port = 0, tak se zablokuje číslo portu. Nebo může hodnota 0 celočíselné proměnné znamenat, že číslo nemá omezení. Například když stanza [ldap] obsahuje záznam max-search-size = 0, tak to znamená, že maximální rozsah vyhledávání není nijak omezen. v U některých záznamů vyžadujících hodnoty celočíselných proměnných nezavádí produkt Tivoli Access Manager horní limit povoleného maximálního čísla. Například obvykle neexistuje maximální hodnota hodnot týkajících se časového limitu, jako např. timeout = číslo ve stanze [ldap]. V takovém případě záznamu je maximální číslo omezeno pouze velikostí paměti alokované pro typ celočíselných dat. Toto číslo je závislé na typu operačního systému. Systémy, které alokují 4 bajty pro celočíselnou proměnnou, používají hodnotu 2147483647. Ale jako administrátor použijte číslo, které představuje hodnotu, které je nejlogičtější pro hodnotu, kterou se snažíte nastavit.
Booleovské hodnoty Mnoho záznamů stanz používá booleovskou hodnotu. Produkt Tivoli Access Manager rozeznává booleovské hodnoty yes (ano) a no (ne). Některé záznamy v konfiguračních souborech čtou jiné servery a obslužné programy. Například mnoho záznamů ve stanze [ldap] čte klient LDAP. Některé z těchto jiných programů rozeznávají další booleovské znaky: v yes (ano) nebo true (pravda) v no (ne) nebo false (nepravda) Cokoli jiného než yes|true včetně prázdné hodnoty bude interpretováno jako no|false. Rozeznávané booleovské záznamy jsou uvedeny v každém záznamu stanzy. Podívejte se do jednotlivých popisů, chcete-li určit, kdy je možné použít také true (pravda) nebo false (nepravda).
242
IBM Tivoli Access Manager: Base: Administrativní příručka
Stanzy Označení stanz se objevuje v hranatých závorkách, jako např.: [jméno-stanzy]. Například stanza [ssl] v konfiguračním souboru ivmgrd.conf definuje nastavení konfigurace SSL pro server politik. Stanza [ldap] definuje nastavení konfigurace, které vyžaduje server politik, aby mohl komunikovat s registrem uživatelů LDAP. Každá stanza v konfiguračním souboru produktu Tivoli Access Manager obsahuje jeden nebo více párů klíč-hodnota, které obsahují informace, vyjádřené ve spárované sadě parametrů. Každý záznam stanzy má následující formát: klíč = hodnota
V konfiguračních souborech byste neměli měnit jména klíčů. Změna jména klíče může vést k nepředvídatelnému chování serverů. Všimněte si, že mezery okolo rovnítka (=) nejsou povinné, ale jejich používání se doporučuje. Výchozí instalace produktu Tivoli Access Manager nastaví mnoho předvolených hodnot. Některé hodnoty jsou statické a nikdy se nezmění. Jiné hodnoty je možné upravovat a tak přizpůsobit funkcionalitu a výkonnost serveru. V následujících popisech každé stanzy najdete seznam platných záznamů stanzy, skládajících se z párů klíč-hodnota. Záznam stanzy obsahuje popis předvoleného chování daného záznamu.
Dodatek A. Referenční informace ke konfiguraci serveru
243
stanza [authentication-mechanisms] Tento objekt stanza definuje knihovny, které mají být použité pro každou formu autentizace. Tivoli Access Manager podporuje pouze dvě formy (heslo a autentizaci pomocí certifikátu). Správci zdrojů, jako WebSEAL, mohou podporovat další formy. Konfigurační záznamy v této stanze potřebuje server, aby mohl komunikovat s registrem uživatelů. Můžete používat buď knihovnu registru URAF (User Registry Adapter Framework), a to buď Active Directory nebo Domino, nebo knihovnu registru LDAP. Záleží na typu registru uživatelů. Protože můžete zadat pouze jeden typ registru uživatelů, některé páry klíč-hodnota ve stanze [authentication-mechanisms] se vzájemně vylučují. passwd-ldap = plně_kvalifikovaná_cesta cert-ldap = plně_kvalifikovaná_cesta #passwd-uraf = plně_kvalifikovaná_cesta #cert-uraf = plně_kvalifikovaná_cesta
V tomto příkladu položky registru URAF jsou zakomentovány pomocí znaku #. Záznamy stanzy orientované na LDAP nejsou zakomentovány. Záznamy stanz pro konfiguraci registru uživatelů produktu Tivoli Access Manager jsou umístěny ve stanze [authentication-mechanism] v každém z těchto konfiguračních souborů: v ivmgrd.conf pro server politik pdmgrd v ivacld.conf pro autorizační server pdacld v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd v Váš konfigurační soubor správce zdrojů Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor pro vytvoření vašeho vlastního konfiguračního souboru správce zdrojů. Vývojáři plug-inů služeb by měli poskytnout standardní funkce. Než dokončíte plug-iny služeb, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference.
244
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [authentication-mechanisms] passwd-uraf = plně_kvalifikovaná_cesta Umístění knihovny, která se má použít pro autentizaci pomocí hesla. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je povinný, pokud jako registr uživatelů používáte registr URAF. Tyto hodnoty můžete ručně editovat. Není nutné používat žádný obslužný konfigurační program. Požadováno pouze, pokud registr uživatelů není LDAP. Adresáře a soubory podle platformy obsahují: v AIX: /opt/PolicyDirector/lib/liburafauthn.a v HP: /opt/PolicyDirector/lib/liburafauthn.sl v Sun: /opt/PolicyDirector/lib/liburafauthn.so v Linux: /opt/PolicyDirector/lib/liburafauthn.so v Windows: instalační_adresář\bin\urafauthn.dll Předvolené hodnoty jsou závislé na serveru. Například pro Windows: passwd-uraf = C:\Program Files\Tivoli\Policy Director\bin\urafauthn.dll & -cfgfile [C:/pd/etc/jméno_serveru.conf] cert-uraf = plně_kvalifikovaná_cesta Umístění knihovny, která se má použít pro autentizaci pomocí certifikátů. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je povinný, pokud jako registr uživatelů používáte registr URAF. Tyto hodnoty můžete ručně editovat. Není nutné používat žádný obslužný konfigurační program. Požadováno pouze, pokud registr uživatelů není LDAP. Adresáře a soubory podle platformy obsahují: v AIX: /opt/PolicyDirector/lib/liburafcertauthn.a v HP: /opt/PolicyDirector/lib/liburafcertauthn.sl v Solaris: /opt/PolicyDirector/lib/liburafauthn.so v Linux: /opt/PolicyDirector/lib/liburafcertauthn.so v Windows: instalační_adresář\bin\urafcertauthn.dll Předvolené hodnoty jsou závislé na serveru. Příklad pro Windows: cert-ldap = C:\Program Files\Tivoli\Policy Director\bin\certauthn.dll & -cfgfile [C:/pd/etc/jméno_serveru.conf]
Dodatek A. Referenční informace ke konfiguraci serveru
245
passwd-ldap = plně_kvalifikovaná_cesta Umístění knihovny, která se má použít pro autentizaci LDAP pomocí hesla. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je povinný, pokud jako registr uživatelů používáte LDAP. Tyto hodnoty můžete ručně editovat. Není nutné používat žádný obslužný konfigurační program. Adresáře a soubory podle platformy obsahují: v AIX: /opt/PolicyDirector/lib/libldapauthn.a v HP: /opt/PolicyDirector/lib/libldapauthn.sl v Solaris: /opt/PolicyDirector/lib/libldapauthn.so v Linux: /opt/PolicyDirector/lib/libldapauthn.so v Windows: instalační_adresář\bin\ldapauthn.dll Předvolené hodnoty jsou závislé na serveru. Příklad pro Solaris: passwd-ldap = /opt/PolicyDirector/lib/libldapauthn.so & -cfgfile [/opt/PolicyDirector/etc/jméno_serveru.conf] cert-ldap = plně_kvalifikovaná_cesta Umístění knihovny, která se má použít pro autentizaci LDAP pomocí certifikátů. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je povinný, pokud jako registr uživatelů používáte LDAP. Tyto hodnoty můžete ručně editovat. Není nutné používat žádný obslužný konfigurační program. Adresáře a soubory podle platformy obsahují: v AIX: /opt/PolicyDirector/lib/libcertauthn.a v HP: /opt/PolicyDirector/lib/libcertauthn.sl v Solaris: /opt/PolicyDirector/lib/libcertauthn.so v Linux: /opt/PolicyDirector/lib/libcertauthn.so v Windows: instalační_adresář\bin\certauthn.dll Předvolené hodnoty jsou závislé na serveru. Příklad pro Solaris: cert-ldap = /opt/PolicyDirector/lib/libcertauthn.so & -cfgfile [/opt/PolicyDirector/etc/jméno_serveru.conf]
246
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [aznapi-admin-services] Plug-in služby administrativy umožňuje aplikacím provádět úlohy administrativy specifické pro aplikaci. Plug-in služby administrativy je zpřístupněný voláním aplikace používající jedeno z rozhraní administrativy Tivoli Access Manager. Volající aplikace může být buď obslužný program administrativy jako příkaz pdadmin produktu Tivoli Access Manager nebo rozhraní Web Portal Manager produktu Tivoli Access Manager. Volající aplikace může být také aplikace na objednávku, která používá API administrativy Tivoli Access Manager. Administrativní služba namapuje volání administrativního rozhraní API na odpovídající volání administrativního rozhraní API a provede požadovanou akci. Každý plug-in program administrativní služby je samostatný modul, který je dynamicky načten do autorizační služby. Parametry pro konfiguraci plug-inů služeb administrativy Tivoli Access Manager jsou uveřejněné v objektu stanza [aznapi-admin-services] těchto konfiguračních souborů poskytovaných Tivoli Access Manager: v ivmgrd.conf pro server politik pdmgrd, v ivacld.conf pro autorizační server pdacld, v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd, v váš konfigurační soubor správce zdrojů pro konfigurované plug-iny služeb administrativy. Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor pro vytvoření vašeho vlastního konfiguračního souboru správce zdrojů. Vývojáři plug-inů služeb by měli poskytnout standardní funkce. Než dokončíte plug-iny služeb, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference.
Dodatek A. Referenční informace ke konfiguraci serveru
247
stanza [aznapi-admin-services] id-služby = {krátké_jméno|cesta_k_dll} [-pobj jméno_hierarchie_chráněných_objektů ] [& parametry] Definuje službu autorizačního rozhraní API pro funkce, které dovolují plug-in programu získávat obsah nadefinované části hierarchie chráněného objektu, nebo které dovolují plug-in programu nadefinovat administrativní úlohy specifické pro aplikaci, které také vrací příkazy, které tyto úlohy provádí. Každý záznam stanzy definuje jiný typ služby aznAPI, a každý záznam má stejný formát, ve kterém: id-služby Vývojářem určená identifikace (ID) administrativní služby. Aplikace autorizačního rozhraní API může zaregistrovat více než jeden plug-in program administrativní služby, ale každý musí mít své jedinečné ID služby. {krátké_jméno|cesta_k_dll} Cesta ke knihovně DLL (Dynamic Link Library), která obsahuje spustitelný kód služby. Je-li knihovna DLL umístěna v adresáři, ve kterém systém obvykle hledá knihovny DLL (například /usr/lib na platformách UNIX, nebo %PATH% na Windows NT), nemusíte uvádět plně kvalifikované jméno ke knihovně DLL, ale pouze jméno knihovny DLL. Pokud chcete používat jméno knihovny DLL nezávislé na platformě, aby mohla být načtena každou podporovanou platformou produktu Tivoli Access Manager, zadejte jméno knihovny v krátkém tvaru. Pro každou platformu je krátké jméno přidané před a známé předpony a přípony knihoven jsou připojené za; hledá se každá možnost. Použijete-li například jméno knihovny v krátkém tvaru azn_ent_user, pak pro každou platformu se budou automaticky hledat následující jména: NT: AIX: Solaris: HP/UX:
jméno_hierarchie_chráněných_objektů Hierarchické jméno chráněného objektu je volitelný parametr. Tento parametr se odkazuje buď na jméno prostoru chráněných objektů (hierarchie), nebo prostě jen na chráněný objekt. Jména hierarchií chráněných objektů musí být pro každý plug-in program administrativní služby jedinečná v rámci aplikace autorizačního rozhraní API. Více instancí aplikace autorizačního rozhraní API však mohou zaregistrovat služby ke stejným jménům hierarchií chráněných objektů, které budou provádět podporu administrativy prostoru objektů přepnutí při selhání v případě, že některý ze serverů aplikace autorizačního rozhraní API selže. parametry Volitelně mohou být do externí autorizační služby předávány další inicializační informace ve tvaru argumentů. Argumenty musí uvádět ampersand (například & -server fred). Autorizační služba nezpracovává znaky umístěné za ampersandem &. Toto předá své znaky přímo do plug-inu služby administrativy. Definice služby je podrobněji probírána v knize IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad: AZN_ADMIN_SVC_TRACE = pdtraceadmin
248
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [aznapi-configuration] Produkt Tivoli Access Manager umožňuje velmi pružný přístup k autorizaci, a to díky použití autorizačního rozhraní API. Autorizační rozhraní API založené na standardech umožňuje aplikacím, aby volaly centralizovanou autorizační službu. Tivoli Access Manager poskytuje vestavěnou podporu jména uživatele a autentizačního hesla také skrz autorizační API. Všimněte se, že konfigurační pár hodnota-klíč použitý pro konfiguraci přejatých monitorovacích souborů serveru Tivoli Access Manager je umístěný v objektu stanza [aznapi-configuration] každého z těchto konfiguračních souborů: v ivmgrd.conf pro server politik pdmgrd, v ivacld.conf pro autorizační server pdacld, v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd, v konfigurační soubory vašeho správce zdrojů. Další záznamy objektů stanza, které se vztahují ke konfiguračním souborům vašeho správce zdrojů, jsou probírané v publikaci IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Vývojáři by si měli přečíst a dobře pochopit koncepty v této knize, aby poskytli požadované standardní funkce. Ukázkový konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager, aby byl použit jako průvodce, jak vytvořit váš vlastní konfigurační soubor správce zdrojů. stanza [aznapi-configuration] mode = {local|remote} Operační režim pro správce zdrojů. Tuto hodnotu nelze změnit po konfiguraci správce zdrojů. Poznámka: Tento záznam objektu stanza je nastavený během konfigurace; neměňte jej. Platné hodnoty zahrnují: local Správce zdrojů používá lokální paměť cache politik. remote Správce zdrojů používá vzdálenou paměť cache politik udržovanou autorizovaným serverem (pdacld). Některé atributy konfigurace se týkají pouze správců zdrojů konfigurovaných pro použití režimu local (lokální). Tento záznam stanzy je povinný. Předvolená hodnota: local Příklad: mode = remote db-file = plně_kvalifikovaná_cesta Jméno a umístění souboru paměti cache databáze politik správců zdrojů. Tuto hodnotu musíte uvést a každý server poskytuje vlastní hodnotu. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Neexistují žádné předvolené hodnoty. Příklad pro Windows: db-file = C:\pd\db\ivacld.db Příklad zobrazující relativní cestu: db-file = ./authzn_demo.db cache-refresh-interval = {disable|default|počet_vteřin} Dodatek A. Referenční informace ke konfiguraci serveru
249
Interval výzvy (v sekundách) mezi kontrolami aktualizace hlavní databáze politik autorizace. Poznámka: Lokální paměť cache je obnovena pouze tehdy, pokud byla detekována aktualizace. Platné hodnoty zahrnují: disable Hodnota intervalu ve vteřinách není nastavena. default Použije se předvolená hodnota 600 vteřin. počet_vteřin Přesný časový interval, který nastavíte uvedením počtu sekund. Platný rozsah je od 0 do velikosti nezapsaného celého čísla, které je asi do 136 let. Tento záznam objektu stanza není použitý v souboru ivmgrd.conf, protože teto server má své vlastní záznamy objektů stanza pro uvedení hlavní cesty hlavní databáze politik autorizace. Tento záznam stanzy je volitelný. Předvolená hodnota: default Příklad: cache-refresh-interval = 500 listen-flags = {enable|disable} Určení, zda se má zapnout nebo vypnout přijímání upozornění o aktualizaci paměti cache pro politiky. Platné hodnoty zahrnují: enable Aktivuje program pro naslouchání aktualizacím. disable Vypíná program pro naslouchání aktualizacím. Tento záznam stanzy je volitelný. Předvolená hodnota: disable Příklad: listen-flags = enable policy-cache-size = velikost Maximální velikost paměti cache politiky v paměti. Tuto velikost lze konfigurovat. Paměť cache se skládá z politiky a vztahů mezi politikou a zdroji. Informace, že zdroj nemá žádnou přímo přidruženou politiku, je také v paměti cache. Maximální velikost paměti cache souvisí s počtem definovaných objektů politik a počtem chráněných zdrojů stejně jako dostupné paměti. Rozumný algoritmus, se kterým začít: (počet objektů politik * 3) + (počet chráněných zdrojů * 3) Tato hodnota kontroluje, kolik informací je uloženo v paměti cache. Větší paměť cache může vylepšit výkon aplikace, ale používá také přídavnou paměť. Platné hodnoty jsou: velikost Velikost je uvedená jako počet záznamů. Tento záznam stanzy je volitelný. Předvolená hodnota: 32768 Příklad: policy-cache-size = 32768
250
IBM Tivoli Access Manager: Base: Administrativní příručka
azn-app-host = jiný-hostitel Atribut uvádí jméno hostitele, které by server politik měl použít při komunikaci se správcem zdrojů. V hodnotě jiný-hostitel můžete zadat libovolné platné internetové jméno hostitele. Pokud neuvedete tento atribut, použije se předvolené jméno hostitele. Příklady platných jmen hostitelů: v mycomputer.city.company.com v mycomputer Standardně je tento atribut zakázán. Je-li zakázán, záznam stanzy je v konfiguračním souboru zakomentován pomocí znaku # na začátku záznamu stanzy. Například: #azn-app-host = libra Chcete-li aktivovat tuto hodnotu, odkomentujte záznam v konfiguračním souboru odstraněním znaku komentáře (#). Ujistěte se, že jste zahrnuli hodnotu hostitelského jména. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad: azn-app-host = libra.dallas.ibm.com cred-attributes-entitlement-services = {služba_nároků_krátkého_jména|cesta_k_dll} Služba, která poskytuje schopnost přidat vnější informace pro pověření uživatele v formě atributů pověření a která umožňuje aplikaci používat tyto informace při provádění rozhodnutí o přístupu. Tyto rozšířené atributy jsou uložené v registru uživatelů. Tato služba může také pracovat s atributy používajícími volání API. Seznam ID služeb nároků autorizační API je požadovaný rozhraním azn_id_get_creds(), aby bylo možné kompilovat seznam atributů, které mají být přidané k pověření uživatele během výstavby pověření. Dynamické obchodní nároky (příznak/hodnota) už není třeba zavádět s použitím modulu autentizačních služeb v WebSEAL, ani nejsou omezené pouze na registr uživatelů LDAP. Seznam ID služeb, které lze nalézt s objektem stanza [aznapi-entitlement-services], jsou dotazované pro kompilaci seznamu atributů. Atributy jsou přidané k pověření uživatelů během výstavby pověření. Každé ID služeb je dotazované v pořadí, ve kterém je uvedené na tomto seznamu. Navrácený atribut je vložený do seznamu atributů pověření každého vystavěného pověření. Například: cred-attribute-entitlement-services = myEntSvcID cred-attribute-entitlement-services = myOtherEntSvcID Poznámka: Nemůžete použít tento záznam objektu stanza pro přepis atributů pouze ke čtení v seznamu atributů pověření, který zahrnuje jméno objektu, UUID objektu a další. Výjimkou pro toto pravidlo je atribut azn_cred_groups. Publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference vypisuje atributy pouze ke čtení, obsahuje více informací o této službě a vysvětluje, proč by se administrátoři, kteří nechtějí tuto schopnost, měli ujistit, že služba azn_mod_rad není aplikací zavedená. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad: cred-attribute-entitlement-services = myEntSvcID
Dodatek A. Referenční informace ke konfiguraci serveru
251
azn-server-name = server–jméno_hostitele Jedinečné jméno serveru správce zdrojů Tivoli Access Manager buď pdmgrproxyd, pdacld nebo pdmgrd, které je konfigurované v této doméně. Znak pomlčka (–) je třeba uvést. Poznámka: Jméno hostitele je generované a nastavené během konfigurace. Needitujte tento záznam objektu stanza. Hodnota server–jméno_hostitele představuje alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Minimální a maximální délky jména, pokud taková omezení existují, jsou určena příslušným registrem. Tento záznam stanzy je volitelný. Předvolená hodnota je závislá na serveru. Příklad: azn-server-name = ivacld–libra pd-user-name = jméno_serveru/jméno_hostitele Uživatelský účet Tivoli Access Manager pro server správce zdrojů, buď pdmgrproxyd, pdacld nebo pdmgrd, který je konfigurované v této doméně. Znak lomítko po směru (/) je třeba uvést. Poznámka: Jméno serveru/uživatelské jméno je generované a nastavené během konfigurace. Needitujte tento záznam objektu stanza. Hodnota jméno_serveru/jméno_hostitele představuje alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Minimální a maximální délky jména, pokud taková omezení existují, jsou určena příslušným registrem. Příklady platných jmen hostitelů: v mycomputer.city.company.com v mycomputer Tento záznam stanzy je volitelný. Předvolená hodnota je závislá na serveru. Příklad: pd-user-name = ivacld/libra pd-user-pwd = heslo_serveru Heslo uživatelského účtu Tivoli Access Manager pro server správce zdrojů, buď pdmgrproxyd, pdacld nebo pdmgrd, které je konfigurované v doméně. Poznámka: Heslo serveru je generované a nastavené během konfigurace. Needitujte tento záznam objektu stanza. Heslo pro server Tivoli Access Manager. Tento záznam stanzy je volitelný. Předvolená hodnota je vygenerována; neměňte ji. Příklad: pd-user-pwd = zs77WVoLSZn1rKr
252
IBM Tivoli Access Manager: Base: Administrativní příručka
permission-info-returned = {atribut1 atribut2 ...} Sada atributů, kterou chce volající obdržet od funkce azn_decision_access_allowed_ext( ) v seznamu atributů informací o oprávněních. Před použitím tohoto příznaku a hodnoty záznamu objektu stanza si přečtěte a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Můžete také definovat své vlastní atributy. Například, můžete nastavit atribut na ACL s použitím volby upravit nastavení atributů acl příkazu pdadmin. Pokud přidáte jméno atributu do seznamu, tento bude navrácený pouze jako informace o oprávnění, je-li použitelný pro aktuální volání o rozhodnutí. Chcete-li získat více informací o seznamu řetězců rozeznaných autorizačním jádrem, viz publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Tento záznam stanzy je volitelný. Předvolená hodnota: Žádná informací se nenavrátí. Příklad pro navrácení ifnormace o oprávnění pro všechny atributy v seznamu: permission-info-returned = azn_perminfo_all_attrs resource-manager-provided-adi = prefix Prefix, který autorizační jádro používá pro zjištění sady chybících informací o rozhodnutí o přístupu (ADI) poskytovaných správcem zdrojů. Abyste uvedli více než jeden prefix, přidejte více záznamů objektů stanza. Tyto záznamy musí odkazovat na existující služby nároků, které byly zavedené s použitím záznamů služby v konfiguračním objektu stanza [aznapi-entitlement-services] nebo inicializačních atributech. Je-li nalezena ADI, která má chybět během vyhodnocování pravidel, každá služba v tomto seznamu je dotazovaná v definovaném pořadí. Záznam objektu stanza prefixu používá řetězový prefix pro svou hodnotu. Například, chcete-li oznámit autorizačnímu jádru, že libovolné ADI začínající sales_customer_ by měly být poskytnuté aplikací správce zdrojů, záznam objektu stanza by byl: resource-manager-provided-adi = sales_customer_ Chcete-li získat více informací o zpracování pravidel, viz “resource-manager-provided-adi” na stránce 115. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad pro více záznamů objektů stanza: resource-manager-provided-adi = sales_item_ resource-manager-provided-adi = sales_customer_
Dodatek A. Referenční informace ke konfiguraci serveru
253
dynamic-adi-entitlement-services = služba_nároků Služby nároků vyvolání dynamické ADI. Služba_nároků je hodnota řetězce pro jména zásobníků požadované ADI. Seznam ID služeb nároků konfiguračních autorizačních API je dotazován jádrem autorizačních pravidel, je-li chybějící ADI detekována během vyhodnocení autorizačních pravidel. Je-li zjištěna nepřítomnost ADI během vyhodnocení pravidel, každá služba v tomto seznamu je dotazovaná v pořadí definovaném v tomto záznamu. Tyto záznamy objektu stanza musí odkazovat na existující služby nároků. ID služeb (například bank_A_ADI) jsou zavedené s použitím záznamů služeb v konfiguračním objektu stanza [aznapi-entitlement-services] služeb nároků nebo v inicializačním atributu. Chcete-li získat více informací o zpracování pravidel a současně o této službě, viz “dynamic-adi-entitlement-services” na stránce 115 a publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad: [aznapi-entitlement-services] dynamic-adi-entitlement-services = bank_A_ADI dynamic-adi-entitlement-services = bank_B_ADI input-adi-xml-prolog = atributy_prologu Prolog, který má být přidán na horní část dokumentu XML, který je vytvořený s použitím ADI (Access Decision Information) potřebné pro vyhodnocení autorizačních pravidel Boolean. Je-li uvedený prolog stylového papíru, tento prolog bude importovaný do prázdného stylového papíru. Není-li prolog uvedený, bude místo toho použitá předvolená hodnota prologu. Všechny s požadovaných atributů prologu jsou uvedené v předvolených záznamech prologu. Poznámka: Jsou-li libovolné z těchto atributů změněné nebo vynechané ze záznamu, potom se autorizačnímu klientu nepodaří spustit a bude navrácená chyba. Platné hodnoty atributy_prologu jsou atributy prologu, které jsou požadované autorizačním jádrem a zahrnují: Chcete-li získat více informací, viz “input-adi-xml-prolog a xsl-stylesheet-prolog” na stránce 116. Tento záznam stanzy je volitelný. Příklad: input-adi-xml-prolog =
254
IBM Tivoli Access Manager: Base: Administrativní příručka
xsl-stylesheet-prolog = atributy_prologu Prolog, který má být přidán do horní části stylového papíru XSL, který se vytvoří s použitím textu XSL, který definuje autorizační pravidlo Boolean. Platné hodnoty atributy_prologu jsou atributy prologu, které jsou požadované autorizačním jádrem. Je-li uvedený prolog stylového papíru, tento prolog bude importovaný do prázdného stylového papíru. Není-li prolog uvedený, bude místo toho použitá předvolená hodnota prologu. Všechny s požadovaných atributů prologu jsou uvedené v předvolených záznamech prologu. Není-li uvedený, předvolený prolog stylového papíru XSL je: !<-- Required for XSLT language --> <xsl:stylesheet xmlns:xsl= "http://www.w3.org/1999/XSL/Transform" version="1.0"> !<-- Required to constrain output of rule evaluation --> <xsl:output method="text" omit-xml-declaration="yes" encoding=’UTF-8’ indent="no" /> !<-- Need this to ensure default text node printing is off --> <xsl:template match="text()">
Poznámka: Je-li libovolný z těchto atributů změněný nebo vynechaný ze záznamu, potom se autorizačnímu klientu nepodaří spustit a bude navrácená chyba. Při změně tohoto nastavení použijte výstrahu. Chcete-li získat více informací, viz “input-adi-xml-prolog a xsl-stylesheet-prolog” na stránce 116. Tento záznam stanzy je volitelný. Chcete-li získat kompletní vysvětlení příkladu prostoru jmen, viz “Definování prostoru jmen XML” na stránce 106.
Dodatek A. Referenční informace ke konfiguraci serveru
255
audit-attribute = atribut-azn Jméno atributu ADI pro audit. Atribut může zavést prokazatelnost přístupu poskytnutím informací, aby tak pomohl označit možné neoprávněné přístupy přínosů. Můžete udělit nebo odmítnout přístup založený na pravidlech, které se týkají atributů. Například, funkce autentizace switch-user (přepnout uživatele) WebSEAL poskytuje mechanismus, který umožňuje určitým uživatelům vtělit se do jiného uživatele. Pokud je použita funkce switch-user, požadavek o autorizaci je vyhodnocený spíše proti předpokládané identitě než proti momentální identitě uživatele. Je vhodné, aby bylo administrátorům umožněno zachytit momentální identitu uživatele. Můžete monitorovat jména nebo popisy politik Tivoli Access Manager (ACL, POP a autorizační pravidlo), které jsou použité pro objekt, do kterého je právě vytvořený přístup. Hodnota atributu autorizační API (atribut_azn) představuje alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí místního nastavení kódů. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad pro WebSEAL: logaudit = yes auditlog = audit.log auditcfg = azn audit-attribute = tagvalue_su-admin logcfg = kategorie:[{stdout|stderr|file|pipe|remote}][[parametr[=hodnota]][parametr[=hodnota]]] Umožní přihlášení a monitorování do aplikace. Parametry kategorie, místo určení a jiné jsou použité pro zachycení událostí monitorování a přihlášení Tivoli Access Manager. Každý server provádí vlastní nastavení protokolování ve svém konfiguračním souboru. Platné hodnoty zahrnují: kategorie:agent-protokolu Kategorie události monitorování. Také indikuje, že místo určení, kde agent-protokolu je jeden z hodnotstdout, stderr, file, pipe nebo remote. Například: audit.azn:file parametr=hodnota Přípustné parametry. Parametry se liší v závislosti na kategorii, cíli událostí a typů monitorování, které chcete provádět. Například: hi_water = počet Chcete-li získat více informací o agentech protokolů a konfiguračních parametrech, viz Kapitola 19, “Zachycení protokolovaných a monitorovaných událostí”, na stránce 197. Tento záznam stanzy je volitelný. Odstraňte znaky komentáře (#) na začátcích řádků konfiguračních souborů, abyste umožnili autentizace nebo autorizační monitorování (nebo obojí) pro aplikaci. Předvolená hodnota: #logcfg = audit.azn:file path=audit.log,flush_interval=20, log_id=audit_log #logcfg = audit.authn:file log_id=audit_log
256
IBM Tivoli Access Manager: Base: Administrativní příručka
logaudit = {yes|true|no|false} Ukazuje, jestli se má provést přejaté monitorování. Platné hodnoty zahrnují: yes|true Přejaté monitorování je aktivované (zapnuté). no|false Přejaté monitorování je zablokované (vypnuté). Předvolená hodnota: no. Avšak, předvolená hodnota je závislá na serveru. Je-li logaudit = yes, musíte také nastavit auditlog a auditcfg. Příklad pro Windows: logaudit = yes auditlog=C:\pd\audit\pdacld.log auditcfg = azn auditcfg = {azn|authn|mgmt|http} Zachycení událostí konfigurace protokolování přejatého auditu Abyste umožnili záznamy auditu specifické pro komponenty, přidejte nebo odstraňte odpovídající definici. Každý server poskytuje vlastní hodnotu ve svém konfiguračním souboru. Například předvolené chování aznAPI.conf je azn; předvolené chování pdacld.conf je také azn. Současně můžete používat více než jednu hodnotu auditcfg. Zakomentujte záznamy stanz, které nechcete používat. Chcete-li zakomentovat záznam stanzy, začněte záznam znakem #. Například: auditcfg = azn auditcfg = authn #auditcfg = mgmt Platné hodnoty pro typ události k monitorování zahrnují: azn Zachycuje autorizační události. authn Zachycuje autentizační události. mgmt Zachycuje události serveru politik. http Zachycuje události HTTP WebSEAL. Chcete-li získat více informací o této hodnotě, viz publikaceIBM Tivoli Access Manager for e-business WebSEAL: Administrativní příručka. Tento záznam stanzy je povinný, pokud je zadáno logaudit = yes.Musíte nastavit také auditlog. Neexistují žádné předvolené hodnoty. Hodnota závisí na typu události, kterou chcete monitorovat: Příklad pro Windows; monitorování autorizačních událostí pro autorizační server pdacld: logaudit = yes auditlog=C:\pd\audit\pdacld.log auditcfg = azn
Dodatek A. Referenční informace ke konfiguraci serveru
257
auditlog = plně_kvalifikovaná_cesta Jméno a umístění přejatého souboru monitorování pro lokálního klienta. Pokud neuvedete jméno a umístění, monitorování nebude prováděno. Každý server provádí vlastní nastavení prověřovacích záznamů ve svém konfiguračním souboru. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je volitelný. Je-li logaudit = yes, musíte nastavit také auditcfg. Jméno souboru protokolu je závislé na serveru. Předvolené umístění instalace pro Windows: C:\instalační_cesta_pd\audit\jméno_serveru.log Předvolené instalační umístění pro UNIX: auditlog = /var/PolicyDirector/audit/jméno_serveru.log Příklad pro Windows pro server politik pdmgrd: logaudit = yes auditlog = C:\pd\audit\pdmgrd.log auditcfg = azn logsize = {0 | záporný_počet_bajtů | počet_bajtů} Prahová hodnota obnovy souboru protokolu (v bajtech) pro přejaté protokoly monitorování. Když soubor prověřovacích záznamů dosáhne této prahové hodnoty, tak se původní soubor prověřovacích záznamů přejmenuje a vytvoří se nový soubor protokolu s původním jménem. Platné hodnoty zahrnují: 0 Nula indikuje, že se vyskytla obnova, ale nevytvořily se žádné její soubory. záporný_počet_bajtů Záporné číslo znamená, že se soubory budou cyklicky přetáčet každý den bez ohledu na velikost. počet_bajtů Maximální velikost (v bajtech) souboru prověřovacích záznamů před provedením cyklické obnovy. Přípustný rozsah je od 1 bajtu do 2 megabajtů. Tento záznam stanzy je volitelný. Předvolená hodnota je závislá na serveru. Příklad: logsize = 2000000.
258
IBM Tivoli Access Manager: Base: Administrativní příručka
logflush = počet_vteřin Časový interval (v sekundách) mezi zarovnáním protokolů vyrovnávacích pamětí souboru protokolu pro přejaté protokoly monitorování. Platné hodnoty zahrnují: počet_vteřin Počet vteřin povolených mezi vyrovnáním protokolů. Platný rozsah je od 1 vteřiny do 6 hodin. Pokud uvedete záporné číslo, pak se jeho absolutní hodnota použije k určení okamžiku, kdy má být provedeno zarovnání souborů prověřovacích záznamů. Tento záznam stanzy je volitelný. Předvolená hodnota je závislá na serveru. Příklad: logflush = 20.
Dodatek A. Referenční informace ke konfiguraci serveru
259
stanza [aznapi-cred-modification-services] Plug-in program služby pro úpravu pověření dovoluje aplikacím autorizačního rozhraní API provádět úpravy v pověření produktu Tivoli Access Manager. Služba pro úpravu pověření může pak toto upravené pověření vrátit volající aplikaci k dalšímu použití. Aplikace mohou tuto službu používat k přidání dalších informací do pověření uživatele. Tyto dodatečné informace mohou například obsahovat číslo kreditní karty uživatele a limit kreditu uživatele. Každý plug-in program služby pro úpravu pověření je samostatný modul, který je dynamicky načten do autorizační služby. Parametry pro konfiguraci plug-inů služeb modifikací pověření produktu Tivoli Access Manager jsou deklarované v objektu stanza [aznapi-cred-modification-services] každého z konfiguračních souborů poskytovaných produktem Tivoli Access Manager: v ivmgrd.conf pro server politik pdmgrd, v ivacld.conf pro autorizační server pdacld, v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd, v konfigurační soubory vašeho správce zdrojů pro konfigurované plug-iny služeb modifikací pověření. Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor pro vytvoření vašeho vlastního konfiguračního souboru správce zdrojů. Vývojáři plug-inů služeb by měli poskytnout standardní funkce. Než dokončíte plug-iny služeb, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference.
260
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [aznapi-cred-modification-services] id-služby = krátké_jméno|cesta_k_dll [ & parametry ... ] Definuje službu autorizačního rozhraní API pro službu úpravy seznamu atributů pověření. Každý záznam stanzy definuje jiný typ služby aznAPI a každý záznam má stejný formát, ve kterém: id-služby Vývojářem určená identifikace (ID) služby pro úpravu pověření. Řetězec ID služby musí být jedinečný. {krátké_jméno|cesta_k_dll} Cesta ke knihovně DLL (Dynamic Link Library), která obsahuje spustitelný kód služby. Je-li knihovna DLL umístěna v adresáři, ve kterém systém obvykle hledá knihovny DLL (například /usr/lib na platformách UNIX, nebo %PATH% na Windows NT), nemusíte uvádět plně kvalifikované jméno ke knihovně DLL, ale pouze jméno knihovny DLL. Pokud chcete používat jméno knihovny DLL nezávislé na platformě, aby mohla být načtena každou podporovanou platformou produktu Tivoli Access Manager, zadejte jméno knihovny v krátkém tvaru. Ke krátkému jménu je připojený prefix známé knihovy a sufix pro každou platfotmu; hledá se každá možnost. Použijete-li například jméno knihovny v krátkém tvaru azn_ent_user, pak pro každou platformu se budou automaticky hledat následující jména: NT: AIX: Solaris: HP/UX:
parametry Volitelně můžete zadat parametry, které budou předány do služby, jakmile bude tato inicializována aznAPI. Všechna data, která následují v řetězci za znakem ampersand (&), se považují za parametry. Definice služby je podrobněji probírána v publikaciIBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad: AZN_MOD_SVC_RAD_2AB = azn_mod_rad
Dodatek A. Referenční informace ke konfiguraci serveru
261
stanza [aznapi-entitlement-services] Plug-in program služby nároků dovoluje aplikacím autorizačního rozhraní API načítat nároky uživatele z interní objektové databáze nároků. Každý plug-in program služby nároků je samostatný modul, který je dynamicky načten do autorizační služby. Záznamy objektů stanza pro konfiguraci plug-inů služeb nároků Tivoli Access Manager jsou vyjádřeny ve stanze [aznapi-entitlement-services] každého z těchto konfiguračních souborů poroduktu Tivoli Access Manager: v v v v
ivmgrd.conf pro server politik pdmgrd, ivacld.conf pro autorizační server pdacld, pdmgrproxyd.conf pro proxy server politik pdmgrproxyd, konfigurační soubor vašeho správce zdrojů pro konfigurované plug-iny služeb nároků.
Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor pro vytvoření vašeho vlastního konfiguračního souboru správce zdrojů. Vývojáři plug-inů služeb by měli poskytnout standardní funkce. Než dokončíte plug-iny služeb, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference.
262
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [aznapi-entitlement-services] id-služeb = {krátké_jméno|cesta_k_dll} [ & parametry ... ] Definuje službu autorizačního rozhraní API pro službu nároků chráněných objektů. Každý záznam stanzy definuje jiný typ služby aznAPI a každý záznam má stejný formát, ve kterém: id-služby Vývojářem určená identifikace (ID) služby, pomocí které může klient aznAPI tuto službu identifikovat. Řetězec ID služby musí být jedinečný. {krátké_jméno|cesta_k_dll} Cesta ke knihovně DLL (Dynamic Link Library), která obsahuje spustitelný kód služby. Je-li knihovna DLL umístěna v adresáři, ve kterém systém obvykle hledá knihovny DLL (například /usr/lib na platformách UNIX, nebo %PATH% na Windows NT), nemusíte uvádět plně kvalifikované jméno ke knihovně DLL, ale pouze jméno knihovny DLL. Pokud chcete používat jméno knihovny DLL nezávislé na platformě, aby mohla být načtena každou podporovanou platformou produktu Tivoli Access Manager, zadejte jméno knihovny v krátkém tvaru. Ke krátkému jménu je připojený prefix známé knihovny a sufix pro každou platformu; hledá se každá možnost. Použijete-li například jméno knihovny v krátkém tvaru azn_ent_user, pak pro každou platformu se budou automaticky hledat následující jména: NT: AIX: Solaris: HP/UX:
parametry Volitelně můžete zadat jeden nebo více parametrů, které budou předány do služby, jakmile bude tato inicializována aznAPI. Všechna data, která následují v řetězci za znakem ampersand (&), se považují za parametry. Definice služby je podrobněji probírána v publikaci IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad: credattrs_ent_svc = azn_ent_cred_attrs
Dodatek A. Referenční informace ke konfiguraci serveru
263
stanza [aznapi-external-authzn-services] Plug-in program externí autorizační služby je volitelným rozšířením autorizační služby produktu Tivoli Access Manager, které vám umožňuje zavést další řízení a podmínky autorizace. Plug-in program externí autorizační služby můžete používat k vynucení toho, aby rozhodnutí o autorizaci byla prováděna na základě kritérií specifických pro aplikaci, která nejsou známa autorizační službě produktu Tivoli Access Manager. Každý plug-in program externí autorizační služby je samostatný modul, který je dynamicky načten do autorizační služby. Parametry pro konfiguraci plug-inů vnějších autorizačních služeb Tivoli Access Manager deklarovaných v objektu stanza [aznapi-external-authzn-services] těchto konfiguračních souborů poskytovaných Tivoli Access Manager: v ivmgrd.conf pro server politik pdmgrd, v ivacld.conf pro autorizační server pdacld, v konfigurační soubor vašeho správce zdrojů pro konfigurované plug-iny externích autorizačních služeb. Konfigurační soubor aznAPI.conf je poskytovaný s Tivoli Access Manager jako ukázkový soubor pro vytvoření vašeho vlastního konfiguračního souboru správce zdrojů. Vývojáři plug-inů služeb by měli poskytnout standardní funkce. Než dokončíte plug-iny služeb, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference.
264
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [aznapi-external-authzn-services] spouštěč-politiky = {krátké_jméno|cesta_k_dll} [ & parametry ... ] Definuje službu autorizačního rozhraní API pro definice externí autorizační služby, které vynucují, aby rozhodnutí o autorizaci byla prováděna na základě kritérií specifických pro aplikaci. Každý záznam stanzy definuje jiný typ služby aznAPI, a každý záznam má stejný formát, ve kterém: spouštěč-politiky Spouštěč politiky je prostředek, pomocí kterého prostředek autorizace vyvolá externí autorizační službu. Jde buď o ID služby nebo o řetězec akce přístupového seznamu (ACL). Může to být například má_služba_1 nebo Trx. Je-li tato služba nadefinována spolu s ID služby, pak se ID služby použije jako rozšířený atribut politiky POP, který bude spouštět externí autorizační službu, kdykoliv bude mít tuto politiku POP objekt připojen. Je-li služba nadefinována spolu s řetězcem akce ACL, pak služba bude vyvolána, kdykoliv bude v procesu rozhodnutí o autorizaci vyvolána tato maska akce ACL. Spouštěč-politiky může být libovolný řetězec, který bude rozeznáván jako platné jméno klíče. Řetězec spouštěč-politiky je citlivý na velikost písmen pro definici sady akcí, protože akce samotné jsou citlivé na velikost písmen. Spouštěč-politiky není však citlivý na velikost písmen, pokud je spouštěč atributem politiky POP. {krátké_jméno|cesta_k_dll} Cesta ke knihovně DLL (Dynamic Link Library), která obsahuje spustitelný kód služby. Je-li knihovna DLL umístěna v adresáři, ve kterém systém obvykle hledá knihovny DLL (například /usr/lib na platformách UNIX, nebo %PATH% na Windows NT), nemusíte uvádět plně kvalifikované jméno ke knihovně DLL, ale pouze jméno knihovny DLL. Pokud chcete používat jméno knihovny DLL nezávislé na platformě, aby mohla být načtena každou podporovanou platformou produktu Tivoli Access Manager, zadejte jméno knihovny v krátkém tvaru. Ke krátkému jménu je připojený prefix známé knihovny a sufix pro každou platformu; hledá se každá možnost. Použijete-li například jméno knihovny v krátkém tvaru azn_ent_user, pak pro každou platformu se budou automaticky hledat následující jména: NT: AIX: Solaris: HP/UX:
[–weight číslo] Váha, která je přiřazena určité externí autorizační službě v procesu rozhodnutí o autorizaci. Parametr weight je hodnotou size_t bez znaménka a je volitelný. Hodnota označuje váhu, která by měla být dána každému rozhodnutí této externí autorizační služby v rámci celého procesu rozhodování. Předvolená hodnota je 101. parametry Volitelně mohou být do externí autorizační služby předávány další inicializační informace ve tvaru argumentů. Argumenty musí uvádět ampersand (například & -server fred). Definice služby je podrobněji probírána v knize IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty.
Dodatek A. Referenční informace ke konfiguraci serveru
265
stanza [aznapi-pac-services] Plug-in služeb PAC poskytuje aplikacím autorizační API schopnost přemístit pověření Tivoli Access Manager tam a zpátky mezi původním formátem pověření produktu Tivoli Access Manager a alternativním formátem nazývaným PAC (privilege attribute certificate). Každý plug-in služeb PAC je samostatný modul, který je dynamicky zavedený do autorizační služby. Z PAC je možné získat informace o totožnosti. Aplikace mohou převést pověření uživatele do PAC a pak je používat v dalších autorizačních doménách. Aplikace pak mohou předávat PAC serverům v jiných autorizačních doménách a provádět s nimi další operace. Záznamy objektu stanza pro konfiguraci služeb PAC produktu Tivoli Access Manager jsou deklarované v objektu stanza [aznapi-pac-services] každého z těchto konfiguračních souborů poskytovaných produktem Tivoli Access Manager: v Konfigurační soubor vašeho správce zdrojů pro konfigurované plug-iny služeb PAC. Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor pro vytvoření vašeho vlastního konfiguračního souboru správce zdrojů. Vývojáři plug-inů služeb by měli poskytnout standardní funkce. Než dokončíte plug-iny služeb, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference.
266
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [aznapi-pac-services] id-služby = {krátké_jméno|cesta_k_dll} [ & parametry ... ] Definuje službu autorizačního rozhraní API pro službu kódování certifikátů PAC (Privilege Attribute Certificate) produktu Tivoli Access Manager. Každý záznam stanzy definuje jiný typ služby aznAPI a každý záznam má stejný formát, ve kterém: id-služby Vývojářem určená identifikace (ID) služby PAC, která vytváří certifikát PAC. Řetězec ID služby musí být jedinečný. {krátké_jméno|cesta_k_dll} Cesta ke knihovně DLL (Dynamic Link Library), která obsahuje spustitelný kód služby. Je-li knihovna DLL umístěna v adresáři, ve kterém systém obvykle hledá knihovny DLL (například /usr/lib na platformách UNIX, nebo %PATH% na Windows NT), nemusíte uvádět plně kvalifikované jméno ke knihovně DLL, ale pouze jméno knihovny DLL. Pokud chcete používat jméno knihovny DLL nezávislé na platformě, aby mohla být načtena každou podporovanou platformou produktu Tivoli Access Manager, zadejte jméno knihovny v krátkém tvaru. Ke krátkému jménu je připojený prefix známé knihovny a sufix pro každou platformu; hledá se každá možnost. Použijete-li například jméno knihovny v krátkém tvaru azn_ent_user, pak pro každou platformu se budou automaticky hledat následující jména: NT: AIX: Solaris: HP/UX:
parametry Volitelně můžete zadat parametry, které budou předány do služby, jakmile bude tato inicializována aznAPI. Všechna data, která následují v řetězci za znakem ampersand (&), se považují za parametry. Definice služby je podrobněji probírána v knize IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty.
Dodatek A. Referenční informace ke konfiguraci serveru
267
stanza [configuration-database] Záznam objektu stanza definuje jméno a umístění konfiguračního souboru zmateného hesla produktu Tivoli Access Manager. Produkt Tivoli Access Manager vytvoří nový konfigurační soubor obsahující všechny zmatené záznamy. Například, všechna spojená hesla (přihlášení) jsou zmatená a umístěná do konfiguračního souboru. Jak existující konfigurační soubor tak zmatený konfigurační soubor mají stejné jméno souboru, pouze je ke jménu souboru přidáno .obf (například, ivmgrd.conf.obf). Navíc, produkt Tivoli Access Manager vytvoří objekt stanza [configuration-database] podle potřeby, kdykoli je zmatený záznam automaticky přidaný ke zmatenému konfiguračnímu souboru. Tento objekt stanza má záznam objektu stanza, který poukazuje na jméno a umístění zmateného konfiguračního souboru. Objekt stanza [configuration-database] může být umístění v každém konfiguračním souboru, včetně konfiguračního souboru pd.conf, je-li k souboru připojená zmatená hodnota. Nikdy by jste neměli editovat záznam v objektu stanza [configuration-database]. Jediná výjimka je, má-li soubor stále měnit různá umístění. Tento scénář je jediná okolnost, kdy by jméno souboru a umístění měla být modifikována. Pamatujte si, že kdykoli konfigurační soubor mění své umístění, musíte přesunout i zmatený soubor. stanza [configuration-database] file = plně_kvalifikovaná_cesta Jméno souboru a umístění, kde se nachází informace o zmateném konfiguračním souboru. Poznámka: Zmatené heslo je generované a nastavené obslužným programem konfigurace. Needitujte tento záznam objektu stanza. Jméno zmateného konfiguračního souboru je stejné jako jméno vztahujícího se konfiguračního souboru. Typ souboru může být libovolný, ale přípona je obvykle .conf.obf. Například, zmatený konfigurační soubor pro ldap.conf je ldap.conf.obf. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam objektu stanza je povinný pouze pokud během konfigurace došlo ke zmatení hesla.Předvolené instalační umístění pro UNIX: /opt/PolicyDirector/etc/jméno_serveru.conf.obf Předvolené instalační umístění ro Windows: c:\Program files\tivoli\Policy Director\etc\jméno_serveru.conf.obf Příklad pro Windows, když je server Microsoft Active Directory registrem uživatelů: C:\Program Files\Tivoli\Policy Director\etc\activedir.conf.obf
268
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [delegated-admin] Konfigurace produktu Tivoli Access Manager může vyžadovat, aby byl uživatel autorizován, chce-li si prohlédnout každou skupinu, která je vrácena v seznamu skupin. Nebo může být uživatel autorizován, aby získal seznam, aniž by se nejprve autorizoval. V delegované administrativě byste měli používat jeden typ rozhraní v celém procesu, chcete-li dosáhnout optimálních výsledků. Používejte buď rozhraní Web Portal Manager, nebo příkazy pdadmin. Tato stanza se týká pouze používání příkazu pdadmin. Záznamy stanzy pro zapnutí nebo vypnutí nastavení kontrol autorizace delegované správy skupin a uživatelů jsou umístěny ve stanze [delegated-admin] tohoto konfiguračního souboru: v ivmgrd.conf pro server politik pdmgrd stanza [delegated-admin] authorize-group-list = {yes|no} Indikuje, jestli je třeba provést kontroly autorizace v příkazech pdadmin group list a group list-dn. Toto klíčové slovo se uvádí jako funkce ovlivňující výkonnost. Platné hodnoty zahrnují: yes Aktivuje kontroly autorizace. no Zakazuje kontroly autorizace. Tento záznam stanzy je volitelný. Předvolená hodnota: no Příklad: authorize-group-list = yes
Dodatek A. Referenční informace ke konfiguraci serveru
269
stanzy [domains] a [domain=jméno_domény] Objekt stanza [domains] obsahuje seznam domén. Každá doména uvedená pod tímto objektem stanza musí mít svůj vlastní objekt stanza [domain=jméno_domény]. Například: [domains] domain = d domain = mydomain [domain=d] [domain=mydomain]
Záznamy objektů stanza pro konfiguraci více domén jsou umístěné v objektech stanza [domains] a [domain=jméno_domény] tohoto konfiguračního souboru: v ivmgrd.conf pro server politik pdmgrd. stanza [domains] domain = jméno_domény Jméno domény, které bylo vytvořeno. Hodnota jméno_domény je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí místního nastavení kódů. Tento záznam objektu stanza je povinný, pokud uživatel vytvoří alespoň jednu doménu. Neexistují žádné předvolené hodnoty. Příklad: domain = mydomain1 stanza [domain = jméno_domény] database-path = plně_kvalifikovaná_cesta Jméno souboru a umístění, kde se nachází databáze pro doménu vypsanou na seznamu. Jméno databáze je stejné jako jméno domény. Typ souboru může být libovolný, ale přípona je obvykle .db. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Poznámka: Editování tohoto záznamu v konfiguračním souboru se nedoporučuje. Tento záznam objektu stanza je povinný, pokud uživatel vytvoří alespoň jednu doménu. Předvolená hodnota pro UNIX: /var/PolicyDirector/db/jméno_domény.db Předvolená hodnota pro Windows: instalační_cesta_pd\db\jméno_domény.db Příklad pro Windows: D:\programs\ibm\am\db\dname1.db
270
IBM Tivoli Access Manager: Base: Administrativní příručka
allowed-registry-substrings = dn Podřetězec rozlišovacího jména (DN), který omezuje, ve kterém registru lze vytvořit uživatele, nebo odkud jej můžeme importovat. DN vytvořeného nebo importovaného uživatele musí obsahovat uvedenou hodnotu podřetězce. Omezení hodnoty podřetězce DN jsou závislé na registru. Většina registrů uživatelů povoluje alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Můžete uvést jedno nebo víc relativních DN, které mají být použité při tvoření uživatelů. Uvedení jednoho nebo více podřetězců lze omezit tvoření a importování uživatelů a skupin do relativních DN, které jsou danými podřetězci označené. Například, můžete uvést podřetězec DN dc=mkt, abyste omezili uživatele, kteří jsou vytvoření a importovaní do domény pojmenované Marketing: Jako administrátor domén správy musíte: 1. Manuálně přidat hodnotu dn pro každou vytvořenou doménu, kromě domény Management (server politik). 2. Poté, co přidáte tento pár klíčových hodnot, oznamte administrátorovi domén, aby přidal tento řetězec do voleb DN při tvoření a importování uživatelů a skupin. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad: allowed-registry-substrings = "dc=mkt"
Dodatek A. Referenční informace ke konfiguraci serveru
271
stanza [ivacld] Záznamy stanzy pro konfiguraci informací týkajících se autorizačního serveru jsou umístěny ve stanze [ivacld] v tomto konfiguračním souboru: v ivacld.conf pro autorizační server pdacld stanza [ivacld] tcp-req-port = {0|port} Port TCP (Transmission Control Protokol), na kterém server očekává požadavky. Platné hodnoty zahrnují: 0 Zakázat číslo portu. port Aktivovat číslo portu. Pro hodnotu port použijte libovolné platné číslo portu. Platné číslo portu je libovolné kladné číslo, které povoluje protokol TCP/IP a které není momentálně používáno jinou aplikací. Doporučuje se, abyste používali předvolenou hodnotu čísla portu, nebo používali číslo portu větší než 1000, které není momentálně používáno. Tento záznam stanzy je povinný. Předvolená hodnota: 7136 Příklad: tcp-req-port = 7136 pid-file = plně_kvalifikovaná_cesta Umístění a jméno souboru PID. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je povinný. Předvolená hodnota pro Windows: C:\instalační_cesta_pd\log\ivacld.pid Předvolená hodnota pro UNIX: /var/PolicyDirector/log/ivacld.pid Příklad pro Windows: pid-file = C:\pd\log\ivacld.pid
272
IBM Tivoli Access Manager: Base: Administrativní příručka
log-file = plně_kvalifikovaná_cesta Umístění a jméno souboru protokolu serveru. Zprávy jsou přesměrované z STDOUT a STDERR a odeslané do souboru protokolu serveru, jak je definováno ve směrovacím souboru autorizačního serveru (pdacld_routing). Autorizační server se spoléhá na směrovací soubor ve zjištění jmen a cesty souborů protokolu. Pří spuštění autorizačního serveru (pdacld) je provedena kontrola existence směrovacího souboru. Pokud existuje, je použitý směrovací soubor a tento záznam objektu stanza je ignorován; jinak je použit tento záznam objektu stanza. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″).Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Pokud jste během instalace produktu Tivoli Access Manager aktivovali adresář Tivoli Common Directory, abyste uvedli umístění společného adresáře pro všechny vaše soubory protokolů komponent Base, předvolený instalační adresář bude jiný. Například: log-file = TCD/HPD/logs /msg__pdacld_utf8.log Identifikátor se třemi znaky použitý v příkladu je HPD a uvádí, že soubory protokolů jsou pro komponenty Base produktu Tivoli Access Manager. Tento záznam stanzy je povinný. Předvolené umístění instalace pro Windows: instalační_cesta_pd\log\msg__pdacld_utf8.log Předvolené instalační umístění pro UNIX: /var/PolicyDirector/log/msg__pdacld_utf8.log Příklad pro Windows bez adresáře Tivoli Common Directory: log-file = C:\pd\log\msg__pdacld_utf8.log Příklad pro UNIX s adresářem Tivoli Common Directory: /PolicyDirector/TAMBase/HPD/logs/msg__pdacld_utf8.log unix-user = jméno_uživatele Účet UNIXového uživatele pro tento server. Server spustí tento účet UNIXového uživatele. Tento záznam stanzy je povinný. Předvolená hodnota: ivmgr Příklad: unix-user = ivmgr unix-group = jméno_skupiny Účet UNIXové skupiny pro tento server. Server spustí tento účet UNIXového uživatele. Tento záznam stanzy je povinný. Předvolená hodnota: ivmgr Příklad: unix-group = ivmgr
Dodatek A. Referenční informace ke konfiguraci serveru
273
permit-unauth-remote-caller= {true|false} Uvádí, zda klienti autorizačního rozhraní API mají být autorizováni autorizačním serverem dříve, než budou zpracovány jejich požadavky. Platné hodnoty zahrnují: true Klienti autorizačního rozhraní API nemusí být autorizováni.
false
Varování: Nastavením tohoto parametru na hodnotu true umožníte, aby databázi politik četli všichni klienti v doméně, nikoliv pouze ti, kteří již byli řádně autorizováni pomocí členství ve skupině remote-acl-users.V závislosti na politice uplatňované v zabezpečení domény musí plánovači systému zvážit, zda schopnost každého klienta číst systémově definovanou politiku, je bezpečnostním rizikem. Klienti autorizačního rozhraní API by měli být autorizováni.
Tento záznam stanzy je volitelný. Předvolená hodnota: false Příklad: permit-unauth-remote-caller= false logcfg = kategorie:[{stdout|stderr|file|pipe|remote}][[parametr[=hodnota]][parametr[=hodnota]]] Umožňuje protokolování a monitorování aplikace. Parametry kategorie, místo určení a jiné jsou použité pro zachycení událostí monitorování a přihlášení Tivoli Access Manager. Každý server provádí vlastní nastavení protokolování ve svém konfiguračním souboru. Platné hodnoty zahrnují: audit.azn Kategorie, která indikuje monitorování autorizační komponenty. agent-protokolu Indikuje místo určení, kde agnet-protokolu je jeden z stdout, stderr, file, pipe nebo remote. Například: audit.azn:file path = cesta Uvádí jméno a umístění souboru protokolu, které je použité pro agenta-protokolu. flush_interval = interval_zarovnání Uvádí frekvenci pro zarovnání vyrovnávací paměti souborů protokolu. log_id = Uvádí identifikátor pro směrování událostí s přídavných kategorií do stejného agenta-protokolů. Odstraňte znaky komentáře (#) na začátcích řádků konfiguračních souborů, abyste umožnili autentizace nebo autorizační monitorování (nebo obojí) pro aplikaci. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad pro konfiguraci autentizačního a autorizační monitorování: logcfg = audit.azn:file path=/var/PolicyDirector/audit/ ivacld.log,flush_interval=20,log_id=PDAclAudit logcfg = audit.authn:file log_id=PDAclAudit
274
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [ivmgrd] Záznamy stanzy týkající se konfigurace serveru politik a databáze politik (známé také jako hlavní autorizační databáze) jsou umístěny ve stanze [ivmgrd] tohoto konfiguračního souboru: v ivmgrd.conf pro server politik pdmgrd. stanza [ivmgrd] unix-user = jméno_uživatele Účet UNIXového uživatele pro tento server. Server spustí tento účet UNIXového uživatele. Tento záznam stanzy je povinný. Předvolená hodnota: ivmgr Příklad: unix-user = ivmgr unix-group = jméno_skupiny Účet UNIXové skupiny pro tento server. Server spustí tento účet UNIXového uživatele. Tento záznam stanzy je povinný. Předvolená hodnota: ivmgr Příklad: unix-group = ivmgr database-path = plně_kvalifikovaná_cesta Umístění a jméno databáze politik, známé také jako hlavní autorizační databáze. Typ souboru může být libovolný, ale přípona je obvykle .db. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″). Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Poznámka: Editování této stanzy v konfiguračním souboru se nedoporučuje. Tento záznam stanzy je povinný. Předvolená hodnota pro UNIX: /var/PolicyDirector/db/master_authzn.db Předvolená hodnota pro Windows: instalační_cesta_pd\db\master_authzn.db Příklad pro Windows: database-path = C:\pd\db\master.db
Dodatek A. Referenční informace ke konfiguraci serveru
275
tcp-req-port = {0|port} Číslo TCP portu, na kterém server očekává požadavky. Platné hodnoty zahrnují: 0 Zakázat číslo portu. port Aktivovat číslo portu. Pro hodnotu port použijte libovolné platné číslo portu. Platné číslo portu je libovolné kladné číslo, které povoluje protokol TCP/IP a které není momentálně používáno jinou aplikací. Doporučuje se, abyste používali předvolenou hodnotu čísla portu, nebo používali číslo portu větší než 1000, které není momentálně používáno. Tento záznam stanzy je povinný. Předvolená hodnota: 8135 Příklad: tcp-req-port = 8135 auto-database-update-notify = {yes|true|no|false} Určuje automatické nebo ruční upozorňování na aktualizace pro repliky autorizační databáze. Platné hodnoty: yes|true Aktivuje automatické upozorňování na aktualizaci. Toto automatické nastavení je vhodné pro prostředí, ve kterých je změn v databázi málo a jsou prováděny zřídka. Pokud nakonfigurujete oznámení o aktualizaci tak, aby bylo automatické, musíte také správně nakonfigurovat záznamy stanzy max-notifier-threads= a notifier-wait-time=. no|false Aktivuje ruční upozorňování o aktualizaci. Tento záznam stanzy je povinný. Předvolená hodnota: yes Příklad: auto-database-update-notify = yes max-notifier-threads = počet_vláken Maximální počet vláken pro proces oznamující události. Server politik je odpovědný za synchronizaci všech replik databáze v zabezpečené doméně. Jakmile je provedena změna v hlavní databázi, vlákna procesu pro oznámení o aktualizaci odešlou oznámení této změny všem replikám. Každá replika má pak povinnost načíst nové informace z hlavní databáze. Pokud je záznam objektu stanza oznámení o aktualizaci nastaven na (yes), musíte správně konfigurovat tento záznam objektu stanza a také záznam objektu stanza notifier-wait-time=. Pro počet_vláken by měla být hodnota obecně nastavená na rovnou počtu existujících replik. Zadejte platné kladné celé číslo. Platný rozsah počtu vláken je 1 až 128 vláken. Tento záznam stanzy je povinný, je-li auto-database-update-notify = yes. Předvolená hodnota: 10 Příklad: max-notifier-threads = 20.
276
IBM Tivoli Access Manager: Base: Administrativní příručka
notifier-wait-time = počet_vteřin Doba (ve vteřinách), po kterou autorizační databáze politik čeká, než je upozornění odesláno na repliky. Když je serveru politik oznámeno, aby provedl změny v hlavní autorizační databázi, čeká po předvolenou dobu, než odešle oznámení o aktualizaci všem replikám databáze. Tato časová prodleva je znovu nastavena při každé následující změně databáze. Pokud je záznam objektu stanza oznámení o aktualizaci nastaven na (yes), musíte správně konfigurovat tento záznam objektu stanza a také objekt stanza max-notifier-threads=. Platné hodnoty zahrnují: počet_vteřin Doba (ve vteřinách), po kterou autorizační databáze politik čeká, než je upozornění odesláno na repliky. Tento záznam stanzy je povinný, je-li auto-database-update-notify = yes. Předvolená hodnota: 15 vteřin Příklad: notifier-wait-time = 30 pid-file = plně_kvalifikovaná_cesta Umístění a jméno souboru PID. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″). Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je povinný. Předvolená hodnota pro UNIX: /var/PolicyDirector/log/ivmgrd.pid Předvolená hodnota pro Windows: instalační_cesta_pd\log\ivmgrd.pid Příklad pro UNIX: pid-file = /var/PolicyDirector/log/ivmgrd.pid
Dodatek A. Referenční informace ke konfiguraci serveru
277
log-file = plně_kvalifikovaná_cesta Umístění a jméno souboru protokolu serveru. Zprávy jsou přesměrované z STDOUT a STDERR a odeslané do souboru protokolů serveru, jak je definováno ve směrovém souboru serveru politik (pdmgrd_routing). Server politik se spoléhá na směrovací soubor, který určuje jména a cesty souborů protokolu. Při spuštění serveru politik (pdmgrd) je provedena kontrola existence směrovacího souboru. Pokud existuje, je použitý směrovací soubor a tento záznam objektu stanza je ignorován; jinak je použit tento záznam objektu stanza. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″). Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je povinný. Předvolené instalační umístění pro Windows: instalační_cesta_pd\log\msg__pdmgrd_utf8.log Předvolené instalační umístění pro UNIX: /var/PolicyDirector/log/msg__pdmgrd_utf8.log Pokud jste během instalace produktu Tivoli Access Manager aktivovali adresář Tivoli Common Directory, abyste uvedli umístění společného adresáře pro všechny soubory protokolů, předvolený instalační adresář bude jiný. Například: log-file = adresář_TCD/HPD/logs /msg__pdmgrd_utf8.log Identifikátor se třemi znaky použitý v příkladu je HPD a uvádí, že soubory protokolů jsou pro komponenty Base produktu Tivoli Access Manager: Příklad pro Windows bez adresáře Tivoli Common Directory: log-file = C:\pd\log\msg__pdmgrd_utf8.log ca-cert-download-enabled = {yes|no} Určuje, zda další komponenty Tivoli Access Manager Runtime mohou automaticky stáhnout kořenový certifikát CA. Tuto hodnotu nastavte pomocí konfiguračního obslužného programu mgrsslcfg. Platné hodnoty zahrnují: yes Povolit klientům stáhnout automaticky kořenový CA certifikát. no Neumožňuje klientům stáhnout kořenový certifikát CA. Tento záznam stanzy je volitelný. Předvolená hodnota: no Příklad: ca-cert-download-enabled = yes
278
IBM Tivoli Access Manager: Base: Administrativní příručka
standby = {0|počet} Počet záložních serverů politik (pdmgrd) Poznámka: Počet záložních serverů je generovaný a nastavený obslužným programem konfigurace. Needitujte tento záznam objektu stanza. Platné hodnoty zahrnují: 0 Nula indikuje, že žádné servery politik nejsou záložní servery. počet Počet záložních serverů politik. Zadejte kladné celé číslo. Momentálně je toto číslo pouze 1. Tento záznam stanzy je povinný. Předvolená hodnota: 0 Příklad: standby = 1 logcfg = kategorie:[{stdout|stderr|file|pipe|remote}][[parametr[=hodnota]][parametr[=hodnota]]] Umožňuje protokolování a monitorování aplikace. Parametry kategorie, místo určení a jiné jsou použité pro zachycení událostí monitorování a přihlášení Tivoli Access Manager. Každý server provádí vlastní nastavení protokolování ve svém konfiguračním souboru. Platné hodnoty zahrnují: audit.azn Kategorie, která indikuje monitorování autorizační komponenty. agent-protokolu Indikuje místo určení, kde agnet-protokolu je jeden z stdout, stderr, file, pipe nebo remote. Například: audit.azn:file path = cesta Uvádí jméno a umístění souboru protokolu, které je použité pro agenta-protokolu. flush_interval = interval_zarovnání Uvádí frekvenci pro zarovnání vyrovnávací paměti souborů protokolu. log_id = Uvádí identifikátor pro směrování událostí s přídavných kategorií do stejného agenta-protokolů. Odstraňte znaky komentáře (#) na začátcích řádků konfiguračních souborů, abyste umožnili autentizace nebo autorizační monitorování (nebo obojí) pro aplikaci. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Příklad pro konfiguraci pouze autentizačního a autorizačního monitorování: logcfg = audit.azn:file path=/var/PolicyDirector/audit/ pdmgrd.log,flush_interval=20,log_id=PDMgrAudit logcfg = audit.authn:file log_id=PDMgrAudit #logcfg = audit.mgmt:file log_id=PDMgrAudit
Dodatek A. Referenční informace ke konfiguraci serveru
279
stanza [ldap] Tento objekt stanza definuje konfigurační páry hodnota-klíč, které je potřeba pro servery produktu Tivoli Access Manager, aby mohly komunikovat se serverem registrů LDAP. Hodnota pro záznam objektu stanza registru uživatelů (ldap-server-config) je určená konfiguračním souborem pd.conf. Soubor pd.conf se vytváří při konfiguraci komponenty Tivoli Access Manager Runtime. Konfigurační páry hodnota- klíč použité pouze pro server registrů LDAP jsou umístěné v konfiguračním souboru ldap.conf v objektu stanza [ldap]. Záznamy objektu stanza serveru LDAP jsou popsané zvlášť v části “stanza [ldap] pro ldap.conf” na stránce 289. Konfigurační páry hodnota-klíč pro konfigurační soubory serveru jsou umístěné v objektu stanza [ldap] každého z těchto konfiguračních souborů: v ivmgrd.conf pro server politik pdmgrd, v ivacld.conf pro autorizační server pdacld, v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd, v konfigurační soubor vašeho správce zdrojů pro konfigurované záznamy LDAP. Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor pro vytvoření vašeho vlastního konfiguračního souboru správce zdrojů. Vývojáři plug-inů služeb by měli poskytnout standardní funkce. Než dokončíte plug-iny služeb, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. stanza [ldap] ldap-server-config = plně_kvalifikovaná_cesta Umístění konfiguračního souboru ldap.conf. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″). Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam objektu stanza je povinný pro soubor ivmgrd.conf. Předvolené instalační umístění pro UNIX: /opt/PolicyDirector/etc/ldap.conf Předvolené instalační umístění pro Windows: C:\Program Files\Tivoli\PolicyDirector\etc\ldap.conf Příklad pro UNIX: ldap-server-config = /opt/PolicyDirector/etc/ldap.conf
280
IBM Tivoli Access Manager: Base: Administrativní příručka
prefer-readwrite-server = {yes|true|no|false} Určení, zda klient může zaslat dotaz na server LDAP s možnostmi pro čtení/zápis, než zašle dotaz na servery s výlučnou možností čtení, které jsou nakonfigurovány v doméně. Předvolené hodnoty se mohou lišit. Například předvolená hodnota pro soubor ivmgrd.conf je yes, zatímco předvolená hodnota pro soubor ivacld.conf je no. Platné hodnoty zahrnují: yes|true Povoluje klientovi, aby se dotazoval na serveru LDAP s možnostmi čtení/zápisu. no|false Zablokuje klienta. Cokoli jiného než yes|true včetně prázdné hodnoty je interpretováno jako no|false. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Předvolená hodnota je závislá na serveru. Příklad: prefer-readwrite-server = no bind-dn = LDAP_dn Rozlišovací jméno (DN - distinguished name) uživatele LDAP, které se používá při spojení (přihlášení se na) serverem LDAP. Hodnota LDAP_dn je vytvořená a založená na jménu serveru, které bylo uvedené volbou –n jméno_serveru a lokálním hostitelem počítače. Použijte obslužný program svrsslcfg, abyste nastavili hodnotu LDAP_dn. Tento záznam stanzy je povinný, je-li jako registr uživatelů nakonfigurován LDAP. Informace, jak používat páry klíč=hodnota, uvedené v této stanze, pro účely ladění výkonnosti najdete v knize IBM Tivoli Access Manager for e-business Performance Tuning Guide. Neexistují žádné předvolené hodnoty. Předvolené hodnoty jsou závislé na serveru. Příklad pro server politik pdmgrd: bind-dn = cn=ivmgrd/master,cn=SecurityDaemons,secAuthority=Default ssl-enabled = {yes|true|no|false} Určení, zda povolit komunikaci SSL se serverem LDAP. Hodnota pro každý server se může lišit v závislosti na konfiguraci daného serveru. Pokud uvedete, že autorizační (aznAPI) komunikuje se serverem s použitím SSL, musíte aktivovat SSL používající tento záznam objektu stanza. Musíte uvést také jméno souboru klíčů SSL, abyste mohli použít IP port SSL, DN souboru klíčů pouze, pokud je v souboru více klíčů, a heslo souboru klíčů. Platné hodnoty zahrnují: yes|true Aktivovat komunikaci SSL. no|false Zakázat komunikaci SSL. Cokoli jiného než yes|true včetně prázdné hodnoty je interpretováno jako no|false a SSL bude automaticky konfigurovaná. Tento záznam objektu stanza je povinný pro aktivaci komunikace SSL. Neexistují žádné předvolené hodnoty. Předvolené hodnoty jsou závislé na serveru. Příklad: ssl-enabled = yes
Dodatek A. Referenční informace ke konfiguraci serveru
281
ssl-keyfile = jméno-souboru-klíčů-ssl-ldap Jméno a umístění souboru klíčů SSL. Soubor klíčů SSL se používá při výměně certifikátů používaných v komunikaci s LDAP. Typ souboru může být libovolný, ale přípona je obvykle .kdb. Soubory certifikátů v adresáři musí být přístupné pro uživatele serveru (všechny uživatele). Ujistěte se, že uživatel serveru (například, ivmgr) nebo všichni uživatelů vlastní oprávnění k přístupu do souboru .kdb a pořadač, který obsahuje soubor .kdb. Platné jméno souboru je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?) nebo dvojité uvozovky. Tento záznam objektu stanza je povinný pouze, když je server LDAP konfigurovaný na provádění autorizace klienta (ssl-enabled = yes). Neexistují žádné předvolené hodnoty. Předvolené hodnoty jsou závislé na serveru. Předvolené umístění pro Windows: instalační_adresář_pd\keytab\jméno_serveru.kdb Předvolené umístění pro UNIX: /opt/PolicyDirector/keytab/jméno_serveru.kdb Příklad pro UNIX pro server politik pdmgrd: ssl-keyfile = /ldap52kdb/a17jsun.kdb ssl-keyfile-dn = označení-souboru-klíčů-ssl-ldap Označení klíče osobního certifikátu klienta v souboru klíčů SSL. Označení klíče se používá k identifikaci certifikátu klienta, který je předložen serveru LDAP. Tento záznam stanzy je povinný, pouze je-li server LDAP nakonfigurován pro provádění autentizace klientů. Je-li databáze klíčů předvoleného serveru politik pdmgrd právě používána, předvolená hodnota certifikátu klienta je: PDLDAP Příklad: ssl-keyfile-dn = "PDLDAP"
282
IBM Tivoli Access Manager: Base: Administrativní příručka
auth-using-compare = {yes|true|no|false} Zvolte, zda se má používat ldap_compare( ) namísto volání ldap_bind( ) při ověření hesla a autentizaci uživatele. Pro ty servery LDAP, které to dovolují, by mohla operace compare probíhat rychleji než operace bind. Hodnota pro každý server se může lišit v závislosti na konfiguraci daného serveru. Tato volba mění metodu používanou těmito voláními aznAPI: v azn_util_client_authenticate( ) v azn_util_password_authenticate( ) Platné hodnoty zahrnují: yes|true Při autentizaci uživatelů LDAP se bude používat operace compare namísto operace bind. no|false Při autentizaci uživatelů LDAP se bude používat operace bind namísto operace compare. Cokoli jiného než yes|true včetně prázdné hodnoty je interpretováno jako no|false. Informace, jak používat páry klíč=hodnota, uvedené v této stanze, pro účely ladění výkonnosti najdete v knize IBM Tivoli Access Manager for e-business Performance Tuning Guide. Tento záznam stanzy je volitelný. Neexistují žádné předvolené hodnoty. Předvolené hodnoty jsou závislé na serveru. Příklad: auth-using-compare = yes port = port Číslo IP portu pro jiný protokol než SSL, které se bude používat pro komunikaci se serverem LDAP. Pro port použijte číslo portu konfigurované pro server LDAP. Tento záznam objektu stanza je povinný pro servery pdmgrproxyd a pdacld. Není povinný pro server politik pdmgrd.Předvolená hodnota: 389 Příklad: port = 389 default-policy-override-support = {yes|true|no|false} Určení, zda je povolena podpora politiky na úrovni uživatele. Platné hodnoty zahrnují: yes|true Podpora politiky uživatele je zakázána a bude se kontrolovat pouze globální (předvolená) politika. Tato volba dovoluje, aby se nekontrolovala politika uživatele, i když je zadána. no|false Podpora politiky uživatele je aktivována. Je-li administrátorem zadána politika uživatele, pak přepíše globální politiku. Není-li uvedena žádná hodnota, pak se nastaví default-policy-override-support = no. Informace, jak používat páry klíč=hodnota, uvedené v této stanze, pro účely ladění výkonnosti najdete v knize IBM Tivoli Access Manager for e-business Performance Tuning Guide. Tento záznam stanzy je volitelný. Předvolená hodnota: no Příklad: default-policy-override-support = yes
Dodatek A. Referenční informace ke konfiguraci serveru
283
user-and-group-in-same-suffix = {yes|true|no|false} Určení, zda ve stejné příponě LDAP budou jako definice uživatele nadefinovány i skupiny, jejichž členem je uživatel. Je-li uživatel autentizován, pak se musí určit skupiny, jejichž členem je uživatel, aby se mohlo vytvořit pověření. Obvykle se prohledávají všechny přípony LDAP, aby se nalezly skupiny, jejichž členem je uživatel. Platné hodnoty zahrnují: yes|true Bude se předpokládat, že skupiny jsou nadefinovány ve stejné příponě jako definice uživatelů. Členství ve skupinách se bude vyhledávat pouze v této příponě. Toto chování může zlepšit výkonnost vyhledávání informací o skupinách, protože se členství ve skupinách bude hledat pouze v rámci jedné přípony. Tato volba by měla být uvedena pouze tehdy, jsou-li definice skupin omezeny na stejnou příponu jako definice uživatelů. no|false Skupiny mohou být nadefinovány v libovolné příponě LDAP. Cokoli jiného než yes|true včetně prázdné hodnoty je interpretováno jako no|false. Informace, jak používat páry klíč=hodnota, uvedené v této stanze, pro účely ladění výkonnosti najdete v knize IBM Tivoli Access Manager for e-business Performance Tuning Guide. Tento záznam stanzy je volitelný. Předvolená hodnota: no Příklad: user-and-group-in-same-suffix = yes cache-enabled = {yes|true|no|false} Určení, zda se bude používat ukládání do paměti cache na straně klienta LDAP, aby byla zlepšena výkonnost podobných dotazů LDAP. Platné hodnoty zahrnují: yes|true Aktivuje ukládání do paměti cache na straně klientů LDAP. no|false Zakazuje ukládání do paměti cache na straně klientů LDAP. Tato hodnota je předvolená. Cokoli jiného než yes|true včetně prázdné hodnoty je interpretováno jako no|false. Informace, jak používat tento pár klíč = hodnota pro účely ladění, najdete v publikaci IBM Tivoli Access Manager for e-business Performance Tuning Guide. Tento záznam stanzy je volitelný. Předvolená hodnota: no Příklad: cache-enabled = no
284
IBM Tivoli Access Manager: Base: Administrativní příručka
cache-user-size = záznamy_uživatele Počet záznamů v paměti cache uživatele LDAP. Tento záznam objektu stanza bude ignorovaný, pokud nebude aktivovaná paměť cache. Hodnota záznamy_uživatele je uvedená jako kladné celé číslo. Tento záznam stanzy je volitelný. Předvolená hodnota: 256 Příklad: cache-user-size = 1000 cache-group-size = záznamy_skupiny Počet záznamů paměti cache skupiny LDAP. Tento záznam objektu stanza bude ignorovaný, pokud nebude aktivovaná paměť cache. Hodnota záznamy_skuipny je uvedená jako kladné celé číslo. Tento záznam stanzy je volitelný. Předvolená hodnota: 64 Příklad: cache-group-size = 100 cache-policy-size = záznamy_politik Počet záznamů v paměti cache politik LDAP. Tento záznam objektu stanza bude ignorovaný, pokud nebude aktivovaná paměť cache. Hodnota záznamy_politik je uvedená jako kladné celé číslo. Tento záznam stanzy je volitelný. Předvolená hodnota: 20 Příklad: cache-policy-size = 50 cache-user-expire-time = počet_vteřin Doba (ve vteřinách) potřebná, než je záznam v paměti cache považovaný za starý a je vyřazený. Tento záznam objektu stanza bude ignorovaný, pokud nebude aktivovaná paměť cache. Platné hodnoty zahrnují: počet_vteřin Doba je uvedená jako číslo ve vteřinách. Použijte kladné celé číslo. Tento záznam stanzy je volitelný. Předvolená hodnota: 30 Příklad: cache-user-expire-time = 120
Dodatek A. Referenční informace ke konfiguraci serveru
285
cache-group-expire-time = počet_vteřin Doba (ve vteřinách) potřebná, než je záznam skupiny v paměti cache považovaný za starý a je vyřazený. Tento záznam objektu stanza bude ignorovaný, pokud nebude aktivovaná paměť cache. Platné hodnoty zahrnují: počet_vteřin Doba je uvedená jako číslo ve vteřinách. Použijte kladné celé číslo. Tento záznam stanzy je volitelný. Předvolená hodnota: 300 (5 minut) Příklad: cache-group-expire-time = 600 cache-policy-expire-time = počet-vteřin Doba (ve vteřinách) potřebná, než je záznam politik v paměti cache považovaný za starý a je vyřazený. Tento záznam objektu stanza bude ignorovaný, pokud nebude aktivovaná paměť cache. Platné hodnoty zahrnují: počet_vteřin Doba je uvedená jako číslo ve vteřinách. Použijte kladné celé číslo. Tento záznam stanzy je volitelný. Předvolená hodnota: 30 Příklad: cache-policy-expire-time = 60 cache-group-membership = {yes|true|no|false} Indikuje, jestli je informace o členství uložená v paměti cache. Tento záznam objektu stanza bude ignorovaný, pokud nebude aktivovaná paměť cache. Platné hodnoty zahrnují: yes|true Členství ve skupině je uloženo v paměti cache. no|false Členství ve skupině není uloženo v paměti cache. Cokoli jiného než yes|true včetně prázdné hodnoty je interpretováno jako no|false. Tento záznam stanzy je volitelný. Předvolené hodnoty: yes|true Příklad: cache-group-membership = no
286
IBM Tivoli Access Manager: Base: Administrativní příručka
cache-use-user-cache = {yes|true|no|false} Indikuje, jestli se mají použít informace o paměti cache uživatele. Tento záznam objektu stanza bude ignorovaný, pokud nebude aktivovaná paměť cache. Platné hodnoty zahrnují: yes|true Použijte informace o uživateli z paměti cache. no|false Nepoužívejte informace o uživateli z paměti cache. Cokoli jiného než yes|true včetně prázdné hodnoty je interpretováno jako no|false. Tento záznam stanzy je volitelný. Předvolené hodnoty: yes|true Příklad: cache-use-user-cache = no max-search-size = [0|počet_záznamů] Omezení maximálního rozsahu vyhledávání, uvedené jako počet záznamů, které budou vráceny ze serveru LDAP. Hodnota pro každý server se může lišit v závislosti na konfiguraci daného serveru. Platné hodnoty zahrnují: 0 Počet je neomezen; neexistuje žádné omezení maximálního rozsahu vyhledávání. počet_záznamů Maximální počet záznamů pro vyhledání, uvedený jako celé číslo. Tato hodnota je omezena vlastním serverem LDAP. Tento záznam stanzy je volitelný. Předvolená hodnota je závislá na serveru, ale pokud není nakonfigurována, použije se standardně 2048. Příklad: max-search-size = 2048 timeout = {0|počet_vteřin} Množství času (ve vteřinách), které je přiděleno operacím autentizace nebo vyhledávání, než se začne považovat server LDAP, že je ve stavu mimo provoz. Jsou-li uvedeny, pak hodnoty záznamů stanzy authn-timeout = nebo search-timeout = přepisují hodnotu tohoto záznamu stanzy. Poznámka: Tento záznam stanzy neuvádějte v konfiguračním souboru serveru ldap.conf. Platné hodnoty zahrnují: 0 Není povolen žádný časový limit. počet_vteřin Počet vteřin povolený pro autentizace nebo hledání uvedený jako kladné celé číslo. Neexistuje žádné omezení rozsahu hodnot časového limitu. Tento záznam stanzy je volitelný. Předvolená hodnota: 0 Příklad: timeout = 0 authn-timeout = {0|počet_vteřin}
Dodatek A. Referenční informace ke konfiguraci serveru
287
Množství času (ve vteřinách), které je přiděleno operacím autentizace, než se začne považovat server LDAP, že je ve stavu mimo provoz. Je-li tato hodnota uvedena, pak přepisuje každou hodnotu uvedenou v timeout = pro operace autentizace. Poznámka: Tento záznam stanzy neuvádějte v konfiguračním souboru serveru ldap.conf. Platné hodnoty zahrnují: 0 Není povolen žádný časový limit. počet_vteřin Uvedený počet vteřin, který je povolen pro provádění operací autentizace, je zadán jako celé kladné číslo. Neexistuje žádné omezení rozsahu hodnot časového limitu. Tento záznam stanzy je volitelný. Předvolená hodnota: 0 Příklad: authn-timeout = 0 search-timeout = {0|počet_vteřin} Množství času (ve vteřinách), které je přiděleno operacím vyhledávání, než se začne považovat server LDAP, že je ve stavu mimo provoz. Je-li tato hodnota uvedena, pak přepisuje každou hodnotu uvedenou v timeout = pro operace vyhledávání. Poznámka: Tento záznam stanzy neuvádějte v konfiguračním souboru serveru ldap.conf. Platné hodnoty zahrnují: 0 Není povolen žádný časový limit. počet_vteřin Uvedený počet vteřin, který je povolen pro provádění operací vyhledávání, je zadán jako celé kladné číslo. Neexistuje žádné omezení rozsahu hodnot časového limitu. Tento záznam stanzy je volitelný. Předvolená hodnota: 0 Příklad: search-timeout = 0
288
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [ldap] pro ldap.conf Tato stanza definuje konfigurační páry klíč-hodnota, které jsou potřeba pro komunikaci se serverem registru LDAP. Zde můžete například najít konfigurační klíče a hodnoty pro přepnutí při selhání LDAP, včetně používání hlavního a replikovaných serverů. Hodnota registru uživatelů je určena souborem pd.conf. Soubor pd.conf se vytváří při konfiguraci komponenty Tivoli Access Manager Runtime. Informace, jak používat páry klíč=hodnota, uvedené v této stanze, pro účely ladění výkonnosti najdete v knize IBM Tivoli Access Manager for e-business Performance Tuning Guide. stanza [ldap] enabled = {yes|true|no|false} Určení, zda se LDAP bude používat jako registr uživatelů. V jednom okamžiku můžete zadat pouze jeden registr uživatelů. Pokud je toto aktivováno jiné požadované záznamy objektů stanza jsou jméno hostitele serveru LDAP a port, se kterým se má spojit server, DN přiřazeného uživatele, a heslo přiřazeného uživatele (zmatené). Platné hodnoty zahrnují: yes|true Aktivuje podporu registru uživatelů LDAP. no|false Zakazuje podporu registru uživatelů LDAP a určuje, že LDAP se nebude používat jako registr uživatelů. Cokoli jiného než yes|true včetně prázdné hodnoty je interpretováno jako no|false. Tento záznam stanzy je povinný, pokud jako registr uživatelů používáte LDAP. Předvolená hodnota se může lišit v závislosti na konfiguraci vašeho serveru. Příklad: enabled = yes host = jméno_hostitele Jméno hostitele serveru LDAP. Platné hodnoty pro jméno_hostitele zahrnují všechna platná jména hostitelů IP. Hodnota jméno_hostitele je získána ze souboru pd.conf. Soubor pd.conf se vytváří při konfiguraci komponenty Tivoli Access Manager Runtime na počítači. Chcete-li nastavit hodnotu jméno_hostitele při konfiguraci LDAP jako registru uživatelů Policy Director, použijte obslužný program svrsslcfg. Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Hodnota je získána ze souboru pd.conf. Příklady jmen hostitelů: host = libra host = libra.dallas.ibm.com
Dodatek A. Referenční informace ke konfiguraci serveru
289
cache-enabled = {yes|true|no|false} Určení, zda se bude používat ukládání do paměti cache na straně klienta LDAP, aby byla zlepšena výkonnost podobných dotazů LDAP. Platné hodnoty zahrnují: yes|true Aktivuje ukládání do paměti cache na straně klientů LDAP. no|false Zakazuje ukládání do paměti cache na straně klientů LDAP. Tato hodnota je předvolená hodnota. Cokoli jiného než yes|true včetně prázdné hodnoty je interpretováno jako no|false. Informace, jak používat tento pár klíč = hodnota pro účely ladění, najdete v publikaci IBM Tivoli Access Manager for e-business Performance Tuning Guide. Tento záznam stanzy je volitelný. Předvolená hodnota: no Příklad: cache-enabled = no port = port Číslo IP portu pro jiný protokol než SSL, které se bude používat pro komunikaci se serverem LDAP. Pro port použijte hodnotu konfigurovanou pro server LDAP. Tento záznam stanzy je povinný. Předvolená hodnota: 389 Příklad: port = 389 ssl-port = port IP port SSL, který se používá ke spojení se serverem LDAP. Pro port použijte libovolné platné číslo portu. Platné číslo portu je libovolné kladné číslo, které povoluje protokol TCP/IP a které není momentálně používáno jinou aplikací. Tento záznam objektu stanza je povinný pouze, když je server LDAP konfigurovaný na provádění autorizace klienta (ssl-enabled = yes). Předvolená hodnota: 636 Příklad: ssl-port = 636
290
IBM Tivoli Access Manager: Base: Administrativní příručka
LdapSSL = {ssl|nossl} Určení, zda povolit komunikaci SSL se serverem LDAP. Hodnota pro každý server se může lišit v závislosti na konfiguraci daného serveru. Platné hodnoty zahrnují: ssl Aktivovat komunikaci SSL. SSL bude automaticky konfigurované. nossl Zakázat komunikaci SSL. Cokoli jiného než ssl včetně prázdné hodnoty je interpretováno jako nossl. Tento záznam stanzy je volitelný. Předvolená hodnota je závislá na serveru. Příklad: LdapSSL = nossl LdapSSLKeyFile = jméno-souboru-klíčů-ssl-ldap Jméno a umístění souboru klíčů SSL. Soubor klíčů SSL se používá při výměně certifikátů používaných v komunikaci s LDAP. Typ souboru může být libovolný, ale přípona je obvykle .kdb. Soubory certifikátů v adresáři musí být přístupné pro uživatele serveru (všechny uživatele). Ujistěte se, že uživatel serveru (například, ivmgr) nebo všichni uživatelů vlastní oprávnění k přístupu do souboru .kdb a pořadač, který obsahuje soubor .kdb. Hodnota jméno a umístění souboru představuje alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″). Tento záznam stanzy je povinný pouze v případě, že je nastaveno LdapSSL = yes. Předvolená hodnota je závislá na serveru. Předvolená hodnota pro Windows: instalační_adresář_pd\keytab\ivmgrd.kdb Předvolená hodnota pro UNIX: /opt/PolicyDirector/keytab/ivmgrd.kdb Příklad pro UNIX: LdapSSLKeyFile = /opt/PolicyDirector/keytab/ivmgrd.kdb LdapSSLKeyFileDn = označení_klíče Označení klíče osobního certifikátu klienta v souboru klíčů SSL. Označení klíče se používá k identifikaci certifikátu klienta, který je předložen serveru LDAP. Tento záznam stanzy je povinný, je-li server LDAP nakonfigurován pro provádění autentizace klientů. Tento záznam stanzy je povinný pouze v případě, že je nastaveno LdapSSL = yes. Neexistují žádné předvolené hodnoty. Příklad: LdapSSLKeyFileDn = "PD_LDAP".
Dodatek A. Referenční informace ke konfiguraci serveru
291
LdapSSLKeyFilePwd = heslo-souboru-klíčů-ssl-ldap Heslo pro přístup do souboru klíčů SSL. Poznámka: Heslo vztahující se k předvoleného souboru klíčů SSL je key4ssl. Tento záznam stanzy je povinný pouze v případě, že je nastaveno LdapSSL = yes. Neexistují žádné předvolené hodnoty. Příklad: LdapSSLKeyFilePwd = mysslpwd replica = ldap-server, port, typ, preference Definice replik registru uživatelů LDAP v doméně, kde: v ldap-server je síťové jméno serveru. v port je číslo portu serveru LDAP. Platné číslo portu je libovolné kladné číslo, které povoluje protokol TCP/IP a které není momentálně používáno jinou aplikací. v type je jedno z readonly nebo readwrite. v pref je číslo od 1 do 10 (10 má nejvyšší preferenci). Tento záznam stanzy je volitelný. Předvolená hodnota je, že nejsou uvedeny žádné repliky. Příklad jedné zadané repliky a dvou zakomentovaných replik: replica = freddy,390,readonly,1 #replica = barney,391,readwrite,2 #replica = benny,392,readwrite,3 dynamic-groups-enabled = {yes|true|no|false} Indikuje, jestli jsou podporované dynamické skupiny. Poznámka: Tento záznam objektu stanza může být použitý pouze v konfiguračním souboru ldap.conf. Platné hodnoty zahrnují: yes|true Produkt Tivoli Access Manager se snaží o analýzu členství dynamických skupin. no|false Produkt Tivoli Access Manager se nesnaží o analýzu členství dynamických skupin. Cokoli jiného než yes|true včetně prázdné hodnoty je interpretováno jako no|false. Tento záznam stanzy je volitelný. Předvolená hodnota: no Příklad: dynamic-groups-enabled = no
292
IBM Tivoli Access Manager: Base: Administrativní příručka
ignore-suffix = dn_přípony Přípona serveru LDAP, která bude ignorovaná při hledání informací o uživatelích a skupinách. Poznámka: Tento záznam objektu stanza může být použitý pouze v konfiguračním souboru ldap.conf. Hodnota dn_přípony uvádí DN přípony, kterou chcete ignorovat. Opakujte tento záznam objektu stanza pro každou příponu, kterou chcete ignorovat. Například, pokud uvedete ignore-suffix = o=tivoli,c=us, libovolný uživatel nebo skupina, která obsahuje o=tivoli,c=us jako součást svého DN, bude ignorovaná. Tento záznam stanzy je volitelný. Předvolená hodnota: Jsou prohledané všechny definované přípony. Příklad: ignore-suffix = o=tivoli,c=us
Dodatek A. Referenční informace ke konfiguraci serveru
293
stanza [manager] Záznamy stanz pro konfiguraci nastavení hlavního serveru jsou umístěny ve stanze [manager] těchto konfiguračních souborů: v ivacld.conf pro autorizační server pdacld, v pd.conf, pokud používáte autorizační server pdacld, v pdmgrproxyd.conf pro proxy server politikpdmgrproxyd. stanza [manager] master-host = jméno_hostitele_serveru Jméno hostitele serveru produktu Tivoli Access Manager. Příklady platných jmen hostitelů: v mycomputer.city.company.com v mycomputer Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Příklad: master-host = ammaster master-port = port Číslo TCP portu, na kterém server očekává požadavky. Tato hodnota je vytvořená a nastavená jedním z následujících obslužných programů: v V souboru pd.conf je tato hodnota nastavena pomocí obslužného programu bassslcfg. v Pro všechny konfigurační soubory je hodnota nastavená pomocí obslužného programu svrsslcfg. Pro port použijte libovolné platné číslo portu. Platné číslo portu je libovolné kladné číslo, které povoluje protokol TCP/IP a které není momentálně používáno jinou aplikací. Doporučuje se, abyste používali předvolenou hodnotu čísla portu, nebo používali číslo portu větší než 1000, které není momentálně používáno. Tento záznam stanzy je povinný. Předvolená hodnota je závislá na serveru. Příklad: master-port = 7135
294
IBM Tivoli Access Manager: Base: Administrativní příručka
management-domain = {default|jméno_domény Jméno domény správy. Tato hodnota je vytvořená a nastavená jednou z těchto utilit: v Pro soubor pd.conf je tato hodnota nastavená utilitou bassslcfg. Pro konfigurační soubor pd.conf, pokud tato hodnota není v konfiguračním souboru, operace, které jsou závislé na její přítomnosti, selžou. v Pro jiné konfigurační soubory je tato hodnota nastavená pomocí utility svrsslcfg. Platné hodnoty zahrnují: Předvolba Uvádí doménu správy. Tato hodnota je předvolená hodnota pro všechny servery. jméno_domény Uvádí doménu uvedenou uživatelem. Použijte tuto hodnotu, když konfigurujete vaše vlastní jméno pro doménu. Hodnota jméno_domény je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí místního nastavení kódů. Platné znaky pro jména domén v USA. Anglické jsou písmena a-Z, čísla 0-9, tečka ( . ), podtržítko ( _ ), plus (+), pomlčka ( - ), zavináč ( @ ), ampersand ( & ) a hvězdička ( * ). Ve jméně domény nelze použít mezeru. Tento záznam stanzy je povinný. Předvolená hodnota pro všechny servery: Předvolená Příklad: management-domain = mymgmtdomain
Dodatek A. Referenční informace ke konfiguraci serveru
295
stanza [meta-info] Záznam objektu stanza pro konfiguraci informací o verzi produktu Tivoli Access Manager je umístěný v objektu stanza [meta-info] každého z těchto konfiguračních souborů: v ivmgrd.conf pro server politik pdmgrd, v ivacld.conf pro autorizační server pdacld, v pd.conf, pokud používáte autorizační server pdacld, v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd. stanza [meta-info] version = číslo Verze produktu Tivoli Access Manager v desítkovém formátu. Například, verze 5.1 produktu Tivoli Access Manager (Base) je představovaná číslem 1296, když se převede na desítkový formát. Poznámka: Tato hodnota je vygenerovaná; neměňte ji. Hodnota číslo se automaticky vyplní během aplikace a nesmí být editovaná. Běh produktu Tivoli Access Manager určí, kterou hodnotu vyplnit. V některých případech produkt Tivoli Access Manager použije klíč verze, aby zjistil, jestli byl na úroveň komponenty Base produktu Tivoli Access Manager aktualizován odpovídající konfigurační soubor. Tento záznam stanzy je povinný. Předvolená hodnota pro verzi 5.1: 1296 Příklad: version = 1296
296
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [pdmgrproxyd] Tyto záznamy objektů stanza pro konfiguraci proxy serveru politik jsou umístěné v: v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd. unix-user = ivmgr unix-group = ivmgr stanza [pdmgrproxyd] tcp-req-port = {0|port} Číslo TCP portu, na kterém server očekává požadavky. Platné hodnoty zahrnují: 0 Zakázat číslo portu. port Aktivovat číslo portu. Pro port použijte libovolné platné číslo portu. Platné číslo portu je libovolné kladné číslo, které povoluje protokol TCP/IP a které není momentálně používáno jinou aplikací. Doporučuje se, abyste používali předvolenou hodnotu čísla portu, nebo používali číslo portu větší než 1000, které není momentálně používáno. Tento záznam stanzy je povinný. Předvolená hodnota: 8138 Příklad: tcp-req-port = 8138 pid-file = plně_kvalifikovaná_cesta Umístění a jméno souboru PID. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″). Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je povinný.Předvolená hodnota pro Windows: instalační_cesta_pd\log\pdmgrproxyd.pid Předvolená hodnota pro UNIX: /var/PolicyDirector/log/ pdmgrproxyd.pid Příklad pro Windows: pid-file = C:\pd\log\pdmgrproxyd.pid
Dodatek A. Referenční informace ke konfiguraci serveru
297
log-file = plně_kvalifikovaná_cesta Umístění a jméno souboru protokolu serveru. Zprávy jsou přesměrované z STDOUT a STDERR a odeslané do souboru protokolu serveru, jak je definováno ve směrovém souboru autorizačního serveru (pdmgrproxyd_routing). Proxy server politik spoléhá na směrovací soubor ve zjištění jmen a cesty souborů protokolů. Při spuštění autorizačního serveru (pdmgrproxyd) je provedena kontrola existence směrového souboru. Pokud existuje, je použitý směrový soubor a tento záznam objektu stanza je ignorován; jinak je použit tento záznam objektu stanza. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″). Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je povinný. Předvolené instalační umístění pro Windows: instalační_cesta_pd\log\msg__pdmgrproxyd_utf8.log Předvolené instalační umístění pro UNIX: /var/PolicyDirector/log/msg__pdmgrproxyd_utf8.log Pokud jste během instalace produktu Tivoli Access Manager aktivovali adresář Tivoli Common Directory, abyste uvedli umístění společného adresáře pro všechny soubory protokolů, předvolený instalační adresář bude jiný. Například: log-file = adresář_TCD/HPD/logs /msg__pdmgrproxyd_utf8.log Identifikátor se třemi znaky použitý v příkladu je HPD a uvádí, že soubory protokolů jsou pro komponenty Base produktu Tivoli Access Manager. Příklad pro Windows bez adresáře Tivoli Common Directory: log-file = C:\pd\log\msg__pdmgrproxyd_utf8.log unix-user = jméno_uživatele Účet UNIXového uživatele pro tento server. Jména skupin a uživatelů v operačním systému UNIX jsou různé položky a obě mohou mít stejnou hodnotu. Jméno uživatele je nastavené jako vlastník uživatele souborů správce proxy serverů. Platnost uvedeného jména uživatele závisí na požadavcích příslušné platformy UNIX. Tento záznam stanzy je povinný, pokud pracujete s účty uživatelů operačního systému UNIX. Předvolená hodnota: ivmgr Příklad: unix-user = ivmgr unix-group = jméno_skupiny Účet UNIXové skupiny pro tento server. Jména skupin a uživatelů v operačním systému UNIX jsou různé položky a obě mohou mít stejnou hodnotu. Jméno uživatele je nastaveno jako vlastník skupiny souborů proxy serverů politik (pdmgrproxyd). Platnost uvedeného jména skupiny závisí na požadavcích příslušné platformy UNIX. Tento záznam stanzy je povinný, pokud pracujete s účty uživatelů operačního systému UNIX. Předvolená hodnota: ivmgr Příklad: unix-group = ivmgr
298
IBM Tivoli Access Manager: Base: Administrativní příručka
cache-database = {yes|no} Indikuje, jestli ukládání do paměti cache databáze politik je aktivováno. Platné hodnoty zahrnují: yes Aktivuje ukládání do paměti cache databáze politik. no Zablokuje ukládání do paměti cache databáze politik. Tento záznam stanzy je povinný. Předvolená hodnota: no Příklad: cache-database = yes
Dodatek A. Referenční informace ke konfiguraci serveru
299
stanza [pdrte] Jakmile je nainstalována sada programů PDMgr, tak se server politik začne automaticky spouštět po každém opětovném spuštění systému. Jakmile je nainstalována sada programů PDAcld, tak se automaticky začne démon autorizačního serveru spouštět po každém opětovném spuštění systému. Záznamy stanzy pro automatické spouštění serveru a při používání libovolného registru uživatelů jsou umístěny ve stanze [pdrte] tohoto konfiguračního souboru: v pd.conf, pokud používáte autorizační server pdacld. Pokud používáte autorizační server pdacld produktu Tivoli Access Manager, musíte mít konfigurační soubor serveru pd.conf. stanza [pdrte] configured = {yes|no} Označuje, zda byla nakonfigurována sada programů Tivoli Access Manager Runtime. Poznámka: Tato hodnota je vygenerovaná; neměňte ji. Platné hodnoty zahrnují: yes Sada programů Runtime byla nakonfigurována. no Sada programů Runtime nebyla nakonfigurována. Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Příklad: configured = no user-reg-type = {ldap|domino|active_directory} Typ registru uživatelů. Poznámka: Tato hodnota je vygenerovaná během konfigurace; neměňte ji. Platné hodnoty pro Windows: ldap Jako registr uživatelů je nakonfigurován LDAP. domino Jako registr uživatelů je nakonfigurován Lotus Domino. active_directory Jako registr uživatelů je nakonfigurován Microsoft Active Directory. Platné hodnoty pro UNIX: ldap Jako registr uživatelů je nakonfigurován LDAP. active_directory Jako registr uživatelů je nakonfigurován Microsoft Active Directory. Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Příklad: user-reg-type = ldap user-reg-server = jméno_serveru Jméno serveru registru uživatelů. Poznámka: Tato hodnota je vygenerovaná během konfigurace; neměňte ji. Platné jméno_serveru je libovolné jméno, které není citlivé na velikost písmen a které je povoleno protokolem TCP/IP. Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Příklad: user-reg-server = libra
300
IBM Tivoli Access Manager: Base: Administrativní příručka
user-reg-host = jméno_hostitele Použijte jméno hostitele registru. Poznámka: Tato hodnota je vygenerovaná během konfigurace; neměňte ji. Příklady platných jmen hostitelů: v mycomputer.city.company.com v mycomputer Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Příklad: user-reg-host = libra user-reg-hostport = port Číslo IP portu pro jiný protokol než SSL, které se bude používat pro komunikaci se serverem registru uživatelů. Poznámka: Tato hodnota je vygenerovaná během konfigurace; neměňte ji. Hodnota port je libovolné platné číslo portu, což znamená libovolné kladné číslo, které povoluje protokol TCP/IP a které není momentálně používáno jinou aplikací. Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Příklad: user-reg-hostport = 389 boot-start-ivmgrd = {yes|no} Označení, zda se má server politik (pdmgrd) spustit při spuštění systému. Platné hodnoty zahrnují: yes Spustí server politik pdmgrd při zavádění systému. no Nespustí server politik pdmgrd při zavádění systému. Tento záznam stanzy je povinný pouze na operačních systémech UNIX. Předvolená hodnota: no Příklad: boot-start-ivmgrd = yes boot-start-ivacld = {yes|no} Označení, zda se má autorizační server (pdacld) spouštět při zavádění systému. Platné hodnoty zahrnují: yes Spustit autorizační server pdacld při zavádění systému. no Nespustit autorizační server pdacld při zavádění systému. Tento záznam stanzy je povinný pouze na operačních systémech UNIX. Předvolená hodnota: no Příklad: boot-start-ivacld = yes
Dodatek A. Referenční informace ke konfiguraci serveru
301
boot-start-pdproxyd = {yes|no} Označení, zda se má spustit proxy server politik (pdmgrproxyd) při zavádění systému. Platné hodnoty zahrnují: yes Spustí proxy server politik pdmgrproxyd při zavádění systému. no Nespustí proxy server politik pdmgrproxyd při zavádění systému. Tento záznam stanzy je povinný pouze na operačních systémech UNIX. Předvolená hodnota: no Příklad: boot-start-pdproxyd = yes tivoli_common_dir = plně_kvalifikovaná_cesta Jméno a umístění souboru pro soubory protokolů zpráv a trasování. Označuje, zda je použitý adresář Tivoli Common Director. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″). Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam objektu stanza je požadovaný pouze, pokud konfigurujete běhové prostředí Java produktu Tivoli Access Manager pro protokolování adresáře TCD (Tivoli Common Directory). viz “Společné adresáře souborů protokolu” na stránce 174, pokud chcete získat více informací o adresáři TCD.
302
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [pdwpm] Tento záznam objektu stanza pro konfiguraci informací o verzi Web Portal Manager produktu Tivoli Access Manager je umístěný v objektu stanza [meta-info] tohoto konfiguračního souboru pdwpm.conf. Tento konfigurační soubor vypisuje také možné adresáře, které mohou být použité pro přizpůsobení souborů .gif. Záznam objektu stanza není použitý pro vypsání jmen a umístění obrazových souborů. stanza [pdwpm] authMethod = {FORM|BASIC|SSO|TAI} Metoda autentizace. Platné hodnoty zahrnují: FORM Použijte, když je potřebné přihlášení založené na FORM. BASIC Použijte, když je potřebná základní autentizace. SSO Použijte pro jednoduché přihlášení, když je Web Portal Manager připojený za WebSEAL. TAI Použijte, když je Web Portal Manager připojený za WebSEAL a je právě používán aplikační server WebSphere Application Server. Tento záznam stanzy je povinný. Předvolená hodnota: FORM Příklad: authMethod = BASIC changePassword = {true|false} Označení, zda se má povolit uživateli Web Portal Manager změna svého hesla. Platné hodnoty zahrnují: true Zobrazí stránky, které umožní uživatelům Web Portal Manager změnit svá hesla. false Nezobrazí stránky, které umožní uživatelům Web Portal Manager změnu svých hesel. Všimněte si, že hesla Web Portal Manager musí dodržovat politiky hesel nastavených administrátorem. Podle předvolby musí hesla obsahovat minimum osmi znaků (skládající se alespoň z jednoho čísla a čtyř písmen) a maximum dvou opakujících se znaků. Tento záznam stanzy je povinný. Předvolená hodnota: true Příklad: changePassword = false
Dodatek A. Referenční informace ke konfiguraci serveru
303
jrteProps = plně_kvalifikovaná_cesta Jméno a umístění souboru vlastností běhového prostředí produktu Tivoli Access Manager. Tento záznam objektu stanza požaduje záznam objektu stanza jrteHost. Poznámka: Tato hodnota je vygenerovaná během konfigurace; neměňte ji. Hodnota plně_kvalifikovaná_cesta se automaticky vyplní během aplikace a nesmí být editovaná. Běh produktu Tivoli Access Manager určí, kterou hodnotu vyplnit. V některých případech produkt Tivoli Access Manager použije klíč verze, aby zjistil, jestli byl na úroveň komponenty Base produktu Tivoli Access Manager aktualizován odpovídající konfigurační soubor. Tento záznam stanzy je povinný. Předvolené instalační umístění pro Windows: instalační_adresář_pd\java\export\pdwpm\pdwpm.properties Předvolené instalační umístění pro UNIX: /opt/PolicyDirector/java/export/pdwpm/pdwpm.properties Příklad pro Windows: jrteProps = C:\Program Files\Tivoli\Policy Director\java\export\pdwpm\pdwpm.properties jrteHost = jméno_hostitele Jméno hostitele konfigurované během instalace Java Runtime. Poznámka: Tato hodnota je vygenerovaná během konfigurace; neměňte ji. Příklady platných jmen hostitelů: v mycomputer.city.company.com v mycomputer Tento záznam objektu stanza požaduje záznam objektu stanza jrteProps. Hodnota jméno_hostitele se vyplní automaticky v průběhu běhové konfigurace. Hodnota jméno hostitele je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Tečka (.) nesmí být posledním znakem jména hostitele. Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Příklad: jrteHost = localhost debug = {true|false} Určí, zda je povolené zobrazení trasování do stdout (standard out). Platné hodnoty zahrnují: true Povolí zobrazení informací o trasování do stdout. false Nepovolí zobrazení informací o trasování do stdout. Tento záznam stanzy je povinný. Předvolená hodnota: false Příklad: debug = true
304
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [ssl] Objekt stanza [ssl] v konfiguračním souboru definuje konfigurační nastavení SSL (Secure Sockets Layer) pro server produktu Tivoli Access Manager. Záznamy objektu stanza pro konfiguraci nastavení SSL produktu Tivoli Access Manager jsou umístěné v objektu stanza [ssl-info] pro každý z těchto konfiguračních souborů: v ivmgrd.conf pro server politik pdmgrd, v ivacld.conf pro autorizační server pdacld, v pd.conf, pokud používáte autorizační server pdacld, v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd. v Konfigurační soubor vašecho správce zdrojů pro konfigurované záznamy SSL. Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor pro vytvoření vašeho vlastního konfiguračního souboru správce zdrojů. Vývojáři plug-inů služeb by měli poskytnout standardní funkce. Než dokončíte plug-iny služeb, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. stanza [ssl] ssl-keyfile = cesta-ke-klíčům-ssl Umístění cesty a jméno souboru souboru klíčů SSL na lokálním systému. Pokud v konfiguračním souboru nebude uveden tento pár klíč-hodnota, aplikace skončí s chybou. Přípona souboru může být libovolná, ale obvykle se používá .kdb. Soubory certifikátů v adresáři musí být přístupné pro uživatele serveru (všechny uživatele). Ujistěte se, že uživatel serveru (například, ivmgr) nebo všichni uživatelů vlastní oprávnění k přístupu do souboru .kdb a pořadač, který obsahuje soubor .kdb. Hodnota jméno a umístění souboru představuje alfanumerický řetězec citlivý na velikost písmen. Poznámka: Jméno souboru, včetně přípony, je generované a nastavené konfigurační utilitou. Needitujte tento záznam objektu stanza. Tento soubor se vytváří a uvedená hodnota se nastavuje pomocí těchto obslužných programů: v Soubor ivmgrd.conf je nastavený pomocí mgrsslcfg. Jméno a cesta jsou pro ivmgrd.conf pevně určeny. v Soubor pd.conf je nastavený pomocí bassslcfg. Jméno a cesta jsou pro pd.conf pevně určeny. v Pro ostatní soubory použijte obslužný program svrsslcfg. Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Jméno je nastavené konfiguračním programem. Předvolené instalační umístění pro UNIX: /var/PolicyDirector/keytab/jméno_serveru.kdb Předvolené instalační umístění pro Windows: instalační_cesta_pd\keytab\jméno_serveru.kdb Příklad pro UNIX pro server politik pdmgrd: ssl-keyfile = /var/PolicyDirector/keytab/ivmgrd.kdb
Dodatek A. Referenční informace ke konfiguraci serveru
305
ssl-keyfile-stash = cesta_k_souboru_pro_uložení_ssl Umístění cesty a jméno souboru souboru pro uložení hesla SSL na lokálním systému. Přípona souboru může být libovolná, ale obvykle se používá .sth. Heslo se používá k ochraně soukromých klíčů v souboru klíčů. Heslo mohlo být uložené v šifrované podobě do souboru pro uložení. Hodnota jméno a umístění souboru představuje alfanumerický řetězec citlivý na velikost písmen. Poznámka: Jméno souboru, včetně přípony, je generované a nastavené obslužným programem konfigurace. Needitujte tento záznam objektu stanza. Tento soubor se vytváří a uvedená hodnota se nastavuje pomocí těchto obslužných programů: v Soubor ivmgrd.conf je nastavený pomocí příkazu mgrsslcfg. Jméno a cesta jsou pro ivmgrd.conf pevně určeny. v Soubor pd.conf je nastavený pomocí příkazu bassslcfg. Jméno a cesta jsou pro pd.conf pevně určeny. v Všechny ostatní jsou nastavené s použitím příkazu svrsslcfg. Cesta je definovaná volbou –d do utility příkazu svrsslcfg. Jméno je definované volbou –n do utility příkazu svrsslcfg. Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Jméno je nastavené konfiguračním programem. Předvolené instalační umístění pro UNIX: var/PolicyDirector/keytab/jméno_serveru.sth Předvolené instalační umístění pro Windows: C:\instalační_cesta_pd\keytab\jméno_serveru.sth Příklad pro Windows pro server pdmgrproxyd: ssl-keyfile-stash = /var/PolicyDirector/keytab/pdmgrproxyd.sth ssl-keyfile-label = označení Označení klíče, které se používá, je-li jiné než předvolba. V hodnotě označení nejsou povoleny dvojité uvozovky. Uživatelsky určené jméno nemá žádnou podporu. Toto označení se vytvoří a uvedená hodnota se nastaví pomocí těchto obslužných programů: v Soubor ivmgrd.conf je nastavený pomocí příkazu mgrsslcfg. v Pro pd.conf se tento parametr nepoužívá. v Všechny ostatní jsou nastavené s použitím příkazu svrsslcfg. Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Jméno je nastavené konfiguračním programem. Příklad pro server politik pdmgrd: ssl-keyfile-label = PD Management Server
306
IBM Tivoli Access Manager: Base: Administrativní příručka
ssl-v3-timeout = počet_vteřin Časový limit relace (ve vteřinách) pro spojení SSL V3 mezi klienty a servery. Hodnota tohoto časového limitu řídí, jak často se provede úplné předávání řídicích signálů mezi klienty a servery produktu Tivoli Access Manager. Platné hodnoty zahrnují: počet_vteřin Platný rozsah hodnot pro počet vteřin je od 10-86400 vteřin, kde 86400 vteřin se rovná 1 dni. Pokud uvedete číslo mimo tento rozsah, použije se předvolená hodnota. Hodnota tohoto časového limitu se vytváří a nastavuje pomocí těchto obslužných programů: v Pro ivmgrd.conf použijte obslužný program mgrsslcfg. v Soubor pd.conf je nastavený pomocí příkazu bassslcfg. Jméno a cesta jsou pro pd.conf pevně určeny. v Všechny ostatní jsou nastavené s použitím příkazu svrsslcfg. Cesta je definovaná volbou –d do utility příkazu svrsslcfg. Jméno je definované volbou –n do příkazu svrsslcfg. Poznámka: Komponenty produktu Tivoli Access Manager nemusí v některých síťových prostředích pracovat s malými hodnotami časových limitů. Tento záznam stanzy je povinný. Předvolená hodnota je závislá na serveru. Příklad: ssl-v3-timeout = 7200. ssl-io-inactivity-timeout = {0|počet_vteřin} Doba (ve vteřinách), po kterou připojení SSL čeká na odpověď, než bude ukončeno. Neexistuje žádná jedna předvolená hodnota, protože konfigurační programy každého ze serverů určují svoji vlastní předvolenou hodnotu. Platné hodnoty zahrnují: 0 Není povolen žádný časový limit. počet_vteřin Časový limit je uveden jako číslo ve vteřinách. Neexistuje žádné omezení rozsahu hodnot časového limitu. Hodnota počet_vteřin se nastavuje pomocí těchto obslužných programů: v Soubor ivmgrd.conf je nastavený pomocí příkazu mgrsslcfg. v Soubor pd.conf je nastavený pomocí příkazu bassslcfg. v Pro ostatní soubory použijte obslužný program svrsslcfg. Tento záznam stanzy je povinný. Předvolená hodnota je závislá na serveru. Příklad: ssl-io-inactivity-timeout = 90 ssl-maximum-worker-threads = počet_vláken
Dodatek A. Referenční informace ke konfiguraci serveru
307
Počet vláken, který může server vytvořit, aby obsloužil příchozí požadavky. Platné hodnoty zahrnují: počet_vláken Počet vláken, který je možný zadat. Platný rozsah musí být rovný 1 nebo větší než 1. Maximální počet se různí, protože je závislý na dostupných prostředcích systému. Tento záznam stanzy je povinný. Předvolená hodnota je závislá na serveru. Příklad: ssl-maximum-worker-threads = 50
308
IBM Tivoli Access Manager: Base: Administrativní příručka
ssl-pwd-life = počet_dnů Doba trvání hesla databázového souboru klíčů, uvedená v počtu dnů. Hodnota doby trvání hesla je při automatickém obnovování hesla řízena hodnotou počet_dnů, která začne platit po spuštění serveru. Platné hodnoty pro počet_dnů je 1 až 7 299 dnů. Pro ruční obnovování hesla je tato hodnota určena hodnotou dodanou příkazem svrsslcfg –chgpwd.Tato hodnota je také zapsána do odpovídajícího konfiguračního souboru. Poznámka: Pokud skončí platnost jak certifikátu, tak i heslu databázového souboru klíčového řetězce (který obsahuje tento certifikát), pak musí být nejprve aktualizováno heslo. Hodnota počet_dnů se vytvoří a nastaví pomocí těchto obslužných programů: v Soubor ivmgrd.conf je nastavený pomocí příkazu mgrsslcfg. v Soubor pd.conf je nastavený pomocí příkazu bassslcfg. v Pro ostatní soubory použijte obslužný program svrsslcfg. Tento záznam stanzy je povinný. Předvolená hodnota je závislá na serveru. Příklad: ssl-pwd-life = 183 ssl-cert-life = počet_dnů Hodnota doby trvání (ve dnech) certifikátu. Tuto hodnotu používají všechny vydané nebo obnovené certifikáty. Poznámka: Tuto hodnotu používá pouze server politik pdmgrd. Pro server ivmgrd.conf nastavíte počet_dnů pomocí obslužného programu mgrsslcfg. Jméno a cesta jsou pro ivmgrd.conf pevně určeny. Pomocí tohoto obslužného programu změňte uvedenou hodnotu po dokončení výchozí konfigurace. Pro hodnotu počet_dní použijte kladné celé číslo v rozsahu mezi 1 a 7299. Abyste zvýšili nebo snížili tuto hodnotu, změňte ji a restartujte server politik pdmgrd. Nová hodnota začne platit pouze pro certifikáty, které byly vydány nebo obnoveny po této změně. Pokud skončí platnost jak certifikátu, tak i heslu databázového souboru klíčového řetězce (který obsahuje tento certifikát), pak musí být nejprve aktualizováno heslo. Tento záznam stanzy je povinný. Předvolená hodnota je závislá na serveru. Příklad: ssl-cert-life = 365
Dodatek A. Referenční informace ke konfiguraci serveru
309
ssl-auto-refresh = {yes|no} Označuje, zda se bude používat automatická obnova SSL certifikátů a hesla databázového souboru klíčů. Platné hodnoty zahrnují: yes Aktivuje automatickou obnovu. Je-li povoleno, certifikát a heslo se obnoví, i když zanedlouho dojde k ukončení jejich platnosti (zůstává méně než polovina doby trvání). no Vypne automatickou obnovu certifikátů a hesla. Tato hodnota je vytvořena a nastavena pomocí těchto obslužných programů: v Soubor ivmgrd.conf je nastavený pomocí příkazu mgrsslcfg. v Soubor pd.conf je nastavený pomocí příkazu bassslcfg. v Pro ostatní soubory použijte obslužný program svrsslcfg. Tento záznam stanzy je povinný. Předvolená hodnota je závislá na serveru. Příklad: ssl-auto-refresh = yes ssl-local-domain = {Default|jméno_domény} Jméno lokální domény. Server je v této doméně spuštěn. Pokud není tato hodnota uvedena v konfiguračním souboru, operace, které jsou na ní závislé, selžou. Hodnota jméno_domény je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí místního nastavení kódů. Pro proxy server politik (pdmgrproxyd), který má obsahovat domény, by tato hodnota měla být doména správy. Hodnota jména domény je vytvořená během konfigurace, ale lze ji změnit použitím jedné z těchto utilit: v Soubor ivmgrd.conf lze změnit s použitím příkazu mgrsslcfg. v Soubor pd.conf lze změnit s použitím příkazu bassslcfg. v Všechny ostatní lze změnit s použitím příkazu svrsslcfg. Tento záznam stanzy je povinný. Předvolená hodnota pro všechny servery: Předvolená Příklad: ssl-local-domain = Default ssl-authn-type = certificate Typ autentizace. Tato hodnota je vytvořena a nastavena během konfigurace pro autentizační server pdacld a proxy server politik pdmgrproxyd. Avšak, záznam objektu stanza není použitý pro server politik pdmgrd. Tento záznam objektu stanza je požadovaný pouze pro autentizační proxy server a proxy server politik. Předvolená hodnota pro všechny servery: certifikát Příklad: ssl-authn-type = certificate
310
IBM Tivoli Access Manager: Base: Administrativní příručka
ssl-listening-port = {0|port} Naslouchací TCP port pro příchozí požadavky. Platné hodnoty zahrnují: 0 Zakazuje naslouchání. Hodnota je určena během konfigurace pomocí obslužného programu svrsslcfg. port Aktivuje naslouchání na uvedeném čísle portu. Platný rozsah pro hodnotu port je kladné číslo, které je povolené protokolem TCP/IP a není momentálně používáno jinou aplikací. Neexistuje žádná jedna předvolená hodnota, protože konfigurační programy každého z démonů určují svoji vlastní předvolenou hodnotu. Například, při konfiguraci proxy serveru politik je uživateli nabízený port s číslem 8139 jako předvolba. Tato hodnota je potom použitá pro volání konfigurační utility SSL. Předvolená hodnota je 0, pokud není uvedena jiná během konfigurace. Jinak je hodnota závislá na serveru. Server politik pdmgrd nepoužívá záznam objektu stanza. Tento záznam objektu stanza je povinný, kromě serveru pdmgrd. Příklad: ssl-listening-port = 8139
Dodatek A. Referenční informace ke konfiguraci serveru
311
stanza [ssl] pro ldap.conf Konfigurační soubor ldap.conf definuje konfigurační nastavení SSL pro server LDAP. Záznamy objektů stanza pro konfiguraci nastavení SSL jsou umístěné v objektu stanza [ssl] těchto konfiguračních souborů: v soubor ldap.conf pro server LDAP. stanza [ssl] ssl-local-domain = {Default|jméno_domény} Jméno lokální domény. Server je v této doméně spuštěn. Pokud není tato hodnota uvedena v konfiguračním souboru, operace, které jsou na ní závislé, selžou. Hodnota jméno_domény je alfanumerický řetězec citlivý na velikost písmen. Hodnota jméno domény je vytvořená a nastavená s použitím obslužného programu příkazu svrsslcfg: Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Jméno je nastavené konfiguračním programem. Příklad: ssl-local-domain = Default
312
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [uraf-registry] Objekt stanza URAF (User Registry Adapter Framework) je povinný, když typ konfigurovaného registru není LDAP. Záznamy objektů stanza pro konfiguraci nastavení registrů založených na URAF pro server jsou umístěné v objektu stanza [uraf-registry] těchto konfiguračních souborů: v ivmgrd.conf pro server politik pdmgrd, v ivacld.conf pro autorizační server pdacld, v pdmgrproxyd.conf pro proxy server politik pdmgrproxyd, v konfigurační soubor vašeho správce zdrojů pro typy konfigurovaných registrů, které nejsou LDAP. Navíc, můžete nastavit další záznamy objektů stanza v objektu stanza [uraf-registry] konfiguračních souborů activedir.conf, activedir_ldap.conf nebo domino.conf. Konfigurační soubor, který je použitý, závisí na typu registru uživatelů URAF, který konfigurujete. Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor pro vytvoření vašeho vlastního konfiguračního souboru správce zdrojů. Vývojáři plug-inů služeb by měli poskytnout standardní funkce. Než dokončíte plug-iny služeb, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. Většina informací o tomto objektu stanza je vyplněna během konfigurace. Výjimku tvoří položky vztahující se k paměti cache, které musí být aktualizované manuálně administrátorem produktu Tivoli Access Manager. Záznamy objektů stanza cache-mode, cache-size a cache-lifetime se neobjevují v konfiguračním souboru ivmgrd.conf, protože objekt serveru politik by neměl být ukládán do paměti cache. Poznámka: Neumísťujte následující záznamy objektů stanza do objektů stanza [uraf-registry] konfiguračních souborů activedir.conf, activedir_ldap.conf nebo domino.conf. uraf-registry-config = C:\PROGRA~1\Tivoli\POLICY~1\etc\activedir.conf bind-id = ivmgrd-master
Dodatek A. Referenční informace ke konfiguraci serveru
313
stanza [uraf-registry] uraf-registry-config = plně_kvalifikovaná_cesta Jméno a umístění konfiguračního souboru registru URAF pro produkt Tivoli Access Manager. Hodnota plně_kvalifikovaná_cesta představuje alfanumerický řetězec. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″). Pro UNIX jsou cesta a jména souborů citlivá na velikost písmen. Tento záznam stanzy je povinný, není-li typ konfigurovaného registru LDAP. Předvolená hodnota je závislá na serveru. Je generovaná; ale lze ji měnit. Konfigurační soubory předvoleného registru URAF mohou být následující: v domino.conf v activedir.conf v activedir_ldap.conf Příklad pro Windows s použitím IBM Domino jako registr uživatelů klienta Windows: uraf-registry-config = C:\Program Files\Tivoli\Policy Director\etc\ domino.conf Příklad pro Windows s použitím registru uživatelů serveru Microsoft Active Directory pro platformy jiné než Windows 2000: uraf-registry-config = c:\Program files\tivoli\Policy Director\etc \activedir_ldap.conf Příklad používající server Microsoft Active Directory jako registr klienta UNIXu: uraf-registry-config = /opt/PolicyDirector/etc/activedir_ldap.conf bind-id = id_serveru ID přihlášení uživatele nebo administrátora serveru, která je použitá pro připojení (přihlášení) do serveru registrů. Tuto ID používá pouze server. Pokud tato ID patří uživateli spíše než administrátorovi, uživatel musí mít privilegia k aktualizaci a upravování dat v registru uživatelů. Pro registr IBM Lotus Domino poskytuje soubor ID Lotus Notes ekvivalent ID připojení. Poznámka: Tato hodnota je vygenerovaná během konfigurace; neměňte ji. Hodnota id_serveru je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí místního nastavení kódů. Minimální a maximální délky ID, pokud taková omezení existují, jsou určena příslušným registrem. Maximální délka pro Active Directory je 256 alfanumerických znaků. Tento záznam stanzy je povinný, není-li typ konfigurovaného registru LDAP. Předvolená hodnota je specifická pro server. Příklad: bind-id = MySvrAdminID
314
IBM Tivoli Access Manager: Base: Administrativní příručka
cache-mode = {enabled|disabled} Režim pro ukládání do paměti cache, který představuje paměť cache, která je buď aktivovaná nebo vypnutá. Poznámka: Tento záznam objektu stanza se neobjevuje v konfiguračním souboru ivmgrd.conf, protože nechcete, aby byl objektů serveru politik uložený do paměti cache. Platné hodnoty zahrnují: enabled Aktivuje paměť cache. Aktivovali byste režim paměti cache, čímž by došlo ke zlepšení výkonu opakovaných akcí Read (čtení) jako: výkon přihlášení, které se provádí více než jednou za den. Výkon pro akce Write (zápis) by se nezlepšil. disabled Vypne paměť cache. Vypnuli byste režim paměti cache pro lepší zabezpečení. Ukládání do paměti cache otevírá pro uživatelé malé okno, které umožňuje přecházet ze serveru do serveru v takovém pořadí, aby byl vynechán maximální počet selhaných pokusů o přihlášení. Tento záznam stanzy je volitelný. Tento záznam objektu stanza je normálně poskytovaný pro všechny servery produktu Tivoli Access Manager kromě serveru politik pdmgrd. Předvolená hodnota: enabled Příklad: cache-mode = enabled cache-lifetime = počet_vteřin Čas (ve vteřinách), jak dlouho je objektům umožněno zůstat v paměti cache. Platné hodnoty zahrnují: počet_vteřin Časový limit je uveden jako číslo ve vteřinách. Použijte číslo v rozsahu od 1 do 86400. Poznámka: Tento záznam objektu stanza se neobjevuje v konfiguračním souboru ivmgrd.conf, protože nechcete, aby byl objekt serveru politik uložený do paměti cache. Je-licache-mode = enabled a tento záznam objektu stanza není použitý, bude použitá předvolená hodnota 30 vteřin. Vzhledem k ladění výkonu, čím delší je uvedený čas, tím déle je podržena výhoda opakované akce Read (čtení). Menší počet vteřin ruší výhodu paměti cache pro akce Read iniciované uživatelem. Tento záznam stanzy je volitelný. Předvolená hodnota: 30 vteřin. Příklad: cache-lifetime = 63200
Dodatek A. Referenční informace ke konfiguraci serveru
315
cache-size = {počet_objektů|typ objektu:hodnota součtu paměti cache Maximální počet objektů pro daný typ objektu, který lze umístit do paměti cache současně bez výskytů kolizí transformačních tabulek. Nebo, pokud není numerický, je připojený seznam více typů objektů a jejich hodnot součtů paměti cache. Poznámka: Tento záznam objektu stanza se neobjevuje v konfiguračním souboru ivmgrd.conf, protože nechcete, aby byl objekt serveru politik uložený do paměti cache. Je-li cache-mode = enabled a tento záznam objektu stanza její použitý, bude použitá předvolená hodnota velikosti paměti cache. Platné hodnoty zahrnují: počet_objektů Maximální počet objektů musí být prvočíslo pro hodnoty součtů pamětí cache. Hodnota rozsahu je od 3 do maximálního počtu, který je logický pro danou úlohu a který neovlivní výkon. Neprvočísla jsou automaticky zaokrouhlená nahoru k následujícímu prvočíslu. Pokud dojde k selhání čísla, bude použita předvolená hodnota. typ objektu:hodnota součtu paměti cache Seznam jednoho nebo více typů objektů a jejich hodnot součtů pamětí cache. Příklady: cache-size = user:251;group:251;resgroup:251;resource:251; rescreds:251; nebo cache-size = user:251;group:251; Druhý příklad nastaví velikosti pamětí cache skupiny a uživatele na 251 a nepoužívá žádnou paměť cache pro ostatní. Ladění výkonu závisí na tom, kolik prostoru paměti je vyhrazeno pro paměť cache a kolik objektu má obvykle aktivováno opakované akce Read (jako například, kolik uživatelů se přihlásí za den). Například, nastavení 251 by nemuselo být dobré, kdyby se se během dne několikrát přihlásilo a odhlásilo 1000 uživatelů. Avšak, pokud se během dne opakovaně přihlásí a odhlásí pouze 200 z těch uživatelů, 251 by mohlo fungovat spolehlivě. Tento záznam stanzy je volitelný. Předvolená hodnota je specifická pro server. Příklad: cache-size = 251
316
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [uraf-registry] pro domino.conf Záznamy objektů stanza pro konfiguraci serveru IBM Lotus Domino jako registru uživatelů jsou umístěné v objektu stanza [uraf-registry] tohoto konfiguračního souboru: v domino.conf pro konfiguraci IBM Lotus Domino jako serveru registru uživatelů. stanza [uraf-registry] enabled = {yes|no} Určení, zda se Domino bude používat jako registr uživatelů. Platné hodnoty zahrnují: yes Označuje, že Domino je používaným registrem uživatelů. no Označuje, že Domino není používaným registrem uživatelů. Cokoli jiného než yes včetně prázdné hodnoty je interpretováno jako no. Tento záznam stanzy je povinný. Předvolená hodnota: no Příklad: enabled = yes server = jméno_serveru Jméno serveru IBM Lotus Domino. Hodnota jméno_serveru představuje alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Minimální a maximální délky jména, pokud taková omezení existují, jsou určena příslušným registrem. Tento záznam stanzy je povinný, je-li enabled = yes. Neexistují žádné předvolené hodnoty. Příklad: server = grizzly/Austin/IBM kde grizzly je jméno hostitele počítače serveru Domino a zbytek je jméno domény Domino. NAB = names.nsf Databáze IBM Lotus Domino NAB (Name and Address Book). Jméno souboru names.nsf se podřizuje konvencím pojmenování základního souboru operačního systému serveru Domino. Tento záznam stanzy je povinný, je-li enabled = yes. Databáze names.nsf je nastavena během konfigurace a nelze ji změnit. Přípona jména souboru musí být vždy .nsf. Předvolená hodnota: names.nsf Příklad: NAB = names.nsf
Dodatek A. Referenční informace ke konfiguraci serveru
317
PDM = jméno_souboru_nsf Meta-data databáze produktu Tivoli Access Manager. Hodnota jméno_souboru_nsf představuje jméno databázového souboru Domino. Jméno souboru odpovídá jmenným konvencím příslušného systému souborů operačního systému Domino serveru. Databáze je vytvořená na serveru Domino během konfigurace a nelze ji měnit. Doporučená přípona jména souboru je .nsf. Tento záznam stanzy je povinný, je-li enabled = yes. Předvolená hodnota: PDMdata.nsf Příklad: PDM = PDMdata.nsf
318
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [uraf-registry] pro activedir.conf Záznam objektu stanza pro konfiguraci serveru Microsoft Active Directory jako registru uživatelů je umístěný v objektu stanza [uraf-registry] tohoto konfiguračního souboru: v activedir.conf pro konfiguraci serveru Microsoft Active Directory jako registru uživatelů. stanza [uraf-registry] enabled = {yes|no} Určení, zda se Active Directory bude používat jako registr uživatelů. Platné hodnoty zahrnují: yes
Označuje, že Active Directory je použitý jako registr uživatelů.
no
Označuje, že Active Directory není použitý jako registr uživatelů. Cokoli jiného než yes včetně prázdné hodnoty je interpretováno jako no.
Tento záznam stanzy je povinný, je-li vaším registrem uživatelů produktu Microsoft Active Directory. Předvolená hodnota: no Příklad: enabled = yes multi-domain = {true|admd|ammd|false} Označení, zda doména je nakonfigurována jako jediná doména nebo jako více domén. Je provedena selekce v průběhu běhové konfigurace produktu Tivoli Access Manager. Poznámka: Tento záznam objektu stanza je nastavený během konfigurace; needitujte jej. Platné hodnoty zahrnují: true|admd Pro jednoduchou doménu produktu Tivoli Access Manager s více doménami Active Directory. ammd Pro jednoduché domény produktu Tivoli Access Manager znamenajícími více domén Active Directory. false Jediná doména Active Directory. Tento záznam stanzy je povinný, je-li vaším registrem uživatelů produktu Microsoft Active Directory. Neexistují žádné předvolené hodnoty. Příklad: multi-domain = true hostname = jméno_hostitele Jméno hostitele DNS Active Directory. Příklady platných jmen hostitelů: v mycomputer.city.company.com v mycomputer Hodnota jméno_hostitele se vyplní automaticky v průběhu běhové konfigurace. Hodnota jméno hostitele je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Tečka (.) nesmí být posledním znakem jména hostitele. Maximální délka řetězce registru uživatelů Active Directory je 256 alfanumerických znaků. Tento záznam stanzy je povinný, je-li vaším registrem uživatelů produktu Microsoft Active Directory. Neexistují žádné předvolené hodnoty. Příklad: hostname = adserver.tivoli.com
Dodatek A. Referenční informace ke konfiguraci serveru
319
domain = jméno_kořenové_domény Kořenová (primární) doména produktu Active Directory. Toto jméno je závislé na doméně založené na tom, co zvolíte v průběhu běhové konfigurace produktu Tivoli Access Manager. Hodnota jméno_kořenové_domény je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Maximální délka jména domény je závislá na registru uživatelů. Maximální délka pro Active Directory je 256 alfanumerických znaků. Tento záznam objektu stanza je povinný, když je váš registr uživatelů server Microsoft Active Directory a když multi-domain = {true|admd}. Neexistují žádné předvolené hodnoty. Příklad: domain = dc=tivoli,dc=com useEncryption = {true|false} Označení, zda se bude v Active Directory používat zašifrovaná komunikace. Tato hodnota je uvedená při běhové konfiguraci produktu Tivoli Access Manager. Platné hodnoty zahrnují: true Aktivuje šifrování komunikací. false Zakazuje šifrování komunikací. Tento záznam stanzy je povinný, je-li vaším registrem uživatelů produktu Microsoft Active Directory. Neexistují žádné předvolené hodnoty. Příklad: useEncryption = false dnforpd = ad_dn Rozlišovací jméno, které používá Active Directory k ukládání dat produktu Tivoli Access Manager. Poznámka: Tento záznam objektu stanza je nastavený během konfigurace; neměňte jej. Hodnota ad_dn je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Minimální a maximální délky ID, pokud taková omezení existují, jsou určena příslušným registrem. Maximální délka pro Active Directory je 256 alfanumerických znaků. Tento záznam stanzy je povinný, je-li vaším registrem uživatelů produktu Microsoft Active Directory. Neexistují žádné předvolené hodnoty. Příklad: dnforpd = dc=child2,dc=com
320
IBM Tivoli Access Manager: Base: Administrativní příručka
stanza [uraf-registry] pro activedir_ldap.conf Pokud používáte klienta LDAP pro načítání dat pro registr uživatelů Active Directory, na který je server Tivoli Access Manager konfigurovaný, musíte vlastnit konfigurační soubor serveru activedir_ldap.conf. Pomocí tohoto konfiguračního souboru přizpůsobíte činnost každého serveru registrů Active Directory. Tyto záznamy objektů stanza pro konfiguraci serveru Microsoft Active Directory jako registru uživatelů na serveru produktu Tivoli Access Manager jsou umístěné v objektu stanza [uraf-registry] tohoto konfiguračního souboru: v activedir_ldap.conf. stanza [uraf-registry] enabled = {yes|no} Určení, zda se Active Directory bude používat jako registr uživatelů. Platné hodnoty zahrnují: yes
Označuje, že Active Directory je registr uživatelů.
no
Označuje, že Active Directory není použitý jako registr uživatelů. Cokoli jiného než yes včetně prázdné hodnoty je interpretováno jako no.
Tento záznam stanzy je povinný, je-li vaším registrem uživatelů produktu Microsoft Active Directory. Předvolená hodnota: no Příklad: enabled = yes multi-domain = {true|admd|ammd|false} Označení, zda doména je nakonfigurována jako jediná doména nebo jako více domén. Je provedena selekce v průběhu běhové konfigurace produktu Tivoli Access Manager. Poznámka: Tento záznam objektu stanza je nastavený během konfigurace; needitujte jej. Platné hodnoty zahrnují: true|admd Pro jednoduchou doménu produktu Tivoli Access Manager s více doménami Active Directory. ammd Pro jednoduché domény produktu Tivoli Access Manager znamenajícími více domén Active Directory. false Jediná doména Active Directory. Tento záznam stanzy je povinný, je-li vaším registrem uživatelů produktu Microsoft Active Directory. Neexistují žádné předvolené hodnoty. Příklad: multi-domain = true UseSSL = {yes|no} Určuje, zda se bude nebo nebude používat protokol SSL. Platné hodnoty: yes Určuje, že chcete používat SSL. no Určuje, že nechcete používat SSL. Tento záznam stanzy je povinný. Předvolená hodnota: yes Příklad: usessl = no
Dodatek A. Referenční informace ke konfiguraci serveru
321
ssl-keyfile = jméno-souboru-klíčů-ssl-ldap Jméno a umístění souboru klíčů SSL. Soubor klíčů SSL se používá při výměně certifikátů používaných v komunikaci s LDAP. Typ souboru může být libovolný, ale přípona je obvykle .kdb. Soubory certifikátů v adresáři musí být přístupné pro uživatele serveru (všechny uživatele). Ujistěte se, že uživatel serveru (například, ivmgr) nebo všichni uživatelů vlastní oprávnění k přístupu do souboru .kdb a pořadač, který obsahuje soubor .kdb. Hodnota jméno a umístění souboru představuje alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Nastavení znaků povolených ve jméně souboru může být určeno systémem souborů a lokálním nastavením kódů. V operačním systému Windows nemohou jména souborů používat tyto znaky: zpětné lomítko (\), dvojtečku(:), otazník (?), nebo dvojité uvozovky (″). Maximální délka řetězce registru uživatelů Active Directory je 256 alfanumerických znaků. Tento záznam stanzy je povinný pouze v případě, že je nastaveno ssl-enabled = yes. Předvolená hodnota je závislá na serveru. Předvolená hodnota pro Windows: instalační_adresář_pd\keytab\jméno_serveru.kdb Předvolená hodnota pro UNIX: /opt/PolicyDirector/keytab/jméno_serveru.kdb Příklad pro UNIX pro server politik pdmgrd: ssl-keyfile = /opt/PolicyDirector/keytab/ivmgrd.kdb ssl-keyfile-label = označení_klíče Uvádí označení klíče, které se používá pro identifikaci certifikátu klienta, který je předložen serveru LDAP. Je to označení klíče osobního certifikátu klienta v souboru klíčů SSL. Hodnota označení_klíče je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Minimální a maximální délky ID, pokud taková omezení existují, jsou určena příslušným registrem. Označené klíče musí být ohraničeno dvojitými uvozovkami. Tento záznam stanzy je povinný, je-li server LDAP nakonfigurován pro provádění autentizace klientů. Neexistují žádné předvolené hodnoty. Příklad: ssl-keyfile-label = "PDLDAP"
322
IBM Tivoli Access Manager: Base: Administrativní příručka
ssl-keyfile-pwd = heslo-souboru-klíčů-ssl-ldap Heslo pro přístup do souboru klíčů SSL. Heslo vztahující se k předvoleného souboru klíčů SSL je key4ssl. Tento záznam stanzy je povinný pouze, je-li enabled = yes. Neexistují žádné předvolené hodnoty. Příklad: ssl-keyfile-pwd = key4ssl primary-domain = jméno_primární_domény Jméno hostitele primární domény Active Directory a žádné nebo více replikovaných jmen hostitele. Je povolen pouze jeden záznam primární domény. Toto jméno je závislé na doméně založené na tom, co zvolíte v průběhu běhové konfigurace produktu Tivoli Access Manager. Hodnota jméno_primární_domény je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Maximální délka jména domény je závislá na registru uživatelů. Maximální délka pro Active Directory je 256 alfanumerických znaků. Pro konfiguraci více domén Active Directory musí primární doména obsahovat informace o kořenové doméně. Pro konfiguraci jedné domény Active Directory mohou být pro informace o doméně použity záznamy objektů stanza buď primary-domain = nebo domain =. Syntaxe je: primary-domain = jjj:hhh[:rrr1[:rrr2[:...]]] Kde: jjj
Jméno primární domény. Formát jména je buď ibm.com nebo dc=ibm,dc=com.
hhh
Jméno hostitele primární domény nebo adresa IP.
rrr
Replikované jméno hostitele primární domény nebo adresa IP.
Hranaté závorky ( [ ] ) zobrazují záznamy, které jsou volitelné a požadovaná dvojtečka ( : ) slouží jako oddělovač. Tento záznam stanzy je povinný. Neexistují žádné předvolené hodnoty. Příklad (zapsaný na řádku) bez mezer: primary-domain = dc=ibm,dc=com:adprim.ibm.com: adprimreplica1.ibm.com
Dodatek A. Referenční informace ke konfiguraci serveru
323
domain = jméno_sekundární_domény Jméno Active Directory nebo jméno hostitele sekundární nebo podřízené domény. Toto jméno hostitele je ve stejném globálním stromu jako kořenová doména, její jméno hostitele a žádné nebo více replikovaných jmen hostitele. Toto jméno je závislé na doméně založené na tom, co zvolíte v průběhu běhové konfigurace produktu Tivoli Access Manager. Hodnota jméno_sekundární_domény je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Maximální délka jména domény je závislá na registru uživatelů. Maximální délka pro Active Directory je 256 alfanumerických znaků. Pro konfiguraci jedné domény Active Directory mohou být pro informace o jména domény použity záznamy objektů stanza buď primary-domain = nebo domain =. Pro konfiguraci více domén Active Directory jsou povolené záznamy jmen více domén. Syntaxe je: domain = jjj:hhh[:rrr1[:rrr2[:...]] kde: jjj
Jméno sekundární nebo podřízené domény. Formát jména je buď ibm.com nebo dc=ibm,dc=com.
hhh
Jméno hostitele sekundární nebo podřízené domény nebo adresa IP.
rrr
Replikované jméno hostitele sekundární nebo podřízené domény nebo adresy IP.
Hranaté závorky ( [ ] ) zobrazují záznamy, které jsou volitelné a požadovaná dvojtečka ( : ) slouží jako oddělovač. Tento záznam objektu stanza je povinný, když je váš registr uživatelů server Microsoft Active Directory a když multi-domain = {true|admd}. Neexistují žádné předvolené hodnoty. Příklad (zapsaný na řádku) bez mezer: domain = dc=child.ibm.com:adhost.child.ibm.com: adhostreplica.child.ibm.com ldap-client-timeout = {0|počet_vteřin} Čas, který je povolení pro jednoduché připojení LDAP a po který LDAP prohledává klienta LDAP, než je považovaný za odpojeného. Platné hodnoty zahrnují: 0 Neomezený čas, ve vteřinách, povolený pouze pro synchronní operace. počet_vteřin Čas, ve vteřinách, povolený pro asynchronní operace. Počet vteřin je uvedený jako kladné celé číslo. Doporučený rozsah je mezi 240 a 900 vteřinami. Tento záznam stanzy je povinný. Předvolená hodnota: 0 Příklad: ldap-client-timeout = 520
324
IBM Tivoli Access Manager: Base: Administrativní příručka
dnforpd = ad_dn Rozlišovací jméno, které používá Active Directory k ukládání dat produktu Tivoli Access Manager. Poznámka: Tento záznam objektu stanza je nastavený během konfigurace; neměňte jej. Hodnota ad_dn je alfanumerický řetězec citlivý na velikost písmen. Předpokládá se, že hodnoty řetězce budou znaky, které jsou součástí lokálního nastavení kódů. Minimální a maximální délky ID, pokud taková omezení existují, jsou určena příslušným registrem. Maximální délka pro Active Directory je 256 alfanumerických znaků. Tento záznam stanzy je povinný, je-li vaším registrem uživatelů produktu Microsoft Active Directory. Neexistují žádné předvolené hodnoty. Příklad: dnforpd = dc=child2,dc=com
Dodatek A. Referenční informace ke konfiguraci serveru
325
stanza [xmladi-attribute-definitions] Zázanmy objektů stanza pro konfiguraci definic atributů dokumentu ADI XML (Access Decision Information eXtensible Markup Language) jsou umístěné v objektu stanza [xmladi-attribute-definitions]. Tento objekt stanza lze nalézt nebo umístit do libovolného z konfiguračních souborů Tivoli Access Manager, kromě konfiguračního souboru pd.conf. Konfigurační soubor aznAPI.conf je poskytovaný produktem Tivoli Access Manager jako ukázkový soubor pro vytvoření vašeho vlastního konfiguračního souboru správce zdrojů. Vývojáři plug-inů služeb by měli poskytnout standardní funkce. Než dokončíte plug-iny služeb, přečtěte si a snažte se dobře pochopit koncepty, kterými se zabývá publikace IBM Tivoli Access Manager for e-business Authorization C API Developer Reference. stanza [xmladi-attribute-definitions] JménoAtributu = "HodnotaAtributu" Definice atributů dokumentů ADI XML, které jsou vložené do příznaků spouštění prvků, umožňují definování atributů pro celé dokumenty XML ADI a pro všechny ADI definované v dokumentu XML ADI. Model ADI XML požaduje, aby dokument XML obsahoval následující prvky XML nejvyšší úrovně, do kterých jsou vkládané všechny cílové ADI pro dané vyhodnocení pravidel. Prvek XMLADI se vytvoří automaticky jako součást procesu vyhodnocování pravidel autorizačním jádrem. <XMLADI>
Tento záznam stanzy je povinný. Příklady pro dva atributy: xmlns:myNS = "http://myURI.mycompany.com" appID = ’"Jupiter" - Account Management Web Portal Server #1.’ Hodnota atributu musí být ohraničená dvojitými nebo jednoduchými uvozovkami. Příznak spouštění prvku XMLADI vystavěný z těchto definic je: <XMLADI xmlns:myNS="http://myURI.mycompany.com" \ appID=’"Jupiter" - Account Management Web Portal Server #1.’> Podrobnější informace najdete v části Kapitola 10, “Správa autorizačních pravidel”, na stránce 99.
326
IBM Tivoli Access Manager: Base: Administrativní příručka
Dodatek B. Rozdíly v registrech uživatelů V této verzi produktu IBM Tivoli Access Manager (Tivoli Access Manager) jsou známy následujících rozdílů v registrech uživatelů. 1. Pokud produkt Tivoli Access Manager používá buď Microsoft Active Directory nebo server Lotus Domino jako svůj registr uživatelů, je podporovaná pouze jedna doména. Použijte registr uživatelů LDAP, pokud si přejete využít podporu pro více domén v produktu Tivoli Access Manager. 2. Produkt Tivoli Access Manager nepodporuje členství napříč skupinami domén nebo univerzální skupiny, když je používán Microsoft Active Directory jako registr uživatelů. Import takových skupin do produktu Tivoli Access Manager není podporován. 3. Pokud server politik produktu Tivoli Access Manager používá jako svůj registr uživatelů buď produkt Microsoft Active Directory, nebo Lotus Domino server, stávající klienti Tivoli SecureWay Policy Director verze 3.8 nebudou schopni se připojit k tomuto serveru politik. Použijte buď jiný typ registru uživatelů, nebo klienty převeďte na vyšší verzi produktu Tivoli Access Manager. 4. Uživatelům, vytvořeným v registru uživatelů Lotus Domino server nebo Microsoft Active Directory, je automaticky udělena schopnost vlastnit pověření jednotného přihlášení a tato schopnost nemůže být odstraněna. Pokud používáte registr uživatelů LDAP, musíte tuto schopnost uživateli explicitně udělit a následně ji můžete také odstranit. 5. Úvodní a koncové mezery ve jménech uživatelů a jménech skupin se ignorují, používá-li se jako registr uživatelů v zabezpečené doméně Tivoli Access Manager produkt Microsoft Active Directory nebo produkt LDAP. Pokud se však jako registr uživatelů používá Lotus Domino server, pak jsou úvodní a koncové mezery významné. Aby bylo zajištěno, že zpracování bude konzistentní bez ohledu na to, jaký typ registru uživatelů bude použit, nadefinujte uživatele a skupiny do registru uživatelů bez úvodních a koncových mezer v jejich jménech. 6. Znak lomítko (/) by se neměl používat ve jménech uživatelů a skupin, definovaných pomocí řetězců rozlišovacího jména. Lomítko se v různých registrech uživatelů rozdílně interpretuje: server Lotus Domino Uživatele a skupiny nelze vytvořit se jmény používajícími řetězec rozlišovacího jména, který obsahuje znak lomítka. Chcete-li se vyvarovat problémů, nepoužívejte znak lomítka nebo nadefinujte uživatele bez použití označení rozlišovacího jména: pdadmin user create mujuživatel jménouživatele/lokalita test test testheslo
namísto: pdadmin user create mujuživatel cn=jménouživatele/o=lokalita test test testheslo
Microsoft Active Directory Uživatele a skupiny je možné vytvořit se jmény používajícími řetězec rozlišovacího jména se znakem lomítka. Avšak některé následné operace s objektem mohou selhat, jelikož některé funkce Active Directory interpretují znak lomítka jako oddělovač mezi jménem objektu a jménem hostitele. Chcete-li se vyvarovat problémů, nepoužívejte znak lomítka při definici uživatele.
7. Pokud používáte vícedoménový registr uživatelů produktu Microsoft Active Directory, pak je možné nadefinovat více uživatelů a skupin se stejným krátkým jménem, pokud jsou tito umístěni v různých doménách. Avšak, plné jméno uživatele nebo skupiny včetně přípony domény musí být do produktu Tivoli Access Manager vždy uvedeno. 8. Pokud používáte jako registr uživatelů produkt iPlanet Version 5.0, pak uživatel, který byl vytvořen, přidán do skupiny a pak odstraněn z registru uživatelů, zůstává členem své skupiny. Pokud bude později vytvořen uživatel se stejným jménem, nový uživatel automaticky převezme členství ve skupinách bývalého uživatele a tak mu mohou být poskytnuta neodpovídající oprávnění. Důrazně se doporučuje, abyste uživatele vymazali ze všech skupin, než vymažete vlastního uživatele. Tento problém se nevyskytuje u žádného z dalších podporovaných registrů uživatelů. 9. Pokus o přidání jednoduchého duplicitního uživatele do skupiny nevytvoří chybu, je-li používán registr uživatelů LDAP. Avšak, pří používání serveru Lotus Domino nebo Microsoft Active Directory je chyba řádně reflektovaná. 10. Autorizační API produktu Tivoli Access Manager poskytuje službu nároků atributů pověření. Tato služba je použitá pro načtení atributů uživatele z registru uživatelů. Pokud je tato služba použitá registrem uživatelů LDAP, načtené atributy mohou být buď řetězec nebo binární data. Avšak, pokud je tato služba použitá registrem uživatelů Microsoft Active Directory nebo Lotus Domino, načtené atributy mohou být buď řetězec, binární nebo celočíselná data. 11. Maximální délky rozdílných jmen vztahujících se k produktu Tivoli Access Manager se liší v závislosti na používaném registru uživatelů.Tabulka 11 nabízí porovnání povolených maximálních délek a doporučovaných maximálních délek, které je možné použít k zajištění kompatibility mezi všemi registry uživatelů podporovanými produktem Tivoli Access Manager. Tabulka 11. Maximální délky jmen v závislosti na registrech uživatelů Maximální délka:
328
LDAP
Microsoft Active Directory
Lotus Domino server
Doporučovaná maximální hodnota
Křestní jméno (LDAP CN)
256
64
960
64
Druhé jméno
128
64
65535
64
Poslední jméno (příjmení)
128
64
960
64
UID registru (LDAP DN)
1024
2048
255
Tato hodnota je závislá na registru uživatelů a musí být změněna, měníte-li registry uživatelů.
Totožnost uživatele Tivoli Access Manager
256
Heslo uživatele
neomezeno
256
neomezeno
256
Popis uživatele
1024
1024
1024
1024
Jméno skupiny
256
Popis skupiny
1024
IBM Tivoli Access Manager: Base: Administrativní příručka
2048 - 1 200 - 4 délka_jm_domény délka_jm_domény
Tato hodnota je závislá na registru uživatelů a musí být změněna, měníte-li registry uživatelů.
256 1024
1024
1024
Tabulka 11. Maximální délky jmen v závislosti na registrech uživatelů (pokračování) Maximální délka:
LDAP
Microsoft Active Directory
Lotus Domino server
Doporučovaná maximální hodnota
Jméno zdroje jednotného přihlášení
240
256
256
240
Popis zdroje jednotného přihlášení
1024
1024
1024
1024
ID uživatele jednotného přihlášení
240
256
256
240
neomezeno
256
neomezeno
256
Jméno skupiny jednotného přihlášení
240
256
256
240
Popis skupiny jednotného přihlášení
1024
1024
1024
1024
1
1
1
1
Popis akce, typ akce
neomezeno
neomezeno
neomezeno
Jméno objektu, jméno prostoru objektů, jméno ACL, jméno POP
neomezeno
neomezeno
neomezeno
Popis objektu, popis prostoru objektů, popis ACL, popis POP
neomezeno
neomezeno
neomezeno
Heslo jednotného přihlášení
Jméno akce
Přestože některá jména mohou mít neomezenou délku, výsledkem používání přílišných délek může být politika, kterou bude těžké spravovat a která může vést ke špatné výkonnosti systému. Zvolte maximální hodnoty, které jsou ve vašem prostředí logické.
Dodatek B. Rozdíly v registrech uživatelů
329
330
IBM Tivoli Access Manager: Base: Administrativní příručka
Dodatek C. Ekvivalenty Web Portal Manager a příkazového řádku administrativy Tento Dodatek zobrazuje mapování, které existuje mezi rozhraním příkazového řádku (CLI) administrativypdadmin a Web Portal Manager. Informace o rozhraní příkazového řádku pdadmin lze nalézt v publikaci IBM Tivoli Access Manager for e-business Command Reference. Tabulka 12. Mapování mezi CLI administrativy a Web Portal Manager pdadmin CLI
Web Portal Manager
acl attach jméno_objektu jméno_acl
ACL → Vypsat ACL → klepnout na jméno POP → ouško Připojit → Připojit
acl create jméno_acl
ACL → Vytvořit ACL
acl delete jméno_acl
ACL → Vypsat ACL → zvolit jména ACL → Vymazat
acl detach jméno_objektu
ACL → Vypsat ACL → klepnout na jméno ACL → ouško Připojit → zvolit jména objektů → Odpojit
acl find jméno_acl
ACL → Vypsat ACL → klepnout na jméno ACL → ouško Připojit
acl list
ACL → Vypsat ACL
acl list jméno_acl attribute
ACL → Vypsat ACL → klepnout na jméno ACL → ouško Rozšířené atributy
Prostor objektů → Procházet prostor objektů → rozbalit a klepnout na jméno objektu → ouško Rozšířené atributy → zvolit atribut → Vymazat
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 12. Mapování mezi CLI administrativy a Web Portal Manager (pokračování) pdadmin CLI
Web Portal Manager
object modify jméno_objektu set attribute jméno_atributu hodnota_atributu
Prostor objetků → Procházet prostor objektů → rozbalit a klepnout na jméno objektu → ouško Rozšířené atributy → Vytvořit
object modify object_name set description description
Prostor objetků → Procházet prostor objektů → rozbalit a klepnout na jméno objektu → ouško Obecné → Použít
object modify jméno_objektu isPolicyAttachable Prostor objektů → Procházet prostor objektů {yes|no} → rozbalit a klepnout na jméno objektu → ouško Obecné → Použít object modify jméno_objektu type typ
Není podporováno
object show jméno_objektu
Prostor objektů → Procházet prostor objektů → rozbalit a klepnout na jméno objektu→ ouško Obecné
object show jméno_objektu attribute jméno_atributu
Prostor objektů → Procházet prostor objektů → rozbalit a klepnout na jméno objektu → ouško Rozšířené atributy
objectspace create jméno_prostoru_objektů
Prostor objektů → Vytvořit prostor objektů
objectspace delete jméno_prostoru_objektů
Prostor objektů → Procházet prostory objektů → klepnout na jméno prostoru objektů→ Vymazat
objectspace list
Prostor objektů → Procházet prostory objektů
policy get account-expiry-date
Uživatel → Zobrazit globální politiku uživatele → Datum ukončení platnosti konta
policy get account-expiry-date -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy get disable-time-interval
Uživatel → Zobrazit globální politiku uživatele → Časový interval zablokování
policy get disable-time-interval -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy get max-login-failures
Uživatel → Zobrazit globální politiku uživatele → Maximum selhání přihlášení
policy get max-login-failures -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnou na jméno uživatele → ouško Politika
policy get max-password-age
Uživatel → Zobrazit globální politiku uživatele → Maximální stáří hesla
policy get max-password-age -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy get max-password-repeated-chars
Uživatel → Zobrazit globální politiku uživatele → Maximum opakovaných znaků hesla
policy get max-password-repeated-chars -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
Dodatek C. Ekvivalenty Web Portal Manager a příkazového řádku administrativy
335
Tabulka 12. Mapování mezi CLI administrativy a Web Portal Manager (pokračování) pdadmin CLI
Web Portal Manager
policy get min-password-alphas
Uživatel → Zobrazit globální politiku uživatele → Maximum písmen hesla
policy get min-password-alphas -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy get min-password-length
Uživatel → Zobrazit globální politiku uživatele → Minimální délka hesla
policy get min-password-length -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy get min-password-non-alphas -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy get password-spaces
Uživatel → Zobrazit globální politiku uživatele → Povolené mezery v hesle
policy get password-spaces -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy get tod-access
Uživatel → Zobrazit globální politiku uživatele → Denní doba přístupu
policy get tod-access -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy set account-expiry-date [unlimited|absolutní_čas|unset]
Uživatel → Zobrazit globální politiku uživatele → Datum ukončení platnosti konta → Použít
policy set account-expiry-date {unlimited|absolutní_čas|unset} -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy set disable-time-interval [počet|unset|disable]
Uživatel → Zobrazit globální politiku uživatele → Zobrazit globální politiku uživatele → Použít
policy set disable-time-interval {počet|unset|disable} -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy set max-login-failures [počet|unset]
Uživatel → Zobrazit globální politiku uživatele → Maximum selhání přihlášení → Použít
policy set max-login-failures {počet|unset} -user Uživatel → Hledat uživatele → zadat vzor a jméno_uživatele maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
336
policy set max-password-age [unset|relativní_čas]
Uživatel → Zobrazit globální politiku uživatele → Maximální stáří hesla → Použít
policy set max-password-age {unset|relativní_čas} -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 12. Mapování mezi CLI administrativy a Web Portal Manager (pokračování) pdadmin CLI
Web Portal Manager
policy set max-password-repeated-chars [počet|unset]
Uživatel → Zobrazit globální politiku uživatele → Maximum opakovaných znaků hesla → Použít
policy set max-password-repeated-chars [počet|unset] -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy set min-password-alphas [počet|unset]
Uživatel → Zobrazit globální politiku uživatele → Maximum písmen hesla → Použít
policy set min-password-alphas [počet|unset] -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy set min-password-length [počet|unset]
Uživatel → Zobrazit globální politiku uživatele → Maximální délka hesla → Použít
policy set min-password-length [počet|unset] -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy set min-password-non-alphas [počet|unset]
Uživatel → Zobrazit globální politiku uživatele → Maximum nepísmenných znaků hesla → Použít
policy set min-password-non-alphas [počet|unset] -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy set password-spaces [yes|no|unset]
Uživatel → Zobrazit globální politiku uživatele → Povolené mezery v hesle → Použít
policy set password-spaces {yes|no|unset} -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
policy set tod-access hodnota_todaccess
Uživatel → Zobrazit globální politiku uživatele → Denní doba přístupu → Použít
policy set tod-access hodnota_todaccess -user jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Politika
pop attach jméno_objektu jméno_pop
POP → Vypsat POP → klepnout na jméno POP → ouško Připojit → Připojit
pop create jméno_pop
POP → Vytvořit POP
pop delete jméno_pop
POP → Vypsat POP → zvolit jména POP → Vymazat
pop detach jméno_objektu
POP → Vypsat POP → klepnout na jméno POP → ouško Připojit → zvolit objekt → Odpojit
pop find jméno_pop
POP → Vypsat POP → klepnout na jméno POP → ouško Připojit
pop list
POP → Vypsat POP
pop list jméno_pop
POP → Vypsat POP → klepnout na jméno POP
pop list jméno_pop attribute
POP → Vypsat POP → klepnout na jméno POP → ouško Rozšířené atributy
Dodatek C. Ekvivalenty Web Portal Manager a příkazového řádku administrativy
337
Tabulka 12. Mapování mezi CLI administrativy a Web Portal Manager (pokračování) pdadmin CLI
Web Portal Manager
pop modify jméno_pop delete attribute jméno_atributu
POP → Vypsat POP → klepnout na jméno POP → ouško Rozšířené atributy → zvolit atributy → Vymazat
pop modify jméno_pop delete attribute jméno_atributu hodnota_atributu
POP → Vypsat POP → klepnou na jméno POP → ouško Rozšířené atributy → zvolit atributy → Vymazat
pop modify jméno_pop set attribute jméno_atributu hodnota_atributu
POP → Vypsat POP → klepnout na jméno POP → ouško Rozšířené atributy → Vytvořit
pop modify jméno_pop set audit-level [all | none POP → Vypsat POP → klepnout na jméno | výpis_úrovně_auditu] POP → ouško Obecné → zvolit zaškrtávací okénko Úroveň auditu → Použít pop modify jméno_pop set description popis
POP → Vypsat POP → klepnout na jméno POP → ouško Obecné → Použít
pop modify jméno_pop set ipauth add síť maska_sítě úroveň_autentizace
POP → Vypsat POP → klepnout na jméno POP → ouško Autentizace IP → Vytvořit → zadejte síť, masku sítě a úrověň autentizace → Použít
pop modify jméno_pop set ipauth add síť maska_sítě forbidden
POP → Vypsat POP → klepnout na jméno POP → ouško Autentizace IP → Vytvořit → zadat síť a masku sítě, zvolit zaškrtávací okénko Zakázáno → Použít
pop modify jméno_pop set ipauth anyothernw úroveň_autentizace
POP → Vypsat POP → klepněte na jméno POP → Autorizace IP → Vytvořit → zvolit zaškrtávací okénko Jiná síť, zadat úroveň autentizace → Vytvořit
pop modify jméno_pop set ipauth anyothernw forbidden
POP → Vypsat POP → klepnout na jméno POP → ouško Autentizace IP → Vytvořit → zvolit zaškrtávací okénko Jiná síť, zvolit zaškrtávací okénkoZakázáno → Vytvořit
pop modify jméno_pop set ipauth remove síť maska_sítě
POP → Vypsat POP → klepnout na jméno POP → ouško Autentizace IP → zvolit záznamy autentizace IP → Vymazat vymazat vs odstranit na panelu GUI?
338
pop modify jméno_pop set qop {none|integrity|privacy}
POP → Vypsat POP → klepnout na jméno POP → ouško Obecné → Použít
pop modify jméno_pop set tod-access {anyday weekday | denní_výpis}:{anytime | určitý_čas-určitý_čas}[:{utc | local}]
POP → Vypsat POP → klepnout na jméno POP → ouško Obecné → Použít
pop modify jméno_pop set warning {yes|no}
POP → Vypsat POP → klepnout na jméno POP → ouško Obecné → Použít
pop show jméno_pop
POP → Vypsat POP → klepnout na jméno POP
pop show jméno_pop attribute
POP → Vypsat POP → klepnout na jméno POP → ouško Rozšířené atributy
quit
Není podporováno
rsrc create jméno_zdroje
Zdroj GSO → Vytvořit GSO
rsrc create jméno_zdroje -desc popis
Zdorj GSO → Vytvořit GSO a zadat popis zdroje GSO
IBM Tivoli Access Manager: Base: Administrativní příručka
Tabulka 12. Mapování mezi CLI administrativy a Web Portal Manager (pokračování) pdadmin CLI
Web Portal Manager
rsrc delete jméno_zdroje
Zdroj GSO → Vypsat GSO → zvolit zdroje GSO → Vymazat
Uživatel → Hledat uživatele → Hledat → klepnout na jméno uživatele → klepnout na ouško Pověření GSO → klepnout na Vytvořit
rsrccred modify jméno_skupiny_zdroje rsrctype Uživatel → Hledat skupiny → Hledat → {web|group} [-rsrcuser id_uživatele_zdroje] klepnout na jméno uživatele → klepnout na [-rsrcpwd pwd_zdroje] user jméno_uživatele ouško Pověření GSO → klepnout na Vytvořit rsrccred show jméno_zdroje rsrctype {web|group} user jméno_uživatele
Uživatel → Hledat skupiny → Hledat → klepnout na jméno uživatele → klepnout na ouškoPověření GSO
rsrccred show jméno_skupiny_zdroje rsrctype {web|group} user jméno_uživatele
Uživatel → Hledat skupiny → Hledat → klepnout na jméno uživatele → klepnout na ouškoPověření GSO
rsrcgroup create jméno_skupiny_zdroje
Zdroj GSO → Vytvořit skupiny GSO
rsrcgroup create jméno_skupiny_zdroje -desc popis
Zdroj GSO → Vytvořit skupinu GSO a zadat popis
rsrcgroup delete jméno_skupiny_zdroje
Zdroje GSO → Vypsat skupiny GSO → zvolit skupiny zdrojů GSO → Vymazat
Zdroje GSO → Vypsat skupiny GSO → klepnout na skupiny zdrojů GSO → zvolit členy → Odstranit
rsrcgroup show jméno_skupiny_zdroje
Zdroj GSO → Vypsat skupiny GSO → klepnout na skupinu zdrojů GSO
server list
Není podporováno
Dodatek C. Ekvivalenty Web Portal Manager a příkazového řádku administrativy
339
Tabulka 12. Mapování mezi CLI administrativy a Web Portal Manager (pokračování) pdadmin CLI
Web Portal Manager
server listtasks jméno_serveru
Není podporováno
server replicate jméno_serveru
Není podporováno
server show jméno_serveru
Není podporováno
server task jméno_serveru {help|stats|trace}
Není podporováno
server task (WebSEAL) jméno_serveru úloha_serveru
Není podporováno Abyste získali další informace o úlohách serveru WebSEAL a bodech spojení, viz publikace IBM Tivoli Access Manager for e-business WebSEAL: Administrativní příručka.
340
user create [-gsouser] [-no-password-policy] jméno_uživatele dn cn sn heslo [(skupina1 skupina2 .... )]
Uživatel → Vytvořit uživatele
user delete [-registry] jméno_uživatele
Skupina → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → zvolit jména uživatelů → Vymazat
user import [-gsouser] jméno_uživatele dn [jméno_skupiny]
Uživatel → Importovat uživatele
user list vzor maximum_navrácených
Skupina → Hledat uživatele → zadat vzor a maximální výsledky → Hledat
user list-dn vzor maximum_navrácených
Není podporováno
user modify jméno_uživatele account-valid {yes|no}
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Obecné
user modify jméno_uživatele password heslo
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Obecné
user modify jméno_uživatele password-valid {yes|no}
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele → ouško Obecné
user show jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnout na jméno uživatele
user show-dn dn
Není podporováno
user show-groups jméno_uživatele
Uživatel → Hledat uživatele → zadat vzor a maximální výsledky → Hledat → klepnou na jméno uživatele → ouško Skupiny
IBM Tivoli Access Manager: Base: Administrativní příručka
Dodatek D. Správa registrů uživatelů Tato kapitola obsahuje podmnožinu úloh registru uživatelů, které jsou specifické pro instalaci produktu Tivoli Access Manager. Pro běžné administrativní úlohy pro váš daný registr uživatelů (úlohy, které nejsou specifické pro produkt Tivoli Access Manager) vás odkazujeme na dokumentaci, které přišla s vaším produktem registru uživatelů. Tato kapitola obsahuje následující části: v “Úlohy specifické pro LDAP” v “Úlohy specifické pro Active Directory” na stránce 353 v “Úlohy specifické pro Novell” na stránce 356
Úlohy specifické pro LDAP LDAP je protokol, který běží přes TCP/IP. Standard protokolu LDAP zahrnuje nízkoúrovňové definice protokolů sítě plus znázornění dat a funkcionalitu obsluhy. Adresář, který je přístupný přes LDAP se běžně nazývá adresář LDAP. Tato volba obsahuje následující témata: v “Konfigurace přepnutí při selhání LDAP” v “Použití platných znaků pro jména uživatelů a skupin LDAP” na stránce 344 v “Použití politiky ACL produktu IBM Tivoli Access Manager do nových přípon serveru LDAP” na stránce 345
Konfigurace přepnutí při selhání LDAP Protokol LDAP (Lightweight Directory Access Protocol) definuje standardní metody pro přístup a aktualizaci informací v adresáři. Adresáře jsou obvykle zpřístupněné s použitím modelu komunikace klient/server. Libovolný server, který využívá protokolu LDAP je v serveru adresářů LDAP. Distribuovaná architektura LDAP podporuje uzpůsobitelné adresářové služby se schopnostmi replikací serveru. Replikace serveru vylepšuje dostupnost adresářové služby. Replikace IBM Directory je založená na modelu hlavní-podřízený. Replikace Sun ONE Directory Server je založená na modelu dodavatel/spotřebitel. Tivoli Access Manager s tímto stále zachází jako se vztahem hlavní-podřízený. Kombinace hlavního serveru a více replikovaných serverů pomáhá zajistit, že potřebná data adresáře jsou vždy dostupná. Dojde-li k selhání libovolného serveru, adresářová služba je i nadále dostupná pro jiný replikovaný server. Tivoli Access Manager podporuje tuto schopnost replikace.
Schopnost přepnutí při selhání serveru Tivoli Access Manager pro servery LDAP Server Tivoli Access Manager se připojuje do hlavního serveru LDAP při svém spouštění. Je-li hlavní server LDAP z jakéhokoliv důvodu vypnutý, server Tivoli Access Manager musí být schopný se připojit k dostupnému replikovanému serveru LDAP pro libovolné operace čtení. Mnoho operací, obzvlášť ty od pravidlených uživatelů, jsou operace čtení. Tyto zahrnují operace jako je autentizace uživatele a přihlášení se do backend připojených webových serverů. Po správné konfiguraci server Tivoli Access Manager provede přepnutí při selhání do replikovaného serveru, není-li schopen připojit se do serveru hlavního. Konfigurační parametry pro přepnutí při selhání LDAP můžete nalézt v objektu stanza [ldap] konfiguračního souboru ldap.conf: UNIX: /opt/PolicyDirector/etc/ldap.conf Windows: instalační_cesta\etc\ldap.conf
Konfigurace hlavního serveru Server IBM Directory podporuje existenci jednoho hlavního serveru LDAP pro operace čtení a zápis. Server Sun ONE Directory podporuje více serverů LDAP pro operace čtení a zápis. Server Tivoli Access Manager zachází se serverem dodavatele Sun ONE jako s hlavním serverem pro konfigurační účely. Aktivní konfigurační řádky v souboru ldap.conf představují parametry a hodnoty pro tento hlavní server LDAP. Vy určíte tyto hodnoty během konfigurace serveru Tivoli Access Manager. Například: [ldap] enabled = yes host = outback port = 389 ssl-port = 636 max-search-size = 2048 Parametr
Popis
enabled
Server Tivoli Access Manager používá registr uživatelů LDAP. Hodnoty jsou yes a no.
host (hostitel)
Jméno sítě počítače, kde je umístění hlavní server LDAP.
port
Naslouchající port TCP hlavního serveru LDAP.
ssl-port
Naslouchající port SSL hlavního serveru LDAP.
max-search-size
Limit serveru Tivoli Access Manager pro prohledávání klienta LDAP položek databáze - jako je požadování od Web Portal Manager, aby vypsal uživatele z databáze LDAP.
Pokud provedete změnu v databázi LDAP, jako přidání nového účtu uživatele přes Web Portal Manager, server Tivoli Access Manager vždy použije (hlavní) server LDAP pro čtení a zápis.
Konfigurace replikovaného serveru Server IBM Directory podporuje existenci jednoho nebo více replikovaných serverů LDAP pouze pro operace čtení. Server Sun ONE Directory podporuje existenci jednoho nebo více replikovaných serverů LDAP pouze pro operace čtení, na které se odkazuje jako na spotřebitele. Musíte přidat řádky do objektu stanza [ldap], který označuje libovolné replikované servery dostupné pro server Tivoli Access Manager. Pro každou repliku použijte následující syntaxi:
342
IBM Tivoli Access Manager: Base: Administrativní příručka
Port, kterému tento server naslouchá. Obecně použijte 389 nebo 636.
typ
Funkcionalita replikovaného serveru - buď pouze ke čtení, nebo čtení-zápis. Normálně použijte pouze ke čtení. Typ čtení-zápis by představoval hlavní server.
preference
Číslo od 1 do 10. Server s nejvyšší hodnotou preference je zvolen se spojení LDAP. Viz “Nastavení hodnot preference pro replikované servery LDAP”.
Změny v souboru ldap.conf nenabudou účinnosti dokud nerestartujete server Tivoli Access Manager.
Nastavení hodnot preference pro replikované servery LDAP Každý replikovaný server LDAP musí mít hodnotu preference (1-10), která určí jeho prioritu pro výběr jako: v primární přístupový server pouze pro čtení, nebo v zálohovaný server pouze pro čtení během přepnutí při selhání. Čím vyšší je číslo, tím vyšší je priorita. Dojde-li k selhání primárního serveru pouze pro čtení z libovolného důvodu, je použitý server s další nejvyšší hodnotou preference. Mají-li dva nebo více serverů stejnou hodnotu preference, nejméně zaneprázdněný algoritmus pro vyvážení zatížení zvolí jeden z nich. Pamatujte si, že hlavní server LDAP funguje jako server pouze pro čtení a také jako server pro čtení a zápis. Pro přístup pouze pro čtení má hlavní server pevně naprogramované předvolené nastavení preference na 5. Toto nastavení preference vám umožňuje nastavit replikovaný server na hodnoty vyšší nebo nižší než server hlavní, abyste obdrželi požadovaný výkon. Například, se správným nastaveným preference byste mohli zabránit hlavnímu serveru v práci s každodenními operacemi čtení. Můžete nastavit hierarchické hodnoty preference, abyste tak umožnili přístup do jednoho serveru LDAP (s přepnutím při selhání do jiných serverů), nebo můžete nastavit stejné hodnoty pro všechny servery, což umožní vyvážení zatížení pro nařízení pro výběr serveru. Následující tabulka ilustruje některé možné scénáře preferencí. “H” odkazuje na hlavní server (pouze pro čtení/čtení-zápis) LDAP; “R1, R2, R3” odkazují na replikované servery (pouze pro čtení) LDAP. H
R1
R2
R3
Preference přepnutí při selhání
5
5
5
5
Všechny servery mají stejné hodnoty preference. Vyvážení zatížení určí, který server bude zvolený pro každou přístupovou operaci.
5
6
6
6
Tři replikované servery mají stejné hodnoty preference. Tato hodnota je vyšší než hodnota hlavního serveru. Vyvážení zatížení určí výběr serveru mezi těmito třemi replikami. Hlavní server je použitý pouze, jsou-li všechny tři replikované servery nedostupné. Dodatek D. Správa registrů uživatelů
343
H 5
R1 6
R2 7
R3 8
Preference přepnutí při selhání Server 3 (s nejvyšší hodnotou preference) se stane primárním serverem. Dojde-li k selhání serveru 3, server 2 se stane primárním serverem, protože má druhou nejvyšší hodnotu preference.
Hodnoty preference mají vliv na přístup pouze pro čtení do databáze LDAP. Server Tivoli Access Manager vždy používá hlavní server (čtení-zápis), potřebujete-li provést změnu v databázi LDAP. Všimněte si také, že někteří démoni Tivoli Access Manager (jako server politik) přepisují nastavení preferencí ve svých konfiguračních souborech, aby tak ukázali, že dávají přednost serveru pro čtení a zápis. Přepisování se vyskytuje, protože tito démoni obvykle provádí operace aktualizace, které by měly jít do hlavního serveru LDAP.
Výzva serveru Dojde-li k selhání serveru LDAP, server Tivoli Access Manager jej neustále vyzývá, aby kontroloval svůj návrat k aktivní službě. Doba opakování výzev je 10 vteřin.
Použití platných znaků pro jména uživatelů a skupin LDAP Při používání serveru LDAP jako registru uživatelů je sada planých znaků povolených pro jméno uživatele a skupiny určená podle následujícího IETF (Internet Engineering Task Force) RFC (Request for Comments): v 2253 ″Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names″ v 2254 ″The String Representation of LDAP Search Filters″ Určitý server LDAP může diktovat také platnost těchto znaků. Obecně můžete použít speciální znaky pro rozlišené jméno DN (Distinguished Name). Avšak, některé speciální znaky vyžadují přídavné únikové znaky. Následující speciální znaky musí být únikové, když jsou použité pro DN: v + (plus), v \ (zpětné lomítko), v ; (středník), v , (čárka). Například, chcete-li vytvořit uživatele obsahujícího středník s použitím obslužného programu pdadmin: pdadmin> user create "user;one" "cn=user\;one,o=tivoli,c=us" "user;one" "user;one" password1
Použijete-li speciální znaky při užívání pdadmin z příkazového řádku, ohraničte každý argument příkazu uživatele nebo skupiny dvojitými uvozovkami. Dvojité uvozovky umožní argumentu, aby byl zadaný bez toto, aniž by byl podřízený interpretaci nadstavbovým příkazovým procesorem operačního systému. Kvůli variabilitě práce s speciálními znaky se vyhněte jejich používání.
344
IBM Tivoli Access Manager: Base: Administrativní příručka
Použití politiky ACL produktu IBM Tivoli Access Manager do nových přípon serveru LDAP Model pojmenování serverů LDAP je obvykle spravovaný v hierarchickém prostoru jmen, na který se odkazuje jako na DIT (Directory Information Tree). Mnoho produktů serveru LDAP, jako IBM Tivoli Directory Server, včetně Tivoli Access Manager a Sun ONE Directory Server, udržují data DIT v hierarchickém prostoru jmen často znázorňovaného jako stromová struktura. Vrchol stromu se nazývá kontext pojmenování, někdy také jednodušeji přípona, protože představuje koncovou část DN záznamu v LDAP. Například, přípona nazývaná c=us mohla být vytvořená, aby představovala organizaci pro danou zemi. Určitý záznam v této příponě by měl DN stejné jako cn=Joe Williams,ou=austin,o=ibm,c=us. Sada přípon, kterou server LDAP udržuje, je konfigurovatelná s použitím nástrojů administrativy vztahujících se k serveru LDAP. Když je server politik produktu Tivoli Access Manager nakonfigurovaný, snaží se použít odpovídající přístupový ovladač ve formě ACL (Access Control List) na každou příponu LDAP, která existuje v té době v serveru LDAP. Tento přístupový ovladač poskytuje odpovídající oprávnění pro umožnění produktu Tivoli Access Manager vytvořit a spravovat informace o uživateli a skupině v těchto příponách LDAP. Přidá-li administrátor LDAP příponu LDAP poté, co byl konfigurovaný Access Manager, a chce-li, aby byl Access Manager dostupný pro správu uživatelů a skupin v této nové příponě, měla by se odpovídající ACL na novou příponu aplikovat manuálně. Chcete-li použít odpovídající přístupové ovladače na nově vytvořené přípony LDAP, použijte odpovídající rozhraní administrativy LDAP, abyste aplikovali následující ACL na každou novou příponu: Skupina LDAP
Přístupový ovladač
cn=SecurityGroup,secAuthority=Default v Plný přístup cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default v čtení v hledání v porovnání cn=remote-acl-users,cn=SecurityGroups,secAuthority=Default v čtení v hledání v porovnání
Navíc, vytvořil-li administrátor Access Manager více domén, to je, více než jednu administrativní doménu jinou než je výchozí doména správy, která je vytvořená při první konfiguraci serveru politik, následující přídavné ACL by měly být aplikované na nové přípony pro doménu.
Dodatek D. Správa registrů uživatelů
345
Skupina LDAP
Přístupový ovladač
cn=SecurityGroup,secAuthority=jméno_domény,cn=Subdomains,secAuthority=Default v Plné ovládání cn=ivacld-servers,cn=SecurityGroups,secAuthority=jméno_domény,cn=Subdomains,secAuthority=Default v čtení v hledání v porovnání cn=remote-acl-users,cn=SecurityGroups,secAuthority=jméno_domény,cn=Subdomains,secAuthority=Default v čtení v hledání v porovnání
Kde jméno_domény je jméno přídavné administrativní domény. Abyste si zobrazili seznam domén, použijte příkaz pdadmin domain list. Následující ukázkové kroky lze použít buď pro server IBM Directory Server nebo Sun ONE Directory Server, závisí na typu používaného serveru LDAP. Všimněte si, že popisované procedury předpokládají nově vytvořenou příponu nazývanou c=fr. Měli byste nahradit skutečnou nově vytvořenou příponu pro tuto hodnotu v následujícím popisu.
Procedury pro server IBM Tivoli Directory Server Následující kroky popisují, jak použít odpovídající přístupové ovladače produktu Tivoli Access Manager na nově vytvořené přípony pro server IBM Tivoli Directory Server. Tyto kroky používají nástroje administrativy IBM Directory Server Web Administration Tool, které jsou zahrnuté v IBM Tivoli Directory Server verze 5.2, a předpokládají, že tyto nástroje byly správně nainstalované a konfigurované do aplikačního serveru WebSphere. 1. Vytvořte přístup na přihlašovací stránku používající podporovaný prohledávací program webu. Předvolené URL přihlašovací stránky je
2.
3. 4.
5.
6.
346
http://jméno_serveru:9080/IDSWebApp/IDSjsp/Login.jsp kde jméno_serveru je jméno hostitele aplikačního serveru, na kterém byly nainstalované nástroje administrativy IBM Directory Server Web Administration Tool. Použijte tento seznam pro volbu jméno hostitele serveru LDAP, který má být spravovaný, a přejděte ke kroku 7 na stránce 347. Pokud jste již nepřidali hostitelský LDAP do seznamu ke správě, budete se muset přihlásit jako Console Admin (administrátor konzole) a přidat server LDAP na seznam serverů konzolí. Abyste mohli takto učinit, přejděte ke kroku 3. Přihlaste se jako Console Admin (administrátor konzole). Předvolená totožnost Console Admin je superadmin a předvolené heslo je secret. V oblasti navigace vlevo klepněte na Console administration (Administrativa konzolí) a Manage console servers (Správa serverů konzolí). Tato akce představuje seznam serverů LDAP, které jsou momentálně konfigurované pro administrativu. Abyste přidali jiný server LDAP, klepněte na tlačítko Add (Přidat) a potom zapište informace jméno hostitele a číslo portu pro server LDAP, který chcete spravovat. Když je vše hotovo, klepněte na tlačítko OK. Poté, co jste přidali server LDAP ke správě, klepněte na tlačítko Close (Zavřít), čímž dokončíte akci Manage console servers (Správa serverů konzolí). Potom klepněte na Logout (Odhlášení) z oblasti navigace. Znovu vytvořte přístup na přihlašovací stránku s použitím URL jako v kroku 1 a zvolte server LDAP, který jste přidali ze seznamu.
IBM Tivoli Access Manager: Base: Administrativní příručka
7. Poté, co jste vybrali server LDAP ze seznamu, zapište Username (Uživatelské jméno) administrátora serveru LDAP (cn=root) a heslo v okně Login (Přihlášení). Klepněte na tlačítko Login (Přihlášení). 8. V oblasti navigace vlevo klepněte na Directory management (Správa adresářů) a Manage entries (Spravovat záznamy). 9. Pokud nevidíte nově přidanou příponu v okně Manage entries (Spravovat záznamy) zobrazeném vpravo, označuje to, že zatím nebyl přidaný žádný záznam pro nově přidanou příponu. Než lze k nové příponě použít přístupový ovladač, musíte nejdřív vytvořit záznam. Pokud vidíte nově přidanou příponu, přejděte ke kroku 13. Jinak, abyste mohli přidat záznam pro nově vytvořenou příponu, klepněte na tlačítko Add (Přidat). Zobrazí se okno Add an entry (Přidat záznam). 10. Vyberte odpovídající strukturální třídu objektů pro nově přidanou příponu. Pro příponu c=fr, je odpovídající třída objektů country (země). Klepněte na tlačítko Next (Další), abyste mohli pokračovat v následujícím okně. Zobrazí se okno Select auxiliary object classes (Zvolit pomocné třídy objektů). 11. Toto okno vám umožňuje přidat další třídy objektů odpovídající pro typ záznamu. V tomto příkladu nejsou potřeba žádné další třídy objektů, takže pouze klepněte na tlačítko Next (Další). 12. Následující okno vám umožňuje pojmenovat nový záznam a zadat hodnoty atributů pro zvolené strukturované třídy objektů. Pro tento příklad zadejte Relative DN (Relativní DN) c=fr a vynechte Parent DN (Nadřízené DN) prázdné. Jediný požadovaný atribut pro tento příklad je c pro zemi. Vyplňte hodnotu fr pro tento příklad a potom klepněte na tlačítko Finish (Dokončit). Toto vás přenese zpět do okna Manage entries (Spravovat záznamy). Nyní byste měli vidět nově přidanou příponu v seznamu záznamů nejvyšší úrovně. 13. Příponu ze seznamu zvolíte klepnutím na ni v sloupci Select (Zvolit) a potom klepněte na tlačítko Edit ACL (Editovat ACL). Zobrazí se okno Edit ACL (Editovat ACL) a zobrazí aktuální ACL v záznamu přípony. Klepněte na tlačítko Non-filtered ACLs (Nefiltrované ACL). 14. Ujistěte se, že je zvolená volba Propagate ACLs (Propagovat ACL). Zadejte následující jméno skupiny v poli DN (rozlišené jméno): cn=SecurityGroup,secAuthority=Default. Nastavte Type (Typ) na group a klepněte na tlačítko Add (Přidat). Zobrazí se okno Add access rights (Přidat přístupová práva). 15. Nastavte právo Add child (Přidat podřízené) a Delete entry (Vymazat záznam) na grant (udělit). Nastavte všechny Security classes (Třídy zabezpečení) (normální, citlivá, kritická, systémová a omezená) na grant pro všechny akce (čtení, zápis, hledání a porovnání). Potom klepněte na tlačítko OK. Znova se zobrazí okno Edit ACL (Editovat ACL). 16. Zadejte následující jméno skupiny v poli DN (rozlišené jméno): cn=ivacldservers,cn=SecurityGroups,secAuthority=Default. Nastavte Type (Typ) na group (skupina) a klepněte na tlačítko Add (Přidat). Zobrazí se okno Add access rights (Přidat přístupová práva). 17. Nastavte třídy zabezpečení normal (normální) a system (systémová) na grant (udělit) pro akce čtení, hledání a porovnání. Nechte Add child (Přidat podřízené), Delete entry (Vymazat záznam), a všechny ostatní Security classes (Třídy zabezpečení) prázdné. Potom klepněte na tlačítko OK. Znova se zobrazí okno Edit ACL (Editovat ACL). 18. Zadejte následující jméno skupiny v poli DN (rozlišené jméno): cn=remote-aclusers,cn=SecurityGroups,secAuthority=Default. Nastavte Type (Typ) na group (skupina) a klepněte na tlačítkoAdd (Přidat). Zobrazí se okno Add access rights (Přidat přístupová práva). 19. Nastavte třídy zabezpečení normal (normální) a system (systémová) na grant (udělit) pro akce čtení, hledání a porovnání. Nechte Add child (Přidat podřízené), Delete entry
Dodatek D. Správa registrů uživatelů
347
20. 21.
22.
23.
24.
25.
26.
27.
28.
(Vymazat záznam), a všechny ostatní Security classes (Třídy zabezpečení) prázdné. Potom klepněte na tlačítko OK. Znova se zobrazí okno Edit ACL (Editovat ACL). Pokud nemáte žádné další domény, toto dokončí kontrolu přístupu a vy můžete přejít ke kroku 27. Pokud máte domény a potřebujete přidat ACL domén, pokračujte krokem 21. Zadejte následující jméno skupiny v poli DN (rozlišené jméno): cn=SecurityGroup,secAuthority=jméno_domény,cn=Subdomains, secAuthority=Default. Kde jméno_domény je chráněné jméno domény. Nastavte Type (Typ) na group (skupina) a klepněte na tlačítkoAdd (Přidat).Zobrazí se okno Add access rights (Přidat přístupová práva). Nastavte právo Add child (Přidat podřízené) a Delete entry (Vymazat záznam) na grant (udělit). Nastavte všechny Security classes (Třídy zabezpečení) (normální, citlivá, kritická, systémová a omezená) na grant pro všechny akce (čtení, zápis, hledání a porovnání). Potom klepněte na tlačítko OK. Znova se zobrazí okno Edit ACL (Editovat ACL). Zadejte následující jméno skupiny v poli DN (rozlišené jméno): cn=ivacldservers,cn=SecurityGroups,secAuthority=jméno_domény,cn=Subdomains, secAuthority=Default. Nastavte Type (Typ) na group a klepněte na tlačítko Add (Přidat). Zobrazí se okno Add access rights (Přidat přístupová práva). Nastavte třídy zabezpečení normal (normální) a system (systémová) na grant (udělit) pro akce čtení, hledání a porovnání. Nechte Add child (Přidat podřízené), Delete entry (Vymazat záznam), a všechny ostatní Security classes (Třídy zabezpečení) prázdné. Potom klepněte na tlačítko OK. Znova se zobrazí okno Edit ACL (Editovat ACL). Zadejte následující jméno skupiny v poli DN (rozlišené jméno): cn=remote-aclusers,cn=SecurityGroups,secAuthority=jméno_domény,cn=Subdomains, secAuthority=Default. Nastavte Type (Typ) na group a klepněte na tlačítko Add (Přidat). Zobrazí se okno Add access rights (Přidat přístupová práva). Nastavte třídy zabezpečení normal (normální) a system (systémová) na grant (udělit) pro akce čtení, hledání a porovnání. Nechte Add child (Přidat podřízené), Delete entry (Vymazat záznam), a všechny ostatní Security classes (Třídy zabezpečení) prázdné. Potom klepněte na tlačítko OK. Znova se zobrazí okno Edit ACL (Editovat ACL). Pokud máte další domény, opakujte kroky 21 až 26 pro každou doménu. Když je vše hotovo, pokračujte krokem 27. Tímto se dokončí přidání přístupového ovladače pro příponu. Klepněte na tlačítko OK. Znova se zobrazí okno Manage ACL (Správa ACL). Klepněte na tlačítko Close (Zavřít). Nemusíte restartovat server LDAP, aby tyto změny byly účinné. Pokud jste skončili s nástroji administrativy IBM Directory Server Web Administration Tool, klepněte na tlačítko Logout (Odhlášení).
Procedury pro server Sun ONE Directory Server Následující kroky popisují, jak použít odpovídající přístupové ovladače produktu Tivoli Access Manager na nově vytvořené přípony pro server Sun ONE Directory Server. Tyto kroky používají Sun ONE Server Console verze 5.2. 1. Spusťte konzoli Sun ONE Server Console s použitím jednoho z následujících příkazů: v V systémech UNIX zadejte následující z instalačního adresáře Sun ONE Directory Server: # ./startconsole
v Na Solaris, nepoužíváte-li verzi sady programů Solaris, se přesuňte do kořenového adresáře serveru a zadejte: startconsole argumenty
348
IBM Tivoli Access Manager: Base: Administrativní příručka
Zapište příkaz –h pro zobrazení zprávy použití vysvětlující argumenty příkazového řádku. v V systémech Windows klepněte na: Start (Spustit) → Programs (Programy) → Sun ONE Server Products (Produkty SOSP) → Sun ONE Server Console Version 5.2. 2. Přihlaste se do konzole Sun ONE Server Console. Zapište ID uživatele pro administrátora LDAP, což je obvykle cn=Directory Manager. Zapište heslo a URL administrativy. Klepněte na tlačítko OK. 3. Zvolte doménu Sun ONE Domain k použití produktem Tivoli Access Manager. 4. Rozbalte jméno serveru a Server Group (Skupinu serveru). 5. Zvolte záznam označený Directory Server (Server adresářů). Informace o konfiguraci serveru Sun ONE Directory jsou zobrazené. 6. Klepněte na tlačítko Open (Otevřít). Vytvoří se přístup k serveru Sun ONE Directory. 7. Klepněte na ouško Directory (Adresář). Pokud se zobrazí nově vytvořená přípona v levém podokně, přejděte ke kroku 8. Pokud se nově vytvořená přípona neobjeví v levém podokně, musíte vytvořit záznam pro novou příponu než pro ni použijete přístupové ovladače. Proveďte následující kroky, abyste vytvořili nový záznam: a. Zvýrazněte jméno serveru v horní části stromu adresáře. Klepněte na Object (Objekt)→ New Root Object (Nový objekt typu root). Zobrazí se seznam kořenových přípon b. Zvolte c=fr ze seznamu kořenových přípon. Zobrazí se výběrové okno New Object (Nový objekt). c. Ve výběrovém okně New Objekt (Nový objekt) sjeďte dolů a zvolte Country (Země) jako typ záznamu nového objektu. d. Klepněte na tlačítko OK. Zobrazí se okno Property Editor (Editor vlastností). e. Vyplňte pole Country (Země) jako fr a klepněte na tlačítko OK.
8.
9. 10. 11. 12. 13.
Poznámka: Tyto instrukce předpokládají příklad přípony. Vytvořte typ záznamu a jméno, které odpovídá vaší skutečné příponě. f. Klepněte na View (Zobrazit)→ Refresh (Obnovit). Nový záznam přípony se zobrazí v levém stromu navigace. Zvýrazněte záznam c=fr v levém podokně. Klepněte na Object (Objekt) → Set Access Permissions (Nastavení přístupových oprávnění). Zobrazí se okno Manage Access Control (Správa přístupového ovladače) pro c=fr . Klepněte na tlačítko New (Nové), čímž se zobrazí okno Edit ACI (Editovat ADI) pro c=fr. Uveďte jméno ADI (Access Control Instructions) jako SECURITY GROUP (skupina zabezpečení) – ALLOW ALL (povolit vše). Zvýrazněte jméno All Users (Všichni uživatelé) a klepněte na tlačítko Remove (Odstranit). Klepněte na tlačítko Edit Manually (Editovat manuálně). Zobrazí se okno Edit ACI (Editovat ACI) pro c=fr. Nahraďte předvolený text ACI následujícím: (target="ldap:///c=fr")(targetattr="*") (version 3.0; acl "SECURITY GROUP – ALLOW ALL"; allow (all) groupdn = "ldap:///cn=SecurityGroup,secAuthority=Default";)
Klepněte na Check Syntax (Kontrola syntaxe), abyste zajistili správné zapsání textu. Opravte všechny chyby až syntaxe projde úspěšně kontrolou. Dodatek D. Správa registrů uživatelů
349
14. Klepněte na tlačítko OK.Zobrazí se okno Manage Access Control (Správa přístupového ovladače) pro c=fr . 15. Klepněte na tlačítko New (Nové). Uveďte jméno ACI jako PD Servers GROUP – ALLOW READ . 16. Zvýrazněte jméno All Users (Všichni uživatelé) a klepněte na tlačítko Remove (Odstranit). 17. Klepněte na tlačítko Edit Manually (Editovat manuálně). Zobrazí se okno Edit ACI (Editovat ACI) pro c=fr. 18. Nahraďte předvolený text ACI následujícím: (target="ldap:///c=fr")(targetattr="*") (version 3.0; acl "PD Servers GROUP – ALLOW READ"; allow (read, search, compare) groupdn = "ldap:///cn=ivacld-servers,cn=SecurityGroups,secAuthority=Default";)
Klepněte na Check Syntax (Kontrola syntaxe), abyste zajistili správné zapsání textu. Opravte všechny chyby až syntaxe projde úspěšně kontrolou. 19. Klepněte na tlačítko OK. Zobrazí se okno Manage Access Control (Správa přístupového ovladače) pro c=fr. 20. Klepněte na tlačítko New (Nové). Uveďte jméno ACI jako PD Remote ACL Users GROUP – ALLOW READ. 21. Zvýrazněte jméno All Users (Všichni uživatelé) a klepněte na tlačítko Remove (Odstranit). 22. Klepněte na tlačítko Edit Manually (Editovat manuálně). Zobrazí se okno Edit ACI (Editovat ACI) pro c=fr. 23. Nahraďte předvolený text ACI následujícím: (target="ldap:///c=fr")(targetattr="*") (version 3.0; acl "PD Remote ACL Users GROUP – ALLOW READ"; allow (read, search, compare) groupdn = "ldap:///cn=remote-acl-users,cn=SecurityGroups, secAuthority=Default";)
24. 25. 26. 27.
Klepněte na Check Syntax (Kontrola syntaxe), abyste zajistili správné zapsání textu. Opravte všechny chyby až syntaxe projde úspěšně kontrolou. Klepněte na tlačítko OK. Zobrazí se okno Manage Access Control (Správa přístupového ovladače) pro c=fr. Klepněte na tlačítko New (Nové). Uveďte jméno ACI jako PD Deny-Others. Zvýrazněte jméno All Users (Všichni uživatelé) a klepněte na tlačítko Remove (Odstranit). Klepněte na tlačítko Edit Manually (Editovat manuálně). Zobrazí se okno Edit ACI (Editovat ACI) pro c=fr.
Klepněte na Check Syntax (Kontrola syntaxe), abyste zajistili správné zapsání textu. Opravte všechny chyby až syntaxe projde úspěšně kontrolou. 29. Klepněte na tlačítko OK.Zobrazí se okno Manage Access Control (Správa přístupového ovladače) pro c=fr .
350
IBM Tivoli Access Manager: Base: Administrativní příručka
30. Pokud nemáte žádné další domény, toto dokončí kontrolu přístupu a vy můžete přejít ke kroku 52 na stránce 352. Pokud máte domény a potřebujete přidat ACL domén, pokračujte krokem 31. 31. Klepněte na tlačítko New (Nové). Uveďte jméno ACI jako SECURITY GROUP – ALLOW ALL 32. Zvýrazněte jméno All Users (Všichni uživatelé) a klepněte na tlačítko Remove (Odstranit). 33. Klepněte na tlačítko Edit Manually (Editovat manuálně). Zobrazí se okno Edit ACI (Editovat ACI) pro c=fr 34. Nahraďte předvolený text ACI následujícím: (target="ldap:///c=fr")(targetattr="*") (version 3.0; acl "SECURITY GROUP - ALLOW ALL; allow (all) groupdn = "ldap:///cn=SecurityGroup,secAuthority=jméno_domény, cn=Subdomains,secAuthority=Default"; )
35. 36. 37. 38. 39.
kde jméno_domény je jméno chráněné domény. Klepněte na Check Syntax (Kontrola syntaxe), abyste zajistili správné zapsání textu. Opravte všechny chyby až syntaxe projde úspěšně kontrolou. Klepněte na tlačítko OK. Zobrazí se okno Manage Access Control (Správa přístupového ovladače) pro c=fr. Klepněte na tlačítko New (Nové). Uveďte jméno ACI jako PD Servers GROUP – ALLOW READ . Zvýrazněte jméno All Users (Všichni uživatelé) a klepněte na tlačítko Remove (Odstranit). Klepněte na tlačítko Edit Manually (Editovat manuálně). Zobrazí se okno Edit ACI (Editovat ACI)pro c=fr. Nahraďte předvolený text ACI následujícím: (target="ldap:///c=fr")(targetattr="*") (version 3.0; acl "PD Servers GROUP - ALLOW READ"; allow (read, search, compare) groupdn = "ldap:///cn=ivacld-servers,cn=SecurityGroups, secAuthority=jméno_domény,cn=Subdomains,secAuthority=Default"; )
40. 41. 42. 43. 44.
kde jméno_domény je jméno chráněné domény. Klepněte na Check Syntax (Kontrola syntaxe), abyste zajistili správné zapsání textu. Opravte všechny chyby až syntaxe projde úspěšně kontrolou. Klepněte na tlačítko OK. Zobrazí se okno Manage Access Control (Správa přístupového ovladače) pro c=fr. Klepněte na tlačítko New (Nové). Uveďte jméno ACI jako PD Remote ACL Users GROUP – ALLOW READ. Zvýrazněte jméno All Users (Všichni uživatelé) a klepněte na tlačítko Remove (Odstranit). Klepněte na tlačítko Edit Manually (Editovat manuálně). Zobrazí se okno Edit ACI (Editovat ACI) pro c=fr. Nahraďte předvolený text ACI následujícím: (target="ldap:///c=fr")(targetattr="*") (version 3.0; acl "PD Remote ACL Users GROUP - ALLOW READ"; allow (read, search, compare) groupdn = "ldap:///cn=remote-acl-users,cn=SecurityGroups, secAuthority=jméno_domény,cn=Subdomains,secAuthority=Default"; )
Dodatek D. Správa registrů uživatelů
351
45. 46. 47. 48. 49.
kde jméno_domény je jméno chráněné domény. Klepněte na Check Syntax (Kontrola syntaxe), abyste zajistili správné zapsání textu. Opravte všechny chyby až syntaxe projde úspěšně kontrolou. Klepněte na tlačítko OK. Zobrazí se okno Manage Access Control (Správa přístupového ovladače) pro c=fr. Klepněte na tlačítko New (Nové). Uveďte jméno ACI jako PD Deny-Others. Zvýrazněte jméno All Users (Všichni uživatelé) a klepněte na tlačítko Remove (Odstranit). Klepněte na tlačítko Edit Manually (Editovat manuálně). Zobrazí se okno Edit ACI (Editovat ACI) pro c=fr. Nahraďte předvolený text ACI následujícím: (targetfilter="(secAuthority=jméno_domény)") (version 3.0; acl "PD Deny-Others"; deny(all) groupdn != "ldap:///cn=SecurityGroup,secAuthority=Default|| ldap:///cn=SecurityGroup,secAuthority=jméno_domény,cn=Subdomains, secAuthority=Default|| ldap:///cn=remote-acl-users,cn=SecurityGroups,secAuthority=jméno_domény, cn=Subdomains,secAuthority=Default|| ldap:///cn=ivacld-servers,cn=SecurityGroups,secAuthority=jméno_domény, cn=Subdomains,secAuthority=Default"; )
50. Klepněte na tlačítko OK. Zobrazí se okno Manage Access Control (Správa přístupového ovladače) pro c=fr. 51. Pokud se zde vyskytují další domény, opakujte kroky 31 na stránce 351 až 50 pro každou doménu. Když je vše hotovo, pokračujte krokem 52. 52. Klepněte na tlačítko OK, čímž zavřete okno Manage Access Control (Správa přístupové kontroly) pro c=fr. 53. Klepněte na Console (Konzole) → Exit (Konec), čímž ukončíte konzoli.
Procedury pro servery zabezpečení IBM z/OS a OS/390 Poté, co jste konfigurovali server politik produktu Tivoli Access Manager, tato procedura popisuje, jak použít odpovídající přístupové ovladače produktu Tivoli Access Manager na nově vytvořenou příponu. Tyto kroky jsou specifické pro servery zabezpečení IBM z/OS Security Server LDAP Server verze 1, vydání 2 nebo vyšší a IBM Security Server for OS/390 verze 2, vydání 10. Na oba servery se kolektivně odkazuje jako servery zabezpečení IBM z/OS a OS/390. Chcete-li přidat příponu k serverům zabezpečení IBM z/OS nebo OS/390: 1. Přidejte novou příponu k souboru serveru zabezpečení slapd.conf. Viz publikace z/OS LDAP Server Administration and Use Guide, chcete-li získat další podrobnosti o tom, jak aktualizovat konfigurační soubory serverů zabezpečení IBM z/OS nebo OS/390. 2. Restartujte servery zabezpečení IBM z/OS nebo OS/390. 3. Abyste přidali záznamy k nově vytvořeným příponám, proveďte následující: a. Vytvořte soubor LDIF. Tento příklad předpokládá, že nově vytvořená přípona je o=neworg,c=us: dn: o=neworg,c=us objectClass: organization objectClass: top o: neworg
b. Použijte odpovídající soubor LDIF jako vstup do příkazu ldapadd: ldapadd -D administrátor_ldap -w pwd_ldap -v -f jméno_souboru_ldif
4. Abyste mohli použít odpovídající přístupové ovladače Tivoli Access Manager pro nově vytvořenou příponu (přípona), proveďte následující:
352
IBM Tivoli Access Manager: Base: Administrativní příručka
a. Nebyly-li vytvořené žádné dodatečné domény Access Manager jiné než výchozí domény správy, vytvořte tento soubor LDIF: přípona aclpropagate=TRUE aclentry=group:cn=ivacld-servers,cn=securitygroups,secauthority=default:\ normal:csr aclentry=group:cn=remote-acl-users,cn=securitygroups,secauthority=default:\ normal:csr aclentry=group:cn=securitygroup,secauthority=default:object:ad:normal:\ wsr:sensitive:cwsr:critical:cwsr:restricted:cwsr aclentry=access-id:dn_domény_LDAP:object:ad:normal:rwsc:sensitive:\ cwsc:critical:cwsr:restricted:cwsr přípona ownerpropagate=TRUE entryOwner=group:cn=SecurityGroup,secAuthority=Default entryOwner=access-id:dn_domény_LDAP
Zpětné lomítko ( \ ) na konci každého řádku označuje, že tento řádek je kombinovaný s ostatními řádky bez mezer. b. Použijte aktualizace v souboru LDIF tak, že jej použijete jako vstup do příkazu ldapmodify: ldapmodify -h jméno_hostitele -D dn_administrátora_LDAP -w pwd_administrátora -v -f jméno_souboru_ldif
c. Avšak, pokud doména již byla vytvořená navíc k výchozí doméně správy a je-li vytvořená i nová přípona, budete muset pro každou tuto novou doménu použít také ACL. ACL přidáte do každé domény tím, že vytvoříte soubor LDIF podobný na: přípona aclentry=group:cn=ivacld-servers,cn=securitygroups,secauthority=\ přidaná_doména,cn=subdomains,secauthority=default:normal:csr aclentry=group:cn=remote-acl-users,cn=securitygroups,secauthority=\ přidaná_doména,cn=subdomains,secauthority=default:normal:csr aclentry=group:cn=securitygroup,secauthority=přidaná_doména,\ cn=subdomains,secauthority=default:object:ad:normal:rwsc:sensitive:\ rwsc:critical:rwsc:restricted:rwsc
d. Použijte aktualizace v souboru LDIF tak, že jej použijete jako vstup do příkazu ldapmodify: ldapmodify -h jméno_hostitele -D dn_administrátora_LDAP -w pwd_administrátora_LDAP -v -f jméno_souboru_ldif
V tomto případě odstraňte aclpropagate=TRUE ze souboru LDIF a znova spusťte příkaz ldapmodify.
Úlohy specifické pro Active Directory Microsoft Active Directory je infrastruktura podporovaná Windows 2000, která zahrnuje síťovou správu adresářových objektů a která má schopnost komunikovat s jinými adresářovými službami. Tato sekce obsahuje následující témata: v “Nastavení Microsoft Windows 2000 Domain Name System pro Active Directory” na stránce 354 Dodatek D. Správa registrů uživatelů
353
v “Aktualizace schématu produktu Tivoli Access Manager” v “Přidání uživatele produktu Tivoli Access Manager do systémové skupiny Active Directory” na stránce 355
Nastavení Microsoft Windows 2000 Domain Name System pro Active Directory Active Directory používá DNS (Domain Name System) jako mechanismus umístění řadiče domén. DNS umožňuje počítačům najít adresy IP řadičů domén. Pro režim s více doménami jsou požadované alespoň dvě domény z těchto typů domén: v primární doména, v podřízená doména primární domény, v strom domén v globálním stromu. Pro přepnutí při selhání jsou potřeba alespoň dva primární řadiče domén. Server DNS můžete nastavit před konfigurací řadičů domén nebo když konfigurujete primární řadič domén Active Directory. Existují dva způsoby, jak nastavit DNS pro Active Directory: 1. Konfigurujte DNS v kořenu globálního stromu. 2. Použijte zvláštní server DNS. Pokud konfigurujete DNS v kořenu globálního stromu, DNS je konfigurovaná automaticky na daném hostiteli, jedná-li se o první konfigurovaný řadič domén. Tento řadič domén a jeho repliky slouží jako servery DNS. Server DNS není nutně v hostiteli, který je řadičem domén v globálním stromu. Můžete použít libovolný server DNS. Pokud nepoužíváte server DNS založený na Windows 2000, kontaktujte svého administrátora DNS nebo prodejce serverů DNS, abyste zjistili, jestli váš server podporuje požadované standardy. Pokud server nepodporuje požadované standardy nebo danou zónu nelze konfigurovat, aby umožňovala dynamické aktualizace, musíte upravit existující infrastrukturu DNS.
Přidání nového jména domény do DNS Abyste přidali nové jméno domény do DNS, proveďte následující: 1. Klepněte na tlačítko Start (Spustit)→Programs (Programy)→Administrator Tools (Nástroje administrativy)→DNS, čímž otevřete DNS. 2. Rozbalte jméno hostitele a Forward Lookup Zones (Postoupené vyhledané zóny). 3. Vytvořte novou zónu (novou kořenovou doménu) nebo podřízenou doménu. 4. Pokud používáte oddělenou DNS, otevřete vlastnosti domény a změňte pole Allow dynamic updates (Umožnit dynamické aktualizace) na Yes.
Aktualizace schématu produktu Tivoli Access Manager Abyste provedli všechny operace produktu Tivoli Access Manager, potřebujete přidat schéma produktu Tivoli Access Manager do Active Directory. Schéma produktu Tivoli Access Manager je přidané do správce schémat, což je kořenový řadič domény v globálním stromu. Schéma produktu Tivoli Access Manager se automatickou aktualizuje na správce schémat během konfigurace produktu Tivoli Access Manager. Musíte manuálně aktualizovat schéma produktu Tivoli Access Manager pouze, když je Tivoli Access Manager konfigurovaný do jednoduché domény Active Directory (ne kořenové domény). Poznámka: Než aktualizujete schéma produktu Tivoli Access Manager, ověřte si, že ještě není ve správci schémat. Schéma produktu Tivoli Access Manager stačí v globálním stromu aktualizovat pouze jednou.
354
IBM Tivoli Access Manager: Base: Administrativní příručka
Abyste si ověřili, jestli je schéma produktu Tivoli Access Manager aktualizované ve vašem systému, proveďte následující: 1. Ve vašem řadiči domén jděte na tlačítko Start (Spustit)→ Programs (Programy)→ Administrative Tools (Nástroje administrativy)→ Active Directory Users and Computers (Uživatelé a počítače Active Directory). Objeví se dialog Active Directory Users and Computers (Uživatelé a počítače Active Directory). 2. V dialogu rozbalte doménu, která obsahuje složku Users (Uživatelé). 3. Klepněte pravým tlačítkem myši na složku Users (Uživatelé). Zobrazí se menu. 4. Klepněte na tlačítko New (Nové) v menu. Zobrazí se další menu. 5. Objeví-li se seznam tříd produktu Tivoli Access Manager pro Active Directory v menu ve formě URAF-xxx (například, URAF-container), potom schéma produktu Tivoli Access Manager je již ve správci schémat. Nepotřebujete aktualizovat schéma produktu Tivoli Access Manager. Abyste manuálně aktualizovali schéma produktu Tivoli Access Manager, proveďte následující: 1. Instalujte dobu běhu produktu Tivoli Access Manager v řadiči kořenové domény. 2. Spusťte příkaz adresář_aminstall\sbin\adschema_update –u AMConfID –p AMConfPWD kde: v adresář_aminstall je adresář, který instaluje produkt Tivoli Access Manager, v AMConfID je ID přihlášení konfigurace produktu Tivoli Access Manager, v AMConfPWD je heslo přihlášení konfigurace produktu Tivoli Access Manager. 3. Poté, co ověříte, že schéma produktu Tivoli Access Manager bylo přidané do správce schémat, můžete odinstalovat dobu běhu produktu Tivoli Access Manager z kořenové domény. Poznámka: Propagace schématu produktu Tivoli Access Manager zabere asi pět minut než se správce schémat přidá k řadiči nekořenové domény.
Přidání uživatele produktu Tivoli Access Manager do systémové skupiny Active Directory Chcete-li si vytvořit dostatečný přístup k úpravě uživatelů a atributů skupin, musíte přidat uživatele produktu Tivoli Access Manager do odpovídající systémové skupiny Active Directory. Abyste přidali uživatele do systémové skupiny Active Directory na systému, kde je konfigurovaný Active Directory jako registr uživatelů produktu Tivoli Access Manager, proveďte následující: 1. Přihlaste se jako Administrator. 2. Přejděte na Start (Spustit)→ Programs (Programy)→ Administrative Tools (Nástroje administrativy). 3. Klepněte na Active Directory Users and Computers (Uživatelé a počítače Active Directory) z menu. Objeví se dialog Active Directory Users and Computers (Uživatelé a počítače Active Directory). 4. Na levém navigačním panelu přejděte na Tivoli PD Domains (Domény Tivoli PD)→ default (předvolba)→ system (systém)→ users (uživatelé), kde je umístěný zásobník uživatelů v zásobníku registru uživatelů produktu Tivoli Access Manager. 5. Ze seznamu zobrazených uživatelů zvolte uživatele produktu Tivoli Access Manager, kterého chcete přidat do systémové skupiny Active Directory. 6. Klepněte pravým tlačítkem myši na uživatele produktu Tivoli Access Manager a klepněte na Properties (Vlastnosti). Zobrazí se okno Properties (Vlastnosti) pro zvoleného uživatele produktu Tivoli Access Manager. Dodatek D. Správa registrů uživatelů
355
7. Klepněte na ouško Member Of (Je členem). 8. Klepněte na tlačítko Add (Přidat). Zobrazí se okno Select Groups (Zvolit skupiny). 9. Zvolte odpovídající skupinu, do které chcete začlenit uživatele produktu Tivoli Access Manager a klepněte na tlačítko Add (Přidat). 10. Proveďte jedno z následujících: v Je-li účelem upravit atributy uživatele nebo skupiny pro jednoduchou doménu Active Directory, zvolte skupinu Domain Admins. v Je-li produkt Tivoli Access Manager konfigurovaný s použitím více domén Active Directory, zvolte skupinu Enterprise Admins. 11. Chcete-li jednoho uživatele přidat k více skupinám, tak tento proces přidání uživatele do skupiny opakujte. 12. Klepněte na tlačítko OK, čímž ukončíte všechna otevřená okna.
Úlohy specifické pro Novell Novell eDirectory lze konfigurovat pro použití jako uživatelský registr Tivoli Access Manager úplně stejným způsobem jako kterýkoliv jiný adresář LDAP. Tento výběr popisuje několik kroků, které jsou jedinečné pro tuto konfiguraci. Úlohy zahrnují: v Aktualizace schématu eDirectory s použitím obslužného programu správy adresáře Novell eDirectory ConsoleOne v Aktivity údržby Novell eDirectory, které mohou poškodit úpravy schématu použité produktem Tivoli Access Manager
Aktualizace schématu eDirectory Instalujete-li novou zabezpečenou doménu produktu Tivoli Access Manager, schéma produktu Tivoli Access Manager je instalované do NSD (Novell eDirectory Server) automaticky při konfiguraci serveru politik Tivoli Access Manager. Avšak, před konfigurací serveru politik, existuje několik úprav Novell eDirectory, které je třeba provést nejdřív s použitím obslužného programu správy adresářů ConsoleOne produktu Novell. Poznámka: Předvolené schéma Novell eDirectory předpokládá, že adresář nepoužívá třídy objektů X.500 inetOrgPerson nebo groupOfNames. Podle předvolby jsou tyto třídy mapované do tříd eDirectory User (Uživatel) a Group (Skupina) současně. Protože Tivoli Access Manager používá třídy objektů inetOrgPerson a groupOfNames pro tvoření svých vlastních uživatelů a skupin, úpravy předvolených schémat eDirectory jsou povinné. Chcete-li automaticky aktualizovat schéma Novell eDirectory před konfigurací serveru politik Tivoli Access Manager, proveďte následující: 1. Spusťte obslužný program správy adresářů ConsoleOne produktu Novell. 2. Zvolte objekt organizace ve stromu Novell eDirectory. Seznam objektů se zobrazí na pravé straně okna ConsoleOne. 3. Klepněte pravým tlačítkem myši na objekt LDAP group (Skupina LDAP) (ne LDAP server), a klepněte na Properties (Vlastnosti) z menu. 4. Klepněte na ouško Class Map (Mapování tříd) a tabulku jmen tříd LDAP. Zobrazí se jména tříd Novell eDirectory. 5. Smažte záznamy s třídami LDAP inetOrgPerson a groupOfNames. 6. Klepněte na tlačítko Apply (Použít) a potom klepněte na Close (Zavřít).
356
IBM Tivoli Access Manager: Base: Administrativní příručka
7. Klepněte na ouško Attribute Map (Mapování atributů) a tabulku jmen atributů LDAP. Zobrazí se jména atributů Novell. 8. Procházejte tabulku dokud nenajdete atribut Novell eDirectory member (člen). Zkontrolujte hodnotu odpovídajícího atributu LDAP. v Je-li atribut LDAP člen, není třeba cokoliv měnit. v Zobrazuje-li atribut předvolenou hodnotu uniqueMember, musíte jej upravit. 9. Klepněte na tlačítko Modify (Upravit). Zobrazí se okno Attribute Mapping (Mapování atributů). 10. Změňte pole Primary LDAP Attribute (Primární atribut LDAP) z uniqueMember (jedinečný člen) na member (člen). 11. Změňte pole Secondary LDAP attribute (Sekundární atribut LDAP) z member (člen) na uniqueMember (jedinečný člen). 12. Klepněte na tlačítko OK. Okno Attribute Mapping (Mapování atributů) se vyčistí. 13. Používáte-li Solaris, přejděte ke kroku 18. Používáte-li Windows NT, budete asi muset přidat jiné mapování pro atribut LDAP ndsHomeDirectory. 14. Abyste přidali jiné mapování pro atribut LDAP ndsHomeDirectory, klepněte na tlačítko Add (Přidat) napravo od okna Attribute Mappings (Mapování atributů). OknoAttribute Mapping (Mapování atributů) se přepíše a znova objeví. 15. Z menu pole Novell eDirectory NSD Attribute (Atribut NSD) klepněte na Home Directory (Domovský adresář). 16. V poli Primary LDAP Attribute (Primární atribut LDAP) klepněte na ndsHomeDirectory. 17. Klepněte na tlačítko OK a okno Attribute Mapping (Mapování atributů) se vyčistí. 18. Klepněte na tlačítko OK v dialogu Properties (Vlastnosti) a okno Properties (Vlastnosti) se vyčistí.
Aktivity údržby Novell eDirectory, které mohou poškodit úpravy schémat použité produktem Tivoli Access Manager Novell eDirectory definuje třídy objektů User (Uživatel) a Group (Skupina) jako součást svého základního schématu. Příklady těchto tříd objektů jsou vytvořené administrátorem eDirectory při definování uživatele a skupiny současně. Obě z těchto tříd objektů jsou definované eDirectory jako uzly listů. eDirectory přidá atribut X-NDS_NOT_CONTAINER ’1’ do každé z těchto definic tříd objektů, které uvádí, že nejsou objekty zásobníků. To, že nejsou objekty typu zásobník, znamená, že je nelze definovat pod úrovní těchto tříd objektů. Produkt Tivoli Access Manager požaduje mít schopnost přidat svůj vlastní objekt pod předtím existující uživatele a skupiny eDirectory. Tak je produkt Tivoli Access Manager může importovat a využívat. Když produkt Tivoli Access Manager přidá svou vlastní definici tříd objektů do schématu eDirectory, také definuje eDirectory třídy objektů User (Uživatel) a Group (Skupina), aby tak umožnil úrovním těchto tříd, aby se staly objekty typu zásobník. Novell eDirectory umožňuje tuto změnu ve své definici schématu. Následující akce administrativy Novell eDirectory způsobí zrušení úprav produktu Tivoli Access Manager do třídy objektů User (Uživatel). Třída objektů Group (Skupina) není ovlivněná. v Spuštění nástroje pro opravu databáze eDirectory ndsrepair s použitím volby rebuild schema (přestavit schéma). v Spuštění Basic Repair z konzole iManager a spuštění local database repair (oprava pro lokální databázi) volbou rebuild operational schema (přestavba volitelného schématu). v Aplikování aktualizace záplaty do Novell eDirectory. Dodatek D. Správa registrů uživatelů
357
v Aktualizace Novell eDirectory na nejnovější verzi. Pokud bude nutné provést libovolnou z těchto operací po konfiguraci produktu Tivoli Access Manager do serveru eDirectory, spusťte následující příkaz Tivoli Access Manager ihned, abyste zajistili, že definice třídy objektů User (Uživatel) je obnovená. ivrgy_tool(.exe) -h jméno_serveru_edir -p port -D dn_administrátora_edir -w heslo_administrátora_edir schema
Obslužný program ivrgy_tool lze nalézt v následujícím adresáři Tivoli Access Manager: Windows: c:\Program Files\Tivoli\Policy Director\sbin UNIX: /opt/PolicyDirector/sbin
Tivoli Access Manager nepřidá adresář sbin do systémové cesty PATH> Musíte spustit obslužný program ivrgy_tool z adresáře sbin.
358
IBM Tivoli Access Manager: Base: Administrativní příručka
Dodatek E. Poznámky Tyto informace byly vytvořeny pro produkty a služby, nabízené v USA. Společnost IBM nemusí v ostatních zemích nabídnout produkty, služby a funkce popsané v tomto dokumentu. Informace o produktech a službách, které jsou momentálně ve vaší zemi dostupné, můžete získat od zástupce společnosti IBM pro vaši oblast. Žádný z odkazů na produkty, programové vybavení nebo služby není zamýšlen jako tvrzení, že lze použít pouze tyto produkty, programové vybavení nebo služby společnosti IBM. Jako náhrada mohou být použity libovolné funkčně ekvivalentní produkty, programové vybavení nebo služby, které neporušují žádné intelektuální vlastnické právo společnosti IBM. Za operace prováděné produkty, programovým vybavením nebo službami, které nepochází od společnosti IBM, nese zodpovědnost uživatel. Společnost IBM může mít k dispozici patenty nebo podané patentové přihlášky, vztahující se k informacím popsaným v tomto dokumentu. Vlastnictví tohoto dokumentu vám nedává žádná práva k těmto patentům. Písemné žádosti o licenci můžete posílat na adresu: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY 10504-1785 U.S.A. Pokud máte zájem o licenci v zemi s dvojbajtovou znakovou sadou (DBCS), kontaktujte zastoupení společnosti IBM ve vaší zemi, nebo písemně zastoupení společnosti IBM na adrese: IBM World Trade Asia Corporation Licensing 2-31 Roppongi 3-chome, Minato-ku Tokyo 106, Japan Následující odstavec se netýká Velké Británie nebo kterékoliv jiné země, kde taková opatření odporují místním zákonům: SPOLEČNOST INTERNATIONAL BUSINESS MACHINES CORPORATION TUTO PUBLIKACI POSKYTUJE TAKOVOU, ″JAKÁ JE″, BEZ JAKÝCHKOLIV ZÁRUK, VYJÁDŘENÝCH NEBO ODVOZENÝCH, VČETNĚ, ALE NE VÝHRADNĚ, ODVOZENÝCH ZÁRUK PORUŠENÍ ZÁKONŮ, PRODEJNOSTI NEBO VHODNOSTI PRO URČITÝ ÚČEL. Některé právní řády nepřipouštějí omezení či vyvázání se ze záruk nebo odpovědnosti za následné či nepředvídatelné škody. V takovém případě se na vás výše uvedené omezení nevztahuje. Tato publikace může obsahovat technické nepřesnosti nebo typografické chyby. Informace zde uvedené jsou pravidelně aktualizovány a v příštích vydáních této publikace již budou tyto změny zahrnuty. Společnost IBM má právo kdykoliv bez upozornění zdokonalovat nebo měnit produkty a programy popsané v této publikaci. Všechny odkazy na tyto informace, uvedené na webových stránkách jiných provozovatelů než společnosti IBM jsou poskytovány pouze pro vaši potřebu a v žádném případě neslouží k propagaci těchto webových stránek. Materiály, uvedené na takovýchto webových stránkách nejsou součástí materiálů, určených pro tento produkt IBM, a proto tyto webové stránky používáte pouze na vlastní riziko.
IBM Tivoli Access Manager: Base: Administrativní příručka
Pokud si tyto informace neprohlížíte v kopii s trvalým záznamem, je možné, že se nezobrazily fotografie a barevné ilustrace.
Ochranné známky Následující termíny jsou ochranné známky společnosti International Business Machines Corporation v USA, v jiných zemích nebo obojí: AIX DB2 IBM IBM logo OS/390 SecureWay Tivoli Tivoli logo Universal Database WebSphere zSeries z/OS Lotus a Domino jsou ochranné známky společností International Business Machines Corporation a Lotus Development Corporation v USA, v jiných zemích nebo obojí. Java a všechny ochranné známky a loga odvozené od Javy jsou ochrannými známky nebo registrovanými obchodními známkami společnosti Sun Microsystems, Inc. v USA a dalších zemích. Microsoft a Windows jsou ochranné známky společnosti Microsoft Corporation v USA, v jiných zemích nebo obojí. UNIX je registrovaná ochranná známka v USA a v dalších zemích, jejíž licenci poskytuje výhradně společnost X/Open Company Limited. Další jména společností, produktů nebo služeb mohou být ochrannými známkami jiných společností.
Dodatek E. Poznámky
361
362
IBM Tivoli Access Manager: Base: Administrativní příručka
Slovníček A access control (řízení přístupu) V zabezpečení počítače jde o proces, který zajišťuje, že zdroje počítačového systému mohou používat pouze oprávnění uživatelé a pouze oprávněným způsobem. access control list (ACL) (přístupový seznam) V zabezpečení počítačů jde o seznam, který je přidružen k objektu a který identifikuje všechny subjekty, které mohou k danému objektu přistupovat, a který určuje jejich přístupová práva k tomuto objektu. Například přístupový seznam je seznam, který je přidružen k souboru a který identifikuje uživatele, kteří mohou přistupovat k tomuto souboru, a který identifikuje přístupová práva těchto uživatelů k danému souboru. access permission (oprávnění k přístupu) přístupu, která platí pro celý objekt,
Oprávnění k
action (akce) Atribut oprávnění přístupového seznamu. Viz též access control list (přístupový seznam). ACL
Viz access control list (přístupový seznam).
administration service (administrativní služba) Plug-in program autorizačního rozhraní API, který se používá k provádění administrativních požadavků na aplikaci správce zdrojů produktu Tivoli Access Manager. Administrativní služba odpovídá vzdáleným požadavkům z příkazu pdadmin a provádí úlohy, jako např. výpis objektů pod určitým uzlem v prostoru chráněných objektů. Zákazníci si mohou tyto služby sami vytvořit pomocí sady pro vývoj authorization ADK. attribute list (seznam atributů) Propojený seznam, který obsahuje rozšířené informace používané k provedení rozhodnutí o autorizaci. Seznamy atributů se skládají z párů klíčové_slovo = hodnota. authentication (autentizace) (1) V zabezpečení počítačů jde o ověření totožnosti uživatele nebo způsobilosti uživatele přistoupit k objektu. (2) V zabezpečení počítačů jde o proces ověření, že zpráva nebyla pozměněna nebo porušena. (3) V zabezpečení počítačů jde o proces, který se používá k ověření uživatele informačního systému nebo chráněných zdrojů. Viz též multi-factor authentication (vícefaktorová autentizace), network-based authentication (autentizace založená na síti) a step-up authentication (zvýšená autentizace). authorization (autorizace) (1) V počítačovém zabezpečení jde o právo udělené uživateli, aby mohl komunikovat nebo používat počítačový systém. (2) Proces, který uživateli udělí buď úplný nebo omezený přístup k objektu, zdroji nebo funkci. authorization rule (autorizační pravidlo) (pravidlo).
authorization service plug-in (plug-in program autorizační služby) Dynamická knihovna (knihovna DLL nebo sdílená knihovna), kterou může načíst klient autorizačního rozhraní API produktu Tivoli Access Manager během své inicializace, aby mohl provádět operace, které rozšiřují rozhraní služeb v rámci autorizačního rozhraní API. Rozhraní služeb, která jsou v současné době k dispozici jsou: administrativní rozhraní, rozhraní pro externí autorizaci, rozhraní pro úpravu pověření, rozhraní pro nároky a rozhraní pro manipulaci s PAC. Zákazníci si mohou tyto služby sami vytvořit pomocí sady pro vývoj authorization ADK.
B BA
Viz basic authentication (základní autentizace).
basic authentication (základní autentizace) Politika autentizace, která vyžaduje, aby uživatel znal platné jméno uživatele a heslo, než mu bude povoleno přistoupit k zabezpečenému online zdroji. bind (spojit) Svázat identifikátor s jiným objektem v programu. Například spojit identifikátor s hodnotou, adresou nebo jiným identifikátorem, nebo spojit formální parametry a skutečné parametry. blade (rozřazovač) Komponenta, která poskytuje služby a komponenty specifické pro danou aplikaci. business entitlements (obchodní nároky) Doplňkový atribut pověření uživatele, který popisuje jemně strukturované podmínky, které lze použít při požadavku na autorizaci ke zdrojům.
C CA
Viz certificate authority (vydavatel certifikátů).
CDAS Viz Cross Domain Authentication Service (služba CDAS). CDMF Viz Cross Domain Mapping Framework (základní struktura CDMF). certificate (certifikát) V zabezpečení počítačů jde o digitální dokument, který spojuje veřejný klíč s totožností vlastníka certifikátu, a tím umožní vlastníkovi certifikátu, aby se autentizoval. Certifikát je vydán vydavatelem certifikátů. certificate authority (CA - vydavatel certifikátů) Organizace, která vydává certifikáty. Vydavatel certifikátů autentizuje totožnost vlastníka certifikátu a služby, které je vlastník oprávněn používat. Tato společnost dále vydává nové certifikáty, obnovuje stávající certifikáty a odvolává certifikáty, které patří uživatelům, kteří již nejsou oprávněni je používat.
363
CGI
Viz common gateway interface (program CGI).
cipher (šifra) Zašifrovaná data, která jsou nečitelná, dokud nebudou pomocí klíče převedena do prostých dat (dešifrovaných). common gateway interface (program CGI) Internetový standard pro definování skriptů, které předávají informaci z webového serveru do aplikačního programu prostřednictvím požadavku HTTP a naopak. Skript CGI je program CGI, který je napsán ve skriptovacím jazyce, jako např. v jazyce Perl. configuration (konfigurace) (1) Způsob, kterým je organizován a propojen hardware a software systémů zpracování dat. (2) Počítače, zařízení a programy, které vytvářejí systém, podsystém nebo síť. connection (připojení) (1) V datové komunikaci jde o zavedené sdružení funkčních jednotek pro postupování informací. (2) V protokolu TCP/IP jde o cestu mezi dvěma aplikacemi protokolu, které poskytují spolehlivou službu doručení toku dat. V Internetu připojení vede z aplikace TCP/IP na jednom systému k aplikaci TCP na jiném systému. (3) V systémových komunikacích jde o linku, prostřednictvím které je možné předávat data mezi dvěma systémy, nebo mezi systémem a zařízením. container object (objekt typu zásobník) Strukturální označení, které organizuje prostor objektů do rozdílných funkčních oblastí. cookie Informace, kterou server ukládá na počítači klienta a ke které se přistupuje během následujících relací. Cookies umožňují, aby si servery pamatovaly určité informace o klientech. credentials (pověření) Podrobné informace získané během autentizace, které popisují uživatele, všechna přidružení ke skupinám a další atributy totožnosti spojené se zabezpečením. Pověření je možné používat k provozování velkého množství služeb, jako např. autorizace, monitorování a delegace. credentials modification service (služba pro úpravu pověření) Plug-in program autorizačního rozhraní API, který se používá k úpravě pověření produktu Tivoli Access Manager. Služby pro úpravu pověření, které byly vyvinuty externě přímo zákazníky, jsou omezeny na provádění operací pro přidání a odstranění atributů ze seznamu atributů pověření, a to pouze pro ty atributy, které se pokládají za upravitelné. cross domain authentication service (služba CDAS) Služba produktu WebSEAL, jejíž součástí je mechanismus sdílené knihovny, který vám dovoluje nahradit předvolený mechanismus autentizace produktu WebSEAL za uživatelsky přizpůsobený proces, který vrátí totožnost produktu Tivoli Access Manager do produktu WebSEAL. Viz též WebSEAL. cross domain mapping framework (základní struktura CDMF) Programovací rozhraní, které dovoluje, aby vývojář upravil mapování totožností uživatelů a zacházení s atributy uživatelů, pokud se používá funkce e-Community jednotného přihlášení produktu WebSEAL.
364
IBM Tivoli Access Manager: Base: Administrativní příručka
D daemon (démon) Program, který svoji činnost provádí bez účasti uživatele, a který souvisle nebo pravidelně provádí systémové funkce, jako např. kontrolu sítě. Některé démony jsou spouštěny automaticky, aby prováděly své úlohy. Jiné démony pracují pravidelně. directory schema (adresářové schéma) Platné typy atributů a třídy objektů, které se mohou v adresáři objevit. Typy atributů a třídy objektů definují syntaxi hodnot atributů, které atributy musí adresář obsahovat a které atributy adresář obsahovat nemusí. distinguished name (rozlišovací jméno) Jméno, které jedinečně identifikuje záznam v adresáři. Rozlišovací jméno se skládá z párů atribut:hodnota, které jsou odděleny čárkami. digital signature (digitální podpis) V elektronickém obchodu jde o data, která jsou připojena k jednotce dat, nebo o data, která jsou zašifrovanou informací jednotky dat, a která umožňují příjemci datové jednotky ověřit zdroj a integritu jednotky a rozeznat potenciální padělek. DN
Viz distinguished name (rozlišovací jméno).
domain (doména) (1) Logické seskupení uživatelů, systémů a zdrojů, které sdílí společné služby a obvykle pracuje na společném úkolu. (2) Ta část počítačové sítě, ve které jsou zdroje zpracování dat řízeny stejným společným ovládáním. Viz též domain name (jméno domény). domain name (jméno domény) V internetové sadě protokolů jde o jméno hostitelského systému. Jméno domény se skládá z posloupnosti podjmén, které jsou odděleny oddělovacím znakem. Například pokud plně kvalifikované jméno domény hostitelského systému je as400.vnet.ibm.com, pak každý z následujících příkladů je jméno domény: as400.rchland.vnet.ibm.com, vnet.ibm.com, ibm.com.
E EAS Viz External Authorization Service (externí autorizační služba). encryption (šifrování) V zabezpečení počítačů jde o proces transformace dat do nesrozumitelné formy takovým způsobem, aby nebylo možné originální data buď získat, nebo aby je bylo možné získat pouze pomocí dešifrovacího procesu. entitlement (nárok) Datová struktura, která obsahuje informace o realizované bezpečnostní politice. Nároky obsahují strategická data nebo schopnosti, které jsou naformátovány takovým způsobem, aby byly pro určitou aplikaci srozumitelné. entitlement service (služba nároků) Plug-in program autorizačního rozhraní API, který se používá pro daný objekt nebo sadu podmínek k navrácení nároků z externího zdroje. Nároky jsou obvykle data specifická pro aplikaci, která mohou být nějakým způsobem zpracována aplikací správce zdrojů, nebo která je možné přidat k pověření objektu, aby je bylo
možné použít později v průběhu procesu autorizace. Zákazníci si mohou tyto služby sami vytvořit pomocí sady pro vývoj authorization ADK. external authorization service (externí autorizační služba) Plug-in program autorizačního rozhraní API, který se používá k provádění rozhodnutí o autorizaci, specifických pro danou aplikaci nebo prostředí. Tato rozhodnutí jsou součástí procesu rozhodování o autorizaci produktu Tivoli Access Manager. Zákazníci si mohou tyto služby sami vytvořit pomocí sady pro vývoj authorization ADK.
F
Internet suite of protocols (internetová sada protokolů) Sada protokolů, které byly vyvinuty, aby byly používány na internetu, a které byly publikovány jako RFC (Requests for Comments) prostřednictvím společnosti IETF (Internet Engineering Task Force). interprocess communication (IPC) (komunikace mezi procesy) (1) Proces, pomocí kterého si programy předávají data mezi sebou a synchronizují své aktivity. Semafory, signály a interní fronty zpráv jsou běžnými politikami komunikace mezi procesy. (2) Mechanismus operačního systému, který dovoluje procesům, aby mezi sebou v rámci stejného počítače nebo přes síť komunikovaly. IP
file transfer protocol (FTP) V internetové sadě protokolů jde o protokol aplikační vrstvy, který používá služby TCP (Transmission Control Protocol) a Telnet pro přenos souborů dávkových dat mezi počítači nebo hostiteli.
IPC Viz Interprocess Communication (IPC) (komunikace mezi procesy).
J
G global signon (GSO) Pružné řešení jednotného přihlášení, které umožňuje uživateli, aby webovému aplikačnímu serveru typu back-end poskytl alternativní jména uživatele a hesla. GSO uděluje uživateli přístup k počítačovým zdrojům, k jejichž použití je autorizován — prostřednictvím jediného přihlášení. Toto řešení bylo navrženo pro velké společnosti, které se skládají z mnoha systémů a aplikací a jejichž počítačové prostředí je heterogenní a distribuované. V takovém prostředí GSO eliminuje potřebu, aby si uživatelé spravovali více jmen uživatelů a hesel. Viz též single signon (jednotné přihlášení). GSO
Viz Internet Protocol (protokol IP).
Viz global signon (GSO).
H
junction (spojení) HTTP nebo HTTPS propojení mezi předřazeným serverem WebSEAL a webovým aplikačním serverem typu back-end. Spojení umožňují produktu WebSEAL provádět ochranné služby v zastoupení serveru typu back-end.
K key (klíč) V zabezpečení počítačů jde o posloupnost znaků, která se používá v šifrovacím algoritmu pro zašifrování nebo dešifrování dat. Viz private key (soukromý klíč) a public key (veřejný klíč). key database file (databázový soubor klíčů) (klíčový řetězec). key file (soubor klíčů)
host (hostitel) Počítač, který je připojen k síti (jako např. k internetu nebo síti SNA) a který poskytuje přístupový bod k dané síti. Hostitel může také, v závislosti na prostředí, poskytovat centralizované řízení sítě. Hostitel může být klientem, serverem, nebo klientem a serverem současně. HTTP
Viz Hypertext Transfer Protocol (protokol HTTP).
hypertext transfer protocol (protokol HTTP) V internetové sadě protokolů jde o protokol, který se používá k přenosu a zobrazení hypertextových dokumentů.
I Internet protocol (protokol IP) V internetové sadě protokolů jde od bezspojový protokol, který směruje data v rámci sítě, nebo propojených sítí a vystupuje jako mezivrstva mezi vyššími vrstvami protokolu a fyzickou sítí.
Viz key ring
Viz key ring (klíčový řetězec).
key pair (pár klíčů) V zabezpečení počítačů jde o veřejný a soukromý klíč. Pokud se pár klíčů používá při šifrování, odesilatel použije veřejný klíč k zašifrování zprávy a příjemce použije soukromý klíč pro dešifrování zprávy. Pokud se pár klíčů používá pro podepisování, signatář vlastní soukromý klíč, aby mohl zašifrovat zprávu a příjemce použije veřejný klíč, aby dešifroval zprávu, a tak mohl ověřit podpis. key ring (klíčový řetězec) V zabezpečení počítačů jde o soubor, který obsahuje veřejné klíče, soukromé klíče, důvěryhodné zdroje a certifikáty.
L LDAP
Viz Lightweight Directory Access Protocol.
lightweight directory access protocol (LDAP) Otevřený protokol, který (a) používá protokol TCP/IP, aby poskytl přístup k adresářům, které podporují model X.500, a (b) nevyvolá požadavky na zdroje komplexnějšího protokolu X.500 Directory Access Protocol (DAP). Aplikace, které používají LDAP, (známé jako adresářové aplikace) mohou Slovníček
365
používat adresář jako obecné úložiště dat a pro získávání informací o lidech nebo službách, jako např. o adresách elektronické pošty, veřejných klíčích, nebo konfiguračních parametrech specifických pro službu. LDAP byl původně uveden v RFC 1777. LDAP verze 3 je uveden v RFC 2251 a společnost IETF pokračuje v práci na dalších standardních funkcích. Některá standardní schémata definovaná společností IETF pro LDAP je možné nalézt v RFC 2256.
permission (oprávnění) Schopnost přistoupit ke chráněnému objektu, jako např. k souboru nebo adresáři. Počet a význam oprávnění pro daný objekt je nadefinován v přístupovém seznamu. Viz též access control list (přístupový seznam).
lightweight third party authentication (LTPA) Základní struktura autentizace, která umožňuje realizaci jednotného přihlášení pro sadu webových serverů, které jsou umístěny v jedné internetové doméně.
policy server (server politik) Server produktu Tivoli Access Manager, který spravuje informace o umístění dalších serverů v rámci zabezpečené domény.
LTPA
Viz lightweight third party authentication.
M
Sada pravidel, která se použijí ke správě
polling (systém výzev) Proces, ve kterém je v pravidelných intervalech vyslýchána databáze, aby se určilo, zda není nutné přenést nějaká data. POP Viz protected object policy (politika chráněného objektu).
management domain (doména správy) Předvolená doména, ve které produkt Tivoli Access Manager vynucuje uplatňování bezpečnostních politik pro autentizaci, autorizaci a řízení přístupu. Tato doména se vytvoří během konfigurace serveru politik. Viz též domain (doména). management server (server správy) server (server politik). metadata dat.
Zastaralé. Viz policy
portal (portál) Integrovaný webový server, který dynamicky vytváří přizpůsobený seznam webových zdrojů, jako např. odkazů, obsahu nebo služeb, jenž je k dispozici určitým uživatelům, a to na základě oprávnění přístupu. privilege attribute certificate (certifikát atributu oprávnění) Digitální dokument, který obsahuje atributy autentizace a autorizace objektu a schopnosti objektu.
Data, která popisují charakteristiky uložených
migration (migrace) Instalace nové verze nebo vydání programu, která má nahradit dřívější verzi nebo vydání. multi-factor authentication (vícefaktorová autentizace) Politika chráněného objektu (POP), která nutí uživatele, aby se autentizoval pomocí dvou nebo více úrovní autentizace. Řízení přístupu ke chráněnému zdroji může například vyžadovat, aby se uživatel autentizoval jak pomocí jména uživatele/hesla, tak i pomocí jména uživatele/token passcode. Viz též protected object policy (politika chráněného objektu). multiplexing proxy agent (MPA) Přenosová brána, která dokáže pojmout více přístupů klientů. Tyto přenosové brány se někdy nazývají bránami WAP (Wireless Access Protocol), a to tehdy, když klient přistupuje do zabezpečené domény pomocí protokolu WAP. Přenosové brány vytvářejí jediný autentizovaný kanál k původnímu serveru a všechny požadavky a odpovědi klientů ″tunelují″ tímto kanálem.
N network-based authentication (autentizace založená na síti) Politika chráněného objektu (POP), která řídí přístup k objektům na základě IP adresy uživatele. Viz též protected object policy (politika chráněného objektu).
P PAC Viz privilege attribute certificate (certifikát atributu oprávnění).
366
policy (politika) zdrojů.
IBM Tivoli Access Manager: Base: Administrativní příručka
privilege attribute certificate service (služba certifikátu atributu oprávnění) Klientský plug-in program autorizačního rozhraní API, který překládá PAC v předdefinovaném formátu do pověření produktu Tivoli Access Manager a naopak. Tyto služby je možné použít také k zabalení nebo seřazení pověření produktu Tivoli Access Manager před jejich přenesením na další členy zabezpečené domény. Zákazníci si mohou tyto služby sami vytvořit pomocí sady pro vývoj authorization ADK. Viz též privilege attribute certificate (certifikát atributu oprávnění). protected object (chráněný objekt) Logické znázornění skutečného systémového zdroje, které se používá pro aplikaci politik ACL a POP a pro autorizaci přístupu uživatele. Viz též protected object policy (politika chráněného objektu) a protected object space (prostor chráněných objektů). protected object policy (politika chráněného objektu) Typ bezpečnostní politiky, která zavádí podmínky pro operace s přístupem ke chráněnému objektu, povolené politikou ACL. Správce zdrojů je odpovědný za to, že vynutí splnění podmínek POP. Viz též access control list (přístupový seznam), protected object (chráněný objekt) a protected object space (prostor chráněných objektů). protected object space (prostor chráněných objektů) Virtuální objektové znázornění skutečných systémových zdrojů, které se používá pro aplikaci politik ACL a POP a které používá autorizační služba. Viz též protected object (chráněný objekt) a protected object policy (politika chráněného objektu).
private key (soukromý klíč) V zabezpečení počítačů jde o klíč, který zná pouze jeho vlastník. Porovnejte s public key (veřejným klíčem). public key (veřejný klíč) V zabezpečení počítačů jde o klíč, který je k dispozici všem. Porovnejte se private key (soukromým klíčem).
Q quality of protection (úroveň zabezpečení) Úroveň zabezpečení dat, která je určena kombinací podmínek pro autentizaci, integritu a utajení.
R registry (registr) Úložiště dat, které obsahuje informace o přístupu a konfiguraci uživatelů, systémů a softwaru. replica (replika) Server, který obsahuje kopii adresáře nebo adresářů jiného serveru. Repliky zálohují servery ve smyslu zvýšení výkonnosti nebo snížení doby odezev, a také ve smyslu zajištění integrity dat. resource object (objekt typu prostředek) Znázornění skutečného síťového prostředku, jako např. služby, souboru, nebo programu. response file (soubor odpovědí) Soubor, který obsahuje sadu předdefinovaných odpovědí na dotazy, které pokládá program a které se používají namísto zadávání těchto hodnot postupně. role activation (aktivace role) přístupu na roli.
Proces aplikování oprávnění
role assignment (přiřazení role) Proces přiřazení role uživateli, takže tento uživatel bude mít odpovídající oprávnění přístupu k objektu, nadefinovanému v této roli. routing file (soubor směrování) Soubor ASCII, který obsahuje příkazy, které řídí konfiguraci zpráv. RSA encryption (šifrování RSA) Systém pro šifrování pomocí veřejného klíče, který se používá pro šifrování a autentizaci. Byl představen Ronem Rivestem, Adi Shamirem a Leonardem Adlemanem v roce 1977. Zabezpečení systému závisí na obtížnosti vydělení výsledku dvěma velkými prvočísly. rule (pravidlo) Jeden nebo více logických příkazů, které dovolují serveru událostí rozeznávat vzájemné souvislosti mezi jednotlivými událostmi (vzájemná souvislost událostí) a automaticky provádět příslušné odpovědí. run time (doba zpracování) Časový úsek, během kterého se provádí počítačový program. Runtime prostředí je prováděcí prostředí.
S scalability (škálovatelnost) Schopnost síťového systému odpovídat na zvyšující se počet uživatelů, kteří požadují zdroje. schema (schéma) Sada příkazů vyjádřená v jazyce definujícím data, která zcela popisuje strukturu databáze. Pro relační databázi jde o schéma, které definuje tabulky, pole v každé tabulce a vztahy mezi poli a tabulkami. secure sockets layer (SSL) Protokol zabezpečení, který poskytuje utajení komunikace. SSL umožňuje aplikacím klient/server, aby komunikovaly způsobem, který byl navržen tak, aby bránil naslouchání, falšování a padělání zpráv. SSL byl vyvinut společnostmi Netscape Communications Corp. a RSA Data Security, Inc. security management (správa zabezpečení ochrany dat) Obor správy, který adresuje schopnost organizace řídit přístup k aplikacím a datům, která jsou kritická pro její úspěch. self-registration (vlastní registrace) Proces, ve kterém uživatel může zadat požadovaná data a stát se registrovaným uživatelem produktu Tivoli Access Manager, aniž by bylo nutné zapojit administrátora. service (služba) Práce prováděná serverem. Služba může být jednoduchý požadavek na data, která mají být odeslána nebo uložena (jako např. u souborových serverů, HTTP serverů, serverů elektronické pošty nebo serverů finger), nebo to může být podstatně komplexnější práce, jako např. u tiskových serverů a provozních serverů. silent installation (tichá instalace) Instalace, která neposílá na konzoli zprávy, ale místo toho ukládá zprávy a chyby do souborů protokolu. Tichá instalace může také používat soubory odpovědí jako svůj datový vstup. Viz též response file (soubor odpovědí). single signon (SSO - jednotné přihlášení) Schopnost uživatele přihlásit se jednou a pak přistupovat k více aplikacím, aniž by se musel přihlašovat ke každé aplikaci samostatně. Viz též global signon (GSO). SSL
Viz Secure Sockets Layer.
SSO
Viz Single Signon (jednotné přihlášení).
step-up authentication (zvýšená autentizace) Politika chráněného objektu (POP), která je založena na předkonfigurované hierarchii úrovní autentizace a která vynucuje určitou úroveň autentizace v závislosti na politice, která je nastavena na daném zdroji. Politika POP zvýšené autentizace nenutí uživatele, aby se autentizoval pomocí více úrovní autentizace, chce-li přistoupit k danému zdroji, ale vyžaduje, aby se uživatel autentizoval minimálně na takové úrovni, která je vyžadována politikou chránící daný zdroj. suffix (přípona) Rozlišovací jméno, které určuje nejvyšší záznam v lokálně držené hierarchii adresářů. Z důvodu relativity schématu pojmenování používaného v protokolu LDAP (Lightweight Directory Access Protocol) toto Slovníček
367
rozlišovací jméno je také příponou každého dalšího záznamu v této hierarchii adresářů. Server adresářů může mít více přípon, z nichž každá určuje lokálně drženou hierarchii adresářů.
T token (1) V lokální počítačové síti jde o symbol oprávnění, který se úspěšně předává z jedné datové stanice na další, aby označil stanici, která dočasně řídí přenosové médium. Každá datová stanice má možnost získat a používat token k řízení média. Token je určitá zpráva nebo bitový vzor, který podepisuje oprávnění, které se má přenést. (2) V lokálních počítačových sítích jde o posloupnost bitů, která se předává z jednoho zařízení na další spolu s přenosovým médiem. Má-li token připojena data, stane se rámcem. trusted root (důvěryhodný zdroj) V protokolu SSL jde o veřejný klíč a přidružené rozlišovací jméno vydavatele certifikátů.
U uniform resource identifier (URI - jednotný identifikátor zdroje) Řetězec znaků, který se používá k identifikaci obsahu na internetu, včetně jména zdroje (adresáře a jména souboru), umístění zdroje (počítače, na kterém daný adresář a jméno souboru existuje), a způsobu, jak je k danému zdroji možné přistupovat (protokol, např. HTTP). Příkladem URI je URL. uniform resource locator (URL - jednotný lokátor zdroje, adresa URL) Posloupnost znaků, která představuje zdroje informací na počítači nebo v síti, jako např. v Internetu. Tato posloupnost znaků obsahuje (a) zkrácené jméno protokolu, který se používá k přístupu ke zdroji informací, a (b) informaci, kterou uvedený protokol použije k vyhledání zdroje informací. Například v prostředí Internetu se používají následující zkratky některých protokolů, které se používají k přístupu k různým zdrojům informací: http, ftp, gopher, telnet, news; a toto je například adresa URL domovské stránky firmy IBM: http://www.ibm.com. URI Viz uniform resource identifier (jednotný identifikátor zdroje). URL Viz uniform resource locator (jednotný lokátor zdroje, adresa URL). user (uživatel) Libovolná osoba, organizace, proces, zařízení, program, protokol nebo systém, který používá služby poskytované ostatními. user registry (registr uživatelů)
Viz registry (registr).
V virtual hosting (virtuální hostitelství) Schopnost webového serveru, která dovoluje, aby se tento objevil na Internetu jako více než jeden hostitel.
368
IBM Tivoli Access Manager: Base: Administrativní příručka
W Web Portal Manager (WPM, rozhraní WPM) Grafická aplikace založená na webu, která se používá ke správě bezpečnostní politiky produktů Tivoli Access Manager Base a WebSEAL v zabezpečené doméně. Alternativní prostředí k rozhraní příkazového řádku pdadmin. Toto grafické rozhraní umožňuje přístup vzdálenému administrátorovi a dovoluje administrátorům vytvářet domény delegovaných uživatelů a k těmto doménám přiřadit delegované administrátory. WebSEAL Proces blade produktu Tivoli Access Manager. Server WebSEAL je výkonný vícevláknový webový server, který aplikuje bezpečnostní politiku na prostor chráněných objektů. Server WebSEAL může poskytovat řešení pro jednotné přihlášení a zahrnout zdroje webových aplikačních serverů typu back-end do vlastní bezpečnostní politiky. WPM
ADI (pokračování) žádost ze správce zdrojů 113, 114 administrativa celopodniková doména 155 delegování rolí 157 role 157 superdoména 155 uživatelé a skupiny 123 více domén 156 administrativní politika ACL (předvolená) 43 administrativní práva nabytí 42 administrativní rozhraní API komponenta Tivoli Access Manager 4 administrativní skupiny 159 administrátor superdoména 155 úlohy 157 více domén 156 Administrátor bezpečnostní politiky 42 administrátor domény 123 administrátor domény sec_master 33 Administrátor chráněného zdroje 42 Administrátor nasazování 42 administrátor politiky ACL 41 administrátoři administrátor 156 celopodniková doména 155 doména 156 pokročilý 156 Policy Director 156 pomocný 157 předdefinovaní 156 sec_master 155 typy 156 vytvoření 41 administrátoři a skupiny předvolby 41 agent protokolu konzole 204 agent protokolu propojení procesů 209 agent protokolu souboru 205 agenti protokolů 197 agenti, protokol 197 akce 73 přizpůsobení 82 přizpůsobení, příklad 83 správa oprávnění Action 46 zadání do záznamů ACL 83 akce administrativa serveru 74 akce číst 73 akce delegovat 73 akce heslo 74 akce procházet 73 akce provést 74 akce přejít 74 akce přidat 73 akce řídit 73 akce trasovat 74 akce upravit 73 akce vymazat 73 akce vynechat POP 73
369
akce vypsat adresář 73 akce vytvořit 73 akce zobrazit 74 aktivace monitorování 227 role 158 algoritmus, autorizace založená na síti 94 any-other atribut typu 72 aplikační akce číst (r) 73 provést (x) 74 vypsat adresář (l) 73 atribut azn_cred_principal_name 111 atribut azn_cred_registry_id 111 atribut azn_engine_requested_actions 100 atribut azn_engine_target_resource 100 atribut azn_init_set_perminfo_attrs 113 atribut azn_perminfo_reason_rule_failed 114 atribut azn_perminfo_rules_adi_request 113, 115 atribut typu any-authenticated Viz any-other atributy atribut azn_engine_requested_actions 100 azn_cred_groups 111 azn_cred_principal_name 111 azn_cred_registry_id 111 azn_engine_target_resource 100 azn_init_set_perminfo_attrs 113 azn_perminfo_reason_rule_failed 114 azn_perminfo_rules_adi_request 113, 115 POP 85 typy záznamů ACL 72 atributy autorizační API 99 atributy POP denní doba přístupu 92 režim varování 91 úroveň auditu 92 atributy typu 72 autentizace komponenta Tivoli Access Manager 2 konfigurace úrovní pro zvýšení 95 použití zvýšené politiky 96 vícefaktorová autentizace 96 záznamy auditu 223 autentizované požadavky 36 autentizovaný autentizované požadavky 36 neautentizované požadavky 37 auto-database-update-notify 146 automatická obnova certifikátu a hesla 135 autorizace komponenta Tivoli Access Manager 2 proces krok-za-krokem 12 proces vyhodnocování 17 záznamy auditu 222 autorizace založená na síti algoritmus 94 omezení 95 zablokování pro POP 94 autorizace založená na síti prostřednictvím adresy IP autorizační API režim lokální paměti cache 15 režim vzdálené paměti cache 14 standard 5 úvod 12
370
autorizační databáze replikace 145 autorizační pravidla 10, 12 Formát a omezení 108 kdy používat 38 lišící se od politik ACL a POP 38 oddělovače 108 odpojení 121 oprávnění pro správu pravidel 51 politiky 37 politiky pro 57 program pro vyhodnocování 107 přehled 99 příklady 110 připojení k objektu 120 správa 99, 117 vyhledat 120 vymazání 118 výpis 118 vytvoření 117 změna 119 autorizační server démon pdacld 139 ochrana před automatickým spuštěním autorizační služba 6 autorizační API 9 přehled 8 rozhraní 9 rozšíření 16 Tivoli Access Manager 7 výhody 7 azn_cred_groups attribute 111
145
B Base produktu Tivoli Access Manager vymáhání atributů POP 56 bezpečnostní politika 34 definice 42 implementace 10 předvolená 41 přehled 4 buffer_size 211
C CA Viz vydavatel certifikátů celopodniková doména 155 centralizovaná správa 3 certifikáty automatická obnova 135 nástroje pro aktualizaci 135 stornování 136 úlohy správy 133 výchozí konfigurace 134 certifikáty PDCA Viz certifikáty 94
IBM Tivoli Access Manager: Base: Administrativní příručka
Č časový limit opakování 212 časový limit opakování při chybě 212 časový limit opakování při opětovném propojení 212 časový limit, opakování při opětovném propojení 212
četnost zarovnávání slučovací vyrovnávací paměť 211 vyrovnávací paměti souboru protokolu 204, 208, 210 vyrovnávací paměti souboru prověřovacích záznamů 229
D databáze cesta pro registr uživatelů 153 databáze politik 8 databáze politik autorizace 8 děděné ACL 52, 55 definice bezpečnostní politika 42 Definice typu dokumentu Viz DTD delegovaná administrativa administrátoři a skupiny 41 objekty typu zásobník pro skupinu 160 oprávnění ACL pro skupiny 164 správa politiky 166 správa prostoru objektů 158 správa uživatelů 165 delegovaná správa administrátoři a skupiny 159 správa skupin 160 delegování rolí administrativa 157 delegování správy 158, 160 delegovaný administrátor, zobrazení 156 doba prodlevy oznámení o aktualizaci 147 doména administrátor (sec_master) 33 administrátoři 156 celopodniková 155 poddoména, popis 155 superdoména 155 úprava 61 více 156 vymazání 60 výpis 60 vytvoření 59 doména správy 31 domény definice 31 oprávnění pro správu domén 51 DTD formát monitorovaných událostí 179 dynamic-adi-entitlement-services 115 dynamická ADI 101
fatální zprávy souborů protokolu 170 formát, autorizační pravidla 108 formáty monitorované událostí 179 fronta propagace 218 fronta protokolování, monitorování 218 fronta v paměti 203 funkce count() 113 funkce sum() 113
G generické akce administrativa serveru (s) 74 upravit (m) 73 vymazat (d) 73 zobrazit (v) 74 Global Sign-On Viz GSO GSO správa oprávnění GSO 50
H HACMP 149 pokyny pro klastry 149 hesla automatická obnova 135 úlohy správy 133 heslo odstraňování problémů 157 změna 128 hlavní databáze politik autorizace 8 hledání autorizačních pravidel 120 hodnota časového limitu opakování 212 hodnota časového limitu, opakování při chybě 212 hodnoty preference (přepnutí při selhání LDAP) 343 horní hranice 211 horní hranice fronty 203, 207, 210 horní hranice fronty událostí 203, 207, 210 hranice, fronta událostí 203, 207, 210
CH chráněné objekty 76 úlohy správy 67 chybové zprávy souborů protokolu
170
I
E explicitní ACL 52 explicitní politika 11 eXtensible Markup Language Viz XML eXtensible Stylesheet Language Viz XSL externí autorizační služba implementace 19 nasazení 19 úvod 16 externí autorizační služba (EAS)
F
37
IBM Directory 341 IBM Tivoli Access Manager komponenta WebSEAL 1 IBM Tivoli Access Manager for Business Integration 1 IBM Tivoli Access Manager for Operating Systems 1 ID souborů protokolu 205 identifikátory řetězce 108 informace o kontextu aplikace 100 autorizační jádro 100 informace o kontextu aplikace 100 informace o rozhodnutí o připojení Viz ADI inicializační atributy 115 Rejstřík
371
inicializační atributy (pokračování) dynamic-adi-entitlement-services 115 input-adi-xml-prolog 116 resource-manager-provided-adi 115 xsl-stylesheet-prolog 116 inicializační parametr azn_init_set_perminfo_attrs 114 integrita dat 149 integrita nebo nadbytek dat 149 IP adresy nastavení pro POP 93 zablokování autorizace založené na síti pro politiky POP iPlanet Viz Sun ONE
J Jazyk autorizačních pravidel jazyky 101 jména zásobníků omezení pro 103 pro zásobníky ADI 103 jméno atributu, XML 104 jméno kategorie EventPool 203
LDAP konfigurace 289 konfigurace přepnutí při selhání konfigurační soubor 280 ldap.conf 342 logaudit 227
341
M K kategorie protokolovaných událostí 197 kategorie společných oblastí událostí 200 kategorie událostí 178, 197 klíčové technologie 2 kód příčiny selhání pravidla 114 kódy akcí autentizační událost 182 autorizační událost 182 příkazy správy 182, 190 událost WebSEAL 182 událost změny hesla 182 kódy příčiny selhání pravidla 114 komentované zprávy souborů protokolu 170 konfigurace agent protokolu konzole 204, 205 agent protokolu propojení procesů 209 centrální fronta propagace událostí 203 certifikáty 134 četnost zarovnávání vyrovnávacích pamětí souboru protokolu 204, 208, 210 četnost zarovnávání vyrovnávacích pamětí souboru prověřovacích záznamů 229 frekvence pro zarovnání slučovací vyrovnávací paměti 211 horní hranice 210 horní hranice fronty událostí 203 inicializační atributy 115 kategorie společných oblastí událostí 200 maximální počet událostí pro zařazení do fronty 203 příkaz bassslcfg –config 137 režim souboru 209 soubory serveru 144 správa oprávnění Config 47 události monitorovacího příznaku 227 umístění programu získávajícího výstup protokolu 209 úrovní pro zvýšenou autentizaci 95 vzdálený agent protokolu 210 konfigurace přepnutí při selhání 341 konfigurační soubory ldap.conf 289
372
IBM Tivoli Access Manager: Base: Administrativní příručka
mapování, pdadmin CLI do WPM 331 max-notifier-threads 146 maximální počet událostí pro zařazení do fronty 207, 209 model autorizace 5 koncepční model 5 model dokumentu pro ADI 102 model, dokument 102 monitorovací příznak 227 monitorovaná událost, definice 227 monitorované událostí agenti protokolů 197 kategorie událostí 197 konfigurace agenta protokolu konzole 204 konfigurace agentů protokolů propojení procesů 209 konfigurace společné oblasti událostí 200 konfigurace vzdáleného agenta protokolu 210 konfigurační soubor agenta protokolu 205 zachycení 197 monitorování aktivace a zakázání 227 přehled 169 úvod 221 monitorování auditu 227 MQSeries 1 msg__error.log 170 msg__fatal.log 170 msg__notice.log 170 msg__verbose 170 msg__warning 170
N nadbytek dat 149 nároky nároky uživatele 100 služby nároků na vyvolání 101 nároky pověření 100 nástroje pro ruční aktualizaci certifikátu 135 neautentizované požadavky 37 neautentizovaný uživatel (unauthenticated) 35 notifier-wait-time 146
O object create 65 objectspace create 64 objectspace delete 66 objectspace list 66 objekt vytvoření 64 objekty vymazání 68 výpis 68 vytvoření 67 objekty typu prostředek 32 objekty typu zásobník 32, 160 objekty typu zásobník pro skupinu vytvoření 160 oblast správy oprávnění 45 obnova, certifikáty a hesla 135 obnovy, soubory klíčů a soubory pro uložení 135 obsah, soubor prověřovacích záznamů 222 obslužný program pdadmin komponenta Tivoli Access Manager 4 oddělovače, program pro vyhodnocování autorizačních pravidel odpojení autorizačních pravidel 121 odpovědnosti Administrátor bezpečnostní politiky 42 Administrátor chráněného zdroje 42 Administrátor nasazování 42 odstranění přístupu pro identifikátory 94 ochrana před automatickým spuštěním autorizační server 145 proxy server 145 server politik 145 ochranné známky 361 omezení, autorizace založená na síti 95 omezení, autorizační pravidla 108 omezení, jména zásobníků 103 omezení, model dokumentu XML pro ADI 103 opětovné spuštění serverů 143 oprávnění 73 administrátoři 41 objekt 79 oprávnění /Management/ACL 45 oprávnění /management/Action 46 oprávnění /Management/Config 47 oprávnění /Management/Domain 51 oprávnění /Management/Groups 50 oprávnění /Management/GSO 50 oprávnění /Management/Policy 48 oprávnění /Management/POP 46 oprávnění /Management/Proxy 52 oprávnění /Management/Replica 48 oprávnění /Management/Rule 51 oprávnění /Management/Server 47 oprávnění /Management/Users 48 prostor objektů 79 přejít (T) 53, 79 přizpůsobení 82 role 157 řídit (c) 53 sec_master 41 skupina iv-admin 41 oprávnění Management/ACL 45 oprávnění management/Action 46 oprávnění Management/Config 47 oprávnění Management/Domain 51 oprávnění Management/Groups 50
oprávnění Management/GSO 50 oprávnění Management/Policy 48 oprávnění Management/POP 46 oprávnění Management/Proxy 52 oprávnění Management/Replica 48 oprávnění Management/Rule 51 oprávnění Management/Server 47 oprávnění Management/Users 48 oprávnění objektu 79 oprávnění pro přechod 53, 79 oprávnění pro řízení 53 oprávnění prostoru objektů 79 ostatní autentizované požadavky 36 neautentizované požadavky 37 ostatní uživatel (any-other) 35
pdadmin server replikace 146 pdadmin server replicate 146 pdmgrd 139 soubory klíčů a soubory pro uložení 135 pdmgrproxyd 139 soubory klíčů a soubory pro uložení 135 PDRTE 135 poddoména 155 podpora hodnoty příznaku 100 pokyny obnova souborů klíčů a souborů pro uložení 137 pro zabezpečení prostoru objektů 38 pole, výstup XML 179 Policy Director administrátoři 156 politika chráněného objektu Viz POP politika POP autorizace založená na síti 93 úroveň zabezpečení 97 politiky ACL 42 autorizační pravidla 37, 57 POP 37 správa oprávnění policy 48 politiky ACL dědičnost 55 explicitní 55 Politiky ACL 42 politiky ACL, definice 10 politiky chráněného objektu Viz POP politiky POP, definice 10 POP aplikovat na objekty 90 atributy 56 definice 11, 34 hledání, kde je připojená 90 konfigurace atributů 91 odpojení od objektu 91 politiky 37 připojení k objektu 90 správa oprávnění POP 46 určení IP adres nebo rozsahů 93 úvod 85 versus autorizační pravidla 38 vymazání 88 výpis 88 vytvoření 86 zablokování autorizace založené na síti prostřednictvím adresy IP 94 změna 89 zobrazení 89 port, vzdálený server 212 použití úrovní pro zvýšenou autentizaci 96 použití politik ACL 55 povolený podřetězec registru 153 požadavky na zdroje 17 prahové hodnoty obnovy 229 pravidla autorizace definice 34 právní informace ochranné známky 361 upozornění 359 proces vyhodnocování, autorizace 17
374
IBM Tivoli Access Manager: Base: Administrativní příručka
procesy blade 33 produkty IBM IBM Tivoli Access Manager 1 IBM Tivoli Access Manager for Business Integration 1 IBM Tivoli Access Manager pro Operating Systems 1 IBM Tivoli Access Manager WebSEAL 1 program pro vyhodnocování rozhodnutí o autorizaci přehled 8 program pro vyhodnocování, autorizační pravidla 107 prokazatelnost přístupu 3 prostor chráněných objektů 32 pokyny 38 prostor objektů definice 32 delegování správy 158 typy 64 úlohy správy 63 vymazání 66 výpis 65 vytvoření 63 protokolované události agenti protokolů 197 kategorie událostí 197 konfigurace agenta protokolu konzole 204 konfigurace agentů protokolů propojení procesů 209 konfigurace společné oblasti událostí 200 konfigurace vzdáleného agenta protokolu 210 konfigurační soubor agenta protokolu 205 zachycení 197 protokolování do souboru 205 do souboru přes propojení procesů 209 do vzdáleného protokolu 210 na konzoli 204 přehled 169 protokolování do souboru 205 protokolování na konzoli 204 protokolování událostí, konzole stderr 204 stdout 204 protokolování událostí, propojení procesů flush_interval 210 hi_water 210 path 209 protokolování událostí, soubor protokolů buffer_size 206 flush_interval 208 horní hranice fronty událostí 207 log_id 205 path 205 queue_size 207 režim souboru 209 rollover_size 206 protokolování událostí, vzdálené časový limit opakování při chybě 212 dn 213 komprimovat vyrovnávací paměti zpráv 211 path 212 port 212 rebind 212 server 212 protokolování událostí, vzdnálené 211 flush_interval 211 hi_water 211 prověřovací záznam, definice 227 proxy server démon pdmgrproxyd 139
proxy server (pokračování) ochrana před automatickým spuštěním 145 úvod 140 proxy servery oprávnění pro správu proxy serverů 52 předvolená ACL pro doménu 44 ACL pro proxy server 44 administrativní politika ACL 43 bezpečnostní politika 41 kořenová politika ACL 43, 53 politika ACL pro GSO 44 politika ACL pro konfiguraci 44 politika ACL pro politiky 44 politika ACL pro replikaci 44 politika ACL pro správu 44 předvolená ACL pro proxy server 44 předvolení administrátoři a skupiny 159 přechod 79 přepnutí při selhání LDAP hodnoty preference 343 příkaz action group příkaz create 81 příkaz delete 82 příkaz list 81 příkaz attach 120 příkaz authzrule attach 120 příkaz authzrule delete 119 příkaz authzrule detach 121 příkaz authzrule find 121 příkaz authzrule list 118 příkaz authzrule modify 119 příkaz auto-database-update-notify 145 příkaz bassslcfg –config 137 příkaz boot-start-ivacld 145 příkaz boot-start-ivmgrd 145 příkaz boot-start-pdmgrproxyd 145 příkaz create 118 příkaz delete 119 příkaz detach 121 příkaz find 121 příkaz group list 166 příkaz group list-dn 166 příkaz list 118 příkaz modify 119 příkaz notifier-wait-time 147 příkaz object create 67 příkaz object delete 69 příkaz object list 68 příkaz pdadmin action create 82 příkaz pdadmin action group create 81 příkaz pdadmin action group delete 82 příkaz pdadmin action group list 81 příkaz pdadmin errtext 181 příkaz pdadmin group create 163 příkaz pdadmin object create 67, 161 příkaz pdadmin pop attach 90 příkaz pdadmin pop create 88 příkaz pdadmin pop delete 89 příkaz pdadmin pop detach 91 příkaz pdadmin pop find 91 příkaz pdadmin pop list 88 příkaz pdadmin pop modify 89 příkaz pdadmin pop show 89 příkaz pdadmin server replicate 146 příkaz pdadmin server task 218
příkaz pdadmin stats get 218 příkaz pdadmin stats list 218 příkaz pop attach 90 příkaz pop create 88 příkaz pop delete 89 příkaz pop detach 91 příkaz pop find 91 příkaz pop list 88 příkaz pop modify 89 příkaz pop show 89 příkaz server task 218 příkaz stats get 218 příkaz stats list 218 příkaz svrsslcfg -chgpwd 136 příkaz svrsslcfg -unconfig 136 příkaz user list 166 příkaz user list-dn 166 příkaz user show groups 166 příkazy authzrule attach 120 authzrule delete 119 authzrule detach 121 authzrule find 121 authzrule list 118 authzrule modify 119 bassslcfg –config 137 group list 166 group list-dn 166 pdadmin acl attach 77 pdadmin acl create 75 pdadmin acl delete 75 pdadmin acl detach 78 pdadmin acl find 77 pdadmin acl list 75 pdadmin acl modify 76 pdadmin acl show 76 pdadmin action create 82 pdadmin action group create 81 pdadmin action group delete 82 pdadmin action group list 81 pdadmin domain delete 61 pdadmin domain list 60 pdadmin domain modify 62 pdadmin errtext 181 pdadmin group create 130 pdadmin group import 130 pdadmin object create 65, 67 pdadmin object delete 69 pdadmin object list 68 pdadmin objectspace create 64 pdadmin objectspace delete 66 pdadmin objectspace list 66 pdadmin pop attach 90 pdadmin pop create 88 pdadmin pop delete 89 pdadmin pop detach 91 pdadmin pop find 91 pdadmin pop list 88 pdadmin pop modify 89 pdadmin pop show 89 pdadmin server replicate 146 pdadmin server task 218 pdadmin user create 124, 125, 126, 128 pdadmin user list 129 pdadmin user modify password 128 pro POP 85 příkaz pdadmin group create 163 Rejstřík
375
příkazy (pokračování) příkaz pdadmin object create 161 stats get 218 stats list 218 svrsslcfg -chgcert 136 svrsslcfg -chgpwd 136 svrsslcfg -unconfig 136 user list 166 user list-dn 166 user show groups 166 vytvoření authzrule 118 vytvoření domény pdadmin 60 příkazy ACL příkaz attach 77 příkaz create 75 příkaz delete 75 příkaz detach 78 příkaz find 77 příkaz list 75 příkaz modify 76 příkaz show 76 příkazy action příkaz create 82 příkazy authzrule 117 příkaz attach 120 příkaz create 118 příkaz delete 119 příkaz detach 121 příkaz find 121 příkaz list 118 příkaz modify 119 příkazy domén příkaz create 60 příkaz delete 61 příkaz list 60 příkaz modify 62 příkazy group příkaz create 130 příkaz import 130 vytvořit 163 příkazy object delete 69 uvedení typů 68 vypsat 68 vytvořit 65, 67, 161 příkazy objectspace delete 66 vypsat 66 vytvořit 64 příkazy POP delete 89 odpojit 91 připojit 90 upravit 89 vyhledat 91 vypsat 88 vytvořit 88 zobrazit 89 příkazy prologu 116 příkazy správy 190 příkazy user příkaz create 124, 125, 126, 128 příkaz list 129 příkaz modify password 128 příklad nároku, XML 105 příklady externí autorizační služba 17
376
IBM Tivoli Access Manager: Base: Administrativní příručka
příklady (pokračování) přizpůsobené akce 83 určení IP adres a rozsahů v POP 94 příklady, autorizační pravidla 110 připojení seznamů ACL k objektům 76 připojení autorizačního pravidla 120 přístupové seznamy Viz ACL přístupový seznam Viz ACL přístupový seznam (ACL - Access Control List) odpojení od objektu 77 vyhledat 77 přizpůsobené akce 83
R registr uživatelů konfigurační soubor LDAP 280, 289 maximální hodnoty 328, 329 rozdíly 327 registr uživatelů IBM Directory Viz server LDAP replicate pdadmin server 146 replika 342 replikace 9 replikace autorizační databáze 145 repliky správa oprávnění pro replikaci 48 režim lokální paměti cache 13, 15 režim vzdálené paměti cache 13, 14 režimy lokální paměť cache autorizačního rozhraní API 15 textové nebo binární soubory 209 vzdálená paměť cache autorizačního rozhraní API 14 role aktivace role 157, 158 definovat 157 delegování 157 oprávnění 157 přiřazení přiřazení role 158 přiřazení role 157 vytvoření role 157 rozhraní správy 9 rozlišovací jméno, vzdálený server 213
Ř řídký model ACL
52
S sdílená disková pole 149 sec_master 155 server politik Viz též pdmgrd démon pdmgrd 139 ochrana před automatickým spuštěním server politik s více klienty 153 server replicate 146 servery automatické spouštění 145 autorizační server 143, 149 jméno hostitele pro vzdálený 212 klastr HACMP 149
145
servery (pokračování) konfigurační soubory 144 opětovné spuštění pomocí obslužného programu pd_start 143 port vzdáleného 212 primární a pomocný 149 proxy server politik 142 rozlišovací jméno pro vzdálený 213 server politik 142 správa 139 správa oprávnění serveru 47 správce zdrojů 134 spuštění a zastavení pro OS UNIX 142 spuštění a zastavení pro OS Windows 143 spuštění pomocí obslužného programu pd_start 142 spuštění pomocí Ovládacího panelu Služby na OS Windows 143 spuštění ručně ve správném pořadí 142 zachycování monitorovaných událostí 227 zastavení pomocí obslužného programu pd_start 143 závislosti 141 servery správců zdrojů 134 seznam atributů app_context 100 seznam atributů app_context 100 seznam atributů permission_info 114 seznamy atributů permission_info-returned 114 skupina hledání 128 import 130 iv-admin 34 výpis 128 vytvoření 129 skupina akcí pokyny 80 vymazání 81 výpis 81 vytvoření 80 vytvoření nové akce ve skupině akcí 82 skupina iv-admin 34, 41 skupina ivmgrd-servers 41 skupiny atribut typu 72 definice 123 delegování správy 160 iv-admin 33 ivmgrd-servers 41 skupina iv-admin 41 správa oprávnění pro skupiny 50 vytvoření 163 slučovací vyrovnávací paměť 211 služba nároků na vyvolání 100, 101 služby nároků načtení 115 služby nároků načtení dynamické ADI 115 soubor audit.log 228 soubor klíčů ivmgrd.kdb 135 soubor klíčů pd.kdb 135 soubor klíčů pdmgrproxyd.kdb 135 soubor pro uložení hesla ivacld.sth 135 soubor pro uložení hesla ivmgrd.sth 135 soubor pro uložení hesla pd.sth 135 soubor pro uložení pdmgrproxyd.sth 135 soubory audit.log 228 soubory klíčů definice 133 ivacld.kdb 135 ivmgrd.kdb 135
soubory klíčů (pokračování) pd.kdb 135 pdmgrproxyd.kdb 135 soubory klíčů ivacld.kdb 135 soubory pro uložení definice 134 ivacld.sth 135 ivmgrd.sth 135 pd.sth 135 pdmgrproxyd.sth 135 soubory protokolu hi_water 211 identifikátor (ID) 205 maximální počet událostí pro zařazení do fronty 207, 209 maximální velikost cyklické obnovy 206 maximální velikost vyrovnávací paměti 206, 211 msg__error.log 170 msg__fatal.log 170 msg__notice.log 170 msg__verbose 170 msg__warning 170 umístění 205 určení prahových hodnot obnovy 229 určení umístění 228 velikost front 211 soubory prověřovacích záznamů 229 formát 179 obsah 222 zarovnávání vyrovnávacích pamětí 229 související publikace xv správa autorizační pravidla 99 certifikáty 133 hesla 133 objekty 67 oprávnění ACL 45 oprávnění Action 46 oprávnění Config 47 oprávnění GSO 50 oprávnění policy 48 oprávnění POP 46 oprávnění pro domény 51 oprávnění pro proxy servery 52 oprávnění pro replikaci 48 oprávnění pro skupiny 50 oprávnění pro uživatele 48 oprávnění rule 51 oprávnění serveru 47 politika delegované administrativy 166 prostor objektů 63 servery 139 záznamy auditu 225 správa skupin 164 správa uživatelů 165 správce zdrojů 6 vymáhání atributů POP 57 žádající ADI 113 spuštění serverů pomocí obslužného programu pd_start 142 pomocí Ovládacího panelu Služby na OS Windows 143 ručně ve správném pořadí 142 UNIX 142 Windows 143 standardní chybový výstup (stderr) protokolování 204 standardní výstup (stdout) protokolování 204 stanza authentication-mechanisms 244 stanza aznapi-configuration 249 Rejstřík
Tivoli Access Manager (pokračování) škálovatelnost 3 úroveň zabezpečení 2 úvod do 1 Web Portal Manager 4 zastavení serverů pomocí obslužného programu pd_start 143 zastavení serverů pomocí Ovládacího panelu Služby na OS Windows 143 typy objekty 65, 68 obslužné programy produktu Tivoli Access Manager 142 prostor objektů 64 serverů produktu Tivoli Access Manager 139 typy objektů 65, 162
U
143
Š škálovatelnost
3, 9
T Tivoli Access Manager administrativní rozhraní API 4 autentizace 2 autorizace 2 autorizační API 12 autorizační služba 7, 8 bezpečnostní politika 157 centralizovaná správa 3 klíčové technologie 2 obslužné programy 142 obslužný program pdadmin s rozhraním příkazového řádku 4 opětovné spuštění serverů pomocí obslužného programu pd_start 143 prokazatelnost přístupu 3 soubory prověřovacích záznamů 227 spuštění serverů pomocí obslužného programu pd_start 142 spuštění serverů pomocí Ovládacího panelu Služby na OS Windows 143 spuštění serverů ručně ve správném pořadí 142
378
IBM Tivoli Access Manager: Base: Administrativní příručka
události kódu akcí 182 události trasování 178 udělit přístup identifikátorům 94 úlohy administrativa rolí 157 aktivace role 157, 158 přiřazení role 157, 158 role 157 typy 157 vytvoření role 157 úlohy správy autorizační pravidla 117 umístění programu získávajícího výstup protokolu 209 soubor protokolu 228 souboru paměti cache 212 soubory protokolu 205 umístění souboru paměti cache 212 unauthenticated atribut typu 72 UNIXové servery spuštění a zastavení 142 upozornění 359 upozorňující zprávy souborů protokolu 170 úroveň zabezpečení 2 úrovně zvýšené autentizace 95 uživatel hledání 123 import 125 nároky pověření 100 sec_master 34 vytvoření 124 uživatel sec_master 34, 41 uživatelé administrátor 33 administrátor, administrátor 156 administrátor, doména 156 administrátor, pokročilý 156 administrátor, Policy Director 156 administrátor, pomocný 157 administrátor, sec_master 155 atribut typu 72 definice 123 delegování 157 sec_master 41 správa oprávnění pro uživatele 48
V varovné zprávy souboru protokolu 170 velikost souborů protokolu 206 velikost vyrovnávací paměti souborů protokolu 206, 211 více domén 156 příklad 156 zobrazení 156 vícefaktorová autentizace 96 vlákna oznámení o aktualizaci 147 volání azn_decision_access_allowed() 113 volání azn_decision_access_allowed_ext () 100 volání azn_decision_access_allowed_ext() 113, 114 volání azn_entitlement_get_entitlements() 108, 115 volba config příkazu bassslcfg 137 volba chgcert příkazu svrsslcfg 136 volba chgpwd příkazu svrsslcfg 136 volba set ipauth add 93, 94 volba set ipauth forbidden 94 volba set ipauth remove 94 vydavatel certifikátů Viz též CA definice 133 určení důvěry 136 vyhodnocování ACL 36 výhody autorizační služby 7 výkonnost 218 vymahač politiky 6 vymáhání atributů POP komponentou Tivoli Access Manager Base 56 správcem zdrojů 57 vymazání ACL 75 objekty 69 prostor objektů 66 skupina akcí 81 vymazání autorizačního pravidla 118 výpis ACL 75 objekty 68 prostor objektů 65 skupina akcí 81 vypsání autorizačních pravidel 118 vyrovnávací paměť souborů auditu 229 vyrovnávací paměti komprimace zpráv 211 zarovnávání slučovací vyrovnávací paměti 211 zarovnávání vyrovnávacích pamětí souboru protokolu 204, 208, 210 zarovnávání vyrovnávacích pamětí souboru prověřovacích záznamů 229 vyrovnávací paměti souboru protokolu 204, 208, 210 vyřešení požadavku ACL 54 výstup protokolu 209 výstupní pole 179 výstupní pole accessor 183 výstupní pole action 182 výstupní pole attribute 187 výstupní pole audit 190 výstupní pole azn 185 výstupní pole component 182 výstupní pole data 189 výstupní pole date 180 výstupní pole descr 187 výstupní pole egid 186 výstupní pole eid 186 výstupní pole event 180 výstupní pole gid 186
výstupní pole location 183 výstupní pole name 186, 188 výstupní pole object 184 výstupní pole originator 181 výstupní pole outcome 181 výstupní pole perm 185 výstupní pole pid 186 výstupní pole policy 186 výstupní pole principal 183 výstupní pole process 186 výstupní pole qualifier 185 výstupní pole result 185 výstupní pole source 188 výstupní pole target 184 výstupní pole type 187, 189 výstupní pole uid 186 výstupní pole value 189 vytvoření ACL 74 autorizační pravidlo 117 nová akce ve skupině akcí 82 objekt 64 objekty 67 objekty typu zásobník pro skupinu 160 POP 86 prostor objektů 63 role 157 skupina akcí 80 vytvořit příkaz authzrule 118 vzdálený agent protokolu 210 vzdálený server časový limit opakování při opětovném propojení 212 jméno hostitele 212 nominace hostitelů 212 odesílání událostí na 210 port 212 rozlišovací jméno 213 slučování do velkých vyrovnávacích pamětí 211 umístění souboru paměti cache 212 velikost vyrovnávací paměti před předáním 211
W Web Portal Manager komponenta Tivoli Access Manager WebSEAL 1 Windows spuštění a zastavení serverů 143
4
X XML atributy páru jméno/hodnota ADI 104 autorizační pravidla 101 model dokumentu ADI 102 monitorování výstupních polí 179 omezení modelu dokumentu ADI 103 příkazy prologu 116 příklad dokumentu nároku 105 zásobníky ADI a jména zásobníků 103 XSL autorizační pravidla 101 příkaz xsl:when 111 příkazy prologu 116 xsl:template statement 110 xsl:template statement 110 Rejstřík
379
xsl:when statement
111
Z zabezpečení politika 157 zablokování autorizací založených na síti pro politiky POP 94 zachycování monitorovaných událostí 227 zakázání monitorování 227 zakázaný přístup identifikátorům 94 základní akce delegovat (g) 73 heslo (W) 74 procházet (b) 73 přejít (T) 74 přidat (A) 73 řídit (c) 73 trasovat (t) 74 vynechat POP (B) 73 vytvořit (N) 73 zarovnávání slučovací vyrovnávací paměť 211 vyrovnávací paměť souborů auditu 229 vyrovnávací paměti souboru protokolu 204, 208, 210 zásobníky pro ADI 103 zastavení serverů pomocí obslužného programu pd_start 143 pomocí Ovládacího panelu Služby na OS Windows 143 UNIX 142 Windows 143 závislosti server 141 záznam objektu stanza max-notifier-threads 147 záznamy auditu autentizace 223 autorizace 222 správa 225 zděděná politika 11 zdroje pro ADI 101 změna ACL 76 certifikáty 136 heslo 136 změna autorizačního pravidla 119 Zpracování více klastrů vysoké dostupnosti Viz HACMP zprávy komprimace vyrovnávacích pamětí 211 zprávy obslužnosti 169 zprávy, obslužnost 169 zvýšená autentizace konfigurace 95 použití 96 versus vícefaktorová autentizace 96
380
IBM Tivoli Access Manager: Base: Administrativní příručka
