LPS:WebAuth
Popis systému
Single Sign-on (SSO) řešení WebAuth je založeno na autentizačním systému Kerberos. Celý systém WebAuth je pak tvořen třemi spolupracujícími moduly do WWW serveru Apache (moduly jsou psány pro verzi Apache 2.0.43 a vyšší): mod_webauth, mod_webauthldap a mod_webkdc.
Srdcem celého systému je login-server běžně nazývaný WebKDC (KDC je převzato z názvosloví systému Kerberos, kde KDC je zkratka pro Key Distribution Center -- centrum výdeje krb ticketů). Na WebKDC a pouze na něm běží jeden z výše uvedených modulů: mod_webkdc. Jeho úkolem je přejímat požadavky od aplikačních serverů, zpracovávat je a ověřovat identitu přistupujícího uživatele u autentizační autority.
Zbylé dva moduly mod_webauth a mod_webauthldap jsou umístěny na aplikačním serveru -- WWW serveru Apache, který poskytuje stránky chráněné systémem WebAuth. První z modulů zajišťuje ověření dosud neznámého uživatele přesměrováváním na WebKDC server a přejímá identitu uživatele z jím zaslaného cookie, do kterého si aplikační server dříve tuto identitu již ověřeného uživatele uložil. Je tedy možné říci, že zajišťuje autentizaci uživatele.
Druhý modul, mod_webauthldap, provádí autorizační službu. Pomocí něj je možné definovat seznam povolených skupin uživatelů, které jsou spravovány adresářovou službou LDAP. Modul mod_webauth musí být na aplikačním serveru vždy, pomocí něj je možné v konfiguračním souboru WWW serveru Apache povolit všechny ověřené uživatele nebo jejich jmenovitý výčet. Modul mod_webauthldap je pro aplikační server volitelný. Prostředí založené na webovém SSO řešení WebAuth může tedy vypadat například tak, jak je znázorněno na obrázku.
.
Prostředí SSO sytému WebAuth
Zpracování přístupu dosud neověřeného uživatele v SSO systému se účastní uživatel (resp. jeho WWW prohlížeč), aplikační server (webová aplikace), login-server (WebKDC) a autentizační autorita (např. Kerberos). Je nutné předeslat, že pro správnou funkci je vyžadované kryptované (https) spojení jak mezi uživatelem a aplikačním serverem, tak i mezi uživatelem a login-serverem. Časová souslednost jednotlivých akcí nutných pro úspěšné ověření uživatele do webové aplikace je patrná z obrázku
.
- Neověřený uživatel přistupuje k webové aplikaci chráněné WebAuthem.
- mod_webauth detekuje, že uživatel dosud nevlastní aplikační token (neobdrží od něj aplikační cookie) a vytvoří tzv. request-token pro id-token. Request-token obsahuje informace jako jsou návratové (resp. původně dotazované) URL, požadovaný typ tokenu, atp. Request-token je zakryptován použitím AES session-klíčem sdíleným mezi aplikačním serverem a WebKDC (login-server) získaným z webkdc-service-tokenu.
- mod_webauth pak vytvoří redirekt na WebKDC, jenž obsahuje request-token v parametrech URL.
- Redirekt způsobí přesměrování uživatelova prohlížeče na WebKDC spolu s vygenerovaným request-tokenem. Žádné cookie není zasláno na WebKDC (zatím žádné uživatel nemá).
- WebKDC následně rozkryptuje request-token. Zkontroluje čas vytvoření, za účelem ověření, zda je dostatečně "čerstvý" a pošle zpět uživatelskému prohlížeči přihlašovací formulář. Request-token je uložen ve skryté položce tohoto formuláře.
- Uživatel zadá své přihlašovací jméno a heslo a odešle data formuláře zpět ke zpracování na WebKDC.
- WebKDC ověří zadané jméno a heslo a také skutečnost, zda aplikační server, který požaduje ověření uživatele má povolení vyžadovat id-token. Předpokládejme, že přihlašovací jméno a heslo jsou správná, pak WebKDC vytvoří cookie, do kterého uloží proxy-token a id-token (obsah cookie je kryptován privátním AES-klíčem WebKDC).Stránka s potvrzením, že ověření proběhlo v pořádku, je následně zaslána do uživatelského prohlížeče obsahující odkaz na původně požadovanou stránku.
- Uživatelský prohlížeč znovu přistoupí na původně požadovanou stránku a v URL parametrech je předán také id-token (identita) uživatele.
- mod_webauth si z požadavku převezme id-token a následně zkontroluje, zda je "čerstvý". Pokud je vše v pořádku, pak přepíše id-token na aplikační-token a uloží jej do cookie pro další použití. Nakonec je token odstraněn z URL (již není zapotřebí -- aplikace věří předkládanému cookie, které je kryptované jejím privátním AES klíčem).
Pokud je uživatel již úspěšně ověřen pomocí WebKDC, pak přístup ke každé další aplikaci probíhá zjednodušeným způsobem -- viz obrázek.
.
- Uživatel přistupuje k webové aplikaci chráněné WebAuthem.
- mod_webauth detekuje, že uživatel dosud nevlastní aplikační token (neobdrží od něj aplikační cookie) a vytvoří tzv. request-token pro id-token. Request-token obsahuje informace jako jsou návratové (resp. původně dotazované) URL, požadovaný typ tokenu, atp. Request-token je zakryptován použitím AES session-klíčem sdíleným mezi aplikačním serverem a WebKDC (login-server) získaným z webkdc-service-tokenu.
- mod_webauth pak vytvoří přesměrování na WebKDC (obsahující request-token v parametrech URL).
- Redirekt způsobí přesměrování uživatelova prohlížeče na WebKDC spolu s vygenerovaným request-tokenem. Zároveň je na WebKDC server zaslané cookie obsahující proxy-token a id-token, které WebKDC server uživateli vystavil při jeho prvotním ověření.
- WebKDC server detekuje ze zaslaného cookie, že uživatel má platný proxy-token a použije jej pro vytvoření nového id-tokenu pro aplikační server. WebKDC následně vygeneruje návratové URL, které obsahuje response-token pro aplikační server.
- Uživatelský prohlížeč znovu požádá o původně zadanou chráněnou stránku a v URL parametru předá aplikačnímu serveru id_token již dříve přihlášeného uživatele.
- mod_webauth si z požadavku převezme id-token a následně zkontroluje, zda je <uv>čerstvý</uv>. Pokud je vše v pořádku, pak přepíše id-token na aplikační-token a uloží jej do cookie pro další použití. Nakonec je token odstraněn z URL (již není zapotřebí -- aplikace věří předkládanému cookie, které je kryptované jejím privátním AES klíčem).
FAQ, aneb často kladené otázky
- Jak nakonfigurovat ověření WebAuthem na straně aplikace?
- Viz odkaz v otázce. Toto nastavení JE třeba provést, aby vaše aplikace byla chráněna systémem WebAuth.
- Jak nakonfigurovat centrální ověřovací WebKDC server?
- Viz odkaz v otázce. Toto nastavení NENÍ třeba dělat, pokud chcete, aby vaše aplikace byla chráněna systémem WebAuth. Jde o zprovoznění centrálního serveru, který finálně dělá ověření uživatele proti systému Kerberos.
- Jaká verze WebAuthu je používána na ZČU?
- Na ZČU v současné době používáme cluster tří WebKDC serverů ve verzi 3.5.0 -- instalováno ze stable vetve debian Linuxu.
- Kde získám kerberovský principal a certifiktát webového serveru nutné pro provoz WebAuthu?
- O obojí můžete zažádat na e-mailové adrese aaa-req@service.zcu.cz, kde si mj. musíte dohodnout bezpečné předání KRB principalu a registračních kódů pro vydání webového certifikátu podepsaného Certifikační autoritou ZČU.
- Jak si vytvořím certifikát webového serveru?
- viz odkaz na prolinkovaný dokument v otázce.
- Kde získám certifikát certifikační autority ZČU?
- Tento certifikát je možné získat přímo na stránce CA ZČU: http://crl.zcu.cz/crl/ZCUrootCA.pem (přes pravé tlačítko myši nechat uložit obsah do lokálního souboru, jinak dojde pouze k importu certifikátu do vašeho WWW prohlížeče, což také není na škodu ;-))
- V logu mám následující chybu -- mod_webauth: curl_easy_perform: error(60): SSL certificate problem, verify that the CA cert is OK... Co s tím?
- Tato chyba se projeví, pokud uživatele autorizujete pomocí LDAP skupin. Problém je ten, že váš server neumí navázat bezpečné spojení s LDAP serverem, neboť nedokáže ověřit jeho certifikát. Např. v distribuci debian je nutné obsah souboru /usr/share/curl/curl-ca-bundle.crt nahradit certifikátem certifikační autority ZČU. Tento certifikát je možné získat přímo na stránce CA ZČU: http://crl.zcu.cz/crl/ZCUrootCA.pem - (přes pravé tlačítko myši nechat uložit obsah do lokálního souboru, jinak dojde pouze k importu certifikátu do vašeho WWW prohlížeče, což také není na škodu ;-)) Pozor!! Tento problém se může objevit též po upgradu balíku libcurl3 !!
- Jak rozběhnout ověření WebAuthem na jiné platformě než linux?
- V současné době máme bohaté zkušenosti pouze s provozem na platformě linux (debian). Pokud se vám podaří systém WebAuth zprovoznit na jiné platformě, např. na základě informací z vývojářského webu, rádi tyto vaše zkušenosti a informace zde zveřejníme.
Další odkazy
- WebAuth - zprovoznění clusteru WebKDC serverů
- WebAuth - ověřování certifikátem (provozní/interní dokumentace)
- WebAuth - odhlášení od aktuální služby a od WebKDC (logout)
- WebAuth - Webová autentizovaná proxy
- WebAuth na Apache 2.2.x
- Zprovoznění WebAuthu pro Javu (Java WebAuth Library) -- balík je zde
- WebAuth prezentace v powerpointu