UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

Transkript

1 UNICORN COLLEGE Katedra informačních technologií BAKALÁŘSKÁ PRÁCE Analýza protokolů pro distribuovanou autentizaci Autor BP: Jaromír Talíř Vedoucí BP: Ing. David Hartman, Ph.D Praha

2

3 6

4 Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Analýza protokolů pro distribuovanou autentizaci vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V Praze dne Jaromír Talíř

5 Poděkování Děkuji vedoucímu bakalářské práce Ing. Davidu Hartmanovi Ph.D. za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

6 Analýza protokolů pro distribuovanou autentizaci Analysis of Protocols for Distributed Authentication 6

7 Abstrakt Tématem práce jsou internetové autentizační protokoly jako například SAML nebo OpenID. V internetové historii bylo standardizováno takových protokolů několik, a přestože se v mnoha aspektech liší, existují společné stavební prvky, které lze nalézt v každém z nich. Práce si klade za cíl poskytnout přehled těchto protokolů, identifikovat společné principy, na kterých jsou tyto protokoly postavené, a porovnat, jak jsou tyto principy v jednotlivých protokolech implementovány. Klíčová slova: Autentizační protokol, Kerberos, SAML, OpenID, OAuth, OpenID Connect, Mozilla BrowserID Abstract The topic of the thesis are authentication protocols like SAML or OpenID. Several such protocols have been standardized in the history of the Internet and despite they differ in many ways, many common building blocks exists in each of them. The goal of the thesis is to provide overview of protocols, to identify common principles used to construct these protocols and to compare how these principles are implemented in individual protocols. Keywords: Authentication protocol, Kerberos, SAML, OpenID, OAuth, OpenID Connect, Mozilla BrowserID 7

8 Obsah 1 Úvod Distribuovaná autentizace Problémy autentizačních mechanismů Koncept distribuované autentizace a jeho výhody Rizika distribuované autentizace Významní poskytovatelé identit Autentizační protokoly Standardizační organizace definující autentizační protokoly Kerberos SAML OpenID Mozilla BrowserID OAuth a OpenID Connect Stavební prvky autentizačních protokolů Identita uživatele Potvrzené prohlášení o uživatelově identitě Počáteční nastavení důvěry Předání dalších údajů Závěr Seznam použitých zdrojů Seznam obrázků

9 1 Úvod Webové autentizační protokoly zažívají v posledních letech svou renesanci. Je to způsobeno jak rostoucí popularitou cloudových služeb v komerční sféře, tak i zrychlováním tempa rozvoje služeb e-governmentu ve vládních sektorech. V těchto oblastech je jedním ze základních atributů právě koncept jednotné elektronické identifikace a autentizace. V internetové historii bylo standardizováno několik protokolů pro distribuovanou autentizaci, ale ne všechny byly úspěšné. Na poli distribuované autentizace v lokálních sítích dosáhl největšího úspěchu protokol Kerberos a z jeho architektury vycházeli i návrháři webových protokolů. První protokol, který uspěl na webové vrstvě, byl SAML. Jeho zjednodušením poté vznikl protokol OpenID. Nedostatky OpenID se v poslední době pokouší napravit nová verze OpenID Connect využívající nový autorizační protokol OAuth. Jako alternativa se také v nedávné době objevil projekt Mozilla BrowserID. V české literatuře dosud nebylo toto téma systematicky podchyceno, a proto je jedním z cílů této práce poskytnout úvodní seznámení s problematikou. Dále si práce klade za cíl popsat historii vývoje zmíněných autentizačních protokolů, identifikovat jejich základní stavební prvky a v závěru provést komparativní analýzu těchto prvků v jednotlivých protokolech. Přestože se v historii vývoje konceptu distribuované autentizace objevilo mnohem více řešení (například WS-Federation nebo InformationCards), práce se těmto nevěnuje a omezuje se pouze na ty nejpopulárnější protokoly zmíněné v prvním odstavci. Ve druhé kapitole bude představen koncept distribuované autentizace, důvody jeho uplatnění a hlavní aktéři prosazující jeho zavádění. Třetí kapitola poskytne přehled jednotlivých protokolů a jejich základní vlastnosti. Čtvrtá kapitola poté identifikuje, jaké jsou hlavní stavební prvky těchto protokolů, jako nastavení prvotní důvěry, dynamické zjišťování informací o protistraně nebo předávaní potvrzení o identitě uživatele. Závěrečná kapitola pak poskytne shrnutí problému. 9

10 2 Distribuovaná autentizace Trendem dnešní doby je implementace řešení IT problémů ve formě služeb dostupných přes internet, ať už ve formě IaaS (Infrastructure as a Service), PaaS (Platform as a Service), nebo SaaS (Software as a Service). Ve všech těchto případech je klíčovou vlastností takového řešení nutnost zabezpečení služby pomocí autentizace uživatele. Implementace autentizačních mechanismů do každé služby s sebou ovšem nese celou řadu problémů. 2.1 Problémy autentizačních mechanismů V první řadě roste počet autentizačních údajů, které musí uživatel udržovat. Převažujícím autentizačním mechanismem jsou stále hesla, která si uživatel musí pamatovat, a jejichž vzrůstající množství může mít negativní vliv na bezpečnost. Uživatelé se snaží používat jednoduchá nebo snadno zapamatovatelná hesla, která je ovšem pak velice snadné prolomit. Nutnost pamatovat si všechna hesla vede k tomu, že si je uživatelé zapisují na papír, ale už neřeší zabezpečení této papírové formy. Odstrašujícím příkladem jsou hesla napsaná na papírcích nalepená na krajích monitoru v kanceláři. Nedostatek fantazie ve vymýšlení nových silných hesel způsobuje, že uživatelé používají stejná hesla pro více služeb. To však v kombinaci s nedostatečným zabezpečení jednotlivých služeb vytváří riziko zneužití získaného hesla pro více služeb. Implementace pokročilých metod detekce průniku, která by měla být součástí autentizačního řešení, však přináší provozovatelům služeb nemalé náklady. I s použitím těchto pokročilých bezpečnostních metod je ovšem používání hesel rizikové, neboť není odolné proti útokům na hesla označovaným jako phishing. Útočník chytrým způsobem vzbudí v uživateli dojem, že přistupuje na reálnou stránku, a donutí ho zadat heslo, které nakonec skončí ve špatných rukou. Z těchto důvodů je u důležitých služeb nutné implementovat takové metody autentizace uživatele, které jsou proti phishingu odolné a vycházejí z kombinace více faktorů. Uživatel musí v těchto metodách prezentovat službě jak znalost nějakého sdíleného tajemství, tak i vlastnictví nějakého soukromého prvku, který nemůže mít nikdo jiný. Opět zde však platí nutnost nemalých investic do implementace těchto autentizačních mechanismů. 10

11 Většina provozovatelů internetových služeb musí také řešit správu osobních údajů svých uživatelů. V minimalistické variantě to obvykle znamená evidovat kromě jména a příjmení některé kontaktní údaje jako ovou adresu nebo telefonní číslo. Z důvodu fyzického doručování zboží nebo dopisové korespondence je někdy nutné udržovat také uživatelovu fyzickou adresu nebo několik takových adres. Většina služeb na internetu tedy začíná svůj vztah se svým uživatelem procesem registrace, ve kterém musí uživatel tyto údaje službě předat. Rostoucí počet opakovaných procesů registrace, při kterých uživatel předává službám stále tatáž data, zaručeně nepřispívá k jeho komfortnímu pocitu. Pro poskytovatele služeb je v souvislosti s osobními údaji důležitá jejich správnost a aktuálnost, protože např. doručení zboží na nesprávnou adresu mu přináší nemalé náklady. Je nasnadě, že uživatel, který musí udržovat kopie svých údajů v desítkách služeb, při změně nějakého údaje buď jejich aktualizaci ve všech těchto službách odmítne, nebo na některou z těchto služeb zapomene. Nesprávnost údajů může být ovšem také záměrná s cílem poskytovatele nějak poškodit. Z těchto důvodů se v internetových službách stále častěji objevují techniky ověřování poskytnutých údajů. V zásadě jsou možné dva přístupy k těmto kontrolám. V prvním přístupu může poskytovatel služby provést pokusné doručení nějakého jednorázového kódu na kontaktní údaj, např formou u, zprávy SMS nebo dopisu. Po zpětném obdržení tohoto kódu od uživatele má poskytovatel jistotu, že poskytnuté údaje existují a jsou pod kontrolou tohoto uživatele. Druhým, silnějším přístupem je fyzická kontrola údajů uživatele proti údajům v občanském průkazu při osobní návštěvě. Opět je zřejmé, že ověření poskytnutých údajů některým z popsaných způsobů znamená významné zvýšení nákladu na provoz služby. Poskytování osobních údajů na internetu je navíc obecně citlivé téma a obvykle na něj dohlíží regulátor, v případě České republiky je to Úřad pro ochranu osobních údajů. Ten má za úkol dohlížet, aby s údaji bylo nakládáno v souladu se zákonem. To mimo jiné znamená počínat si tak, aby údaje byly uchovávány bezpečně. Splnění této povinnosti vyžaduje, aby byla data u poskytovatele služby zabezpečena už při svém sběru, což lze zajistit implementací bezpečnostních prvků do procesu registrace, jako například šifrováním komunikace s uživatelem prostřednictvím technologie SSL. Jak ukazují výzkumy prováděné organizacemi jako EFF (Electronic Frontier Foundation), rozšířenost tohoto typu zabezpečení je stále minimální. 11

12 2.2 Koncept distribuované autentizace a jeho výhody Výše popsané problémy postupně vedly ke změně paradigmatu v oblasti autentizace uživatelů internetových služeb a k zavedení konceptu distribuované autentizace, někdy též označované jako AaaS (Authentication as a Service) nebo SSO (Single Sign-On). Klíčovou vlastností tohoto konceptu je přenesení zodpovědnosti za řešení části nebo všech výše uvedených problémů na třetí stranu, která má dostatečné zdroje, zázemí nebo zkušenosti pro jejich úspěšné řešení. Tato strana se obvykle označuje jako poskytovatel identit (IdP Identity provider) a má za úkol bezpečně spravovat údaje uživatelů a provádět jejich autentizaci bezpečnou a dostatečně silnou metodou. Na opačné straně stojí poskytovatel služby (SP Service provider), který potřebuje s využitím poskytovatele identit ověřit totožnost uživatele požadující službu. Někdy se tato strana také označuje jako důvěřující strana (RP Relying party). Schématicky je koncept distribuované autentizace znázorněn na následujícím obrázku: Obrázek 1: Schéma distribuované autentizace 1. Uživatel se pokusí o přístup ke službě (SP), která vyžaduje autentizaci. 12

13 2. SP z předaných údajů zjistí, kde se nachází poskytovatel identity pro daného uživatele (IdP) a přesměruje uživatele na vstupní bránu IdP. 3. Uživatel zadá autentizační údaje, které po něm požaduje IdP, a tím se autentizuje. 4. IdP přesměruje uživatele zpátky na SP a přibalí k přesměrování informaci, ze které je možné získat identifikaci uživatele. 5. SP vybalí identifikaci uživatele, ověří si, že pochází od prověřeného IdP, a pokud je vše v pořádku, uživateli umožní využívat službu. Rozhodnutím se pro využití distribuované autentizace uvolňuje poskytovatel služeb interní zdroje, které by jinak musel věnovat na zajištění vlastního řešení, a může je tím pádem využít na svou hlavní činnost. Zároveň tím získává jeho systém vlastnosti, které jej dělají mnohem robustnějším. Poskytovatel identit se totiž na autentizaci specializuje, a může ji tak vykonávat mnohem lépe. V první řadě může nabídnou celou škálu autentizačních metod jako klientské SSL certifikáty, jednorázová hesla (OTP One Time Password) nebo třeba i otisk prstu. Objevují se však i nové přístupy k vlastnímu ověření uživatele jako např. různé grafické metody spojování obrázkových komponent v předloženém obrázku. S každým rozšířením těchto metod ji přirozeně mohou okamžitě používat všichni poskytovatelé služeb napojení na tohoto poskytovatele identit. Samozřejmostí je, že poskytovatel služby si může vyžádat konkrétní metodu autentizace, zejména pokud se jedná o službu s citlivými údaji. Vedle toho může poskytovatel identit nabídnou vysokou úroveň ochrany proti podvržené autentizaci. Systém poskytovatele může třeba hlídat, jak často se uživatel přihlašuje nebo odkud se uživatel přihlašuje, a v případě detekce nějaké anomálie vyžádat dodatečné potvrzení identity uživatele. Google například během každého přihlášení analyzuje více než 120 proměnných, aby zjistil, zda-li se nejedná o pokus o unesení účtu[1]. Z pohledu správy údajů mohou poskytovatelé identit nabídnout jedinečnou možnost ověřování vložených údajů. Mnoho internetových zpravodajských portálů od roku 2010 postupně ruší anonymní registrace uživatelů diskutujících pod jednotlivými články. Důvodem je zejména boj proti vzrůstající verbální agresivitě těchto diskutujících. Obvyklým řešením neanonymní registrace je zaslání přístupového hesla dopisem na 13

14 poštovní adresu zadanou při registraci. Ale nejsou to jenom zpravodajské portály vyšší úroveň ověření uživatelů vyžadují i prodejní portály jako například Aukro.cz. Je zřejmé, že toto zasílání dopisů je ekonomicky nákladné. Poskytovatelé identity ovšem mohou toto ověření provést jednou pro mnoho poskytovatelů služeb, čímž se celý model rázem stává ekonomicky mnohem výhodnějším. 2.3 Rizika distribuované autentizace Přestože koncept distribuované autentizace přináší uživatelům větší pohodlí a vyšší bezpečnost při pohybu na internetu, má tento koncept také svá rizika, kterých by si každý uživatel měl být vědom. Tato rizika jsou ovšem obdobná jako například rizika rozhodnutí svěřit své finanční prostředky bankovnímu ústavu a používání platebních karet. Prvním rizikem je fakt, že poskytovatel identity, kterému uživatel svěří správu svých údajů, má přehled o všech poskytovatelích služeb, ke kterým se uživatel tímto způsobem přihlásí. Je to důsledek toho, že uživatel má v rámci přihlášení u poskytovatele identity možnost odsouhlasit, jaké informace se k poskytovateli služby přenesou. Je zde pak otázka důvěry v daného poskytovatele identity, tedy zda uživatel důvěřuje tomu, že tato data nebudou žádným způsobem zneužita. Konec konců v nastíněné analogii ví uživatelův bankovní ústav přesně o každém použití jeho platební karty a ve kterých obchodech byla použita. I přesto většina lidí tento fakt nevnímá jako zásadní problém a platební karty jsou čím dál populárnější. Právě tuto vlastnost distribuované autentizace se snažil vyřešit protokol Mozilla BrowserID, nicméně za cenu odmítnutí většiny výhod, které právě distribuovaná autentizace přináší. Jako riziko je svým způsobem možné chápat také hlavní vlastnost tohoto konceptu, tedy to, že je možné s jedněmi autentizačními údaji získat přístup k velkému množství služeb na internetu. Pokud uživateli někdo přístupové údaje odcizí, získá tím přístup ke všem jeho službám. Uživatel by tedy nadále neměl podceňovat bezpečnost nakládání s autentizačními údaji a v ideálním případě používat takové metody, které bezpečí zvyšují, jako například vícefaktorovou autentizaci. Na druhou stranu již bylo zmíněno, že uživatelé mají tendenci používat jedno a to samé heslo u více služeb, a oproti takovémuto stavu je v konceptu distribuované autentizace pravděpodobnější, že míra zabezpečení bude u důvěryhodného poskytovatele identit vyšší než u celé řady poskytovatelů služeb, které uživatel navštěvuje. 14

15 Výše popsaná rizika se týkala distribuované autentizace z pohledu uživatele. Existuje však také pohled implementátorů informačních systémů, které tento způsob autentizace využívají. Oproti klasické autentizaci je distribuovaný koncept implementačně náročnější, a to přirozeně přináší dodatečná rizika. Většina autentizačních protokolů má ve svých definujících dokumentech pasáž týkající se právě rizik při jejich implementaci. Implementátoři nesmí tato rizika ignorovat, neboť případná chyba může otřást důvěrou uživatelů a právě důvěra je jedním z klíčových prvků celého konceptu. 2.4 Významní poskytovatelé identit Celosvětově známé organizace, které lze označit za poskytovatele identit, jsou provozovatelé významných sociálních sítí jako Facebook, Google nebo LinkedIn. Z popsaných charakteristik distribuované autentizace se však tyto služby koncentrují pouze na oblast jednotného přihlašování, tzn. je možné do systémů poskytovatelů služeb implementovat možnost přihlášení se např. přes Facebook. Založit si účet u těchto služeb ovšem může kdokoliv a bez jakéhokoliv ověřování. V případě těchto sociálních sítí tedy rozhodně není možné spoléhat na správnost údajů, které o svých uživatelích evidují. V České republice je v tuto chvíli asi nejvýznamnějším zástupcem poskytovatelů identit služba mojeid, která je provozovaná správcem národní domény, sdružením CZ.NIC. Tato služba má ambice naplnit všechny aspekty problematiky zmiňované v předchozím textu. Služba mojeid byla představena na podzim v roce 2010 a podle zveřejněných statistik tuto službu od jejího zavedení alespoň jednou použilo již přes uživatelů[2]. Jednou z jejich klíčových vlastností je právě několikastupňové ověřování údajů uživatelů. Nejvyšší stupeň ověření představující kontrolu údajů proti dokladu totožnosti je prakticky totožný s ověřováním, jaké provádějí některé certifikační autority. V tuto chvíli jediný autentizační protokol, který tato služba podporuje, je protokol OpenID 2.0. V tuzemské akademické sféře již od roku 2005 existuje projekt EduID, který lze označit jako federaci vzájemně uznávaných poskytovatelů služeb a poskytovatelů identit. Stranu poskytovatelů identit tvoří vysoké školy, které disponují širokou uživatelskou bází studentů, učitelů a zaměstnanců. Vzhledem k tomu, že zařazení do této skupiny vyžaduje osobní souhlas a podpis řady dokumentů, dá se předpokládat vysoký stupeň důvěry v údaje 15

16 těchto osob. Stranu poskytovatelů služeb tvoří různé akademické instituce jako například knihovny, ale také opět samy vysoké školy. Je tedy např. Možné, aby se student přihlašoval do systémů cizí školy s autentizačními údaji ze své školy. Tuto federaci provozuje sdružení CESNET a jedná se víceméně o uzavřenou skupinu systémů. Služba EduID je celá postavená na standardizovaném protokolu SAML 2.0. Vzhledem k tomu, že asi nejkompletnější a obvykle nejaktuálnější databázi údajů o osobách eviduje každý stát, je nasnadě, že se oblast distribuované autentizace úzce dotýká konceptu e-governmentu, tedy možnosti elektronické komunikace státu a jeho občanů. V České republice jsme v tomto ohledu bohužel významně pozadu a projekt elektronické identity občanů v podobě elektronických občanských průkazů zatím stále ještě nepřekročil hranici diskuzí architektů. Zatím posledním počinem v této oblasti bylo zavedení základních registrů a jejich propojení se systémem datových schránek. Zatímco systém základních registrů poprvé představuje jednu kompletní, důvěryhodnou a centrální databázi občanů, systém datových schránek zavedený o pár let dříve poskytuje důvěryhodnou metodu autentizace pro elektronické služby. Díky tomuto propojení se začínají objevovat elektronické služby státní správy vyžadující přihlášení a využívající autentizační rozhraní datových schránek jako poskytovatele identit. Aby tento proces mohly využívat i služby mimo státní správu, bylo nutné novelizovat příslušný zákon a implementovat nové přístupové rozhraní. To bylo nabídnuto k dispozici soukromému sektoru až v roce Používání tohoto rozhraní je zpoplatněné a vzhledem k poměrně vysokým nárokům na subjekty, které se rozhodnout toto rozhraní používat (zejména v podobě splnění všech možných bezpečnostních certifikací), se zatím podařilo integrovat ho do svého systému pouze jednomu subjektu, a to bance ČSOB. Zajímavé také je (a je to již bohužel zvykem ve státní správě), že návrháři tohoto nového rozhraní nevyužili možností sáhnout po libovolném existujícím standardu na autentizační protokoly a vyvinuli proprietární, s ničím nekompatibilní vlastní protokol. Ostatní státy Evropské unie jsou na tom o poznání lépe. Některé z nich již dokonce několikrát testovaly možnost elektronických voleb, kde je jednou z klíčových vlastností právě jednoznačná elektronická identifikace občana. Přestože většina států, snad kromě Estonska, od elektronických voleb zatím ustoupila, koncept jednotné centrální elektronické autentizace využívá pro řadu svých služeb dále. V letech 2010 až 2012 probíhal v rámci rámcových operačních programů Evropské unie projekt STORK, jehož cílem bylo vytvořit 16

17 platformu na propojení existujících elektronických identifikačních systému států Evropské unie. Smysl projektu byl často demonstrován na příkladu potenciálního studenta, který se jde zapsat do zahraniční školy a použije k tomu eid (elektronickou identitu) ze svého domovského státu. Do projektu bylo zapojeno 10 států a na konci projektu bylo opravdu docíleno nasazení funkčního řešení. To spočívá v tom, že každý stát ve své zemi nasadí a bude provozovat bránu PEPS (Pan European Proxy Server). Všechny tyto brány budou nakonfigurovány tak, že o sobě budou vědět a budou si mezi sebou pomocí standardizovaného protokolu SAML předávat požadavky na autentizaci. Na každou bránu je pak v každé zemi připojen poskytovatel identity garantovaný státem a řada poskytovatelů služeb (například zmíněné univerzity), kteří celý systém přeshraniční autentizace využívají. Součástí celé elektronické transakce samozřejmě je předání zaručených osobních údajů uživatelů do systému poskytovatele služby. Přestože systém běží v produkčním provozu, existuje jen velice málo služeb, kde jej je možné reálně použít. Jediný, o kterém se veřejně mluví a na kterém se celý projekt STORK demonstruje, je interní systém Evropské komise ECAS (European Commison Authentication Service) sloužící pro autentizaci v elektronických agendách Evropské komise. Pro období 2013 až 2015 byl proto vypsán projekt STORK2, který má na infrastruktuře vybudované v rámci předchozího projektu postavit další užitečné služby. Tohoto projektu se již účastní i Česká republika. V rámci dohody mezi ministerstvem vnitra a sdružením CZ.NIC bude aktuálně jako jediný poskytovatel identity Českou republiku reprezentovat služba mojeid. Obsahem projektu STORK2 je hlavně řešení standardizace mezistátně předávaných údajů. Projekt využívá novou roli subjektu v rámci distribuované autentizace, a tím je poskytovatel atributů (AP Attribute Provider). Tento AP doplňuje roli IdP v tom smyslu, že zatímco IdP se stará pouze o autentizaci uživatele, AP přidává k identitě uživatele sadu atributů. K jednomu IdP tak může existovat několik AP. Jedním z tzv. pilotů projektu STORK2 je akademický pilot, jehož cílem je definovat sadu údajů poskytujících informace o dosaženém vzdělání. Představa je taková, že evropské vysoké školy by hrály právě roli poskytovatele atributů v rámci své země. Občan Evropské unie by tedy mohl kdekoliv v zahraničí elektronickým způsobem prokázat svoje vzdělání pouze předložením své elektronické identity. V rámci projektu STORK2 běží také pilot, který se snaží podchytit komplikovanou oblast právnických osob a na základě 17

18 elektronické evidence v jednotlivých státech umožnit zachytit situaci, kdy identifikovaná osoba jedná za někoho jiného, například jako jednatel nějaké společnosti. Z uvedených skutečností je patrné, že koncept distribuované autentizace je řešením reálných problémů světa na internetu a řada společností investuje nemalé úsilí do jeho prosazení v mnohem větším měřítku, než je zatím patrné. Dá se tedy předpokládat, že v nejbližších letech bude tento trend nadále pokračovat. V jádru každé zmíněné služby existuje nějaký autentizační protokol a o těchto bude pojednávat následující kapitola. 18

19 3 Autentizační protokoly Autentizačním protokolem je myšlen standardizovaný předpis, podle kterého se chovají systémy, které spolu komunikují za účelem provedení autentizace nějakého uživatele. Obecné schéma autentizačního protokolu je znázorněno v kapitole 2.2. V této kapitole budou popsány nejvýznamnější autentizační protokoly, a to Kerberos, SAML, OpenID 2.0, OpenID Connect a Mozilla BrowserID. Tyto protokoly vznikají postupně již od devadesátých let, a to obvykle na půdě hned několika standardizačních organizací. 3.1 Standardizační organizace definující autentizační protokoly O definování autentizačních protokolů se starají standardizační organizace. Ty jsou většinou (s výjimkou IETF) sdružením velkých firem, které se snaží udržet vzájemnou kompatibilitu svých systémů. Asi nejznámější standardizační organizací ve světě internetu je IETF (Internet Engeneering Task Force). Tato organizace vydává svá doporučení v řadě dokumentů označovaných jako RFC (Request For Comment). IETF stojí za celou řadou standardů v oblasti autentizace, mimo jiné za protokolem Kerberos nebo v posledních letech za protokolem OAuth. Do tvorby standardů v IETF se může zapojit prakticky každý, protože většina vývoje probíhá uvnitř otevřených ových konferencí. Další standardizační autoritou je organizace OASIS, která má na starosti většinu standardů, které nějakým způsobem využívají značkovací jazyk XML. Takovým standardem je právě autentizační protokol SAML, využívající XML jazyk pro formát svých zpráv. OASIS je členská organizace, a tudíž pro zapojení se do vývoje standardů je nutné kvalifikovat se do některé z členských kategorií. S organizací OASIS je úzce propojená standardizační organizace W3C, která definuje některé podpůrné standardy jako vlastní jazyk XML nebo digitální podepisování XML dokumentů XML-SIG. W3C je konsorcium sdružující více než tři stovky organizací. Poslední významnou institucí v této oblasti je OpenID Foundation, organizace založená specifický za účelem vyvinutí univerzálně akceptovaného autentizační standardu. 19

20 Jak je z názvu patrné, organizace stála u zrodu protokolu OpenID a průběžně tento protokol stále inovuje. Ne každý protokol však vzniká přímo u některé standardizační organizace. Často se stává, že protokol navrhne společnost nebo jedinec a teprve ve chvíli, kdy začne být protokol populární, se přesune do procesu standardizace. Tak například autentizační protokol Mozilla BrowserID je stále pouze návrhem od organizace Mozilla vyvíjející populární webový prohlížeč Firefox a v tuto chvíli neprobíhají žádné iniciativy směřující k jeho standardizaci. 3.2 Kerberos Vznik protokolu Kerberos spadá do druhé poloviny osmdesátých let a stojí za ním skupina vědců z americké univerzity MIT. Tato skupina nejprve vytvořila tři interní verze protokolu, a tak první verze, která se objevila na veřejnosti, byla verze 4. Tato verze vznikla v rámci většího projektu Athena, jehož cílem bylo vytvoření kampusové sítě propojující systémy univerzity a zaměřené na podporu vzdělávání studentů[3]. Krátce na to, v roce 1993 byla představena verze 5, která již vznikla na půdě IETF jako RFC 1510[4]. V rámci IETF byl standard v roce 2005 aktualizován, a tak je jeho aktuální podoba definována v RFC 4120[5]. Základní charakteristikou protokolu Kerberos je využití symetrické kryptografie za účelem jednoznačné identifikace uživatele bez nutnosti předání jakéhokoliv hesla v průběhu autentizace. Roli správce identity zde přebírá Kerberos Distribution Center (KDC), které udržuje databázi všech uživatelů a všech služeb ve spravované oblasti (realmu) včetně jejich hesel neboli klíčů. Jako klíč uživatele se používá hash jeho hesla. Tyto údaje je tedy nutné na začátku komunikace do KDC vložit. Každá služba a uživatel jsou v této databázi identifikováni pomocí strukturovaného řetězce označovaného jako principal. Pokud se chce uživatel autentizovat u některé služby, provede to tak, že požádá o spolupráci KDC. Od KDC dostane potvrzení autentizace zašifrované klíčem služby, ke které se uživatel hlásí, takzvaný tiket. Tiket také obsahuje náhodně vygenerovaný klíč sezení. Kromě tiketu, který je určený službě a k jehož obsahu uživatel nemá přístup, předá KDC uživateli klíč sezení ještě jednou, tentokrát zašifrovaný klíčem uživatele. Ze znalosti svého hesla může uživatel dekódovat klíč sezení, který v tuto chvíli sdílí se službou. 20

21 Uživatel mající tiket pro službu a klíč sezení pak již komunikuje přímo se službou. Té zašle pro identifikaci tiket a dvojici časová značka a principal, zašifrovanou klíčem sezení. Z těchto informací již služba může jednoznačně odvodit, s kým komunikuje. Aby nebylo nutné při každé této operaci požívat heslo uživatele, je KDC rozděleno na dvě komponenty, autentizační server (AS) a tiketovou službu (TGS). Uživatel nejprve provede výše popsanou transakci ve vztahu k tiketové službě a ze znalostí hesla obdrží tiket (TGT) a klíč sezení pro TGS. Při přihlášení k jakékoliv další službě již nepoužívá své heslo. S využitím získaného TGT obdrží od TGS tiket a klíč sezení k službě, ke které se chce přihlásit. Schéma komunikace je znázorněno na následujícím obrázku: Obrázek 2: Schéma komunikace protokolu Kerberos 1. Uživatel požádá o TGT. 2. AS vrátí TGT a zašifrovaný klíč sezení k TGS. 21

22 3. Uživatel pomocí svého hesla dešifruje klíč sezení a s tímto klíčem a TGT požádá TGS o tiket ke službě. 4. TGS vrátí tiket ke službě a klíč sezení ke službě. 5. Uživatel se přihlásí ke službě pomocí tiketu a klíče sezení ke službě. 6. Služba potvrdí přihlášení. Přes svoje stáří je protokol Kerberos stále velice populární v podnikových sítích. Je integrální součástí řešení Active Directory od firmy Microsoft, a tak bývá často využit v podnikových sítí provozovaných na platformě Windows. Zaměstnanci se tak mohou jedním heslem přihlašovat do všech podnikových služeb jako u, souborového serveru, webového intranetu a dalších. Bohužel tento protokol nikdy také rozsah podnikové sítě neopustil. Přes pokusy přenést protokol do webového prostředí[6], získaly nakonec v globálním internetu větší popularitu jiné protokoly. 3.3 SAML Na konci druhého tisíciletí se ve světě internetu objevil fenomén webových služeb. Rozvoj internetu umožnil, aby spolu komunikovaly systémy na mnohem větší vzdálenosti, a tak služby, které uživatelé požadovali, přestaly být lokální z pohledu podnikové nebo školní sítě. I v rámci těchto služeb, používajících prověřené webové prostředí, brzy vznikla potřeba nějakým způsobem řešit distribuovanou autentizaci. Vzniklo několik proprietárních řešení, ale první protokol který byl standardizován, byl právě SAML Security Assertion Markup Language. První verze SAML 1.0 byla publikována na půdě standardizační organizace OASIS v roce 2002 a o rok později byla na základě prvních zkušeností upravena do verze 1.1[7]. V roce 2005 byla vydána zatím poslední verze označená jako SAML 2.0, která již nebyla zpětně kompatibilní a přinášela některá potřebná rozšíření užitečná zejména pro takzvané federace identit. Tyto federace tvoří několik poskytovatelů identit, kteří navzájem uznávají své identity. Protokol SAML kombinuje několik ve své době populárních technologií. Především je to jazyk XML, který je použit jako formát zpráv. S tímto jazykem pak souvisí využití technologií jako XML Schema pro popis formátu zpráv a XML Signatures spolu 22