LPS:WebAuth/Cluster WebKDC serverů
Cluster WebKDC serverů
Při úspěšném zavední systému WebAuth do provozu, je nutné zajistit, aby celý systém byl odolný proti výpadkům. Tím je samozřejmě míněno hlavně zajištění odolnosti proti výpadku login-serveru WebKDC, které je srdcem celého systému. Logickým krokem je zavedení více login-serverů. Samozřejmě je možné zprovoznit několik login-serverů a nechat různé aplikace ověřovat se proti různým WebKDC serverům. Tím ovšem ztratíme hlavní požadovanou funkčnost, kterou je Single Sign-On. Je tedy nutné zajistit chování celého systému tak, aby bylo více login-serverů zprovozněných a nakonfigurovaných tak, že navenek vystupují jako server jediný (resp. cluster těchto serverů) a je zcela jedno, ke kterému uživatel aktuálně přistupuje.
Několik serverů je možné nakonfigurovat tak, že v DNS (Domain Name Services) mají shodné jméno -- např. webkdc.zcu.cz -- a rozhodnutí, ke kterému z nich bude přistupující uživatel připojen je ponecháno na technologii DNS round-robin. Ta ovšem nedokáže zajistit, aby nebyl nabízen server, který je nedostupný například z důvodu hardwarové poruchy. Tedy při zapojení dvou login-serverů nebude obsloužena polovina dotazů. Z tohoto pohledu je technologie round-robin nedostačující a je nutné nalézt sofitikovanější přístup, který stírá popsané nedostatky.
Jako vhodné řešení se jeví upravený DNS sever, který kromě vyřízení standardního DNS požadavku umí provádět i load-balancing mezi několika servery. Tento požadavek splnujě například softwarový produkt lbnamed (viz http://www.math.utah.edu/~pocock/lbnamed.html) napsaný v programovacím jazyce Perl. Součástí tohoto řešení je kromě samotného DNS serveru také část poller, který perodicky (např. 2x za minutu) kontaktuje "svěřené" servery a zjišťuje dostupnost těchto serverů, tak i jejich aktuální vytížení (load serveru, počet připojených uživatelů). Aby bylo možné tyto informace získat, je nutné, aby na serverech běžel load-balancigový client daemon -- lbcd, který obsluhuje UDP požadavky poller-u. Informace, které poller získá, jsou použité pro zpřesnění nabídky jednotlivých serverů. Pokud je některý ze serverů nedostupný, přestane být jeho IP adresa nabízena jako relevantí záznam pro DNS dotaz. Pokud je některý se serverů více vytížen, je nabízení jeho IP adresy znevýhodněno oproti ostatním serverům v clusteru.
DNS odpovědi zasílané programem lbnamed mají standardně dobu životnosti TTL (Time to Live) nastaven na hodnotu 0. Tímto je zajištěno, že odpověd nebude uložena do žádné DNS cache. Uživatel tedy vždy obdrží IP adresu login-serveru, který je v současné době nejvhodnější pro zpracování jeho požadavku.
Samozřejmě není nutné převádět všechny DNS servery na tento produkt. Nejvhodnější je nadefinovat si virtuální DNS zónu -- např. lb.zcu.cz -- jejíž provoz bude zajištěn jedním nebo více DNS servery lbnamed. Do konfigurace DNS tedy přidáme záznamy, že na dotazy z domény "lb.zcu.cz" budou odpovídat DNS servery s load-balancingem lbdns1.zcu.cz a <adresa>lbdns2.zcu.cz</adresa>:
lb IN NS lbdns1.zcu.cz. lb IN NS lbdns2.zcu.cz.
Pokud se vám pak příliš nezamlouvá uvedení této subdomény ve jménu clusteru serveru, je možné zavést DNS alias například webkdc-pool.zcu.cz pro webkdc-pool.lb.zcu.cz.
webkdc-pool IN CNAME webkdc-pool.lb.zcu.cz.
Nyní již stačí jen nakonfigurovat seznam zdrojů pro load-balancingovaný cluster ověřovacích serverů v konfiguraci lbnamed:
Soubor sweet.config:
webkdc1 1 webkdc-pool webkdc2 1 webkdc-pool webkdc3 1 webkdc-pool
Synchronizace AES privátních klíčů služby WebKDC
Pro zajištění správné funkce SSO při použití více login-serverů je nutné zajistit distribuci shodných privátních klíčů mezi všechny WebKDC servery. Tímto klíčem WebKDC server kryptuje vydaný proxy-token zaslaný uživateli v podobě cookie. Proxy token obsahuje uživatelský krb lístek a je základním kamenem SSO, proto je nutné, aby všechny login-servery v clusteru byly schopny dekryptovat cookie zaslané uživatelem při opakovaném přístupu.
V případě jediného login-serveru je možné nadefinovat standardní dobu platnosti privátního AES klíče přímo v konfiguraci WebKDC serveru. O výměnu klíče se pak stará přímo modul mod_webkdc. Při použití clusteru login-serverů je nutné tuto funkkčnost zakázat, neboť každý WebKDC server by měnil svůj klíč nezávisle na ostaních login-serverech. Výměnu shodného klíče je tedy nutné zajistit "zvenčí" a do konfigurace všech serverů v clusteru dát direktivu zakazující automatický update privátního klíče:
WebKdcKeyringAutoUpdate off
Na obrázku je znázorněno řešení systému WebAuth odolné proti výpadku. V případě více DNS serverů s load-balancingem je vhodné (ne-li nutné), aby oba servery byly v počítačové síti připojeny v různých částech odlišnými síťovými aktivními prvky. Systém pak z velké části bude odolný i proti výpadku části sítě, hardwarové poruše jednoho z DNS serverů, apod. Load-balancigované DNS servery (lbdns1.zcu.cz a lbdns2.zcu.cz) si informace o dostupnosti sítě nevyměňují přímo mezi sebou, ale sbírají si je nezávisle na (ne)dostupnosti ostatních DNS serverů.
.
Naštestí vývojáři systému WebAuth s možností použití více WebKDC serverů počítají a součástí systému je i management privátních klíčů v podobě programu wa_keyring. Je tedy možné určit jeden ze serverů jako "hlavní" a na něm provádět výměnu privátního klíče například jedenkrát za měsíc přímo z crontabu. Původní klíč není možné vyměnit bez náhrady, ale měl by existovat překryv platnosti klíčů dlouhý alespoň tak, jako je standardní doba platnosti proxy-tokenu (resp. uživatelského krb lístku). Součástí wa_keyring-u je i garbage collector, který ze souboru s klíči zruší již neplatné klíče staré například více než 60 dní.
Následně je nutné klíč vygenerovaný na "hlavním" serveru vypropagovat bezpečnou cestou na všechny ostatní servery v clusteru. To je možné zajistit například pomocí programu secure-copy scp. Aby bylo možné klíče propagovat mezi servery bez nutnosti ručně zadávat přístupové heslo, je nutné pomocí ssh-keygen vygenerovat pár klíčů pro každou dvojici "hlavní server" -- "server podřízený" (resp. jakýkoliv jiný stroj z clusteru). Z "hlavního" serveru je pak nutné vzít public-key a zkopírovat jej na všechny další servery z clusteru. Postup je tedy následující:
- na <uv>hlavním</uv> serveru vygenerovat privátní a veřejný klíč pro SSH:
ssh-keygen -t dsa
- klíče nechat vygenerovat bez hesla např. do přednastaveného souboru /root/.ssh/id_dsa (id_dsa.pub respektive)
- veřejný klíč id_dsa.pub přidat(!) na všechny ostatní servery z clusteru do souboru /root/.ssh/authorized_keys
- ručně provést přihlášení uživatele root na všechny stroje, kam byl nakopírován veřejný klíč
- pak na "hlavním" serveru spouštět z crontabu pravidelně např. následující skript
#!/bin/sh # následující řádek zruší všechny klíče starší než 60 dní (garbage-collector) /usr/bin/wa_keyring -f /etc/webkdc/keyring gc -60d # vygenerujeme nový klíč s platností začínající za 2 dni /usr/bin/wa_keyring -f /etf/webkdc/keyring add 2d # skript mění práva keytabu :-( chmod www-data.root /etc/webkdc/keytab # rozkopírujeme soubor s klíči na všechny zbylé servery clusteru scp /etc/webkdc/keyring root@webkdc2.zcu.cz:/etc/webkdc/ scp /etc/webkdc/keyring root@webkdc3.zcu.cz:/etc/webkdc/ ## reload vsech apachu /etc/init.d/apache2 reload ssh root@webkdc-2.zcu.cz /etc/init.d/apache2 reload ssh root@webkdc-3.zcu.cz /etc/init.d/apache2 reload
