MASARYKOVA UNIVERZITA F}w¡¢£¤¥¦§¨  AKULTA INFORMATIKY !"#$%&'()+,-./012345

Knihovna pro pˇrístup k federacím identit

BAKALÁRSKÁPRÁCEˇ

Marcel Poul

Brno, 2011

Prohlášení

Prohlašuji, že tato bakaláˇrskápráce je mým p ˚uvodnímautorským dílem, které jsem vypracoval samostatnˇe.Všechny zdroje, prameny a literaturu, které jsem pˇrivypracování používal nebo z nich ˇcerpal,v práci ˇrádnˇecituji s uvedením úplného odkazu na pˇríslušnýzdroj.

Marcel Poul

Vedoucí práce: RNDr. Daniel Kouˇril

iii

Podˇekování

Tímto dˇekujivedoucímu mé bakaláˇrsképráce RNDr. Danielu Kouˇriloviza cenné rady a ˇcas,který mi vˇenovalpˇriˇrešenídané problematiky.

v

Shrnutí

Tato práce se vˇenujenávrhu knihovny pro pˇrístupk federacím identit a její implementaci pomocí jakyka C. V práci je pˇredstavenprincip federací iden- tit a popsán návrh a implementace knihovny.

vii

Klíˇcováslova

Federace identit, poskytovatel služeb, poskytovatel identit, SAML, Shibbo- leth

ix

Obsah

1 Úvod ...... 3 2 Federace identit ...... 5 2.1 Struktura federací ...... 5 2.2 Security Assertion Markup Language (SAML) ...... 7 2.3 Shibboleth ...... 7 2.4 Federace eduID.cz ...... 8 2.5 SWITCHaai ...... 9 2.6 eduroam ...... 9 2.7 OpenID ...... 10 2.8 MojeID ...... 11 3 Návrh knihovny pro pˇrístupk federacím identit ...... 13 3.1 Analýza proces ˚upˇripˇrístupuk federacím identit ...... 13 3.2 Požadavky na ˇrešení ...... 16 3.2.1 Funkcionalita ...... 16 3.2.2 Vlastnosti knihovny ...... 16 3.2.3 Rozhraní pro programování aplikací (API) ...... 17 3.3 Konfigurace knihovny ...... 17 4 Implementace knihovny ...... 19 4.1 Datové struktury pro uchování informací ...... 19 4.2 Knihovna libcurl ...... 21 4.3 API knihovny ...... 21 4.3.1 Inicializace knihovny ...... 22 4.3.2 Pˇrístupk SP ...... 23 4.3.3 Autentizace uživatele bez pˇrístupuk SP ...... 23 4.3.4 Získání certifikátu veˇrejnéhoklíˇce ...... 23 4.3.5 Ukonˇcenípráce s knihovnou ...... 23 4.4 Konfiguraˇcnísoubor ...... 24 4.4.1 Formát konfiguraˇcníhosouboru ...... 24 5 Použití navrhované knihovny ...... 27 5.1 Definice struktur a inicializace knihovny ...... 27 5.2 Demonstrace funkcionalit knihovny ...... 28 5.3 Chybové hlášení a ukonˇcenípráce s knihovnou ...... 29 6 Závˇer ...... 31 A Obsah pˇriloženéhoCD ...... 35

1

1 Úvod

Poˇcítaˇcovíuživatelé dnes velmi ˇcastovyužívají služby dostupné on-line. Potˇrebujíje napˇríkladjako zdroje informací pˇristudiu nebo zamˇestnání. Aby mˇelike službˇepˇrístupjen žádoucí uživatelé, využívají aplikace bez- peˇcnostnímechanismy zajišt’ující jejich autentizaci a autorizaci. O každém z nich také spravují sadu informací, které urˇcujíuživatelovu identitu. Správu uživatel ˚utémˇeˇrvždy obstarává každá služba zvlášt’. Tento pro- ces obnáší bezpeˇcnostnírizika a odpovˇednost za svˇeˇrenéinformace. Z eko- nomického hlediska se jedná o proces nároˇcný,nebot’ je tˇrebazakoupit od- povídající hardware a software. Je nutné také zamˇestnatadministrátory, kteˇríse postarají o jejich obsluhu. Duplicitní správa identit je tedy z po- hledu poskytovatel ˚uslužeb v mnoha ohledech neefektivní. Aplikace pˇriautentizaci vyžadují uživatelské autentizaˇcníchúdaje. Není výjimkou, že si uživatelé své pˇrihlašovacíúdaje ukládají a dostateˇcnˇene- chrání. Napˇríkladhesla si píší na kousek papíru, který mají nalepený na viditelném místˇeu svého poˇcítaˇce.V tom pˇrípadˇeusnadˇnujímožným útoˇc- ník ˚umzískat autentizaˇcníinformace. Uživatelé, kteˇrípˇristupujík mnoha službám, jsou nuceni spravovat nˇe- kolik tajných informací. To je nepohodlné a m ˚užeto také vést k situaci, kdy uživatelé používají stejná hesla pro pˇrístupk r ˚uznýmslužbám, aby si ulehˇcilijejich zapamatování. Tím vystavují riziku kompromitace nezávislé služby. Ty spolu nespolupracují, proto ani nemají možnost navzájem si pˇre- dat informaci, že heslo nˇejakéhouživatele bylo vyzrazeno. Z pohledu bezpeˇcnostia uživatelského komfortu tedy není popisovaný mechanismus správy uživatelských identit optimální. Nˇekterézásadní ne- dostatky zmínˇenéhoschématu ˇreší federace identit (identity federation).[6] Model federativních mechanism ˚umá mnoho výhod oproti klasickému pˇrístupu,kdy je správa uživatel ˚uˇrešena každou aplikací zvlášt’. Z pohledu uživatele je pˇríjemné,že autentizace probíhá vždy u jeho domovské insti- tuce pomocí jediných autentizaˇcníchúdaj ˚u,které jsou ˇcastotvoˇrenykom- binací jméno – heslo. Odpadá nutnost pamatovat si nˇekolikpˇrihlašova- cích údaj ˚upro pˇrístupk r ˚uznýmslužbám, tím je dosaženo vyššího pohodlí a efektivity pˇrístupuke službám. D ˚uležitouvlastností ˇrízenípˇrístupuve federacích je Single sign-on (SSO). Ta uživateli zaruˇcuje,že se v pr ˚ubˇehusezení autentizuje pouze jednou. Poté má pˇrístupke všem službám v dané federaci. Ukazuje se však, že SSO s je- diným heslem je slabým místem federací. Nedovoluje napˇríkladzavést více „úrovní bezpeˇcnosti“.Pˇreszmínˇenáomezení je SSO žádoucí z pohledu uži-

3 1. ÚVOD vatele i bezpeˇcnostisystému. Cílem této bakaláˇrsképráce je navrhnout a implementovat knihovnu pro pˇrístupk federacím identit. Práce se zamˇeˇrujena federace založené na protokolu SAML1, které využívají HTTP a webový prohlížeˇcpro pˇrístup ke službám. Takové federace nejsou vhodné napˇríkladpro využití aplika- cemi bez grafického rozhraní. Z pohledu uživatele jsou pak nepraktické pro vykonávání pravidelnˇese opakujících operací, jako je tˇrebagenerování cer- tifikát ˚us krátkou dobou platnosti. Knihovna poskytne vývojáˇrinástroj pro autentizaci a autorizaci uživa- tel ˚uve federovaném prostˇredí,aniž by bylo potˇrebake zmínˇenýmúkon ˚um použít webový prohlížeˇc.Dále poskytne mechanismus pro kontrolu uži- vatelských autentizaˇcníchúdaj ˚ubez pˇrístupuke službˇe.Pomocí knihovny bude možné také získat certifikát veˇrejnéhoklíˇceod specializované služby. V textu této práce je ve druhé kapitole vysvˇetlenazákladní terminologie. Katipola dále popisuje vlastnosti federací identit a pˇredstavujetypickou in- frastrukturu federace. Ve tˇretíkapitole se ˇctenáˇrdozví, jaké procesy probíhají pˇripˇrístupuk fe- deracím identit. Dále je zde popsán návrh knihovny vˇcetnˇepožadavk ˚una funkcionalitu. Následující ˇctvrtákapitola je vˇenovánaimplementaci knihovny. Nej- prve jsou pˇrestavenyzákladní datové typy, které jsou v knihovnˇedefi- novány. Popsáno je také jejich využití. Vývojáˇrise v této ˇcástipráce mo- hou seznámit s množinou funkcí, které slouží jako rozhraní pro pˇrístupke knihovnˇe.Poté je detailnˇepopsán zp ˚usobkonfigurace knihovny. Pátá kapitola je vˇenovánademonstraci použití navrhované knihovny. Jsou zde pˇredevšímuvedeny komentované ukázky kódu knihovny. V poslední šesté kapitole jsou shrnuty výsledky práce a plánovaný smˇer vývoje knihovny.

1.

4 2 Federace identit

Federace identit neboli spolˇcenítotožností je systém pro zpˇrístupnˇeníon- line služeb uživatel ˚umv poˇcítaˇcovésíti napˇríˇcr ˚uznýmidoménami (cross- domain). Doména v tomto kontextu oznaˇcujeoblast p ˚usobnostiorganizace, která poskytuje služby. Federace identit zajišt’uje autentizaci a autorizaci uživatele pro pˇrístupk federovaným službám pomocí uživatelových au- tentizaˇcníchúdaj ˚u.Vychází z potˇrebyuživatel ˚upohodlnˇea efektivnˇepˇri- stupovat ke zdroj ˚uminformací a z potˇreborganizací tyto služby bezpeˇcnˇe nabízet. Federace identit dovoluje uživateli pˇrihlásitse k r ˚uznýmfedero- vaným službám za pomoci jediných autentizaˇcníchúdaj ˚u.Další d ˚uležitou vlastností federací je SSO.

2.1 Struktura federací

Pˇredpokládáse, že každý, kdo chce pˇristoupitk nˇejakéfederované službˇe na Internetu, má svou federovanou identitu. Její správu zajišt’uje domovská organizace uživatele, která poskytuje jednotné standardizované rozhraní pro distribuci atribut˚u, výraz ˚upopisujících uživatele. Toto rozhraní je ozna- ˇcovánojako poskytovatel identity (Identity Provider, IdP). Koncové služby se ve federacích nazývají poskytovatelé služeb (Service Providers, SP). Model fe- deraˇcníhouspoˇrádáníje znázornˇenna obrázku 2.1. Pˇrenášenéatributy mo- hou být napˇríklad: eduPersonPrincipalName eduPersonAffiliation eduPersonScopedAffiliation SP má možnost povolit, nebo zamítnout pˇrístupke svým službám s ohle- dem na informace získané od IdP. D ˚uležitousouˇcástímnoha federací je služba Where Are You From (WAYF), ke které uživatel pˇristupujepˇredsa- motným kontaktováním SP. Zde si ze seznamu nabízených IdP vybírá toho, v ˚uˇcikterému se chce autentizovat. Na obrázku 2.2 je ukázka ˇcástiwebové stránky, na které si uživatel pomocí formuláˇrevolí svého IdP. Instituce, které se organizují do federací, pracují podle pˇredemdohod- nutých pravidel. Ta ˇcastobývají smluvnˇestvrzena. Zachycuje se v nich spe- cifikace politik nutných k ustanovení d ˚uvˇerymezi ˇclenyfederace, nebot’ zodpovˇednostpˇrisprávˇeuživatelských dat je na stranˇeIdP, nikoliv SP. Pˇrizakládání federace se obvykle definuje schéma atribut ˚u,které si jed- notlivé entity (SP a IdP) ve federaci o uživateli vymˇeˇnují.Entity se také ˇcasto domlouvají na syntaxi a sémantice atribut ˚u.

5 2. FEDERACEIDENTIT

Obrázek 2.1: Model federaˇcníhouspoˇrádání

Obrázek 2.2: výbˇerIdP pomocí WAYF serveru

6 2. FEDERACEIDENTIT

V souˇcasnédobˇese ukazuje, že v nˇekterýchpˇrípadechje vhodnˇejší, když se IdP a SP dohodnou na zmínˇenýchdefinicích sami až pˇripˇrístupu uživatele ke službˇe.Tento zp ˚usobzaruˇcuje,že požadavky ze strany SP na množinu uživatelských atribut ˚ujsou pˇrikaždém pˇrístupuke službˇeaktu- ální. Atributy v dané chvíli nepotˇrebnépro autorizaci se nepˇrenášejí,chrání se tím soukromí uživatel ˚u.Minimalizuje se také možnost špatné interpre- tace atribut ˚uv rámci federace.

2.2 Security Assertion Markup Language (SAML)

SAML je standard udržovaný konsorciem OASIS, které se stará o ˇrízenívý- voje, pˇrijímánía konvergenci otevˇrenýchstandard ˚u.[1]Mimo standardu SAML jsou velmi známé napˇríklad DocBook nebo OpenDocument. SAML je založený na XML. Specifikuje pˇridruženou množinu protokol ˚uzapojených do správy systému SAML. Dále definuje syntaxi a sémantiku tvrzení (asser- tions), výrok ˚ud ˚uvˇeryhodnýchstran o jiném subjektu.Ve federacích identit se za d ˚uvˇeryhodnouentitu považuje poskytovatel identit, který posílá po- skytovateli služeb tvrzení o svých uživatelích. V dobˇepsaní této práce je verze standardu 2.0. Aby spolu jednotlivé entity mohly komunikovat, musí o sobˇeza prvé vˇedˇeta za druhé si d ˚uvˇeˇrovat.K tomuto úˇceluslouží metadata , jejichž sché- ma definuje také SAML. Metadata obsahují d ˚uležitéinformace o entitách federací. Mohou napˇríkladpopisovat množinu atribut ˚u,které SP potˇrebuje pro autorizaci uživatele. Komunikace mezi entitami je témˇeˇrvždy šifro- vána. Používají se mechanismy založené na principech asymetrické kryp- tografie, proto je d ˚uležitéd ˚uvˇeryhodnˇedistribuovat veˇrejnéklíˇcezúˇcastnˇe- ných stran. K tomuto úˇceluse také využívají metadata.[7]

2.3 Shibboleth

[. . . ]„The Shibboleth System is a standards based, open source software package for web single sign-on across or within organizational boundaries.“[3]

Middleware Shibboleth je vyvíjen sdružením Internet21. Ve webovém prostˇredílze s jeho pomocí implementovat a ˇríditsystém s vlastnostmi SSO pro pˇrístupke službám. Implementuje standardy federací identit, kon- krétnˇe SAML , ale m ˚užespolupracovat i s jinými SAML kompatibilními systémy, jako je simpleSAMLphp2. Shibboleth pomocí standardu SAML zpro-

1. 2. http://simplesamlphp.org/

7 2. FEDERACEIDENTIT

Obrázek 2.3: Pˇrístupk federaci identit stˇredkováváautentizaci, autorizaci a výmˇenuatribut ˚u. Shibboleth je projekt s otevˇrenýmkódem (open source), volnˇedostupný pod licencí Apache Soft- ware License3. Pokud chce uživatel pˇristoupitke službˇeve federovaném prostˇredí,které používá systém Shibboleth, využije k tomu webový prohlížeˇc.Jednotlivé kroky jsou znázornˇenyv obrázku 2.3: 1. Nejprve se uživatel pokusí získat pˇrístupke službˇezadáním její URL. 2. Jestliže k dané službˇepˇristupujeuživatel poprvé, je ihned pˇresmˇe- rován na server WAYF. V opaˇcnémpˇrípadˇemu m ˚užebýt povolen pˇrístuppˇrímo.Služba WAYF je nejˇcastˇejiˇrešenajako webová stránka s formuláˇrem,na které si uživatel vybere IdP své domovské organi- zace. 3. V tomto kroku je uživatel k vybranému IdP pˇresmˇerován. Zde pro- bˇehnejeho autentizace. 4. Pokud tento proces probˇehlúspˇešnˇe,je naveden zpˇetk p ˚uvodnímu SP. Na základˇetvrzení, která si mezi sebou SP a IdP vymˇení,m ˚uže SP povolit uživateli pˇrístupke své službˇe.

2.4 Federace eduID.cz

EduID.cz je Ceskᡠakademická federace identit. Za cíl si bere:

3.

8 2. FEDERACEIDENTIT

[. . . ]„poskytnout svým ˇclen˚umrámec pro vzájemné využívání identit uživatel˚upˇri ˇrízenípˇrístupuk sít’ovým službám pˇrirespektování ochrany osobních údaj˚u.“[4]

Jejím operátorem je CESNET4. , který se stará o koordinaci dˇenínebo tˇrebaregistraci a podporu ˇclen˚u.Je také vykonavatelem federaˇcnípolitiky eduID.cz. To je dokument, jenž ustanovuje zásady provozu této federace. Vymezuje d ˚uležitépojmy jako federace identit, metadata nebo poskytovatel slu- žeb. Vymezuje role subjekt ˚uzapojených do systému jako napˇríklad operátor federace nebo uživatel. Dokument také obsahuje podmínky zapojení do fe- derace nebo její opuštˇení.[5] Drtivá vˇetšinaIdP a SP ve federaci eduID.cz využívá middleware Shib- boleth. Instituce zapojené do této infrastruktury jsou pˇredevšímˇceskéuni- verzity. Nechybí mezi nimi Univerzita Karlova v Praze nebo Masarykova univerzita v Brnˇe.Kompletní seznam SP a IdP je umístˇenna webových stránkách federace. S eduID.cz je spjatá testovací federace czTestFed. Pravidla pro pˇrijetído této federace jsou volnˇejšínež u eduID.cz. Neopírá se totiž o žádné dohody a smlouvy mezi organizacemi.

[. . . ]„czTestFed vzniká za úˇcelemtestování nástroj˚una federativní správu identit a aplikací využívající prostˇredkyfederace pro úˇcelyautentizace a autorizace.“[4]

2.5 SWITCHaai

Pˇríklademjedné z nejstarších federací založených na systému SAML, která používá systém Shibboleth, je SWITCHaai5. Ta je v souˇcasnostitvoˇrenatémˇeˇr všemi švýcarskými univerzitami. Federace je ˇrízenaorganizací SWITCH. Zajímavý je její partnerský program, do kterého jsou zapojeny mezinárodní spoleˇcnostijako napˇríkladApple Sales International nebo vzdˇelávacíinsti- tuce jako Masarykova univerzita, jež vystupuje jako poskytovatel služeb.

2.6 eduroam

V roce 2003 vznikl mezinárodní projekt eduroam. Jeho cílem je umožnit uži- vatel ˚umpomocí federované identity transparentní využívání sítí provozo- vaných výzkumnými a vzdˇelávacímiinstitucemi po celém svˇetˇe.Instituce v eduroam tvoˇrína národní úrovni federace, které jsou dále sdružovány do

4. 5.

9 2. FEDERACEIDENTIT regionálních konfederací.[8] V ˇceskémprostˇredífunguje projekt eduroam.cz, který je zaštit’ován sdružením CESNET. Pro autentizaci a autorizaci uživatele ve federaci slouží hierarchie ser- ver ˚u RADIUS. Každá organizace v eduroam musí tento server provozovat a pˇripojitho k národnímu RADIUS serveru. Technologie eduroam využívá standardu 802.1X asociace IEEE6. Tento standard poskytuje autentizaˇcníme- chanismy pro zaˇrízení,která se chtˇejípˇripojitk lokální síti (LAN). Pro získání pˇrístupuk síti organizace zapojené do eduroam se uživatel pˇripojík sít’ovému zaˇrízení,napˇríkladbezdrátovému pˇrístupovémubodu (AP) v této síti. Protokol EAP, definovaný v RFC 3748, umožní vytvoˇrit chránˇenéspojení (tunel) mezi uživatelovým zaˇrízeníma jeho domovským RADIUS serverem. Zvláštní software (supplicant) poté od uživatele odešle autentizaˇcníúdaje na server, kde se provede vlastní autentizace. Na základˇe výsledku autentizace AP udˇelujepovolení, nebo zamítnutí pˇrístupuk sítí. Pˇrenášenéinformace jsou známé pouze koncovým zaˇrízenímv tunelu, tím se mimo jiné chrání uživatelovo soukromí.

2.7 OpenID

OpenID je sada standard ˚u,která umožˇnujepˇrístupk r ˚uznýmwebovým stránkám. pomocí jediného úˇctuzastupujícího uživatelovu identitu. Projekt používá vlastní standardizované protokoly pro autentizaci a au- torizaci uživatele. Oproti federacím založeným na systému SAML nepo- užívá metadata a je tedy pro uživatele snadnˇejšípˇrihlásitse ke službám pomocí nového IdP. Uživatel se v tomto systému registruje u poskytovatele identit oznaˇco- vaného jako registrátor. MyIpenID7 je pˇríkladtakového registrátora. Pˇrire- gistraci je uživateli pˇridˇelenjednoznaˇcnýidentifikátor, který má tvar URL. Heslo si ˇcastouživatel vybírá sám. Nˇekteˇríregistrátoˇriumožˇnujíi jiné zp ˚u- soby autentizace, napˇríkladvyužití certifikát ˚u.Pˇriregistraci lze zadat další nepovinné atributy jako e-mail nebo datum narození. Nad množinou pˇri- daných atribut ˚umá kontrolu sám uživatel, spravuje je registrátor. Pˇripˇrístupuke službˇeje uživatel pˇresmˇerován na svého registrátora a zde se autentizuje. Je zˇrejmé,že tento systém má kromˇeviditelných výhod federované iden- tity také zásadní nedostatky. Uživatel o sobˇem ˚užepˇriregistraci tvrdit témˇeˇr cokoli, není žádná záruka, že jím zadané informace nejsou zcela smyšlené.

6. 7.

10 2. FEDERACEIDENTIT

Míra bezpeˇcnostiproto pˇrímozávisí na d ˚uvˇeryhodnostia zabezpeˇceníre- gistrátora a jeho mechanismu ovˇeˇrenískuteˇcnéidentity uživatele. Obecnˇe ale nelze zabezpeˇcitd ˚uvˇeryhodnostposkytovatel ˚uslužeb ani poskytova- tel ˚uidentit:

[. . . ]„Today, anyone can choose to use an OpenID or become an OpenID Provider for free without having to register or be approved by any organization.“[2]

Systém je náchylný na r ˚uznédruhy útok ˚u,napˇríklad phishing. Navzdory zmínˇenýmnedostatk ˚ummá OpenID podporu mnoha silných hráˇc˚una poli sít’ových technologií. Jako pˇríkladlze uvést spoleˇcnostGoogle nebo službu flickr.

2.8 MojeID

V listopadu 2010 spustilo sdružení CZ.NIC8 službu mojeID9. Jedná se o po- dobnou službu jako registrátor v OpenID, je dokonce na jeho standardech založena. Pro aktivaci úˇctuuživatele je nutné ovˇeˇritjeho deklarovanou identitu dvˇemar ˚uznýmizp ˚usoby. Elektronickou poštou a formou SMS jsou doru- ˇcenytajné informace (PIN), které slouží k dokonˇceníregistrace. Pro plné využití úˇctuje však nutné pˇriregistraci zadat platnou adresu pro listovní korespondenci. Na ni pˇrijdetˇretíPIN pro ovˇeˇreníidentity. Po úspˇešném zadání této informace službˇemojeID má uživatelova identita status identi- fikovaný koktakt. Identitu je možné povýšit na úroveˇnvalidovaného kontaktu. V tom pˇrí- padˇeje nutné fyzicky ovˇeˇritidentitu uživatele, napˇríkladpomocí obˇcan- ského pr ˚ukazuna kontaktních místech CZ.NIC. Další možností je doruˇcit zmínˇenémusdružení žádost o validaci s úˇrednˇeovˇeˇrenýmpodpisem. Na žádost je také možné použít elektronický podpis ovˇeˇrenýuznávanou certi- fikaˇcníautoritou. Poskytovatelé služeb mají tedy možnost volit ze dvou úrovní ovˇeˇrení uživatele. Zejména vyšší zmínˇenáúroveˇnposkytuje jistotu, že uživatel sku- teˇcnˇeexituje. Pˇrístupk webovým službám pomocí služby mojeID a OpenID je díky vzájemné kompatibilitˇetémˇeˇrstejný. Nˇekterépˇredevšímˇceskéor- ganizace dokonce podporují mojeID pˇrímo.

8. 9.

11

3 Návrh knihovny pro pˇrístupk federacím identit

Jedním z cíl ˚uknihovny je poskytnout programátor ˚umfunkcionalitu, po- mocí které lze usnadnit uživatel ˚umpˇrístupk federacím identit. Rešením,ˇ jak toho dosáhnout, je skrýt pˇreduživatelem mechanismy vykonávané pˇri pˇrístupuk federacím a do maximální míry je zautomatizovat. S tím souvisí odstranˇenínutnosti použít pro pˇrístupk federaci webový prohlížeˇc. Významnou souˇcástíˇrešeníje umožnit autentizaci uživatele u svého po- skytovatele identity a zajistit pˇrístupke službˇedistribucí potˇrebnýchdat poskytovateli služeb. To vše s minimálním aktivním zapojením uživatele. Knihovna bude ˇrešitproblém pˇrihlášeníuživatele do federace identit. Lze si pˇredstavitsituaci, kdy uživatel pˇripˇrihlášeníke svému desktopu zadá své autentizaˇcníúdaje pro pˇrihlášeník federaci a vybere svého IdP. Poté aplikace využívající navrhovanou knihovnu automaticky zajistí pˇrí- stup k federaci po celou dobu, kdy uživatel na daném desktopu pracuje. Knihovna bude pˇripravenaˇrešitproblém získání certifikátu veˇrejného klíˇceod SP. Vygeneruje pár RSA klíˇc˚uo délce 512 bit ˚ua veˇrejnýklíˇcza- šle službˇeve federaci, která vystupuje jako certifikaˇcníautorita (CA). Ta jeho veˇrejnýklíˇcpodepíše svým soukromým klíˇcema pošle zpˇetuživateli. Knihovna bude schopna toto chování demonstrovat na pevnˇezvoleném SP a bude pˇripravenapro rozšíˇrenífunkcionality na libovolného SP. To je vhodné pro ˇcastézískávání certifikátu s krátkou dobou platnosti.

3.1 Analýza proces ˚upˇripˇrístupuk federacím identit

Pˇredsamotným návrhem knihovny je nejprve nutné analyzovat procesy, které probíhají od úvodního kontaktování SP až po autentizaci uživatele. Obrázek 3.1 znázorˇnujeprobíhající komunikaci a postupy pˇripˇrístupuuži- vatele ke službˇeve federaci identit. Ukázka pˇredpokládá,že uživatel k dané službˇepˇristupujepoprvé. Následuje popis d ˚uležitýchˇcástíkomunikace. Popis se nezabývá pˇrímoukomunikací mezi SP a IdP. Na úrovni HTTP hla- viˇcek jsou popsány pouze provedené operace žádoucí pro pochopení pro- blematiky pˇrístupuk federacím.

1. Uživatel do prohlížeˇcezadá webovou adresu služby, ke které chce pˇristoupit.Webový prohlížeˇcvyšle na zadanou adresu HTTP hla- viˇcku GET.

2. SP nemá dostatek informací, aby mohl daný subjekt úspˇešnˇeauto- rizovat pro pˇrístup.Proto mu odpovídá hlaviˇckou HTTP 302, která

13 3. NÁVRH KNIHOVNY PRO PRÍSTUPKFEDERACÍMIDENTITˇ

Obrázek 3.1: Procesy probíhající pˇripˇrístupuk federované službˇe

14 3. NÁVRH KNIHOVNY PRO PRÍSTUPKFEDERACÍMIDENTITˇ

znaˇcí,že zadaný zdroj je doˇcasnˇepˇresunutý.Spolu s tím pošle URL cíle pˇresmˇerování v hlaviˇcceLocation. Cástˇ generované URL je ad- resa serveru WAYF, v další ˇcástijsou zakódované informace od SP jako jeho URL. 3. Webový prohlížeˇcpošle výzvu GET na pˇrijatounovou adresu. 4. WAYF server odpoví HTTP 200 OK a pošle prohlížeˇciwebovou stránku s formuláˇrem. V nˇemje seznam aktuálnˇedostupných organizací, které poskytují IdP. 5. Zde si uživatel vybere z nabídnutých možností svou domovskou or- ganizaci. Na základˇetoho webový prohlížeˇczformuluje odpovˇed’ a metodou POST ji odešle zpˇetslužbˇeWAYF. 6. Následnˇezmiˇnovanáslužba odpoví HTTP 302 a pˇresmˇeruje uživa- tele na vybraného IdP stejným zp ˚usobemjako pˇredtímSP. 7. Prohlížeˇcse snaží pˇristoupitk IdP. V tomto kroku m ˚užeještˇedojít k dalším pˇresmˇerování, ale pouze v rámci dané organizace. Komu- nikace s IdP bývá témˇeˇrvždy zabezpeˇcenapomocí SSL/TLS. 8. IdP použije autentizaˇcnímechanismy a odešle uživateli výzvu k au- tentizaci. Typicky se jedná o webovou stránku s formuláˇrem,do kte- rého uživatel vyplní své pˇrihlašovacíúdaje, pˇrípadnˇepˇriložísv ˚uj certifikát veˇrejnéhoklíˇce. 9. Webový prohlížeˇcvyplnˇenýformuláˇrzpracuje a odešle metodou POST zpˇetIdP. 10. IdP zkontroluje pˇrijatádata a jako odpovˇed’ pošle html stránku, na které je pˇredvyplnˇenýformuláˇr.Hodnota jeho atributu je URL poskytovatele služeb. Formuláˇrdále obsahuje sadu tvrzení o uži- vateli a další atributy jako tˇrebastatus autentizace. Tato ˇcástje formá- tovaná podle standardu SAML a zakódovaná pomocí base64. Je také podepsaná soukromým klíˇcemIdP a ˇcástdat je šifrovaná veˇrejným klíˇcemSP. Tím se zajistí d ˚uvˇernost,integrita a autentiˇcnostposíla- ných dat. 11. Souˇcástípˇrijatýchdat je kód v jazyce /textitJavaScript, který po na- ˇctenído prohlížeˇcepˇredvyplnˇenýformuláˇrautomaticky odešle na adresu v atributu . Pokud uživatel nemá JavaScript v prohlí- žeˇcipovolený, musí uživatel stisknutím požadovaného tlaˇcítkaode- slat formuláˇrmanuálnˇe.

15 3. NÁVRH KNIHOVNY PRO PRÍSTUPKFEDERACÍMIDENTITˇ

12. V posledním kroku provede SP autorizaci uživatele na základˇepˇri- jatých tvrzení.

3.2 Požadavky na ˇrešení

Souˇcástízadání práce bylo použít pro vytvoˇreníknihovny programovací jazyk C.

3.2.1 Funkcionalita

• Autentizace a autorizace – Knihovna musí zajistit bezproblémovou a bezpeˇcnouautentizaci uživatele v ˚uˇcizadanému IdP a získaná opráv- nˇenípˇredatkonkrétní požadované službˇe.

• Kontrola zadaných autentizaˇcníchúdaj ˚u– Knihovna poskytuje mož- nost, jak zkontrolovat validitu autentizaˇcníchdat pˇrímou IdP.

• Získání certifikátu veˇrejnéhoklíˇce– Uživatel m ˚užepoužít knihovnu k vygenerování páru RSA klíˇc˚u.Veˇrejnýklíˇcm ˚uženáslednˇenechat podepsat u SP, který takovou službu nabízí.

3.2.2 Vlastnosti knihovny

• Rozšiˇritelnost– Pro další rozšíˇrenífunkcionalit knihovny je vhodné na tuto vlastnost myslet již pˇrisamotném návrhu. Funkce definované v knihovnˇeje úˇcelné pˇripravittak, aby jejich pˇrípadnézmˇeny nebo rozšíˇrenípostihly co nejmenší ˇcástknihovny.

• Modularita – Nˇekteréˇcástiknihovny je dobré pˇripravitpro použití modulárních ˇcástís ohledem na budoucí vývoj knihovny. Kromˇeau- tentizace a autorizace m ˚užev budoucnu knihovna sloužit tˇrebak zís- kání certifikátu uživatelova veˇrejnéhoklíˇceod certifikaˇcníautority (CA) poskytované SP. Toho lze dosáhnou vytvoˇrenímmodul ˚upro jednotlivé SP a jejich dynamickým naˇcítánímz knihovny.

• Robustnost – Knihovna by mˇelaadekvátnˇereagovat na pˇredvída- telné chybové stavy a nezp ˚usobovatzbyteˇcnýpád aplikace. Funkce, je-li to žádoucí, mohou napˇríkladkontrolovat své vstupní parametry a v pˇrípadˇeproblému delegovat tuto informaci nadˇrazenýmrutinám pomocí návratových hodnot nebo chybových zpráv.

16 3. NÁVRH KNIHOVNY PRO PRÍSTUPKFEDERACÍMIDENTITˇ

• Minimální zapojení uživatele – Pˇrisamotném zpracování požadavku na pˇrístupk federaci se od uživatele neoˇcekávážádná zbyteˇcnáko- munikace s knihovnou. Napˇríkladpo úspˇešnéautorizaci u SP je pˇrí- stup k dalším službám zajišt’ován knihovnou automaticky.

3.2.3 Rozhraní pro programování aplikací (API) Styˇcnouplochou mezi vývojáˇrema knihovnou je API. Vývojáˇrise ˇcastoroz- hodují, jakou knihovnu vybratpro sv ˚ujprojekt, na základˇevhodnˇenavrže- ného API. Požadavky, na které je kladen d ˚urazpˇrinávrhu této knihovny, jsou:

• Pevné definované rozhraní – Aplikace by mˇelymít pˇrístuppouze k jasnˇevymezenému souboru funkcí. Jejich vnitˇrníimplementace by mˇelabýt volajícímu programu skrytá.

• Jednoduchost – Použití knihovny by mˇelobýt pro programátora co nejsnadnˇejší.Navrhované funkce API by mˇelybýt dobˇredokumen- tované, napˇríkladformou komentáˇr˚uv hlaviˇckovýchsouborech.

3.3 Konfigurace knihovny

Knihovna potˇrebujepro sv ˚ujbˇehv urˇcitéfederaci znát údaje o všech IdP, kteˇríjsou v dané federaci k dispozici. Je proto úˇcelnédát knihovnˇetyto in- formace k dispozici dˇríve,než probˇehnejakýkoli pokus o pˇripojeník fede- raci, aby se knihovna podle nich mohla nastavit. Data, která popisují IdP, se v dané federaci mˇenízˇrídka.Spíše se pˇridávajíinformace o nových posky- tovatelích, proto je vhodné konfiguraci knihovny neprovádˇetdynamicky za bˇehu,ale poskytnout konfiguraˇcnísoubor. Z nˇejknihovna v iniciální fázi potˇrebnéinformace naˇcte. Ve skuteˇcnostinení nutné, aby pˇriinicializaci knihovny byly v konfi- guraˇcnímsouboru záznamy o všech IdP v dané federaci. Vývojáˇrimohou pˇrednastavitknihovnu pouze pro použití s vybranými IdP. Toto m ˚užemít charakter omezení výbˇeru IdP pro uživatele, pokud nemá pˇrístupke kon- figuraˇcnímusouboru knihovny. Nicménˇenalézt d ˚uvodpro takové restrik- tivní chování ve federovaném prostˇredílze tˇežko.Dalo by se naopak ˇríct, že je nežádané.

17

4 Implementace knihovny

Jednou z podmínek zadání práce je naprogramovat knihovnu v programo- vacím jazyce C. Knihovna v hojné míˇrevyužívá jeho datové typy struktura (structure) a výˇctovýtyp (enumerator). Všechny definice nových datových typ ˚upopisovaných v této kapitole jsou vytvoˇrenypomocí pˇríkazu typedef. API nabízí mechanismy pro inicializaci knihovny. Dále umožˇnujeau- tentizaci uživatele v ˚uˇcipožadované federované službˇe.Knihovna zajišt’uje správu cookies pro opˇetovnýpˇrístupk dané službˇebez nutnosti opˇetovné autorizace. API také poskytuje funkce pro ovˇeˇreníuživatelských atribut ˚u pˇrímou pˇríslušnéhoIdP, aniž by pˇritom bylo nutné kontaktovat SP. Skrze API lze pomocí knihovny vygenerovat pár RSA klíˇc˚uo pevné ve- likosti 512 bit ˚ua od vybraného SP získat certifikát veˇrejnéhoklíˇce. Prototypy funkcí dostupných pˇresAPI jsou spolu s komentáˇria defi- nicemi nových datových typ ˚uumístˇenyv souboru cfed.h, který je souˇcástí zdrojových kód ˚uknihovny na pˇriloženémCD.

4.1 Datové struktury pro uchování informací

Je nanejvýš vhodné, aby si knihovna uchovávala ˇcastopoužívaná data v ope- raˇcnípamˇeti.Napˇríklad záznamy o IdP z konfiguraˇcníhosouboru naˇcte z pevného disku do pamˇetive své iniciální fázi. Je také úˇcelnéudržovat informace o SP, ke kterým se pomocí knihovny pˇristupuje.D ˚uležitéje in- formovat volající aplikaci o úspˇechu,nebo selhání posledního pokusu o au- tentizaci nebo pˇrístupk SP. Na obrázku 4.1 je zobrazeno hierarchické uspo- ˇrádáníknihovnou definovaných typ ˚ustruktur. V nich knihovna uchovává potˇrebnéinformace. Struktury jsou navzájem provázány promˇennýmitypu ukazatel (pointer). D ˚uležitéjsou zejména struktury:

• cfed_s_context_t – Tato struktura je na vrcholu uspoˇrádání.Pomocí ukazatele conf lze pˇristoupitke struktuˇre cfed_s_idpspconf_t, kde jsou všechna d ˚uležitádata o známých IdP a SP. Za ukazatelem error se ukrývá textový ˇretˇezec(string) s popisem všech chyb, které se vy- skytly pˇribˇehuknihovny. A koneˇcnˇeresult ukazuje na strukturu cfed_s_result_t, ve které lze najít potˇrebnéinformace o posledním po- kusu o pˇrístupk SP nebo autorizaci u IdP. Témˇeˇrkaždá rutina navr- hované knihovny požaduje jako sv ˚ujprvní parametr ukazatel právˇe na popisovanou strukturu.

• cfed_s_result_t – Pokud je volána knihovní funkce, která provádí au-

19 4. IMPLEMENTACE KNIHOVNY

Obrázek 4.1: Hierarchie knihovnou definovaných struktur

tentizaci uživatele u IdP, pak prvek raw struktury ukazuje na textový ˇretˇezecobsahující html stránku, kterou zaslal IdP jako výsledek au- tentizace. Položka assertions obsahuje ˇcástodpovˇediIdP pˇriúspˇešné autentizaci, konkrétnˇehodnotu atributu SAMLResponse formuláˇreze získané html stránky. Text v assertions je zakódovaný ve formátu base64, ˇcástje navíc zašifrovaná veˇrejnýmklíˇcemSP. Cástˇ textu v as- sertions, jak název napovídá, je sada tvrzení o uživateli, mimo jiné také status probˇehléautentizace. Poslední neménˇed ˚uležitoupolož- kou popisované struktury je authn_status. Ta pomocí ˇcíselnéhodnoty vyjadˇrujestatus poslední autentizace. Hodnota 1 znaˇcíúspˇech,0 sig- nalizuje neúspˇech.

• cfed_s_idp_attr_t – V takového struktuˇreje uložena autentizaˇcníin- formace. authn_attr obsahuje hodnotu typu cfed_e_authn_attrs_t, která popisuje typ autentizaˇcníinformace. Tato hodnota m ˚užebýt kupˇrí- kladu CFED_AUTHN_ATTR_UNAME pro oznaˇceníuživatelského jmé- na. Položka value obsahuje textový ˇretˇezecse samotnou autentizaˇcní informací.

Pro úˇcelypˇredáníuživatelských autentizaˇcníchúdaj ˚ua dalších informací je definován nový typ struktury: • cfed_s_user_attrs_t – Pomocí promˇennétohoto typu jsou pˇredávány uživatelovy pˇrihlašovacíúdaje nˇekterýmknihovním funkcím. Vola-

20 4. IMPLEMENTACE KNIHOVNY

jící funkce musí ˇrádnˇevyplnit položku authn_type. V ní je pole ukaza- tel ˚una promˇennétypu cfed_e_authn_type_t, které oznaˇcují,jaký typ autentizace uživatel požaduje. V položce user_creds je uloženo pole ukazatel ˚una struktury cfed_s_idp_attr_t s pˇrihlašovacímiúdaji uži- vatele. Je nutné, aby obˇezmínˇenápole obsahovala jako poslední po- ložku ukazatel s hodnotou NULL.

4.2 Knihovna libcurl

Knihovna libcurl slouží pro URL pˇrenosna stranˇeklienta. Vychází z pro- jektu cURL autora Daniela Stenberga a je distribuována jako svobodný soft- ware. To znamená, že kdokoli m ˚užeupravit nebo šíˇritzdrojový kód. Je možné libcurl použít pro libovolné úˇcely, vˇcetnˇekomerˇcních. Knihovna je vysoce pˇrenositelná,lze ji používat na mnoha platformách jako kupˇríkladuSolaris, Linux, Windows a dalších. Projekt cURL nabízí zmínˇenouknihovnu pouze s API v jazyce C, nicménˇenˇekteréorganizace nebo samotní vývojáˇrivytvoˇrili r ˚uznéjazykové mutace (bindings), napˇrí- klad pro jazyky C++, Java nebo PHP. V implementaci knihovny, kterou se zabývá tato bakaláˇrskápráce, je libcurl využita k zajištˇeníveškeré sít’ové komunikace. Z širokého portfolia funkcionalit je d ˚uležitápˇredevšímpodpora HTTP, HTTPS a SSL certifikát˚u. Pro správu cookies nabízí libcurl vlastní nástroj (parser). Ten uchovává coo- kies v operaˇcnípamˇetia pˇripokusu o opˇetovnýpˇrístupke stejnému serveru pˇripojujek požadavku i hlaviˇckyobsahující odpovídající cookies. Pro pˇrenosposkytuje libcurl dvˇerozhraní, jsou to easy a multi. Výhodou druhého zmiˇnovanéhorozhraní je možnost nˇekolika simultánních spojení najednou. Navrhovaná knihovna používá synchronní rozhraní easy, které plnˇepostaˇcujejejím nárok ˚um.

4.3 API knihovny

Obrázek 4.2 znázorˇnujeschéma API, které knihovna nabízí. Pˇriúspˇešném provedení jakékoliv rutiny dostupné pˇresAPI je volající funkci vrácena ˇcíselnáhodnota 0. Neúspˇechje spojen s jakoukoli jinou ˇcíselnouhodno- tou. V tom pˇrípadˇeje také zanesena chybová zpráva do položky error pro- mˇennétypu cfed_s_context_t, kterou funkce pˇrijímajíprostˇrednictvím uka- zatele jako sv ˚ujprvní parametr. Dále bude tato promˇennáoznaˇcovánajako kontext.

21 4. IMPLEMENTACE KNIHOVNY

Obrázek 4.2: Schéma API

4.3.1 Inicializace knihovny

O alokaci pamˇetipro potˇrebnépromˇennéa poˇcáteˇcníinicializaci se stará rutina cfed_init(). Je to první funkce, kterou musí programátor zavolat pˇri práci s knihovnou. Uvedená funkce se také stará o naˇctení dat z konfigu- raˇcníhosouboru, která jsou následnˇeuložena do struktury cfed_s_idpconf_t. V inicializaˇcnífázi knihovna kontroluje správný formát konfiguraˇcního souboru. Je napˇríklad zkontrolováno, zda jsou položky správného typu a formátu. Pokud tomu tak není, cfed_init() ukonˇcísv ˚ujbˇeha uvolní místo po již použitých strukturách. Rutina cfed_init() mimo jiné volá funkci curl_global_init() knihovny lib- curl pro globální inicializaci nˇekterých jejích funkcionalit. Poté inicializuje rozhraní easy zmiˇnovanéknihovny a získá ukazatel pro manipulaci s kni- hovnou (handle) libcurl, který uloží do kontextu. V neposlední ˇradˇejsou nastaveny obecné volby pro pozdˇejšípˇrenosy. Je nezbytné, aby proces inicializace knihovny probˇehlúspˇešnˇe.V opaˇc- ném pˇrípadˇetotiž nejsou nastaveny struktury pro uchování dat a volání dalších rutin knihovny by mohlo zp ˚usobitneoˇcekávanéchování. Doporu- ˇcujese vždy kontrolovat návratovou hodnotu rutiny cfed_init(). Pokud není nulová, je vhodné zkontrolovat chybovou zprávu v kontextu.

22 4. IMPLEMENTACE KNIHOVNY

4.3.2 Pˇrístupk SP

Rutina cfed_whole_round() simuluje chování webového prohlížeˇcepˇripˇrí- stupu uživatele ke službˇe.Funkce nejprve zkontroluje, zda má záznam o IdP, jehož identifikátor dostane pˇrivolání jako sv ˚ujparametr. Následnˇeautoma- ticky provede všechny operace znázornˇenéobrázkem 3.1, pˇredevšímtedy autentizaci uživatele u zadaného IdP, delegaci sady tvrzení k SP a násled- nou autorizaci. Status autentizace, html stránka pˇrijatáod Idp a sada tvr- zení o uživateli jsou navíc zaneseny do pˇríslušnýchpoložek kontextu. Pokud uživatel nepˇristupujeke službˇepoprvé a nevypršela ještˇeplat- nost cookies, o které se stará knihovna libcurl, funkce cfed_whole_round() zprostˇredkujepˇrístupke službˇebez nutnosti opˇetovnéautentizace a auto- rizace

4.3.3 Autentizace uživatele bez pˇrístupuk SP

Pro kontrolu autentizaˇcníchúdaj ˚ulze využít funkci cfed_authn_only(). Tuto rutinu lze použít pouze ve federaci czTestFed, nebot’ využívá pevnˇezvole- ného SP v této federaci. Po volání této rutiny se vytvoˇríˇcasovérazítko, které spolu s informacemi o SP vytvoˇríURL. Pomocí tohoto URL je kontaktován IdP, u kterého následnˇeprobˇehnekontrola zadaných pˇrihlašovacíchinfor- mací. Pokud kontrola probˇehnev poˇrádku,pak popisovaná funkce nastaví autentizaˇcnístatus v kontextu na hodnotu 1.

4.3.4 Získání certifikátu veˇrejnéhoklíˇce

Funkce cfed_get_new_cert() ˇrešíproblém, jak od SP získat certifikát veˇrej- ného klíˇce.Tato rutina vygeneruje pár 512 bitových RSA klíˇc˚u.Poté se pˇri- pojí ke specializované službˇe,která poskytuje funkcionalitu CA. Její URL pˇredávolající funkce popisované rutinˇejako parametr. Pokud je ke službˇe pˇristupovánopoprvé, využije se funkce cfed_whole_round() pro autentizaci a autorizaci. Dále je zaslán vygenerovaný veˇrejnýklíˇck SP, který ho po- depíše a odešle zpˇet.Knihovna uloží soukromý klíˇca podepsaný veˇrejný klíˇcdo separátních soubor ˚u,jejichž názvy jsou také rutinˇepˇredánypomocí parametr ˚u.

4.3.5 Ukonˇcenípráce s knihovnou

Pokud již nejsou služby navrhované knihovny využívány, je vhodné uvol- nit alokované místo v pamˇetipo použitých strukturách. K tomu slouží funk- ce cfed_cleanup(). Ta uvolní pˇredevšímpamˇet’, která byla využívána pro ulo-

23 4. IMPLEMENTACE KNIHOVNY

žení informací o IdP a SP v kontextu pomocí položky conf. Pamˇet’ po ostat- ních položkách v kontextu je uvolnˇenataké. Nicménˇeje na aplikaci pou- žívající knihovnu, aby se postarala o uvolnˇenípamˇetipo promˇennétypu cfed_s_user_attrs_t s uživatelskými daty. Na závˇerje ukonˇcenosezení easy u knihovny libcurl.

4.4 Konfiguraˇcnísoubor

V tomto souboru jsou obsaženy vývojáˇremzadané informace o poskytova- telích identit v dané federaci. Knihovna definuje vlastní jednoduchý formát souboru, který je podobný nˇekterýmkonfiguraˇcnímsoubor ˚umznámých unixových utilit. Název a umístˇenísouboru v souborovém systému jsou de- finovány programátorem a pˇredányknihovnˇepomocí její rutiny cfed_init(). Je nutné konfiguraˇcnímusouboru knihovny pˇridˇelitvhodná oprávnˇeníke ˇctenía zápisu, aby pˇrístupk ní mˇelapouze aplikace využívající knihovnu a uživatel, pokud je to žádoucí.

4.4.1 Formát konfiguraˇcníhosouboru Každý ˇrádekkonfiguraˇcníhosouboru m ˚užezaˇcínatlibovolným poˇctembí- lých znak ˚u.Pokud je první nebílý znak na ˇrádku mˇrížka(’#’), celý ˇrádekse považuje za komentáˇr.Pokud je tento znak levá složená závorka (’{’), násle- dující ˇrádkyobsahují informace o jednom IdP. Blok informací je ukonˇcen znakem pravá složená závorka (’}’) na samostatném ˇrádku. Vyjma komentáˇreby první slovo na ˇrádkuby mˇelobýt z množiny de- finované výˇctovýmtypem cfed_e_idp_key_t. Dále bude tento výraz oznaˇco- ván jako klíˇc. Po bílých znacích musí následovat rovnítko (’=’) a dále textový ˇretˇezecuzavˇrený uvozovkami (’“’), dále odkazovaný jako hodnota. Následuje znak pro nový ˇrádek,zde oznaˇcovaný (’\n’). Rádkyˇ popisující IdP mohou tedy být následujícího tvaru: klíˇc= "hodnota" \n

Povinné jsou vždy alespoˇnnásledující klíˇces hodnotami: • CFED_INIT_NAME – Klíˇcoznaˇcujejedineˇcnouidentifikaci IdP.Hod- nota je ˇretˇezecve smyslu jazyka C. Ten odpovídá položce value znaˇcky option u daného IdP ve formuláˇri,který uživateli posílá server WAYF. • CFED_INIT_URL – Hodnota tohoto klíˇceurˇcujeURL pro pˇrímýpˇrí- stup k IdP bez pˇredchozíhokontaktování SP. Tato znaˇckam ˚užemít jako hodnotu prázdný ˇretˇezec,oznaˇcenýdvˇemauvozovkami.

24 4. IMPLEMENTACE KNIHOVNY

• CFED_INIT_AUTHN_TYPE – Tento klíˇcnese informaci o tom, jaké typy autentizace daný IdP podporuje. Hodnotou je pak položka vý- ˇctovéhotypu cfed_e_authn_type_t. Pokud IdP podporuje více než jednu metodu autentizace, pak v bloku m ˚užebýt více ˇrádk˚us popi- sovaným klíˇcem.

• CFED_INIT_IDP_TYPE – Klíˇcoznaˇcujetyp IdP podle toho, zda se jedná o bˇežnéhoposkytovatele, nebo speciálnˇeupraveného, kteˇrímají nˇekterénestandardní funkce. Upravení IdP jsou využíváni pˇrede- vším ve vývoji a testování. K tomuto klíˇcise váží hodnoty, jimiž jsou položky výˇctovéhotypu cfed_e_idp_type_t.

Následující kód demonstruje správnˇesestavený blok.

{ CFED_INIT_NAME="https://idp2.ics.muni.cz/idp/shibboleth" CFED_INIT_URL="https://idp2.ics.muni.cz/idp/Authn/UserP assword" CFED_INIT_AUTHN_TYPE="CFED_AUTHN_TYPE_FORMPASS" CFED_INIT_IDP_TYPE="CFED_IDP_TYPE_STANDARD" CFED_INIT_UNAME="j_username" CFED_INIT_PASSWORD="j_password" }

25

5 Použití navrhované knihovny

V této kapitole je pˇredstaven modelový pˇríkladpoužití navrhované kniho- vny. Pro demonstraci je využita ˇceskátestovací federace czTestFed. Ukázky kódu neošetˇrujívšechny možné chybové stavy, napˇríkladpˇripˇridˇelování pamˇetifunkcí malloc(). Cástˇ pˇredstavenéhokódu je shodná s kódem v sou- boru cfed_test.c na pˇriloženémCD. Soubor lze po pˇreloženía linkování s kni- hovnou použít pro demonstraci funkcí knihovny.

5.1 Definice struktur a inicializace knihovny

Nejprve je nutné vytvoˇritstruktury pro uchování kontextu a uživatelských autentizaˇcníchúdaj ˚u: cfed_s_context_t s_context; cfed_s_user_attrs_t user_attrs;

Následující kód vytvoˇrímísto pro tˇriukazatele na výˇctovétypy s poža- dovaným typem autentizace uživatele. user_attrs.authn_type = (cfed_e_authn_type_t**)malloc (3*sizeof(cfed_e_authn_type_t *));

Poté lze vytvoˇritdva avizované výˇctovétypy a pˇridˇelitdˇrívedefinova- ným ukazatel ˚umjejich adresy. Je nutné, aby hodnota posledního ukazatele byla NULL. cfed_e_authn_type_t authn_type_formpass = CFED_AUTHN_ TYPE_FORMPASS; user_attrs.authn_type[0] = &authn_type_formpass; cfed_e_authn_type_t authn_type_basic = CFED_AUTHN_TYPE_ BASIC; user_attrs.authn_type[1] = &authn_type_basic; user_attrs.authn_type[2] = NULL;

Ještˇezbývá vytvoˇritstruktury pro hodnoty autentizaˇcníchdat a tˇemito informacemi je inicializovat. V následujícím pˇríkladuse uživatel chce pˇri- hlašovat pomocí pˇrihlašovacíhojména a hesla. Opˇetje nutné pˇridˇelitpo- slednímu ukazateli hodnotu NULL.

27 5. POUŽITÍ NAVRHOVANÉ KNIHOVNY user_attrs.user_creds = (cfed_s_idp_attr_t**)malloc (3*sizeof(cfed_s_idp_attr_t *)); cfed_s_idp_attr_t username; username.authn_attr = CFED_AUTHN_ATTR_UNAME; username.value = „myuname“; user_attrs.user_creds[0] = &username; cfed_s_idp_attr_t password; password.authn_attr = CFED_AUTHN_ATTR_PASSWORD; password.value = „mypassword“; user_attrs.user_creds[1] = &password; user_attrs.authn_type[2] = NULL;

Nyní funkce cfed_init() provede inicializaci knihovny. Rutina má dva pa- rametry, první je adresa kontextu, druhý je jméno konfiguraˇcníhosouboru. Je nutné, aby mˇelaaplikace právo ˇctenísouboru. Je doporuˇcenokontrolovat návratovou hodnotu této funkce. if (cfed_init(&s_context, "cfed.conf")) printf("cfed_init skoncila chybou, zkontroluj chybovou zpravu \n");

5.2 Demonstrace funkcionalit knihovny

Po úspˇešnéfázi inicializace lze rutinami dostupnými pˇresAPI využít nˇekte- rých funkcionalit knihovny. Následující pˇríkladvyužívá cfed_whole_round() pro pˇrístupuživatele k vybrané federované službˇe.Jako argument funkce pˇrijímá kontext, identifikátor IdP, URL služby a nakonec strukturu s uživatel- skými autentizaˇcnímiúdaji. cfed_whole_round(&s_context, "https://idp2.ics.muni.cz/ idp/shibboleth", "https://mizar.ics.muni.cz/onlineca/ cgi-bin/login-mozilla.cgi?ca=Aleph", &user_attrs);

Pokud SP poskytuje službu certifikace veˇrejnýchklíˇc˚u,lze k jeho zís- kání použít rutinu cfed_get_new_cert(). Funkce pˇrijímájako argument kon- text, identifikátor IdP, pˇrihlašovacíúdaje a také jméno souboru pro nový certifikát veˇrejnéhoklíˇcea jméno souboru pro pˇríslušnýsoukromý klíˇc.

28 5. POUŽITÍ NAVRHOVANÉ KNIHOVNY cfed_get_new_cert(&s_context, "https://mizar.ics.mu ni.cz/onlineca/cgi-bin/login-mozilla.cgi?ca=Alep h" "https://idp2.ics.muni.cz/idp/shibboleth", &user_ attrs, "soubor_certifikat", "soubor_soukromy");

Pokud je tˇrebaovˇeˇrituživatelovy autentizaˇcníinformace pˇrímou IdP, lze využít funkci cfed_authn_only(). Funkce pˇrijímájako parametry kontext, identifikátor IdP a uživatelovy autentizaˇcníúdaje. cfed_authn_only(&s_context, "https://idp2.ics.muni.cz/ idp/shibboleth", &user_attrs);

5.3 Chybové hlášení a ukonˇcenípráce s knihovnou

V kontextu se uchovává mimo jiné textový popis všech nastalých chyb. Jeho výpis je možné provést napˇríklad: printf ("error msg:%s\n", s_context.error);

Nakonec je vhodné uvolnit pamˇet’ po použitých datových strukturách. Funkce cfed_cleanup(), která jako sv ˚ujjediný parametr pˇrijímá kontext, se postará právˇeo uvolnˇenípamˇetipo strukturách a ukazatelích v kontextu. cfed_cleanup(&s_context);

29

6 Závˇer

Úvodní ˇcástpráce vysvˇetlilapojem federace identit, standard SAML a middle- ware Shibboleth. Dále zde byly uvedeny pˇríkladynˇekterýchfederací a pro- jekt ˚uzabývajících se federovanou identitou. V následující kapitole byl ˇctenáˇrseznámen s procesy, které probíhají pˇri pˇrístupuk federacím identit. Dozvˇedˇelse také, jaké požadavky byly kla- deny na vytvoˇreníknihovny. V ˇcástizabývající se implementací knihovny byly popsány d ˚uležitéda- tové struktury definované v knihovnˇe.Také zde byla pˇredstavenaknihovna libcurl pro zajištˇenísít’ové komunikace. Poté bylo popsáno API a zp ˚usob konfigurace navržené knihovny. Modelovým použitím knihovny se zabývala kapitola pátá. Na ukázkách zdrojového kódu vysvˇetlila,jak používat funkce dostupné skrze API. V souˇcasnédobˇejsou všechny ˇcástiknihovny ve funkˇcnímstavu. Nic- ménˇese pˇredpokládá,že vývoj knihovny bude pokraˇcovat.Výsledky této práce budou využity v rámci projektu "API pro pˇrístupk federaci", který je fi- nancován Masarykovou univerzitou a Fondem rozvoje sdruženi CESNET. Cílem projektu je vytvoˇrenínástroj ˚upro pˇrístupk federované online CA a snadnému získáváni certifikát ˚u,které m ˚užebýt integrováno do existují- cích GUI a jiných aplikaci.

31

Literatura

[1] OASIS :Who We Are - Mission. [online]. c1993 [cit. 2010-12-31]. URL

[2] OpenIDFoundation : What is OpenID? [online]. c2006, [cit. 2010-11-22]. URL

[3] Shibboleth : A project of the Internet2 Middleware Initiative. [online]. c2010. [cit. 2010-12-28]. URL

[4] Ceskᡠakademická federace identit eduID.cz. [online]. poslední modifi- kace 30. dubna 2009, [cit. 2010-11-15]. URL

[5] CESNET: Federaˇcnípolitika eduID.cz. [online]. c2008 verze 1.1, [cit. 2010-12-19]. URL

[6] KOURIL,ˇ D.; KUBA, M.; OSOVSKÝ, M.; aj.: Federace identit aneb spolˇcení totožností. [online]. [cit. 2010-12-31]. Zpravodaj ÚVT MU, roˇcník18, ISSN 1212-0901. URL

[7] NOVÁK, J.: Aplikace pro sbˇermetadat ve federaci identit. Brno, 2008, bakaláˇrskápráce na Fakulté informatiky MU. URL

[8] TERENA: eduroam > about. [online]. c2009, poslední modifikace 30. záˇrí2009, [cit. 2010-12-15]. URL

33

A Obsah pˇriloženéhoCD

CD obsahuje tyto položky:

• Text této práce ve formátu pdf.

• Zdrojové kódy navržené knihovny.

• Sdílenou knihovnu.

• Aplikaci pro demonstraci funkcí knihovny.

• Zdrojový kód aplikace pro demonstraci funkcí knihovny.

• Makefile pro vytvoˇrení sdílené knihovny ze zdrojových kódu a vy- tvoˇreníaplikace pro demonstraci funkcí knihovny.

• Vzor konfiguraˇcníhosouboru knihovny.

• Soubor README s pokyny pro práci s uvedenými soubory.

Všechny soubory na CD, stejnˇejako text této práce, jsou uvolnˇenypod BSD licencí. Držitelem práv je Masarykova univerzita. Text licence je do- stupný v souboru README na pˇriloženémCD.

35