AUTENTIZACE A SPRÁVA UŽIVATELŮ V PROSTŘEDÍ MS SHAREPOINT 2010 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ DIPLOMOVÁ PRÁCE

Transkript

1 ČESKÉ VYSOKÉ UČENÍ TECHNICKÉ V PRAZE FAKULTA ELEKTROTECHNICKÁ DIPLOMOVÁ PRÁCE AUTENTIZACE A SPRÁVA UŽIVATELŮ V PROSTŘEDÍ MS SHAREPOINT 2010 Bc Jan Salajka Vedoucí práce: Ing. Richard Šusta, PhD. Studijní program: Otevřená informatika Obor: Softwarové inženýrství Prosinec 2011

2

3 Poděkování Děkuji Ing. Richardu Šustovi, PhD. za vedení této práce a za jeho podnětné návrhy které, ji obohatily. v

4 vi

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

6 viii

7 Abstract This thesis deals with authentication and user management in Microsoft SharePoint It also includes design and implementation application for user management for this environment. Key words: Microsoft Sharepoint, Authentication, ASP.NET, User management Abstrakt Tato diplomová práce se zabývá problematikou autentizace a správou uživatelů v prostředí Microsoft Sharepoint Její součástí je také návrh a implementace aplikace pro správu uživatelů pro toto prostředí. Klíčová slova: Microsoft Sharepoint, Autentizace, Ověřování, ASP.NET, Správa uživatelů ix

8 x

9 Obsah 1 Úvod. 7 2 Popis problému, vymezení cílů práce a požadavků Základní cíle požadované implementace Identifikované problémy a požadavky uživatelů související se správou uživatelů Změna hesla Zapomenutí hesla a jeho resetování Změna profilu uživatele a jeho vlastností Žádost o založení a zrušení uživatelského účtu Identifikované problémy a požadavky správců systému Založení a zrušení uživatelského účtu Hromadné zakládání uživatelských účtů Distribuce prvopočátečních hesel uživatelům Vytváření a údržba uživatelských skupin Změna členství uživatelů v uživatelských skupinách Import a synchronizace uživatelských profilů 10 3 Vysvětlení základních využívaných pojmů Adresářová služba (2) IIS Internet information servervices (3) Kerberos protokol (4) NTLM protokol (5) Microsoft Active Directory (6) Adam Active directory application mode (7) Identita Claim (Assertion) Security Token Autentizace (8) Basic autentizace Digest autentizace Forms-based autentizace Windows autentizace SAML token-based autentizace (9) Autorizace (10) 13 1

10 4 Popis struktury práce ve vztahu k vytyčeným cílům Analýza technologických možností řešení autentizace Autentizační metody webových aplikací ASP.NET v prostředí Windows. (11) Windows autentizace (12) Anonymní přístup autentizace založená na certifikátu Formulářová autentizace v ASP.NET aplikacích (15) Platforma Microsoft Sharepoint Design infrastruktury pro nasazení platformy Microsoft Sharepoint 2010 v heterogenním prostředí (16) Autentizační metody platformy Microsoft Sharepoint Konfigurace Autentizačních metod platformy Sharepoint detaily Claims-based módu autentizace z pohledu uživatele Práce s ASP.NET MemberShip v prostředí.net (17) Využítí ASP.NET membership funkcí C# třídy pro práci s ASP.NET membership ASP.NET SQL authenzation provider Konfigurace ASP.NET SQL autentizačního providera 24 6 Rešeršní zpracování existujících řešení Nástroje a doplňky přímo pro platformu Sharepoint SharePoint 2010 FBA Pack Produkty společnosti SharePointBoost HarePoint Password Change for SharePoint Bamboo solutions Administration toolkit Nástroje pro ASP.NET membership autentizačního providera The Asp.Net Web Site Administration Tool - WSAT The Membership Manager Control MyWSAT 29 7 Návrh a specifikace rolí jednotlivých částí systému Infrastruktura pro produkční platformu Sharepoint Schéma sítové komunikace Návrh metod ověřování jednotlivých částí systému Virtualizace prostředí Infrastruktura pro testovací a vývojové prostředí 31 2

11 8 Analýza a specifikace požadavků na aplikaci pro správu uživatelů Specifikace požadavků Nefunkcionální požadavky Funkcionální požadavky Datový model Další stanovené cíle 37 9 Popis implementace Výběr vývojového prostředí pro vyvíjenou aplikaci Výběr architektury řešení Architektura ASP.NET MVC Popis jednotlivých částí projektu aplikace Členění projektu Databáze Lokalizace Uživatelské rozhraní a design Nasazení řešení v laboratorním prostředí Instalace infrastrukturních serverů Instalace Sharepoint farmy Vytvoření Sharepoint farmy Konfigurace ověřování (19) Instalace aplikace pro správu uživatelů Nastavení oprávnění pro uživatele Ukázky uživatelského rozhraní aplikace Testování a verifikace (20) testy Černá a bílá skříňka Unit testy Akceptační testy Integrační testy Zátěžové testy Optimalizace testovacích kroků (21) Ortogonální pole Postup při použití techniky Ortogonálních polí Nalezení vhodného ortogonálního pole 50 3

12 10.3 Testování aplikace pro správu uživatelů Prerekvizity testů Vybrané testovací scénáře Test 1 aktualizace atributů aplikace Test 2 Aktualizace atributů Role Test 3 aktualizace atributů uživatele Výsledky testování Závěr Možný další rozvoj 60 Bibliografie 61 Příloha A Obsah přiloženého CD 63 4

13 Seznam tabulek Tabulka 1 Třídy pro ASP.NET Membership Tabulka 2 Metody ASP.NET SQL Membership providera Tabulka 3 Aktéři pocesů Tabulka 4 Případy užití Tabulka 5 Příklad Ortogonálního pole o velikosti 2 4, Tabulka 6 Seznam příloh pro testování Tabulka 7 paramerty a význemné hodnoty testu Tabulka 8 Testovací případy TESTU Tabulka 9 paramerty a význemné hodnoty testu Tabulka 10 Ortogonální pole Tabulka 11 Testovací případy TESTU Tabulka 12 paramerty a význemné hodnoty testu Tabulka 13 Ortogonální pole 3 9, Tabulka 14 Testovací případy TESTU Seznam obrázků Obrázek 1 Ověřovací schéma webové aplikace Obrázek 2 Schéma Sharepoint infrastruktury - Edge Firewall Obrázek 3 Schéma Sharepoint infrastruktury Back-To-Back Perimeter Obrázek 4 Schéma Claim-based autentizačního procesu - Lokální ověřování Obrázek 5 Schéma Claim based autentizačního procesu externí ověřování Obrázek 6 Příklad Sharepoint Claim based logon selectoru Obrázek 7 Příklad Windows login dialogu v Internet Exploreru Obrázek 8 Příklad Sharepoint form dased sign in page Obrázek 9 Databázové schéma ASP.NET SQL membership providera Obrázek 10 Schéma Návrhu Infrastruktury Sharepoint Obrázek 11 Schéma Komunikace a protokolů Obrázek 12 Schéma návrhu infrastruktury Sharepoint pro vývoj Obrázek 13 Diagram Případu užití - údržba uživatelů Obrázek 14 Diagram Případu užití - údržba rolí Obrázek 15 Diagram Případu užití - údržba aplikací Obrázek 16 Diagram Případu užití - Podpůrné procesy Obrázek 17 Diagram Případu užití - ověření uživatele sharepoint Obrázek 18 Schéma modelu "MembershipModel" v projektu Obrázek 19 Ukázka přehledu uživatelů Obrázek 20 Ukázka přehledu Aplikací Obrázek 21 Ukázka formuláře pro založení uživatele

14 6

15 1 ÚVOD. Zadání vzešlo z praktických požadavků na uplatnění technologie Microsoft Sharepoint v procesu výuky a především spolupráce v menších týmech na projektech, kde se podílí lidé jak z řad studentů a pedagogů, ale také externích spolupracovníků. Prostředí Microsoft Sharepoint 2010 je aktuální verzí produktu, který umožňuje především k řízené tvorbě a správě informací ve webovém prostředí. Dále usnadňuje spolupráci mezi lidmi. Pomocí služby SharePoint 2010 mohou uživatelé vytvářet weby určené ke sdílení informací s jinými uživateli, správě dokumentů od začátku do konce a publikování sestav usnadňujících rozhodování. (1) Služba Microsoft Sharepoint je součástí celé rodiny produktů společnosti Microsoft a takto je i koncipovány dostupné funkce, které jsou součástí vlastního produktu, což je vhodné zejména v prostředích, kde jsou využívány další produkty společnosti tak, aby celý systém nabízel maximální možné využití. Tento způsob návrhu a prodeje produktů má výhodu v cíleném zaměření každého dílčího produktu na určité cíle a požadavky na něj kladoucí. Nicméně v heterogenním prostředí se toto zaměření a ohraničení jednotlivých systémů může působit negativně a to zejména tím, že pokud zákazník nevyužije nebo nemůže využít i ostatní programy a systémy z dané rodiny, mohou mu některé funkce chybět. Na druhou stranu se společnost Microsoft snaží takovou to závislost a uzavřenost systémů eliminovat a postupně nabízí zákazníků možnost volby a ve svých produktech definuje standardy a rozhraní pro spolupráci i s jinými technologiemi, tak aby podpořila rozvoj, prodej a uplatnění svých produktů v co nejširší možné míře. Implementaci Sharepoint platformy je možné provést jako klíčový prvek celé infrastruktury a jeho integraci do všech systémů. Toto nasazení je nutné řešit integrovaně se všemi ostatními prvky heterogenní infrastruktury, zejména klíčové je spojení s adresářovými službami. Na druhou stranu již není jednoduché nasadit Sharepoint lokálně například pro určitou pracovní (výzkumnou) skupinu nebo jen organizační část, jelikož tato jednotka nemá zpravidla přístup k centrálním systémům adresářových služeb na potřebné technologické úrovni. Zadání a požadavky na tuto práci vycházejí z víše uvedených vlastností produktu, kde při nasazení v heterogenním prostředí v malých různorodých týmech chybějí některé funkce, pokud nedokážeme (nebo nechceme) implementovat komplexní řešení společnosti Microsoft v celém produkčním prostředí. Práce se soustředí na doplnění požadovaných funkcí týkající se autentizace a správy uživatelů v prostředí, kde nechceme využít jiných produktů implementující adresářové služby a správu identit, anebo chceme využít prostředí Sharepoint s různými správci identit v jednom prostředí. Problematika integrace adresářových služeb a správy uživatelů je velice rozsáhlé téma a v rámci této práce byla zpracována pouze část týkající se nasazení platformy Sharepoint nezávislé na centrálních adresářových službách. 7

16 2 POPIS PROBLÉMU, VYMEZENÍ CÍLŮ PRÁCE A POŽADAVKŮ. Cílem práce je navrhnou a implementovat vhodné autentizační metody pro prostředí Microsoft Sharepoint 2010 s ohledem na možnost využívat uživatelské účty mimo běžně používané integrované adresářové služby, taky aby bylo možné jednoduchým způsobem sdílet prostředí Sharepoint mezi základními uživateli (zaměstnanci) a externími uživateli. Dále na základě uživatelských požadavků implementovat vhodné rozhraní pro správu těchto externích uživatelských účtů. 2.1 ZÁKLADNÍ CÍLE POŽADOVANÉ IMPLEMENTACE Cíle byly specifikovány ve spolupráci se zadavatelem. 1. Moci využít produkt Microsoft Sharepoint 2010 implementovaný na operačním systému Microsoft Windows Server Umožnit přístup k platformě Sharepoint uživatelům ověřovaným z lokální Active directory. 3. Umožnit přístup k platformě Sharepoint uživatelům ověřovaným pomocí uživatelských účtů spravovaných zadavatelem v samostatném uložišti (např. DB SQL). 4. Umožnit řešit problémy uživatelů s uživatelskými účty spravovanými zadavatelem v samostatném uložišti. 5. Umožnit administraci uživatelských účtů spravovanými zadavatelem v samostatném uložišti. 6. Celý projekt implementovat v laboratorním prostředí včetně vytvoření testovacích scénářů a jejich následné ověření. 2.2 IDENTIFIKOVANÉ PROBLÉMY A POŽADAVKY UŽIVATELŮ SOUVISEJÍCÍ SE SPRÁVOU UŽIVATELŮ. Tyto problémy se týkají valné většiny uživatelů a nejsou příliš závislé na způsobu využití platformy Sharepoint, její velikosti a způsobu integrace s další infrastrukturou. Uvádím zde asi ty nejdůležitější, které vycházení z každodenní praxe ZMĚNA HESLA Standardní řešení nemá vestavěnu funkčnost na uživatelskou změnu hesla. Tento problém je dvojího charakteru, a to změna hesla při vypršení platnosti (případně při nutnosti změny při prvním přihlášení) a klasická změna hesla při běžném provozu. Na tyto problémy existuje několik komerčních doplňků řešících tuto problematiku a je možné je bez problémů využít ZAPOMENUTÍ HESLA A JEHO RESETOVÁNÍ Tento problém souvisí s předchozím a opět standardní prostředí Sharepoint tuto funkcionalitu nenabízí, ale jsou dostupné doplňky jako v předchozím případě ZMĚNA PROFILU UŽIVATELE A JEHO VLASTNOSTÍ Údržba profilu koncovým uživatelem je v prostředí Sharepoint implementována. Je možné konfigurovat službu User profile service, která umožňuje definici atributů uživatelů a jejich synchronizaci s ostatními systémy. Ve výchozí konfiguraci jsou základní informace profilu uživatele pouze pro 8

17 čtení a jako autoritativní informace jsou brány data z nadřazené adresářové služby (typicky z Active directory) ŽÁDOST O ZALOŽENÍ A ZRUŠENÍ UŽIVATELSKÉHO ÚČTU Platforma Sharepoint umožňuje automatické zakládání uživatelských účtů (při spojení s Microsoft Active Directory) a případnou distribuci prvotního uživatelského hesla, nicméně dle mého názoru, tato funkcionalita v heterogenním prostřední není dostatečná. Opět existují některé doplňky, které je možné k tomuto procesu využít, případně je možné k tomuto účelu implementovat proces žádosti přímo v platformě Sharepoint pomocí jednoduchého workflow. 2.3 IDENTIFIKOVANÉ PROBLÉMY A POŽADAVKY SPRÁVCŮ SYSTÉMU ZALOŽENÍ A ZRUŠENÍ UŽIVATELSKÉHO ÚČTU Pokud se nejedná o uživatelské účty automaticky zakládané jinými mechanizmy v adresářových službách pomocí systémů na správu identit, je tento požadavek nejběžnější činností správce HROMADNÉ ZAKLÁDÁNÍ UŽIVATELSKÝCH ÚČTŮ V případě využití platformy Sharepoint v rámci výuky, případně pro spolupráci např. projektových týmů je požadavek na založení více uživatelských účtů (případně zrušení/zneplatnění) opět běžným úkonem nastávajícím na začátku semestru nebo při startu nového projektu. S tímto procesem také souvisí i další identifikovaný požadavek DISTRIBUCE PRVOPOČÁTEČNÍCH HESEL UŽIVATELŮM Distribuce počátečních hesel může být velice problematická a to zejména ze dvou hlavních důvodů: 1. Zajištění bezpečnosti a snížení rizik kompromitace příslušných uživatelských účtů při procesu distribuce hesel např. em. 2. Vynucení změny hesla při prvním přihlášení. Tento požadavek je z pohledu prostředí webových aplikací na systémech Windows poměrně problematický, vyplývající z technologických důvodů. Problém této situace je dán použitím uživatelského účtu uživatele již při získávání zdrojů webových stránek nebo jejich renderování vlastním webovým serverem IIS, který nemůže použít pro tyto účely účet uživatele, který je označen pro změnu hesla při prvním přihlášení, tak jak to například dělá přímo operační systém VYTVÁŘENÍ A ÚDRŽBA UŽIVATELSKÝCH SKUPIN Další oblast souvisí s uživatelskými skupinami, či rolemi, které většinou sdružují a zjednodušují správu oprávnění. Platforma Sharepoint nabízí definování vlastních uživatelských skupin, ale také umožnuje využití skupin definovaných v externích adresářových službách. Díky této funkcionalitě není potřeba tento problém dále pro platformu Sharepoint řešit. 1 Tuto funkcionalitu je možné implementovat přímo na aplikační úrovni rozdělením aplikace na část s anonymním přístupem, která musí tuto situaci ošetřit 9

18 2.3.5 ZMĚNA ČLENSTVÍ UŽIVATELŮ V UŽIVATELSKÝCH SKUPINÁCH Tato problematika je díky implementaci vlastních uživatelských skupin již v systému řešena IMPORT A SYNCHRONIZACE UŽIVATELSKÝCH PROFILŮ V platformě Sharepoint je implementována celá oblast týkající této problematiky. Jedná se tzv. User profile service, která nabízí velikou škálu možností konfigurace. Opět je možné tuto vestavěnou funkcionalitu bez problémů využít. 10

19 3 VYSVĚTLENÍ ZÁKLADNÍCH VYUŽÍVANÝCH POJMŮ V celé práci se opírám o velké množství existujících systémů, využívaných protokolů a služeb. V této části jsou vysvětleny některé z nich, ostatní obsahují vysvětlení přímo v dané části, kde jsou použity. 3.1 ADRESÁŘOVÁ SLUŽBA (2) Adresářová služba je aplikace shromažďující a poskytující informace o pojmenovaných objektech, ke kterým bývá intenzivně přistupováno, ale mění se jen zřídka. Informace jsou uloženy ve formě atributů hierarchicky pojmenovaných záznamů (DIT), které jsou pro lepší integraci systémů standardizovány. Adresářová služba je často ústřední bezpečnostní komponenta a udržuje odpovídající záznamy pro řízení přístupu (jakým způsobem může někdo operovat s nějakým objektem). Soudobé adresářové služby využívané pro správu a uživatelů: LDAP (Lightweight Directory Access Protocol) a jeho implementace OpenLDAP Active Directory služba ve Windows, od verze Windows 2000 Server 3.2 IIS INTERNET INFORMATION SERVERVICES (3) IIS dříve nazývány Internet Information Server je web server a sada funkcí a rozšiřujících modulů vytvořených společností Microsoft pro použití s Microsoft Windows. Je to druhý nejpoužívanější web server po Apache HTTP Server 3.3 KERBEROS PROTOKOL (4) Kerberos je síťový autentizační protokol umožňující komukoli komunikujícímu v nezabezpečené síti prokázat bezpečně svoji identitu někomu dalšímu. Kerberos zabraňuje odposlechnutí nebo zopakování takovéto komunikace a zaručuje integritu dat. Byl vytvořen primárně pro model klientserver a poskytuje vzájemnou autentizaci klient i server si ověří identitu své protistrany. 3.4 NTLM PROTOKOL (5) NTLM (zkratka z NT LAN Manager) je autentizační protokol, používaný zejména protokolem SMB a některými implementacemi síťových protokolů Microsoft Windows za účelem ověření uživatele nebo spojení. Je důležitou součástí konceptu Integrated Windows Authentication. Protokol není oficiálně dokumentován, byl však popsán v rámci práce na projektu Samba. Stejně jako Microsoft Windows, prošel i NTLM značným vývojem, zejména s ohledem na bezpečnost. Jako NTLMv2 je označována novější verze, která se liší zacházením s privátními daty. Starší verze je od té doby označována jako NTLMv1. Kryptografické mechanismy NTML jsou shodné s mechanismy použitými v protokolu MS-CHAP, jež jsou popsány v RFC 2433 (verze v1) a RFC 2759 (verze v2). 3.5 MICROSOFT ACTIVE DIRECTORY (6) Active Directory je implementace adresářových služeb LDAP firmou Microsoft pro použití v prostředí systému Microsoft Windows. Active Directory umožňuje administrátorům nastavovat politiku, instalovat programy na mnoho počítačů nebo aplikovat kritické aktualizace v celé organizační struktuře. Active Directory ukládá své informace a nastavení v centrální organizované databázi. 11

20 3.5.1 ADAM ACTIVE DIRECTORY APPLICATION MODE (7) Adam je režim služby Active Directory directory, který je navržen pro specifické potřeby organizace, které používají aplikace pracující s adresářovými službami. Zatímco samotná služba Active Directory podporuje aplikace pracující s adresářovými službami spolu s operačním systémem, nemusí splňovat všechny požadavky. Nejčastějším příkladem je změna schématu, které aplikace požadují. Adam je samostatnou rolí, která slouží pouze pro potřeby aplikací a není zatížená dalšími omezeními a vazbami. 3.6 IDENTITA Identitou v kontextu této práce rozumíme reprezentace řady tvrzení o jednom předmětu nebo osobě. 3.7 CLAIM (ASSERTION) Atribut identity (tvrzení) jako například uživatelské jméno, AD skupina a podobně. 3.8 SECURITY TOKEN Serialoizovaná sada tvrzení (claim) o autentikovaném uživateli. 3.9 AUTENTIZACE (8) Autentizací se myslí ověření identity uživatele služeb nebo původce zprávy. Používají se tyto základní metody pro zjištění identity: podle toho, co uživatel zná (zná správnou kombinaci uživatelského označení a hesla nebo PIN) podle toho, co uživatel má (nějaký technický prostředek, který uživatel vlastní hardwarový klíč, smart card, privátní klíč apod.) podle toho, čím uživatel je (uživatel má biometrické vlastnosti, které lze prověřit otisk prstu, snímek oční duhovky či sítnice apod.) podle toho, co uživatel umí (umí správně odpovědět na náhodně vygenerovaný kontrolní dotaz) BASIC AUTENTIZACE Basic access authentication (jednoduché ověření přístupu) je v informatice označení pro jednoduchou autentizaci při přístupu na webové stránky. Webový server vyzve pomocí protokolu HTTP přistupujícího klienta, aby poslal v rámci požadavku na stránku také autentizační informace (jméno a heslo). Jméno a heslo je zasláno jako jeden textový řetězec. Jméno a heslo je zakódováno metodou Base64 a odesláno v rámci HTTP požadavku. Přestože zakódování znesnadňuje čtení autentizačních informací člověkem, není jeho smyslem tyto informace kryptograficky zabezpečit DIGEST AUTENTIZACE Digest autentizace je autentizační metoda, která je používaná pro výměnu autentizačních informací mezi web serverem a klientem. Využívá kryptovací algoritmus (MD5) pro zaslání hesla po síti. Je bezpečnější než Basic autentizace, která zasílá heslo v podobě prostého textu. 12

21 3.9.3 FORMS-BASED AUTENTIZACE Ověřování pomocí formuláře je možné proti standardní adresářové službě LDAP nebo proti databázovým serverům (SQL a podobně). Je možné také implementovat vlastní řešení nebo využít řešení třetích stran WINDOWS AUTENTIZACE Tento typ autentizace využívá základní autentizační protokoly implementované v systémech Windows, jako jsou NTLM, Kerberos, anonymní přístup, Basic a Digest autentizace SAML TOKEN-BASED AUTENTIZACE (9) Security Assertion Markup Language (SAML) je založen na XML standardu pro výměnu autentizačních a autorizačních informací mezi bezpečnostními doménami, to je, mezi identity providerem (producer of assertions) a servis providerem (consumer of assertions). SAML je produkt OASIS Security Services Technical Committee. SAML token-based autentizaci v prostředí Microsoft Sharepoint je možné provozovat ve spolupráci s AD FS 2.0 (active directory federation service), LDAP a nebo identity providery třetích stran AUTORIZACE (10) Je funkce, která specifikuje přístupová práva k zdrojům, které se týká bezpečnosti informací a bezpečnost počítačů obecně a zejména řízení přístupu. Formálně řečeno, "autorizovat" je definovat přístupová oprávnění. 13

22 4 POPIS STRUKTURY PRÁCE VE VZTAHU K VYTYČENÝM CÍLŮM. Práce je rozdělena do několika celků, které umožňují oddělit jednotlivé etapy a každá z nich plní některé s vytyčených cílů: 1. Přehled existující řešení zabývajících se podobnou problematikou (kap. 6). 2. Analýza technologických možností řešení autentizace vzhledem k požadovaným vlastnostem a výběr varianty finálního řešení (kap. Chyba! Nenalezen zdroj odkazů.). 3. Návrh a konfigurace autentizace Microsoft Sharepoint 2010 vybraného řešení v laboratorním prostředí (kap. 6). 4. Návrh, vývoj a implementace pomocných nástrojů pro správu uživatelů spravovaných v samostatném uložišti (kap. 8 a 9). 5. Otestování implementovaných nástrojů v laboratorním prostředí na základě navrženým testovacích scénářů (kap. 9.5). 14

23 5 ANALÝZA TECHNOLOGICKÝCH MOŽNOSTÍ ŘEŠENÍ AUTENTIZACE 5.1 AUTENTIZAČNÍ METODY WEBOVÝCH APLIKACÍ ASP.NET V PROSTŘEDÍ WINDOWS. (11) ASP.NET,ve spojení s Microsoft Internet Information Services (IIS), může autentizovat uživatelské přihlašovací informace pomocí těchto 3 autentizačních metod: Windows autentizace o Basic o Digest o Integrated Windows Authentication (NTLM or Kerberos) Formulářová autentizace, při které je využita přihlašovací strana a řídí autentizaci aplikace. Ověření certifikátem klienta. Bez ověřování (anonymní přístup) ASP.NET kontroluje přístup k informací a aplikačním stránkám porovnáním autentizačních informací nebo jejich reprezentací proti oprávněním souborového systému NTFS nebo souboru XML který obsahuje seznam autorizovaných uživatelů, rolí nebo autorizovaných typů http požadavků (http verbs). Vlastní autentizace v prostředí Microsoft.Net je implementováno pomocí tzv. providerů, které jsou tvořen třídou obsahující statické metody umožňující zpracovat autentizační požadavek od klienta. ASP.NET aplikace může být nakonfigurována (nasměrována) některého Autentizačních providerů, kteří řídí a udržují stavy během autentizačního procesu: Windows autentizační provider Autentizační providere na bázi formuláře WINDOWS AUTENTIZACE (12) Windows autentizace je implementována v ASP.NET s využitím WindowsAuthenticationModule modulu. Modul konstruuje WindowsIdentity na základě ověřovacích informací předávaných webovým serverem a nastaví identitu jako current User property hodnotu pro využití aplikací. Webový server umožňuje získat autentizační informace od uživatele případně klientského počítače pomocí několika metod: Základní ověřování (13) Jak již bylo uvedeno v přehledu v úvodu práce, tato metoda je nejjednodušší a nejpodporovanější metodou klientskými operačními systémy a internetovými prohlížeči. Jeho největší nevýhodou je, že uživatelské informace jsou přenášené po síti (internetu) v textové podobě bez jakéhokoliv šifrování a mohou být tedy jednoduše odposlechnuty. Je možné zvýšit úroveň zabezpečení šifrováním na úrovni samotné komunikace mezi klientem a serverem pomocí protokolu SSL. Před přenosem uživatelského jména je doplněno dvojtečkou, za ní je připojeno heslo. Výsledný řetězec je kódována algoritmem Base64. Řetězec je předán v HTTP hlavičce na server. 15

24 Webový server se pokusí předanými informacemi přihlásit k operačnímu systému a na základě úspěchu či neúspěchu dále řídí přístup k aplikačním zdrojům Digest ověřování (14) Tento typ autentizace (stejně jako základní autentizace) vyžaduje od uživatele, aby zadal informace do přihlašovacího dialogového boxu, který je zobrazen prohlížečem. Na rozdíl od základní autentizace však digest autentizace předává místo hesla samotného jeho hašovanou formu. Samotné heslo se v textové podobě nikdy po síti neposílá, protože se posílá jeho hašovaná forma, což zabraňuje zcizení hesla i přes fakt, že není použito šifrování pomocí SSL. Proces autentizace uživatele pomocí souhrnné metody funguje takto: 1. Neautentizovaný klient požaduje webovou stránku s omezeným přístupem 2. Server odpoví odezvou HTTP 401. Tato odezva zahrnuje příležitostnou hodnotu (nonce value), což je náhodně vygenerovaná série bitů. Server zajišťuje, že každá příležitostná hodnota bude jedinečná, předtím než ji použije. 3. Klient použije pro vytvoření haše příležitostnou hodnotu, heslo, uživatelské jméno a některé další hodnoty. Hodnota tohoto haše, tzv. digest, je poslána zpátky na server společně s uživatelským jménem ve formě prostého textu. 4. Server použije příležitostnou hodnotu, heslo uložené pro uživatelské jméno a ostatní hodnoty pro vytvoření haše. Tento haš pak porovná s hašem získaným od klienta. Pokud obě hodnoty souhlasí, je autentizace úspěšná. Odposlechnutý digest případnému útočníkovi nepřinese žádný užitek, protože příležitostná hodnota se mění s každým autentizačním požadavkem. Z digestu se původní heslo extrahovat nedá. Protože digest obsahuje příležitostnou hodnotu, nemůže být použit pro opakovaný útok (replay attacks), kdy se útočník pokouší získat přístup ke chráněným zdrojům tak, že použije dříve zachycený digest Integrovaná Windows autentizace (14) Tato metoda je nejvhodnějším autentizačním standardem pro intranetové aplikace, neboť autentizaci vykonává bez toho, aby se vyžadovala interakce s klientem. Webový server požádá klienta, aby se autentizoval, prohlížeč pošle token reprezentující uživatelský účet Windows aktuálního uživatele. Pokud webový server při autentizaci pomocí těchto údajů neuspěje, objeví se dialogový box, kam může uživatel zadat jiné uživatelské jméno a heslo. Integrovaná autentizace Windows může fungovat jen tehdy, když jsou klient a webový server ve stejné lokální síti nebo intranetu, neboť tato metoda de facto nepřenáší údaje obsahující uživatelská jména a hesla. Místo toho pracuje v koordinaci s doménovým serverem nebo instancí Active Directory, kde proběhlo přihlášení, přičemž přikáže příslušnému počítači, aby na webový server poslal autentizační údaje. Jako protokol je pro přenášení autentizačních údajů použita buď autentizace NTLM (NT LAN Manager), nebo Kerberos 5 závisí to na verzi operačního systému klienta a serveru. Popis autentizačních protokolů není předmětem této práce a podrobnosti je možné dohledat v citovaných zdrojích. 16

25 5.1.2 ANONYMNÍ PŘÍSTUP Bez ověřování neboli anonymní přístup je zde uveden pro úplnost, jeho využití napovídá sám název, pro aplikace, které jsou nabízeny všem uživatelům bez rozlišení jejich identity. Takové to aplikace většinou musí být doplněny některým z předešlých způsobů autentizace pro administraci, nebo existuje jiný způsob, případně jiná aplikace, pro zprávu, úpravy a pořízení dat. Místo konkrétního uživatele je pro spuštění a přístup aplikace k ostatním zdrojům využit jeden uživatelský účet systému Windows pro všechny uživatele. Oprávnění tohoto účtu určují oprávnění a přístup ke všem prostředkům, které mohou využívat anonymní uživatelé přistupující k serveru AUTENTIZACE ZALOŽENÁ NA CERTIFIKÁTU Autentizace uživatele na bázi certifikátu umožňuje přihlášení uživatele pomocí klientského digitálního certifikátu, certifikát vydaný certifikační autoritou je namapován na příslušný uživatelský účet uživatele Windows. Tento typ autentizace je náročný na jak na zavedení a zprávu celé infrastruktury starající se o vydávání a distribuci certifikátů. Tento typ autentizace není vhodný pro splnění požadavků definovaných v úvodu této práce FORMULÁŘOVÁ AUTENTIZACE V ASP.NET APLIKACÍCH (15) Formulářová autentizace umožňuje ověřit identitu uživatele zadáním přihlašovacích informací pomocí přihlašovacího formuláře. Neautentizovaný požadavek je přesměrován na přihlašovací stránku, kde uživatel zadá ověřovací informace a odešle formulář, jestliže aplikace ověří požadavek, systém předá tiket obsahující klíč pro znovu ověření identity v dalších požadavcích. Client Request: Welcome.aspx Response: Login.aspx Request: Login.aspx + data Response: Welcome.aspx + Cookie Web Server Authenticate user Web.config or User database OBRÁZEK 1 OVĚŘOVACÍ SCHÉMA WEBOVÉ APLIKACE Tiket, který je vytvořen při přihlášení uživatele, je používán a sledován při každém požadavku. Většinou je předán pomocí Cookie (jak ukazuje schéma). Platforma ASP.NET umožňuje také formulářové ověřování i bez použití Cookie. V tomto případě je tiket předáván pomocí hodnoty v adrese požadavku (query string) 5.2 PLATFORMA MICROSOFT SHAREPOINT DESIGN INFRASTRUKTURY PRO NASAZENÍ PLATFORMY MICROSOFT SHAREPOINT 2010 V HETEROGENNÍM PROSTŘEDÍ (16) V této kapitole jsou popsány základní typy designu síťové topologie a zabezpečení platformy Sharepoint. Každá z uvedených vybraných variant má své specifické vlastnosti, úroveň zabezpečení a také složitost nasazení a následné údržby. 17

26 Edge firewall celá infrastruktura je oddělena od internetu pouze jedním firewallem. Toto řešení je velice jednoduché na implementaci a je vhodné zejména tam kdy v zabezpečení nerozhoduje rozdělení uživatelů na interní a externí. Firewall zajišťuje pouze technologické oddělení platformy Sharepoint od internetu. V případě kompromitace platformy získá narušitel přístup k celému datovému obsahu. Internet Corporate network Remote users Firewall Server farm Internal users OBRÁZEK 2 SCHÉMA SHAREPOINT INFRASTRUKTURY - EDGE FIREWALL Back-to-back perimeter oddělení celé platformy Sharepoint dvěma firewally. Tato varianta je podobná předchozí, ale odděluje infrastrukturu Sharepoint od ostatního provozu interních uživatelů. Při kompromitaci aplikací získá útočník opět přístup k celému datovému obsahu, ale neumožní mu získat přímý přístup k dalším prostředků ve vnitřní síti. Jak naznačuje obrázek je možné ještě celý perimetr rozdělit do několika celků a tím případně zajistit vyšší bezpečnost a monitoring pomocí routerů případně firewallů (záleží na možnosti technologických možnostech těchto zařízení). Firewall Router A Router B Firewall Users Application server SQL Server DNS Administrator workstation Web servers Application server SQL Server Active Directory domain controller Layer 1 Web servers Layer 2 Application servers and database servers Layer 3 DNS and domain controller OBRÁZEK 3 SCHÉMA SHAREPOINT INFRASTRUKTURY BACK-TO-BACK PERIMETER AUTENTIZAČNÍ METODY PLATFORMY MICROSOFT SHAREPOINT 2010 Prostředí Microsoft Sharepoint 2010 nabízí dva základní autentizační módy, které je možné při konfiguraci zvolit tzv. klasický a claims-based Klasický mód autentizace Klasický mód autentizace využívá metody Windows autentizace popsané v kapitole Je založen převážně na technologiích Microsoft a tím pádem není vhodný pro heterogenní univerzitní prostředí. 18

27 Claims-based mód autentizace Tento mód autentizace a správy identit je vystavěn na části Microsoft.NET nazvané Windows Identity Foundation (WIF). V prostředí Sharepoint umožňuje využít různé typy autentizačních mechanizmů a také umožňuje jejich mixování. Jsou dostupné následující mechanizmy: Windows autentizace (Integrovaná Windows autentizace Kerberos and NTLM, Digest and Basic autentizace) všechny protokoly byly již popsány v kapitole V rámci analýzy byla Windows autentizace identifikována jako nedostatečná pro heterogenní prostředí, jelikož je orientována převážně na prostředí Windows a není jednoduchým způsobem rozšiřitelná. Form-based autentizace je popsána v kapitole a byla zvolena jako nejhodnější kandidát pro implementaci SAML token-based autentizace je popsána v kapitole Při zvolení Claim-based autentizačního módu SharePoint Server 2010 automaticky změní všechny uživatelské účty na tzv. claim identity rozlišeny jednoznačným claim tokenem. Tento token obsahuje tvrzení, vztahující se k uživateli. Windows účty jsou převedeny na Windows claim. Formbase membership, uživatelé se mění v claim ověřování na základě formulářů. Mohou být také použity Claimy, které jsou obsaženy v SAML based tokenu. Na následujících schématech je zobrazen autentizační proces v různých typech prostředí Microsoft Sharepoint. OBRÁZEK 4 SCHÉMA CLAIM-BASED AUTENTIZAČNÍHO PROCESU - LOKÁLNÍ OVĚŘOVÁNÍ 19

28 OBRÁZEK 5 SCHÉMA CLAIM BASED AUTENTIZAČNÍHO PROCESU EXTERNÍ OVĚŘOVÁNÍ Vysvětlení pojmů uvedených ve schématech: Security Token Service (STS): vytváří, podepisuje a vydává bezpečnostní tokeny. Issuing Authority: systém na správu identit, který zná tvrzení (claims) - AD, ASP.NET, LiveID, atd. Identity Provider: důvěryhodná služba, která vytváří a postupuje tvrzení (claims). Relying Party: aplikace, která rozhoduje o autorizaci na základě přijatých tvrzení KONFIGURACE AUTENTIZAČNÍCH METOD PLATFORMY SHAREPOINT Základním stavebním systémovým kamenem platformy Sharepoint je tzv. webové aplikace na webovém serveru. Tato webová aplikace přijímá požadavky uživatelů a dále je zpracovává. Každá webová aplikace má několik základních parametrů, tyto můžeme rozdělit na systémové dané webovým serverem IIS a pak na Sharepoint parametry, které jsou dány již samotnou platformou. Ze systémových parametrů je důležité tzv. mapování, na základě kterého IIS rozlišuje příchozí požadavky a rozděluje je na zpracování jednotlivým webovým aplikacím. Základní mapování je na základě IP adresy a TCP portu na kterém každá webová aplikace poslouchá. Pokud chceme sdílet jednu IP adresu a požívat stejný port (standardně je pro protokol http využíván port 80) je nutné rozlišit mapování na základě tzv. host headeru, což není nic jiného než DNS jméno na základě kterého přišel požadavek od klienta. Zvláštním případ mapování je pro zabezpečené připojení pomocí protokolu SSL (HTTPS), které ve výchozím stavu poslouchá na portu 443 a není možné jednoduše sdílet stejnou IP adresu na IIS. Pokud chceme provozovat více zabezpečených webových aplikací, měli bychom mít pro každou z nich připravenou samostatnou IP. Dalším důležitým konfiguračním parametrem je konfigurace tzv. aplikačního poolu a jeho identity. Poslední důležitou částí z pohledu platfor- 20

29 my Sharepoint je konfigurace autentizačních providerů, jejich konfigurace je podrobně popsaná v kap Konfigurace webové aplikace na straně Sharepoint určuje zejména, ve kterých databázích obsahu budou uloženy data uživatelů, dále tzv. zóny webové aplikace a alternativní jména a v neposlední řadě typ autentizace. Sharepoint dává k dispozici 5 zón přístupu k webové aplikaci ( Default, Intranet, Extranet, Internet, Custom ). Každá z těchto zón je reprezentována webovou adresou serveru (včetně protokolu, např. svou webovou aplikací na úrovni IIS 2. Pro takto vytvořenou zónu je možné pro takto definovanou zónu nadefinovat typ ověřování a také další restrikce. Toto je důležité zejména při publikování informací dostupných z internetu, tak aby tento byl maximálně zabezpečen a zároveň aby se dalo využít zjednodušeného (integrovaného) ověřování při přístupu interních uživatelů. Dále jsou zde k dispozici tzv. alternativní jména, kterých je možné ke každé zóně nadefinovat libovolné množství, ale ty pouze způsobí přesměrování uživatele na výchozí adresu dané zóny DETAILY CLAIMS-BASED MÓDU AUTENTIZACE Z POHLEDU UŽIVATELE Z pohledu uživatele je navenek formulářové ověřování tvořeno dvěma dialogy. Při přístupu na zabezpečené stránky (vyžadující autentizaci) prostředí Sharepoint se uživateli nejdříve zobrazí tzv. logon selektor a po výběru typu poskytovatele autentizace pokračuje přesměrování na konkrétní přihlašovací stránku (formulář se zadáním jména a hesla). Pro zajištění bezpečného přenosu uživatelského jména a hesla je nutné zabezpečit komunikaci pomocí šifrování. Toto je možné jednoduše zajistit pomocí protokolu HTTPS a případně zabezpečenou komunikaci pomocí konfigurace na webovém serveru přímo vynutit Claims based logon selector Logon selector se zobrazí při přístupu na zabezpečené stránky platformy Sharepoint v módu Claim based ověřování a v případě, že je povoleno pro zónu více typů autentizace. V tomto formuláři si uživatel musí zvolit typ ověřování (Windows, Form nebo Claim). Předloha této webové stránky je součástí tzv Sharepoint Hive na lokálním disku daného serveru (typicky C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\IDENTITYMODEL\LOGIN\default.aspx). OBRÁZEK 6 PŘÍKLAD SHAREPOINT CLAIM BASED LOGON SELECTORU Windows Sign in page V případě, že probíhá Windows ověřování, dostane uživatel klasický dialog pro zadání jména a hesla, který generuje webový prohlížeč, tento dialog není možné nijak upravovat ani customizovat. Pokud uživatel umožní webovému prohlížeči poskytnout informace o identitě uživatele aktuálně při- 2 Pozor webové aplikace na straně Sharepoint a webové aplikace na straně webového serveru nejsou jedno a totéž (jedna ku jedné), i když to tak běžně navenek působí. 21

30 hlášeného přímo k operačnímu systému Windows, dojde k takzvanému integrovanému přihlášení automaticky bez toho, aby uživatel musel zadávat znovu jméno a heslo. Tato situace záleží na bezpečnostní zóně, v níž je identifikován webový server, na který byl dán požadavek 3. Výchozí nastavení pro bezpečnostní zónu 4 Intranet a Místní síť je integrované přihlášení povoleno. OBRÁZEK 7 PŘÍKLAD WINDOWS LOGIN DIALOGU V INTERNET EXPLORERU Forms base Sign in page Tento dialog pro zadání jména a hesla se uživateli objeví, pokud dochází k ověřování pomocí formuláře, opět je součástí hive Sharepoint na pevném disku serveru. Opět je možné jej upravit, kompletní postup pro vývoj alternativní přihlašovací stránky je uveden např. na internetu: OBRÁZEK 8 PŘÍKLAD SHAREPOINT FORM DASED SIGN IN PAGE 5.3 PRÁCE S ASP.NET MEMBERSHIP V PROSTŘEDÍ.NET (17) ASP.NET membership dává vestavěnou možnost ověřovat a ukládat uživatelské přístupové informace. Umožňuje vývojářům webových aplikací ASP.NET využít funkce pro přihlášení a údržbu uživatelských účtů. ASP.NET membership je možné využít pro tyto činnosti: Založení uživatele a vytvoření hesla. Uložení přihlašovacích informací (uživatelské jméno, heslo a další informace) v Microsoft SQL databázi, Active Directory, nebo v alternativních uložištích. 3 Toto platí pro prohlížeč Microsoft Internet Explorer. 4 Pozor tyto zóny nekorespondují s nastavením na straně Sharepoint, ale jsou čistě záležitostí internetového prohlížeče IE. 22

31 Ověření uživatele pomocí vlastního řešení, nebo je možné využít vestavěný ASP.NET login control pro vytvoření kompletního autentizačního systému s minimem vlastního kódu. Údržba hesel, která zahrnuje vytvoření, změnu a resetování hesla uživatele závisející na konfigurace membership systému a je také možné využít automatického systému na resetování hesla na základě bezpečnostní otázky a odpovědi. Zajištění jednoznačného identifikátoru přihlášeného uživatele, který je možné využít ve vlastní aplikaci a je možné aplikaci také integrovat s ASPN.NET personalizací a řízením (ověřováním) rolí (ASP.NET personalization and role-management). Využití vlastního memebership providera, který umožní využít vlastní kód pro řízení uživatelských účtů včetně datového uložiště VYUŽÍTÍ ASP.NET MEMBERSHIP FUNKCÍ Pro využití vestavěných funkcí je nutné provést tři základní kroky: Konfigurace membership ve vaší aplikaci. Tato konfigurace je uvedena v souboru Web.config (základní konfigurační soubor ASP.NET aplikace). Nakonfigurovat aplikaci pro použití ověřování na základě formuláře a případně nastavit zabezpečení pro jednotlivé aplikační stránky. Definovat uživatelské účty. Pro vytváření a údržbu je možné vytvořit vlastní rozhraní v aplikaci s využitím vestavěných komponent (controls), případně použít nástroj pro administraci ASP.NET webových stránek (Web Site Administration Tool). Vytvoření samostatného nástroje pro správu uživatelský účtů je výsledkem této diplomové práce C# TŘÍDY PRO PRÁCI S ASP.NET MEMBERSHIP Jednotlivé třídy a jejich funkce jsou popsány v následující tabulce: TABULKA 1 TŘÍDY PRO ASP.NET MEMBERSHIP Třída / rozhraní Membership MembershipUser MembershipProvider MembershipProviderCollection Fukce Obsahuje základní vybavení ASP.NET membership: Založení uživatele. Zrušení uživatele. Aktualizace uživatelských informací. Vyhledání uživatele pomocí u nebo jména. Ověření uživatele (autentizace). Zjištění počtu uživatelů, kteří jsou on-line. Zprostředkovává informace o konkrétním uživateli: Získání uživatelského hesla a bezpečnostní otázky. Změna hesla. Zjištění jestli je uživatel online. Ověření uživatele Získání data poslední aktivity uživatele a změny hesla. Odemčení uzamčeného uživatele. Definuje funkcionalitu pro datové uložiště využívané ASP.NET membership systému. Vrací kolekci providerů, kteří jsou k dispozici v systému. 23

32 MembershipUserCollection MembershipCreateStatus MembershipCreateUserException MembershipPasswordFormat Uchovává reference na MembershipUser objektů. Specifikuje popisné hodnoty možných selhání při zakládání uživatele. Definuje výjimky, které mohou nastat při neúspěšném založení uživatele. Specifikuje možné formáty pro uložení hesla pomocí membership providera (Clear, Hashed, Encrypted) 5.4 ASP.NET SQL AUTHENZATION PROVIDER Jak již bylo uvedeno výše.net 2.0 obsahuje tzv. membership feature, která umožňuje využít autentizaci pomocí formuláře (form base authentication). Uživatelské účty mohou být uloženy např. v SQL databázi. ASP.NET SQL Mebership providera je možné využít také v prostředí Microsoft Sharepoint. Tato varianta se mi jeví nejvýhodnější, z pohledu jednoduchosti nasazení, univerzálnosti, možnosti využít implementace jeho implementace a rozšíření i pro jiné aplikace KONFIGURACE ASP.NET SQL AUTENTIZAČNÍHO PROVIDERA Pokud chceme použít ASP.NET SQL autentizačního providera je nutné nejprve vytvořit databázi pro ukládání persistentních informací. K tomuto účelu je možné využít Microsoft SQL server. Je možné používat tzv. Express verzi SQL serveru 2005 či 2008, kterou je možné využívat zdarma a jeho instalační média je možné stáhnout na webu společnosti Microsoft. Pokud organizace vlastní patřičné licence pro použití plné verze sql serveru (SQL 2005/2008 standard nebo enterprise), které neobsahují určitá omezení (max. velikost databáze a některé další) a naopak jsou rozšířeny o množství pokročilých funkcí pro zajištění maximální dostupnosti a co největšího výkonu. Díky tomu, že budeme využívat datové uložiště pro ukládání ověřovacích informací a aplikace by v případě výpadku SQL serveru byla tím pádem nedostupná, je nutné přihlédnout k tomu faktu při zvažování využití verze SQL Express (ostatní omezení nejsou pro toto řešení podstatná) 5. Po instalaci SQL serveru je nutné vytvořit databázi se strukturou, kterou vyžaduje provider. Dále je nutné provést konfiguraci ASP.NET aplikace, v našem případě platformu Sharepoint, tak aby využívala ASP.NET SQL autentizačního providera. Posledním krokem je vytvoření uživatelských účtů a nastavení jejich hesel. Pro tento účel můžeme využít několik nástrojů, ale primárně přepokládáme využití aplikace pro administraci uživatelů v rámci této diplomové práce Vytvoření DB pro ASP.NET SQL Membership autentizačního providera (18) K vytvoření schématu (struktury) databáze je možné využít nástroj Aspnet_regsql.exe. Je umístěn v podadresáři DOT NET frameworku v systémovém adresáři operačního systému Windows, kde jsou nainstalovány patřičné role pro provoz aplikací ASP.NET a IIS. Typicky je tato cesta: C:\WINDOWS\Microsoft.NET\Framework\versionNumber\. 5 Jelikož implementujeme ověřování pro platformu Microsoft Sharepoint, který vyžaduje také využití SQL serveru je většinou dán typ použitého SQL serveru přímo platformou, jelikož požadavky na datové uložiště a jeho vysokou dostupnost jsou dány přímo typem využití Microsoft Sharepointu. 24

33 Aspnet_regsql.exe se používá k vytvoření struktury (schématu) databáze tak také k přidávání nebo odebírání jednotlivých funkcí z existující databáze. Je možné využít tento program jak v příkazovém režimu a ovládat jej za pomocí parametrů nebo v grafickém režimu s uživatelským rozhraním. Mnou využívaná a popsaná a využívaná databáze má zapnuty všechny funkce ASP.NET membership, jejich základní přehled je uveden v následující tabulce. TABULKA 2 METODY ASP.NET SQL MEMBERSHIP PROVIDERA Funkce Membership Role management Profile Web Parts personalization Web events Popis Základní funkcionalita pro uložení uživatelů a hesel. Funkcionalita umožňující zařazování uživatelů do skupin (rolí), na které je možné následně použít pro různé úrovně zabezpečení aplikace. Umožňuje ukládat další informace o uživateli. Umožňuje personalizaci webových částí (nastavení jejich konfigurace pro jednotlivé uživatele). Umožňuje evidovat události webové aplikace Struktura DB pro.net SQL autentizačního providera Následující obrázek znázorňuje databázové schéma vytvořené databáze nástrojem Aspnet_regsql.exe. 25

34 OBRÁZEK 9 DATABÁZOVÉ SCHÉMA ASP.NET SQL MEMBERSHIP PROVIDERA Uložené procedury DB pro.net SQL autentizačního providera Vytvořená databáze obsahuje automaticky také uložené procedury (stored procedures) pro jednotlivé funkce a práci s databází. Tyto procedury jsou ve velice podobné struktuře jako jsou metody třídy ASP.NET membership což je poněkud zavádějící. Při počáteční analýze jsem předpokládal, že kompletní business logika je skryta v těchto procedurách a třída ASP.NET membership je pouze jejich zprostředkovatelem z prostředí ASP.NET. Při finální implementaci se tato domněnka nepotvrdila a až poměrně náročným zkoumáním jsem zjistil, že vlastní logika práce s daty je implementována nikoli v databázi, ale ve vlastní třídě ASP.NET membership a uložené procedury jsou pouze pro zprostředkování vlastního ukládání do databáze a navíc ani neobsahují kompletní obsluhu všech datových 26

35 entit a atributů a ani potřebné validace. Tyto skutečnosti nejsou z dokumentace na první pohled zřejmé a mohou výrazně ovlivnit návrh nástrojů pracujících s touto databází. 27

36 6 REŠERŠNÍ ZPRACOVÁNÍ EXISTUJÍCÍCH ŘEŠENÍ. Díky možnosti využití platformy Sharepoint využít různé autentizační metody a providery, je možné najít různá existující řešení podle toho, pro který typ autentizačního providera se jedná. 6.1 NÁSTROJE A DOPLŇKY PŘÍMO PRO PLATFORMU SHAREPOINT SHAREPOINT 2010 FBA PACK Tento produkt je vyvíjen jako open source pod Microsoft public Licencí. Jedná se o balíček pro formulářové ověřování pro platformu Sharepoint Obsahuje webové části pro registraci uživatelů, změnu a obnovu hesla a také nástroje pro správu uživatelů ověřovaných pomocí formuláře. Adresa projektu: PRODUKTY SPOLEČNOSTI SHAREPOINTBOOST Tato společnost nabízí několik komerčních produktů zabývajících se jednotlivými dílčími problémy identifikovanými v této práci orientovaných převážně na správu uživatelů definovaných v Active directory. SharePoint AD Administration - SharePoint AD Self Service - SharePoint Password Change & Reset Pack HAREPOINT PASSWORD CHANGE FOR SHAREPOINT Jedná se opět o komerční produkt, řešící jen problematiku změny a resetování hesel. Umožňuje uživateli změnu hesla. Podporuje všechny typy autentizace implementované platformou Sharepoint. Podporuje ovou notifikaci o blížícím se vypršení platnosti hesla BAMBOO SOLUTIONS ADMINISTRATION TOOLKIT Další komerční nástroje zabývající se problematikou administrace Sharepoint uživatelů Nabízející například tyto funkcionality: Změna hesla Vytvoření uživatelského účtu Resetování hesla Registraci uživatele Ukončení platnosti hesla 28

37 6.2 NÁSTROJE PRO ASP.NET MEMBERSHIP AUTENTIZAČNÍHO PROVIDERA. Díky tomu, že Sharepoint umožňuje využít autentizačního ASP membership providera, je možné pro správu takto ověřovaných uživatelů využít i nástroje určené pro platformu ASP THE ASP.NET WEB SITE ADMINISTRATION TOOL - WSAT Základním nástrojem pro správu uživatelů je webová aplikace implementovaná a dodávaná přímo jako součást.net Frameworku. Tato aplikace ale nenabízí potřebný komfort a její funkcionalita je velice omezená. Dokumentace k tomuto produktu je možné najít přímo na stránkách webu MSDN společnosti Microsoft THE MEMBERSHIP MANAGER CONTROL Jedná se o komerční produkt webové aplikace pro správu uživatelů ASP.NET s výrazně vyšším uživatelským komfortem MYWSAT Je webová aplikace pro správu uživatelů pro ASP.NET Membership providera. Je vyvíjena jako open source projekt pod GNU Library General Public licencí. 29

38 7 NÁVRH A SPECIFIKACE ROLÍ JEDNOTLIVÝCH ČÁSTÍ SYSTÉMU. Při provozu platformy Sharepoint je potřeba nejprve navrhnout jeho infrastrukturní potřeby a topologie. 7.1 INFRASTRUKTURA PRO PRODUKČNÍ PLATFORMU SHAREPOINT. Návrh základní infrastruktury pro provoz platformy Sharepoint v prostředí, kde uživatelé přistupují jak z vnějších sítí (internetu) tak z vnitřních sítí. Vlastní Sharepoint s databázovým serverem jsou odděleny v demilitarizované zóně, ostatní infrastrukturní služby, včetně aplikace pro správu uživatelů, jsou umístěny ve vnitřní síti. Internet Users Firewall Firewall/Router Users Sharepoint farm SQL Server DNS Administrator workstation Active Directory domain controller DMZ User management application OBRÁZEK 10 SCHÉMA NÁVRHU INFRASTRUKTURY SHAREPOINT Toto schéma je kompromisem mezi komplexností a mírou zabezpečení. Aplikace pro údržbu uživatelských účtů je vyčleněna z demilitarizované zóny a bude přistupovat pouze k databázi ASP.NET membership. Z vlastního prostředí platformy Sharepoint je možné omezit přístup k funkcím databáze, tak aby nebylo možné, ani v případě kompromitace vlastního serveru manipulovat s uživatelskými účty. Databáze s uživatelskými účty nemusí obsahovat hesla v reverzibilní podobě (záleží na vlastní konfiguraci administrační aplikace a ověřování uživatelů), takže případný narušitel není schopen zjistit uložená hesla, pouze jejich otisky (hashe). Uvedený návrh infrastruktury je jen jeden z mnoha scénářů a rozpracován pouze do základních kontur, které přímo ovlivňují návrh aplikace pro správu uživatelů a metody ověřování SCHÉMA SÍTOVÉ KOMUNIKACE Komunikace mezi jednotlivými celky je oddělena dvěma firewally. Komunikace z vnitřní sítě do DMZ je iniciována striktně ve směru vnitřní síť -> demilitarizovaná zóna. Komunikace z internetu je konfigurována pouze pomocí protokolu SSL, aby nebylo možné kompromitovat ověřovací hesla při přenosech dat po internetu. 30

39 Internet Users HTTPS Firewall/Router HTTP,HTTPS Users Firewall SQL Administrator workstation Sharepoint farm SQL Server User management application DNS DMZ Active Directory domain controller OBRÁZEK 11 SCHÉMA KOMUNIKACE A PROTOKOLŮ NÁVRH METOD OVĚŘOVÁNÍ JEDNOTLIVÝCH ČÁSTÍ SYSTÉMU Ověřování na straně farmy Sharepoint bude konfigurována do módu Claim based a bude využito ověřování pomocí formuláře. Dále bude nakonfigurován webový server (IIS) tak aby mohl využívat ASP.NET SQL membership providera, který bude využívat membership databázi na serveru SQL využívaných i pro další potřebné databáze. Ověřování uživatelů do Aplikace pro správu uživatelů může být nakonfigurováno např. pro využití integrovaného ověřování. Je možné využít i ostatní způsoby ověřování, ale integrované ověřování zajištěné pomocí active directory je dostatečně bezpečné a nevyžaduje další konfigurace. Také předpokládáme, že administrátor uživatelských účtů pro formu Sharepoint bude vnitřním zaměstnancem univerzity a bude tím pádem mít existující active directory účet. Aplikace pro modifikace v databázi SQL membership bude využívat tzv. conection string s uloženým jménem, heslem a typem uživatelského účtu SQL ve webové aplikaci. V případě, že by mělo fungovat integrované ověřování uživatele Aplikace pro správu uživatelů přímo proti SQL serveru, bylo by nutné SQL server i Sharepoint farmu umístit do stejné Active directory domény, nebo mezi domény vytvořit trust. Toto řešení se mi jeví jako velice komplikované a náročné na správu a nutí nás daleko více otevřít sítovou komunikaci mezi DMZ a vnitřní sítí. Tuto alternativní variantu nepovažuji z těchto důvodů za vhodnou VIRTUALIZACE PROSTŘEDÍ Navržené prostředí se nabízí virtualizovat některým z dostupných platforem. Při návrhu virtuálního prostředí je nutné vzít primárně v úvahu zatížení a role jednotlivých serverů. Principiálně jsou nejvhodnějšími kandidáty na provoz ve virtuálním prostředí všechny aplikační a webové servery. Vhodnost je potřeba primárně zvážit u databázového serveru (z důvodu diskové zátěže) a také u doménového řadiče, kde by mohlo dojít k problémům při startu celého prostředí, kde by měl být alespoň jeden doménový řadič v infrastruktuře dostupný před startem ostatních strojů. 7.2 INFRASTRUKTURA PRO TESTOVACÍ A VÝVOJOVÉ PROSTŘEDÍ Pro vývoj a testování je možné infrastrukturu výrazně zredukovat, jelikož není nutné klást důraz na zabezpečení a také je možné s výhodou využít již zmíněné možnosti virtualizace. 31

40 Virtuální infrastruktura Front-end Web Servers Aplication server Database server Active directory Domain Name Server Fyzická infrastruktura Virtualizační server OBRÁZEK 12 SCHÉMA NÁVRHU INFRASTRUKTURY SHAREPOINT PRO VÝVOJ 32

41 8 ANALÝZA A SPECIFIKACE POŽADAVKŮ NA APLIKACI PRO SPRÁVU UŽI- VATELŮ Jednou z částí diplomové práce je aplikace pro správu uživatelských účtů. Aplikace bude sloužit pro správu uživatelských účtů používaných ASP.NET membership SQL providerem. 8.1 SPECIFIKACE POŽADAVKŮ NEFUNKCIONÁLNÍ POŽADAVKY Základní nefunkcionální požadavky vyplývají ze zadání, ostatní jsou doplněny tak, aby aplikace zajistila přínos oproti standardním řešením: 1. Systém bude možné provozovat pro správu uživatelů pro prostředí Sharepoint Systém bude dostatečně robustní pro správu většího počtu uživatelů (odhadujeme pro nasazení v univerzitním prostřední min 100 a více). 3. Aplikace pro správu uživatelů by měla zajistit správu uživatelů nezávisle na platformě Sharepoint 4. Aplikace by měla oddělit správu uživatelů klientské aplikace a vlastní přístup k aplikaci. 5. Aplikace by měla moci spravovat i uživatele pro jiné systémy než platforma Sharepoint. 6. Aplikace by měla moci být provozována z webového prohlížeče FUNKCIONÁLNÍ POŽADAVKY Pro znázornění funkčních požadavků jsem použil diagramy případů užití. Pro přehlednost byly případy užití rozděleny do několika diagramů 6. Metody ASP.NET SQL Membership providera 6 případy užití aktéři a subsystémy se stejným názvem reprezentují tentýž objekt 33

42 Aplikace pro správu uživatelů - údržba uživatelů Uzamknout účet Odemknout účet Odemknout skupinu účtů Administrator Uzamknout skupinu účtů Vypsat všechny uživatele Resetovat heslo «subsystem» Databáze SQL Membership Odebrat uživatele Vyhledat uživatele Přidat uživatele Vypsat všechny role Aktualizovat atributy uživatele Vypsat všechny aplikace OBRÁZEK 13 DIAGRAM PŘÍPADU UŽITÍ - ÚDRŽBA UŽIVATELŮ 34

43 Aplikace pro správu uživatelů - údržba rolí Smazat roli Vyhledat uživatele v roli Vypsat všechny role Vypsat všechny aplikace «subsystem» Databáze SQL Membership Aktualizovat atributy role Administrator Přidat roli Vyhledat roli Vyhledat role aplikace OBRÁZEK 14 DIAGRAM PŘÍPADU UŽITÍ - ÚDRŽBA ROLÍ Aplikace pro správu uživatelů - údržba aplikací Vypsat všechny aplikace Vyhledat role aplikace Smazat aplikaci Administrator Vyhledat uživatele aplikace «subsystem»databáze SQL Membership Vyhledat aplikaci Přidat aplikaci Aktualizovat atributy aplikace OBRÁZEK 15 DIAGRAM PŘÍPADU UŽITÍ - ÚDRŽBA APLIKACÍ 35

44 Aplikace pro správu uživatelů - podpůrné procesy Odhlášení od aplikace «subsystem» Databáze SQL Membership Administrator Přihlášení do aplikace Změna hesla «subsystem» ASP.NET SQL Membership provider «subsystem» ASP.NET Membership «subsystem» ASP.NET Memebership provider «subsystem» Sharepoint OBRÁZEK 16 DIAGRAM PŘÍPADU UŽITÍ - PODPŮRNÉ PROCESY Sharepoint::Uživatel systému Sharepoint Microsoft Sharepoint - integrace Přihlášení Sharepoint uživatele «subsystem» Správa uživatelů::asp.net Membership Změna hesla Sharepoint uzivatele Uživatel systému Sharepoint OBRÁZEK 17 DIAGRAM PŘÍPADU UŽITÍ - OVĚŘENÍ UŽIVATELE SHAREPOINT TABULKA 3 AKTÉŘI POCESŮ Identifikovaní aktéři Administrátor Uživatel systému Sharepoint Popis uživatel administrujíc uživatelské účty uživatelů platformy Sharepoint autentizující se pomocí formbase autentizace Je uživatel technologicky zastoupený ASP.NET SQL providerem, využívající funkce pro přihlášení z prostředí Sharepoint. TABULKA 4 PŘÍPADY UŽITÍ Identifikované případy užití 36

45 Aktualizovat atributy aplikace Aktualizovat atributy role Aktualizovat atributy uživatele Odebrat uživatele Odemknout skupinu účtů Odemknout účet Odhlášení od aplikace Přidat aplikaci Přidat roli Přidat uživatele Přihlášení do aplikace Resetovat heslo Smazat aplikaci Smazat roli Uzamknout skupinu účtů Uzamknout účet Vyhledat aplikaci Vyhledat role aplikace Vyhledat roli Vyhledat uživatele Vyhledat uživatele aplikace Vyhledat uživatele v roli Vypsat všechny aplikace Vypsat všechny role Vypsat všechny uživatele Změna hesla Přihlášení Sharepoint uživatele Změna hesla Sharepoint uživatele Tyto identifikované případy užití budou sloužit pro vytvoření základních Akceptačních testovacích scénářů popsaných v kapitole DATOVÝ MODEL Datový model jednotlivých entit je dán ve své podstatě přímo databází ASP.NET SQL membership využívanou pro ověřování uživatelů na platformě Sharepoint. Její schéma bylo již uvedeno v kapitole DALŠÍ STANOVENÉ CÍLE Jedním z mých cílů stanovených před vyvinutím vlastní aplikace pro správu uživatelů bylo zachovat strukturu databáze bez jakéhokoli zásahu ve výchozí podobě, tak aby aplikace byla dostatečně univerzální a dala se použít pro správu uživatelů jakékoli aplikace, která využívá ASP.NET SQL membership providera. Jak ukázal vývoj, tento cíle nemohl být splněn z důvodů nekompatibility použitých nástrojů. Podrobné informace o příčinách jsou popsány dále. 37

46 9 POPIS IMPLEMENTACE Implementace se skládá z vývoje aplikace pro správu uživatelů a jeho implementace v navrženém a nakonfigurované prostředí Sharepoint. 9.1 VÝBĚR VÝVOJOVÉHO PROSTŘEDÍ PRO VYVÍJENOU APLIKACI Pro vývoj jsem zvolil Microsoft Visual studio 2010, které nativně podporuje vývoj aplikací pro Sharepoint a také umožňuje vytvářet webové aplikace pro Microsoft Windows server dále uvedených architekturních typů. 9.2 VÝBĚR ARCHITEKTURY ŘEŠENÍ Jak vyplynulo z nefunkcionálních požadavků, bude aplikace pro údržbu uživatelských účtů tvořena jako webová obsluhovaná z webového prohlížeče. Pro platformu Microsoft Windows se nabízí několik variant možné aplikační architektury a také různé programovací jazyky. Vzhledem k tomu, že nativní prostředí vývoje webových aplikací je Microsoft.NET framework a pro vývoj webových aplikací ASP.NET jsem u této volby zůstal. Prostředí ASP.NET umožňuje volbu programovacího jazyka Visual Basic a C#. V tomhle případě se kloním k volbě C#, který je syntakticky více příbuzný programovacím jazykům JAVA a C. Tato volba nijak neovlivňuje funkčnost, pracnost vývoje ani výkon, z tohoto pohledu jsou jazyky Visual Basic a C# téměř rovnocenné. Dalším důležitým rozhodnutím je vlastní architektura webové aplikace a uvnitř použitých frameworků. Microsoft Visual studio nabízí několik šablon pro tvorbu webových aplikací: ASP.NET ASP.NET MVC (Model-View-Controler) 7 ASP.NET Dynamic Data Entities Web Application ASP.NET Dynamic Data Linq to SQL Web Application Vzhledem k tomu, že mé zkušenosti s vývojem samostatných webových aplikací nebyly před začátkem tvorby aplikace nijak hluboké, vyzkoušel jsem základní funkce aplikace s propojením do Membership SQL databáze s podporou pouze ASP.NET a následně také v architektuře MVC a na základě tohoto testu jsem pro finální implementaci vybral architekturu ASP.NET MVC 3. Pro persistentní uložení dat jak již bylo naznačeno slouží databáze ASP.NET SQL membership. Pro oddělení databázové vrstvy a aplikační vrstvy jsem použit Microsoft Entity Framework, který umí na základě DB schématu vytvořit ekvivalentní typové objekty pro bezpečný a rychlý vývoj. Tento postup návrhu objektového modelu je znám jako tzv. Database-First Approach ARCHITEKTURA ASP.NET MVC Pro vývoj aplikace jsem využil ve finálním řešení MVC Framework verze 3, který umožňuje tvorbu webové aplikace na základě návrhového vzoru MVC. Tento vzor striktně odděluje datovou vrstvu (model) aplikace od její vizuální reprezentace (view) a také je oddělena výkonná a řídící část obsahující tzv. business logiku (controller). 7 ASP.NET MVC 3 je framework pro vytváření webových aplikací stažitelný zdarma ( jako doplněk do Microsoft Visual studia. 38

47 Po prostudování úvodních příkladů pro vytváření aplikací v tomto frameworku, jsem nabyl dojmu, že tvorba čisté a funkční aplikace bude velice snadná a přímočará. Framework umožňuje využití všech tří základních přístupů ke tvorbě modelu. Model first approach návrh aplikace začíná klasickým způsobem, nejprve tvorbo datového modelu nad kterým umožňuje entity framework vygenerovat třídy přímo v cílovém programovacím jazyku (C#). Code first approach vývoj aplikace začíná tvorbou datových tříd, které jsou následně použity persistentní vrstvou pro uložení, Většinou jsou data ukládána v pomocí relačního databázového stroje. Database first approach aplikace předpokládá již existující databázi, ze které je možné automaticky vygenerovat třídy v cílovém programovacím jazyku (C#), případně provést mapování atributů a také uložených procedur. Dále je nad takto získaným modelem možné vygenerovat základní kostru kontroleru, kde jsou již implementovány prototypy základních metody pro přístup a vytváření dat (CRUD). V dalším kroku je možné využít automatického generování uživatelského rozhraní pomocí tzv. scaffoldingu. V MVC frameworku verze 3 je možné využít dva různé zobrazovací stroje (Web form aspx a Razor). Razor generuje daleko čistější a jednodušší HTML kód, který je možné snadněji upravovat do finální zobrazované podoby pomocí kaskádních stylů CSS. Další výhody MVC jsou hlavně v jednodušším automatizovaném testování již při vlastním vývoji aplikace, tím se výrazně snižuje riziko chyb odhalených až při finalizaci aplikace a tím snížení nákladů na opravy odhalených chyb. Také se lépe pracuje s klientskými skripty pro validaci (javascript a jquery). 9.3 POPIS JEDNOTLIVÝCH ČÁSTÍ PROJEKTU APLIKACE Finální varianta aplikace byla vytvořena ve Visual studiu 2010 na základě šablony projektu ASP.NET MVC 3, kde byl základní model vygenerován z databáze ASP.NET SQL membership ČLENĚNÍ PROJEKTU Aplikace pro správu uživatelů je obsažena v jedné Visual studio solution MembershipUser- Management.MVC, která obsahuje jeden Visual studio projekt MembershipUserManagement.MVC. Modely (models) Projekt obsahuje dva modely jeden generovaný automaticky ze šablony pro autentizaci uživatelů do vlastní aplikace (AccountModels.cs). Druhý model byl vytvořen z databáze ASP.NET SQL membership se zapnutou kompletní funkčností. 39

48 OBRÁZEK 18 SCHÉMA MODELU "MEMBERSHIPMODEL" V PROJEKTU Na základě uvedeného modelu Entity framework automaticky generuje tzv. POCO 8 třídy pro jednotlivé entity a dále kontext pro práci s perzistentním uložištěm, kterým je v mém případě Micro- 8 Plain Old CLR Object or POCO je podobný termínu POJO známým ze světa programovacího jazyka Java. Tento termín se používá v kontrastu jednoduchého objektu používaného komplikovanými specializovanými objekty frameworků, jako jsou například ORM komponenty 40

49 soft SQL databáze. Tato konstrukce umožňuje výrazně jednodušší testování již při vlastním vývoji, jelikož je možné pro testování podstrčit (injektovat) místo perzistentního uložiště testovací vrstvu. Entitní třídy jsou typu POCO a můžeme s nimi tedy pracovat klasickým způsobem včetně automatizovaného testování. Nicméně jsem tento režim testování v projektu nevyužil, jelikož jsem teprve nabýval zkušenosti s vývojem tohoto typu webových aplikací a automatizovaným testováním. Kontroléry (controlers) V rámci aplikace jsou obsluhovány pouze níže uvedené entity, pro které jsou vytvořeny jednotlivé kontroléry. o o o o ApplicationController.cs kontrolér pro správu aplikací (aspnet_applications) PathController.cs kontrolér pro správu spravovaných cest (aspnet_paths) RoleController.cs kontrolér pro správu uživatelských rolí (aspnet_roles) UserController.cs kontroler pro správu vlastních uživatelských účtů (aspnet_membership, aspnet_users) Dále existují ještě dva kontroléry generované samotnou šablonou projektu. o o AccountController.cs jedná se automaticky generovaný kontrolér daný šablonou projektu, který obsluhuje přihlašování do vlastní aplikace. HomeController.cs kontrolér pro obsluhu nápovědy a úvodní stránky aplikace Pohledy (views) Jednotlivé pohledy jsou strukturovány do složek, které odpovídají jednotlivým kontrolérům. Každá takováto složka obsahuje typicky 5 základní pohledů, jeden přehledový (index) a dále každý pro základní CRUD operace (create, read pojmenován detail, update pojmenován edit,delete). Dále je vytvořena složka Shared pro sdílené části webových stran (partial views). Textové zdroje (resources) Celý aplikace je navržena jako lokalizovatelná. Všechny použité textové zdroje jsou umístěny v res souborech a pro přehlednost jsou soustředěny v samostatné složce Resources, kde jsou dále členěny podle toho, k jaké části aplikace patří (model, view, controller). Každý z res souborů má specifikován svůj jmenný prostor, aby nedocházelo k možným duplicitám, či záměnám. Ostatní složky a prvky o Složka Content obsahuje části týkající se grafických témat a kaskádních stylů. V rámci projektu byl využit předdefinovaný design aplikace a výchozí CSS 41

50 o o o o styly. Vzhledem k čistotě generovaného HTML kódu ASP.MVC Frameworku, je možné velice jednoduchým způsobem brandovat či měnit design celé aplikace. Složka Scripts obsahuje Javascripty a JQuery skripty používané na klientské straně zejména pro validaci. Složka Utilities Soubor Global.asax se stará v prostředí ASP MVC frameworku o virtuální mapování adresního prostoru URL adres na patřičné části aplikace. Soubor Web.config obsahuje konfiguraci webové aplikace potřebnou pro provoz v Internet Information serveru DATABÁZE Základem databáze je schéma generované pomocí utility Aspnet_regsql.exe využívané pro správu uživatelů ASP aplikací. Dle původního záměru bylo vytvořit aplikaci tak, aby nebylo nutné již do vygenerovaného schématu zasahovat, nicméně po delších pokusech a ladění jsem byl nucen zasáhnout, kvůli problémům použitím nekompatibilních návratových kódů z uložených procedur. Microsoft Entity Framework podporuje návratové hodnoty, vracené pouze metodou SELECT nikoli RETURN, jak je tomu u uložených procedur v databázi ASP.NET Membership. Díky tomuto omezení jsem byl nucen některé uložené procedury duplikovat a změnit v nich ukládání návratových hodnot. Toto bylo učiněno pouze u procedur, kde měly návratové hodnoty (chyby) zásadnější význam. Tyto změny je nutné provést pomocí SQL scriptů přiložených v projektu. Všechny změny ve schématu databáze jsou provedeny tak, aby původní funkcionalita a využití pro univerzálního ASP.SQL membership providera zůstala zachována LOKALIZACE Celý projekt jsem tvořil jako plně lokalizovatelný, všechny textové řetězce jsou striktně odděleny v samostatných resource souborech. Jako základní jazyk je volena angličtina. Aplikace v tuto chvíli (kromě několika testovacích resourců) neobsahuje žádné další jazykové mutace. Byl rozšířen standardní MVC route handler umožňující přepínat jednotlivé jazykové mutace pomocí na základě virtuální cesty v URL využívané aplikace UŽIVATELSKÉ ROZHRANÍ A DESIGN Design je plně oddělen od aplikace a je možné ho pomocí témat a kaskádních stylů kdykoli modifikovat bez zásahu do vlastní aplikace. Pro aplikaci byl použit základní styl vytvořený přímo pomocí šablony projektu. Pro pohodlnou práci v uživatelském rozhraní byl použit vestavěný helper pro zobrazení datagridu s možností stránkování a změnou řazení dle jednotlivých sloupců. Při přechodu z přehledových stánek s datagridem do editačního nebo detailního režimu byl implementováno předávání aktuální konfigurace datagridu (třídění a stránkování) pomocí quuery stringu, tak aby jednotlivé stránky byly striktně bez stavové a přitom při přechodu mezi nimi byl zachován uživatelský komfort a kontinuita. 42

51 9.4 NASAZENÍ ŘEŠENÍ V LABORATORNÍM PROSTŘEDÍ V laboratorním prostředí jsem s výhodou použil virtualizační technologie a testovací server je provozován ve virtuálním prostředí. Vzhledem k tomu, že nejvíce využívám virtualizační platformu VMWare použil jsem k tomuto účelu software VMWare Workstation build Jedná se o licencovanou verzi, nicméně je možné využít i jiné virtualizační platformy, které jsou k dispozici zdarma 9. Testovací a vývojové prostředí jsem hostoval na notebooku Lenovo T400 (procesor Intel core 2 duo T9400, operační paměť 8GB, disky 150 GB systémový, 300GB datový). Hostující operační systém je Microsoft Windows 7 Enterprise 64 bitová edice. Neuvádím zde kompletní kroky Instalace a konfigurace celého Sharepoint prostředí, jelikož se jedná o běžně dostupné postupy na internetu např. SharePoint Step by Step Install publikovaný na ACS Blogu ( _2D00_-Step-by-Step-Install.aspx) INSTALACE INFRASTRUKTURNÍCH SERVERŮ Celé prostředí je nainstalováno a testováno na serveru s těmito parametry: HW parametry: Operační paměť: Procesor: Disk: SW parametry: 4GB 2 Jádra 50 GB Operační systém: Microsoft Windows 2008 server standard R2 anglická verze Aplikační role: DNS server, Řadič Active directory, Aplikační server, Webový server, Souborový server Vývojové nástroje Microsoft Visual studio 2010 premium Databázový server Microsoft SQL server 2008 Enterprise Edice 64 bit verze Ostatní nástroje VMWare tools Microsoft Framework 4 Microsoft EntityFramework41.exe Microsoft Internet Explorer v 8 a vyšší INSTALACE SHAREPOINT FARMY Sharepoint server je instalován jako Farm instalace, tzn. je možné jej případně rozšířit o další servery a databázový server není přímo součástí této instalace, ale pro vývojové prostředí je instalován a hostován na stejném serveru. Tento typ instalace je výrazně výhodnější, jelikož je možné farmu v budoucnu libovolně rozšiřovat o další servery a jednotlivé aplikační role na tyto servery rozdělovat. 9 Např. VMWare player nebo VirtualBox 43

52 9.4.3 VYTVOŘENÍ SHAREPOINT FARMY Vlastní Sharepoint farma se vytváří pomocí průvodce SharePoint 2010 Products Configuration Wizard, kde volíme vytvoření nové farmy a nastavíme přístup k databázovému serveru. A následně průvodce vytvoří v několika krocích kompletně novou Sharepoint farmu. Dalším krokem je vytvoření webové aplikace, která bude hostovat naše prostředí. Vytvoření webové aplikace provádíme v centrální administraci Sharepoint, kterou vytvořil configuration wizard pomocí webového prohlížeče. Konfiguraci ověřování, jež je součástí tvorby webové aplikace doporučuji nejprve nechat ve výchozím stavu a úpravy provést až po ověření plné funkčnosti webové aplikace. Posledním krokem je vytvoření Kolekce webů, opět pomocí centrální administrace. Při tvorbě kolekce webů je nutné vybrat šablonu, na základě které se nám vytvoří obsah webu a také zadat jméno administrátora této kolekce. Pokud se nám podařilo úspěšně vytvořit a otevřít pomocí webového prohlížeče právě vytvořený web, můžeme přistoupit rekonfiguraci metod ověřování KONFIGURACE OVĚŘOVÁNÍ (19) Konfiguraci na základě analýzy a návrhu celého řešení přepneme ověřování webové aplikace do módu Claim Based a povolíme ověřování pomocí formulářů (Form Based Authentication). Tato konfigurace vyžaduje 3 základní kroky: 1. Přepnutí webové aplikace do módu Claim Based 2. Vytvoření databáze pro ukládání uživatelských účtů (při vytváření databáze je potřeba mít zapnuty all features ) 3. Modifikace konfiguračních souborů hostující webové aplikace IIS Celý postup je opět uveden na internetu např. na webu Another Sharepoint Blog - Configure Forms Based Authentication (FBA) with SharePoint INSTALACE APLIKACE PRO SPRÁVU UŽIVATELŮ Aplikace pro správu uživatelů je nasazována pomocí vytvořeného balíčku. Nasazení je možné pomocí instalačního souboru MembershipUserManagement.MVC.deploy.cmd, nebo pomocí GUI Internet Information services manažeru. 1. Vyberte nebo vytvořte cílovou webovou aplikaci, která bude hostovat aplikaci pro správu uživatelů v konsole IIS, ověřte, že tato Vámi Application pool použité webová aplikace má povolen.net framework verze 4. a managed pipeline mode Integrated. 2. Spusťte volbu import Application ve vybrané webové aplikaci 3. Vyberte cestu k instalačnímu balíčku MembershipUserManagement.MVC.zip aplikace na pevném disku. 4. V dalším kroku specifikujte jméno webové aplikace a upravte connection string pro aspnetdbentities zadejte správné jméno Vámi používaného SQL serveru, a uživatelské 44

53 jméno a heslo uživatele, který je vlastníkem připravené databáze ASP.NET Sql membership Dokončete průvodce a na vytvořené webové aplikaci povolte způsob ověřování Windows (Windows authentication) a zakažte anonymní (Anonymous authentication) pro integrované přihlášení. 6. Spusťte SQL script pro úpravu databázového schématu již vytvořené ASP.NET Memebership databázi. 7. Ověřte funkčnost nainstalované aplikace ve webovém prohlížeči NASTAVENÍ OPRÁVNĚNÍ PRO UŽIVATELE Nyní již zbývá poslední ověřovací krok. Je potřeba vytvořit v aplikaci pro správu uživatelů vytvořit testovacího uživatele a nastavit mu oprávnění ve dříve vytvořené kolekci webů. 1. Spusťte aplikaci pro správu uživatelů a přihlaste se. Pokud využíváte integrovanou autentizaci Windows a nedošlo k automatickému přihlášení, ověřte nastavení webového prohlížeče Internet Explorer a jeho zabezpečení (výchozí nastavení umožňuje použít integrované autentizace pro Trusted sites a Local Intranet ). 2. Zvolte z navigačního menu volbu Users a vytvořte nového uživatele. Application name zvolte / a password format Clear nebo Hashed 3. Ve webovém prohlížeči otevřete Centrální administraci Sharepoint, v části Application management a Change site collection administrators a přidejte jako administrátora dříve vytvořené kolekci webů nově vytvořeného testovacího uživatele. 4. Ve webovém prohlížeči otevřete připravenou kolekci webů a přihlaste se pomocí vytvořeného testovacího uživatele. 10 V případě, že nebudete pro ověřování přístupu do aplikace pro správu uživatelů je potřeba upravit i připojovací řetězec Application Services 45

54 9.5 UKÁZKY UŽIVATELSKÉHO ROZHRANÍ APLIKACE OBRÁZEK 19 UKÁZKA PŘEHLEDU UŽIVATELŮ OBRÁZEK 20 UKÁZKA PŘEHLEDU APLIKACÍ 46