Č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
KAPITOLA 3. TEORETICKÁ ANALÝZA VYBRANÝCH TECHNOLOGIÍ
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
KAPITOLA 3. TEORETICKÁ ANALÝZA VYBRANÝCH TECHNOLOGIÍ
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
KAPITOLA 3. TEORETICKÁ ANALÝZA VYBRANÝCH TECHNOLOGIÍ
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
KAPITOLA 3. TEORETICKÁ ANALÝZA VYBRANÝCH TECHNOLOGIÍ
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
KAPITOLA 3. TEORETICKÁ ANALÝZA VYBRANÝCH TECHNOLOGIÍ
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
KAPITOLA 3. TEORETICKÁ ANALÝZA VYBRANÝCH TECHNOLOGIÍ
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
KAPITOLA 4. NASAZENÍ TECHNOLOGIE OPENID V MICROSOFT AZURE
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
4.4. ÚPRAVA KNIHOVNY
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
4.4. ÚPRAVA KNIHOVNY
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
KAPITOLA 4. NASAZENÍ TECHNOLOGIE OPENID V MICROSOFT AZURE
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
4.4. ÚPRAVA KNIHOVNY
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
KAPITOLA 4. NASAZENÍ TECHNOLOGIE OPENID V MICROSOFT AZURE
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
KAPITOLA 4. NASAZENÍ TECHNOLOGIE OPENID V MICROSOFT AZURE
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
KAPITOLA 4. NASAZENÍ TECHNOLOGIE OPENID V MICROSOFT AZURE
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 4. NASAZENÍ TECHNOLOGIE OPENID V MICROSOFT AZURE
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>
<Task commandLine=" setACL . cmd " e x e c u t i o n C o n te x t=" e l e v a t e d " taskType=" s i m p l e "/>
</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
KAPITOLA 5. INTEGRACE OPENID DO APLIKACE
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
KAPITOLA 5. INTEGRACE OPENID DO APLIKACE
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 5. INTEGRACE OPENID DO APLIKACE
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: <http://openid.net/>.
[2] OpenID Foundation. OpenID Authentication 2.0 - Final [online]. Poslední revize 2007-12-5 [cit. 2011-4-25]. Dostupné z WWW: <http://openid.net/specs/
openid-authentication-2_0.html>.
[3] Janrain. OpenID Enabled | Janrain [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW:
<http://www.janrain.com/openid-enabled>.
[4] OpenID Foundation. Get an OpenID | OpenID [online]. ©2006-2011 [cit. 2011-4-25].
Dostupné z WWW: <http://openid.net/get-an-openid/>.
[5] OASIS Open. XRI Syntax Specification [online]. Poslední revize 2005-11-14 [cit. 2011-425]. Dostupné z WWW: <http://www.oasis-open.org/committees/download.php/
15376>.
[6] Janrain. Welcome to myOpenID [online]. ©2008 [cit. 2011-4-25]. Dostupné z WWW:
<https://www.myopenid.com/>.
[7] CZ NIC. MojeID - Vítejte v mojeID [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW:
<http://www.mojeid.cz/>.
[8] Sam Ruby. Sam Ruby: OpenID for non-SuperUsers [online]. Poslední revize 2007-1-3
[cit. 2011-4-25]. Dostupné z WWW: <http://www.intertwingly.net/blog/2007/
01/03/OpenID-for-non-SuperUsers>.
[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: <http://www.ibm.com/developerworks/tivoli/library/
t-openid-tfim/index.html>.
[10] Yadis 1.0. Main Page [online]. Poslední revize 2011-4-19 [cit. 2011-4-25]. Dostupné z
WWW: <http://yadis.org/wiki/Main_Page>.
[11] Network Working Group. Diffie-Hellman Key Agreement Method [online]. Poslední
revize 1999-6 [cit. 2011-4-25]. Dostupné z WWW: <http://www.ietf.org/rfc/
rfc2631.txt>.
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: <http://openid.net/specs/openid-simple-registration-extension-1_
0.html>.
[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: <http://
openid.net/specs/openid-attribute-exchange-1_0.html>.
[14] BBC news | Technology. Engineer error knocks out Gmail [online]. Poslední revize 2009-9-2 [cit. 2011-4-25]. Dostupné z WWW: <http://news.bbc.co.uk/2/hi/
technology/8232971.stm>.
[15] Google. Federated Login for Google Account Users [online]. ©2011 [cit. 2011-425]. Dostupné z WWW: <http://code.google.com/intl/cs/apis/accounts/docs/
OpenID.html>.
[16] Plaxo. Sign-in [online]. ©2002-2011 [cit. 2011-4-25]. Dostupné z WWW: <https:
//www.plaxo.com/auth?src=header&secure=1>.
[17] CZ.NIC Správce domény CZ. Hlavní strana [online]. ©2011 [cit. 2011-4-25]. Dostupné
z WWW: <http://www.nic.cz/>.
[18] Internet2. Main page [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW: <http:
//www.internet2.edu/>.
[19] Internet2. Shibboleth [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW: <http:
//shibboleth.internet2.edu/>.
[20] Shibboleth. Technical Specifications [online]. Poslední revize 2011-04-13 [cit. 20114-25]. Dostupné z WWW: <https://wiki.shibboleth.net/confluence/display/
DEV/TechSpecs>.
[21] Internet2 Middleware. EduPerson Specification [online]. Poslední revize 2003-12 [cit.
2011-4-25]. Dostupné z WWW: <http://middleware.internet2.edu/eduperson/
docs/internet2-mace-dir-eduperson-200312.html>.
[22] Online community for the SAML OASIS Standard. Main page [online]. ©1993-2011
[cit. 2011-4-25]. Dostupné z WWW: <http://saml.xml.org/>.
[23] Česká akademická federace identit eduID.cz. Hlavní strana [online]. Poslední revize
2009-04-30 [cit. 2011-4-25]. Dostupné z WWW: <http://www.eduid.cz/wiki/eduid/
index>.
[24] CESNET. Hlavní strana [online]. ©1996-2011 [cit. 2011-4-25]. Dostupné z WWW:
<http://www.cesnet.cz/>.
[25] Pavel Satrapa. Shibboleth - identifikujte se jen jednou [online]. Poslední revize
2005-08-12 [cit. 2011-4-25]. Dostupné z WWW: <http://www.lupa.cz/clanky/
shibboleth/>.
LITERATURA
57
[26] Microsoft. Windows Live ID [online]. ©2011 [cit. 2011-12-30]. Dostupné z WWW:
<http://www.passport.net/>.
[27] Microsoft. Windows Azure Storage [online]. ©2011 [cit. 2011-4-25]. Dostupné z WWW:
<http://www.microsoft.com/windowsazure/storage/>.
[28] Microsoft. SQL Azure [online]. ©2010 [cit. 2011-4-25]. Dostupné z WWW: <http:
//www.microsoft.com/en-us/sqlazure/default.aspx>.
[29] Maarten Balliauw. Developing with Windows Azure Storage & SQL Azure [online]. ©2009 [cit. 2011-4-25]. Dostupné z WWW: <http://www.slideshare.net/
maartenba/windows-azure-storage-sql-azure>.
[30] Microsoft MSDN. Naming and Referencing Containers, Blobs, and Metadata [online]. Poslední revize 2010-11-22 [cit. 2011-12-29]. Dostupné z WWW: <http:
//msdn.microsoft.com/en-us/library/windowsazure/dd135715.aspx>.
[31] PHP Group. PEAR - PHP Extension and Application Repository [online]. ©2001-2011
[cit. 2011-4-26]. Dostupné z WWW: <http://pear.php.net/>.
[32] PHP Group. PEAR - Package Information: DB [online]. Poslední revize 2010-12-24
[cit. 2011-4-26]. Dostupné z WWW: <http://pear.php.net/package/DB>.
[33] PHP Group. PEAR - Package Information: MDB2 [online]. Poslední revize 2010-8-29
[cit. 2011-4-26]. Dostupné z WWW: <http://pear.php.net/package/MDB2>.
[34] Stoyan Stefanov. DB-2-MDB2 [online]. Poslední revize 2006-2-4 [cit. 2011-4-26]. Dostupné z WWW: <http://www.phpied.com/db-2-mdb2/>.
[35] Microsoft MSDN. General Guidelines and Limitations (SQL Azure Database) [online].
©2011 [cit. 2011-4-27]. Dostupné z WWW: <http://msdn.microsoft.com/en-us/
library/ee336245.aspx>.
[36] InstallationWiki.org. MDB2 - Data types [online]. Poslední revize 2010-9-15 [cit. 2011-428]. Dostupné z WWW: <http://www.installationwiki.org/MDB2#Data_Types>.
[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:
<http://sourcecookbook.com/en/recipes/60/
janrain-s-php-openid-library-fixed-for-php-5-3-and-how-i-did-it>.
[38] CURL. Bundle of CA Root Certificates [online]. Poslední revize 2011-4-13 [cit. 2011-425]. Dostupné z WWW: <http://curl.haxx.se/ca/cacert.pem>.
[39] The Eclipse Foundation. Eclipse - The Eclipse Foundation open source community
website [online]. ©2011 [cit. 2011-12-30]. Dostupné z WWW: <http://http://www.
eclipse.org/>.
[40] Soyatec. Windows Azure Tools 4 Eclipse [online]. ©2009 [cit. 2011-12-30]. Dostupné z
WWW: <http://www.windowsazure4e.org/>.
58
LITERATURA
[41] Dokuwiki. Main page [online]. Poslední revize 2011-1-19 [cit. 2011-4-25]. Dostupné z
WWW: <http://www.dokuwiki.org/dokuwiki>.
[42] DokuWiki. DokuWiki OpenID plugin [online]. Poslední revize 2011-2-15 [cit. 2011-1230]. Dostupné z WWW: <http://www.dokuwiki.org/plugin:openid>.
[43] Alistair Cockburn. Alistair Cockburn - Basic use case template [online]. Poslední
revize 1998-4-26 [cit. 2011-12-30]. Dostupné z WWW: <http://alistair.cockburn.
us/index.php/Basic_use_case_template>.
[44] GitHub. OpenID / PHP OpenID repository [online]. ©2011 [cit. 2011-5-1]. Dostupné z
WWW: <https://github.com/openid/php-openid>.
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
PŘÍLOHA B. TESTOVACÍ SCÉNÁŘE KNIHOVNY - AZURE STORAGE
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 B. TESTOVACÍ SCÉNÁŘE KNIHOVNY - AZURE STORAGE
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
Download

Federace identit v cloudu