WebISO - Single Sign-On řešení pro WWW

Technická zpráva CESNETu číslo 7/2005
k dispozici též ve formátech PDF, PostScript a XML.

Petr Grolmus
30. listopadu 2005

1   Elektronická identita

Každý jednotlivec žijící v moderní společnosti je identifikovatelný velkým množstvím atributů, jakým mohou být například rodné číslo, číslo občanského průkazu, cestovního pasu, řidičského průkazu, číslo kreditní karty, bankovních účtů a mnohými dalšími. Elektronickou identitu jednotlivce lze však chápat v mnohem větším měřítku. K dříve uvedeným je možné přidat e-mailové adresy, jména a hesla k aplikacím a systémům, diář plánovaných schůzek, seznam kontaktů, charakteristické profily zájmů, ale také i elektronicky objednané obědy z firemního jídelníčku. Přidáme-li k tomuto výčtu spojeného nejčastěji s výkonem zaměstnání další uživatelovy "otisky" při putování internetem (účty veřejných poskytovatelů elektronické pošty, účty v rámci elektronických obchodů, registrace při stažení demoverzí softwarových produktů, identitu v diskuzních fórech, ...), dostaneme poměrně pěknou džungli plnou jmen, hesel a různých kódů.

Naštěstí doba, kdy každá nová aplikace si s sebou přinášela vlastní1 způsob ověření uživatelů a řízení přístupových práv, se pomalu stává minulostí. Stále více se daří přesvědčovat dodavatele nových systémů, aby využívali k ověření uživatelů autentizačních prostředků již ve firmách zavedených. V rámci společností se nyní směřuje k tomu, aby uživatel byl uvnitř rámci organizace identifikován ve výpočetním systému, pokud možno, pouze jediným účtem (jménem/heslem, osobním certifikátem, apod.).

2   SSO řešení WebAuth

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 Apache2: 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.

[Obrázek]

Obrázek 1: 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.

[Obrázek]

Obrázek 2: Prvotní přihlášení uživatele k SSO

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

[Obrázek]

Obrázek 3: Single Sign-On

  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. mod_webauth pak vytvoří přesměrování na WebKDC (obsahující request-token v parametrech URL).
  3. 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í.
  4. 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.
  5. 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.
  6. 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).

2.1   Konfigurace WWW serveru Apache na WebKDC

Pro správnou funkci je samozřejmě nutné korektně nakonfigurovat jednotlivé moduly WWW serveru, jak na straně WebKDC, tak na straně jednotlivých aplikačních serverů. V době, kdy jsme začínali experimentovat se systémem WebAuth, bylo v podstatě nutné moduly na jednotlivých strojích ručně překládat. V současné době již vývojáři poskytují kompilované balíky pro linuxovou distribuci Debian, čímž výrazným způsobem zjednodušili jak používání jejich systému, tak i jeho další šíření.

Jak WebKDC, tak i všechny aplikační servery mají svůj vlastní principal v Kerberos systému. Tento fakt pomáhá zvyšovat bezpečnost celého systému, neboť je možné definovat seznam "povolených" aplikačních serverů, které smí požádat o identitu přistupujícího uživatele.

Na straně WebKDC je samozřejmě nutné zapnout modul mod_webkdc, nainstalovat skripty a šablony, které se účastní ověření uživatele (přihlašovací formulář a jeho zpracování). V neposlední řadě je nutné provést alespoň minimální konfiguraci modulu. Toto nastavení může v konfiguračních souborech WWW serveru Apache vypadat například takto:

   ## WebKDC nastavení
   WebKdcServiceTokenLifetime 30d
   WebKdcKeyring /etc/apache2/conf/webkdc/keyring
   WebKdcKeytab /etc/apache2/conf/webkdc/keytab
   WebKdcTokenAcl /etc/apache2/conf/webkdc/token.acl

kde soubor keytab obsahuje krb klíč služby webkdc - půjde například o klíč krb principalu "webkdc/webkdc.zcu.cz@ZCU.CZ". Soubor keyring pak obsahuje soukromý AES klíč webkdc služby. Tento soubor je načten při každém startu nového procesu Apache. V případě, že dosud tento soubor neexistuje, je modulem mod_webkdc vytvořen pro další použití. Direktiva WebKdcServiceTokenLifetime určuje, s jakou periodou si bude modul z bezpečnostních důvodů měnit tento privátní klíč. Poslední z uvedených souborů token.acl obsahuje seznam krb principalů, které se mohou serveru WebKDC dotazovat na identitu uživatele a také seznam tokenů, které mohou vyžadovat. Soubor tedy může mít například tento obsah:

    krb5:webauth/*.zcu.cz@ZCU.CZ id

kde tato řádka definuje, že kterýkoliv aplikační server identifikovaný krb principalem s instancí "webauth" v doméně zcu.cz (webauth/*.zcu.cz) smí vyžadovat identifikační token uživatele (id). Pokud máte kontrolu nad vytvářením krb principalů pro jednotlivé aplikační servery, pak je tento zápis dostačující. V opačném případě by bylo vhodné vyjmenovávat všechny tyto principaly pro případ jejich možného pozdějšího vyřazení ze seznamu aplikací, které se smějí WebKDC dotazovat na uživatelovu identitu.

2.2   Konfigurace WebAuthu na aplikačních serverech

Konfigurace modulů na straně aplikačního serveru je rozdělena na dvě části. První provádí obecné nastavení, jako je definování adresy URL pro ověření dosud neznámého uživatele na WebKDC serveru, soubor s krb klíčem principalu, apod. Definice nastavení pro modul mod_webauth může vypadat tedy například takto:

   ## WebAuth nastaveni
   WebAuthLoginURL "https://webkdc.zcu.cz/login.fcgi"
   WebAuthWebKdcURL "https://webkdc.zcu.cz/webkdc-service/"
   WebAuthWebKdcPrincipal webkdc/webkdc
   WebAuthKeyring /etc/apache2/keyring
   WebAuthKeyringAutoUpdate on
   WebAuthKeyringKeyLifetime 30d
   WebauthKeytab /etc/apache2/keytab
   WebAuthServiceTokenCache /etc/apache2/service_token.cache

Většina konfigurace tohoto modulu lze odvodit z názvu jednotlivých direktiv, ale pro pořádek je rozepíšeme. První URL odkazuje na přihlašovací formulář; druhý URL odkaz směřuje na adresu, kam aplikační servery přímo posílají kryptované požadavky; další řádka obsahuje název krb principalu služby WebKDC. Další tři direktivy souvisejí s lokálně uloženým privátním AES klíčem aplikačního serveru. WebAuthKeyring sděluje modulu, kde daný klíč leží; direktiva WebAuthKeyringAutoUpdate povoluje modulu automatickou změnu tohoto klíče a WebAuthKeyringKeyLifetime určuje, jak dlouho může být jednou vygenerovaný klíč používán před další výměnou. Direktiva WebauthKeytab sděluje, kde na disku je možné najít klíč krb principalu aplikačního serveru. Poslední direktiva slouží k uložení service-tokenu, který se tak stává použitelným pro všechny nově vytvářené procesy WWW serveru Apache.

V případě, že je na aplikačním serveru použit i modul mod_webauthldap, pak další konfigurace se týká tohoto modulu:

   ## WebAuthLDAP nastaveni
   WebAuthLdapHost ldap.zcu.cz
   WebAuthLdapBase ou=rfc2307,o=zcu,c=cz
   WebAuthLdapAuthorizationAttribute cn
   WebAuthLdapKeytab /etc/apache2/ldapkeytab webauth/sso.zcu.cz
   WebAuthLdapFilter memberUid=USER
   WebAuthLdapTktCache /tmp/webauthldap.tkt

První direktiva určuje, na kterém serveru bude hledat informace pro autorizaci podle skupin. Další direktiva WebAuthLdapBase definuje konkrétní úložiště s informacemi o skupinách. WebAuthLdapAuthorizationAttribute určuje, který atribut koresponduje s položkou v LDAPu obsahující skupiny uživatelů. WebAuthLdapKeytab obsahuje odkaz na soubor s klíčem krb principalu použitého pro dotaz na LDAP server. WebAuthLdapFilter definuje filtr do LDAPu, který určuje, na kterou z položek je mapován login uživatelů. Poslední direktiva určuje Kerberos cache, která pokud obsahuje validní krb ticket, tak je použit, jinak je použit dříve definovaný keytab k získání nového krb ticketu.

Další část konfigurace už se týká přímo chránění přístupu pro definovaný adresář pomocí WebAuth SSO řešení.

<Directory /usr/local/data/www/>
    AllowOverride None
    AuthType WebAuth
    Require privgroup lps civ
    Require user indy bike dolf sustr4
</Directory>

Důležité jsou poslední tři řádky uvnitř tagu Directory. Direktiva AuthType definuje, že přístup pro daný adresář je používána služba WebAuth. Další řádek určuje seznam povolených skupin uživatelů (skupiny lps a civ). Poslední řádek obsahuje explicitní seznam povolených uživatelů, kteří budou autorizováni bez ohledu na příslušnost v některé ze skupin. V případě, že aplikační server neobsahuje modul mod_webauthldap, pak není možné přístup omezovat na seznam skupin uživatelů. Je možné povolit přístup jen pro vyjmenované uživatele, případně lze povolit všechny uživatele pomocí direktivy Require valid-user.

Použitá literatura

[sso] Grolmus, P., Švamberg, M.: Single Sign-On řešení pro webové aplikace. Vyšlo ve sborníku XXVII. konference EurOpen, 2005, s.87-100, ISBN 80-86583-09-0,
[wa] http://webauthv3.stanford.edu/ - domovská stránka SSO systému WebAuth vyvíjeném na Lealand Stanford Junior University, California, USA,
[cs] http://www.umich.edu/ umweb/software/cosign/ - webové SSO řešení z University of Michigan, Michigan, USA,
[pc] http://www.pubcookie.org/ - oficiální stránka webového SSO PubCookie,

 

Poznámky:

  1. samozřejmě nejlepší ;-)

  2. Moduly jsou psány pro verzi Apache 2.0.43 a vyšší.

další weby:fond rozvojemetacentrumCzechLightpřenosyvideoservereduroameduID.cz