LPS:WebAuth

Z Support
Přejít na: navigace, hledání


Obsah

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.

Webauth schema.jpg
.

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

Webauth overeni full.jpg
.


  1. Neověřený uživatel přistupuje k webové aplikaci chráněné WebAuthem.
  2. 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.
  3. mod_webauth pak vytvoří redirekt na WebKDC, jenž obsahuje request-token v parametrech URL.
  4. 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á).
  5. 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.
  6. Uživatel zadá své přihlašovací jméno a heslo a odešle data formuláře zpět ke zpracování na WebKDC.
  7. 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.
  8. 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.
  9. 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.

Webauth overeni short.jpg
.
  1. Uživatel přistupuje k webové aplikaci chráněné WebAuthem.
  2. 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.
  3. mod_webauth pak vytvoří přesměrování na WebKDC (obsahující request-token v parametrech URL).</li>
  4. 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í.
  5. 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.</li>
  6. 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.
  7. 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 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.
  • 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

Osobní nástroje
Jmenné prostory

Varianty
Zobrazení
Akce
Kdo jsem
Navigace
Často hledaná témata
Nástroje