LPS:WebAuth

Z HelpDesk

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.

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

Frquently Asked Questions

Jak nakonfigurovat centrální ověřovací WebKDC server?. Toto nastavení NENÍ třeba dělat, pokud chcete, aby vaše aplikace byla chráněna systémem WebAuth.