Tento text pojednává o autentizaci na webu, a to zejména tam, kde existuje větší množství na sobě nezávislých web serverů, které mají různý stupeň důvěryhodnosti a jsou používány přibližně stejnou skupinou uživatelů. Uživatel by měl mít možnost se identifikovat na každém web serveru stejným způsoben (např. stejným jménem/heslem) a nejlépe pouze jednou (tj. pokud se již jednou autentizoval při přístupu k dokumentům na web serveru A, potom by při požadavku na dokument ze serveru B neměl být znovu obtěžován vypisováním svého jména/hesla).
Pro potřeby tohoto článku rozdělím autentizaci na tři typy:
Protokol HTTP 1.0 definuje jednoduchý challenge-response autentizační mechanismus. V rámci tohoto mechanismu mohou být použita různá autentizační schémata.
V protokolu HTTP 1.0 je jako jediné autentizační schéma definováno Basic Authentication schéma, protokol HTTP 1.1 je rozšířen o Digest Access Authentication schéma. Obě typu 1.
Basic Authentication je založena na tom, že uživatel zašle svůj login a heslo, jež jsou zakódovány ve formě base64. Z toho je patrné, že toto schéma samo o sobě neposkytuje žadné zabezpečení proti odposlechu hesla po cestě.
Digest Access Authentication byl navržen za účelem odstranění zásadního nedostatku Basic autentizace, tj. zasílání hesla v otevřené formě. V tomto případě klient zasílá pouze MD5 kontrolní součet loginu, hesla a řetězce, který obdržel od serveru v rámci požadavku na autentizaci.
Většina současných prohlížečů umí jak basic tak digest autentizaci, jakékoli další autentizační schéma musí být obvykle implementováno jako rozšiřující plugin prohlížeče, což ztěžuje jejich větší rozšíření.
Další možností, která je taktéž hojně využívána, je použití běžného html formuláře, kde uživatel vyplní login/heslo a ty jsou zaslány na server. Server následně vytvoří relaci (session), jejíž identifikátor je mezi serverem a prohlížečem předáván pomocí cookies1 nebo je přímo vkládán do URL. Pokud je klient jistou dobu neaktivní, je relace na serveru zrušena a v případě dalšího požadavku na dokument je třeba provést autentizaci znovu.
Protokol HTTP nezajištuje důvěrnost přenosu ani integritu spojení. Proto se obvykle používá transportní vrstva, která zajistí důvěrnost/integritu spojení a taktéž autentizaci klienta/serveru pomocí asymetrické kryptografie. V současné době je nejrozšířenější transportní protokol SSL (Secure Socket Layer) vyvinutý společností Netscape. Zabezpečení protokolu HTTP pomocí SSL se označuje jako protokol HTTPS. Jako následník SSL je označován TLS protokol (Transport Layer Security).
Použití SSL umožňuje autentizaci založenou na asymetrické kryptografii (typ 3), konkrétně X.509 certifikátech. Uživatel obdrží osobní certifikát od certifikační autority. S tímto certifikátem se pak může autentizovat v rámci skupiny serverů, které této certifikační autoritě důvěřují. Zřejmou výhodou tohoto přístupu je to, že uživatel může bez rizika použít jeden certifikát pro autentizaci na více místech (web serverech). Za možnou nevýhodu pak lze považovat to, že na rozdíl od jména/hesla, které je možno si lehce zapamatovat, certifikát nemusí mít uživatel vždy po ruce. Osobní certifikáty obsahují základní údaje o uživateli a jsou tedy velmi vhodné pro "instantní registraci", tj. uživatel je ušetřen zdlouhavého vyplňování formulářů, protože základní údaje jsou převzaty právě přímo z certifikátu.
Autentizace na webu za pomocí systému Kerberos je v současné době řešena dvěma způsoby:
Výhodou prvního způsobu je to, že není třeba upravovat klienta, postačí pouze úprava serveru. Tento přístup však není příliš korektní a příčí se základním principům systému Kerberos.
Tento systém se skládá z centrálního autentizačního web serveru (authsrv), aplikačních web serverů (appsrv) a samozřejmě webových klientů. V případě, kdy klient chce využít služeb aplikačního web serveru, je nejdříve přesměrován na autentizační web server, kde se autentizuje pomocí Basic Authentication. Autentizační web server následně sdělí aplikačnímu serveru identitu uživatele, a to s využitím asymetrické kryptografie. Aplikační server vytvoří pro klienta novou relaci, jejíž identifikátor se může předávat pomocí cookies.
Jednotlivé kroky autentizace jsou ilustrovány následujícím příkladem:
Klient požaduje stránku z aplikačního web serveru, jejíž URL je:
https://appsrv.net/info.cgi
Aplikační server přesměruje klienta na URL:
https://authsrv.net/auth?challenge=náhodný text&appsrv=https://appsrv.net/&appauth=starts.pl&back=info.cgi
Autentizační server provede Basic autentizaci uživatele, vygeneruje autentizační řetězec AR a přesměruje klienta na URL:
https://appsrv.net/starts.pl?AR=autentizacni retezec&back=info.cgi
Autentizační server z parametru AR odvodí identitu uživatele a vytvoří pro něj novou relaci. Následuje závěrečné přesměrování na původní stránku, tj.:
https://appsrv.net/info.cgi
Pokud je uživatel nějakou dobu neaktivní a relace vyprší, celý autentizační mechanismus se zopakuje. Vzhledem k tomu, že autentizační server používá Basic autentizaci, uživatel již nemusí znovu zadávat login a heslo. To samé platí i v případě, že uživatel navštíví jiný aplikační server, který používá tentýž autentizační server.
Autentizační řetězec AR obsahuje id-uživatele, čas, challenge řetězec a jméno aplikačního serveru, pro nějž byl generován. To vše je zakryptováno privátním klíčem autentizačního serveru a zakódováno ve formě base64.
Kerberos
Je třeba počítat s tím, že je nutno použít upravené prohlížeče, takže
použití tohoto řešení je vhodné v rámci menších skupin, popř. tam, kde
je již Kerberos hojně využíván.
Osobní certifikáty
Tento typ autentizace je součástí transportního protokolu SSL, jenž je
podporován většinou v současné době používaných prohlížečů i web
serverů. Ne každý uživatel však asi bude nadšen tím, že k autentizaci
potřebuje jakýsi certifikát, který má uložen někde na lokálním disku a
k němuž si stejně musí pamatovat heslo, aby nebylo možno certifikát
zneužít.
BCA
Vyžaduje úpravy na straně web serverů, což je pro uživatele, jemuž
k autentizaci stačí pouze znalost jména a hesla, mnohem praktičtější.
Taktéž správa uživatelů v rámci jednoho autentizačního serveru je
mnohem jednodušší než využítí certifikátů a jejich distribuce či
revokace.
| 1 | Cookies umožnují web serveru uložit informace na straně klienta
a poté je v případě potřeby získat zpět.
... zpět do textu |
předchozí článek
