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 se stará resp. vyžaduje 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.

.

[LPS:WebAuth/Konfigurace_WebKDC]

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

.

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.

.

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

Jak nakonfigurovat centrální ověřovací server WebKDC je možné vidět v tomto článku. Toto nastavení NENÍ třeba dělat, pokud chcete, aby vaše aplikace byla chráněna systémem WebAuth.