UNICORN COLLEGE BAKALÁŘSKÁ PRÁCE

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. 2014 Praha

6

Č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 1.8.2014

...................................... Jaromír Talíř

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.

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

6

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

Obsah 1 Úvod....................................................................................................................................9 2 Distribuovaná autentizace.................................................................................................10 2.1 Problémy autentizačních mechanismů......................................................................10 2.2 Koncept distribuované autentizace a jeho výhody....................................................12 2.3 Rizika distribuované autentizace...............................................................................14 2.4 Významní poskytovatelé identit................................................................................15 3 Autentizační protokoly......................................................................................................19 3.1 Standardizační organizace definující autentizační protokoly....................................19 3.2 Kerberos.....................................................................................................................20 3.3 SAML........................................................................................................................22 3.4 OpenID......................................................................................................................23 3.5 Mozilla BrowserID....................................................................................................24 3.6 OAuth a OpenID Connect.........................................................................................26 4 Stavební prvky autentizačních protokolů..........................................................................29 4.1 Identita uživatele........................................................................................................30 4.2 Potvrzené prohlášení o uživatelově identitě..............................................................34 4.3 Počáteční nastavení důvěry.......................................................................................37 4.4 Předání dalších údajů.................................................................................................39 5 Závěr..................................................................................................................................43 6 Seznam použitých zdrojů..................................................................................................45 7 Seznam obrázků................................................................................................................47

8

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

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

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 e-mailovou 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 e-mailu, 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

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

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

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

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 300 000 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

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

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

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

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 e-mailový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

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

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

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 e-mailu, 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

s XML Encryption pro podepisování a šifrování zpráv. Zprávy generované účastníky autentizačního procesu se v protokolu SAML předávají buď HTTP protokolem, nebo protokolem SOAP, což je stále převažující protokol ve světě webových služeb. Specifikace protokolu SAML je strukturovaně rozdělena do čtyř hlavních vzájemně vnořených oblastí. Jádro tvoří definice zprávy označovaná jako Assertion[8]. Tato zpráva obsahuje prohlášení o nějaké skutečnosti jako například o ověření uživatele nebo o některých jeho dalších údajích. Druhou oblastí uvedenou ve specifikaci jsou definice protokolů, které určují, jaký způsobem se zprávy předávají mezi jednotlivými účastníky procesu. Kromě autentizačního procesu je totiž možné s využitím protokolu SAML řešit i další procesy (například jednotné odhlášení). Jednotlivé protokoly určují pořadí a formáty zpráv. Třetí oblast obsahuje definice transportních mechanismů[9]. Již bylo zmíněno, že pro transport se používají protokoly SOAP a HTTP, v rámci těchto řešení je však několik další podvariant, které přinášejí specifické možnosti. Poslední, čtvrtá oblast se týká takzvaných profilů, tedy specifických kombinací vlastností z předchozích tří oblastí propojených za účelem vyřešení konkrétního problému[10]. SAML také nabízí celou řadu možností pro definici rozšíření a postupně vznikají nové profily. Vzhledem k existenci celé řady různých profilů, které je možné ze základních prvků protokolu SAML poskládat, neexistuje jedno univerzální schéma komunikace jednotlivých účastníků. Z pohledu hlavního autentizačního procesu se ovšem komunikace neliší od obecného schématu popsaného v úvodní kapitole. Protokol SAML 2.0 se velice rychle rozšířil zejména v oblasti velkých společností, a stal se tak de facto symbolem pro distribuovanou autentizaci. Obdobně populární je tento protokol i v akademické a státní sféře. V rámci již zmiňovaného projektu STORK proběhl v roce 2011 průzkum, který ukázal že devět evropských zemí pro svůj interní systém národní elektronické identity používá nebo plánuje použít právě SAML[11].

3.4 OpenID V roce 2005, tedy ve stejném roce, ve kterém vznikla poslední verze protokolu SAML 2.0, vytvořil americký programátor Brad Fitzpatrick první verzi protokolu OpenID. Cílem jeho snažení bylo nabídnout jednoduchý systém jednotného přihlašování pro několik blogovacích platforem. A tak zatímco se implementace protokolu SAML vyznačuje určitou 23

komplexitou spočívající v generování a zpracovávaní podepsaných XML dokumentů, disponoval protokol OpenID od začátku mnohem jednodušším přístupem. První verze protokolu z května 2005 se již během jednoho roku stala značně populární. Přesně rok poté, v květnu 2006, byly některé první nedostatky odstraněny ve verzi 1.1. Zároveň ve stejné době vznikl protokol Yadis pro dynamické zjišťování informací o zdrojích na internetu. V této době také vzniká organizace OpenID Foundation, která si klade za cíl standardizaci dalších verzí. Poslední verze OpenID protokolu, verze 2.0, byla publikována v prosinci 2007[12]. Tato verze integruje protokol Yadis pro zjišťování informací o účastnících autentizačního procesu a zároveň přidává specifikaci rozšíření protokolu pro výměnu údajů o identitě uživatele. Na základě kritických reakcí vzniklo v prosinci 2008 ještě jedno klíčové rozšíření umožňující službě specifikovat požadovanou úroveň ověření uživatele, typicky takovou, která je odolná proti phishingovým útokům. Přestože protokol OpenID vznikl v prostředí blogovacích služeb, brzy se o něj začaly zajímat velké firmy jako Google, Microsoft nebo Yahoo, které se staly členy OpenID Foundation. V roce 2011 začal používat OpenID také PayPal. V současné době většina těchto služeb přechází na OpenID Connect.

3.5 Mozilla BrowserID V roce 2011 představila společnost Mozilla nový protokol nazvaný BrowserID. Ze strany vývojářů populárního webového prohlížeče se jednalo o snahu poskytnout uživatelům ještě větší komfort při pohybu na internetu. Protokol BrowserID se rozhodl vyřešit dva základní problémy, které podle jeho autorů trápí internetové uživatele při používání autentizačních protokolů jako OpenID[13]. První deklarovaná výhoda byla použití e-mailu jako identifikátoru uživatele. Pro běžné uživatele je e-mailová adresa, se kterou se dostávají do styku denně, mnohem lepší než webová adresa použitá u OpenID. Druhou výhodou mělo být vyřešení problému, že poskytovatele identit ví o každém přihlášení k nějaké službě, při němž se použije distribuovaná autentizace. V BrowserID je poskytovatelem identit správce e-mailové adresy. Ten na počátku stvrdí svým podpisem, že uživateli patří konkrétní e-mailová

24

adresa, a uživatel se tímto tvrzením prokazuje službě. Služba pak může ověřit platnost tohoto tvrzení pomocí obecného certifikátu získaného přímo od správce e-mailu. Třetí výhoda spočívala v tom, že kryptografický materiál používaný pro komunikaci se službou bude mít uživatel uložen ve svém prohlížeči, a tedy nebude nutné nikam psát hesla. Základní vlastnosti protokolu jsou zřejmé z následujícího schématu:

Obrázek 3: Schéma komunikace protokolu BrowserID 1. Uživatel nejprve musí získat ověření svého e-mailu od správce e-mailu. Proto se přihlásí do systému svého správce e-mailu svým uživatelským jménem a heslem. 2. V prohlížeči uživatele se vygeneruje privátní klíč, a odpovídající veřejný klíč spolu s e-mailovou adresou podepíše správce e-mailu, čímž garantuje vazbu uživatele na tuto e-mailovou adresu, čímž vytvoří certifikát. 3. Při přístupu na službu předá uživatel službě e-mailovou adresu a certifikát, vše podepsané svým privátním klíčem. 4. Pokud služba nemá veřejný klíč správce e-mailu, požádá o něj na rozhraní odvozeném z emailové adresy. 5. Správce e-mailu předá službě veřejnou část klíče, ta si tuto informaci může po nějaký čas udržovat, a tedy tato komunikace u dalších přihlášení neproběhne. 6. Služba ověří certifikát na základě veřejného klíče správce e-mailu a umožní uživateli přístup.

25

Celá transakce víceméně kopíruje standardní model PKI, ve kterém ovšem roli certifikační autority plní správce e-mailu. Přestože se jedná o zajímavé řešení, má aktuálně hned několik nedostatků. V první řadě by ho museli implementovat provozovatelé e-mailových služeb, což se bohužel ani po třech letech nepovedlo zajistit. Dočasně tedy plní tuto roli služba provozovaná společností Mozilla, která ověřuje vlastnictví e-mailu zasláním odkazu na e-mailovou adresu. Po odkliknutí na zaslaný odkaz dojde ke stejnému procesu jako v případě očekávaného přihlášení ke správci e-mailu. Obdobně se zatím nepodařilo zajistit implementaci potřebného kódu přímo ve webových prohlížečích, a tak je část týkající se generování potvrzení o vlastnictví e-mailu prováděna přes další službu společnosti Mozilla. V roce 2012 došlo k přejmenování projektu včetně navazujících (a původně dočasných) služeb na Mozilla Persona a BrowserID zůstal název pro vlastní protokol. V roce 2014 společnost Mozilla překvapivě ukončila podporu celého projektu a předala ho komunitě.

3.6 OAuth a OpenID Connect V průběhu implementace OpenID do populární služby Twitter v roce 2006 narazil vývojář Blane Cook na některé chybějící vlastnosti tohoto protokolu, a to zejména na možnost delegace přístupových oprávnění k nějakým chráněným údajům. Na základě diskuzí s Davidem Recordonem, autorem OpenID, a dalšími vývojáři vznikla idea nového protokolu, který byl pojmenován OAuth. Protokol OAuth není autentizační protokol, ale spíše autorizační protokol. Jeho cílem není přihlášení uživatele ke službě A s využitím přihlašovacích údajů služby B, nýbrž umožnění službě A, aby mohla sama přistupovat ke službě B, jako kdyby to dělal uživatel sám, ale bez předání svých přihlašovacích údajů službě A. Například uživatel si udržuje nějaké fotky ve službě Facebook a chce umožnit službě provádějící tisk fotek, aby si zvolené fotky sama z Facebooku stáhla, aniž by jí uživatel předal přihlašovací údaje. Toto přesně řeší protokol OAuth tím, že Facebook po přihlášení uživatele a potvrzení přístupu vystaví takzvaný Access token, který se předá službě. Ta se pak již připojuje k Facebooku přímo s přiloženým Access tokenem, který ji umožní získat potřebná data.

26

Tento nový protokol se velice rychle stal populární ve světě sociálních sítí, kde je princip sdílení informací mezi službami klíčovou vlastností. OAuth brzy implementoval Facebook, Twitter, LinkedIn, Google a další. První draft byl publikován v roce 2008 a tato verze byla v roce 2010 standardizována v IETF jako RFC 5489[14]. Poté se začalo v IETF pracovat na verzi 2.0, která vyšla jako RFC 6749 v roce 2012[15]. Vznik nové verze provázeli bouřlivé diskuze, protože OAuth 2.0 je spíš stavebnice, na které je možné pomocí rozšíření budovat nové protokoly. Navíc tato verze opouští povinné šifrování zpráv a nechává bezpečnost komunikace mezi účastníky na transportním protokolu (tedy spoléhá na TLS) . Toto směrování přímo rozlítilo některé původní autory verze 1.0 a od nové verze se distancovali. Již bylo zmíněno, že OAuth není autentizační protokol. Přesto ho všechny služby, které ho nasadily, začaly pro autentizaci používat. Za tímto účelem si každá služba vymyslela nějaké proprietární rozšíření, které přidává k jednoduchému protokolu OAuth autentizační vlastnosti. Díku tomu přirozeně neexistuje žádná kompatibilita a služba, která chce využívat přihlášení přes tyto poskytovatele, musí implementovat každé řešení zvlášť. Různí vývojáři se dlouho snažili propojit to nejlepší z protokolů OpenID a OAuth, čímž postupně vznikaly různé hybridní varianty. Nakonec se podařilo vynakládané úsilí koncentrovat a pod hlavičkou standardizační organizace OpenID Foundation vznikl v roce 2010 prototyp nového protokolu pojmenovaný OpenID Connect[16]. V průběhu dalších několika let se tento prototyp upravoval a finální standard byl organizací schválen a publikován v únoru 2014. OpenID Connect je tedy možné definovat jako tenkou autentizační vrstvu vybudovanou nad OAuth 2.0. Návrh se částečně vrací k některým vlastnostem, které se objevily již u protokolu SAML, nicméně v současnosti se místo zpráv SOAP používá moderní přístup REST a jazyk XML pro definování formátu zpráv byl nahrazen jazykem JSON. Z pohledu srovnání OpenID Connect a jeho předchůdce OpenID 2.0 jsou, kromě zmíněného opuštění jazyka XML, patrné některé další zásadní rozdíly. Přestože OpenID 2.0 používal pro podepisování zpráv poměrně jednoduchý mechanismus, stávala se jeho implementace zdrojem nekompatibility. V OpenID Connect se využívá standardu pro obecné podepisování JSON objektů. Dále je (právě díky použití OAuth 2.0) nový protokol 27

na rozdíl od starého mnohem vstřícnější k mobilním technologiím. V neposlední řadě také OpenID Connect umožňuje uživatelům používat e-mailové adresy jako uživatelská jména. Protokol OpenID Connect je poměrně mladý, a tak zatím není možné příliš hodnotit jeho vlastnosti. Z velkých firem ho jako první implementoval do svých systémů Google, a další velké společnosti jako třeba Microsoft na jeho implementaci pracují.

28

4 Stavební prvky autentizačních protokolů Protože všechny autentizační protokoly vznikly za společným cílem, tzn. umožnit uživateli přihlásit se k nějaké službě, mají v jádru celou řadu společných prvků. Jednotlivé protokoly ovšem vznikaly v různé době a s různými původními cíli, což se projevilo na variantách jakými, jsou tyto společné prvky řešeny. Doba vzniku se velice zřetelně promítá například v použitých technologiích, které se v dané době jevily jako jasná volba, přestože třeba dnes již zdaleka tak populární nejsou. Takovým příkladem může být přechod od využití jazyka XML v protokolech SAML a OpenID 2.0 k jazyku JSON v protokolu OpenID Connect. Obdobně různé původní cíle spočívající například v důrazu na některou konkrétní vlastnost protokolu a potlačení některé jiné nebo v omezení na konkrétní skupinu uživatelů nebo služeb znamenají, že některé stavební prvky jsou v některých protokolech potlačené. V této kapitole budou identifikovány základní stavební prvky autentizačních protokolů a následně detailně analyzovány v jednotlivých podkapitolách s důrazem na jejich konkrétní implementaci v popisovaných protokolech. Základními stavebními prvky jsou: •

Identita uživatele. Výsledkem celého procesu autentizace je, že systém, ke kterému se uživatel přihlašuje, zná jeho identitu a může mu poskytnout požadovanou

službu.

Typicky

je

uživatel

označen

jednoznačným

identifikátorem, jehož vlastnictví v průběhu autentizace prokazuje. •

Potvrzené prohlášení o uživatelově identitě. Samo o sobě by prohlášení uživatele o jeho identitě nebylo dostačující. Služba ovšem důvěřuje poskytovateli identit, že identitu uživatele prověřil. Tato důvěra se přenáší formou potvrzeného prohlášení, které má možnost služba ověřit

•

Počáteční nastavení důvěry. Aby mohla služba ověřit, že prohlášení o identitě pochází od správného poskytovatele, je nutné, aby si služba předem zjistila informace, které jí toto ověření umožní. Tyto údaje je buď možné staticky nastavit, nebo je zjišťovat dynamicky za běhu.

29

•

Předání dalších údajů. Kromě identifikátoru uživatele může služba požadovat předání dalších doplňujících údajů souvisejících s jeho identitou jako e-mailu, telefonu nebo adresy.

4.1 Identita uživatele Elektronická identita je komplexní pojem přesahující rozsah této práce. Vztah elektronické identity a distribuované autentizace poměrně výstižně shrnul Kim Cameron ve svém článku The Laws of Identity[17]. V této práci je identita chápána úzce jako jednoznačný identifikátor sloužící ke ztotožnění uživatele s nějakou evidencí v informačním systému. Tento identifikátor je pro účely autentizace sdílený mezi službou a poskytovatelem identit. U poskytovatele identit je tento identifikátor spojen s autentizačními údaji, jejichž znalostí prokazuje uživatel vlastnictví dané identity. Z důvodů ochrany soukromí bývá někdy požadováno, aby pro každou službu existovala oddělená identita, a nebylo tedy možné propojením informací z více systémů ztotožnit chování uživatele u více služeb. Tomuto principu se také říká anonymní nebo soukromá identita. Kerberos V protokolu Kerberos se za identitu uživatele (ale i služby) považuje řetězec označovaný jako principal, který má obecný tvar část1/část2/.../částN@REALM. REALM je řetězec nejčastěji ve tvaru doménového jména označující oblast služeb sdílejících jeden autentizační server. Počet částí je obvykle dva, přičemž první část je uživatelské jméno a druhá část doplňující označení role. Jinak ovšem tento identifikátor neposkytuje žádné rozšiřující možnosti. SAML 2.0 V protokolu SAML je identita uživatele účastnícího se autentizačního procesu označovaná jako subjekt. Tento subjekt je ovšem obecně volitelná položka, takže například může nastat situace, že výsledkem autentizačního procesu není zjištění konkrétní identity, ale pouze nějakého údaje o této identitě. 30

Subjekt je identifikován pomocí identifikátoru NameID, přičemž tento identifikátor má celou řadu vlastností. Jaké vlastnosti bude služba po identifikátoru požadovat, může služba předat poskytovateli identit uvnitř autentizačního požadavku. V první řadě má tento identifikátor NameID jeden z následujících typů: e-mailová adresa, subjekt z X.509, doménové jméno Windows, Kerberos principal, identifikátor entity a anonymní trvalý nebo dočasný identifikátor. První čtyři identifikátory vycházejí z identifikace subjektu v jiných protokolech. Identifikátor entity se používá, pokud je subjektem nějaký poskytovatel služby nebo poskytovatel identit. identifikátor NameID může být navíc předán v zašifrované podobě. Zajímavé možnosti poskytují anonymní trvalý a dočasný identifikátor, ve kterých poskytovatel služby vytvoří k identitě pseudonáhodný kód, ze kterého se není možné dozvědět žádné další informace. U tohoto identifikátoru je navíc možné uvést pro jakou službu nebo skupinu služeb je vytvořen (vznikne párový identifikátor). Dočasný identifikátor typicky není spojen s žádnou evidencí u služby a existuje pouze v rámci jednoho autentizačního procesu. Někdy spolu potřebují služby komunikovat o nějaké konkrétní identitě, což je v případě, kdy nepatří do skupiny sdílející stejný identifikátor, nemožné. Pro tyto případy existuje v SAML speciální mapovací protokol, který umožňuje požádat pokaždé poskytovatele identit o nový identifikátor, u kterého budou obě strany vědět o koho se jedná bez toho, že by si navzájem prozradily své soukromé identifikátory. Pokud nastane situace, že poskytovatel služby ruší nebo mění nějaký jím vygenerovaný identifikátor, může rozeslat všem poskytovatelům služeb o této změně zprávu. OpenID 2.0 Autoři protokolu OpenID se nejspíš rozhodli celou situaci kolem identifikátoru identity zjednodušit a navrhli, aby identifikátorem byla webová adresa (URL). V průběhu standardizace verze 2.0 byla přidána ještě možnost, aby takovým identifikátorem byl také obecný XRI (eXtensible Resource Identifier). Proces standardizace celé komplexní infrastruktury kolem XRI na půdě OASIS však nebyl úspěšný, a tak se tento typ identifikátoru prakticky nepoužívá. 31

Použití URL jako identifikátoru v OpenID přineslo jednu zásadní novinku, a to možnosti dynamicky zjistit z této URL poskytovatele identit, na kterého je nutné uživatele v rámci autentizačního procesu přesměrovat. Na rozdíl od světa protokolu SAML, kde je služba obvykle staticky svázána s konkrétní skupinou poskytovatelů identit, ze které si musí uživatel vybrat, u OpenID je možné u služby nabídnout napojení na libovolného poskytovatele identit. Tento proces dynamického zjišťování informací z poskytnutého identifikátoru označovaný jako Discovery (objevování) se posléze stal předmětem samostatného zkoumání, ze kterého vznikla celá řada nových standardů. U OpenID navíc tento proces umožňuje se zachováním jednoho identifikátoru měnit svého poskytovatele identit. Bohužel však toto řešení brzy ukázalo svoje zásadní nevýhody. Běžný uživatel, který nedisponuje schopností provozovat jmenný a webový server, si těžko pamatuje svůj identifikátor ve formě URL přiděleného poskytovatelem identit. Tato situace vedla k tomu, že služby podporující OpenID se stejně nakonec vrátily k tomu, že uživateli nabídly seznam podporovaných poskytovatelů identit, a možnost dynamického zjišťování zůstala pouze pro zkušené uživatele. OpenID také nabízí pro poskytovatele identit možnost recyklovat identifikátory, tedy po skončení platností nějaké identity přidělit stejný identifikátor jiné identitě. To se provádí připojením unikátního řetězce do fragmentové části URL (za znak #). Služba musí tedy identifikovat uživatele podle celého URL, přestože uživatelé mohou používat v komunikaci zkrácené URL. Tato vlastnost také přináší bezpečností riziko pro implementátory služeb, neboť opomenutí fragmentu může znamenat umožnění neoprávněného přístupu. Z pohledu anonymity bohužel protokol OpenID 2.0 nenabízí řádnou podporu párového identifikátoru určeného pouze konkrétní službě. Mozilla BrowserID Jednou z hlavních výhod deklarovaných návrháři BrowserID bylo použití emailu jako identifikátoru pro identitu. Výhodou je fakt, že uživatelé svůj e-mail znají. Navíc u většiny služeb je e-mail de facto autentizační prvek, neboť řešení situací jako zapomenuté heslo

32

stejně spočívá v zaslání jednorázového hesla nebo odkazu na obnovení hesla na uloženou e-mailovou adresu. Na druhou stranu existují i nevýhody. Dokud nebudou BrowserID certifikáty vydávat přímo správci e-mailů, existuje riziko odchycení e-mailové komunikace při ověřování e-mailu a kompromitace přístupů. Navíc e-mail nenabízí žádnou možnost ochrany proti recyklaci e-mailových adres a ani možnost specifikaci různých identifikátorů pro různé služby, ke kterým uživatel přistupuje. OpenID Connect V OpenID Connect je informace o identitě svým způsobem rozdělena na dvě části. První je způsob, jakým způsobem prezentuje uživatel svojí identitu službě. Zde je opět klíčové, aby služba z této poskytnuté informace dokázala zjistit, kdo je poskytovatelem identit, který jí má prokázat, že uživatel je ten, za koho se vydává. Druhou část tvoří vlastní identifikátor, který služba obdrží od poskytovatele identit a který si uloží do své evidence nebo podle nějž vyhledá již existujícího uživatele. První část je stejně jako v předchozích verzích OpenID volitelná, protože uživatel může službě předat odkaz na poskytovatele identit přímo, nebo (pravděpodobněji) služba nabídne uživateli výběr z poskytovatelů, které zná. Pokud však chce uživatel této možnosti využít, OpenID Connect nabízí několik možností, a to například e-mailovou adresu nebo webovou adresu. Pro zjištění adresy rozhraní poskytovatele identit je následně využit také nedávno standardizovaný protokol Webfinger[18] umožňující z libovolného identifikátoru, který je možné upravit na doménové jméno, zjišťovat informace o službách souvisejících s tímto identifikátorem. Je ovšem nutné, aby správce takové domény tuto zjišťovací službu v té doméně provozoval, což bude vyžadovat dodatečné úsilí. Z pohledu toho, jak identitu prezentuje službě poskytovatel identity, došlo k maximálnímu možnému zjednodušení. V rámci autentizačního procesu předá poskytovatel identit službě dvojici identifikátor poskytovatele služeb (řetězec ve formátu URL) a identifikátor identity u tohoto poskytovatele (náhodný unikátní řetězec). Tuto dvojici pak služba použije pro spárování identity s vlastní evidencí. Jsou podporovány dva typy identifikátorů, a to veřejný a unikátní pro danou službu. Služba si může vyžádat typ identifikátoru při zahájení autentizačního procesu. 33

4.2 Potvrzené prohlášení o uživatelově identitě Klíčovou vlastností procesu distribuované autentizace je předání informace o identitě uživatele od poskytovatele identit ke službě, a to takovým způsobem, aby služba mohla informaci o autentizaci uživatele ověřit a důvěřovat jí. Ve všech protokolech je toto řešeno s využitím kryptografie. Poskytovatel identity, který ověří uživatelovu totožnost, sestaví zprávu obsahující prohlášení o uživatelovo identitě a připojí k ní informaci, ze které příjemce zprávy, tedy poskytovatel služby, jednoznačně odvodí, že zpráva pochází od poskytovatele služeb. Toto lze zajistit technikami šifrování nebo podepisování. Způsob, jakým se informace o ověření identity dostane od poskytovatele identit ke službě, se v různých protokolech liší. Pro dva hlavní způsoby komunikace se vžilo označení „front channel“ a „back channel“, nebo také nepřímá a přímá komunikace. Nepřímá komunikace (neboli „front channel“) se vyznačuje tím, že služba a poskytovatel identity nekomunikují přímo, ale prostřednictvím uživatele. Uživatel převezme zprávu od poskytovatele a předá ji službě. V prostředí webu se toto obvykle řeší přesměrováním, které automaticky provede prohlížeč. Nevýhoda této komunikace je, že informace je vystavena uživateli což v závislosti na obsahu zprávy může představovat určité riziko. Přímá komunikace (neboli „back channel“) naopak, jak i její název napovídá, spočívá v přímé výměně zpráv mezi službou a poskytovatelem identity. Někdy je užitečné oba dva způsoby komunikace kombinovat a rozdělit zprávu na část předávanou nepřímo a část předávanou přímo. Kerberos V protokolu Kerberos je proces důvěryhodného zprostředkování informace o uživatelově identitě postaven na symetrickém šifrování. Služba a autentizační server spolu sdílejí tajný klíč, a tedy pokud server zašifruje zprávu tímto klíčem, může tuto zprávu rozšifrovat pouze služba. Obsahem této zašifrované zprávy, tzv. tiketu, je informace o identitě uživatele ve formě řetězce označovaného jako principal doplněná o jednorázový klíč pro toto sezení, který zná jenom uživatel. Uživatel tedy službě předá tiket a ještě jednou svou identitu zašifrovanou tímto klíčem sezení. Služba nejprve rozšifruje tiket, vyzvedne z něj klíč sezení a s tímto klíčem rozšifruje druhou část zprávy. Pokud odpovídá identita uživatele 34

v tiketu a ve druhé části zprávy, může si být služba jistá, že komunikuje s daným uživatelem. Z pohledu typu komunikace v protokolu Kerberos nikdy nedochází k přímé komunikace mezi službou a autentizačním serverem. Informaci o ověření uživatele ve formě tiketu nejprve vyzvedne uživatel od autorizačního serveru nebo tiketové služby a pak jí předá konkrétní službě. SAML 2.0 Klíčovým artefaktem autentizačního procesu v protokolu SAML je XML objekt Assertion (ujištění) obsahující prohlášení poskytovatele identit o nějaké skutečnosti. Uvnitř tohoto objektu mohou být tři typy informací, a to prohlášení o ověření identity, o dalších údajích identity a o oprávněních identity. Celý objekt je buď podepsán, nebo může být podepsaná zpráva, která ho nese. Služba, která tento objekt obdrží, musí mít k dispozici klíč, aby mohla ověřit pravost doručené informace. Způsobů, jakými se předá prohlášení od poskytovatele identit ke službě, definuje protokol SAML hned několik. Jsou to HTTP Redirect, HTTP POST a HTTP Artifact. V prvních dvou variantách se zpráva předává nepřímo přes uživatelův prohlížeč. Ve třetí variantě, HTTP Artifact, se přes prohlížeč předá pouze identifikátor zprávy a druhá strana si vlastní zprávu musí získat přímým dotazem. Ve variantě HTTP Redirect se serializovaná zpráva předána jako parametr HTTP GET URL vráceného do prohlížeče uživatele v odpovědi s požadavkem na přesměrování. V případě HTTP POST obsahuje odpověď HTML formulář obsahující skrytou položku s hodnotou serializované zprávy. OpenID 2.0 Zjednodušení provázející architekturu protokolu OpenID se promítá i do formátu zpráv zajišťujících předání informací o ověření uživatele. Zprávy jsou tvořeny jednoduchými seznamy dvojic klíč a hodnota. K dispozici jsou dva způsoby kódování zpráv, a to textový formát, kde jsou na každém řádku klíč a hodnota odděleny dvojtečkou, a HTTP formát, ve kterém se používá standardní kódování parametrů HTTP. I v tomto protokolu se využívají přímý i nepřímý způsob komunikace. Přímá komunikace směřující od služby k poskytovateli identity slouží buď na počátku 35

k ustanovení asociace, tedy k výměně klíče, kterým budou podepisovány zprávy, anebo alternativně k ověření každého podpisu každé zprávy. Podpisy jsou vypočítávány velice jednoduše jako hash textového formátu zprávy. Aby nebylo možné zopakovat již jednou zaslanou zprávu, obsahuje každá zpráva unikátní řetězec označovaný jako nonce. Ten si musí příjemce zprávy uložit a nesmí zpracovat zprávu, která by obsahovala stejný řetězec. Mozilla BrowserID V BrowserID je proces ověřování informací postaven na vlastnostech asymetrického šifrování a infrastruktury veřejných klíčů (PKI – public key infrastructure). Uživatel jakožto vlastník e-mailu drží soukromý klíč k certifikátu, který mu o tomto vlastnictví vystavila certifikační autorita v podobě správce e-mailu. V okamžiku přihlášení ke službě vytvoří prohlížeč uživatele jednoduchý objekt v jazyce JavaScript, který se skládá ze dvou částí. První část obsahuje doménové jméno služby a časovou značku platnosti ověření a je podepsaná privátním klíčem uživatele. Druhá obsahuje certifikát od správce e-mailu, a je tedy podepsaná jeho privátním klíčem. Dokud je tento certifikát platný, může ho uživatel používat bez nutnosti znovu kontaktovat správce e-mailu. Naopak služba pro ověření potřebuje veřejnou část klíče správce emailu. Pokud ho nemá k dispozici, BrowserID specifikuje, jakým způsobem ho může získat dotazem na pevnou URL, kterou očekává v doméně získané z e-mailové adresy. Pokud služba veřejnou část klíče má, může ověřovat zprávy bez nutnosti komunikace se správcem e-mailu. OpenID Connect Klíčový objekt zajišťující přenos informace o ověření uživatele se v OpenID Connect nazývá ID Token. Ten je speciální formou objektu JSON Web Token (JWT), což je sada informací reprezentovaná v jazyku JSON a zakódovaná tak, aby ji bylo možné jednoduše přenášet v HTTP komunikaci, a zároveň obsahující digitální podpis. Celá sada standardů definujících, jak funguje podepisování a šifrování nad objekty JSON, je teprve ve stádiu finální standardizace v IETF, přesto už se nepředpokládá, že by u nich došlo k nějaké změně, a existuje celá řada implementací. Obsahem objektu ID Token je kompletní sada informací: kdo ho vystavil, identifikátor uživatele, komu je určen, kdy proběhlo poslední ověření, jakým způsobem toto ověření proběhlo a další. Služba musí všechny tyto parametry vyhodnotit předtím, než se rozhodne jim důvěřovat.

36

Způsob výměny informací mezi službou a poskytovatelem identit je v OpenID Connect víceméně delegován na fungování protokolu OAuth. Ten nabízí hned několik možností, kdy například poskytovatel identit nepřímo předá službě takzvaný autentizační kód a služba pak přímým dotazem zjistí ID Token od poskytovatele identit; nebo je ID Token předán službě nepřímo přes uživatele. V případě nepřímé komunikace musí navíc služba ověřit podpisy ID Tokenu na základě informací o klíčích získaných od poskytovatele identit.

4.3 Počáteční nastavení důvěry Služba, ke které se uživatel přihlašuje, a poskytovatel identity si musí vzájemně důvěřovat. Služba musí mít jistotu, že informace o ověření identity uživatele, kterou dostává, není podvržená a poskytovatel identity musí mít jistotu, že informace o uživateli předává opravdu té správné službě. Před vlastní transakcí je tedy nutné, aby se tyto dvě strany dohodly, jakým způsobem nastaví vzájemnou důvěru a jakým způsobem budou zprávy od sebe ověřovat. Informace, které o sobě tyto dvě komponenty potřebují vědět, mohou být jednak adresy, na kterých je možné spolu komunikovat, jednak vzájemné autentizační prostředky.

Tyto

informace

mohou

být

dopředu

staticky

nastavené

nějakým

administrátorem nebo je možné, že si je obě strany dynamicky zjistí až v okamžiku, kdy spolu chtějí začít komunikovat. Kerberos Jakožto nejstarší protokol má Kerberos jenom omezené možnosti týkající se nastavení důvěry. Administrátor musí pro každou službu vygenerovat klíč a tento klíč uložit jak do databáze autentizačního serveru, tak do konfigurace služby. SAML 2.0 Pro popis důležitých parametrů a vlastností zveřejňují poskytovatel služby a poskytovatel identit soubor označovaný v terminologii SAML jako metadata[19]. V tomto souboru jsou uvedeny adresy jednotlivých rozhraní, na kterých se očekává komunikace, dále kryptografický materiál sloužící k ověření zpráv od tohoto účastníka, podporované způsoby přenosu zpráv a další. Podstatné je, že tato metadata si obě strany musí dopředu

37

nějak vyměnit. Nutnost nakonfigurovat obě strany před začátkem autentizačního procesu způsobuje, že protokolu SAML chybí dynamické vlastnosti typické pro OpenID. Obdobně je to s okamžikem, kdy služba potřebuje zjistit, jaký je vlastně poskytovatel identit pro uživatele, se kterým komunikuje. Specifikace v tomto směru nechává řešení na implementaci. Určitou snahou tento problém vyřešit je jeden z profilů standardu nazvaného Identity Provider Discovery. Ten spočívá ve specifikaci cookie v prohlížeči uživatele, ve které jsou uloženy adresy podporovaných poskytovatelů identit. To ovšem vyžaduje, aby služba i poskytovatel sdíleli definované doménové jméno, a to není jednoduché zajistit. V roce 2008 byla sada specifikací SAML doplněna o nový dokument, který se právě věnuje zjišťování poskytovatele identit[20]. Tento dokument definuje alternativní přístupu, ve kterém je však nutné vložit do komunikace novou komponentu, která bude informace o poskytovatelích identit udržovat. OpenID 2.0 Pro zjištění důležitých parametrů o účastnících autentizačního procesu se v první fází používá proces popsaný již v sekci o identitě. Z identity URL zjistí služba potřebnou adresu rozhraní poskytovatele služby a přímým dotazem může vytvořit asociaci, která slouží k ověřování zpráv. Služba se v protokolu OpenID identifikuje pomocí řetězce označovaného jako realm (oblast). Realm je opět URL, ze kterého může poskytovatel služby zjistit umístění souboru ve formátu XRDS (eXtensible Resource Descriptor Sequence). Tento soubor obsahuje hlavně návratovou adresu služby. Pokud návratová adresa není obsažena přímo v požadavku na autentizaci, použije se adresa z XRDS souboru. Pokud obsažena je, musí patřit do doménového podstromu adresy ze souboru. Mozilla BrowserID V mnoha ohledech je BrowserID stále spíše koncept nebo prototyp a některé prvky architektury jsou tedy popisovány podle toho, jak by měly vypadat, pokud by poskytovatelé služeb začali tento protokol brát vážně. Protokol například určuje, že zjištění informací o poskytovateli identity z e-mailu se bude provádět přes princip popsaný v RFC 5785 a označovaný jako „well-known“[21]. Tento mechanismus popisuje, že v doméně (například v tomto případě v té části, která je v e-mailu za znakem @) musí existovat 38

adresář /.well-known/), který obsahuje podadresáře pro jednotlivé služby. Seznam služeb by měl být udržován v celosvětově platném registru, aby nedocházelo ke kolizi identifikátorů. Nicméně registrace konkrétního identifikátoru služby pro BrowserID zatím neproběhla. Tímto způsobem by služba měla zjistit, kde získat veřejný klíč pro kontrolu platnosti prohlášení o vlastnictví e-mailu, a zároveň prohlížeč by stejným způsobem měl zjistit, kam přesměrovat uživatele na prvotní vystavení nového certifikátu. Protože ovšem v tuto chvíli neexistují správci e-mailů, kteří by tuto roli plnili, je v obou případech uživatel směrován na stránky projektu, které slouží jako dočasný poskytovatel potřebných informací. OpenID Connect Podobně jako u OpenID 2.0 si zjistí služba většinu informací o poskytovateli identit zjišťovacím procesem s využitím protokolu Webfinger, popsaným již v části o identitě[22]. Pro zajištění vzájemné důvěry je ovšem nutné, aby poskytovatel identit také důvěřoval službě se kterou komunikuje. Při přímé komunikaci s poskytovatelem identit se služba identifikuje vlastním klientským identifikátorem a heslem. Tento identifikátor služba získá při procesu registrace u poskytovatele identit. V průběhu této registrace také musí služba uvést návratovou adresu pro autentizační proces. Dále je možné v tento okamžik uvést celou řadu přednastavených hodnot pro autentizační proces místo toho, aby je služba předávala v parametrech každého dotazu. Je zřejmé, že tento přístup na první pohled boří představu dynamické služby, která může komunikovat s libovolným poskytovatelem identit, jak tomu bylo u OpenID 2.0. Tento problém řeší specifikace dynamické registrace služeb. Tato specifikace existuje jako součást OpenID Connect a definuje rozhraní poskytovatele identit, na které je možné zaslat žádost o registraci nové služby včetně všech jejích parametrů[23].

4.4 Předání dalších údajů Informace o identitě uživatele není zdaleka jediný údaj, který si mezi sebou mohou služba a poskytovatel identit vyměnit. Poměrně podstatným údajem souvisejícím s autentizací je způsob, jakým byl uživatel poskytovatelem identit ověřen a kdy se tak stalo. Na základě 39

těchto údajů pak může služba měnit své chování. Služba si někdy navíc může některý z těchto údajů vynutit – tedy může například vyžádat, aby poskytovatel identit ověřil uživatele konkrétním způsobem, nebo aby ověřil uživatele znovu, pokud tak neučinil v požadovaném období. Kromě údajů souvisejících s autentizací nabízejí některé autentizační protokoly i možnost předání celé řady dalších údajů, které poskytovatel identit o uživateli eviduje. Služba má obvykle možnost uvést v žádosti o přihlášení, jaké údaje pro své fungování potřebuje, a roztřídit je na povinné a nepovinné. Přestože to není možné vynutit protokolem, důrazně se doporučuje, aby k předání údajů dal přihlášený uživatel jasný souhlas. Všechny zmíněné dodatečné údaje podléhají stejnému režimu jako samotná identita a musí existovat způsob, jak služba ověří, zda údaje pocházejí od poskytovatele identit a zda během komunikace nedošlo manipulaci s nimi. Kerberos V protokolu Kerberos žádné tyto vlastnosti k dispozici nejsou. Asi nejvíce se těmto vlastnostem blíží to, že tikety zasílané službě mohou mít příznak „Initial“. Tento příznak označuje, že tiket vznikl od autentizačního serveru, a tudíž uživatel byl v nedávné době ověřen heslem. Pokud tento příznak tiket nemá, vznikl od tiketové služby na základě již dlouhodobě ověřeného uživatele. Služba si navíc může vyžádat, aby tiket, který jí bude zaslán, měl tento příznak, což znamená, že Kerberos musí znovu provést ověření uživatele heslem. SAML 2.0 V protokolu SAML můžeme najít téměř všechny očekávané rozšiřující možnosti. V první řadě je to velmi bohatá škála různých autentizačních metod definovaná v samostatné specifikaci[24]. Samozřejmě záleží na tom, jaké metody ve finále poskytovatel identit implementuje. Služba si může pohodlně definovat, které autentizační možnosti při přihlášení požaduje. Dále může služba požadovat, aby poskytovatel ověřil uživatele znovu, i když již ověření z dřívějška existuje.

40

Trochu neohrabaně je však v protokolu SAML řešena specifikace dalších údajů o identitě, které by měly být součástí odpovědi od poskytovatele služeb. Seznam požadovaných údajů totiž není součástí autentizačního procesu, ale musí být staticky předkonfigurován v metadatech služby, která o autentizaci žádá. OpenID 2.0 Základní verze protokolu OpenID definuje také schéma, kterým je možné do autentizačního procesu vkládat další parametry v rámci rozšíření. Jedno takové rozšíření označované PAPE (Provider Authentication Policy Extension) umožňuje službě požádat o preferovanou metodu ověření uživatele a maximální možnou dobu od posledního ověření[25]. V odpovědi poskytovatel identity kromě výsledku ověření také zašle použitou metodu ověření a stáří posledního ověření. Další dvě populární rozšíření se týkají přenášení rozšiřujících údajů o identitě. První je označované jako SREG (Simple Registration) a umožňuje předat podmnožinu z definované skupiny devíti údajů jako přezdívka, jméno, e-mail nebo datum narození[26]. Druhé rozšíření označované jako AX (Attribute eXchange) umožňuje sofistikovanější předávání údajů, ve kterém je možné definovat vlastní typy přednášených údajů anebo také používat seznamové hodnoty[27]. Mozilla BrowserID Protokol BrowserID záměrně neimplementuje žádné z možných rozšíření. Získání aktuálních údajů o identitě by totiž vyžadovalo komunikaci s poskytovatelem identit (v tomto případě správcem e-mailu) a narušilo by tím základní výhodu spočívající právě v tom, že služba se s poskytovatelem identit nespojí. To přirozeně staví proti sobě dva principy a je možné, že právě absence těchto vlastností přispívá k malému rozšíření tohoto protokolu. OpenID Connect Jakožto nejnovější protokol v dané oblasti nabízí OpenID Connect prakticky všechny možnosti, které jsou k dispozici. V souladu s principem návrhářů protokolu – jednoduché věci řešit jednoduše a složité věci umožnit – lze některé vlastnosti řešit více způsoby. V první řadě je možné již v prvotní žádosti o autentizaci zaslat poskytovateli identit 41

takzvaný scope (rozsah), obsahující seznam některých základních skupin údajů. Požadované údaje je ovšem možné také předat jako strukturu v parametru claims nebo v parametru request. V nejjednodušší variantě budou hodnoty požadovaných údajů obsahem vráceného objektu ID Token. Další možností je získat údaje doplňujícím dotazem na zvláštní rozhraní poskytovatele identit, které vrací objekt typu UserInfo. Tento objekt může obsahovat buď přímo hodnoty, nebo odkazy na další rozhraní, kde je možné požadované údaje získat.

42

5 Závěr V práci byl popsán koncept distribuované autentizace, který řeší reálné problémy pohybu uživatelů v internetového prostředí. S využitím principu outsourcingu, promítnutého do oblasti ověřování uživatelovy identity, nabízí tento koncept větší komfort a vyšší bezpečí oproti stávajícímu stále převažujícímu vytváření individuálních účtů. Úvodní část práce shrnula klíčové výhody distribuované autentizace a zároveň rizika, která s tímto konceptem souvisí. Hlavními účastníky autentizačního procesu jsou uživatel, který chce využívat nějakou službu, tato služba, ke které se uživatel chce přihlásit, a poskytovatel identit, který zajišťuje ověření uživatelovy identity a který toto ověření předává službě, jež tomuto ověření plně důvěřuje. Stěžejním tématem práce byly internetové autentizační protokoly, tedy standardy definované převážně standardizačními institucemi, které mají zajistit, aby spolu jednotliví účastníci procesu distribuované autentizace dokázali bez problémů komunikovat. Těchto protokolů vzniklo v historii internetu několik a dokonce nové stále vznikají. Práce poskytla přehled těch nejvýznamnějších z nich z pohledu jejich hlavních vlastností. Prvním autentizačním protokolem, který získal širokou popularitu byl Kerberos. Protokol je stále využíván, nepodařilo se mu ovšem proniknout do webového prostředí. Tam se v kontextu rozmachu webových služeb uplatnil protokol SAML, který je stále využíván v akademické, korporátní a vládní sféře. Určitá komplikovanost a zejména nízká dynamičnost tohoto protokolu vedla ke vzniku standardu OpenID. Ten se uplatnil zejména v prostředí menších internetových služeb, blogů a e-shopů. I na tomto protokolu byla identifikována slabá místa, a tak vznikl autorizační protokol OAuth, který byl poté doplněn o autentizační prvky v rámci nového protokolu OpenID Connect. Tomuto hlavnímu proudu podobných autentizačních protokolů se pokusil konkurovat protokol Mozilla BrowserID. Nepodařilo se mu však oslovit širší masu uživatelů a posléze byl společností Mozilla opuštěn. Všechny autentizační protokoly zmíněné v práci sdílí některé stavební prvky. Hlavní analytickou částí práce tedy bylo tyto základní stavební prvky identifikovat, popsat je a ukázat, jak jsou v jednotlivých autentizačních protokolech implementovány. 43

Výsledkem analýzy byla identifikace čtyř základních stavebních prvků, kterými jsou koncept identity, předávaní potvrzeného prohlášení o identitě, prvotní nastavení důvěry a možnost předávání dalších atributů. Koncept identity je základním stavebním prvkem a určuje, jakým způsobem protokol identifikuje uživatele v rámci autentizačního procesu. Poskytovatel identit v průběhu tohoto procesu ověří totožnost uživatele a přidělí mu jeho identitu. O výsledku tohoto ověření identity informuje poskytovatel identit službu, a to takovým způsobem, aby služba mohla informaci důvěřovat. Typicky se tak děje technikami kryptografie, a to šifrováním nebo podepisováním. Aby bylo možné povést toto ověření, je třeba před vlastním autentizačním procesem nastavit důvěru mezi jednotlivými účastníky procesu. Toto je možné staticky administrátorem procesu, nebo dynamicky v průběhu procesu z informací, které o sobě jednotliví účastníci zveřejní. V rámci autentizačního procesu si mohou služba a poskytovatel identit vyměnit více informací než jen identitu ověřeného uživatele. Od služby k poskytovateli identit mohou jít další doplňující požadavky na proces ověření uživatele jako typ ověření a požadované další údaje uživatele, zpět od poskytovatele identit ke službě pak mohou jít hodnoty těch údajů, které služba požadovala a uživatel jejich předání odsouhlasil. Z analýzy vypracované v této práci je zřejmé, že autentizační protokoly procházejí inkrementálním vývojem. Přestože principiálně řeší stejný problém, v implementaci jednotlivých stavebních prvků se liší, přičemž novější verze protokolů staví na zkušenostech svých předchůdců. Zároveň se také na příkladu protokolu Mozilla BrowserID zdá, že pokud se nový protokol příliš odchýlí od hlavního proudu, nepodaří se mu prosadit.

44

6 Seznam použitých zdrojů 1. HEARN, M. : An update on our war against account hijackers [online]. květen 2013 [cit. 2014-08-01] Dostupný z URL: http://googleblog.blogspot.cz/2013/02/an-update-onour-war-against-account.html 2. CZ.NIC : Statistiky služby mojeID [online]. 2014 [cit. 2014-08-01] Dostupný z URL: http://stats.nic.cz/stats/mojeid_contacts_by_verification_level/ 3. KOHL, J. a kol. : The Evolution of the Kerberos Authentication Service [online]. červenec 1992 [cit. 2014-08-01] Dostupný z URL: http://www.isi.edu/div7/publication_files/evolution_of_kerberos.pdf 4. KOHL, J. a kol. : The Kerberos Network Authentication Service (V5) [online]. IETF září 1993 [cit. 2014-08-01] Dostupný z URL: http://tools.ietf.org/html/rfc5849 5. NEUMAN, C. a kol. : The Kerberos Network Authentication Service (V5) [online]. IETF červenec 2005 [cit. 2014-08-01] Dostupný z URL: http://tools.ietf.org/html/rfc4120 6. HODGES, J. a kol. : Towards Kerberizing Web Identity and Services [online]. prosinec 2008 [cit. 2014-08-01] Dostupný z URL: http://www.kerberos.org/software/kerbweb.pdf 7. : History of SAML [online]. říjen 2007 [cit. 2014-08-01] Dostupný z URL: http://saml.xml.org/history 8. CANTOR, S., a kol. : Assertions and Protocols for the OASIS Security Assertion Markup Language (SAML) V2.0 [online]. březen 2005 [cit. 2014-08-01] Dostupný z URL: http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf 9. CANTOR, S., a kol. : Bindings for the OASIS Security Assertion Markup Language (SAML) V2.0 [online]. březen 2005 [cit. 2014-08-01] Dostupný z URL: http://docs.oasisopen.org/security/saml/v2.0/saml-bindings-2.0-os.pdf 10. CANTOR, S., a kol. : Profiles for the the OASIS Security Assertion Markup Language (SAML) V2.0 [online]. březen 2005 [cit. 2014-08-01] Dostupný z URL: http://docs.oasisopen.org/security/saml/v2.0/saml-profiles-2.0-os.pdf 11. IVKOVIC, M., ZWATTENDORFER, B. : STORK Work Item 3.2.1 SAML [online]. říjen 2012 [cit. 2014-08-01] Dostupný z URL: https://www.eid-stork.eu/index.php? option=com_processes&Itemid=&act=streamDocument&did=1383 12. RECORDON, D. a kol. : OpenID Authentication 2.0 [online]. srpen 2007 [cit. 201408-01] Dostupný z URL: http://openid.net/specs/openid-authentication-2_0.html 13. HILAIEL, L. : How BrowserID Works [online]. červenec 2011 [cit. 2014-08-01] Dostupný z URL: http://lloyd.io/how-browserid-works/ 14. HAMMER-LAHAV, E. : The OAuth 1.0 Protocol [online]. duben 2010 [cit. 2014-0801] Dostupný z URL: http://tools.ietf.org/html/rfc5849 15. HARDT, D. a kol. : The OAuth 2.0 Authorization Framework [online]. říjen 2012 [cit. 2014-08-01] Dostupný z URL: http://tools.ietf.org/html/rfc6749 16. SAKIMURA, N., BRADLEY, J., JONES, M. : OpenID Connect Core 1.0 [online]. únor 2014 [cit. 2014-08-01] Dostupný z URL: http://openid.net/specs/openid-connectcore-1_0.html 17. CAMERON, C. : The Laws of Identity [online]. listopad 2005 [cit. 2014-08-01] Dostupný z URL: http://www.identityblog.com/stories/2005/05/13/TheLawsOfIdentity.pdf 18. JONES, J. a kol. : Webfinger [online]. září 2013 [cit. 2014-08-01] Dostupný z URL: http://tools.ietf.org/html/rfc7033 19. CANTOR, S., a kol. : Metadata for the the OASIS Security Assertion Markup Language (SAML) V2.0 [online]. březen 2005 [cit. 2014-08-01] Dostupný z URL: http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf 45

20. CANTOR, S., a kol. : Identity Provider Discovery Service Protocol and Profile [online]. březen 2008 [cit. 2014-08-01] Dostupný z URL: http://docs.oasisopen.org/security/saml/Post2.0/sstc-saml-idp-discovery.pdf 21. HAMMER-LAHAV, E. a kol. : Defining Well-Known Uniform Resource Identifiers (URIs) [online]. duben 2010 [cit. 2014-08-01] Dostupný z URL: http://tools.ietf.org/html/rfc5785 22. SAKIMURA, N., BRADLEY, J., JONES, M. : OpenID Connect Discovery 1.0 [online]. únor 2014 [cit. 2014-08-01] Dostupný z URL: http://openid.net/specs/openidconnect-discovery-1_0.html 23. SAKIMURA, N., BRADLEY, J., JONES, M. : OpenID Connect Dynamic Client registration 1.0 [online]. únor 2014 [cit. 2014-08-01] Dostupný z URL: http://openid.net/specs/openid-connect-registration-1_0.html 24. CANTOR, S., a kol. : Authentication Context for the OASIS Security Assertion Markup Language (SAML) V2.0 [online]. březen 2005 [cit. 2014-08-01] Dostupný z URL: http://docs.oasis-open.org/security/saml/v2.0/saml-authn-context-2.0-os.pdf 25. RECORDON, D. a kol. : OpenID Provider Authentication Policy Extension 1.0 [online]. prosince 2008 [cit. 2014-08-01] Dostupný z URL: http://openid.net/specs/openidprovider-authentication-policy-extension-1_0.html 26. RECORDON, D. a kol. : OpenID Simple Registration Extension 1.0 [online]. červen 2006 [cit. 2014-08-01] Dostupný z URL: http://openid.net/specs/openid-simpleregistration-extension-1_0.html 27. HARDT, D. a kol. : OpenID Attribute Exchange 1.0 [online]. prosince 2007 [cit. 201408-01] Dostupný z URL: http://openid.net/specs/openid-attribute-exchange-1_0.html

46

7 Seznam obrázků Obrázek 1: Schéma distribuované autentizace.....................................................................12 Obrázek 2: Schéma komunikace protokolu Kerberos..........................................................21 Obrázek 3: Schéma komunikace protokolu BrowserID.......................................................25

47