Federace identit v cloudu. Bc. Petr Soukup

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Federace identit v cloudu Bc. Petr Soukup

Vedoucí práce: Ing. Jan Kubr

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 3. ledna 2012

iv

v

Poděkování Na tomto místě bych rád poděkoval vedoucímu své diplomové práce, Ing. Janu Kubrovi, za užitečné rady a celkové vedení při tvorbě a sepisování této práce.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 3. ledna 2012

.............................................................

viii

Abstract This thesis deals with identity federation with focus on deploying OpenID technology to the Microsoft Azure cloud. Work results in a modified JanRain OpenID PHP library which uses Azure Storage or SQL Azure as a data backend. Hence, it can be deployed on the MS Azure using multiple virtual server instances. The library is then used in the implementation of the wiki system DokuWiki OpenID extension. Result of this part is a DokuWiki plugin enabling OpenID authentication and authorization based on user attributes fetched from the OpenID identity.

Abstrakt Práce se zabývá technologií federace identit se zaměřením na nasazení technologie OpenID v cloud prostředí Microsoft Azure. Výsledkem práce je upravená knihovna JanRain OpenID PHP, která pro ukládání provozních dat využívá uložiště Azure Storage nebo SQL Azure a umožňuje tak nasazení v MS Azure na více instancích virtuálních serverů. OpenID knihovna je dále použita v implementaci rozšíření do wiki systému DokuWiki. Výsledkem této části je DokuWiki plugin umožňující autentizaci prostřednictvím OpenID a autorizaci založenou na uživatelských atributech načtených z OpenID identity.

ix

x

Obsah 1 Úvod 1.1 Cíl a struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 2

2 Federace identit 2.1 Autentizace, autorizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 6

3 Teoretická analýza vybraných technologií 3.1 OpenID . . . . . . . . . . . . . . . . . . . 3.1.1 OpenID pojmy . . . . . . . . . . . 3.1.2 Poskytovatelé identity . . . . . . . 3.1.3 Průběh autentizace . . . . . . . . . 3.1.4 Příklad autentizace . . . . . . . . . 3.1.5 Autorizace . . . . . . . . . . . . . 3.2 Google Account . . . . . . . . . . . . . . . 3.2.1 Průběh autentizace . . . . . . . . . 3.3 MojeID . . . . . . . . . . . . . . . . . . . 3.4 Shibboleth . . . . . . . . . . . . . . . . . . 3.4.1 Průběh autentizace a autorizace .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

9 9 9 10 11 13 15 16 17 19 19 20

4 Nasazení technologie OpenID v Microsoft Azure 4.1 Teoretická využitelnost federace identit v cloud prostředí . 4.2 Obecné úpravy pro nasazení v MS Azure . . . . . . . . . 4.3 Použité programové prostředky . . . . . . . . . . . . . . . 4.4 Úprava knihovny . . . . . . . . . . . . . . . . . . . . . . . 4.4.1 Volba datového uložiště . . . . . . . . . . . . . . . 4.4.2 Přidání podpory Azure Storage . . . . . . . . . . . 4.4.3 Přidání podpory MS SQL . . . . . . . . . . . . . . 4.4.4 Náhrada balíku PEAR DB . . . . . . . . . . . . . 4.4.5 Úprava pro SQL Azure . . . . . . . . . . . . . . . 4.5 Doplňkové úpravy knihovny . . . . . . . . . . . . . . . . . 4.5.1 Úprava pro PHP 5.3 . . . . . . . . . . . . . . . . . 4.5.2 Generátor náhodných čísel . . . . . . . . . . . . . . 4.5.3 HTTPS komunikace . . . . . . . . . . . . . . . . . 4.6 Windows Azure Tools 4 Eclipse . . . . . . . . . . . . . . . 4.7 Dokumentace . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

23 23 24 24 25 26 27 30 31 32 34 34 34 34 36 37

xi

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

xii

OBSAH

5 Integrace OpenID do aplikace 5.1 Výběr aplikace . . . . . . . . . . . . . 5.2 OpenID plugin . . . . . . . . . . . . . 5.3 Rozšíření funkcionality . . . . . . . . . 5.4 Řízení přístupu poskytovatelů . . . . . 5.5 Autorizace s využitím OpenID . . . . 5.6 Podpora rozšíření Attribute Extension 5.7 Dokumentace . . . . . . . . . . . . . . 6 Testování 6.1 Upravené části OpenID knihovny 6.2 Dokuwiki OpenID plugin . . . . 6.2.1 Funkční testování . . . . . 6.2.2 Usability testování . . . .

. . . .

. . . .

. . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . .

39 39 39 40 41 42 45 45

. . . .

47 47 50 50 52

7 Závěr

53

A Seznam použitých zkratek

59

B Testovací scénáře knihovny - Azure Storage

61

C Testovací scénáře knihovny - SQL Storage

67

D Obsah přiloženého CD

71

Seznam obrázků 3.1 3.2 3.3 3.4 3.5 4.1 4.2 4.3 4.4

Příklad přihlašovacího formuláře pro autentizaci pomocí OpenID . . . . . . Průběh autentizace v technologii OpenID . . . . . . . . . . . . . . . . . . . Ukázka paralelního použití možností přihlášení pomocí OpenID a přihlášení pomocí účtu Google . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Průběh OpenID autentizace s použitím účtu Google . . . . . . . . . . . . . Průběh autentizace v technologii Shibboleth . . . . . . . . . . . . . . . . . . Schéma provozu PHP aplikace v prostředí Azure a dostupná uložiště . . . . Konceptuální diagram tříd znázorňující design rozhraní OpenIDStore . . . . Konceptuální diagram tříd znázorňující rozšíření podpory knihovny o uložiště Azure Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Konceptuální diagram tříd znázorňující design třídy SQLStore . . . . . . .

. 11 . 12 . 18 . 18 . 21 . 25 . 26 . 27 . 30

5.1 5.2

Formulář pro definování pravidel pro řízení přístupu na úrovni OpenID atributů 42 Konceptuální sekvenční diagram znázorňující implementaci průběhu operací v DokuWiki OpenID pluginu před odesláním OpenID žádosti . . . . . . . . . 44

6.1

Vzorek pravidel pro testování vyhodnocení uživatelských atributů . . . . . . . 52

D.1 Adresářová struktura přiloženého CD . . . . . . . . . . . . . . . . . . . . . . . 71

xiii

xiv

SEZNAM OBRÁZKŮ

Seznam tabulek 2.1

Shrnutí výhod a nevýhod federace identit . . . . . . . . . . . . . . . . . . . .

3.1 3.2

Význam parametrů OpenID žádosti z Př. 3.2 . . . . . . . . . . . . . . . . . . 14 Význam parametrů rozšíření Attribute Exchange z Př. 3.5 . . . . . . . . . . . 17

4.1 4.2

Omezení názvů kontejnerů v Azure Storage . . . . . . . . . . . . . . . . . . . 28 Vybraná omezení databáze SQL Azure . . . . . . . . . . . . . . . . . . . . . . 33

6.1 6.2 6.3 6.4

Příklad případu užití knihovny s použitím Azure Storage využitý pro testování Testovací konfigurace MS Azure . . . . . . . . . . . . . . . . . . . . . . . . . . Testovací konfigurace použitých prostředků . . . . . . . . . . . . . . . . . . . Výsledky testování načítání uživatelských atributů využitím SREG a AX u různých poskytovatelů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

49 50 50

B.1 B.2 B.3 B.4 B.5

Případ Případ Případ Případ Případ

užití užití užití užití užití

-

Přihlásit se - Azure Storage (1.část) Přihlásit se - Azure Storage (2.část) Inicializovat uložiště - Azure Storage Provést údržbu - Azure Storage . . . Ukončit použití - Azure Storage . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

61 62 63 64 65

C.1 C.2 C.3 C.4 C.5

Případ Případ Případ Případ Případ

užití užití užití užití užití

-

Přihlásit se - SQL Azure (1.část) Přihlásit se - SQL Azure (2.část) Inicializovat uložiště - SQL Azure Provést údržbu - SQL Azure . . Vyčistit uložiště - SQL Azure . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

67 68 69 69 70

xv

. . . . .

. . . . .

7

51

xvi

SEZNAM TABULEK

Kapitola 1

Úvod Rozvoj internetu a personalizovaných on-line služeb s sebou přináší pro uživatele velké možnosti, kdy průměrný uživatel vlastní alespoň jeden emailový účet, má účet na sociální, síti, nakupuje v několika internetových obchodech, případně diskutuje na tematicky zaměřených serverech nebo vlastní blog ve službách k tomu určených. Takto široké pole uživatelské působnosti zpravidla vyžaduje mít u každé takové služby založený uživatelský účet, který umožňuje rozpoznat identitu a roli daného uživatele, typicky v kombinaci s nějakým způsobem zabezpečení, aby bylo zabráněno zneužití účtu. Uživatel tedy musí být před použitím služby autentizován, potvrzen jako skutečný majitel proklamované identity. Výše popsanou situaci komplikuje fakt, že uživatel nemusí chtít vystupovat v každé službě pod stejnou identitou, stejně jako praktická nemožnost vlastnictví stejné identity u všech služeb, dané například obsazeností požadovaného uživatelského jména či rozdílnou politikou tvorby uživatelským jmen či hesel. Výsledkem je, že každý uživatel je nucen spravovat mnoho uživatelských jmen a mnoho hesel. Stejná situace se objevuje ve firemní sféře. Trend decentralizace firemních systémů či outsourcing některých firemních potřeb přináší nutnost autentizovat uživatele v různých doménách, např. v hlavním firemním systému a v systému externího partnera, spravujícího účetnictví či zajišťujícího dodávky zboží. Obecně každý další systém či služba mohou znamenat potřebu dalších přihlašovacích údajů. Rizikem spravování mnoha uživatelských jmen a hesel, které může být navíc nutné díky heslové politice pravidelně měnit, je překročení paměťové kapacity uživatele. To může vést v nejhorším případě k situaci, že si uživatel poznamenává přihlašovací údaje k jednotlivým službám na papírek, který je připevněn na kraji monitoru. Toto samozřejmě představuje závažné bezpečnostní riziko. Řešení této komplexnosti nabízí technologie federace identit, kdy uživatel potřebuje k autentizaci pouze jedny přihlašovací údaje. Použitím těchto údajů se uživatel identifikuje u strany vyhrazené k tomuto účelu. Cílový systém či služba se poté místo vlastního požadavku na autentizaci obrací na autentizační stranu, která službě předá potvrzení, že daný uživatel má právo k použití proklamované identity. Cloud systémy představují oproti dnes využívanějším on-premise nasazením velké množství výhod. Hlavními jsou vysoký výpočetní výkon, vysoká datová propustnost a téměř 1

2

KAPITOLA 1. ÚVOD

neomezená kapacita datových uložišť. Dále široké možnost škálování, vysoká úroveň zabezpečení, vysoká garantovaná dostupnost, bezúdržbový provoz serveru, či možnost geo-lokace. Aplikace nasazované do cloud prostředí ale také musí podléhat charakteristickým rysům cloud prostředí, danými zejména během na virtuálních serverech a jejich replikací, umožňující vysokou škálovatelnost. Hlavním požadavkem je bezestavovost běhu jednotlivých instancí serverů. Pevně určený je také operační systém a webový server, na kterém bude aplikace nasazena. Technologie použité v aplikaci musí proto tyto požadavky podporovat. Omezena je také možnost konfigurace serveru. Nestandardní prostředky proto nemusí být k dispozici. Podobně komunikace na nestandardních portech může být z bezpečnostních důvodů blokována. Z výše uvedeného vyplývá, že existující technologii či aplikaci nelze obvykle v cloud prostředí použít bez nutnosti provedení úprav, přizpůsobujících aplikaci specifikacím cloud systému. Tato práce se proto věnuje možnostem nasaditelnosti technologie federace identit do cloud prostředí.

1.1

Cíl a struktura práce

Cíl práce lze rozdělit na tři části. První částí je teoretická analýza vybraných technologií federace identit, která objasní princip fungování jednotlivých technologií. Výstup této části bude použit pro teoretické zhodnocení možností využitelnosti v prostředí cloudu. Hlavní částí práce je poté praktické ověření funkce vybrané technologie v cloud prostředí Microsoft Azure, tedy vyzkoušení a případná úprava funkčnosti této technologie tak, aby fungovala při nasazení do cloud prostředí. Výběr technologie bude založen na výsledku analýzy technologií. Výsledkem bude upravená knihovna umožňující použití v MS Azure. Závěřečnou částí práce je praktická implementace technologie do aplikace nasaditelné do MS Azure. V praktické části práce jsou posuzovány i některá specifika a omezení MS Azure, vyplývající z podstaty cloud prostředí, relativně krátké doby uvedení do provozu a stále probíhajícímu vývoji. Výsledkem je tedy shrnutí zkušeností s vývojem a návod na integraci technologie federace identit do aplikací provozovaných na MS Azure. Technologie byly vybrány následující: • OpenID • Google Account • MojeID • Shibboleth Práce začíná úvodem do problematiky, definováním cíle a výběrem diskutovaných technologií. Druhá kapitola vysvětluje pojem federace identit z obecného hlediska a zmiňuje i souvislost autentizace a autorizace a podporující mechanismy federace identit. Třetí kapitola se věnuje teoretické analýze jednotlivých vybraných technologií souvisejících s tímto pojmem. Ke každé technologii je poskytnut úvod s referencemi na doplňující informace.

1.1. CÍL A STRUKTURA PRÁCE

3

Z technického aspektu je důraz kladen na nutnost případných změn na klientské straně potřebných pro fungování, na princip průběhu autentizace a komunikaci mezi zúčastněnými stranami. Čtvrtá kapitola je zaměřena na praktické aspekty implementace související s nasazením vybrané technologie OpenID do prostředí Microsoft Azure. Diskutovány jsou možné konceptuální překážky, krátce je zmíněna charakteristika cloud prostředí a její dopad na případnou potřebu uzpůsobení kódu knihovny a aplikace. Hlavní částí je dokumentace změn, které bylo nutné provést do vybrané knihovny JanRain OpenID PHP, aby bylo možné ji nasadit do MS Azure. Pátá kapitola se věnuje integraci upravené OpenID knihovny do aplikace. Zaměřena je na demontraci praktického využití možností, které technologie OpenID nabízí, a popis jejich implementace. Kapitola šestá obsahuje popis testovacích procedur, které byly použity pro ověření správné funkce obou implementačních částí práce, a výsledky testů. Závěrečná kapitola shrnuje zjištěné poznatky, zhodnocuje dosažené výsledky a uvádí i možné pokračování práce.

4

KAPITOLA 1. ÚVOD

Kapitola 2

Federace identit Technologie federace identit definuje oddělení procesu autentizace ze strany poskytovatele služby na vyhrazenou stranu. Ta uživatele ověří a poskytovateli služby předá pouze potvrzení jeho identity, ne jeho přihlašovací údaje. Tento koncept osvobozuje uživatele od nutnosti mít u každé služby nový uživatelský účet. Výhodu přináší i poskytovateli služby, kterého osvobozuje od vlastní implementace technologie autentizace. Dále mu umožňuje mít přístup k aktuálně platným uživatelským údajům, které by nemusel mít, pokud by uživatel zapomněl údaj aktualizovat v jeho lokálním účtu. Poskytovatel služby má také možnost zcela vynechat nebo automatickým doplněním některých uživatelských údajů maximálně zjednodušit lokální registrační proces, jehož nutnost může uživatele v určitých případech zcela odradit od použití služby. Dle definice není technologie federace identit svázána s žádným konkrétním protokolem, technologií, implementací, apod. Hlavním cílem je umožnit uživatelům jedné domény bezpečně přistoupit k službě či datům jiné domény bez nutnosti administrace uživatele na vzdálené doméně. Možné scénáře jsou jak user-controlled, kdy o přístupech a povoleních mezi doménami rozhoduje uživatel, tak enterprise-controlled (business-to-business scénáře), kdy jsou pravidla definovaná předem na úrovni celku, obvykle smluvním závazkem. Termín „federace“ označuje skupinu stran s vzájemným závazkem důvěry. Tato federace je díky definovaným otevřeným standardům a veřejně publikovaným specifikacím zpřístupněna, takže různé strany mohou tyto technologie implementovat a dosáhnout tak interoperability. Jednou z výhod, kterou federace umožňuje je single sign-on (SSO) funkcionalita, kdy se uživatel autentizuje u svého poskytovatele identity pouze při prvním přístupu a poté již není nucen zadávat své přihlašovací údaje znovu a znovu, i když přistupuje k různým poskytovatelům služeb. Jeho identita je po odsouhlasení vztahu automaticky delegována a pro uživatele je tak práce pohodlnější a rychlejší. Poskytovatel identity také může, jakožto vyhrazená strana, udržovat kompletní přehled o použití identity a umožňuje tak uživateli např. odhalit zneužití identity při vyzrazení přihlašovacích údajů. Koncept fungování federace identit přináší i některé další bezpečnostní výhody. Již zmíněn byl fakt, že uživatel poskytuje své přihlašovací údaje pouze straně, kterou zná a které věří. Heslo také není předáváno za hranice důvěryhodné domény. Dále odpadá nutnost pamatování si mnoha různých přihlašovacích údajů, která může v důsledku vést ke slabé ochraně 5

6

KAPITOLA 2. FEDERACE IDENTIT

hesel. Snižuje se i riziko phishingu1 , protože uživatel zná svou přihlašovací stránku a není navyklý zadávat svá hesla bez přemýšlení všude. Na druhé straně koncept centrálního bodu autentizace a univerzálních přihlašovacích údajů zvýrazňuje nutnost silného zabezpečení autentizačního bodu. Vyvstává také riziko nedostupnosti veškerých koncových služeb při jeho výpadku. Souhrn výhod a rizik, které federace identit přináší uživateli a poskytovateli služby je uveden v Tab. 2.1.

2.1

Autentizace, autorizace

Kromě ověření identity uživatele, tedy autentizace, může být při přístupu ke službě nutné řídit přístup uživatele k jednotlivým zdrojům, tedy kontrolovat, zda je uživatel autorizovaný k provedení určité akce. Zatímco autentizace je z definice federace identit prováděna na straně poskytovatele identity, autorizaci není žádoucí přesunout, protože poskytovatel služby by tak ztratil část kontroly nad svou službou a svými daty, což je z principu nežádoucí. Řízení přístupu uživatelů tedy zůstává plně v odpovědnosti poskytovatele služby. Definovat autorizační pravidla na úrovni jednotlivých uživatelů není v mnoha případech nezbytné a většinou by toto nebylo efektivní. Pro účely řízení přístupu se tedy používá rozhodování na základě větších celků, např. příslušnosti k určité skupině. Technologie implementující koncept federace identit proto poskytují mechanismy, jak se autentizačního serveru, který jediný má přístup ke kompletní identitě uživatele, dotázat i na doplňující atributy týkající se jeho identity. Na základě těchto atributů je poté možné efektivně řídit přístup k daným zdrojům. Důležitým aspektem ovšem zůstává, že toto předávání informací se neděje bez vědomí uživatele, ale je vždy odsouhlaseno, ať již při nastání situace, či dlouhodobějším vztahem důvěry.

1

Způsob podvodného vylákání uživatelských citlivých údajů, zpravidla prostřednictvím falešného přihlašovacího formuláře. Více viz např. http://en.wikipedia.org/wiki/Phishing

2.1. AUTENTIZACE, AUTORIZACE

Výhody Pro uživatele Pro poskytovatele služby jen jedny přihlašovací údaje není nutná implementace vlastního autentizačního mechanismu heslo neopouští důvěryhodnou do- udržování aktuálních uživatelských ménu údajů přehled o použití identity vynechání či zjednodušení lokální registrace SSO - pohodlnější a rychlejší práce vynechaná či zjednodušená lokální registrace Nevýhody vyzrazení přihlašovacích údajů znamená přístup ke všem službám riziko nedostupnosti všech koncových služeb při výpadku autentizačního bodu Tabulka 2.1: Shrnutí výhod a nevýhod federace identit

7

8

KAPITOLA 2. FEDERACE IDENTIT

Kapitola 3

Teoretická analýza vybraných technologií Tato kapitola poskytuje teoretický základ funkce vybraných technologií federace identit. Zaměřena je především na komunikaci a princip průběhu autentizace mezi zúčastněnými stranami.

3.1

OpenID

OpenID je otevřený standard poskytující možnost ověření identity uživatele služby napříč doménami, bez nutnosti předání jeho přihlašovacích údajů, zvláště pak hesla. Jeho první specifikace byla zveřejněna v roce 2005, aktuální verze 2.0 je z roku 2007. Jako identifikátor uživatele se používá unikátní identifikátor v podobě URI, ke kterému je obvykle přiřazeno heslo, ale OpenID nepředepisuje způsob autentizace, ten je ponechán zcela na straně autentizačního serveru, tudíž je možné využívat i certifikáty, aj. Používány jsou pouze standardní http(s) žádosti a odpovědi, na straně klienta tedy nejsou vyžadovány žádné dodatečné úpravy. Domovské webové stránky technologie OpenID lze nalézt na [1], specifikaci protokolu na [2]. Pro usnadnění implementace technologie OpenID lze nalézt ověřené knihovny nejen pro jazyk PHP, např. na [3]. Zajímavostí OpenID také je, že jej podporují, tj. implementují, někteří velcí poskytovatelé online služeb [4], např. Google, Yahoo!, či AOL. Tito poskytovatelé služeb fungují zároveň jako OpenID poskytovatelé. Každý uživatelský účet této služby tedy funguje jako OpenID identita. Využitelnost této skutečnosti je však výrazně snížena faktem, že tito poskytovatelé o OpenID funkcionalitě uživatele při registraci nijak explicitně neinformují a uživatelé tak o této možnosti nemusí vůbec vědět.

3.1.1

OpenID pojmy

Identifikátor (Identifier) Identifikátor je buď http nebo https URI nebo XRI [5]. 9

10

KAPITOLA 3. TEORETICKÁ ANALÝZA VYBRANÝCH TECHNOLOGIÍ

Uživatelský agent (User-agent) alespoň standard http 1.1.

Uživatelským agentem je webový prohlížeč splňující

Poskytovatel služby, RP (Relying party, Service provider) Systém, webová služba či aplikace, která vyžaduje potvrzení, že uživatel vlastní proklamovanou identitu, tj. služba, která vyžaduje autentizaci pomocí OpenID. OpenID poskytovatel, poskytovatel identity, OP (OpenID provider, Identity provider) OpenID autentizační server, ke kterému se obrací poskytovatel služby s žádostí o ověření vlastnictví identity, tj. strana, která provádí samotnou autentizaci. OP identifikátor (OP identifier)

URL identifikátor OpenID poskytovatele.

Uživatelem zadaný identifikátor (User-supplied identifier) Identifikátor, který uživatel zadal u poskytovatele služby. RP se poté obrací na OP s požadavkem na ověření vlastnictví identifikátoru. V počáteční fázi protokolu může uživatel zadat buď vlastní identifikátor, nebo OP identifikátor, kdy vlastní identifikátor zvolí až na straně OP. URL adresa poskytovatele identity (OP Endpoint URL) Http(s) URL adresa autentizačního serveru, na které jsou přijímány zprávy protokolu OpenID. Tato adresa je zjištěna provedením funkce discovery na uživatelem zadaném identifikátoru. Proklamovaný identifikátor (Claimed identifier) Identifikátor reprezentující identitu, u níž uživatel proklamuje vlastnictví. Tento identifikátor je získán v případě URI normalizací uživatelem zadaného identifikátoru nebo v případě XRI je za něj brán CanonicalID element. OP-lokální identifikátor (OP-local identifier) OpenID poskytovatel může přiřadit uživateli svůj lokální identifikátor, který je uživateli transparentní.

3.1.2

Poskytovatelé identity

OpenID je decentralizovaný protokol, který využívá více poskytovatelů identit a uživateli je ponechána volnost v jejich volbě. Obecně je možno mít více identit u jednoho či více poskytovatelů. Běžné požadavky na poskytovatele jsou jeho důvěryhodnost, která zajišťuje bezpečnost spravovaných uživatelských údajů, a jeho neutralita, která je žádoucí z hlediska nezneužití údajů poskytovatelem, např. předáním třetí straně. Seznam prověřených a doporučených veřejných poskytovatelů lze nalézt na [4]. Rozsah uživatelských dat, která poskytovatel o uživateli spravuje, závisí na vůli uživatele, ale liší se také mezi jednotlivými poskytovateli. Obecně je pro založení identity, nutné pouze uživatelské jméno, ze kterého je vygenerován URI identifikátor, obvykle připojením přípony poskytovatele, viz Př. 3.1. Pro plné využití konceptu federace identit, např. pro zjednodušení

3.1. OPENID

11

registračního procesu automatickým doplněním uživatelských údajů, poskytovatelé obvykle nabízejí uživateli správu více údajů, zpravidla emailové adresy, korespondenční adresy, telefonního čísla, apod. Různí poskytovatelé také různě přistupují k možnosti jednoznačné identifikace konkrétní fyzické osoby, či vytváření více identit. Prvním příkladem může být poskytovatel MyOpenID [6]. Tento pro založení openID identity vyžaduje pouze uživatelské jméno, zbytek údajů je dobrovolný. Také umožňuje vytvoření několika různých identit pod stejným URI, takže při delegaci údajů poskytovali služby si uživatel volí, ze které identity chce údaje poskytnout. Oproti tomu poskytovatel MojeID [7], si klade za cíl suplovat jednoznačný identifikátor fyzické osoby, proto při registraci využívá i ověření pomocí korespondenční adresy a telefonního čísla, stejně jako neumožňuje vytváření alternativních identit. Uživatelské jméno : jan−novak Vygenerované URI : jan−novak . myopenid . com

Příklad 3.1: Generování URI z uživatelského jména u poskytovatele identity MyOpenID Identifikátor lze také zvolit vlastní, např. adresu osobní webové stránky, tudíž je identifikátor více personalizovaný a také díky funkci delegace nezávislý na konkrétním poskytovateli, tedy přenositelný. Implementace delegace je popsána např. v [8]. Jelikož je případná krádež identity kritickým místem single-sign-on systémů, prověření poskytovatelé uchovávají historii používání identity, pomocí které lze mít přehled nad použitím identity.

3.1.3

Průběh autentizace

Obr. 3.2 zobrazuje průběh autentizace s použitím technologie OpenID. Uživatel prostřednictvím svého agenta, typicky webového prohlížeče, u svého poskytovatele služby, typicky využitím webové stránky, zvolí možnost přihlášení pomocí OpenID. Na rozdíl od běžného formuláře pro zadání uživatelského jména a hesla je u OpenID potřeba zadání pouze URI identifikátoru, proto se vzhled formuláře většinou změní a bývá označen logem technologie OpenID, příklad na Obr. 3.1.

Obrázek 3.1: Příklad přihlašovacího formuláře pro autentizaci pomocí OpenID; převzato z [1] Autentizace poté probíhá těmito body, jak jsou zachyceny i v Obr. 3.2: 1. Uživatel prostřednictvím svého agenta zadá na straně poskytovatele služby URI identifikátor, např. jan-novak.myopenid.com, a odešle formulář. Tento identifikátor může být identifikátor přímo proklamované identity, nebo OP identifikátor, kdy proklamovaná identita je zadána až na straně OP.

12


Obrázek 3.2: Průběh autentizace v technologii OpenID; převzato z [9] RP normalizuje poskytnutý URI, tj. např. http://jan-novak.myopenid.com/, a provede discovery proces poskytovatele OpenID, který spravuje zadanou identitu, pro získání URL adresy OP, např. https://www.myopenid.com/. Tento krok je u OpenID 2.0 zajištěn vyžádáním XRDS dokumentu prostřednictvím Yadis protokolu [10]. 2. Volitelný krok. Po vyhledání poskytovatele je možné asociovat poskytovatele identity a služby pomocí sdíleného tajného klíče (získaného s využitím technologie DiffieHellman výměny klíčů [11]). Tento klíč používá OP k šifrování vyměňovaných zpráv a RP k ověření jejich pravosti a integrity. OpenID definuje dva možné módy autentizace, checkid_setup a checkid_immediate. Mód checkid_immediate slouží k nastavení automatické autentizace bez zásahu uživatele. V tomto módu je tedy vynechán krok 3. Běžnější je mód checkid_setup, který vyžaduje interakci uživatele (např. zadání hesla). 3. RP přesměruje uživatelského agenta na stránky svého poskytovatele identity s žádostí o autentizaci poskytnutého identifikátoru. Pozn.: Autentizace může proběhnout i v rámci stránky poskytovatele s použitím např. pop-up okna. Pokud uživatel ještě v dané relaci nebyl přihlášen, zadá své jméno a heslo, či použije jiný způsob autentizace. Pokud ano, zafunguje princip single-sign-on. Uživatel je také dotázán, zda a jaké jeho osobní údaje mají být předány poskytovateli služby (nikdy ne heslo). Tento proces zajišťuje uživateli plnou kontrolu nad tím, které údaje o své osobě předá třetí straně pro další využití. 4. V dalším kroku je uživatelův agent přesměrován zpět na stranu poskytovatele služby s výsledkem autentizace (úspěšná/neúspěšná) a RP jsou předány případné odsouhla-

3.1. OPENID

13

sené uživatelské údaje. V případě neúspěšné autentizace či odmítnutí předání uživatelských údajů, které RP vyžaduje pro svou činnost, obvykle RP s uživatelem dále nakládá jako s neautentizovaným. 5. Poskytovatel služby ověří, zda přijatá data pochází skutečně od tázaného OP, tedy vyloučí možnost man-in-the-middle útoku. Kontroluje se návratová adresa PR, nonce parametr (zamezení replay útoku), a podpis zprávy. Pokud byl na začátku komunikace vyměněn sdílený klíč (krok 2), je podpis ověřen použitím tohoto klíče. Je tedy nutné, aby RP udržoval během komunikace tajné klíče. Tento mód OpenID protokolu se nazývá stateful. Druhou možností je stateless (dumb) mód RP, který vynechává krok 2 a proto po přijetí výsledku od OP odesílá poskytovateli identity ještě žádost o ověření podpisu, tzv. check_autentication. 6. Po úspěšném dokončení předchozích kroků má RP jistotu ověřené identity uživatele a může nastavit a započít svou službu.

3.1.4

Příklad autentizace

Žádost Př. 3.2 zobrazuje příklad OpenID request žádosti o potvrzení identity uživatele při přihlašování na serveru http://likeorhate.com/. Význam jednotlivých parametrů je uveden v Tab. 3.1. https : / / www . myopenid . com / server ? openid . ns=http : / / specs . openid . net / auth /2.0& openid . mode=checkid_setup& openid . assoc_handle={HMAC−SHA256 }{4 ce2ca6c }{ aD4hRg==}& openid . claimed_id=http : / / jan−novak . myopenid . com/& openid . identity=http : / / jan−novak . myopenid . com/& openid . return_to=https : / / likeorhate . rpxnow . com / openid / finish ? d is co ve r y_ to ke n=pd%253←A 4 d d 8 5 9 d 9 d 2 8 1 9 c 3 2& openid . realm=https : / / likeorhate . rpxnow . com/& openid . ns . sreg=http : / / openid . net / extensions / sreg /1.1& openid . sreg . policy_url=https : / / likeorhate . rpxnow . com / openid / sreg_policy& openid . sreg . optional=nickname , email , fullname , dob , gender , country , timezone

Příklad 3.2: Ukázka OpenID žádosti o autentizaci od poskytovatele služby likeorhate.com poskytovateli identity myopenid.com

Odpověď Odpověď OP na OpenID žádost má velice podobný tvar jako žádost, viz Př. 3.3, odpověď na žádost uvedenou v Př. 3.2. Parametr openid.mode je využit pro signalizaci výsledku autentizace. V případě úspěšné autentizace je nastaven na hodnotu id_res (OpenID response), další možné hodnoty jsou např. cancel při odmítnutí autentizace či setup_needed při selhání módu autentizace bez interakce uživatele. Pro účely rozpoznání uživatele na straně RP, tedy pro suplování skrytého lokálního uživatelského jména, lze použít vrácený parametr openid.claimed_id nebo openid.identity.

14


Parametr https://www.myopenid.com/server

openid.ns= http://specs.openid.net/auth/2.0 openid.mode=checkid_setup

openid.assoc_handle= {HMACSHA256}{4ce2ca6c}{aD4hRg==} openid.claimed_id= http://jan-novak.myopenid.com/ openid.identity= http://jan-novak.myopenid.com/ openid.return_to= https://likeorhate.rpxnow.com/ openid/finish?discovery_token= pd%253A4dd859d9d2819c32 openid.realm= https://likeorhate.rpxnow.com/ openid.ns.sreg= http://openid.net/extensions/ sreg/1.1 openid.sreg.policy_url= https://likeorhate.rpxnow.com/ openid/sreg_policy openid.sreg.optional=nickname, email,fullname,dob,gender, postcode,country,timezone

Význam https požadavek na OP-endpoint adresu poskytovatele identity myOpenID (https://www.myopenid.com/server), která byla zjištěna při discovery procesu povinná hlavička zprávy OpenID protokolu mód autentizace; checkid_setup vyžaduje interakci uživatele; nastavení módu checkid_immediate by v tomto případě selhalo, protože i kdyby již byl uživatel oproti OP autentizovaný, musí potvrdit předání údajů poskytovateli služby nastavení parametrů asociace OP a RP normalizovaný identifikátor zadaný uživatelem do přihlašovacího formuláře (zadáno jannovak.myopenid.com) OP lokální identifikátor; v tomto případě stejný jako uživatelem proklamovaný, ale obecně může mít libovolný tvar, např. http://www.myopenid.com/jan-novak/ adresa pro přesměrování uživatelského agenta po dokončení autentizace obecné URL poskytovatele služby povinná hlavička definice rozšíření OpenID Simle Registration, které je navrženo pro předávání základních uživatelských údajů využitelných např. pro zautomatizování registračního procesu na straně RP URL adresa, na které se nachází prohlášení o politice nakládání s předanými údaji žádost o předání údajů (nepovinně) - přezdívky, emailové adresy, celého jména, data narození, apod.

Tabulka 3.1: Význam parametrů OpenID žádosti z Př. 3.2

3.1. OPENID

15

https : / / likeorhate . rpxnow . com / openid / finish ? d is co ve r y_ to ke n=pd%253 A 4 d d 8 5 8 d 9 d 2 8 1 9 c 3 2 ←? openid . ns=http : / / specs . openid . net / auth / 2 . 0 &openid . mode=id_res &openid . op_endpoint= https : / / www . myopenid . com / server &openid . respo nse_nonc e =2008−09−18 T04 : 1 4 : 4 1 Zt6shNlcz−MBdaw &openid . return_to= https : / / likeorhate . rpxnow . com / openid / finish ? d is co ve r y_ to ke n=pd←%253 A 4 d d 8 5 8 d 9 d 2 8 1 9 c 3 2 &openid . assoc_handle={HMAC−SHA256 }{4 ce2ca6c }{ aD4hRg==} &openid . signed=op_endpoint , claimed_id , identity , return_to , response_nonce , ←assoc_handle &openid . sig=s / g f i W S V L B Q c m k j v s K v b I S h c z H 2 N O i s j z B L Z O s f i z k I= &openid . claimed_id=http : / / jan−novak . myopenid . com / &openid . identity=http : / / jan−novak . myopenid . com /

Příklad 3.3: Ukázka OpenID odpovědi na žádost o autentizaci od poskytovatele služby likeorhate.com poskytovateli identity myopenid.com

openid . claimed_id=http : / / jan−novak . myopenid . com / openid . identity=http : / / jan−novak . myopenid . com / openid . claimed_id=https : / / jan−novak . mojeid . cz / openid . identity=https : / / mojeid . cz / id /3 kak1biwVf / openid . claimed_id=https : / / www . google . com / accounts / o8 / id ? id=←AItOawmwQJBKF7hd4McxDTx3LkTeu5LgF0krr54 openid . identity=https : / / www . google . com / accounts / o8 / id ? id=←AItOawmwQJBKF7hd4McxDTx3LkTeu5LgF0krr54

Příklad 3.4: Příklady možných návratových hodnot parametrů openid.claimed_id a openid.identity u různých OP v odpovědi na žádost o autentizaci uživatele.

Vracená hodnota je perzistentní, při implementaci je však nutné brát v potaz, že syntaxe se liší dle jednotlivých providerů. Může být přijat nezměněný URI poskytnutý do žádosti, ale OP také může suplovat svůj vnitřní identifikátor reprezentující uživatele. Některé příklady jsou uvedeny v Př. 3.4. V odpovědi jsou dále navíc 4 důležité parametry openid.endpoint, openid.response_nonce a seznam podepsaných parametrů odpovědi se samotným podpisem (openid.signed, resp. openid.sig). Parametr endpoint uvádí URL adresu OP serveru, který poskytuje odpověď. Parametr nonce slouží k vyloučení replay útoků, kdy obsahuje textový řetězec začínající aktuálním časem na OP serveru doplněný o znaky zajišťujícími unikátnost hodnoty parametru. RP si udržuje hodnoty přijatých parametrů nonce a pro stejnou adresu OP ignoruje odpovědi s opakovaným nonce řetězcem.

3.1.5

Autorizace

Pro účely autorizace, pokud je vhodné rozhodování na úrovni uživatelských atributů, lze v technologii OpenID využít rozšíření Simple Registration (SREG) [12] nebo Attribute Exchange (AX) [13], které umožňují načtení atributů z uživatelova profilu. Rozšíření SREG

16


openid . ns . ax=http : / / openid . net / srv / ax / 1 . 0 openid . ax . mode=fetch_request openid . ax . type . fname=http : / / example . com / schema / fullname openid . ax . type . gender=http : / / example . com / schema / gender openid . ax . type . fav_dog=http : / / example . com / schema / favourite_dog openid . ax . type . fav_movie=http : / / example . com / schema / f av ou ri t e_ mo vi e openid . ax . count . fav_movie=3 openid . ax . required=fname , gender openid . ax . if_available=fav_dog , fav_movie

Příklad 3.5: Ukázka části OpenID žádosti využívající rozšíření OpenID Attribute Exchange; převzato z [13]

podporuje pouze základní atributy, rozšíření AX je komplexnější a umožňuje definovat i nové uživatelské atributy. Pro správné vyřízení žádosti však musí tuto definici interpretovat stejným způsobem OP i RP, takže tato možnost je značně omezena a většina OP podporuje pouze základní atributy odpovídající SREG. Význam AX atributu je definován URL jmenným prostorem - schématem. Mezi poskytovateli však neexistuje jednoznačná shoda, jaké schéma pro definici AX atributů používat, což dále komplikuje praktické použití. Existence dvou rozšíření pro načítání uživatelských údajů navíc komplikuje fakt, že nejsou obě podporovány všemi poskytovateli identit. Z důvodů jednodušší implementace je podporováno častěji rozšíření SREG, někteří OP podporují obě rozšíření, ale existují i poskytovatelé, kteří implementují pouze AX. Pokud je tedy pro poskytovatele služby získání uživatelových atributů důležité, je výhodnější vložit do odesílané OpenID žádosti části obou rozšíření, aby byla vyšší pravděpodobnost odpovědi od OP. Poskytovatel však vždy musí implementovat i možnost nevrácení hodnot atributů. Tato situace nastane u OP, který nepodporuje ani jedno z rozšíření, ale také když uživatel odmítne své informace předat. Použití rozšíření SREG v OpenID žádosti je součástí Př. 3.2. Př. 3.5 ukazuje příklad použití rozšíření Attribute Exchange s definicí atributů využívající schéma http://example.com/ schema/. Příklad je převzatý ze specifikace protokolu [13] a ukazuje široké teoretické možnosti atributů AX. V praxi by však tyto atributy pravděpodobně nebyly podporovány poskytovateli identity. Význam parametrů je uveden v Tab. 3.2.

3.2

Google Account

Účet Google (Google Account) využívá technologii federace identit pro delegování identity uživatele napříč službami poskytovanými společností Google. Při uvažování pouze účtů spojených s emailovou službou Gmail tento účet v roce 2009 vlastnilo přes 150 milionů uživatelů po celém světě [14]. Pro dosažení globální federace identity s účtem Google lze využít nepříliš známý fakt, že společnost Google od roku 2008 slouží jako poskytovatel identity OpenID. Každý účet Google lze tedy využít ve službách podporujících standard OpenID 2.0 a lze k němu přistupovat podobným způsobem jako k účtu OpenID. Podporována jsou i některá rozšíření, zejména OpenID Attribute Exchange. Domácí webová stránka projektu federace identit u účtu Google je k nalezení na [15].

17

3.2. GOOGLE ACCOUNT Parametr openid.ns.ax= http://openid.net/srv/ax/1.0 openid.ax.mode=fetch_request openid.ax.type.fname openid.ax.type.fav_dog openid.ax.type.fav_movie openid.ax.count.fav_movie=3 openid.ax.required=fname openid.ax.if_available=fav_dog, fav_movie

Význam povinná hlavička zprávy OpenID Attribute Exchange typ zprávy – žádost RP o vyznačené údaje označení atributu zastupujícího celé jméno uživatele označení atributu zastupujícího oblíbenou rasu psa uživatele označení atributu zastupujícího oblíbený film uživatele upřesňující žádost o 3 nejoblíbenější filmy vyžadovány údaje o jménu nepovinně žádány údaje o rase psa a filmech

Tabulka 3.2: Význam parametrů rozšíření Attribute Exchange z Př. 3.5

3.2.1

Průběh autentizace

Principiálně zůstává průběh autentizace stejný jako u technologie OpenID. Uživatelům účtu Google však není přiřazen URI identifikátor jako u čistých OpenID účtů. Použití Google účtu v roli OpenID se tedy drobně liší na uživatelské straně v počátku autentizace, kdy uživatel prostřednictvím svého agenta musí zvolit způsob autentizace. Zde je při zvolení „přihlášení pomocí OpenID“ nutné dle definice protokolu obejít zadání URI uživatele zadáním URL adresy poskytovatele identity, tedy ponecháním zvolení konkrétní uživatelské identity až na stranu poskytovatele identity. URL adresa Google pro použití s OpenID je uvedena v Př. 3.6. Zapamatování této adresy je však komplikované, proto pro zvýšení uživatelské přívětivosti někteří poskytovatelé služeb nabízí přímou možnost zvolit, například pomocí zástupné ikony možnost „přihlásit se pomocí účtu Google“ (ukázka viz Obr. 3.3), která je ekvivalentem výše uvedeného postupu, ale přesměrování na autentizační stránku Google je provedeno automaticky bez interakce uživatele. Grafické znázornění tohoto přístupu je zobrazuje Obr. 3.4. Struktura žádostí i odpovědí podléhá standardu OpenID. Je však užitečné vědět, že identifikátor uživatele openid.identity i openid.claimed_id předaný v odpovědi poskytovateli služby se u poskytovatele Google liší pro každou službu. Rozlišení služby je uskutečňováno podle openid.realm parametru. Pokud by se tedy strana poskytovatele služby rozhodla změnit v odesílaných žádostech openid.realm parametr, původní mapování dvojice Google poskytnutý identifikátor-skutečný uživatel se zneplatní.

https : / / www . google . com / accounts / o8 / id

Příklad 3.6: URL adresa OpenID koncového bodu poskytovatele Google

18


Obrázek 3.3: Ukázka paralelního použití možností přihlášení pomocí OpenID a přihlášení pomocí účtu Google u poskytovatele služby Plaxo. Zvolení OpenID zobrazí zadávací pole pro vložení identifikátoru, kde uživatel musí zadat složitou adresu uvedenou v Př. 3.6. Volba Google provede rovnou přesměrování; převzato z [16]

Obrázek 3.4: Průběh OpenID autentizace s použitím účtu Google; převzato z [15]

3.3. MOJEID

3.3

19

MojeID

Identita MojeID je implementací protokolu OpenID správcem národní domény .cz sdružením CZ.NIC [17]. Projekt funguje od roku 2010, domovské stránky jsou na [7]. Cílem projektu MojeID je jednak rozšíření použití OpenID mezi českými uživateli, ale MojeID se dále profiluje myšlenkou na vytvoření ekvivalentu občanského průkazu v elektronické podobě. Pravidla použití MojeID jsou tedy nastavena tak, aby uživateli umožňovala založení a udržování pouze jedné identity. Prakticky je toto ošetřeno validací každého uživatele po registraci prostřednictvím zadaného telefonního čísla a korespondenční adresy, nejvyšší stupeň validace využívá dokonce fyzické ověření totožnosti proti občanskému průkazu. Poskytovatel služby tedy dostává jistotu pravdivé identity uživatelů a rozsah působnosti OpenID je tímto eventuálně rozšířen i do sféry např. peněžních ústavů či státní správy. Důvěryhodnost pro poskytnutí takto detailních údajů MojeID proklamuje na základě technických zkušeností sdružení CZ.NIC, a na nezávislosti tohoto subjektu v českém prostředí, tedy záruce nezneužití např. pro marketingové účely. Autentizace s MojeID se z technického hlediska neliší od OpenID. URL adresa koncového bodu OP MojeID je uvedena v Př. 3.7. Pro účely rozpoznání uživatele v OpenID odpovědi je doporučeno použití parametru openid.identity, kde MojeID poskytuje svůj lokální identifikátor vytvořený hash funkcí z údajů uživatele, viz Př. 3.8. Lze tak zamezit záměně uživatelů na straně RP v případě, že si první uživatel zruší účet, a jiný využije uvolněný identifikátor. https : / / mojeid . cz / endpoint /

Příklad 3.7: URL adresa OpenID koncového bodu poskytovatele MojeID

openid . claimed_id=https : / / jan−novak . mojeid . cz / openid . identity=https : / / mojeid . cz / id /3 kak1biwVf /

Příklad 3.8: Příklad návratových hodnot parametrů openid.claimed_id a openid.identity v odpovědi autentizace u poskytovatele MojeID

3.4

Shibboleth

Shibboleth je open-source technologie, která umožňuje single-sign-on přístup ke službám uvnitř organizace i napříč doménami. Primárně byla vyvinutá pro vědecko-výzkumnou oblast, akademickou komunitu, a vybrané organizace veřejné správy. První kompletní specifikace Shibboleth 1.0 byla vydána v roce 2003, od roku 2008 je k dispozici aktuální verze 2.0. Vývoj zaštiťuje organizace Internet2 [18]. Domovské stránky technologie Shibboleth lze nalézt na [19], specifikaci protokolu na [20]. Technologie Shibboleth je od svého počátku cílena na využití mezi institucemi. V autentizaci a autorizaci přístupů jsou proto spíše než user-controlled uplatňovány businessto-business scénáře. Domovská instituce uživatele uzavírá smluvní závazek s další institucí,

20


který upravuje podmínky a pravidla vzájemného přístupu. Např. předávání hodnot uživatelských atributů proto nemusí odsouhlasovat jednotliví uživatelé při každém přístupu. Předání je automaticky uskutečněno na základě důvěry uživatele ke své domovské instituci, která na základě smluvního závazku věří cílové instituci. Na rozdíl od technologie OpenID zde poskytovatel identity často funguje i jako poskytovatel služby. Výhodou vzájemné důvěryhodnosti partnerských stran je, že autentizace a správa uživatelských údajů je ponechána na straně domácí instituce, zatímco cílová instituce určuje pouze autorizační pravidla. Způsob autentizace není technologicky předepsán, ale může být předmětem smluvního závazku při navázání spolupráce. Přístup na straně cílové instituce je řízen na základě domácí institucí předaných atributů o žádajícím uživateli, a to vždy v reálném čase přístupu, takže poskytovateli jsou dodány vždy aktuální a platné údaje. Tyto údaje se navíc obvykle nemusí týkat konkrétního uživatele, ale stačí obecnější informace, např. vztah k domácí instituci. Tento vztah může být předán podle potřeby cílové instituce na různých úrovních detailů. Např. tedy student, student–student na katedře počítačů či student–student kurzu X36MTI. Důležitým faktem tedy je, že uživatel nemá duplikovaný uživatelský účet vedený v cílové instituci, a proto když se změní jeho role v rámci domácí instituce, jeho přístup do cílové instituce je také okamžitě ovlivněn. Atributy identity nejsou technologií nijak předepisovány, důležité pouze je, aby jejich významu rozuměl stejně jak poskytovatel identity, tak poskytovatel služby. Např. v akademické sféře je proto používán objekt EduPerson [21], který je rozšířením LDAP třídy inetOrgPerson. Pro komunikaci mezi poskytovatelem identity a poskytovatelem služby je v technologii Shibboleth využíván otevřený standard SAML (Security Assertion Markup Language) [22], založený na technologii XML, určený k výměně autentizačních a autorizačních údajů mezi doménami, nezávisle na lokálních implementacích. SAML zprávy jsou dále zapouzdřeny ve standardních http(s) žádostech a odpovědích. Na straně klienta tak nejsou vyžadovány žádné úpravy. Nejen akademická sféra také vybízí k zavedení mnohostranných vztahů důvěry mezi institucemi, např. mezi všemi univerzitami. Pro zjednodušení tohoto problému zavádí Shibboleth pojem federace, který představuje množinu subjektů, do které se mohou instituce sdružovat a jednoduše tak navázat spolupráci se všemi ostatními, týkající se sdílení prostředků a politik přístupů k nim. Mezi podmínkami pro vstup do federace může být např. splnění úrovně bezpečnostního auditu a zajištění kompatibility technických prostředků. V akademické sféře tyto federace fungují často na celonárodní úrovni. V České Republice funguje federace eduID.cz [23], kde v roli poskytovatelů identit vystupují české univerzity či knihovny a navzájem uživatelům poskytují přístup ke svým službám. Operátorem federace je CESNET [24].

3.4.1

Průběh autentizace a autorizace

Typický průběh přístupu k chráněnému sdílenému prostředku probíhá podle schématu zachyceném na Obr. 3.5. 1. Uživatel prostřednictvím svého agenta přistoupí k cílovému prostředku.

3.4. SHIBBOLETH

21

Obrázek 3.5: Průběh autentizace v technologii Shibboleth; s úpravami převzato z [25] 2. Pokud poskytovatel služby dosud uživatele neidentifikoval (první přístup), iniciuje autentizační proces přesměrováním uživatelova agenta na přihlašovací stránky poskytovatele identity. Pokud tento není zatím znám, proběhne přesměrování na server služby WAYF (Where Are You From). S použitím této služby není nutné, aby si všichni poskytovatelé služeb pamatovali všechny poskytovatele identit, stačí, pokud používají známou WAYF službu. 3. Server WAYF přijme požadavek od poskytovatele služby a zobrazí uživateli stránku, kde může zvolit svou domácí instituci, u které se hodlá autentizovat. 4. Uživatel zvolí svou domovskou instituci. Tato volba může být např. ze seznamu členů federace, kterou služba WAYF obsluhuje 5. Uživatel je přesměrován na stránky zvoleného poskytovatele identity. Pokud se již v dané relaci autentizoval, zafunguje princip single-sign-on a proces pokračuje s příznakem úspěšné autentizace (kroky 6 a 7 jsou přeskočeny). V opačném případě následuje proces běžného ověření uživatelovy identity. 6. Uživatel je vyzván k autentizaci, která je totožná jako při přístupu k prostředkům

22


v rámci instituce. Metoda autentizace závisí pouze na poskytovateli identity. 7. Uživatel se autentizuje, např. vložením uživatelského jména a hesla. 8. Po úspěšné autentizaci je uživatel přesměrován zpět na cíl obdržený v autentizační žádosti, tedy na stránky poskytovatele služeb, s příznakem úspěšné autentizace a dočasným identifikátorem (není předána samotná identita). Na straně poskytovatele služby je obvykle vyhrazená služba určená k vyhodnocování žádostí o přístup k prostředkům (assertion consumer service), která vyhodnotí přijatou žádost. 9. Pokud pravidla přístupu k žádanému prostředku definují striktnější politiku, než povolení přístupu libovolnému autentizovanému uživateli, je třeba zjistit o uživateli doplňující atributy. Toto volání může být vyřízeno přímo, bez nutnosti přesměrování uživatelského klienta (pokud není k předání údajů potřeba potvrzení uživatele). Pravost této žádosti je zkontrolována vyhrazenou částí serveru poskytovatele identity (služba řešení artefaktů). Pokud je žádost platná, jsou v databázi vyhledány potřebné atributy uživatele. 10. Žádané uživatelské atributy jsou odeslány poskytovateli služby. Ten na základě přijatých atributů může rozhodnout o povolení přístupu k prostředku.

Kapitola 4

Nasazení technologie OpenID v Microsoft Azure Tato kapitola se věnuje praktické implementaci technologie federace identit v cloud prostředí Microsoft Azure. Na začátku je krátké teoretické zhodnocení možnosti nasaditelnosti technologie do cloud prostředí a jsou zmíněny základní oblasti, které jsou charakteristické pro cloud a které je potřeba brát v úvahu při nasazení. Hlavní náplní kapitoly je mapování praktických úprav, které bylo nutné provést do výchozí distribuované knihovny, vyplývající z nasazení do Microsoft Azure a souvisejícího běhu na webovém serveru Microsoft IIS. Pro praktické nasazení v prostředí Azure byla vybrána technologie OpenID. Tato technologie je vhodnější k použití u veřejné služby cílené na individuální uživatele než technologie Shibboleth, která je běžnější v enterprise sféře. Z důvodu vysokého počtu již existujících účtů, tedy potenciálních uživatelů služby, může být pro poskytovatele služby atraktivní podpora autentizace prostřednictvím účtu Google. Díky podpoře OpenID jsou ale tyto účty implementací technologie OpenID pokryty. Jako jazyk implementace byl zvolen jazyk PHP, který je v oblasti vývoje webových služeb široce rozšířený. Při volbě tohoto jazyka lze také dobře posoudit možnosti vývoje pro Microsoft Azure v jiném než hlavním podporovaném jazyce, kterým je ASP .NET. Jako výchozí knihovna byla vybrána knihovna JanRain OpenID PHP5 [3], která je doporučována k použití s jazykem PHP organizací OpenID Foundation i poskytovateli MyOpenID a MojeID.

4.1

Teoretická využitelnost federace identit v cloud prostředí

Během teoretického studia technologií OpenID a Shibboleth nebyla objevena jednoznačná překážka zabraňující možné funkčnosti v cloud prostředí. Obě využívají pro komunikaci mezi zúčastněnými stranami standardní http(s) žádosti a komunikují tedy na portu 80, resp. 443. Z tohoto důvodu není ani nutné např. nastavovat ve firewallu výjimky pro nový komunikační protokol. Obecný teoretický předpoklad funkčnosti dále podporuje fakt, že v prostředí Azure je již možné využívat autentizaci pomocí Microsoft LiveID [26], která také využívá dedikovaný autentizační server a svou architekturou tedy konceptuálně odpovídá technologii OpenID i Shibboleth. 23

24

KAPITOLA 4. NASAZENÍ TECHNOLOGIE OPENID V MICROSOFT AZURE

Při implementaci je však třeba brát ohled na obecná specifika nasazení aplikace do prostředí cloudu, zejména doporučený běh na více instancích serveru a tedy možnou potřebu sdílení dat, či neperzistentnost ukládání dat na lokální disk v prostředí cloudu. Při výběru technologie federace identit, zejména konkrétní knihovny, je tedy nutné provést detailní analýzu funkce knihovny se zaměřením na tok dat, i dočasných, využívaných v průběhu autentizace. Při nasazení knihovny do cloudu Microsoft Azure je také nebytné vzít v úvahu nutnost podpory webového serveru Microsoft IIS a potřebu případného odlišného nastavení od nasazení na jiných webových serverech.

4.2

Obecné úpravy pro nasazení v MS Azure

Základní úpravy, které je nutné provést při nasazení technologie federace identit v prostředí Azure, souvisejí především v ukládání provozních dat potřebných v procesu autentizace, např. asociace serverů. Při integraci knihovny s uživatelskou službou je navíc pravděpodobné, i za předpokladu neuvažování datového uložiště samotné služby, že služba bude potřebovat mít uložená data o uživateli. A to i přesto, že identita je spravována poskytovatelem identity. Daty souvisejícími s identitou může být např. část uživatelského profilu charakteristického pouze pro danou službu, jako je příslušnost ke skupině, uživatelská oprávnění, apod. V prostředí Azure je nutné uvažovat lokální disk za neperzistentní uložiště dat. Ke ztrátě dat na lokálním disku konkrétního virtuálního serveru s nasazenou aplikací dojde nejen při selhání serveru, ale i při automatizovaném přenesení aplikace na jiný server, např. z důvodu údržby. Dále je nutné dle charakteru dat určit nutnost jejich sdílení mezi jednotlivými instancemi serverů, které v případě využití lokálního pevného disku také není možné. Pokud tedy aplikace či technologie federace identit využívají jako primární uložiště pevný disk, je při nasazení do Azure nutné provést úpravy pro využití jiného datového prostoru. Pro trvalé uchování dat s možností sdílení nabízí Azure možnost využití Azure Storage [27] nebo databázového uložiště SQL Azure [28]. Tato uložiště jsou dostupná z každé instance serveru, případně k nim lze přistupovat i z aplikace běžící mimo Azure, viz Obr. 4.1.

4.3

Použité programové prostředky

V praktické implementaci byly použity následující prostředky: • knihovna OpenID: JanRain OpenID PHP5 http://www.janrain.com/openid-enabled • PHP: PHP 5.3 VC9 NTS http://windows.php.net/ – verze VC9 určená pro webový server IIS – pro OpenID knihovnu potřebná některá rozšíření: CURL, XML parser, GMP – součástí distribuce, framework PEAR – součástí distribuce, nutno doinstalovat balík MDB2

4.4. ÚPRAVA KNIHOVNY

25

Obrázek 4.1: Schéma provozu PHP aplikace v prostředí Azure a dostupná uložiště. Každá instance virtuálního serveru má k dispozici lokální disk použitelný pro dočasná data bez potřeby sdílení. Pro perzistentní uložení dat mohou instance využívat uložiště Azure Storage a SQL Azure; s úpravami převzato z [29] – nutno přidat MS SQL driver pro odpovídající verzi PHP: sqlsrv_53_nts_VC9.dll http://www.microsoft.com/download/en/details.aspx?id=20098 • vývoj pro Azure: Windows Azure SDK v1.3 http://www.microsoft.com/windowsazure/newinsdk1.3/ • podpora vývoje pro Azure a tvorba balíčků k nasazení: Windows Azure Tools 4 Eclipse http://www.windowsazure4e.org

4.4

Úprava knihovny

Teoretický popis procesu autentizace technologie OpenID, viz kap. 3.1, ukazuje, že protokol může fungovat bez ukládání stavu, v tzv. dumb módu. Tento mód je však nevýhodný zejména proto, že protokol je v krátkém časovém okně mezi přijetím potvrzení identity a jeho ověřením napadnutelný replay útokem. Při ukládání stavu, v tzv. stateful módu, protokol funguje efektivněji a bezpečněji. Odpadá nutnost dodatečného volání serveru o ověření potvrzení při každé autentizaci a je eliminována možnost replay útoku. Při tomto nastavení musí být uchovávány navázané asociace mezi poskytovatelem služby a poskytovateli identit a také nonces jednotlivých odpovědí. Asociace jsou využívány pro ověření integrity přijaté autentizace, (viz Obr. 3.2, krok 2) , nonces zajišťují unikátnost přijaté autentizační odpovědi (viz Obr. 3.2, krok 5). Charakter dat určuje, že asociace i nonces záznamy je nutné

26


uchovávat dlouhodobě, tzn. v perzistentním uložišti, a v případě běhu na více instancích serverů je nezbytná jejich dostupnost ze všech instancí. Distribuovaná JanRain OpenID knihovna nabízí jako uložiště pro asociace a nonces lokální pevný disk nebo možnost využití databázového uložiště. Ukládání na lokální disk by při dodržení zápisu do povolené oblasti disku fungovalo i při nasazení do Azure, avšak lokální disk v tomto případě nesplňuje kritéria perzistentního uložiště s možností sdílení dat. Dedikované databázové uložiště těmto kritériím vyhovuje, avšak knihovna v distribuované podobě nabízí pouze podporu databázových serverů MySQL, PostgreSQL a SQLite. Podporován tedy není MS SQL server, který je základem SQL Azure. Toto uložiště tedy také nelze bez úprav použít. Základní úpravou, kterou bylo nutné pro použití knihovny v MS Azure udělat, byla tedy změna použitého datového uložiště pro uchovávání asociací a nonces záznamů.

4.4.1

Volba datového uložiště

Knihovna JanRain OpenID PHP má pro potřebu změny uložiště vhodně navržený design, kdy využívá rozhraní Auth_OpenID_OpenIDStore, které abstraktně definuje metody manipulace s daty, zejména ukládání a načítání asociací a použití nonces záznamů. Konkrétní implementaci těchto metod zajišťují třídy reprezentující jednotlivá datová uložiště, které implementují toto rozhraní, viz Obr. 4.2. Distribuovaný balík knihovny podporuje dva druhy práce s daty – ukládání do souborů na pevný disk (třída Auth_OpenID_FileStore) a ukládání do tabulek na SQL server (třída Auth_OpenID_SQLStore). Poslední třída implementující rozhraní OpenIDStore (třída Auth_OpenID_DumbStore) reprezentuje dumb mód protokolu, který neuchovává žádná data. Podporu nového způsobu ukládání dat je tedy možné implementovat vytvořením nové třídy, která bude definovat metody rozhraní Auth_OpenID_OpenIDStore.

Obrázek 4.2: Konceptuální diagram tříd znázorňující design rozhraní OpenIDStore, které abstraktně definuje metody práce s asociacemi a nonces, a třídy reprezentující různá datová uložiště, které tyto metody implementují Perzistentní uložiště s možností sdílení dat v prostředí Azure nabízí Azure Storage [27] a SQL Azure [28]. Postup při migraci služby pro nasazení v MS Azure by měl zahrnovat


27

i ekonomickou analýzu, která zohledňuje cenové náklady využití daného typu uložiště. V případě migrace knihovny by však tato analýza nebyla relevantní, protože výsledné náklady jsou dány četností využití ve službě, která knihovnu implementuje. Rozhodnutí volby datového uložiště bylo v tomto případě motivováno principem, že knihovna by dle možností neměla uživatele omezovat, ale naopak nabízet co nejširší využití. Proto bylo rozhodnuto o implementaci podpory obou uložišť. Možnost výběru uložiště podpoří i ekonomický pohled, protože poskytovatel služby využívající knihovnu nebude povinen platit i za službu Azure Storage, pokud jeho služba využívá pro zbytek svých dat pouze SQL Azure, a naopak. Implementace podpory uložiště Azure Storage je popsána v sekci 4.4.2, implementace části SQL Azure poté v 4.4.3, resp. 4.4.5.

4.4.2

Přidání podpory Azure Storage

Služba BLOB uložiště Azure Storage umožňuje ukládat binární data a lze jí tedy připodobnit způsobu ukládání na pevný disk. Při implementaci podpory uložiště Azure Storage bylo tedy vhodné vycházet z třídy Auth_OpenID_FileStore. Z pohledu architektury knihovny je však třída Auth_OpenID_AzureStorageStore, která byla vytvořena pro tento účel, novou implementací rozhranní Auth_OpenID_OpenIDStore, viz Obr. 4.3.

Obrázek 4.3: Konceptuální diagram tříd znázorňující rozšíření podpory knihovny o uložiště Azure Storage, které je reprezentováno třídou AzureStorageStore. Ta implementuje rozhraní OpenIDStore Pro práci s uložištěm Azure Storage je nezbytné využít Azure Storage knihovní funkce zprostředkovávající jednoduché volání metod umožňujících CRUD funkčnost nad kontejnery a bloby. Tato knihovna je distibuována s Windows Azure SDK pro PHP a její použití významně zjednodušuje použitý vývojový nástroj Windows Azure Tools 4 Eclipse. Tomuto nástroji se samostatně věnuje kap. 4.6. K provádění operací v uložišti Azure Storage je potřeba vytvoření klienta, který slouží k volání všech funkcí. V implementaci třídy Auth_OpenID_AzureStorageStore je tento klient vytvořen již v konstruktoru třídy, protože jeho správná inicializace a následná dostupnost Azure Storage je nezbytná pro další fungování třídy. Knihovní funkce SDK umožňují načtení konfigurace uložiště přímo z konfiguračního souboru Azure balíčku, souboru ServiceConfiguration.cscfg. Implementace podporuje i využití vývojového Storage emulátoru. V konfiguračním souboru je kromě druhu nasazení (parametr UseDevelopmentStorage nebo

28

KAPITOLA 4. NASAZENÍ TECHNOLOGIE OPENID V MICROSOFT AZURE Název může obsahovat pouze písmena, čísla, a pomlčky Název musí začínat písmenem nebo číslicí V názvu nejsou povoleny navazující pomlčky Všechna písmena v názvu musí být malá Název musí být dlouhý od 3 do 63 znaků Tabulka 4.1: Omezení názvů kontejnerů v Azure Storage

UseCloudStorage) nutné specifikovat název a klíč k přístupu k Azure Storage účtu (parametry StorageAccountName a StorageAccountKey). Kód vytváření klienta je uveden v Kód. 4.1.

function _ c r e a t e B l o b S t o r a g e C l i e n t ( ) { // k l i e n t pro v y u ž i t í u l o ž i š t ě v MS Azure i f ( a zu re_g e tc on fi g ( ' UseDevelopmentStorage ' ) == ' f a l s e ' && a zu re _g e tc on fi g ( ' ←U s e C l o u d S t o r a g e ' ) == ' t r u e ' ) { $host = M i c r o s o f t _ W i n d o w s A z u r e _ S t o r a g e : : URL_C LOUD_BLO B ; $accountName = a zu re _g e tc on fi g ( ' StorageAccountName ' ) ; $accountKey = a zu re _g e tc on fi g ( ' StorageAccountKey ' ) ; $ u s e Pa t h S t y l eU r i = f a l s e ; $retryPolicy = M i c r o s o f t _ W i n d o w s A z u r e _ R e t r y P o l i c y _ R e t r y P o l i c y A b s t r a c t : : ←retryN ( 1 0 , 2 5 0 ) ; $ b l o b S t o r a g e C l i e n t = new M i c r o s o f t _ W i n d o w s A z u r e _ S t o r a g e _ B l o b ( $host , $accountName , $accountKey , $usePathStyleUri , $retryPolicy ); } else { // k l i e n t pro v y u ž i t í Azure S t o r a g e e m u l á t o r u $ b l o b S t o r a g e C l i e n t = new M i c r o s o f t _ W i n d o w s A z u r e _ S t o r a g e _ B l o b ( ) ; } }

return $ b l o b S t o r a g e C l i e n t ;

Kód 4.1: Vytvoření klienta pro provádění operací s Azure Storage. Dle nastavení v konfiguračním souboru balíčku je inicializován buď klient pro použití s vývojovým Azure Storage emulátorem nebo klient pro komunikaci s uložištěm v MS Azure. Implementace třídy navrhuje výchozí názvy kontejnerů pro uložení asociací a nonces záznamů (associations a nonces). Tyto názvy je možné předáním parametrů konstruktoru třídy předefinovat, ale je nutné zohlednit omezení, která jsou kladena na názvy zdrojů v Azure Storage. Kompletní seznam omezení lze najít na [30], Tab. 4.1 shrnuje omezení platná pro názvy kontejnerů. Knihovní funkce pro ukládání dat do blobu pracuje s lokálním souborem obsahujícím data k uložení, podobně funkce pro načtení dat z blobu také neumí data načítat přímo do paměti, ale ukládá je do lokálního souboru. Velká část kódu pro zpracování obsahu dat mohla tedy být využita z třídy FileStore a změny byly provedeny hlavně ve funkcích pro


29

načítání a ukládání asociací a u použití nonce záznamů. Pro přehlednost byly ve většině případů zachovány i původní názvy privátních metod, pokud jejich modifikovaná funkčnost v principu odpovídá původní. MS Azure uplatňuje silná omezení možnosti zápisu na lokální disk, přičemž podobná omezení se neprojeví při běhu v lokálním emulátoru. S tímto faktem je třeba počítat při volbě lokace zápisu na lokální disk. Implementovaná třída ve výchozím nastavení pracuje s TEMP adresářem instance, ale toto nastavení může implementátor změnit voláním metody _mkstemp s parametrem cesty k požadovanému adresáři. Důraz při testování byl kladen na úklid použitého dočasného souboru v okamžiku, kdy je obsah využit a samotný soubor již není potřebný, aby při běhu knihovny nedocházelo k zanechávání nepotřebných souborů. Kód. 4.2 uvádí příklad implementované metody pro práci s Azure Storage, metodu _getBlob, která načítá data z blobu a ukládá je do dočasného souboru. Vrácen je odkaz na tento soubor, aby bylo možné s ním dále pracovat. Funkce provádí např. kontrolu existence požadovaného blobu, protože k prostředkům uložiště Azure Storage se přistupuje pomocí URI lokátorů a požadavek na neplatný blob by skončil http chybou. Využívány jsou CRUD funkce poskytované Azure Storage knihovnou (fce blobExists, getBlob, apod.), které jsou volány prostřednictvím dříve vytvořeného klienta blobStorageClient, viz. Kód. 4.1.

function _getBlob ( $containerName , $blobName ) { // k o n t r o l a e x i s t e n c e blobu i f ( ! $this−>_blobExists ( $containerName , $blobName ) ) { return null ; } // v y t v o r e n i d o c a s n e h o s ou bor u i f ( ! $temp _fileNam e = $this−>_mkstemp ( ) ) { return null ; } try { // n a c t e n i dat z blobu a u l o z e n i do d o c a s n e h o so ub or u $this−>blobStorageClient−>getBlob ( $containerName , $blobName , $temp _fileNam e←);

}

i f ( f i l e s i z e ( $temp _fileNam e ) == 0 ) { @unlink ( $temp _fileNam e ) ; return null ; } } catch ( M i c r o s o f t _ W i n d o w s A z u r e _ E x c e p t i o n $e ) { t r i g g e r _ e r r o r ( ' Windows Azure S t o r a g e E r r o r : ' . $e−>getMessage ( ) , ←E_USER_ERROR ) ; @unlink ( $temp _fileNam e ) ; return null ; } return $temp_ fileName ;

Kód 4.2: Příklad funkce pro práci s uložištěm Azure Storage. Funkce načítá data z blobu a ukládá je do dočasného souboru na lokálním disku. Využity jsou funkce Azure Storage knihovny blobExists a getBlob

30

4.4.3


Přidání podpory MS SQL

Design knihovny související s využitím SQL uložiště vychází z třídy Auth_OpenID_ SQLStore. Při implementaci podpory uložiště SQL Azure, jakožto relační databáze, je tedy užitečné vycházet z této třídy. SQLStore počítá s ukládáním do tabulkové struktury, proto s daty pracuje v podobě entit a jejich atributů. Např. v případě asociace je hlavní entitou adresa serveru poskytovatele identity, se kterým byla navázána asociace, a atributy jsou typ asociace, druh šifrování, heslo, apod. Třída Auth_OpenID_SQLStore implementuje společné funkce pro práci s daty definované v rozhraní Auth_OpenID_OpenIDStore, a doplňuje funkcionalitu specifickou pro SQL uložiště. Třída využívá abstrakci databázové vrstvy prostřednictvím frameworku PEAR [31], díky které není knihovna vázána na použití konkrétního RDBMS. Třída SQLStore tak implementuje společnou logiku a tuto třídu rozšiřují třídy implementující specifika konkrétního RDBMS. Tyto podtřídy zejména poskytují třídě SQLStore DDL a DML SQL řetězce (funkce setSQL()). Podtřídy dále upravují případné odlišnosti od obecné implementace, např. pokud je nutné použít jinou konstrukci volání SQL příkazu či pokud je nutná konverze dat před uložením do DB. Tento design je zachycen na Obr. 4.4. Distribuční balík knihovny podporuje koncovou SQL vrstvu databází MySQL, PostgreSQL a SQLLite. Pro využití v prostředí Azure bylo tedy nutné doimplementovat podporu MS SQL Serveru, který je základem pro SQL Azure. Díky výše diskutovanému designu lze tohoto dosáhnout vytvořením potomka třídy SQLStore s definicí vhodných MS SQL kostrukcí a implementací metod odlišných pro databázi MS SQL, viz Obr. 4.4.

Obrázek 4.4: Konceptuální diagram tříd znázorňující design třídy SQLStore. Tuto abstraktní třídu rozšiřují třídy implementující specifickou funkčnost pro konkrétní RDBMS. Třídu MSSQLStore podporující MS SQL Server bylo potřeba doimplementovat Pro zachování jednotnosti vychází nově vytvořená třída MSSQLStore z třídy MySQLStore. Zpočátku šlo s výhodou využít téměř totožné syntaxe SQL příkazů, ve kterých byly


31

UPDATE %1\$s SET server_url =: server_url , handle =: handle , secret=CONVERT( VARBINARY←( 2 5 5 ) , : secret ) , issued =: issued , lifetime =: lifetime , assoc_type =: assoc_type ←WHERE ( server_url =: server_url AND handle =: handle ) ; IF @@ROWCOUNT=0 INSERT INTO %1\$s VALUES ( : server_url , : handle , CONVERT( VARBINARY←( 2 5 5 ) , : secret ) , : issued , : lifetime , : assoc_type ) ;

Kód 4.3: SQL příkaz pro uložení asociace upravený pro MS SQL Server. Placeholder %1\$s je před voláním nahrazen jménem tabulky s asociacemi

provedeny pouze detailní úpravy pro přizpůsobení MS SQL Serveru, např. byl změněn datový typ BLOB na VARBINARY. Výjimkou byl SQL příkaz pro nastavení asociace, kde třída MySQLStore využívá nepodporovanou konstrukci REPLACE. Příkaz proto musel být změněn s využitím syntaxe podporované MS SQL. Řešení bylo implementováno s použitím dvou SQL příkazů UPDATE a INSERT, avšak odlišně od třídy PostgreSQLStore, kde je řešen stejný problém a k provedení těchto příkazů je potřeba dvou volání mezi aplikací a DB. Pro omezení nadbytečné komunikace bylo použito konstrukce IF @@ROWCOUNT=0, díky které je počet ovlivněných řádků po provedení části UPDATE zjištěn již na straně DB a případné vložení nové hodnoty je provedeno okamžitě. Z důvodu opakovaného použití hodnot dosazovaných do příkazu byly pro efektivnost a zlepšení přehlednosti zavedeny jmenné zástupné symboly (placeholdery). Pro jejich podporu však musela být funkce _set_assoc() předefinována oproti výchozí třídě SQLStore. MS SQL také nepodporuje implicitní konverzi datového typu STRING na VARBINARY, proto byla tato konverze do SQL příkazu doplněna. Výslednou implementaci příkazu uvádí Kód. 4.3. Tato podoba však musela být později dále upravena pro použití s SQL Azure. Podrobnosti těchto úprav jsou uvedeny v samostatné sekci 4.4.5.

4.4.4

Náhrada balíku PEAR DB

Implementace třídy Auth_OpenID_MSSQL pro podporu koncové vrstvy MS SQL Server se ukázála nedostačující, neboť základní třída Auth_OpenID_SQLStore, pracující s abstrakcí databázové vrstvy, vychází z použití balíku PEAR DB [32]. Tento je sice stále podporovaný, avšak již nahrazený. Pro práci s MS SQL podporuje využití ovladače mssql.dll, který již není s PHP 5.3 distribuován z důvodu omezení podpory na oficiální ovladač sqldrv.dll vyvíjený společností Microsoft. Pro práci s SQL Azure, která je možná pouze prostřednictvím ovladače sqlsrv bylo tedy nutné nahrazení balíku DB novějším balíkem MDB2 [33]. Toto nahrazení je žádoucí i pro budoucí zachování funkce s ostatními RDBMS, až přestane být balík DB podporován. Komplikací při zaměňování balíku DB se ukázal být fakt, že novější balík MDB2 není s balíkem DB zpětně kompatibilní. Není tedy možné jednoduše importovat nový balík, protože balík MDB2 definuje pro stejnou práci nad daty odlišné názvy i syntaxi některých metod. Významně se liší např. řízení transakcí. Do třídy Auth_OpenID_SQLStore bylo tedy nutné provést změny odpovídající použití balíku MDB2. Nahrazování bylo prováděno procházením kódu a hledáním ekvivalentu metody starého balíku metodou nového balíku dle dokumentace na oficiálních stránkách. Kontrola probíhala s využitím externího zdroje zabývajícím se stejnou migrací [34]. Příklad změny lze dobře

32


demonstrovat na funkci pro úklid prošlých asociací cleanupAssociations(), viz Kód. 4.4. Liší se řízení transakce, funkce pro provedení SQL příkazu má jiný název a pro její volání je potřeba načtení rozšířeného modulu Extended (provedeno na jiném místě kódu). Funkce také narozdíl od původní přímo vrací počet ovlivněných řádků. Vzhledem k faktu, že úpravy kódu původní třídy po migraci na balík MDB2 nemohly být z důvodu nedostatku zdrojů otestovány na ostatních RDBMS, není jisté, zda nedošlo k ovlivnění funkčnosti jejich reprezentujících podtříd. Z tohoto důvodu byla místo nahrazení původní třídy vytvořena nová třída Auth_OpenID_SQLStore2. Tato třída bude moci po otestování s ostatními databázovými vrstvami nahradit původní třídu v distribučním balíku knihovny.

// B a l i k PEAR DB function c l e a n u p A s s o c i a t i o n s ( ) { $this−>connection−>query ( $this−>sql [ ' c l e a n _ a s s o c ' ] , a r r a y ( time ( ) ) ) ; $num = $this−>connection−>affectedRows ( ) ; $this−>connection−>commit ( ) ; return $num ; } // B a l i k PEAR MDB2 function c l e a n u p A s s o c i a t i o n s ( ) { $this−>connection−>b e g i n T r a n s a c ti o n ( ) ; $num = $this−>connection−>extended−>execParam ( $this−>sql [ ' c l e a n _ a s s o c ' ] , a r r a y ( time ( ) ) ) ; i f ( $this−>connection−>in_tr ansactio n ) { $this−>connection−>commit ( ) ; } return $num ; }

Kód 4.4: Příklad rozdílu syntaxe balíků PEAR DB a PEAR MDB2. V balíku MDB2 je potřeba explicitně začít transakci, funkce pro provedení SQL DML příkazu má jiný název i syntaxi a vrací přímo počet ovlivněných řádků. Pro její volání je dále potřeba mít načtený modul Extended (provedeno na jiném místě kódu)

4.4.5

Úprava pro SQL Azure

Po vytvoření třídy s podporou databázového serveru MS SQL a implementaci balíku MDB2 pro podporu připojení přes ovladač sqlsrv.dll byla úspěšně lokálně otestována funkčnost knihovny s využitím MS SQL Serveru jako databázové vrstvy uložiště dat. Práce s SQL Azure je totožná s on-premise SQL serverem, proto pro změnu na využití SQL Azure stačí změnit připojovací parametry při vytváření připojení k databázi. Při nastavení využití SQL Azure však knihovna přestala správným způsobem fungovat a bylo tedy patrné, že je potřeba nově vytvořenou MS SQL část knihovny dodatečně uzpůsobit pro běh přímo v SQL Azure.

4.4. ÚPRAVA KNIHOVNY PHP ovladač Transakce Znaková sada Indexování

33

pouze SQL Server 2008 pro PHP, v. 1.1 nebo pozdější nejsou podporovány distribuované transakce podpora pouze SQL_LATIN1_GENERAL_CP1_CI_AS požadavek na clustered index u každé tabulky

Tabulka 4.2: Vybraná omezení databáze SQL Azure Databázový server SQL Azure je stejně jako další části prostředí MS Azure stále ve vývoji a v současné době nepodporuje všechny funkce MS SQL Serveru. Omezení a doporučené postupy při návrhu lze nalézt na [35], některá z nich jsou shrnuta v Tab. 4.2. Tato omezení bylo proto třeba zohlednit i při úpravě knihovny. Aplikovat bylo nutné hlavně požadavek na existenci clustered indexu v každé tabulce, kdy původní návrh schématu převzatý z třídy MySQLStore nevytvářel index v tabulce nonces záznamů. Přidávání položek z tohoto důvodu končilo chybou. Po změně bylo zajištěno opětovné ukládání asociací i nonces záznamů. Knihovna však na rozdíl od on-premise MS SQL Express serveru stále nefungovala korektně, kdy proces autentizace byl zakončen chybou BAD SIGNATURE. Tato chyba signalizovala problém při potvrzování pravosti přijatého autentizačního potvrzení, tedy související s asociací komunikujících stran. Při krokování procesu bylo objeveno, že heslo ukládané do DB při zakládání asociace neodpovídalo heslu načtenému k závěrečnému porovnání. Problém byl výsledně identifikován v použitém nastavení znakové sady, resp. porovnávání. Testovací lokální MS SQL Server byl nastaven na porovnávání SQL_LATIN1_CP1250 s podporou českých znaků, zatímco SQL Azure využívá anglické porovnávání SQL_LATIN1_GENERAL, v současnosti jediné podporované. Toto nastavení však při provádění SQL příkazu pro uložení asociace změnilo některé speciální znaky, které heslo náhodně obsahuje. Tento jev je způsoben kódováním znaků v MS SQL, které je prováděno po jednotlivých bytech, tedy bez podpory znaků Unicode. S těmito znaky umí pracovat pouze určené datové typy, včetně VARBINARY. Pro odstranění problému s nesprávně uloženým heslem bylo tedy nutné odstínit databázi od práce s heslem v podobě řetězce, tedy odstranit původně použitou konverzi datového typu STRING na VARBINARY na straně databáze. Místo toho lze konverzi provádět již na straně aplikace a databázi předávat heslo v podobě blobu. S možnou nutností takové konverze design knihovny počítá a třída SQLStore nabízí k předefinování funkce blobEncode a blobDecode. Tyto funkce tedy byly doimplementovány do třídy MSSQLStore. Po této úpravě však byla objevena dosud neznámá syntaktická odlišnost balíků PEAR DB a MDB2 a také možná chyba v balíku MDB2. Aby databáze MS SQL správně interpretovala typ předávané hodnoty hesla, je nutné tuto hodnotu správně označit, v případě typu blob (VARBINARY ) bez uvozovek. Balík DB při přípravě SQL příkazu odlišuje dva typy pozičních placeholderů. Placeholder ? slouží pro nahrazení skalární hodnotou - číslem či řetězcem, která je automaticky odpovídajícím způsobem označena. Placeholder ! pak slouží pro vložení skalární hodnoty přesně tak, jak je poskytnuta, tedy bez označení uvozovkami. Balík MDB2 oproti tomu zachovává pouze placeholder ?, kdy odpovídající označení je odvozeno automaticky, případně funkce pro volání SQL příkazů poskytují parametr pro manuální definování vkládaných datových typů. Pro zachování nezávislosti na konkrétní RDBMS definuje MDB2 vlastní obecné datové typy [36], např. typ TEXT pro znakově orientované

34


hodnoty, a definuje i typ BLOB. Volání funkce pro uložení asociace s využitím této syntaxe je uvedeno v Kód. 4.5. Volání této funkce však stále způsobovalo chybu na straně databáze při vkládání asociace, která byla způsobena označením hodnoty hesla uvozovkami. Databáze tedy tuto hodnotu interpretovala jako řetězec a vyžadovala konverzi datového typu. Balík MDB2 zde tedy i přes explicitní určení datového typu hesla chybně označuje jeho hodnotu uvozovkami. Pro vynucení neoznačování hodnoty hesla uvozovkami bylo nutné přepsat podobu funkce pro uložení asociace s využitím funkce quote balíku MDB2. Tato funkce při poskytnutí datového typu správně označuje hodnotu dle tohoto parametru a označení lze i vypnout, tedy dosáhnout ekvivalentu placeholderu ! balíku DB. Funkci quote lze však využít pouze pro přímou manipulaci s SQL řetězcem, který je poté pro spuštění místo funkce execParam volán funkcí exec základního balíku MDB2. Výsledná implementace funkce pro uložení asociace je tedy uvedena v Kód. 4.6. SQL příkaz, který tato funkce využívá je uveden v Kód. 4.7.

4.5

Doplňkové úpravy knihovny

Kromě hlavních úprav, které byly nezbytné z důvodu úpravy knihovny pro nasazení v prostředí Microsoft Azure, byly do originálního balíku knihovny provedeny ještě některé drobné úpravy, které jsou nutné pro plnou funkci, ale nejsou dobře zdokumentovány a mohou tak komplikovat implementaci.

4.5.1

Úprava pro PHP 5.3

Knihovnu JanRain PHP OpenID bylo nutné upravit pro běh pod PHP 5.3, kde způsobovala chybu funkce dl(). Pro tuto úpravu byl použit kód z [37].

4.5.2

Generátor náhodných čísel

Knihovna pro svou funkci potřebuje generátor náhodných čísel. Ten v systému Windows neexistuje a je proto nutné definovat použití pseudonáhodného generátoru, který je součástí kódu knihovny. Před voláním OpenID žádosti je tedy nutné definovat proměnnou Auth_OpenID_RAND_SOURCE na hodnotu null, viz Kód. 4.8. Vhodná pozice pro tuto definici je např. před vrácením objektu Auth_OpenID_Consumer, který je vstupním bodem pro návaznou OpenID komunikaci.

4.5.3

HTTPS komunikace

Knihovna v distribuované verzi neumí pracovat se zabezpečenými servery, tedy při použití komunikace přes protokol https. Toto představuje v technologii OpenID výrazné omezení, protože většina poskytovatelů identit zabezpečenou komunikaci využívá. Omezení je způsobeno výchozím nastavením PHP knihovny CURL, která je nakonfigurována, aby nedůvěřovala žádné certifikační autoritě. Z tohoto důvodu je https certifikát serveru poskytovatele identity odmítnut. Jednou z možností úpravy je knihovnu nastavit, aby neprováděla kontrolu, která certifikační autorita certifikát podepsala (parametr CURLOPT_SSL_VERIFYPEER nastaven

4.5. DOPLŇKOVÉ ÚPRAVY KNIHOVNY

35

function _set_assoc ( $server_url , $handle , $secret , $issued , $lifetime , $assoc_type ) { $res = $this−>connection−>extended−>execParam ( $this−>sql [ ' s e t _ a s s o c ' ] , array ( ' s e r v e r _ u r l ' => $server_url , ' h a n d l e ' => $handle , ' s e c r e t ' => $secret , ' i s s u e d ' => $issued , ' l i f e t i m e ' => $lifetime , ' a s s o c _ t y p e ' => $assoc_type ) , a r r a y ( ' t e x t ' , ' t e x t ' , ' b l o b ' , ' i n t e g e r ' , ' ←integer ' , ' text ' ) ) ; }

Kód 4.5: Funkce pro uložení asociace s využitím balíku MDB2. První parametr funkce execParam je SQL příkaz k vykonání, druhý parametr je pole hodnot k dosazení za definované placeholdery, třetí (nepovinný) parametr je pole manuálně určující datové typy dosazovaných hodnot. SQL příkaz vykonávaný touto funkcí odpovídá Kód. 4.3 bez konverze na straně DB, která je prováděna na straně aplikace.

function _set_assoc ( $server_url , $handle , $secret , $issued , $lifetime , $assoc_type ) { $stmt = s p r i n t f ( $this−>sql [ ' s e t _ a s s o c ' ] , $this−>connection−>quote ( $server_url , ' t e x t ' ) , $this−>connection−>quote ( $handle , ' t e x t ' ) , $this−>connection−>quote ( $secret , ' b l o b ' , f a l s e ) , $this−>connection−>quote ( $issued , ' i n t e g e r ' ) , $this−>connection−>quote ( $lifetime , ' i n t e g e r ' ) , $this−>connection−>quote ( $assoc_type , ' t e x t ' ) ) ; $res = $this−>connection−>e x e c ( $stmt ) ; } }

Kód 4.6: Výsledná implementace funkce pro uložení asociace s využitím balíku MDB2. Použita je funkce quote pro přímou manipulaci s SQL řetězcem pomocí PHP funkce sprintf. Tento postup umožňuje explicitní vypnutí označení hodnoty datového typu blob uvozovkami. Použitý SQL řetězec je načten z pole sql[’set_assoc’] a je uveden v Kód. 4.7.

UPDATE %1\$s SET server_url=%%1\$s , handle=%%2\$s , secret=%%3\$s , issued=%%4\$s , ←lifetime=%%5\$s , assoc_type=%%6\$s WHERE ( server_url=%%1\$s AND handle=%%2\$s ) ; IF @@ROWCOUNT=0 INSERT INTO %1\$s VALUES (%%1\$s , %%2\$s , %%3\$s , %%4\$s , %%5\$s , ←%%6\$s ) ;

Kód 4.7: Výsledná podoba SQL retězce pro uložení asociace. Řetězec je dvakrát zpracován PHP funkcí sprintf, kdy při prvním průchodu je nahrazen placeholder %1\$s jménem tabulky asociací, a při druhém průchodu jsou s využitím funkce quote balíku MDB2 nahrazeny ostatní placeholdery správně označenými hodnotami asociace, viz Kód. 4.6.

36


d e f i n e ( 'Auth_OpenID_RAND_SOURCE ' , null ) ;

Kód 4.8: Definice použití pseudonáhodného generátoru čísel, kterou je v OS Windows nutné uvést před prvním voláním OpenID žádosti

na false), takže je každý certifikát považován za důvěryhodný. V procesu autentizace jsou však předávány důvěrné přihlašovací údaje, takže toto nastavení by představovalo bezpečnostní hrozbu. Vhodnější konfigurace CURL je proto přes nastavení parametru CURLOPT_CAINFO, kterým je možné knihovně nastavit důvěryhodný certifikát. Tento certifikát musí být ve formátu .pem. V projektu byl použit certifikát z domovské stránky knihovny CURL [38]. Požadovaný certifikát je nutné uložit do dostupného uložiště, které ale i v případě nasazení do Azure může být lokální disk, protože není nutné jej sdílet, každá instance může využívat svou lokální kopii. Konfiguraci CURL knihovny je u OpenID knihovny nutné provést ve třídě Auth_Yadis_ ParanoidHTTP Fetcher.php. Nastavení parametrů i cesty k certifikátu musí být před voláním metody curl_exec(), viz Kód. 4.9.

// Trida Auth_Yadis_ParanoidHTTPFetcher . php : i f ( d e f i n e d ( 'Auth_OpenID_VERIFY_HOST ' ) && A u t h _ O p e n I D _ V E R I F Y _ H O S T == f a l s e ) { c u r l _ s e t o p t ( $c , CURLOPT_SSL_VERIFYPEER , f a l s e ) ; } e l s e i f ( d e f i n e d ( 'Auth_OpenID_VERIFY_HOST ' ) ) { c u r l _ s e t o p t ( $c , CURLOPT_SSL_VERIFYPEER , t r u e ) ; c u r l _ s e t o p t ( $c , CURLOPT_SSL_VERIFYHOST , 2 ) ; c u r l _ s e t o p t ( $c , CURLOPT_CAINFO , ' p a t h _ t o _ c e r t i f i c a t e ' ) ; } c u r l _ e x e c ( $c ) ;

Kód 4.9: Konfigurace PHP knihovny CURL pro zajištění funkce s HTTPS servery. Parametr CURLOPT_SSL_VERIFYPEER konfiguruje knihovnu pro kontrolu certifikátu serveru oproti podpisu důvěryhodné certifikační autority. Parametr CURLOPT _SSL_VERIFYHOST s hodnotou 2 znamená kontrolu, že atribut Common Name (CN) existuje a je shodný s atributem Host Name serveru. Parametr CURLOPT_CAINFO definuje cestu k důvěryhodnému certifikátu.

4.6

Windows Azure Tools 4 Eclipse

Při vývoji byl použit nástroj Azure Tools 4 Eclipse, který nabízí funkce, které výrazně zjednodušují vývoj a práci s MS Azure. Jedná se o nástroj ve formě rozšíření do vývojového prostředí Eclipse [39] a je ke stažení zdarma na domovské stránce projektu [40]. Díky integraci přímo do IDE je použití nástroje pohodlné a práci urychluje. Kromě samotného nástroje jsou na uvedené stránce k nalezení i výukové materiály, které na praktických příkladech ilustrují použití nástroje a jeho užitečnost. Příklady obsahují pro objasnění pro-

4.7. DOKUMENTACE

37

blematiky i teoretickou část a mohou tak pomoci i pro celkové pochopení některých částí a funkcí MS Azure. Tento zdroj lze proto doporučit. Klíčové funkce a nástroje, které Azure Tools 4 Eclipse nabízí pro zjednodušení vývoje: • Konverze PHP projektu do Windows Azure projektu • Průvodce pro vytvoření Web role i Worker role • Automatická konfigurace projektu a import knihoven pro práci s Azure Storage nebo SQL Azure • Prohlížeč uložiště Azure Storage • Vytvoření Azure balíčku k nasazení • Nasazení aplikace do Windows Azure přímo z IDE

4.7

Dokumentace

Vzhledem k určení knihovny, která nepracuje na uživatelské vrstvě, není nutná dokumentace pro koncového uživatele. Pro poskytovatele služeb, kteří budou integrovat knihovnu do svých aplikací, jsou nejužitečnější komentáře přímo ve zdrojovém kódu. Nově implementované části byly doplněny komentáři ve stejném stylu s původními částmi knihovny. Komentáře jsou ve formátu umožňujícím vývojovým IDE prostředím zobrazování nápovědy např. v kontextovém okně přímo při užití metody. Pro maximální objasnění funkčnosti jsou nad rámec těchto hlavních komentářů komentovány i některé fragmenty kódů. K novým třídám byla také vygenerována samostatná dokumentace ve formátu html, která je dostupná na CD, které je součástí této práce.

38


Kapitola 5

Integrace OpenID do aplikace Tato kapitola se zabývá integrací upravené knihovny do uživatelské služby, na které je možné ukázat praktické možnosti technologie OpenID.

5.1

Výběr aplikace

Aplikací pro integraci OpenID knihovny byl zvolen wiki systém DokuWiki [41]. Tento systém je oblíbený a široce rozšířený wiki nástroj psaný v jazyce PHP. Wiki systém je vhodnou službou pro demonstraci možností technologie OpenID, protože kromě autentizace lze v uzavřené wiki uplatnit i autorizační pravidla. Výhodou pro tento projekt je architektura DokuWiki umožňující rozšíření základní funkčnosti pomocí zásuvných modulů, pluginů. Systém DokuWiki v současné době nenabízí verzi pro nasazení v MS Azure. Kompletní portace je mimo rozsah této práce. Přesto bylo rozhodnuto o pokračování tvorby s touto aplikací, protože vzhledem k oblíbenosti DokuWiki a jejímu využívání i ve firemním prostředí lze kompletní portaci v brzké době předpokládat. Spíše než od komunity DokuWiki ji lze očekávat od vývojářských firem, které se na portace pro cloud specializují. Wiki systémy a jiné univerzálně použitelné CMS bývají kvůli dobrému odbytu prioritou. Pro funkci DokuWiki při nasazení do MS Azure v současné podobě byl použit startovací skript role, který zajišťuje možnost zápisu na lokální disk podobně jako při nasazení na on-premise serveru. Tento skript a jeho definice v konfiguraci Azure balíčku je uveden v Kód. 5.1. Toto řešení při nasazení v Azure samozřejmě představuje dlouhodobě neperzistentní ukládání dat, stejně jako omezení běhu na jednu instanci. Pro potřebu této práce, kdy není cílem uchování dat, ale pouze demonstrace a otestování funkce OpenID, je použité řešení dostačující.

5.2

OpenID plugin

DokuWiki má architekturu navrženou tak, že její funkčnost je možné rozšiřovat pomocí pluginů. Jednou z kategorií těchto pluginů jsou autentizační pluginy, které přidávají uživatelům DokuWiki možnost autentizace jiným mechanismem, než vestavěným lokálním 39

40

KAPITOLA 5. INTEGRACE OPENID DO APLIKACE

// k o n f i g u r a c n i s o u b o r S e r v i c e D e f i n i t i o n . c s d e f , e l e m e n t WebRole : <Startup> // s k r i p t ' setACL . cmd ' , umisteny v~ a d r e s a r i ' b i n ' web r o l e icacls %RoleRoot%\approot \ data / grant IIS_IUSRS : F / t icacls %RoleRoot%\approot \ conf / grant IIS_IUSRS : F / t icacls %RoleRoot%\approot \ lib \ plugins / grant IIS_IUSRS : F / t

Kód 5.1: Startovací skript role, se kterým byla do MS Azure nasazena DokuWiki, a jeho definice v konfiguračním souboru. Skript příkazem icacls upravuje přístupová práva role pro povolení zápisu do adresářů, do kterých DokuWiki zapisuje data. Skript musí být spuštěn se zvýšenými právy (executionContext = "elevated")

přihlašováním. Přidání možnosti využití technologie OpenID je proto vhodné právě pomocí pluginu. Při prohledání repozitáře existujících DokuWiki pluginů bylo zjištěno, že plugin umožňující autentizaci prostřednictvím OpenID je již pro DokuWiki k dispozici [42]. Tento plugin však poskytuje pouze základní funkčnost: • Možnost přihlášení přes OpenID • Doplnění registračních údajů využitím rozšíření Simple Registration • Možnost přidání více identit k jednomu lokálnímu účtu Uvedený výčet ukazuje, že doplňku například zcela chybí jakákoliv možnost administrátora mít přehled či dokonce řídit použití OpenID identit ve své wiki. Žádanost podobné funkcionality naznačuje i „Feature requests“ část na stránce doplňku, tedy žádosti směřované na autora o rozšíření možností pluginu. Vzhledem k možnostem, které technologie OpenID teoreticky nabízí, by také zcela určitě bylo zajímavé umožnit řízení uživatelských přístupů na základě atributů uložených v OpenID identitě, aj. I při krátkodobém vyzkoušení existujícího pluginu navíc byly objeveny nedokonalosti v samotné funkci, kdy např. přejmenování uživatelského účtu administrátorem vedlo k zmizení uživatelových registrovaných OpenID identit. Bylo proto rozhodnuto o založení poslední části této práce na tomto původním pluginu s cílem rozšířit funkcionalitu. Rozšíření bude zejména směrem k lepší využitelnosti doplňku administrátorem. Cílem je více využít možnosti poskytované technologií OpenID.

5.3

Rozšíření funkcionality

Do původního DokuWiki OpenID pluginu byly doplněny nebo opraveny následující funkce a vlastnosti: Uživatelský pohled • Uživatelé, kteří mají registrovanou alespoň jednu OpenID identitu, jsou členy skupiny „openidusers“. Toto zařazení umožňuje administrátorovi mít přehled o počtu uživatelů

5.4. ŘÍZENÍ PŘÍSTUPU POSKYTOVATELŮ

41

využívajících OpenID autentizaci. Také mu umožňuje na základě tohoto atributu řídit přístup ke zdrojům pro OpenID uživatele. • Byla přidána administrátorská část pluginu. Zaměření této části je na řízení uživatelských přístupů s využitím OpenID identity a k tomuto účelu implementuje dvě části. První je řízení přistupu dle poskytovatele, kdy umožňuje administrátorovi definovat množinu povolených či zakázaných poskytovatelů. Této části se věnuje samostatná sekce 5.4. Druhou částí je autorizace přístupu ke zdrojům na základě individuálních atributů uživatele, která je popsána v sekci 5.5. • Byla přidána česká lokalizace Backend pohled • Plugin nově definuje reakci na DokuWiki událost AUTH_USER_CHANGE. Tato událost je vyvolána při změně uživatelských údajů administrátorem. Původní verze tyto změny nereflektovala a při změně uživatelského jména proto došlo k zneplatnění asociace uživatel - OpenID identita. Podobně při smazání uživatele nedošlo k odstranění jeho registrovaných OpenID identit. • Kód původní verze při přihlašování zjišťuje, zda je použitá OpenID identita již registrována. V případě, že není, tzn. jedná se o nového uživatele, přidává k OpenID žádosti SREG část pro načtení uživatelovi přezdívky, jména a emailu. Tyto informace jsou poté využity v registraci. V kódu však byla chyba, která způsobovala, že SREG část byla zbytečně přidána vždy, i v případě vracejícího se uživatele. Nová verze toto chování opravuje. • Byla přidána podpora rozšíření Attribute Extension. Implementaci této části se věnuje sekce 5.6. • Původní verze pluginu registruje OpenID identity do DokuWiki podle parametru žádosti claimed_id. Při testování ale bylo zjištěno, že hodnota tohoto parametru se u poskytovatele MojeID detailně liší v discovery procesu a při samotné odpovědi. Z tohoto důvodu ji nelze použít pro kontrolu existence identity. Nově tedy plugin pracuje s parametrem local_id, který je pro daný účel doporučován i poskytovateli. Narozdíl od parametru claimed_id je také neměnný i při použití techniky delegace identity.

5.4

Řízení přístupu poskytovatelů

V nově implementovaném rozhraní pro administraci OpenID pluginu má administrátor možnost definovat seznam přípustných poskytovatelů. Seznam se dá definovat jako seznam jediných povolených poskytovatelů nebo jako seznam zakázaných poskytovatelů. Volba typu seznamu se provádí v konfiguračním menu DokuWiki. Při vkládání nového poskytovatele na seznam se využívá discovery proces. Je tedy možné zadat poskytovatele např. ve tvaru myopenid.com. Nad touto adresou je proveden discovery proces, který zjišťuje odpověď od OpenID poskytovatele, a při nalezení je vrácen správný OP Endpoint URL, tzn. např. http://www.myopenid.com/endpoint.

42


Zajímavostí při implementaci této funkce bylo, že poskytovatel identity VerisignLabs vrací rozdílné hodnoty parametru server_url dle typu discovery procesu. Při dotazu nad URL adresou serveru je vrácena hodnota koncového URL zabezpečeného serveru, https:// pip.verisignlabs.com. Při dotazu nad uživatelským identifikátorem náležícím tomuto poskytovateli je však vrácena adresa s protokolem http. Výsledná implementace byla proto upravena tak, že při vyhodnocování poskytovatele je ignorován protokol.

5.5

Autorizace s využitím OpenID

Druhá funkční část administračního rozhraní OpenID pluginu umožňuje administrátorovi nastavit pravidla, která lze v kombinaci s DokuWiki autorizací využít pro řízení přístupu ke zdrojům na základě uživatelských atributů. Každé pravidlo je definováno názvem skupiny, řídícím atributem, jeho operátorem a hodnotou atributu, viz zadávací formulář na Obr. 5.1. Řízení funguje tak, že do definované skupiny jsou přiřazení OpenID uživatelé, kteří splňují danou podmínku. Podmínek pro jednu skupinu může být i více a testuje se splnění všech z nich. Jméno skupiny lze poté využít v autorizačním menu DokuWiki a řídit tak přístup ke zdrojům. Příkladem tak může být např. omezení přístupu na určité stránky uživatelům mladším 18 let, apod.

Obrázek 5.1: Formulář pro definování pravidel pro řízení přístupu na úrovni OpenID atributů Tato funkce společně s řízením na základě poskytovatelů výrazně rozšířila sled událostí, které probíhají před přihlášením prostřednictvím OpenID. Původní plugin po uživatelově zadání identifikátoru pouze přidal žádost o registrační informace a OpenID žádost odeslal. Nově implementované funkce přidávají před samotným odesláním nutnost spolupráce s administrační částí a vyhodnocování podmínek. Pro názornější představu je kompletní proces ve zjednodušené podobě zachycen v konceptuálním sekvenčním diagramu na Obr. 5.2. Události probíhají v případě zadání správného uživatelského identifikátoru následovně: 1. Uživatel odešle OpenID identifikátor 2. Nad identifikátorem je proveden discovery proces, který vrátí informace o OpenID poskytovateli 3. Z administrační části jsou načteny pravidla týkající se poskytovatelů 4. OpenID poskytovatel se testuje oproti definovaným pravidlům

5.5. AUTORIZACE S VYUŽITÍM OPENID

43

5. Pokud není poskytovatel povolen, proces končí 6. Je zjištěno, zda má uživatel lokální registraci nebo se jedná o nového uživatele 7. Je zjištěno, zda OpenID poskytovatel podporuje rozšíření SREG či AX 8. Pokud poskytovatel nepodporuje ani jedno rozšíření, je žádost odeslána 9. Pokud poskytovatel podporuje rozšíření SREG, je toto použito 10. Pokud poskytovatel nepodporuje SREG a AX ano, je použito AX 11. Z administrační části jsou načtena pravidla týkající se uživatelských atributů 12. Atributy pravidel jsou přeloženy do podoby SREG a AX 13. Pokud se jedná o nového uživatele, je k žádosti o atributy přiložena i žádost o registrační informace 14. Žádosti jsou přiloženy k OpenID žádosti 15. OpenID žádost je odeslána Implementace testuje podporu rozšíření SREG a AX, aby nebyla tato rozšíření do OpenID žádosti přidávána zbytečně v případě, že nejsou poskytovatelem podporovány. K vyhodnocení podpory je využit parametr OpenID serveru type_uris. Specifikace OpenID uvádí, že v tomto parametru poskytovatelé „mohou“ zveřejňovat seznam podporovaných rozšíření. U testovaných poskytovatelů tomu tak bylo, kromě poskytovatele MojeID. Tento obě rozšíření podporuje, ale v parametru type_uris zveřejňuje pouze jiná rozšíření. Po vznesení připomínky na technickou podporu byla obdržena odpověd od technického ředitele, že tento fakt bude zohledněn v příští verzi, plánované na leden 2012. Implementace tedy zůstala v dané podobě. V současné verzi kódu je v administračním rozhraní možné volit pouze podmínky týkající se věku a pohlaví. Kód je však připraven na jednoduché rozšíření o další atributy. Tato úprava spočívá v: Administrační část • Přidání názvu atributu do pole výběru • Případné přidání názvu operátoru do pole výběru • Naprogramování podmínek validace operátoru a hodnoty pro daný atribut OpenID část • Definování překladu atributu do SREG a AX názvů • Naprogramování vyhodnocovací metody atributu • Přidání volání výše uvedené metody do metody vyhodnocení přijatých atributů

44


Obrázek 5.2: Konceptuální sekvenční diagram znázorňující implementaci průběhu operací v DokuWiki OpenID pluginu před odesláním OpenID žádosti. Nejprve je proti AC seznamu kontrolován poskytovatel identity. Poté jsou dle definovaných AC pravidel skupin získány atributy k načtení potřebných údajů. Ty jsou nakonec dle podpory vloženy do žádosti v podobě SREG či AX části a žádost je odeslána. Pro zjednodušení nejsou zachyceny chybové stavy, např. zadání špatného identifikátoru

5.6. PODPORA ROZŠÍŘENÍ ATTRIBUTE EXTENSION

45

V kódu tedy není pevně zabudován mechanismus pro vyhodnocení pouze těchto dvou atributů. V případě potřeby by však pro další zpřehlednění mohl být implementován mechanismus vyvolání události vyhodnocení a registrace reakcí na ni. Budoucím rozšíření práce by také mělo být vylepšení zadávacího formuláře pravidel. Např. validace hodnot by měla probíhat dynamicky, kdy by při zvolení atributu pohlaví došlo ke změně pole hodnoty z textového pole na výběr dvou možností.

5.6

Podpora rozšíření Attribute Extension

Do pluginu byla přidána možnost využití rozšíření AX pro načítání atributů z uživatelského profilu. Protože většina poskytovatelů podporuje pouze SREG, je toto rozšíření v současné implementaci preferováno. Toto je i z důvodu komplikovaného použití AX, daného benevolentností specifikace při použití jmenného prostoru definujícího atribut (viz kapitola 3.1.5). Např. poskytovatel Google však podporuje pouze rozšíření AX, proto je podpora tohoto rozšíření ve službě žádoucí. Pro překlad názvu atributu použitého v administračním rozhraní na atribut AX je stejně jako u SREG použito překladové pole. Rozšíření AX v tomto případě přináší nejednoznačnost identifikátorů odpovídajících uživatelskému atributu. V implementaci byl tento problém vyřešen znásobením překladových hodnot. Tímto způsobem je možné definovat více URI pro stejný uživatelský atribut v závislosti na tom, jaké URI vyžaduje poskytovatel. Do OpenID žádosti jsou poté přidána všechna odpovídající URI, přičemž odpověď přijde pouze na podporovaný identifikátor.

static $attri butes_ax = a r r a y ( ' h t t p : / / o p e n i d . n e t / schema / b i r t h D a t e ' => ' age ' , ' h t t p : / / axschema . o r g / b i r t h D a t e ' => ' age ' , ' h t t p : / / o p e n i d . n e t / schema / g e n d e r ' => ' g e n d e r ' , ' h t t p : / / axschema . o r g / p e r s o n / g e n d e r ' => ' g e n d e r ' );

Kód 5.2: Ukázka překladového pole atributů pro řízení přístupu na odpovídající Attribute Extension identifikátory. Nejednoznačnost v identifikátorech pro různé poskytovatele je řešena znásobením překladů pro každé URI schéma

5.7

Dokumentace

Upravená i nově vytvořená část DokuWiki OpenID doplňku byla pro přehlednost opatřena komentáři v kódu, které umožňující generování dokumentace ve formátu html. Tato dokumentace je dostupná na přiloženém CD. Pro maximální objasnění funkčnosti jsou nad rámec těchto hlavních komentářů komentovány i některé fragmenty kódů. Plugin pracuje na uživatelské vrstvě, ale ovládání lze považovat za intuitivní, doplněné nápovědnými lokalizovanými texty přímo v aplikaci. Uživatelská dokumentace proto nebyla vytvořena.

46


Kapitola 6

Testování Tato kapitola obsahuje popis použitých testovacích procedur, které byly provedeny v obou implementačních částech práce pro ověření správnosti funkce, a výsledky testů.

6.1

Upravené části OpenID knihovny

Úpravy původní JanRain OpenID PHP knihovny byly provedeny pouze v části použitého uložiště pro stav autentizace. Díky dobré architektuře knihovny nebyly provedeny žádné zásahy do jádra knihovny a proto bylo možné se při testování zaměřit pouze na správnou spolupráci knihovny s uložištěm. Při autentizaci je nutná interakce uživatele, pro plně automatizované testy by tedy bylo nutné využívat speciální SW nástroje či programovat složité testovací algoritmy s využitím OpenID módu autentizace check_immediate. Tento mód navíc často nelze použít. Testování proto bylo prováděno manuálně. Při testování nově implementovaných uložišť byla pozornost věnována nejen správnému ukládání provozních dat do uložiště, ale i správnému úklidu případných dočasných souborů. Testovací procedury byly prováděny pomocí předem připravených scénářů užití. Byly definovány čtyři scénáře, které svým rozsahem využívají všechny metody v kódu: • UC1: Přihlásit se - autentizuje uživatele • UC2: Inicializovat uložiště - připraví uložiště pro funkci • UC3: Provést údržbu - vyčistí uložiště od prošlých asociací a nonces • UC4: Ukončit použití - vrátí uložiště do stavu před použitím K detailnímu formálnímu zaznamenání průběhu scénáře byla použita Cockburnova šablona [43]. Její autor, Alistair Cockburn, se problematice zaznamenání případů užití věnuje dlouhodobě a tato šablona patří k obecně uznávaným způsobům textového popisu případů užití. Šablona definuje spouštěcí i výstupní podmínky akce, možné varianty průběhu i aktuální stavy uložiště. Příklad využitého testovacího scénáře je uveden v Tab. 6.1. Scénář 47

48

KAPITOLA 6. TESTOVÁNÍ

postihuje autentizaci uživatele, knihovna je nastavena pro využití Azure Storage. Body vyznačené kurzívou se týkají části Azure Storage. Klíčové pro vyhodnocení úspěšnosti testu je splnění koncových podmínek. Ostatní testovací scénáře jsou uvedeny v příloze B, resp. C, této práce. Výhodnost testování pomocí komplexních scénářů, namísto jednotlivých metod kódu, se ukázala např. při testování třídy SQLStore, resp. MSSQLStore, tedy u využití uložiště SQL Azure. Průběh metody _set_assoc v třídě SQLStore by i před provedením změn přizpůsobujících třídu pro běh na SQL Azure, viz sekce 4.4.5, byl vyhodnocen jako úspěšný, neboť na konci metody byla asociace uložena v tabulce. Chyba v podobě špatně uloženého hesla se projevila vždy až při použití asociace v posledním kroku autentizace. Při využití scénáře znamenala tato chyba stav nezachycený ve scénáři, tedy chybu ve funkčnosti. Výsledek testů Obě nově implementovaná uložiště byla průběžně testována s využitím výše uvedených scénářů. Koncový výsledek testů jsou všechny splněné scénáře. Testovací konfigurace Tab. 6.2 uvádí testovací konfiguraci MS Azure využitou při vývoji i testování, Tab. 6.3 verze použitých prostředků. Knihovna byla testována pouze při běhu jedné instance. Díky využití sdíleného uložiště pro všechna dlouhodobě potřebná data lze teoreticky předpokládat správnou funkci na více instancích. Samotné nasazení na více instancích by však nemohlo být považováno za potvrzení tohoto předpokladu. Při nulovém vedlejším vytížení lze očekávat směrování všech požadavků na stále stejnou instanci. Bylo by proto nutné prostudovat funkci vyvažování zátěže a pravděpodobně i využít nějaký testovací prostředek pro vynucení střídání směrování požadavků, aby došlo k obsluze všemi instancemi. Toto je mimo rozsah této práce. V konfiguraci PHP je nezbytné dodržet zejména nastavení parametrů charakteristických pro běh na webovém serveru Microsoft IIS: • enable_dl = off • cgi.force_redirect = 0 • fastcgi.impersonate = 1 Do JanRain PHP knihovny v. 2.2.2 byly provedeny změny uvedené v kapitole 4.5. Balíček MDB2 frameworku PEAR bylo nutné použít ve verzi 2.5.0b3, tedy v beta fázi vývoje, protože předchozí stabilní verze nepodporují ovladač sqlsrv. Tato verze také upravuje kompatibilitu s PHP 5.3. Stav kódu Úpravy, které byly do knihovny implementovány, byly odladěny do podoby bez chyb i bez PHP varování. Výjimkou je použití volání PEAR::isError() ve třídě SQLStore, které vyvolává varování o statickém použití nestatické metody. Použití v této podobě je však uvedeno v dokumentaci PEAR. V diskuzích na domovských stránkách frameworku PEAR

6.1. UPRAVENÉ ČÁSTI OPENID KNIHOVNY

USE CASE 1

49

Přihlásit se

Goal in context Preconditions

Autentizuje uživatele u RP 1) RP umožňuje přihlášení prostřednictvím OpenID 2) Uživatel je neautentizován a RP je ve stavu přihlášení uživatele 3) Uložiště Azure Storage je dostupné Success end 1) Uživatel je autentizován u RP condition 2) V association kontejneru existuje blob s odpovídajícím názvem a je v něm uložena asociace 3) Dočasný soubor na lokálním FS využitý pro uložení asociace do blobu je smazán 4) Dočasný soubor na lokálním FS využitý pro načtení asociace z blobu je smazán 5) V nonce kontejneru existuje blob s odpovídajícím názvem reprezentující nonce parametr 6) Dočasný soubor na lokálním FS využitý pro uložení nonce do blobu je smazán Actors Uživatel Trigger Uživatel vyplní svůj OpenID identifikátor a odešle žádost o přihlášení DESCRIPTION Step Action 1 Je provedena inicializace uložiště - Spuštěn USE CASE 2 2 Uživatelský agent je přesměrován na stranu OP +Systémová akce: 1) Je testována přítomnost blobu s domluvenou asociací 2) Asociace je přítomna a platná - je použita 3 Uživatel se přihlásí na straně OP a odsouhlasí předání svých údajů 4 Uživatelský agent je přesměrován zpět na RP jako autentizovaný +Systémová akce: 1) Je testována přítomnost blobu s domluvenou asociací 2) Asociace je přítomna a platná - je použita 3) Je vytvořen nonce blob EXTENSIONS Step Branching action 1a Podmínka: Provádění kroku skončilo chybou Není možné pokračovat v autentizaci - UC končí chybou 2a Podmínka: Není nalezen blob s existující asociací nebo je neplatný Je vytvořen blob s novou asociací 3a Podmínka: Uživatel na straně OP zruší proces autentizace Uživatelský agent je přesměrován zpět na RP jako neautentizovaný Blob s domluveným způsobem asociace mezi RP a OP zůstane zachován 4a Podmínka: Není nalezen blob s existující asociací nebo je neplatný Nelze ověřit podpis žádosti Proces autentizace je neúspěšný 4b Podmínka: Je nalezen nonce blob žádosti Žádost o autentizaci je opakovaná - možný replay attack Proces autentizace je neúspěšný

Tabulka 6.1: Příklad případu užití knihovny s použitím Azure Storage využitý pro testování

50

KAPITOLA 6. TESTOVÁNÍ OS family OS version Počet instancí Database edition

Windows Server 2008 SP2 Automatic 1 Web

Tabulka 6.2: Testovací konfigurace MS Azure PHP Windows Azure SDK OpenID Janrain PHP PEAR MDB2

PHP 5.3.8 VC9 NTS 1.3 2.2.2 2.5.0b3

Tabulka 6.3: Testovací konfigurace použitých prostředků lze dohledat několik vláken zmiňující tuto chybu, nicméně řešení nabízejí pouze v potlačení zobrazování chyb na PHP úrovni E_STRICT, kterou některé části frameworku v současnosti nesplňují.

6.2 6.2.1

Dokuwiki OpenID plugin Funkční testování

Testovací konfigurace Konfigurace pro testování OpenID pluginu zůstala stejná jako v případě OpenID knihovny. Uvedena je v Tab. 6.2, resp. Tab. 6.3. Nasazení v Azure pouze na jedné instanci bylo v tomto případě dáno i způsobem úpravy DokuWiki pro umožnění běhu v Azure, které využití ve více instancích z principu neumožňovalo. Nestandardní chování Při testování pluginu bylo zaznamenáno následující nestandardní, chybové chování. Uvedené problémy byly pozorovány s náhodným výskytem, nepodařilo se tedy určit příčiny, ani kroky k reprodukci chyb. • DokuWiki občas při požadavku na přesměrování neprovede přesměrování, ale zůstane na prázdné obrazovce. Po znovuodeslání adresy je původní akce dokončena. Výskyt této chyby byl pozorován nejčastěji při přihlášení do Admin účtu. Chování je při zapnutém výpisu chyb doprovázeno chybou Invalid CRT parameters detected. Zdrojem chyby je DokuWiki třída HTTPClient.php. Tato chyba je hlášena v buglistu PHP, ale dle uvedených informací není původcem chyby PHP, ale C++ knihovna na vrstvě pod PHP při provozu na IIS. • Při nasazení v lokálním emulátoru byl občas vyvolán dialog výjimky procesu WAHOST.EXE. Výskyt chyby byl pozorován náhodně. Po zobrazení chybového hlášení trvalo zotavení několik vteřin, poté bylo možné pokračovat v původní akci se zachováním stavu. Příčina chyby může být způsobena i lokální instalací emulátoru.

51

6.2. DOKUWIKI OPENID PLUGIN

• JanRain OpenID knihovna občas funguje chybově při odeslání a přijímání OpenID žádosti s Attribute Exchange rozšířením. Při odeslání žádosti se může objevit hlášení prohlížeče „Informace třetí straně budou odeslány nezašifrovaně, chcete pokračovat?“. Po odsouhlasení je místo přesměrování na poskytovatele proveden návrat na výchozí DokuWiki stránku. V URL je vidět fragment pozůstatku OpenID žádosti. Stejné chování bylo v jiném případě zaznamenáno také až při návratu ze strany poskytovatele. Použití rozšíření AX s knihovnou JanRain je obecně špatně dokumentováno, buglist se nepodařilo najít. Chyba proto zůstává nejasná. Načítání informací z uživatelského profilu Tab. 6.4 uvádí výsledky testů načítání uživatelských atributů s využitím rozšíření SREG a AX u testovaných poskytovatelů identity. Finální verze kódu preferuje při podpoře obou rozšíření použití SREG před AX, proto bylo při testech využití AX manuálně vynuceno. Poskytovatel MyOpenID Google MojeID VerisignLabs

Podpora SREG yes no yes yes

Test SREG pass pass pass

Podpora AX yes yes yes no

Test AX pass fail pass -

Tabulka 6.4: Výsledky testování načítání uživatelských atributů využitím SREG a AX u různých poskytovatelů Hlavní motivací pro implementaci podpory rozšíření AX byla podpora poskytovatele Google. Předávání uživatelských údajů pomocí AX však s tímto poskytovatelem stále nefunguje, přestože s poskytovateli MyOpenID a MojeID bylo toto rozšíření úspěšně testováno. Neúspěch předání atributů při použití AX s poskytovatelem Google není předpokládán v chybné definici atributů, protože Google ve své specifikaci explicitně uvádí použití URL schématu axschema.org. V případě chybné definice schématu by navíc OpenID odpověď vrátila prázdné hodnoty daných atributů. Odpověď však místo toho vůbec neobsahuje AX část. Chyba proto není předpokládána na straně knihovny ani nové implementace. Testování funkce řízení přístupu Nejzásadnější změnou provedenou do původního DokuWiki OpenID pluginu byla implementace řízení přístupů na základě OpenID atributů. Klíčové je u této funkce správné vyhodnocení přijatých atributů a přidělení uživatele do odpovídajících skupin. Pro komplexní otestování funkce je rozhodující správná volba vzorku pravidel, které prověří všechny možnosti vyhodnocení, zejména u mnohonásobných podmínek. Obr. 6.1 ukazuje soubor pravidel, která byla při testování použita. Skupina males (muži) prověřuje správné vyhodnocení atributu pohlaví. Ostatní skupiny se zaměřují na atribut věk. Testování probíhalo především s využitím poskytovatele MyOpenID, který umožňuje vytváření mnohonásobných identit. Tyto identity byly zadány tak, aby věk uživatele postupně spadal do jednotlivých věkových rozmezí, i mezi ně. Důležitou vlastností testu bylo, že vyhodnocován byl obsah seznamů skupin k přidání a skupin k odebrání. Tyto funkce pro přidávání a odebírání uživatelových skupin byly otesto-

52

KAPITOLA 6. TESTOVÁNÍ

vány již předem. Pokud by byl porovnáván pouze seznam výsledných uživatelových skupin, mohla by jeho výsledná podoba být ovlivněna předchozím obsahem.

Obrázek 6.1: Vzorek pravidel pro testování vyhodnocení uživatelských atributů

6.2.2

Usability testování

Testy použitelnosti nebyly u pluginu prováděny. V současné fázi nebyla práce zaměřena na grafický vzhled ani na pohodlnost užití. Orientaci by uživateli mělo usnadnit použití standardních vzhledových DokuWiki prvků, díky kterým doplněk odpovídá vzhledu zbytku systému. Před zveřejněním pluginu by však v oblasti interakce s uživatelem mohlo být vylepšeno zejména zadávání autorizačních pravidel v administrační části tak, aby byla práce pohodlnější a intuitivnější. V autentizační části by také mohly být přidány zástupné ikony např. pro přihlašování přes účet Google, aby uživatel nebyl nucen zadávat dlouhou a nezapamatovatelnou adresu Google OpenID serveru.

Kapitola 7

Závěr Práce úspěšně prakticky ověřila možnost využití federace identit prostřednictvím technologie OpenID v cloud prostředí Microsoft Azure. Teoretický předpoklad konceptuální využitelnosti byl tedy potvrzen, avšak v závislosti na použitých programových prostředcích, zejména použité knihovně OpenID, byla prokázána možná nezbytnost provedení úprav souvisejících s charakteristikou provozu aplikací v cloudu. Použití technologie OpenID bylo také prakticky demonstrováno implementací doplňku do aplikace DokuWiki. Vytyčené cíle práce tedy byly splněny. Teoretická část práce přinesla neočekáváné zjištění, že federace u účtu Google i u účtu MojeID jsou založeny na technologii OpenID. Tento fakt usnadnil výběr technologie pro praktickou implementaci, kdy bylo technologií OpenID pokryto nejvíce účtů. V teoretické analýze bylo také zjištěno, že technologie OpenID a Shibboleth jsou konceptuálně velmi podobné. Nejvýraznějším rozdílem je zaměření technologií, kdy OpenID je zaměřena na jednotlivé uživatele, zatímco Shibboleth na organizace. Zaměření technologie Shibboleth je výhodnější v tom, že všichni uživatelé mají stejné, známé atributy, podle kterých je možné autorizovat přístup ke zdrojům. Tato možnost je v OpenID komplikována z důvodu obecnosti, různorodosti uživatelů. Toto vysvětluje, proč většina poskytovatelů podporuje pouze rozšíření Simple Registration, které nabízí jen základní atributy. Tyto jsou ale společné všem uživatelům. Komplexnost nabízí v teoretické rovině rozšíření Attribute Extension. V praxi je ale použití tohoto rozšíření komplikované, protože není příliš podporované a implementaci komplikuje neexistující shoda ve schématu pro definici atributů. Toto rozšíření tedy nabízí široké možnosti definice uživatelských atributů, využitelné např. v autorizaci, ale využitelné je hlavně při komunikaci dvou smluvených stran, tedy při omezení služby na konkrétního poskytovatele identit. Při tomto postupu je ale smazána základní myšlenka potřeby jediného OpenID účtu a volnosti uživatele ve výběru jeho poskytovatele. Univerzálnost rozšíření AX je tedy zároveň i překážkou. Výstupem praktické části práce je upravený zdrojový kód knihovny JanRain OpenID PHP5, který distribuční verzi balíku rozšiřuje o podporu uložiště Azure Storage a databázového uložiště MS SQL, resp. SQL Azure. Tyto úpravy nově umožňují provoz knihovny v prostředí Azure s nasazením na více instancích serverů. Implementována byla podpora obou Azure uložišť, takže poskytovatel služby má při integraci knihovny možnost výběru a není nucen platit za druhý typ uložiště, pokud ho ve své službě nepoužívá. V rámci úprav bylo 53

54

KAPITOLA 7. ZÁVĚR

také provedeno nahrazení zastaralého balíku PEAR DB pro abstrakci databázové vrstvy aktuálním balíkem PEAR MDB2. Provedené úpravy posouvají budoucí využitelnost knihovny, proto se předpokládá zveřejnění výstupu, zejména v domovském repositáři knihovny [44]. Druhým výstupem je rozšířený DokuWiki OpenID plugin. Praktické možnosti tohoto pluginu byly oproti výchozí verzi výrazně rozšířeny. Provedené úpravy navíc nejsou vázány pouze na použití s MS Azure, proto lze předpokládat zájem uživatelů současné verze pluginu o tuto rozšířenou. Pro zjištění zájmu je předpokládáno zveřejnění doplňku v repozitáři rozšíření DokuWiki pro účely testování. Na základě uživatelského zájmu by poté mohlo být na dopňku dále pracováno. Budoucím pokračování práce může být zejména rozšíření množství uživatelských atributů, podle kterých funguje autorizace uživatelů, a vylepšení grafické stránky a pohodlnosti zadávání autorizačních OpenID pravidel. Komplexnější testování více uživateli by také umožnilo odhalit příčinu problému s použitím rozšíření Attribute Extension a dále tuto chybu řešit. K prostředí Microsoft Azure je nutné uvést, že jde o relativně novou technologii, která je stále rozvíjena. U jednotlivých částí tak v současnosti existují omezení, které brzy nemusí platit. Také se objevují nové služby, technologie a postupy, které rozšiřují možnosti či zjednodušují vývoj aplikací. Technologie jsou však vyvíjeny primárně pro podporu jazyka ASP.NET a jejich využití v jazyce PHP a ostatních nemusí být od začátku podporováno. Vzhledem k častým změnám a pokrokům také může být problém se v implementačních postupech orientovat. Vývojáři Microsoftu často informují na svých blozích, ale informace bývají neoznačené jako neaktuální, pokud byl postup již nahrazen novou verzí. I pro ostatní programovací jazyky se však podpora zlepšuje. I v průběhu vypracovávání této práce byl zaznamenán posun v podpoře nasazení PHP aplikace do Azure. Zpočátku čas nahrání a spuštění samotné OpenID knihovny v Azure trvalo přibližně 25 minut. Tento čas byl velmi znepříjemňující práci zejména proto, že i drobná chyba v kódu znamenala nutnost nového nahrání. V současnosti je k nahrání a spuštění celé DokuWiki potřeba přibližně 15 minut. Pro PHP také vznikají podpůrné nástroje, které výrazně ulehčují vývoj, např. použitý Windows Azure Tools 4 Eclipse, který je dále aktivně vyvíjený.

Literatura [1] OpenID Foundation. OpenID Foundation website [online]. ©2006-2011 [cit. 2011-4-25]. Dostupné z WWW: . [2] OpenID Foundation. OpenID Authentication 2.0 - Final [online]. Poslední revize 2007-12-5 [cit. 2011-4-25]. Dostupné z WWW: . [3] Janrain. OpenID Enabled | Janrain [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW: . [4] OpenID Foundation. Get an OpenID | OpenID [online]. ©2006-2011 [cit. 2011-4-25]. Dostupné z WWW: . [5] OASIS Open. XRI Syntax Specification [online]. Poslední revize 2005-11-14 [cit. 2011-425]. Dostupné z WWW: . [6] Janrain. Welcome to myOpenID [online]. ©2008 [cit. 2011-4-25]. Dostupné z WWW: . [7] CZ NIC. MojeID - Vítejte v mojeID [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW: . [8] Sam Ruby. Sam Ruby: OpenID for non-SuperUsers [online]. Poslední revize 2007-1-3 [cit. 2011-4-25]. Dostupné z WWW: . [9] Shane B. Weeden and Eduardo A. Solis. Managing OpenID trusted sites with Tivoli Federated Identity Manager [online]. Poslední revize 2008-10-15 [cit. 2011-425]. Dostupné z WWW: . [10] Yadis 1.0. Main Page [online]. Poslední revize 2011-4-19 [cit. 2011-4-25]. Dostupné z WWW: . [11] Network Working Group. Diffie-Hellman Key Agreement Method [online]. Poslední revize 1999-6 [cit. 2011-4-25]. Dostupné z WWW: .

55

56

LITERATURA

[12] Josh Hoyt, Jonathan Daugherty, and David Recordon. OpenID Simple Registration Extension 1.0 [online]. Poslední revize 2006-6-30 [cit. 2011-4-25]. Dostupné z WWW: . [13] Dick Hardt, Johnny Bufu, and Josh Hoyt. OpenID Attribute Exchange 1.0 - Final [online]. Poslední revize 2007-12-5 [cit. 2011-4-25]. Dostupné z WWW: . [14] BBC news | Technology. Engineer error knocks out Gmail [online]. Poslední revize 2009-9-2 [cit. 2011-4-25]. Dostupné z WWW: . [15] Google. Federated Login for Google Account Users [online]. ©2011 [cit. 2011-425]. Dostupné z WWW: . [16] Plaxo. Sign-in [online]. ©2002-2011 [cit. 2011-4-25]. Dostupné z WWW: . [17] CZ.NIC Správce domény CZ. Hlavní strana [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW: . [18] Internet2. Main page [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW: . [19] Internet2. Shibboleth [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW: . [20] Shibboleth. Technical Specifications [online]. Poslední revize 2011-04-13 [cit. 20114-25]. Dostupné z WWW: . [21] Internet2 Middleware. EduPerson Specification [online]. Poslední revize 2003-12 [cit. 2011-4-25]. Dostupné z WWW: . [22] Online community for the SAML OASIS Standard. Main page [online]. ©1993-2011 [cit. 2011-4-25]. Dostupné z WWW: . [23] Česká akademická federace identit eduID.cz. Hlavní strana [online]. Poslední revize 2009-04-30 [cit. 2011-4-25]. Dostupné z WWW: . [24] CESNET. Hlavní strana [online]. ©1996-2011 [cit. 2011-4-25]. Dostupné z WWW: . [25] Pavel Satrapa. Shibboleth - identifikujte se jen jednou [online]. Poslední revize 2005-08-12 [cit. 2011-4-25]. Dostupné z WWW: .

LITERATURA

57

[26] Microsoft. Windows Live ID [online]. ©2011 [cit. 2011-12-30]. Dostupné z WWW: . [27] Microsoft. Windows Azure Storage [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW: . [28] Microsoft. SQL Azure [online]. ©2010 [cit. 2011-4-25]. Dostupné z WWW: . [29] Maarten Balliauw. Developing with Windows Azure Storage & SQL Azure [online]. ©2009 [cit. 2011-4-25]. Dostupné z WWW: . [30] Microsoft MSDN. Naming and Referencing Containers, Blobs, and Metadata [online]. Poslední revize 2010-11-22 [cit. 2011-12-29]. Dostupné z WWW: . [31] PHP Group. PEAR - PHP Extension and Application Repository [online]. ©2001-2011 [cit. 2011-4-26]. Dostupné z WWW: . [32] PHP Group. PEAR - Package Information: DB [online]. Poslední revize 2010-12-24 [cit. 2011-4-26]. Dostupné z WWW: . [33] PHP Group. PEAR - Package Information: MDB2 [online]. Poslední revize 2010-8-29 [cit. 2011-4-26]. Dostupné z WWW: . [34] Stoyan Stefanov. DB-2-MDB2 [online]. Poslední revize 2006-2-4 [cit. 2011-4-26]. Dostupné z WWW: . [35] Microsoft MSDN. General Guidelines and Limitations (SQL Azure Database) [online]. ©2011 [cit. 2011-4-27]. Dostupné z WWW: . [36] InstallationWiki.org. MDB2 - Data types [online]. Poslední revize 2010-9-15 [cit. 2011-428]. Dostupné z WWW: . [37] Miguel Santirso. Janrain’s PHP OpenID library fixed for PHP 5.3 (and how I did it) [online]. ©2010 [cit. 2011-4-25]. Dostupné z WWW: . [38] CURL. Bundle of CA Root Certificates [online]. Poslední revize 2011-4-13 [cit. 2011-425]. Dostupné z WWW: . [39] The Eclipse Foundation. Eclipse - The Eclipse Foundation open source community website [online]. ©2011 [cit. 2011-12-30]. Dostupné z WWW: . [40] Soyatec. Windows Azure Tools 4 Eclipse [online]. ©2009 [cit. 2011-12-30]. Dostupné z WWW: .

58

LITERATURA

[41] Dokuwiki. Main page [online]. Poslední revize 2011-1-19 [cit. 2011-4-25]. Dostupné z WWW: . [42] DokuWiki. DokuWiki OpenID plugin [online]. Poslední revize 2011-2-15 [cit. 2011-1230]. Dostupné z WWW: . [43] Alistair Cockburn. Alistair Cockburn - Basic use case template [online]. Poslední revize 1998-4-26 [cit. 2011-12-30]. Dostupné z WWW: . [44] GitHub. OpenID / PHP OpenID repository [online]. ©2011 [cit. 2011-5-1]. Dostupné z WWW: .

Příloha A

Seznam použitých zkratek AC Access Control ACL Access Control List AX Attribute Exchange CRUD Create Read Update Delete DDL Data Definition Language DML Data Manipulation Language FS Filesystem IDE Integrated Development Environment IIS Internet Information Services MS Microsoft OP OpenID Provider RDBMS Relational Database Management System RP Relying party SAML Security Assertion Markup Language SDK Software Development Kit SREG Simple Registration SSO Single-Sign-On URI Uniform Resource Identifier URL Uniform Resource Locator XML Extensible Markup Language XRI Extensible Resource Identifier

59

60

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

Příloha B

Testovací scénáře knihovny - Azure Storage USE CASE 1 Goal in context Preconditions

Success condition

Actors Trigger

end

Přihlásit se Autentizuje uživatele u RP 1) RP umožňuje přihlášení prostřednictvím OpenID 2) Uživatel je neautentizován a RP je ve stavu přihlášení uživatele 3) Uložiště Azure Storage je dostupné 1) Uživatel je autentizován u RP 2) V association kontejneru existuje blob s odpovídajícím názvem a je v něm uložena asociace 3) Dočasný soubor na lokálním FS využitý pro uložení asociace do blobu je smazán 4) Dočasný soubor na lokálním FS využitý pro načtení asociace z blobu je smazán 5) V nonce kontejneru existuje blob s odpovídajícím názvem reprezentující nonce parametr 6) Dočasný soubor na lokálním FS využitý pro uložení nonce do blobu je smazán Uživatel Uživatel vyplní svůj OpenID identifikátor a odešle žádost o přihlášení

Tabulka B.1: Případ užití - Přihlásit se - Azure Storage (1.část)

61

62

PŘÍLOHA B. TESTOVACÍ SCÉNÁŘE KNIHOVNY - AZURE STORAGE

USE CASE 1 Přihlásit se DESCRIPTION Step Action 1 Je provedena inicializace uložiště - Spuštěn USE CASE 2 2 Uživatelský agent je přesměrován na stranu OP +Systémová akce: 1) Je testována přítomnost blobu s domluvenou asociací 2) Asociace je přítomna a platná - je použita 3 Uživatel se přihlásí na straně OP a odsouhlasí předání svých údajů 4 Uživatelský agent je přesměrován zpět na RP jako autentizovaný +Systémová akce: 1) Je testována přítomnost blobu s domluvenou asociací 2) Asociace je přítomna a platná - je použita 3) Je vytvořen nonce blob EXTENSIONS Step Branching action 1a Podmínka: Provádění kroku skončilo chybou Není možné pokračovat v autentizaci - UC končí chybou 2a Podmínka: Není nalezen blob s existující asociací nebo je neplatný Je vytvořen blob s novou asociací 3a Podmínka: Uživatel na straně OP zruší proces autentizace Uživatelský agent je přesměrován zpět na RP jako neautentizovaný Blob s domluveným způsobem asociace mezi RP a OP zůstane zachován 4a Podmínka: Není nalezen blob s existující asociací nebo je neplatný Nelze ověřit podpis žádosti Proces autentizace je neúspěšný 4b Podmínka: Je nalezen nonce blob žádosti Žádost o autentizaci je opakovaná - možný replay attack Proces autentizace je neúspěšný Tabulka B.2: Případ užití - Přihlásit se - Azure Storage (2.část)

63

USE CASE 2 Goal in context Preconditions Success end condition

Inicializovat uložiště Připraví uložiště pro použití OpenID autentizace s využitím Azure Storage Uložiště Azure Storage je dostupné 1) Existuje kontejner pro ukládání asociací 2) Existuje kontejner pro ukládání nonce parametrů 3) Je nastavena životnost ukládaných nonce parametrů

Actors Trigger Průběh USE CASE 1 DESCRIPTION Step Action 1 Systémová akce: Je nastavena životnost ukládaných nonce parametrů 2 Systémová akce: Je vytvořen kontejner pro ukládání asociací 3 Systémová akce: Je vytvořen kontejner pro ukládání nonce parametrů EXTENSIONS Step Branching action 2a Podmínka: Název kontejneru k vytvoření není validní Není možné inicializovat uložiště - přeskočí se krok 3 UC končí chybou 2b Podmínka: Kontejner již existuje Je zachován existující kontejner - není vytvořen nový. 3a Podmínka: Název kontejneru k vytvoření není validní Není možné inicializovat uložiště - UC končí chybou 3b Podmínka: Kontejner již existuje Je zachován existující kontejner - není vytvořen nový. Tabulka B.3: Případ užití - Inicializovat uložiště - Azure Storage

64


Provést údržbu Vyčistí uložiště Azure Storage od asociací a nonces záznamů s prošlou dobou platnosti Preconditions 1) Uložiště Azure Storage je dostupné 2) Uložiště Azure Storage je inicializované Success end 1) Kontejner pro ukládání asociací neobsahuje bloby obsahující condition asociace s prošlou dobou platnosti 2) Kontejner pro ukládání nonces neobsahuje bloby reprezentující nonce parametry s prošlou dobou platnosti 3) Na lokálním FS nezůstaly žádné dočasné soubory využité pro načtení asociace z blobu Actors Administrátor / Worker role Trigger Administrátor spustí provádění údržby nebo je spuštěno automaticky DESCRIPTION Step Action 1 Systémová akce: Jsou načteny všechny názvy blobů v kontejneru pro ukládání nonce parametrů Pozn.: Bloby s nonce parametry neobsahují žádný obsah, jsou porovnávány pouze podle názvů. 2 Systémová akce: Seznam načtených nonce parametrů je testován na přítomnost expirovaných nonces Při nalezení expirovaného nonce záznamu je smazán blob reprezentující tento záznam 3 Systémová akce: Jsou načteny všechny bloby z kontejneru pro ukládání asociací 4 Systémová akce: Seznam načtených asociací je testován na přítomnost expirovaných asociací Při nalezení expirované asociace je smazán blob obsahující asociaci USE CASE 3 Goal in context

Tabulka B.4: Případ užití - Provést údržbu - Azure Storage

65

Ukončit použití Uvede uložiště do stavu před inicializací 1) Uložiště Azure Storage je dostupné 2) Uložiště Azure Storage je inicializované Success end 1) Neexistuje kontejner pro ukládání asociací condition 2) Neexistuje kontejner pro ukládání nonce parametrů 3) Uložiště je nastaveno jako neaktivní Actors Administrátor / Worker role Trigger Administrátor vyvolá ukončení použití nebo je spuštěno automaticky DESCRIPTION Step Action 1 Systémová akce: Je smazán kontejner pro ukládání asociací 2 Systémová akce: Je smazán kontejner pro ukládání nonce parametrů 3 Systémová akce: Uložiště je nastaveno jako neaktivní. USE CASE 4 Goal in context Preconditions

Tabulka B.5: Případ užití - Ukončit použití - Azure Storage

66


Příloha C

Testovací scénáře knihovny - SQL Storage USE CASE 1 Goal in context Preconditions

Success condition Actors Trigger

end

Přihlásit se Autentizuje uživatele u RP 1) RP umožňuje přihlášení prostřednictvím OpenID 2) Uživatel je neautentizován a RP je ve stavu přihlášení uživatele 3) Uložiště SQL Azure je dostupné 1) Uživatel je autentizován u RP 2) V association tabulce existuje záznam s asociací 3) V nonce tabulce existuje záznam s nonce parametrem Uživatel Uživatel vyplní svůj OpenID identifikátor a odešle žádost o přihlášení

Tabulka C.1: Případ užití - Přihlásit se - SQL Azure (1.část)

67

68

PŘÍLOHA C. TESTOVACÍ SCÉNÁŘE KNIHOVNY - SQL STORAGE

USE CASE 1 Přihlásit se DESCRIPTION Step Action 1 Je provedena inicializace uložiště - Spuštěn USE CASE 2 2 Uživatelský agent je přesměrován na stranu OP +Systémová akce: 1) Je testována existence záznamu s domluvenou asociací 2) Asociace je přítomna a platná - je použita 3 Uživatel se přihlásí na straně OP a odsouhlasí předání svých údajů 4 Uživatelský agent je přesměrován zpět na RP jako autentizovaný +Systémová akce: 1) Je testována existence záznamu s domluvenou asociací 2) Asociace je přítomna a platná - je použita 3) Je vytvořen nonce záznam EXTENSIONS Step Branching action 1a Podmínka: Provádění kroku skončilo chybou Není možné pokračovat v autentizaci - UC končí chybou 2a Podmínka: Není nalezen záznam s existující asociací nebo je neplatný Je vytvořen záznam s novou asociací 3a Podmínka: Uživatel na straně OP zruší proces autentizace Uživatelský agent je přesměrován zpět na RP jako neautentizovaný Záznam s domluveným způsobem asociace mezi RP a OP zůstane zachován 4a Podmínka: Není nalezen záznam s existující asociací nebo je neplatný Nelze ověřit podpis žádosti Proces autentizace je neúspěšný 4b Podmínka: Je nalezen nonce záznam žádosti Žádost o autentizaci je opakovaná - možný replay attack Proces autentizace je neúspěšný Tabulka C.2: Případ užití - Přihlásit se - SQL Azure (2.část)

69

USE CASE 2 Goal in context Preconditions Success end condition

Inicializovat uložiště Připraví uložiště pro použití OpenID autentizace s využitím SQL Azure Uložiště SQL Azure je dostupné 1) Existuje tabulka pro ukládání asociací 2) Existuje tabulka pro ukládání nonce parametrů 3) Je nastavena životnost ukládaných nonce parametrů

Actors Trigger Průběh USE CASE 1 DESCRIPTION Step Action 1 Systémová akce: Je nastavena životnost ukládaných nonce parametrů 2 Systémová akce: Je vytvořena tabulka pro ukládání asociací 3 Systémová akce: Je vytvořena tabulka pro ukládání nonce parametrů EXTENSIONS Step Branching action 2a Podmínka: Tabulka již existuje Je zachována existující tabulka - není vytvořena nová. 3a Podmínka: Tabulka již existuje Je zachována existující tabulka - není vytvořena nová. Tabulka C.3: Případ užití - Inicializovat uložiště - SQL Azure

Provést údržbu Vyčistí tabulky SQL Azure od asociací a nonces záznamů s prošlou dobou platnosti Preconditions Uložiště SQL Azure je dostupné Success end 1) Tabulka pro ukládání asociací neobsahuje záznamy asociací condition s prošlou dobou platnosti 2) Tabulka pro ukládání nonces neobsahuje záznamy nonce parametrů s prošlou dobou platnosti Actors Administrátor / Worker role Trigger Administrátor spustí provádění údržby nebo je spuštěno automaticky DESCRIPTION Step Action 1 Systémová akce: Je vykonán SQL příkaz k smazání expirovaných asociací 2 Systémová akce: Je vykonán SQL příkaz k smazání expirovaných nonces záznamů USE CASE 3 Goal in context

Tabulka C.4: Případ užití - Provést údržbu - SQL Azure

70

PŘÍLOHA C. TESTOVACÍ SCÉNÁŘE KNIHOVNY - SQL STORAGE

Vyčistit uložiště Smaže záznamy v tabulkách pro ukládání asociací a nonces záznamů Preconditions Uložiště SQL Azure je dostupné Success end 1) Tabulka pro ukládání asociací je prázdná condition 2) Tabulka pro ukládání nonce parametrů je prázdná Actors Administrátor / Worker role Trigger Administrátor vyvolá smazání záznamů nebo je spuštěno automaticky DESCRIPTION Step Action 1 Systémová akce: Je vykonán SQL příkaz k smazání všech asociací 2 Systémová akce: Je vykonán SQL příkaz k smazání všech nonce parametrů USE CASE 4 Goal in context

Tabulka C.5: Případ užití - Vyčistit uložiště - SQL Azure

Příloha D

Obsah přiloženého CD Obr. D.1 zobrazuje adresářovou strukturu přiloženého CD.

Obrázek D.1: Adresářová struktura přiloženého CD Adresář Azure obsahuje vygenerovaný DokuWiki Azure balíček, který je možné nahrát do MS Azure. Balíček obsahuje i potřebnou verzi PHP. Adresář Dokumentace obsahuje vygenerovanou dokumentaci ve formátu HTML k upravené části OpenID knihovny i k DokuWiki OpenID pluginu. Adresář Kod obsahuje adresáře se zdrojovými kódy. Podadresář DokuWiki_Azure obsahuje zdrojové kódy Azure projektu DokuWiki s nainstalovaným OpenID pluginem. Tento balík byl použit pro vygenerování Azure balíčku. Podadresář DokuWiki_OpenID_plugin obsahuje zdrojové kódy samotného OpenID DokuWiki pluginu. Podadresář OpenID_knihovna obsahuje zdrojové kódy samotné použité OpenID knihovny. Adresář Text obsahuje tuto práci ve formátu PDF.

71

Federace identit v cloudu. Bc. Petr Soukup

Recommend Documents