Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze

Vladimír Forejt

Sjednocená autentizace přístupu do centra softwaru DreamSpark (MSDN AA) Bakalářská práce

2012

Prohlášení Prohlašuji, že jsem bakalářskou práci na téma Sjednocená autentizace přístupu do centra softwaru DreamSpark (MSDN AA) zpracoval samostatně a použil při tom pouze zdroje, které cituji a uvádím v seznamu použité literatury. V Praze dne 21. 5. 2012

Podpis

Poděkování Chtěl bych poděkovat vedoucímu své bakalářské práce, Ing. Bc. Davidu Klimánkovi, PhD., za návrh zajímavého tématu a za to, že mi dal k dispozici přístup k systému ELMS a ke zdrojovým kódům systému rezervací, bez kterých bych práci nenapsal.

Abstrakt Ve své bakalářské práci se zabývám přístupem uživatelů do systému ELMS, který se používá pro distribuci softwaru studentům a vyučujícím ze vzdělávacích institucí, jež se zapojily do licenčního programu DreamSpark firmy Microsoft. Je předložen návrh, jak by se dal využít systém Vyšší odborné školy informačních služeb v Praze pro autentizaci jejích studentů, když se připojují do systému ELMS. Klíčová slova: DreamSpark, MSDN AA, ELMS, autentizace, LDAP, NetWare

Abstract My bachelor thesis deals with user access to the ELMS system. ELMS is used for software distribution to students and faculty of educational institutions, that are members of the Microsoft DreamSpark program. I present a proposal on how to make use of the current information system of Vyšší odborná škola informačních služeb in Prague to authenticate it’s students when when they access ELMS. Key words: DreamSpark, MSDN AA, ELMS, authentication, LDAP, NetWare

Obsah Obsah ....................................................................................................................... 6 Použité termíny a zkratky ........................................................................................ 8 1.

Úvod.............................................................................................................. 10

Teoretická část ....................................................................................................... 11 2.

3.

Microsoft DreamSpark ................................................................................. 12 2.1

DreamSpark ........................................................................................... 12

2.2

DreamSpark Premium ........................................................................... 13

2.3

Příklady akceptovatelného a neakceptovatelného použití ..................... 13

2.4

Používání studenty ................................................................................ 14

2.5

Dostupný software ................................................................................. 14

2.6

Distribuce produktů ............................................................................... 15

Systém ELMS ............................................................................................... 16 3.1

Správa katalogů produktů ...................................................................... 16

3.2

Správa uživatelů a skupin ...................................................................... 16

3.3

Způsob ověření uživatelů ...................................................................... 17

3.3.1

User Imports ..................................................................................... 18

3.3.2

Single Sign-On ................................................................................. 18

Shibboleth .................................................................................................. 19 Standard Integrated User Verification (IUV) ............................................ 21 4.

DreamSpark na VOŠIS ................................................................................. 24

5.

Systém rezervace témat absolventských prací a konzultací ......................... 27

6.

5.1

Popis funkčnosti RS .............................................................................. 27

5.2

Model databáze...................................................................................... 28

Adresářové služby......................................................................................... 30 6.1

Adresářové služby na VOŠIS ................................................................ 30

6.2

LDAP..................................................................................................... 32

6.3

LDAP a PHP ......................................................................................... 33 6

Praktická část ......................................................................................................... 36 Realizace integrované autentizace ......................................................................... 37 7.

PHP aplikace pro komunikaci s ELMS ........................................................ 37 7.1

Registrace uživatele do systému ELMS ................................................ 37

7.2

Přesměrování do systému ELMS .......................................................... 40

8.

Konfigurace systému ELMS ......................................................................... 41

9.

Integrace aplikace ......................................................................................... 43 9.1

Řešení se změnou mechanismu autentizace v RS ................................. 43

9.2

Řešení bez změny mechanismu autentizace v RS ................................. 47

9.2.1

Omezení přístupu k softwaru na oprávněné uživatele...................... 47

9.2.2

Ukončení přístupu pro ty, kdo již nejsou studenty VOŠIS .............. 49

9.2.3

Návrh integrace bez změny autentizačního mechanismu................. 50

9.3

Shrnutí: .................................................................................................. 54

9.4

Získání údajů o uživatelích z LDAP serveru ......................................... 54

10. Vlastní přínos ................................................................................................ 56 11. Závěr ............................................................................................................. 57 12. Seznam literatury .......................................................................................... 58 13. Přílohy........................................................................................................... 61 Seznam obrázků a tabulek ......................................................................... 61

7

Použité termíny a zkratky MSDN AA (Microsoft Developer Network Academic Alliance) – předchůdce licenčního programu DreamSpark Premium DreamSpark – licenční program společnosti Microsoft LDAP (Lightweight Directory Access Protocol) – protokol pro přístup k adresářovým službám VOŠIS – Vyšší odborná škola informačních služeb v Praze BP – bakalářská práce AP – absolventská práce ELMS (e-academy License Management System) – webový systém provozovaný společností e-acadamy, který je používán pro distribuci softwaru z programu DreamSpark Autentizace – proces ověření identity SSO (Single Sign-On) – mechanismus pro jednotné přihlášení User Imports – základní metoda pro autentizaci v systému ELMS IUV (Integrated User Verification) – metoda pro autentizaci do systému ELMS, která funguje na principu SSO Shibboleth – software určený pro SSO na webových stránkách Atribut – vlastnost nějakého objektu HTTP (HyperText Transfer Protocol) – protokol, který slouží pro přenos hypertextu SSL (Secure Socket Layer) – protokol pro zabezpečenou komunikaci v síti, předchůdce TLS TLS (Transport Layer Security) – protokol pro zabezpečenou komunikaci v síti URL (Uniform Resource Locator ) – řetězec znaků, který slouží k určení umístění zdroje na internetu. RS – Systém rezervace témat absolventských prací a konzultací na VOŠIS EULA (End User Licence Agreement) – licenční ujednání NetWare – síťový operační systém firmy Novell NDS (Novell Directory Services) – adresářová služba; předchůdce eDirectory 8

eDirectory - adresářová služba PHP (PHP Hypertext Preprocessor) – skriptovací jazyk používaný při tvorbě dynamických webových stránek MySQL – databázový systém GET – jedna z dotazovacích metod protokolu HTTP ER (entity-relationship) diagram – diagram, který zobrazuje entity a vztahy mezi nimi

9

1. Úvod Sjednocenou autentizaci považuji za aktuální téma. Běžně uživatelé počítačových systémů a sítí musí při svých aktivitách používat různé přístupové údaje – k osobnímu počítači, k emailové schránce, k účtu na Facebooku, k různým programům pro instant messaging, k počítačové síti v zaměstnání a k mnoha dalším službám, ke kterým se připojují a které jsou navzájem v podstatě nezávislé. Přesto lze zaznamenat snahu přístup k různým systémům nějakým způsobem sjednotit, aby uživatel mohl využít jedny přihlašovací údaje. To je pro uživatele pohodlnější, protože se tím snižuje počet uživatelských jmen a hesel, která si musí pamatovat. U systému v rámci jedné organizace to také zjednodušuje správu uživatelů. Vyšší odborná škola informačních služeb v Praze (VOŠIS) je zapojena do licenčního programu firmy Microsoft s názvem DreamSpark Premium, dříve označovaného MSDN Academic Alliance. Studenti díky tomu mohou získat software za výhodných podmínek. Stahují ho ze systému, který není provozován VOŠIS. Samozřejmě se do něj musí přihlašovat. Cílem mé práce je navrhnout, jak by se daly využít přihlašovací údaje, které studenti již na VOŠIS používají, pro přístup do systému, odkud si stahují software. Abych toho dosáhl, budu muset analyzovat informační systém na VOŠIS a také možnosti přihlašování, které nabízí systém programu DreamSpark. Téma práce je pro mě zajímavé, protože v sobě spojuje vývoj aplikace s prací s počítačovou sítí a síťovými protokoly (zejména LDAP). Budu zvažovat několik možností řešení. Jedno z nich realizuji a navrhnu pro implementaci ve stávajícím systému. Je nutné, aby také vyhovovalo licenčním podmínkám programu DreamSpark.

10

Teoretická část

11

2. Microsoft DreamSpark DreamSpark je licenční program společnosti Microsoft, který usnadňuje studentům a vzdělávacím institucím přístup k vybraným softwarovým nástrojům z jeho nabídky. Díky DreamSparku mohou při dodržení zvláštních licenčních podmínek získat software za výhodnou cenu. Dříve Microsoft nabízel podobných programů více – MSDN Academic Alliance (Developer AA), MSDN Academic Alliance Designer (Designer AA) a DreamSpark. Nyní se nabídka sjednotila pod jeden program, který je dostupný ve dvou verzích – DreamSpark a DreamSpark Premium. [1] Verze se od sebe liší nejen tím, pro koho jsou určeny a podmínkami používaní, ale i nabízeným softwarem a v neposlední řadě cenou.

2.1 DreamSpark Tento program (někdy jej budu označovat jako „základní“) umožňuje studentům a vyučujícím bezplatné stažení nástrojů Microsoft. [2] Byl spuštěn v listopadu roku 2008, od té doby však prodělal jisté změny. [3] Nejdříve se do něj mohli zapojit pouze studenti, kteří svůj statut potvrzovali platnou ISIC kartou. V roce 2011 byl podepsán dodatek „k memorandu o porozumění mezi společností Microsoft a Ministerstvem školství mládeže a tělovýchovy. Tento dodatek otevírá cestu k Dreamspark všem vyučujícím a zaměstnancům škol a školských zařízení bez ohledu na stupeň ... a to k účelům přímo souvisejícím s výukou samotnou.“ [4] Jednotlivec – student nebo vyučující – se do programu zaregistruje na stránkách http://www.dreamspark.com. Následně proběhne ověření jeho statutu. Pokud je úspěšné, může dotyčný začít bezplatně stahovat software a využívat další výhody, které program nabízí. Ověření statutu se opakuje každých 12 měsíců. Díky programu DreamSpark se studenti mohou seznámit se softwarovými nástroji Microsoftu a používat je pro osobní nekomerční účely. Členem programu DreamSpark se může stát také celá vzdělávací instituce, bez ohledu na zaměření. (V dalším textu budu školu zapojenou do programu označovat také jako „členskou instituci“.) Zakoupením předplatného na jeden nebo na tři roky získává licenci k instalaci softwarového vybavení do školních učeben a laboratoří pro účely výuky a výzkumu. [1] Podrobnosti týkající se použití jsou uvedeny v licenčním ujednání [5], několik příkladů uvádím níže. Navíc instituce získává přístup 12

k automatizovanému systému pro distribuci softwaru ELMS. Tento systém bude popsán v jedné z následujících částí.

2.2 DreamSpark Premium Pod označením Premium se skrývá licenční program dříve známý pod názvem Microsoft Developer Network Academic Alliance (MSDN AA, Developer AA). Oproti základnímu programu DreamSpark obsahuje širší nabídku produktů. Firma Microsoft o tomto programu uvádí, že „je navržen specificky pro střední a vyšší školy, katedry vysokých škol vyučující odbornou práci na počítači, akademické laboratoře a studenty oborů Počítačová věda, Technika, Informační systémy a Design. Program usnadňuje a zlevňuje získávání vývojových nástrojů, platforem a serverů společnosti Microsoft pro účely výuky, výzkumu a vývoje“. [6] Zapojit se do něj tedy mohou pouze školy nebo oddělení (např. fakulty) vyučující předměty, které odpovídají daným kritériím. Na školní počítače licenční podmínky umožňují instalovat nabízený software, ovšem stejně jako u základního DreamSpark programu pouze pro účely výuky a výzkumu. Není dovoleno software používat pro komerční účely ani pro vývoj a provozování vlastní IT infrastruktury. [7]

2.3 Příklady akceptovatelného a neakceptovatelného použití Na webových stránkách, kde jsou rozebírány podmínky využívání programu, bychom našli následující příklady přípustného a nepřípustného použití softwaru. [8] Oddělení může použít SQL Server 2008 k výuce koncepcí nebo teorie databázových struktur, správy databázových systémů a podobných kurzů týkajících se databází. Oddělení nemůže použít SQL Server 2008 k vytvoření vlastní vnitřní databáze pro účely školního informačního systému. Oddělení může používat Visual Studio k výuce koncepcí a teorií v kurzech programování. Pracovníci školního IT oddělení nemohou použít Visual Studio k úpravám školního účetního systému.

13

2.4 Používání studenty Členská instituce může dát software k dispozici svým studentům, eventuálně vyučujícím. Studenti a vyučující jsou oprávněni nainstalovat si programové vybavení i na vlastní počítač či zařízení a v souladu s podmínkami ho používat. Po ukončení studia (nebo učebních aktivit v případě vyučujících) již nový software nemohou získat, přesto je jim nadále umožněno využívat nástroje již dříve nainstalované. [1]

2.5 Dostupný software Tabulka uvádí srovnání nabídky softwarových nástrojů dostupných v rámci programů DreamSpark a DreamSpark Premium. Tabulka 2.5: Srovnání nabídky softwaru. Zdroj: [9]

DreamSpark

DreamSpark Premium

Operační systémy

●

Windows Client Windows Server

●

●

●

●

Nástroje pro vývoj a návrh Visual Studio Professional Visual Studio Premium

●

Visual Studio Ultimate

●

Expression

●

●

Windows Embedded

●

●

Aplikace Visio

●

Project

●

OneNote

●

Servery SQL Server

●

●

BizTalk Server

●

SharePoint Server

●

14

Z tabulky je vidět, že DreamSpark Premium obsahuje výrazně širší nabídku produktů. V základní verzi DreamSparku nejsou dostupné klientské operační systémy, aplikace a některé servery. (Tabulka popisuje obecné rozdělení, ne konkrétní verze produktů.)

2.6 Distribuce produktů Základní i Premium program umožňují jak stažení produktů z internetu, tak za příplatek zaslání DVD do členské instituce. [9] Elektronicky získat software je možné dvěma způsoby – ze serveru MSDN Subscriber Downloads, nebo prostřednictvím systému ELMS. V prvním případě stáhne administrátor DreamSpark programu software ze serveru MSDN Subscriber Downloads a získá na něm licenční klíče, které pak předá studentům. Protože se tato metoda příliš často nepoužívá, nebudu se jí dále věnovat. Preferovaný je druhý způsob, který celý postup zjednodušuje. [1]

15

3. Systém ELMS ELMS (e-academy License Management System) je webový systém kanadské společnosti e-academy, který je používán v programu DreamSpark. Usnadňuje správu licencí a softwaru a také distribuci uživatelům. Disponuje mechanismy, které automatizují činnosti s procesem distribuce spojené, jako je např. ověření uživatelů, souhlas s licenčními podmínkami a samotné dodání. Pro shrnutí, díky účasti v programu DreamSpark získávají uživatelé licenci. Software si stahují pomocí systému ELMS, které lze označit (podle názvu práce) jako centrum softwaru. Systém ELMS má pro uživatele podobu elektronického obchodu, ve kterém si uživatelé mohou sami vybírat a stahovat produkty. (Software je ovšem zdarma.) Dále disponuje administrátorským rozhraním, které dovoluje upravit nastavení systému. [10] K důležitým úkolům administrátora patří nastavení způsobu ověřování a správa uživatelů, uživatelských skupin a katalogů produktů.

3.1 Správa katalogů produktů V katalogu si uživatel „elektronického obchodu“ systému ELMS vybírá produkty ke stažení. Administrátor určuje, které jazykové mutace produktů budou dostupné. Výchozí katalog má nastaveno úložiště softwaru na serverech ELMS. To znamená, že uživatelé si produkty stahují přímo. Administrátor může přidat ještě tzv. campus hosted katalog. V tom případě má softwarové balíčky produktů členská instituce uložené na vlastním serveru. Nejdříve se tedy produkty uloží na server instituce a uživatelé je pak stahují z něj. Výhodou může být vyšší rychlost stahování při připojení ze školní sítě. Uživatelé se v obou případech připojují přes systém ELMS. [1] [11]

3.2 Správa uživatelů a skupin Ve zkratce popíšu správu uživatelů a skupin podle příručky Getting Started Guide For DreamSpark Program. [11] Administrátor může do systému ELMS přidat buď jednotlivého uživatele, nebo jich importovat víc najednou. Každý účet má nastaveno datum, kdy vyprší jeho platnost. Uživatelský účet patří do jedné nebo více skupin. Jako základní sou založeny skupiny pro studenty (Students), vyučující (Faculty), zaměstnance (Staff) a osoby, které 16

mají na starost instalaci v učebnách (Lab Installers). V každé z těchto skupin lze vytvořit podskupiny. Členství ve skupině je důležité při objednávce produktů, protože některé mohou být vyhrazeny pouze pro vybrané skupiny. Dále je možné nastavit najednou datum exspirace všem účtům ve skupině.

3.3 Způsob ověření uživatelů Proces ověření identity se nazývá autentizace.* Entita (uživatel, počítač...) při ní musí prokázat, že je tím, za koho se prohlašuje. [12] uvádí, že autentizaci je možné provést tehdy, když: uživatel něco zná (heslo), uživatel něco vlastní (čipová karta, certifikát), uživatel má nějaké biometrické vlastnosti (otisk prstu, struktura sítnice). Nejčastěji se používá první metoda, při které se uživatel prokazuje tajným heslem. Pro dosažení vyššího zabezpečení je ideální metody kombinovat. Aby si uživatel mohl objednat produkty z DreamSparku, musí nejprve prokázat, že k tomu má oprávnění. V systému ELMS pro DreamSpark jsou k dispozici tři metody ověření uživatelů: User Imports, Standard Integrated User Verification (IUV) a Shibboleth. Poslední dvě zmíněné fungují na principu Single Sign-On (SSO). Jako výchozí je nastavena metoda User Imports. Další lze přidat v administračním rozhraní. Metody se mohou nacházet v jednom ze tří stavů: Active, Testing a Inactive. [11] Active: Metoda se používá k ověření uživatelů, pokud je ve stavu Active. Dvě metody typu SSO nesmí být aktivní současně. Testing: Než se metoda nastaví jako aktivní, aby sloužila k ověřování uživatelů ve skutečném provozu, je ve stavu Testing. Tak se dá ve zkušebním režimu testovat, jestli ověřování funguje správně. K tomu slouží speciální adresa URL (na obrázku je v rámečku vespod). Pomocí ní se lze přihlásit do systému, ale nevytvoří se skutečné objednávky. Pouze jedna metoda typu SSO může být nastavena jako testovací.

*

Pro označení procesu ověření identity uživatele se v češtině používají jako synonyma výrazu autentizace také pojmy autentifikace, autentikace nebo ověření uživatelů. [13] Já budu v textu držet termínů autentizace a ověření uživatelů.

17

Inactive: Když je metoda neaktivní, tak se nepoužívá ani k reálnému ověřování, ani k testování. Je možné jí nastavit parametry a pak přepnout do jiného režimu.

Obrázek 3.3: Metody autentizace do ELMS. Zdroj: autor

3.3.1 User Imports User Imports představuje základní metodu autentizace. Nevyžaduje žádnou další konfiguraci. Uživatelské účty se vytvoří přímo v systému ELMS tak, že administrátor zapíše seznam nových uživatelů do textového souboru, ze kterého se pak hromadně do ELMS importují. [11] Na zadané emailové adresy uživatelům přijde odkaz, pomocí něhož se registrují a aktivují své účty. Výhodou tohoto způsobu je jeho jednoduchost – vše je od začátku připraveno, stačí jen vložit seznam uživatelů. Nevýhodou jsou větší nároky na správu – uživatelské účty je nutné vytvořit, přestože již (ve většině případů) existují v počítačovém systému členské instituce. Navíc si uživatelé musí zapamatovat další přihlašovací údaje.

3.3.2

Single Sign-On V prostředí systémů, které spolu nejsou z hlediska správy uživatelů propojeny, se

uživatelé přihlašují ke každému systému zvlášť, obvykle s použitím různých přihlašovacích údajů. Uživatelé si musí pamatovat několik uživatelských jmen a hesel, administrátoři udržují databázi uživatelů pro každý systém zvlášť a jednotlivé systémy mají vlastní způsob autentizace. [14] Příklad: Uživatel se přihlásí k operačnímu systému na svém počítači, kde má uživatelský účet. Proběhne autentizace, a pokud zadal platné přihlašovací údaje, může se systémem pracovat. Pak se rozhodne přistupovat k prostředkům na síťovém souborovém serveru. Tam musí mít vytvořený další 18

uživatelský účet. Server ho vyzve k zadání přihlašovacích údajů, a v případě, že je autentizace úspěšná, může se serverem pracovat. Mechanismus Single Sign-On umožňuje uživateli, aby se přihlásil do jednoho systému, a pak přistupoval k dalším bez nutnosti znovu zadávat přihlašovací údaje. Administrátor spravuje databázi uživatelů pouze v jednom systému. V našem případě by se tedy v systému ELMS nemusely uživatelské účty vytvářet znovu. [14] Nevýhodou je, že ve chvíli, kdy by došlo ke zkompromitování uživatelského účtu, útočník by se dostal ke všem prostředkům, ke kterým měl přístup uživatel – a těch je více, než když není metoda SSO použita. Nadto se systém, jehož prostřednictvím probíhá autentizace, stává klíčovým. V případě, že bude nedostupný, uživatelé nebudou moci přistupovat k žádným prostředkům, které na společné autentizaci závisí. [15]

Shibboleth Systém Shibboleth je software s otevřeným kódem (open source) určený pro SSO na webových stránkách v rámci organizace nebo mimo ni. [16] Shibboleth se používá v tzv. federaci neboli skupině institucí. [17] Domovská organizace i síťový zdroj jsou součástí federace, ve které se používá systém Shibboleth. Princip fungování znázorňuje obrázek 3.3.2a.*

*

Na webu organizace Switch (http://www.switch.ch/aai/demo/) je možné si pro názornost autentizaci Shibboleth vyzkoušet s použitím testovacích účtů.

19

Obrázek 3.3.2a: Princip fungování Shibboleth. Zdroj: [18], překresleno a upraveno autorem.

Pojmy: Poskytovatel identit (Identity Provider, IdP) – komponenta federace napojená na uživatelskou databázi; provádí autentizaci a poskytuje informace o uživatelích (v našem příkladu univerzita ABC). [19] Poskytovatel služeb (Service Provider, SP) – „poskytuje uživatelům federace online služby a zdroje“ (v našem příkladu www.zdroj.com). [19] Atribut – údaj přiřazený uživateli, např. členství ve skupinách nebo email. [20] WAYF (Where Are You From nebo také Discovery Service) – služba, která má za úkol zobrazit uživateli seznam organizací a přesměrovat ho na vybraného IdP nebo zpět k SP. [21] Popis kroků: 1. Uživatel XY (např. student univerzity ABC) chce přistupovat k síťové službě (zdroji) na adrese www.zdroj.com. Pokud už se uživatel XY v rámci Shibboleth autentizoval, může zdroje používat. Jinak je přesměrován na WAYF server. 2. WAYF server odpoví webovou stránkou, na které uživatel mezi nabízenými organizacemi vybere svoji domovskou, kde má uživatelský účet. 20

3. Uživatel je přesměrován zpět na zdroj. 4. Zdroj zašle požadavek na autentizaci jeho domovské organizaci. Uživatel je tedy přesměrován na stránku univerzity ABC. 5. Uživatel se přihlásí na „své“ univerzitě ABC. (Metoda autentizace závisí na rozhodnutí každé organizace.) 6. Pokud je přihlášení úspěšné, server domovské organizace to sdělí systému www.zdroj.com spolu s nezbytnými atributy uživatele. Může mezi ně patřit například informace o tom, že uživatel studuje na univerzitě ABC. Systém www.zdroj.com atributy zkontroluje a na základě nich rozhodne, zda uživateli udělí přístup. Kdyby např. byla stránka www.zdroj.com určena pouze pro skupinu Vyučující, uživatel by k ní přístup nedostal, přestože jeho autentizace na univerzitě ABC proběhla úspěšně (patří do skupiny Studenti). Z popisu vyplývá, že uživatel se přihlašuje u své domovské organizace, která o něm sděluje jen atributy nutné pro rozhodnutí SP o autorizaci. V IdP se nastaví, které atributy se budou zveřejňovat. Citlivé údaje, např. heslo, nikdy neopouští domovskou organizaci. Instituce, která chce používat Shibbolet jako metodu autentizace do systému ELMS, musí být členem federace, ve které je e-academy poskytovatelem služeb (SP). V České republice existuje Česká akademická federace identit eduID.cz, o kterou se stará organizace CESNET. V seznamu federací, ve kterých e-academy funguje jako SP, však uvedena není – to znamená, že Shibboleth zatím není možné v ČR pro autentizaci uživatelů do ELMS použít. [20] Studenti členů eduID.cz ale mohou nechat ověřit svůj statut při registraci do základního DreamSpark programu pro jednotlivé uživatele. [4]

Standard Integrated User Verification (IUV) IUV je Single Sign-On mechanismus mezi systémem členské instituce DreamSpark programu a systémem ELMS. Jak integrovaná autentizace funguje? Základní princip uvádí průvodce implementací IUV [15] v několika krocích, které jsou znázorněny také na obrázku 3.3.2b. 1. Uživatel otevře v internetovém prohlížeči stránku své školy (fakulty, katedry...). Další možností je, že si otevřel rovnou elektronický obchod systému ELMS. V takovém případě je přesměrován na stránky své instituce po kliknutí na odkaz Přihlásit (Sign in). 21

2. Domovská instituce uživatele autentizuje. Použije k tomu vlastní metodu autentizace – obvykle ho vyzve k zadání uživatelského jména a hesla, které pak ověří. 3. Uživatel na stránkách své instituce klikne na odkaz, který vede do elektronického obchodu systému ELMS. 4. Domovská instituce pošle HTTP požadavek metodou GET (přenos je šifrován pomocí SSL) na URL systému ELMS.* Jako parametry dotazu uvede informace o uživateli, které jsou systémem ELMS vyžadovány. (Parametry podrobně rozeberu později.) 5. Systém instituce dostane zpátky odpověď s kódem stavu HTTP. Ten signalizuje, jestli HTTP dotaz proběhl úspěšně. Pokud ano, je uživatel přesměrován na stránky elektronického obchodu systému ELMS a může si začít objednávat produkty.

*

HyperText Transfer Protocol (HTTP) je definovaný v RFC 2616. [22] Slouží pro přenos hypertextu (soubory ve formátu html), v dnešní době i dalších typů dokumentů. Nástin fungování: Klient (webový prohlížeč) odešle webovému serveru požadavek (HTTP request). Má na výběr z několika dotazovacích metod, z nichž nejběžnější je metoda GET. Tou si vyžádá dokument na serveru. Při použití metody GET se případný obsah formulářů nebo různé parametry předávají jako součást URL. Server v reakci odešle klientovi zpět odpověď (HTTP response). Hlavička odpovědi obsahuje tzv. kód stavu HTTP, který informuje o tom, jak byl požadavek zpracován. V těle zprávy jsou požadovaná data. HTTP komunikaci je možné zabezpečit šifrováním pomocí protokolu Secure Socket Layer (SSL), případně jeho nástupce Transport Layer Security (TLS). Zabezpečený HTTP protokol se označuje zkratkou HTTPS (HTTP Secure). URL (Uniform Resource Locator ) je řetězec znaků, který slouží k určení umístění zdroje (např. dokumentu) na internetu.

22

Obrázek 3.3.2b: Princip fungování IUV. Zdroj: [15], překresleno autorem.

23

4. DreamSpark na VOŠIS Škola se přihlásila do programu MSDN AA, nyní se tedy na ní vztahují podmínky programu DreamSpark Premium. Software z DreamSparku se využívá pro podporu výuky odborných předmětů zejména oboru Podnikové informační systémy. Jedná se například o předměty Počítačové systémy a sítě a Databázové systémy a programové vybavení, jako je Windows Server 2003 / 2008, Windows XP / Windows 7, MS SQL Server 2008 a jiné. V současnosti se studenti do programu DreamSpark registrují ve chvíli, kdy si zapíšou nějaký předmět, ve kterém se softwarové nástroje z DreamSparku využívají. Administrátor DreamSpark programu vytváří uživatele přímo v systému ELMS. Používá metodu importování uživatelů (User Imports). Postup je znázorněn na diagramu na obrázku 4 a sestává z následujících kroků: 1. Student podepíše vytištěné licenční ujednání společnosti Microsoft (EULA) a vyplní v něm své jméno, příjmení a email. 2. Student předá dokument administrátorovi DreamSpark programu. 3. Ten uloží podepsaný dokument do archivu, jak to doporučila partnerská společnost Microsoftu, u které se VOŠIS do programu registrovala. 4. Administrátor přidá studenty do seznamu nových uživatelů, který vytvořil v podobě textového souboru. 5. Importuje uživatele ze souboru do systému ELMS. Tam se jim založí účty. 6. ELMS odešle na zadané adresy studentů email. 7. Studenti na základě pokynů v emailu dokončí registraci (např. nastaví si heslo apod.).

24

Obrázek 4: Současný postup při vytváření uživatelů v ELMS. Zdroj: autor.

Z diagramu je vidět, že procesy lze rozdělit do dvou skupin – na ty, které jsou spojené s dokumentem EULA, a na ty, které souvisí s vlastním vytvořením uživatelů. Jak by bylo možné postup zjednodušit? V prvé řadě v programu DreamSpark, oproti předchozí MSDN AA, už není nutné fyzicky podepsat dokument EULA a archivovat ho. Uživatelé musí odsouhlasit licenční ujednání elektronicky při objednání softwaru v systému ELMS. To znamená, že odpadá značná část administrativy spojené s registrací studentů do programu. Co se týče vytváření uživatelů, v další části práce se budu zabývat tím, jak implementovat na VOŠIS metodu autentizace IUV (Integrated User Verification). Budu zkoumat možnosti, jak využít stávající informační systém a jeho databázi uživatelů 25

k autentizaci do systému ELMS. S použitím této metody se proces registrace obejde bez manuálního vytváření uživatelských účtů přímo v ELMS, čímž se ulehčí práce administrátorovi DreamSparku a uživatelé využijí přihlašovací údaje, které již mají. S administrátorem programu DreamSpark na VOŠIS, Ing. Bc. Davidem Klimánkem, PhD., jsem se dohodl, že k integraci použiji Systém rezervace témat absolventských prací a konzultací, který funguje na VOŠIS. Už nyní poskytuje důležité služby, je proto u něj třeba vysoké dostupnosti. V navrhovaném řešení má být zajištěn přístup k softwaru z DreamSparku všem studentům na VOŠIS.

26

5. Systém rezervace témat absolventských prací a konzultací Systém rezervace témat absolventských prací a konzultací (dále jen RS) je přístupný na adresách seb.sks.cz, sep.sks.cz a konzultace.sks.cz. Na VOŠIS funguje vedle hlavního informačního systému. V jeho popisu budu vycházet z bakalářské práce studenta, který vytvořil jeho základ [23], a z vlastního zkoumání. RS je napsán ve skriptovacím jazyce PHP a data jsou uložena v databázi MySQL. Vyučujícím slouží k vypsání konzultačních hodin a témat absolventských a bakalářských prací (dále jen AP a BP), které nabízí. Studenti Vyšší odborné školy i bakalářských oborů si mohou konzultace nebo téma zarezervovat. Studenti se do RS obvykle registrují, když se začnou zabývat výběrem tématu své absolventské práce. Systém rozlišuje 4 typy uživatelů – administrátor, učitel, student a anonymní uživatel.

5.1 Popis funkčnosti RS Administrátor má k dispozici zvláštní funkce. Může např. resetovat uživatelovo zapomenuté heslo nebo odebrat uživatele. Anonymní uživatel představuje kohokoli, kdo si zobrazí stránky RS. Takový nepřihlášený uživatel vybírá z omezené nabídky – má právo pouze zobrazit vypsané konzultace, stáhnout si formuláře, přihlásit se nebo se registrovat. Účet studenta si může zaregistrovat kdokoliv, pro založení účtu učitele musí dotyčná osoba znát heslo. Základní práva anonymního uživatele dědí typy učitel a student. Student vidí nabídku AP a BP a konzultačních hodin a může si vybrané téma či konzultaci zarezervovat u vyučujícího. Dále má v menu odkaz na změnu údajů, zobrazení zapsaných konzultací a poznámky ke své AP nebo BP. Učitel přidává, upravuje a odstraňuje témata nebo konzultace. Také vypracovává posudky AP a BP. Odkaz na stažení softwaru z programu DreamSpark bude další funkce, kterou chci přidat registrovaným uživatelům. Funkčnost systému odpovídá potřebám. Jako jeho nevýhodu však vidím to, při jeho vytváření nebyl dostatečně vzat v úvahu kontext, ve kterém měl být systém provozován, tedy počítačová síť VOŠIS. To se projevuje tím, že RS má vlastní autentizační mechanismus. Uživatelé jsou ověřování na základě uživatelského jména a 27

hesla vytvořených při registraci do RS a uložených v lokální databázi, místo toho, aby se využily přihlašovací údaje, které již studenti používají v síti VOŠIS. Nepřímo s tím souvisí zásadní vlastnost, kterou musím vzít v úvahu – v RS si může založit studentský účet kdokoli, dokonce ani nemusí mít nic společného s VOŠIS.

5.2 Model databáze Na ER diagramu jsou zvýrazněny tři tabulky, které se týkají autentizace (Admin, Student a Ucitel) a tabulka Ostatni, kterou v jednom návrhu využívám. U ostatních tabulek jsem pro přehlednost skryl všechny atributy kromě primárních klíčů (PK) a cizích klíčů (FK). Při přihlašování do systému zadá uživatel do formuláře uživatelské jméno a heslo. Tyto údaje se ověřují dotazem do databáze do tabulek Student, Ucitel a Admin. Pokud je v některé z nich nalezen odpovídající záznam, je uživatel s příslušným přidělením role a oprávnění přihlášen.

Obrázek 5.2: ER diagram databáze RS. Zdroj: [23] a Ing. Bc. David Klimánek, PhD., překresleno autorem.

28

Datový slovník: Tabulka 5.2a: Atributy tabulky Administrator. Zdroj: autor. Název

Datový typ

Popis

username

VARCHAR

Uživatelské jméno administrátora; PK

password

VARCHAR

Heslo

Tabulka 5.2b: Atributy tabulky Student. Zdroj: autor. Název

Datový typ

Popis

id_Studenta

INT

Identifikátor; PK

jmeno

VARCHAR

Jméno studenta

prijmeni

VARCHAR

Příjmení studenta

username

VARCHAR

Uživatelské jméno

heslo

VARCHAR

Heslo

typ_Studia

TINYINT

Typ studia – bakalářský/nebakalářský

email

VARCHAR

Emailová adresa studenta

Tabulka 5.2c: Atributy tabulky Ucitel. Zdroj: autor. Název

Datový typ

Popis

id_Ucitele

INT

Identifikátor; PK

jmeno

VARCHAR

Jméno učitele

prijmeni

VARCHAR

Příjmení učitele

username

VARCHAR

Uživatelské jméno

heslo

VARCHAR

Heslo

email

VARCHAR

Emailová adresa učitele

tituly_Pred

VARCHAR

Tituly před jménem

tituly_Za

VARCHAR

Tituly za jménem

Tabulka 5.2.d: Atributy tabulky Ostatni. Zdroj: autor. Název

Datový typ

Popis

typ

VARCHAR

Typ události; PK. Např: odevzdání bakalářských prací

datum

DATE

Datum události

Termín

29

6. Adresářové služby V této části se zmíním o adresářových službách, které se správou uživatelů souvisí. Pod tímto pojmem se skrývají služby v síti, které se využívají pro ukládání a vyhledávání informací (typu jméno, příjmení, email, telefon aj.) o uživatelích. Servery, které je poskytují, mohou sloužit také k ověření přístupových práv k nějakému prostředku (např. uživatelskému účtu).

6.1 Adresářové služby na VOŠIS Jádro sítě VOŠIS tvoří servery s operačním systémem NetWare 5.xx od firmy Novell. Stanice jsou typu Microsoft Windows. V systému NetWare jsou založeny účty uživatelů, kteří se na stanicích přihlašují do sítě pomocí tzv. Novell klienta. Mezi řadou služeb, které Novell NetWare může poskytovat, je adresářová služba eDirectory, jejíž předchůdce byl znám jako NDS (Novell Directory Services). Obě vycházejí ze standardu X.500 pro adresářové služby. NDS byla poprvé použita v roce 1993 v systému NetWare 4, v roce 2000 bylo v NetWare 5.1 možné zvolit eDirectory jako alternativu. V NetWare 6 a v následnickém produktu Novell Open Enterprise Server je eDirectory základním systémovým adresářem. Podporuje ovšem i další platformy. [24] Služba eDirectory je v podstatě databází, ve které jsou uloženy informace o součástech sítě – nejen o uživatelích a počítačích, ale také o tiskárnách, tiskových frontách, aplikacích, diskových svazcích aj. Prostřednictvím eDirectory je možné síťové prostředky spravovat na jednom místě, což síťovou administraci zjednodušuje. [24] Adresář eDirectory má hierarchickou (stromovou) strukturu (viz Obrázek 6.1), síťové zdroje a informace o nich jsou uloženy v podobě objektů a jejich vlastností. Objekty se dělí do dvou základních typů – container a leaf. Objekty typu container si můžeme představit jako větve stromu, které obsahují další objekty container či leaf. Umožňují strukturu logicky členit, aby byla přehlednější a umožňovala efektivnější správu. Příkladem takového objektu je Country (Země) nebo Organizational Unit (Organizační jednotka). Objekty typu leaf jsou koncové. Příkladem může být uživatel, server nebo tisková fronta. [25] K adresářové struktuře je možné nastavit přístupová práva. Uživatelé nemají mít přístup ke všem záznamům nebo jejich vlastnostem. 30

Pozice ve stromové struktuře se označuje jako kontext objektu. Definuje se odspodu od objektu nahoru ke kořenu. [25] Jednotlivé úrovně struktury se oddělují tečkou.* Příklad kontextu v síti VOŠIS: cn=Everyone.o=VSIS Zkratka CN znamená commonName a běžně se používá pro název objektu, v tomto případě Everyone. Objekt je obsažen v containeru typu Organization (organizace) s názvem VSIS. Do kontextu o=VSIS jsou zasazeny všechny uživatelské účty.

Obrázek 6.1: Ukázka části struktury adresáře v síti VOŠIS. Zdroj: autor.

*

Existuje více způsobů, jak zapsat jméno objektu. [25] Rozlišuje se relativní jméno (Relative Distinguished Name – RDN), tzn. název v rámci určitého kontextu, a úplné jméno (Complete name, Distinguished Name – DN), které za název objektu připojuje i celý jeho kontext. Jméno lze dále zapsat jako typové (typeful), přičemž se výslovně uvádí typ objektů (cn=Everyone.ou=VSIS), nebo beztypové (typeless), které vypouští označení typu objektů (Everyone.VSIS).

31

Vlastnosti objektu jsou popsány atributy. Mají formát název_atributu = hodnota. Výpis některých atributů objektu (uživatele) FOREJVLA: mail = [email protected] – emailová adresa mailForwardingAddress = [email protected] – adresa pro přeposílání fullName = Forejt Vladimir – celé jméno groupMembership = cn=Studenti.o=VSIS – členství ve skupinách groupMembership = cn=Everyone.o=VSIS – členství ve skupinách groupMembership = cn=E1.o=VSIS – členství ve skupinách Z příkladu je vidět, že atribut může mít nastaveno několik hodnot (zde případ groupMembership). Pro anonymního uživatele je z uvedených atributů viditelný pouze atribut mail. (To se samozřejmě liší v závislosti na nastavení přístupových oprávnění.) Atribut groupMembership obsahuje skupiny, jichž je objekt členem. Je z nich možné zjistit, jaký obor uživatel studuje (zde E – Podnikové informační systémy), nebo jestli je vyučující. Když je uživatel vyučující, tak je členem skupin Sbor nebo Exter. Server Novell NetWare lze nastavit, aby k jeho NDS (eDirectory) bylo možné přistupovat pomocí protokolu LDAP.

6.2 LDAP Lightweight Directory Access Protocol (LDAP) je zjednodušenou verzí protokolu Directory Access Protocol (DAP), který je definován standardem X.501. Adresářový protokol LDAP využívá transportní protokol TCP portu 389, eventuálně port 636 v případě spojení šifrovaného pomocí Secure Socket Layer (SSL). Základní operace LDAP se dají rozdělit do tří skupin [26]: Dotazovací operace: search, compare. Pomocí těchto operací je možné klást adresářovému serveru dotazy. Aktualizační operace: add, delete, modify, modify DN (rename). Těmito operacemi je možné upravovat záznamy na adresářovém serveru Autentizační a řídící operace: bind, unbind, abandon.

32

Celkový průběh dotazu do adresářového serveru může vypadat tak, jak to popisuje [26]: 1. Klient otevře TCP spojení s LDAP serverem a zašle mu příkaz bind, který slouží pro autentizaci klienta. 2. Server ověří identitu klienta (nejčastěji na základě uživatelského jména a hesla). Pokud je autentizace úspěšná, může klient zaslat další operace, jinak je spojení ukončeno. 3. Klient odešle příkaz search pro vyhledání záznamu v adresáři. 4. Server pošle zpět nalezený záznam/záznamy. 5. Server odešle návratový kód. 6. Klient požádá příkazem unbind o ukončení spojení. 7. Server spojení uzavře.

Obrázek 6.2: Průběh komunikace LDAP klienta a serveru. Zdroj: [26], překresleno autorem.

[27] připomíná, že se adresáře LDAP a NDS (eDirectory) mírně liší a také používají jinou syntaxi pro zápis jmen. V LDAP je nutné vždy specifikovat typ objektu a jednotlivé úrovně se oddělují čárkou, nikoli tečkou.

6.3 LDAP a PHP Aplikace pro integrovanou autentizaci bude součástí RS. Protože to představuje zásah do existujícího systému, musím vzít v úvahu použité technologie. RS byl vytvořen v jazyku PHP a je provozován na webovém serveru Apache. Databáze je umístěna na serveru MySQL. Z tohoto důvodu byl pro vývoj autentizační aplikace jazyk PHP v podstatě předurčen. Jaká je jeho podpora protokolu LDAP? PHP ve výchozí konfiguraci nepodporuje LDAP. Je potřeba ho s touto volbou zkompilovat a mít k dispozici LDAP knihovny. V prostředí Windows je v souboru

33

php.ini nutné povolit rozšíření php_ldap.dll a správně nastavit cesty ke knihovnám libeay32.dll a ssleay32.dll. Uvedu několik funkcí pro práci s LDAP, jak jsou popsány v PHP manuálu [28]. Zápis funkcí je ve formátu dt_návratové_hodnoty název_funkce ( dt_parametru $název_parametru) , kde dt je zkratka pro datový typ. V hranatých závorkách jsou uváděny nepovinné parametry s výchozí hodnotou. resource ldap_connect ([ string $hostname = NULL [, int $port = 389 ]] ) Funkce vytvoří spojení s LDAP serverem na zadané adrese ($hostname) a portu ($port, výchozí hodnota 389). Návratovou hodnotou je identifikátor spojení. Pro použití zabezpečeného spojení lze zadat ldaps://hostname/.

bool ldap_bind ( resource $link_identifier [, string $bind_rdn = NULL [, string $bind_password = NULL ]] ) Funkce pro spojení s LDAP adresářem. K přihlášení použije údaje $bind_rdn a $bind_password. Pokud se tyto parametry nespecifikují, naváže funkce anonymní spojení. Funkce vrací hodnotu TRUE v případě úspěšného spojení a FALSE v případě neúspěšného. $link_identifier – identifikátor spojení, který vrátila funkce ldap_connect $bind_rdn – Relativní nebo úplné (RDN/DN) jméno uživatele $bind_password – heslo uživatele

resource ldap_search ( resource $link_identifier , string $base_dn , string $filter [, array $attributes [, int $attrsonly [, int $sizelimit [, int $timelimit [, int $deref ]]]]]) Funkce prohledá LDAP adresář. Vrací identifikátor výsledku. $link_identifier – identifikátor spojení, který vrátila funkce ldap_connect $base_dn – základní DN adresáře $filter – filtr pro vyhledávání 34

$attributes – atributy, které má server vrátit (např. jen atribut „mail“) $attrsonly – příznak, jestli chci jen typy atributů, nebo i jejich hodnoty $sizelimit – omezení počtu vyhledaných záznamů $timelimit – jak dlouho se má adresář maximálně prohledávat $deref – specifikuje, jak se má zacházet s aliasy objektů

resource

ldap_first_entry

(

resource

$link_identifier

,

resource

$result_identifier ) Vrací identifikátor prvního záznamu nalezeného funkcí ldap_search. $link_identifier – identifikátor spojení, který vrátila funkce ldap_connect $result_identifier – identifikátor výsledku hledání, který vrátila funkce ldap_search

array

ldap_get_values

(

resource

$link_identifier

,

resource

$result_entry_identifier , string $attribute ) Načte do pole všechny hodnoty zadaného atributu záznamu z výsledku hledání. $link_identifier – identifikátor spojení, který vrátila funkce ldap_connect $result_entry_identifier – identifikátor záznamu (vrácený např. funkcí ldap_first_entry) $attribute – název atributu, jehož hodnoty chci získat.

35

Praktická část

36

Realizace integrované autentizace Vývoj aplikace pro integrovanou autentizaci rozdělím do tří částí: 1. Vytvoření PHP aplikace (skriptu), která bude komunikovat se systémem ELMS. 2. Konfigurace systému ELMS. 3. Integrace aplikace do RS na VOŠIS. V této části musím také vyřešit, jak ověřit, že nějaký uživatel skutečně studuje na VOŠIS a má tudíž mít povolen přístup do systému ELMS a stažení softwaru.

7. PHP aplikace pro komunikaci s ELMS Mezi autentizací uživatele a jeho vstupem do systému ELMS je nutné vykonat následující dva kroky: 1.

Registrace autentizovaného uživatele do systému ELMS

2. Přesměrování uživatele do elektronického obchodu systému ELMS Oba kroky musím ve skriptu zajistit.

7.1 Registrace uživatele do systému ELMS V této fázi domovská instituce odešle do ELMS údaje o uživateli. Následně pak zpracuje návratové kódy, které obdrží. Údaje jsou odeslány jakožto parametry HTTP metodou GET na URL adresu https://e5.onthehub.com/WebStore/Security/AuthenticateUser.aspx. Je při tom použito šifrování pomocí protokolu SSL, takže parametry nejsou zaslány jako prostý text. Seznam parametrů uvádí tabulka. Je z ní také vidět, které jsou povinné a které jsou volitelné.

37

Tabulka 7.1: Parametry HTTP požadavku. Zdroj: [15]

Název parametru

Povinný? Popis

account

ano

Číslo členské instituce programu DreamSpark, které má přiřazené v rámci ELMS

username

ano

Unikátní identifikátor uživatele. Maximální délka 100 znaků.

key

ano

Tajný klíč, který se vygeneruje administrátorském rozhraní ELMS

academic_statuses

ano

Seznam skupin, do kterých uživatel patří. Skupiny jsou oddělené čárkami.

email

ne

Emailová adresa uživatele

last_name

po

Příjmení uživatele

first_name

út

Jméno uživatele

shopper_ip

st

IP adresa počítače uživatele. Lze ji použít k ověření při přesměrování do ELMS.

Adresa

URL

včetně

parametrů

může

vypadat

v

například

takto:

https://e5.onthehub.com/WebStore/Security/AuthenticateUser.aspx?account=10000111 1&username=karelnovak&key=bda0989f&academic_statuses=students.

Použití

šifrovaného spojení je vidět z názvu protokolu https://. Další část představuje cestu ke stránce, kde se na základě dodaných parametrů vygeneruje odpověď pro server domovské instituce. Za znakem „?“ následují jednotlivé parametry ve formátu název_parametru=hodnota. Navzájem jsou oddělené znakem „&“. V PHP je více možností, jak načíst webovou stránku určenou adresou URL, například pomocí funkcí knihovny Client URL (cURL), funkce stream_get_contents anebo file_get_contents. (Poslední dvě jmenované jsou si velmi podobné.) Já jsem zvolil funkci file_get_contents. Neskýtá sice takové možnosti, jako cURL, ale použití je jednoduché a pro tento účel dostačuje. Syntaxe funkce file_get_contents je následující:

string file_get_contents ( string $filename [, bool $use_include_path = false [, resource $context [, int $offset = -1 [, int $maxlen ]]]] ) 38

Funkce tedy vrací obsah souboru jako datový typ string (textový řetězec). Její jediný povinný parametr je název souboru, který chci načíst. Ten rovněž zadávám jako typ string. Dále uvádím ukázku části kódu, která se stará o registraci autentizovaného uživatele do systému ELMS: Proměnné $site přiřadím adresu stránky systému ELMS, které budu předávat údaje o uživateli $site = "https://e5.onthehub.com/WebStore/Security/AuthenticateUser.aspx";

Do proměnné $parameters postupně načítám hodnoty jednotlivých parametrů (viz Tabulku 7.1). Ty zatím v této fázi, kdy mi jde pouze o testování spojení s ELMS, přiřazuji sám (např. $username = “josef_novak”). Až budu integrovat aplikaci do systému rezervací na VOŠIS, budu získávat skutečné údaje o uživatelích. Hodnoty proměnných $account a $key jsou pro všechny uživatele VOŠIS společné, proto je nadefinuji samostatně. Nepovinné parametry prozatím nezahrnuji. $parameters

=

$account;

$parameters

.=

$username;

$parameters

.=

$key;

$parameters .= $academic_statuses;

Proměnná $authURL obsahuje celou URL včetně parametrů. $authURL = $site . "?" . $parameters;

Funkcí file_get_contents získám obsah stránky, který systém ELMS odešle zpět v rámci HTTP odpovědi. V případě úspěchu obdržím URL adresu elektronického obchodu systému ELMS, na kterou bude uživatel přesměrován. Uložím ji do proměnné $redirectURL. $redirectURL = file_get_contents($authURL);

To, jestli byl požadavek úspěšný, nebo ne, zjistím z hlavičky HTTP odpovědi. První řádek hlavičky obsahuje (kromě verze HTTP protokolu) kód stavu HTTP. Kód 200 znamená úspěch. V průvodci implementací IUV je doporučeno, aby v aplikaci byly 39

ošetřeny chybové stavy s kódy 400 a 500. [15] Kód 500 znamená, že došlo k chybě na na straně systému ELMS. Kód 400 naznačuje chybu v aplikaci pro integrovanou autentizaci, např. v případě, že chybí jeden z povinných parametrů. Postup v závislosti na stavovém kódu znázorňuje diagram na obrázku 7.1.

Obrázek 7.1: Reakce na kódy stavu HTTP. Zdroj: [15], překresleno autorem.

Hlavička HTTP odpovědi se uloží do proměnné $http_response_header. Ta je datového typu pole. Její první prvek ($http_response_header[0]) obsahuje první řádek hlavičky s kódem stavu HTTP. Tím tedy zjístím kód a můžu příslušně upravit chování aplikce, zejména aby upozornila administrátora DreamSpark programu při chybách a aby přesměrovala uživatele v případě, že je vše v pořádku.

7.2 Přesměrování do systému ELMS Samotné přesměrování internetového prohlížeče uživatele provedu funkcí header na adresu, kterou jsem získal z odpovědi systému ELMS a která je uložena v proměnné $redirectURL. header("Location: ".$redirectURL); 40

8. Konfigurace systému ELMS Aby systém ELMS umožňoval integrovanou autentizaci uživatelů, je potřeba změnit nastavení. Nejdříve se je nutné IUV přidat mezi metody autentizace, a následně nakonfigurovat její parametry. To lze v administrátorském rozhraní systému ELMS. Po přidání je metoda automaticky v testovacím režimu, díky kterému je možné ověřovat funkčnost komunikace mezi vytvářenou aplikací a systémem ELMS, aniž by to nějak ohrozilo přihlašování uživatelů. Jak je vidět z obrázku, v nastavení je k dispozici šest parametrů:

Obrázek 8: Nastavení integrované autentizace v ELMS. Zdroj: autor.

External Sign-in ULR (povinný): Adresa serveru domovské instituce, kde dojde k autentizaci uživatele. Systém ELMS na ní uživatele přesměruje, když dojde k události, která vyžaduje ověření identity, např. kliknutí na odkaz přihlášení nebo požadavek na stažení produktu. {Doplnit adresu} Key (povinný): Tajný klíč, který se používá ve fázi, kdy se posílají údaje o uživateli do systému ELMS. (Viz část Registrace uživatele do systému ELMS.) Stisknutím tlačítka se automaticky vygeneruje. Organization Account Number (povinný): Číslo instituce v rámci systému ELMS. (Viz část Registrace uživatele do systému ELMS.) 41

Verify shopper’s IP address (nepovinný): Určuje, jestli se má ověřovat IP adresa uživatele. Pokud ano, pak při autentizaci server členské instituce zaznamená IP adresu uživatele, v HTTP požadavku ji předá systému ELMS, následně je uživatel přesměrován do systému ELMS a ten ověří, jestli se jeho IP adresa nezměnila. Pokud ano, nedojde k úspěšnému přihlášení. Ve výchozím stavu je tato volba vypnuta. V aplikaci, kterou vytvářím, se nebude používat. Calling Server IP Address List (nepovinný): IP adresy serverů členské organizace, ze kterých budou odeslány HTTP žádosti ve fázi registrace autentizovaných uživatelů. Zadáním adresy se zvyšuje zabezpečení. Ve skutečném provozu doporučuji zadat IP adresu RS. IUV Administrator Email Address (povinný): Emailová adresa, na kterou budou zasílána chybová hlášení. V případě VOŠIS to bude adresa DreamSpark administrátora. Jakmile jsem nakonfiguroval IUV v systému ELMS, vyzkoušel jsem, jak probíhá komunikace se skriptem, který jsem vytvořil v předchozí části. Systém ELMS správně vrátil adresu URL a po přesměrování došlo k úspěšnému přihlášení uživatele. Základ integrované autentizace je tedy funkční.

42

9. Integrace aplikace Nyní je potřeba ještě skript začlenit do Systému rezervace témat absolventských prací a konzultací (RS). Do menu, které má k dispozici uživatel, přidám další položku „Přístup do DreamSpark“, jak je ukázáno na obrázku. V současnosti je v podmenu Ostatní jen sekce Ke stažení.

Obrázek 9: Úprava menu RS. Zdroj: autor.

Nejdřív ale připomenu skutečnosti, které při tom musím vzít v úvahu. V RS si může vytvořit uživatelský účet studenta kdokoli. To znamená, že vůbec nemusí ve skutečnosti být studentem VOŠIS. Ve chvíli, kdy některý uživatel přestane být studentem VOŠIS, měl by mu být zamezen přístup k softwaru z DreamSparku. Účet v RS není po ukončení studia nijak zablokován. Z výše uvedených bodů vyplývají dvě otázky, které je nutné vyřešit: 1. Jak zajistit, aby přístup k softwaru získali pouze ti uživatelé, kteří skutečně na VOŠIS studují? 2. Jak zamezit v přístupu těm uživatelům, kteří již přestali na VOŠIS studovat? Dospěl jsem k několika možnostem řešení. Daly by se rozdělit do dvou skupin. Jedna skupina řešení předpokládá úpravu autentizačního mechanismu, u řešení ve druhé skupině je stávající mechanismus autentizace zachován.

9.1 Řešení se změnou mechanismu autentizace v RS Tento způsob by vyřešil obě nastíněné otázky, a to tím, že by uživatelé nebyli ověřováni v lokální MySQL databázi, kde mají uložené uživatelské jméno a heslo, které si vytvořili při registraci do RS, nýbrž na LDAP serveru v síti VOŠIS. Na ten se mohou přihlásit pouze studenti, učitelé a další zaměstnanci VOŠIS. Po jejich odchodu je jim účet zablokován. To znamená, že namísto registrace by se už poprvé do RS přihlásili pomocí údajů, které používají při přihlašování do sítě. Z LDAP serveru by RS získal 43

takové informace o uživateli, jako je jméno, příjmení nebo studovaný obor. RS by nebyl přístupný celému světu, jako je tomu nyní. Jeví se to jako ideální řešení, ale vzniká otázka, co s již zaregistrovanými uživateli, z nichž mnozí v systému mají informace o své BP? Jednoduchou odpověď neznám, protože se jedná o významný zásah do systému, ale možnosti jsou v podstatě dvě: 1. Vyzvat stávající uživatele, aby si změnili uživatelské jméno na to, které používají v síti VOŠIS. Výzva by se objevila po pokusu o přihlášení, případně by ho upravil administrátor DreamSparku přímo v databázi. V prvním případě by uživatelé byli zmateni novým oznámením. Ve druhém by navíc měl mnoho práce administrátor. 2. Nové uživatele ověřovat na LDAP serveru, stávající v lokální databázi jako doposud; pouze kdyby chtěli přistupovat do DreamSparku, došlo by k jejich autentizaci na LDAP. Jak ale odlišit ty, kteří se registrovali dříve, od těch, co se přihlašují pomocí LDAP? Návrhuji následující postup (diagram je na Obrázku 9.1): Uživatel se přihlásí zadáním svého uživatelského jména a hesla (jako doposud). Zadané údaje se vyhledají v lokální databázi v tabulkách Student, Učitel a Admin. (Pro všechny existuje jeden formulář, ale údaje jsou ve třech tabulkách podle typu uživatelského účtu.) Pokud je záznam nalezen (což znamená, že se již uživatel do RS někdy v minulosti přihlašoval), ověří se, jestli v poli „heslo“ má speciální sekvenci. Ta by byla podle tohoto návrhu vložena do pole „heslo“ uživatelům, kteří se v RS neregistrovali, ale autentizují se „novým způsobem“ pomocí LDAP. Její délka by byla 40 znaků. Tím se odliší od uživatelů, kteří si vytvářeli účet registrací do RS. (Je pravda, že teoreticky by si uživatel mohl zvolit stejné heslo jako tajná speciální sekvence, ale pravděpodobnost u tak dlouhého řetězce je zanedbatelná.) Pokud je v poli „heslo“ speciální řetězec, ověří se uživatelské jméno a heslo na LDAP serveru. V opačném případě se ověří v lokální databázi. Pokud uživatel nebyl v lokální databázi nalezen, znamená to, že se jedná o nového uživatele. Jeho přihlašovací údaje se ověří na LDAP serveru a načtou se informace o něm.

44

Pokud je přihlášení úspěšné, vytvoří se záznam o uživateli v lokální databázi, do které se uloží získané informace. Pokud je uživatel zařazen do skupiny „sbor“, znamená to, že se jedná o vyučujícího a záznam se uloží do tabulky Učitel. Jinak se uloží do tabulky Student. Heslo uživatele se neukládá, ale místo toho se vloží speciální sekvence znaků, které označují, že má při přihlášení dojít k ověření uživatelského jména a hesla na LDAP serveru. Výhodou tohoto řešení by byla zlepšená integrace RS do sítě VOŠIS. Uživatelé by nemuseli mít dvoje přihlašovací údaje, přihlásili by se bez registrace. Nebyly by nutné žádné změny v databázi RS. Navíc by byl připraven základ pro další rozšíření systému – např. pokud by bylo v nějaké funkci potřeba zjistit studovaný obor, bude k tomu možné využít propojení s LDAP. Nevýhodou je, že se nejedná o prosté přidání funkcionality, ale změnu způsobu autentizace, což ovlivňuje klíčové funkce RS. Vyžadovalo by tedy důkladné testování. Samozřejmě přihlášení do RS by nebylo možné, kdyby došlo k výpadku LDAP na NetWare serverech, serverů samotných nebo nějakého síťového prvku (např. switche). Ale na jejich fungování závisí i intranetová aplikace a prakticky celá síť VOŠIS; nedá se říci, že by role RS byla kritičtější. Pokud je spolehlivost NetWare serverů dostatečná pro tyto služby, jsem přesvědčen, že je dostatečná i pro autentizaci do RS.

45

Obrázek 9.1: Návrh řešení se změnou autentizace RS. Zdroj: autor.

46

9.2 Řešení bez změny mechanismu autentizace v RS Další skupina návrhů ponechává stávající mechanismus autentizace do RS. Uživatelé tedy používají dvoje přihlašovací údaje – jedny pro přístup do sítě VOŠIS, intranetu apod., a druhé k přihlášení do RS. Musí být ovšem splněny stanovené požadavky, tj. 1. pouze studenti VOŠIS mají mít přístup k softwaru z DreamSparku a 2. pokud přestanou být studenti, je potřeba jim přístup zamezit. Následují body Omezení přístupu k softwaru z DreamSparku na autorizované uživatele a Ukončení přístupu pro ty, kdo již nejsou studenty VOŠIS, ve kterých rozděluji návrhy do dvou dílčích fází řešení.

9.2.1 Omezení přístupu k softwaru na oprávněné uživatele Cílem v této části je najít způsob, jak ověřit, zda určitý uživatel zaregistrovaný v RS studuje na VOŠIS, při zachování stávajícího mechanismu autentizace do RS. Uživatel se přihlásí do RS pomocí uživatelského jména a hesla, které používal doposud. Po přihlášení se mu zobrazí mezi stávajícími položkami menu také odkaz, na který klikne, když bude chtít stáhnout software z DreamSparku. Dále nastíním několik možností ověření. Uživatel klikne na odkaz, načež se vygeneruje email pro administrátora DreamSparku. Pokud by administrátor chtěl uživateli povolit přístup, klikl by na odkaz v těle emailu. Odkaz by vedl na skript v RS, který by na tomto základě udělil uživateli autorizaci. o Tento způsob je jednoduchý a dává administrátorovi možnost přesně rozhodnout, kteří uživatelé dostanou přístupové právo. Na druhou stranu by s tím měl jen o něco méně práce než teď, kdy uživatele přidává metodou User imports. Navíc by musel mít přehled o tom, kteří studenti jsou v jakých oborech, což by v praxi bylo velmi obtížné. Další varianta je podobná té předchozí. Poté, co uživatel klikne na odkaz, by se ale jeho jméno zařadilo do tabulky „čekajících“ uživatelů. Administrátor by si mohl např. jednou týdně nechat celou tabulku zobrazit a u každého uživatele žádost povolit, nebo zamítnout. Tak by vyřešil více uživatelů najednou.

47

o Oproti potvrzení přes odkaz v emailu je tento způsob pro administrátora o něco málo jednodušší. Přesto stále není plně automatizovaný a nevýhody uvedené u předchozího bodu zůstávají. Třetí způsob vychází ze skutečnosti, že každý student má svojí školní emailovou adresu ve formátu [email protected]. Username je uživatelské jméno, přes které se přihlašuje do počítačové sítě VOŠIS, intranetu, na FTP apod. Postup řešení je následující: Uživatel při registraci účtu v RS zadá svoje uživatelské jméno do sítě VOŠIS. Systém vygeneruje zprávu, kterou mu zašle na školní email. Uživatel klikne na odkaz v emailu vedoucí do RS, čímž potvrdí, že skutečně je studentem VOŠIS. RS povolí registraci nového uživatele. Zamezilo by se tím možné situaci, kdy si v RS vytvoří účet člověk, který není studentem VOŠIS. o Toto řešení je z hlediska DreamSpark administrátora v podstatě automatizované, i když víc kroků vyžaduje zase od uživatele, který musí potvrdit odkaz v obdrženém emailu. Další nevýhodou je, že mnozí uživatelé školní mail vůbec nepoužívají, ani ho nemají přesměrovaný na svůj soukromý. Čtvrtý způsob využívá školní server, na kterém běží systém Novell Netware. Účty na něm mají studenti od chvíle, kdy začnou navštěvovat VOŠIS. Údaje o uživatelích z něj lze získat přes protokol LDAP. Nástin fungování: Uživatel zadá do formuláře v RS své uživatelské jméno a heslo do sítě VOŠIS. Skript se pokusí pomocí zadaných údajů připojit k LDAP na NetWare serveru. Pokud je pokus úspěšný, znamená to, že uživatel má platný účet v síti VOŠIS a může mu tedy být povolen přístupu k softwaru z DreamSparku. Při tom se nezasahuje do mechanismu autentizace RS. Na LDAP serveru se uživatelé ověřují, pouze pokud chtějí přistupovat k softwaru z DreamSparku. o Tato varianta představuje automatizované řešení. Nevyužívá žádné pochybné zdroje informací, ale přímo školní LDAP server. Od studenta vyžaduje pouze zadání uživatelského jména a hesla do sítě VOŠIS. Nevýhodou je to, že se aplikace pro integrovanou autentizaci stává závislou na fungování dalšího systému. Přesto se tento způsob (mezi alternativami

bez

zásahu

do

autentizačního

mechanismu

RS)

z uvedených důvodů jeví jako nejlepší

48

9.2.2 Ukončení přístupu pro ty, kdo již nejsou studenty VOŠIS Uživatelům, kteří ukončili studium, ať už řádně závěrečnou zkouškou, nebo předčasně, již nesmí být podle licenčních podmínek programu DreamSpark povolen přístup k softwaru. Je opět několik způsobů, jak to zajistit, přičemž současný mechanismus autentizace do RS zůstane zachován. Počítám s použitím LDAP serveru, jak to popisuji v předchozí části. Zároveň by nebylo efektivní, kdyby se uživatelské jméno a heslo do sítě VOŠIS muselo ověřovat při každém stahování software z DreamSparku. Uživatel by se v podstatě musel přihlašovat dvakrát – do RS a pak do sítě VOŠIS. Navrhovaná řešení: Studijní oddělení informuje, když některý student ukončí studium. Datum ukončení studia je přesné, na druhou stranu je toto řešení velmi administrativně náročné. Po úspěšném ověření přes LDAP nastavit v RS datum exspirace přístupu do DreamSparku. Ve chvíli, kdy vyprší platnost, uživatel se bude muset znovu prokázat svými přihlašovacími údaji do školní sítě. Pokud by přestal na VOŠIS studovat, jeho účet v síti by byl deaktivován a ověření by tudíž nebylo úspěšné. o Nevýhody: Pokud by se nastavila krátká doba exspirace, např. jeden měsíc, uživatel by byl poměrně často obtěžován nutností znovu ověřovat svůj statut. Pokud by byla dlouhá, např. půl roku nebo rok, mohla by uplynout dlouhá doba mezi dnem, kdy uživatel přestane být studentem a dne, kdy je mu ukončen přístup do DreamSparku. Uložit do RS data začátku a konce semestru. Protože studenti končí studium v průběhu semestru jen velmi výjimečně, ověřování jejich statutu se ověří pouze jednou na začátku semestru. Pak se v RS nastaví, že již ověření proběhlo a k dalšímu ověření dojde opět až v novém semestru. Administrátor na začátku školního roku uloží do databáze RS do tabulky Ostatni datum začátku zimního semestru, letního semestru a konec letního semestru. Tento způsob je uspokojivým kompromisem mezi přesností informace o statutu, administrativní náročností a pohodlností pro uživatele. Proto jej z návrhů, které nepočítají se změnou autentizačního mechanismu RS, hodnotím jako nejlepší.

49

9.2.3 Návrh integrace bez změny autentizačního mechanismu Po kliknutí na tlačítko (odkaz) Přístup do DreamSpark v menu RS aplikace ověří, jestli je uživatel oprávněn ke vstupu. Pokud ano, dojde k jeho přesměrování do elektronického obchodu systému ELMS. Pokud ne, zobrazí se hlášení, že přístup je zamítnut. Postup znázorňuje diagram:

Obrázek 9.2.3a: Návrh řešení bez změny autentizace RS – zjednodušený diagram. Zdroj: autor.

Pro účely ověření oprávnění ke vstupu vytvořím v databázi novou tabulku s názvem DreamsparkPristup. Bude v relaci s tabulkou Student s kardinalitou vztahu 1:1. To znamená, že záznam v tabulce DreamsparkPristup (pokud existuje), bude odpovídat právě jednomu záznamu v tabulce Student. Vztah 1:1 je poměrně neobvyklý, spíše jsou všechny sloupce v jedné tabulce. V tomto případě ale volím tabulky dvě proto, že se jedná o specifické údaje o uživatelích, které přímo nesouvisí s účelem tabulky Student. Navíc se týkají pouze studentů oboru Podnikové informační systémy; u ostatních studentů by tato část tabulky byla prázdná. Dále uvádím návrh tabulky:

50

Obrázek 9.2.3b: Návrh tabulky DreamsparkPristup. Zdroj:autor

Datový slovník tabulky DreamsparkPristup: Tabulka 9.2.3: Atributy tabulky DreamsparkPristup. Zdroj: autor.

Jméno atributu

Typ

Popis

vosis_loginname

VARCHAR

Uživatelské jméno do sítě VOŠIS

autorizovan

TINYINT

Příznak,

jestli

je

uživatel

autorizován k přístupu k softwaru z DreamSpark datum_overeni

DATE

Datum posledního ověření uživatele přes LDAP server v síti VOŠIS

zablokovan

TINYINT

Příznak zablokování přístupu, např. administrátorem

id_Studenta

INT

Cizí klíč tabulky Student, který je zároveň primární klíč tabulky DreamsparkPristup.

Ověření oprávnění ke vstupu by probíhalo v několika krocích, které jsou vidět z diagramu na Obrázku 9.2.3c. Nejdříve se zjišťuje, jestli má uživatel záznam v tabulce DreamsparkPristup. Pokud ne, záznam se vytvoří a na LDAP serveru se pomocí přihlašovacího jména a hesla do sítě VOŠIS ověří, jestli se jedná o studenta oboru PIS. Na základě toho je mu přidělen nebo zamítnut přístup do systému ELMS. Pokud záznam v tabulce DreamsparkPristup existuje, znamená to, že již někdy proběhlo ověření uživatele. Po kontrole, jestli nemá zablokovaný přístup (v tom případě se mu zobrazí hlášení o zamítnutí), se testuje, zda mu byl přístup přidělen. (Tzn. atribut „autorizovan“ v tabulce DreamsparkPristup má hodnotu 1.) Pokud mu přístup udělen 51

nebyl, dojde k ověření jeho údajů na LDAP serveru. Tato situace může nastat např. při chybném zadání hesla. V případě, že uživatel již byl k přístupu autorizován, se pomocí atributu „datum overeni“ kontroluje, jestli autorizace proběhla v aktuálním semestru. Jestliže ano, nic již uživateli nebrání v přístupu. Pokud ne, musí ověření proběhnout znovu. Aktivita „Aktualizovat tabulku DreamsparkPristup“ sestává z nastavení atributu „autorizovan“, aktuálního data v atributu „datum_overeni“ a případně ještě pole vosis_loginname u příslušného záznamu. Je vidět, že řešení zachovávající současnou podobu způsobu autentizace je poněkud komplikované. Výhodou ovšem je, že se do RS pouze přidá další funkcionalita (odkaz na DreamSpark), která nijak neovlivní jeho ostatní části.

52

Obrázek 9.2.3c: Návrh ověření oprávnění vstupu do ELMS bez změny autentizačního mechanismu RS. Zdroj: autor.

53

9.3 Shrnutí: Řešení se změnou autentizačního mechanismu (využití LDAP) Výhody: lepší integrace do sítě; stejné přístupové údaje jako do sítě; není potřeba registrace; nemění se databáze; efektivnější vzhledem k budoucím možným úpravám; přesné určení statutu studenta Nevýhody: výrazný zásah do systému – většina funkcí závisí na autentizaci; autentizace závislá na fungování LDAP serveru Řešení bez úpravy autentizačního mechanismu (využitím LDAP) Výhody: přidání funkce Přístup do DreamSparku nemá vliv na další části RS; Nevýhody: komplikovanost; určení statutu studenta ne zcela přesné (avšak dostačující); autentizace závislá na fungování LDAP serveru Obě řešení mají podobný základ – autentizace na LDAP serveru. První varianta však implementuje tuto autentizaci přímo v základu RS. Tím se RS lépe začlení mezi zbývající součásti sítě VOŠIS. Navíc je to „čistší“ řešení, které dává prostor i pro budoucí rozšíření. Proto realizuji tuto variantu – upravím mechanismus autentizace RS, aby používal LDAP server.

9.4 Získání údajů o uživatelích z LDAP serveru V této části předvedu ukázku, jak lze pomocí PHP získávat informace o uživateli z LDAP serveru. Kód je napsán pro část aplikace, která do MySQL uloží nového uživatele, který se ověřil přes LDAP. Pro tento účel je potřeba získat jméno, příjmení, emailovou adresu a informaci o tom, jestli studuje bakalářský nebo nebakalářský obor. Nejdříve se aplikace připojí k serveru funkcí ldap_connect, poté naváže spojení funkcí ldap_bind, prohledá adresář funkcí ldap_search a obdrží první nalezenou položku díky použití ldap_first_entry. Funkcí ldap_get_values se získávají hodnoty atributů. Proměnná $ldapconn obsahuje identifikátor spojení a $entry odkaz na nalezený záznam. "fullName", "groupMembership" a "mail" jsou názvy atributů uživatelů v prostředí adresáře NetWare pro celé jméno, členství ve skupinách a email. Tyto atributy se v následujících příkazech načtou do příslušných proměnných.

54

$full_name_values = ldap_get_values($ldapconn, $entry, "fullName"); $group_membership_values = ldap_get_values($ldapconn,$entry, "groupMembership"); $mail_values = ldap_get_values($ldapconn, $entry, "mail");

Z celého jména se získá jméno a příjmení rozdělením řetězce (který je ve formátu „Prijmeni Jmeno“) podle mezery uprostřed funkcí explode. Té se jako parametr předá první hodnota atributu „fullName“ záznamu, který se načetl z LDAP. Do proměnné typu pole $full_name se uloží oba řetězce, které se pak přiřadí příslušným proměnným $prijmeni a $jmeno. $full_name = explode(" ", $full_name_values[0]); $prijmeni = $full_name[0]; $jmeno = $full_name[1];

Zjištění emailové adresy je jednoduché – je to první prvek pole hodnot, získaných z atributu „mail“. $mail = $mail_values[0];

Obdobně (i když o něco komplikovaněji) se zjistí to, jestli uživatel je student bakalářského nebo nebakalářského programu, případně jestli je vyučující. Využije se k tomu znalost skupin, do kterých patří. Získané hodnoty se uloží do MySQL databáze a uživatel tím může používat funkce RS pro registrované, i když samotné ověření přihlašovacích údajů probíhá na LDAP serveru.

55

10. Vlastní přínos Téma mi zpočátku připadalo poměrně snadné. Do RS na VOŠIS přidat odkaz do centra pro stažení softwaru. Postup integrované autentizace do systému ELMS je navíc dobře zdokumentovaný. Postupně jsem ale narážel na problémy, se kterými jsem se musel vypořádat. První bylo, když jsem si uvědomil, že není nijak ošetřena registrace uživatelů do RS. Licenční podmínky programu DreamSpark umožňují poskytovat software pouze studentům VOŠIS. Musel jsem tedy najít způsob, jak ověřit, že uživatel RS je skutečně studentem VOŠIS. Nejdříve jsem to chtěl řešit na úrovni kliknutí na odkaz „Přístup do DreamSparku“ způsoby, které by vyžadovaly velkou aktivitu uživatelů, např. potvrzení emailem. Pak jsem si ale uvědomil, že do intranetové aplikace na VOŠIS se lze přihlásit s použitím uživatelského jména a hesla do sítě. Zjistil jsem, že tedy musí existovat způsob, jak se z webové aplikace připojit k serveru Novell NetWare. Objevil jsem PHP knihovnu pro komunikaci s LDAP. Odtud již chyběl jen krůček k úvaze, jestli by nebylo lepší ověřovat uživatele pomocí LDAP rovnou při registraci. Vlastně by se ani registrovat nemuseli, protože údaje o nich by se získaly z LDAP a oni by je jen v případě potřeby upravili. Jako „vedlejší produkt“ by se tedy RS integroval do sítě VOŠIS, a nemusely by se v jedné síti používat dvoje přihlašovací údaje. Další překážky vyvstaly při realizaci. Zjistil jsem, že testovací provoz autentizační metody IUV systému ELMS se nechová stejně, jako když je metoda aktivní. Ve stavu Testing je nutné nejprve otevřít testovací URL adresu ELMS, pak se ve stejném okně prohlížeče přihlásit do RS a pak teprve je uživatel úspěšně přesměrován do centra softwaru. Když je metoda IUV nastavena jako aktivní, uživatel se může rovnou přihlásit do RS, kliknout na odkaz a je bez problémů přesměrován. Navíc jsem si uvědomil, že budou nutné větší úpravy RS. Pro studenty, kteří se neregistrovali, ale přihlašují s využitím LDAP, by například neměly být dostupné takové funkce jako změna hesla nebo resetování hesla přes email. Ti, kdo se do RS registrovali, k těmto funkcím naopak přístup mít budou. U studentů jsem již v RS základní funkce upravil, ale u učitelů jsem to nestihl. Navíc – protože změny jsou rozsáhlejší, než jsem původně předpokládal – bude nutné důkladné testování, aby se ověřilo, že všechno funguje tak, jak je požadováno. 56

11. Závěr Cílem mé práce bylo navrhnout řešení pro sjednocenou autentizaci mezi systémem ELMS používaným pro distribuci softwaru z programu DreamSpark a informačním systémem na VOŠIS. Jednotná autentizace je jednodušší jak pro uživatele, tak i pro administrátora programu, který uživatelské účty spravuje. V teoretické části nejdříve popisuji licenční program Microsoft DreamSpark. Ten v nedávné době prošel zásadními změnami. Sjednotil se s programem MSDN Academic Alliance, takže v současnosti existuje ve dvou verzích: DreamSpark a DreamSpark Premium. Pro distribuci softwaru zpřístupněného pod licencí DreamSpark se používá webový systém ELMS. Z něj si uživatelé mohou programové nástroje stahovat. V práci popisuji, jaká nastavení se dají v systému provést, se zaměřením na metody autentizace. Z části, kde zkoumám DreamSpark na VOŠIS vyplývá, že není nutné podepisovat licenční ujednání, protože licenci uživatel musí odsouhlasit při stažení softwaru. Proces se tím zjednoduší. V závěru teoretické části analyzuji současné systémy na VOŠIS – zejména RS, do kterého jsem měl aplikaci pro jednotnou autentizaci integrovat. Z tohoto oddílu vyplynulo zjištění, že bude nutné ověřovat statut studentů u uživatelů RS. Také stručně popisuji adresářovou strukturu na serverech Novell Netware v síti VOŠIS a to, jak je možné k nim přistupovat pomocí skriptovacího jazyka PHP přes protokol LDAP. Samotnou realizaci, kterou popisuji v praktické části, jsem rozdělil do tří fází – vytvoření skriptu pro komunikaci se systémem ELMS, konfigurace ELMS, aby podporoval požadovanou autentizační metodu, a nakonec integraci skriptu do prostředí RS. V rámci poslední fáze jsem také chtěl upravit RS, aby autentizace uživatelů probíhala na NetWare serveru pomocí protokolu LDAP. V jazyce PHP jsem RS (resp. jeho testovací verzi, jež jsem měl k dispozici) upravil, takže se z něj lze přihlásit do systému ELMS a stáhnout software. Také je možné se do RS přihlásit pomocí přihlašovacích údajů do sítě VOŠIS, ale tato funkce je zatím k dispozici pouze pro studenty. Pro vyučující jsem ji zatím vzhledem k rozsahu nutných úprav nezahrnul. Pokud by se navrhované řešení plně implementovalo, nejenže by se studentům zjednodušil přístup k softwaru z programu DreamSpark, ale také by bylo možné využít přihlašovací údaje do sítě i k přihlášení se do RS. 57

12. Seznam literatury [1] DreamSpark Support. MICROSOFT. Microsoft DreamSpark [online]. ©2012 [cit. 2012-04-09]. Dostupné z: https://www.dreamspark.com/Support/Default.aspx [2] DreamSpark: Nejčastější dotazy studentů. MICROSOFT. Microsoft MSDN [online]. ©2012 [cit. 2012-04-08]. Dostupné z: http://msdn.microsoft.com/cs-cz/ee460830.aspx [3] Microsoft přináší studentům profesionální software zcela zdarma. MICROSOFT. Microsoft: Tiskové centrum [online]. 26. 11. 2008 [cit. 2012-04-09]. Dostupné z: http://www.microsoft.com/cze/presspass/msg/20081126_news1.mspx [4] Microsoft Dreamspark – pro všechny studenty a učitele v ČR. In: Czech MSDN Blog [online]. 17. 5. 2011 [cit. 2012-04-09]. Dostupné z: http://blogs.msdn.com/b/vyvojari/archive/2011/05/17/microsoft-dreamspark-provsechny-studenty-a-ucitele-v-cr.aspx [5] SUBSCRIPTION AGREEMENT - MICROSOFT DREAMSPARK. Microsoft DreamSpark [online]. ©2012 [cit. 2012-04-09]. Dostupné z: https://www.dreamspark.com/licensing/Basic-EULA.aspx [6 ] DreamSpark Premium. MICROSOFT. Microsoft MSDN [online]. ©2012 [cit. 201204-09]. Dostupné z: http://msdn.microsoft.com/cs-cz/ff898347 [7] SUBSCRIPTION AGREEMENT - MICROSOFT DREAMSPARK PREMIUM. Microsoft DreamSpark [online]. ©2012 [cit. 2012-04-09]. Dostupné z: https://www.dreamspark.com/licensing/Premium-EULA.aspx [8] Podmínky využívání programu MSDN® Academic Alliance. MICROSOFT. Microsoft: Školství a vzdělávání [online]. ©2012 [cit. 2012-04-09]. Dostupné z: http://www.microsoft.com/cze/education/licence/msdn_academic_alliance/podminky.m spx [9] Compare Subscriptions. MICROSOFT. Microsoft DreamSpark [online]. ©2012 [cit. 2012-04-09]. Dostupné z: https://www.dreamspark.com/Institution/CompareSubscription.aspx [10] ELMS for DreamSpark. E-ACADEMY, Inc. e-academy [online]. ©2012 [cit. 2012-04-12]. Dostupné z: http://e-academy.com/dreamspark.cfm

58

[11] E-ACADEMY, Inc. Getting Started Guide For DreamSpark Program. Version 2.0. 2012-01-15 [cit. 2012-04-12]. Dostupné z: http://www.eacademy.com/dreamspark/DreamSparkGettingStartedGuide_en.pdf [12] DOSTÁLEK, Libor. Velký průvodce protokoly TCP/IP: bezpečnost. 2. aktualiz. vyd. Praha: Computer Press, 2003, xvi, 571 s. ISBN 80-722-6849-X. [13] BEHÚN, Dalibor. Hříchy pro šíleného korektora: Autentizace, autentikace nebo autentifikace?. Interval.cz [online]. 25. 11. 2004 [cit. 2012-05-10]. Dostupné z: http://interval.cz/clanky/hrichy-pro-sileneho-korektora-autentizace-autentikace-neboautentifikace/ [14] Introduction to Single Sign-On. THE OPEN GROUP. The Open Group [online]. ©1995-2010 [cit. 2012-04-13]. Dostupné z: http://www.opengroup.org/security/sso/sso_intro.htm [15] E-ACADEMY, Inc. Integrated User Verification: Customer Implementation Guide. Version 2.4. 2012-01-31 [cit. 2012-04-13]. Dostupné z: ftp://ftp.eacademy.com/support/outgoing/ELMS_Integrated_User_Verification_Customer_Imple mentation_Guide_en.pdf [16] INTERNET2. Shibboleth [online]. ©2012 [cit. 2012-04-14]. Dostupné z: http://shibboleth.internet2.edu/ [17] Federations and Shibboleth. INTERNET2. Internet2 [online]. ©1996-2010 [cit. 2012-04-14]. Dostupné z: http://middleware.internet2.edu/foo/docs/internet2-mace-foofederations-and-shibboleth-200306.html [18] Authentication - simple demo. SWITCH. Switch: Serving Swiss Universities [online]. ©2012 [cit. 2012-04-14]. Dostupné z: http://www.switch.ch/aai/demo/2/simple.html [19] O federaci. [email protected]. EDUID.CZ. Česká akademická federace identit eduID.cz [online]. 2009-04-30 [cit. 2012-04-14]. Dostupné z: http://www.eduid.cz/wiki/eduid/index [20] E-ACADEMY, Inc. Shibboleth User Verification: Customer Implementation Guide. Version 2.1. 2012-01-31 [cit. 2012-04-13]. Dostupné z: ftp://ftp.eacademy.com/support/outgoing/ELMS_Shibboleth_User_Verification_Customer_Imple mentation_Guide_EN.pdf

59

[21] WAYF Service. Switch: Serving Swiss Universities [online]. ©2012 [cit. 2012-0414]. Dostupné z: http://www.switch.ch/aai/support/tools/wayf.html [22] Fielding, R. a kol. Hypertext Transfer Protocol -- HTTP/1.1 [RFC 2616]. The Internet Society. 1999 [cit. 2012-05-10]. Dostupné z http://www.ietf.org/rfc/rfc2616.txt [23] PETRÍK, Vladimír. Reengineering informačního systému pro tvorbu posudků bakalářských a absolventských prací. Praha, 2011. Bakalářská práce. Vysoká škola ekonomická v Praze, Fakulta informatiky a statistiky, Vyšší odborná škola informačních služeb. Dostupné z: http://info.sks.cz/www/zavprace/soubory/76520.pdf [24] PŘICHYSTAL, Oldřich. Adresářová služba Novell eDirectory. [online]. 2006 [cit. 2012-05-10]. Dostupné z: http://www.prichystal.cz/Archiv_c/NovNews/eDir_nn/edir_nn.htm [25] Novell Directory Services (NDS). [online]. 1997 [cit. 2012-05-10]. Dostupné z: http://kmdec.fjfi.cvut.cz/nds/index.html [26] BENÁK, Karel. Použití adresářových služeb v informačních systémech. Praha, 2004. Dostupné z: http://ldap.benak.net/diplom.pdf. Diplomová práce. České vysoké učení technické v Praze, Fakulta stavební, Katedra systémového inženýrství. Vedoucí práce doc. RNDr. Jiří Demel, CSc. [27] PŘICHYSTAL, Oldřich. Cizím jazykům se učí i NDSka. [online]. 2000 [cit. 2012-0510]. Dostupné z: http://www.prichystal.cz/Archiv_c/Connect/Ldap_cp/ldap_cp.htm [28] LDAP Functions [online]. 2012-05-18 [cit. 2012-05-10]. Dostupné z: http://php.net/manual/en/ref.ldap.php

60

13. Přílohy Seznam obrázků a tabulek Tabulka 2.5: Srovnání nabídky softwaru. Obrázek 3.3: Metody autentizace do ELMS. Obrázek 3.3.2a: Princip fungování Shibboleth. Obrázek 3.3.2b: Princip fungování IUV. Obrázek 4: Současný postup při vytváření uživatelů v ELMS. Obrázek 5.2: ER diagram databáze RS. Tabulka 5.2a: Atributy tabulky Administrator. Tabulka 5.2b: Atributy tabulky Student. Tabulka 5.2c: Atributy tabulky Ucitel. Tabulka 5.2.d: Atributy tabulky Ostatni. Obrázek 6.1: Ukázka části struktury adresáře v síti VOŠIS. Obrázek 6.2: Průběh komunikace LDAP klienta a serveru. Tabulka 7.1: Parametry HTTP požadavku. Obrázek 7.1: Reakce na kódy stavu HTTP. Obrázek 8: Nastavení integrované autentizace v ELMS. Obrázek 9: Úprava menu RS. Obrázek 9.1: Návrh řešení se změnou autentizace RS. Obrázek 9.2.3a: Návrh řešení bez změny autentizace RS – zjednodušený diagram. Obrázek 9.2.3b: Návrh tabulky DreamsparkPristup. Tabulka 9.2.3: Atributy tabulky DreamsparkPristup.

61