Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. fragmentů textu

Za´padoˇceska´ univerzita v Plzni Fakulta aplikovanyćh vˇed Katedra informatiky a vy´poˇcetn´ı techniky

Diplomov´ a pr´ ace Sestavov´ an´ı dokument˚ uz fragment˚ u textu

Plzeˇ n, 2013

Bc. Jan Rabuˇsic

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem diplomovou práci vypracoval samostatnˇe a v´ yhradnˇe s pouˇzit´ım citovan´ ych pramen˚ u. V Plzni dne 8. kvˇetna 2013 Bc. Jan Rabuˇsic

Podˇ ekov´ an´ı Na tomto m´ıstˇe bych chtˇel podˇekovat Ing. Martinovi B´ıklovi za ˇcas vˇenovan´ y konzultac´ım a cenné rady, bez kter´ ych by tato práce nemohla vzniknout. Také bych chtˇel podˇekovat vˇsem bl´ızk´ ym, kteˇr´ı se mnou mˇeli bˇehem mé tvorby nesm´ırnou trpˇelivost.

Abstrakt C´ılem práce je nalézt formát dokument˚ u, kter´ y je vhodn´ y pro automatizované vytváˇren´ı dokument˚ u s moˇznost´ı doplˇ nován´ı zadan´ ych informac´ı, opatˇrován´ı elektronick´ ym podpisem a ˇcasov´ ym raz´ıtkem a je vhodn´ y pro uˇzit´ı v podnikovém prostˇred´ı. Tato práce zahrnuje v´ ybˇer formátu, anal´ yzu a implementaci ˇreˇsen´ı automatizovaného vytváˇren´ı a opatˇrován´ı elektronick´ ym podpisem a ˇcasov´ ym raz´ıtkem. Integrace ˇreˇsen´ı do systému Microsft SharePoint 2010 demonstruje vyuˇzit´ı zvoleného ˇreˇsen´ı. Práce hodnot´ı právn´ı platnost a v´ yznam elektronick´ ych podpis˚ u a ˇcasov´ ych raz´ıtek.

Abstract The aim of the work is to find a document format that is suitable for automatic document composition with filling the entered information, obtaining electronic signature and time stamp and is suitable for use in a corporate environment. The work includes analysis and implementation of solution for automatic creation and obtaining electronic the signature and the time stamp. Integration of the solution into the Microsoft SharePoint 2010 demonstrates the use of the solution. Thesis evaluates the juristic validity and importance of electronic signatures and time stamps.

Obsah ´ 1 Uvod 1.1 Pozad´ı problému . . . . . . 1.1.1 Správa dokument˚ u . 1.1.2 D˚ uvod vzniku práce 1.2 Pˇrehled práce . . . . . . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

2 Form´ aty sloˇ zen´ ych textov´ ych dokument˚ u 2.1 Kritéria formátu sloˇzeného dokumentu . . 2.1.1 Dostupnost . . . . . . . . . . . . . 2.1.2 Automatické vytváˇren´ı dokumentu 2.1.3 Archivace . . . . . . . . . . . . . . 2.2 Zkoumané modely . . . . . . . . . . . . . . 2.3 Portable Document Format . . . . . . . . 2.3.1 Struktura PDF . . . . . . . . . . . 2.3.2 Vytváˇren´ı PDF . . . . . . . . . . . 2.3.3 Shrnut´ı PDF . . . . . . . . . . . . 2.4 Office Open XML . . . . . . . . . . . . . . 2.4.1 Struktura OOXML . . . . . . . . . 2.4.2 Tvorba OOXML . . . . . . . . . . 2.4.3 Shrnut´ı OOXML . . . . . . . . . . 2.5 OpenDocument . . . . . . . . . . . . . . . 2.5.1 Struktura ODF . . . . . . . . . . . 2.5.2 Tvorba ODF . . . . . . . . . . . . 2.5.3 Shrnut´ı ODF . . . . . . . . . . . . 2.6 XSL-FO . . . . . . . . . . . . . . . . . . . 2.6.1 Struktura XSL-FO . . . . . . . . . 2.6.2 Tvorba XSL-FO . . . . . . . . . . . 2.6.3 Shrnut´ı XSL-FO . . . . . . . . . . 2.7 Rich Text Format . . . . . . . . . . . . . 2.7.1 Struktura RTF . . . . . . . . . . . 2.7.2 Tvorba RTF . . . . . . . . . . . . .

. . . .

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

. . . .

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

. . . .

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

. . . .

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

. . . .

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

. . . .

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

. . . .

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

. . . .

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

. . . .

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

. . . .

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

. . . .

1 1 1 2 2

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

3 3 3 3 4 4 5 5 6 7 7 8 9 12 12 13 14 14 15 16 16 17 17 18 19

2.7.3

Shrnut´ı RTF

. . . . . . . . . . . . . . . . . . . . . . . 20

3 Elektronick´ e podpisy a ˇ casov´ a raz´ıtka 3.1 Základn´ı pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Princip elektronického podpisu . . . . . . . . . . . . . . . . . 3.2.1 Proces podepisován´ı . . . . . . . . . . . . . . . . . . . 3.2.2 Proces ovˇeˇrován´ı . . . . . . . . . . . . . . . . . . . . . 3.3 Proces ovˇeˇrován´ı . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 Platnost elektronického podpisu . . . . . . . . . . . . . . . . . 3.4.1 Nezpochybnitelnost . . . . . . . . . . . . . . . . . . . . 3.4.2 Okamˇzik posuzován´ı platnosti podpisu . . . . . . . . . ˇ 3.4.3 Casov´ e raz´ıtko a kvalifikované ˇcasové raz´ıtko . . . . . . 3.4.4 Revokace certifikátu a jej´ı vyhodnocen´ı pˇri ovˇeˇrován´ı podpisu . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Postup ovˇeˇrován´ı podpisu . . . . . . . . . . . . . . . . . . . . 3.6 Elektronick´ y podpis v praxi . . . . . . . . . . . . . . . . . . . 3.6.1 Odpovˇednost za ˇskodu . . . . . . . . . . . . . . . . . . 3.6.2 Souˇcasn´ y stav podpory elektronick´ ych podpis˚ u v aplikac´ıch . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7 Formáty pokroˇcil´ ych el. podpis˚ u . . . . . . . . . . . . . . . . . 3.7.1 Pˇrehled . . . . . . . . . . . . . . . . . . . . . . . . . . 3.7.2 XAdES . . . . . . . . . . . . . . . . . . . . . . . . . .

21 21 22 22 22 23 23 23 24 24 25 26 27 27 28 28 28 29

4 Syst´ em spr´ avy dokument˚ u Microsoft SharePoint 32 4.1 Pˇrehled sluˇzby . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.2 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.3 Word Automation Services . . . . . . . . . . . . . . . . . . . . 33 5 Anal´ yza 5.1 Formáty sloˇzen´ ych dokument˚ u . . . . . . . . . 5.1.1 PDF . . . . . . . . . . . . . . . . . . . 5.1.2 OOXML . . . . . . . . . . . . . . . . . 5.1.3 ODF . . . . . . . . . . . . . . . . . . . 5.1.4 XSL-FO . . . . . . . . . . . . . . . . . 5.1.5 RTF . . . . . . . . . . . . . . . . . . . 5.1.6 Porovnán´ı . . . . . . . . . . . . . . . . 5.1.7 V´ ybˇer . . . . . . . . . . . . . . . . . . 5.2 Kritéria aplikace . . . . . . . . . . . . . . . . 5.2.1 Platforma .NET . . . . . . . . . . . . . 5.2.2 Nezávislost datov´ ych zdroj˚ u . . . . . . 5.2.3 Modularita jednotliv´ ych ˇcást´ı aplikace

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

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

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

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

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

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

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

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

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

35 35 35 36 36 37 37 38 38 39 39 39 39

5.2.4

Integrace aplikace do systému správy dokument˚ u . . . 40

6 Z´ akladn´ı aplikace – MergeSignModul 6.1 Architektura . . . . . . . . . . . . . . . . . 6.1.1 Kontext aplikace . . . . . . . . . . 6.1.2 Struktura modulu . . . . . . . . . . 6.1.3 Pˇredáván´ı dat a odst´ınˇen´ı datov´ ych 6.1.4 Pˇrehled tˇr´ıd . . . . . . . . . . . . . 6.2 Implementace . . . . . . . . . . . . . . . . 6.2.1 Tˇr´ıda MFSManager . . . . . . . . . 6.2.2 Tˇr´ıda AltChunkMergeService . . . 6.2.3 Tˇr´ıda PTMergeService . . . . . . . 6.2.4 Tˇr´ıda SimpleFillService . . . . . . . 6.2.5 Tˇr´ıda SimpleTagsLoader . . . . . . 6.2.6 Tˇr´ıda XmlDsigService . . . . . . . 6.2.7 Tˇr´ıda XadesService . . . . . . . . . 6.2.8 Logován´ı modulu . . . . . . . . . . 6.2.9 Konfigurace modulu . . . . . . . . 7 Pomocn´ e aplikace 7.1 MergeSignModulConfig . . . 7.2 MergeSignApp . . . . . . . . 7.3 XadesVerifyTool . . . . . . . 7.4 TestTimeToOpenDocument

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . . . . . . . . . . zdroj˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . .

. . . .

8 Integrace Modulu 8.1 Návrh integrace . . . . . . . . . . . . . . . . . 8.2 Pouˇzit´ı SharePoint 2010 SDK . . . . . . . . . 8.3 Implementace UI a kontroloru . . . . . . . . . 8.3.1 Poloˇzka kontextového menu . . . . . . 8.3.2 Modáln´ı dialogové okno . . . . . . . . 8.4 Zmˇeny v modulu oproti základn´ı implementaci 8.4.1 Logován´ı modulu . . . . . . . . . . . . 8.4.2 Konfigurace modulu . . . . . . . . . . 8.4.3 IfillService . . . . . . . . . . . . . . . . ´ ziˇstˇe digitáln´ıch certifikát˚ 8.4.4 Uloˇ u . . . . . 8.5 V´ ysledek integrace . . . . . . . . . . . . . . .

. . . .

. . . . . . . . . . .

. . . .

. . . . . . . . . . .

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

. . . .

. . . . . . . . . . .

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

. . . .

. . . . . . . . . . .

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

. . . .

. . . . . . . . . . .

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

. . . .

. . . . . . . . . . .

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

. . . .

. . . . . . . . . . .

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

. . . .

. . . . . . . . . . .

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

41 41 41 41 42 43 43 43 43 45 45 46 46 46 47 47

. . . .

48 48 48 51 51

. . . . . . . . . . .

53 53 54 56 56 57 59 59 59 60 60 60

9 Porovn´ an´ı metod skl´ ad´ an´ı 61 9.1 Doba bˇehu a v´ ysledná velikost souboru . . . . . . . . . . . . . 62 9.2 Doba otev´ırán´ı dokumentu . . . . . . . . . . . . . . . . . . . . 64

9.3

Závˇery porovnán´ı . . . . . . . . . . . . . . . . . . . . . . . . . 65

10 Pˇ r´ınos implementace el. podpisu a ˇ casov´ ych raz´ıtek 66 10.1 XmlDsigService . . . . . . . . . . . . . . . . . . . . . . . . . . 66 10.2 XadesService . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 11 Z´ avˇ er A Pˇ r´ıloha - Uˇ zivatelsk´ a dokumentace A.1 MergeSignApp . . . . . . . . . . . . . . A.2 XadesVerifyTool . . . . . . . . . . . . . A.3 TestTimeToOpenDocument . . . . . . A.4 SPMergeSign . . . . . . . . . . . . . . A.4.1 Instalace SharePoint serveru . . A.4.2 Nasazen´ı ˇreˇsen´ı . . . . . . . . . A.4.3 Ovládán´ı SPMergeSign . . . . . A.4.4 Nastaven´ı podpisu SPMergeSign

70

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

74 74 74 74 75 75 76 77 77

B Pˇ r´ıloha - XSD 79 B.1 Config.xsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 B.2 Params.xsd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 C Pˇ r´ıloha - Grafy

81

´ 1 Uvod 1.1

Pozad´ı probl´ emu

Téma této diplomové práce bylo zadáno spoleˇcnost´ı CCA Group a.s. se s´ıdlem Karlovo námˇest´ı 17, 120 00 Praha 2, dále jen CCA Group.

1.1.1

Spr´ ava dokument˚ u

V posledn´ı dobˇe roste neb´ yvalou mˇerou mnoˇzstv´ı elektronick´ ych dokument˚ u. D˚ uvodem je stále vˇetˇs´ı objem elektronické komunikace a postupn´ y trend opouˇstˇen´ı pap´ırov´ ych dokument˚ u. Podle Cite World (www.citeworld.com) bylo v roce 2012 odesláno 89 miliard firemn´ıch e-mail˚ u dennˇe. Odhaduje se, ˇze do roku 2016 vzroste poˇcet tˇechto e-mail˚ u na 143,8 miliard dennˇe.[1] Oˇcekává se tedy témˇeˇr dvojnásobn´ y objem komunikace prostˇrednictv´ım e-mailu. Detailnˇejˇs´ı pr˚ uzkum spoleˇcnosti Radicati nab´ız´ı v´ yvoj pr˚ umˇerného poˇctu obdrˇzen´ ych e-mail˚ u pr˚ umˇerného firemn´ıho uˇzivatele za den. V roce 2011 to bylo 72 e-mail˚ u za den. Pokud nebudeme poˇc´ıtat nevyˇza´danou poˇstu, pak to bylo 58 e-mail˚ u za den. Oˇcekává se, ˇze v roce 2016 to bude 71 e-mail˚ u dennˇe bez nevyˇza´dané poˇsty.[2] Kromˇe objemu elektronické komunikace roste poˇcet digitalizovan´ ych dokument˚ u i v jin´ ych oblastech. Zaveden´ım legislativy ˇ e republice (Zákon ˇc. 227/2000 Sb.) a podk elektronickému podpisu v Cesk´ porou elektronizace státn´ı správy (e-Government) se firmám otev´ırá dalˇs´ı oblast, ze které lze oˇcekávat nár˚ ust objemu elektronick´ ych dokument˚ u. Správa dokument˚ u se zamˇeˇruje na ukládán´ı a uspoˇrádán´ı dokument˚ u s c´ılem ” podporovat aktuálnˇe rozpracovanou práci“[3]. To zahrnuje pˇredevˇs´ım vytvá´ cel je zˇrejm´ ˇren´ı a sd´ılen´ı obsahu. Uˇ y – kdyˇz organizace nevyuˇz´ıvá ˇzádn´ y systém správy dokument˚ u, obsah se zpravidla vytváˇr´ı a ukládá neuspoˇra´danˇe a decentralizovanˇe. To vede k ˇcasté redundanci informac´ı, neschopnosti efektivnˇe vyhledávat ve firemn´ıch dokumentech, spolupracovat na vytváˇren´ı obsahu a jeho hromadnému uˇz´ıván´ı.[3] ˇ e republice. Potvrzuje to i Tato problematika je aktuáln´ım tématem i v Cesk´ IT internetov´ y portál SystemOnLine.cz, kter´ y uvád´ı, ˇze nezbytnost nasazen´ı DMS a zjevn´ y zájem hlavnˇe vˇetˇs´ıch firem dokazuje intern´ı pr˚ uzkum spoleˇc1

´ Uvod

Pˇrehled práce

nosti Infinity z ledna roku 2012, kter´ y uskuteˇcnila ve 130 stˇrednˇe velk´ ych a velk´ ych ˇcesk´ ych firmách. Podle tohoto pr˚ uzkumu aˇz 44% firem hodnot´ı problematiku správy dokument˚ u jako kl´ıˇcovou.[4]

1.1.2

D˚ uvod vzniku pr´ ace

Zámˇer spoleˇcnosti CCA Group nab´ızet systémy pro správu dokument˚ u vyˇzaduje pr˚ uzkum souˇcasného stavu dokumentov´ ych formát˚ u, moˇznosti jejich vyuˇzit´ı a m´ıry jejich podpory. Z tohoto d˚ uvodu vznikla práce, která má za u ´kol prozkoumat tento stav, vybrat dokumentov´ y formát vhodn´ y k podporován´ı a vyzkouˇset práci s n´ım na základn´ıch operac´ıch (skládán´ı dokument˚ u, jejich podepisován´ı) v desktopové aplikaci a pˇr´ıpadnˇe jej´ı integraci do jiˇz existuj´ıc´ıho DMS systému (SharePoint). Zároveˇ n vyˇzaduje pr˚ uzkum z hlediska platnosti elektronick´ ych podpis˚ u.

1.2

Pˇ rehled pr´ ace

V teoretické ˇcásti se budu vˇenovat srovnán´ı jednotliv´ ych textov´ ych dokumentov´ ych formát˚ u, teorii elektronick´ ych podpis˚ u a ˇcasov´ ych raz´ıtek vˇcetnˇe kontextu ˇceské legislativy a pˇredstaven´ı v´ yvoje modul˚ u pro systém správy dokument˚ u Microsoft SharePoint. V praktické ˇca´sti provedu anal´ yzu poˇzadavk˚ u na dokumentov´ y formát. Na základˇe srovnán´ı dokumentov´ ych formát˚ u provedeného v teoretické ˇca´sti vyberu, kter´ y dokumentov´ y formát podporovat. Navrhnu a naimplementuji aplikaci pro skládán´ı dokument˚ u, jejich plnˇen´ı a podepisován´ı tak, aby byla s co nejmenˇs´ım mnoˇzstv´ım u ´prav pouˇzitelná jako serverové ˇreˇsen´ı, respektive integrovatelná do systému Microsoft SharePoint. Následnˇe ji do tohoto systému ve formˇe monolitického ˇreˇsen´ı zakomponuji. ˇ sen´ı otestuji a ohodnot´ım z hlediska v´ Reˇ ykonu. Na závˇer zhodnot´ım zp˚ usob ˇreˇsen´ı elektronick´ ych podpis˚ u ve formátu Office Open XML.

2

2 Formáty sloˇzených textových dokument˚ u Jedn´ım z u ´kol˚ u je urˇcit formát dokument˚ u, kter´ y je vhodné pouˇz´ıvat v oblasti podnikov´ ych informaˇcn´ıch systém˚ u. Pro tento u ´ˇcel pˇredstav´ım vybrané dokumenty se zamˇeˇren´ım na tˇri hlavn´ı kritéria.

2.1

Krit´ eria form´ atu sloˇ zen´ eho dokumentu

Z reáln´ ych poˇzadavk˚ u zákazn´ık˚ u a standard˚ u kladen´ ych na správu dokument˚ u lze odvodit nˇekolik hlavn´ıch kritéri´ı, které mus´ı sloˇzené formáty dokument˚ u splnit.

2.1.1

Dostupnost

Primárn´ım poˇzadavkem na formát dokumentu je, aby byl ˇsiroce dostupn´ y veˇrejnosti, tedy aby se nejednalo o proprietárn´ı formát, jehoˇz specifikace nen´ı známá, a tak aby zákazn´ıka pro práci s n´ım nic nevázalo k pouˇz´ıván´ı konkrétn´ı aplikace. To plat´ı bez v´ yjimky pro firemn´ı dokumenty. Aˇckoliv by bylo moˇzné zavést proprietárn´ı dokumentov´ y formát uvnitˇr podniku, mus´ıme poˇc´ıtat s t´ım, ˇze dokumenty nejsou vázány pouze na podnikové prostˇred´ı, ale jejich prostˇrednictv´ım prob´ıhá interakce s okol´ım (jiné organizace, státn´ı správa a dalˇs´ı). Zde bychom naráˇzeli na problémy s akceptac´ı takov´ ych dokument˚ u.

2.1.2

Automatick´ e vytv´ aˇ ren´ı dokumentu

Dalˇs´ım poˇzadavkem je, aby existovala nekomerˇcn´ı knihovna, která by znaˇcnˇe usnadnila práci s t´ımto formátem. Pˇrináˇsela by moˇznost skládat dokument z menˇs´ıch definovan´ ych celk˚ u – ˇsablon, které by umoˇzn ˇovala následnˇe plnit textov´ ymi fragmenty.

3

Formáty sloˇzených textových dokument˚ u

2.1.3

Zkoumané modely

Archivace

Posledn´ım hlavn´ım poˇzadavkem je, aby struktura dokumentu podporovala, nebo alespoˇ n umoˇzn ˇovala pˇripojován´ı elektronick´ ych podpis˚ u a ˇcasov´ ych raz´ıtek, d˚ uleˇzit´ ych pro archivaci.

2.2

Zkouman´ e modely

Jiˇz podle kritéria 2.1.1, které klade d˚ uraz na otevˇrenost formátu, mohu mezi porovnávané formáty dokument˚ u zahrnout následuj´ıc´ı: ∙ Portable Document Format (PDF) ∙ Office Open XML (OOXML) ∙ Open Document Format for Office Aplications (ODF) ∙ eXtensible Stylesheet Language - Formatting Objects (XSL-FO) ∙ Rich Text Format (RTF) Tyto formáty splˇ nuj´ı kritérium 2.1.1, to vˇsak neznamená, ˇze jsou to jedin´ı zástupci, kteˇr´ı tuto podm´ınku splˇ nuj´ı. Byly vybrány také proto, ˇze jsou pomˇernˇe rozˇs´ıˇrené, nebo maj´ı alespoˇ n specifické vlastnosti, které by mohly m´ıt pro odvˇetv´ı správy dokument˚ u v´ yznam. V dalˇs´ıch podkapitolách, kde budou podrobnˇe rozebrány, neopomenu zhodnotit, do jaké m´ıry vyhovuj´ı bod˚ um 2.1.2 a 2.1.3. Následuj´ıc´ı informace o formátech dokument˚ u vycházej´ı z poznatk˚ u zjiˇstˇen´ ych v práci na téma Modely dokument˚ u a metody jejich skládán´ı“, kterou ” jsem vypracoval jako souˇca´st Oborového projektu. Zde se vˇsak na rozd´ıl od v´ yˇse uvedeného projektu v´ıce zamˇeˇruji na dostupnost knihoven pro platformu .NET, která byla uvedena jako poˇzadavek spoleˇcnosti CCA Group, a podle tohoto kritéria zohledˇ nuji závˇereˇcné hodnocen´ı.

4


2.3

Portable Document Format


Portable Document Format (dále jen PDF) je souborov´ y formát vyvinut´ y p˚ uvodnˇe jako proprietárn´ı formát spoleˇcnosti Adobe Systems. Pˇrestoˇze byla v roce 1993 uveˇrejnˇena volnˇe ˇsiˇritelná specifikace formátu PDF, z˚ ustal formát pod kontrolou spoleˇcnosti Adobe aˇz do 1. ˇcervna 2008, kdy byl publikován jako otevˇren´ y standard ISO 32000-1.[5] Jedná se o formát, kter´ y slouˇz´ı k r˚ uzn´ ym u ´ˇcel˚ um podle toho, jak´ y standard splˇ nuje: ∙ PDF/X - PDF for Exchange – grafické technologie – pˇredtisková v´ ymˇena digitáln´ıch dat, ∙ PDF/A - PDF for Archive – správa dokument˚ u – formát elektronického dokumentu pro dlouhodobou u ´schovu, ∙ PDF/E - PDF for Engineering – správa dokument˚ u – formát pro technickou dokumentaci, ∙ PDF/VT - PDF for exchange of variable data and transactional (VT) printing – grafické technologie – podpora variable data printing, ∙ PDF/UA - PDF for Universal Access – správa dokument˚ u – usnadnˇen´ı navigace v dokumentu (pro lidi s postiˇzen´ım).[6]

2.3.1

Struktura PDF

PDF je strukturovan´ y formát, jehoˇz kód je rozdˇelen implicitnˇe do následuj´ıc´ıch komponent: header, body, xref table, trailer (obrázek 2.1). ˇ ast header obsahuje pouze jednu ˇrádku kódu, která oznaˇcuje verzi PDF. C´ ˇ ast body obsahuje veˇskeré informace o objektech (p´ısma, texty, formuláˇrová C´ pole, obrázky a dalˇs´ı). Xref table obsahuje informace o tom, kolik objekt˚ u dokument obsahuje, kde zaˇc´ınaj´ı a jejich délku v bytech. Trailer obsahuje ukazatele na poloˇzky v xref table a na kl´ıˇcové objekty. Pokud chceme PDF mˇenit, máme dvˇe moˇznosti, jak následnˇe dokument uloˇzit. Volbou uloˇ zit jako (Save As) uloˇz´ıme pouze zmˇenˇené PDF. Volbou uloˇ zit (Save) dojde k uloˇzen´ı p˚ uvodn´ıho PDF, ke kterému jsou pˇripojeny update ˇca´sti: body changes, tref a trailer nového dokumentu. Pokud chceme PDF dokument podepsat, mus´ıme jej ukládat volbou uloˇzit, jinak bychom zmˇenili p˚ uvodn´ı PDF 5



Obrázek 2.1: Struktura PDF souboru po mnohonásobném ukládán´ı (zdroj: autor). a podpis by nebyl validn´ı.[7] PDF vyuˇz´ıvá pro generován´ı layoutu a grafiky podmnoˇzinu popisného jazyka PostScript. Ten nav´ıc rozˇsiˇruje o dˇr´ıve zm´ınˇené strukturován´ı, systém vkládán´ı a pˇrenosu p´ısma a dalˇs´ı.

2.3.2

Vytv´ aˇ ren´ı PDF

Pro práci s PDF existuje celá ˇrada knihoven. Jednou z nich je napˇr´ıklad iText, kter´ y má placenou i AGPL variantu a existuje i ve verzi pro C# .NET. Umoˇzn ˇuje automaticky vytváˇret PDF jak po chunk bloc´ıch (po kusech) a odstavc´ıch, tak pˇr´ımo po bytech. Dále umoˇzn ˇuje automaticky plnit interaktivn´ı formuláˇre a podepisovat, ˇsifrovat, popisovat, spojovat a rozdˇelovat dokumenty formátu PDF.

6


2.3.3

Office Open XML

Shrnut´ı PDF

Na jedné stranˇe je velkou v´ yhodou PDF jeho rozˇs´ıˇrenost a standardizace, která se nav´ıc stále vyv´ıj´ı. Na druhé stranˇe je pro obyˇcejného uˇzivatele“ ne” v´ yhodou, ˇze jiˇz vytvoˇren´ y dokument m˚ uˇze mˇenit pouze s omezen´ımi (pˇridán´ı popisku, podepsán´ı atd.) nebo za pouˇzit´ı pokroˇcil´ ych nástroj˚ u (zpravidla se jedná o placené nástroje).

2.4

Office Open XML

Formát Office Open XML (dále jen OOXML) byl vyvinut spoleˇcnost´ı Microsoft a vyuˇz´ıvá kombinace ukládán´ı dat ve formátu XML, které jsou strukturovány v ZIP archivu. Prvn´ı standard byl vydán organizac´ı Ecma (ECMA376) a o nˇeco pozdˇeji ISO a IEC (ISO/IEC 29500). Od vydán´ı Microsoft Office 2007 se stal OOXML defaultn´ım formátem Microsoft Office. D´ıky otevˇrené specifikaci lze nalézt mnoho program˚ u napˇr´ıˇc operaˇcn´ımi systémy, které s OOXML um´ı pracovat. Formát OOXML byl navrˇzen tak, aby podporoval následuj´ıc´ı oblasti: ∙ Jednoduchá integrace business informac´ı s dokumenty – podporuje rychlou tvorbu dokument˚ u za pouˇzit´ı datov´ ych zdroj˚ u. ∙ Otevˇrenost, bezplatnost – formát je zaloˇzen na technologi´ıch XML a ZIP, které jsou vˇseobecnˇe dostupné, specifikace je téˇz bezplatná a otevˇrená. ∙ Interoperabilita – d´ıky tomu, ˇze je jádro dokumentu ve formátu XML, lze formát OOXML snadno pouˇz´ıt pro v´ ymˇenu dat mezi informaˇcn´ımi systémy a aplikacemi Microsoft Office. ∙ Robustnost – formát OOXML je navrˇzen tak, aby byl robustnˇejˇs´ı neˇz klasické binárn´ı formáty (poˇskozen´ı podsouboru neomez´ı ˇcitelnost ostatn´ıch podsoubor˚ u atd.). ∙ Efektivita – ZIP formát umoˇzn ˇuje komprimovat data (aˇz o 75% menˇs´ı soubory). ∙ Bezpeˇcnost – otevˇrenost formátu umoˇzn ˇuje snadno identifikovat a odstranit osobn´ı ˇci jiné citlivé u ´daje. Dalˇs´ı vylepˇsen´ı v oblasti bezpeˇcnosti 7


Office Open XML

pˇrináˇsej´ı OOXML dokumenty t´ım, ˇze defaultnˇe nevykonávaj´ı vloˇzen´ y kód, tedy nen´ı moˇzné touto cestou podstrˇcit ˇskodliv´ y kód k vykonán´ı. ∙ Zpˇetná kompatibilita – pˇredeˇslé .doc, .xls a .ppt formáty jsou plnˇe kompatibiln´ı s jejich OOXML nástupci.[8]

2.4.1

Struktura OOXML

Jak bylo ˇreˇceno v´ yˇse, OOXML kombinuje technologie ZIP a XML. Jedná se tedy o zip archiv pˇreváˇznˇe XML soubor˚ u, které obsahuj´ı informace o formátován´ı, stylech, kapitoly, textov´ y obsah, metadata a dalˇs´ı. Jednotlivé ˇcásti dokumentu lze samostatnˇe mˇenit, nebo nahrazovat. Existuje zde systém odkaz˚ u, které ukazuj´ı na jednotlivé ˇca´sti dokumentu. Z toho je patrné, ˇze struktura adresáˇre zde nen´ı pevnˇe stanovená a záleˇz´ı jen na odkazech. XML ˇca´sti dokumentu mohou b´ yt r˚ uzn´ ych typ˚ u, nˇekteré jsou spoleˇcné pro vˇsechny aplikace, které s OOXML pracuj´ı, dalˇs´ı jsou pak podˇr´ızeny pˇr´ımo konkrétn´ım typ˚ um aplikac´ı (napˇr´ıklad list je implicitnˇe urˇcen aplikaci Excel, nebo slide master aplikaci PowerPoint). Dalˇs´ı objekty, napˇr´ıklad obrázky, jsou ukládány pˇr´ımo v jejich nativn´ım formátu.[8] D˚ uleˇzité souˇca´sti: y soubor .rels. ∙ Sloˇ zka rels obsahuje koˇrenov´ ∙ Soubor .rels obsahuje popis ˇca´st´ı, které se váˇz´ı k (virtuáln´ı) startovn´ı ˇcásti dokumentu, pomoc´ı vztah˚ u. Vztahy (Relationships) obsahuj´ı informaci o typu ˇcásti, na kterou odkazuj´ı, dále obsahuj´ı unikátn´ı identifikátor a um´ıstˇen´ı ˇcásti. Pˇr´ıklad vztah˚ u naleznete na obrázku 2.2. ych typ˚ u ob∙ Soubor [Content Types].xml obsahuje definice pouˇzit´ sahu. Odkazované ˇca´sti mohou b´ yt bud’ jednoduché, nebo opˇet sloˇzené pomoc´ı odkazován´ı v rels. V kaˇzdém rels je definována hlavn´ı ˇca´st dokumentu (u PowerPoint dokumentu je to presentation, u Excel dokumentu workbook a u Word dokumentu je to document). Podle typu hlavn´ı ˇca´sti dokumentu se odv´ıjej´ı ostatn´ı vztahy. Vztahy (relationships) nehraj´ı roli pouze v rels ˇca´stech, ale pouˇz´ıvaj´ı se jako zp˚ usob propojen´ı v celém OOXML. Pˇr´ıklad implicitn´ıho a explicitn´ıho odkazován´ı ve formátu OOXML naleznete na obrázc´ıch 2.3 a 2.4. 8


Office Open XML

Obrázek 2.2: Pˇr´ıklad vysoko´ urovˇ nových vztah˚ u v seˇsitu aplikace Excel (zdroj: msdn.microsoft.com).

Uˇziteˇcnou vlastnost´ı formátu OOXML je také to, ˇze nab´ız´ı vztahován´ı nejen na intern´ı, ale i na extern´ı zdroje. Jak uˇz bylo zm´ınˇeno v´ yˇse, formát OOXML defaultnˇe nepodporuje makra. Je moˇzné uloˇzit dokument s podporou maker, v tom pˇr´ıpadˇe ale uˇzivatel rozezná takov´ y typ dokumentu (je uloˇzen s koncovkou m“ m´ısto x“). Pokud bude dokument s podporou maker otev´ırán ” ” jako dokument bez podpory (zmˇena koncovky), aplikace vrát´ı chybu. [8]

2.4.2

Tvorba OOXML

Pro práci s OOXML teoreticky staˇc´ı pouze prostˇredek pro manipulaci se ZIP archivy. Pˇresto existuje ˇrada nástroj˚ u pro práci s OOXML vydan´ ych pˇr´ımo spoleˇcnost´ı Microsoft. Nejv´ yznamnˇejˇs´ımi nástroji jsou patrnˇe Office Open XML SDK (nyn´ı jiˇz ve verzi 2.0) a PowerTools for Open XML. Tyto nástroje umoˇzn ˇuj´ı vytváˇren´ı dokument˚ u, zmˇenu jejich obsahu a mnohé dalˇs´ı. Pokud se zamˇeˇr´ım na vytváˇren´ı dokument˚ u spojen´ım jiˇz existuj´ıc´ıch, jsou známy minimálnˇe dvˇe r˚ uzné moˇznosti, jak takov´ y dokument vytvoˇrit: ∙ altChunk je speciáln´ı vysoko´ urovˇ nov´ y pˇr´ıstup skládán´ı Word OOXML dokumentu pomoc´ı znaˇckován´ı, kter´ y umoˇzn ˇuje do tˇela dokumentu vkládat jin´ y OOXML dokument, nebo html stránku. Pouˇzité dokumenty jsou pˇribaleny do bal´ıku c´ılového dokumentu a v tˇele jsou na nˇe vytvoˇreny odkazy.

9


Office Open XML

Obrázek 2.3: Implicitn´ı odkazován´ı v OOXML (zdroj: msdn.microsoft.com).

10


Office Open XML

Obrázek 2.4: Explicitn´ı odkazován´ı v OOXML (zdroj: msdn.microsoft.com).

11


OpenDocument

∙ DocumentBuilder je tˇr´ıda z PowerTools for Open XML urˇcená k vytváˇren´ı dokument˚ u. C´ılov´ y dokument je pˇr´ımo vytvoˇren ze zdrojov´ ych a nejedná se o pouhé odkazován´ı. Rozd´ıl mezi tˇemito pˇr´ıstupy je zˇrejm´ y – dokument pomoc´ı altChunk bude snadné a rychlé vytvoˇrit, ale vzroste zátˇeˇz stroje pˇri otev´ırán´ı dokumentu. Naproti tomu se bude nov´ y dokument pomoc´ı DocumentBuilder vytváˇret déle, avˇsak jeho otev´ırán´ı bude ménˇe nároˇcné. Podepisován´ı OOXML dokument˚ u je moˇzné realizovat mnoha zp˚ usoby. Nejsnazˇs´ı moˇznost´ı je vkládán´ı intern´ıch podpis˚ u ve formátu XMLDsig, staˇc´ı k tomu knihovny System.IO.Packaging (.NET Framework 3.0 a vyˇsˇs´ı) a System.Security.Cryptography (.NET Framework 1.1 a vyˇsˇs´ı). V aplikac´ıch Office od verze 2010 existuje moˇznost podepisován´ı OOXML ve formátu XAdES (viz kapitola 3.6).

2.4.3

Shrnut´ı OOXML

Formát OOXML je mnohem mladˇs´ı a také ménˇe rozˇs´ıˇren´ y neˇz formát PDF. Pravdˇepodobnˇe z tˇechto d˚ uvod˚ u nen´ı zvykem vyuˇz´ıvat dokumenty ve formátu OOXML k archivaci. D´ıky podpoˇre ze strany tv˚ urc˚ u bal´ıku Office vid´ım snahu o zaveden´ı uznávan´ ych standard˚ u podpisov´ ych formát˚ u, coˇz by mohlo formátu OOXML z pohledu archivace v budoucnu prospˇet. V souˇcasnosti lze tento nedostatek ˇreˇsit konverz´ı OOXML dokument˚ u do formátu PDF (k tomu m˚ uˇze poslouˇzit napˇr´ıklad knihovna DocX, urˇcená pro platformu .NET). Nev´ yhodou OOXML je, ˇze mimo platformu .NET má ménˇe kvalitn´ı podporu. K formátu OOXML existuje otevˇren´ y standard a mnoho aplikac´ı tak s t´ımto formátem um´ı zacházet. Dále je pro uˇzivatele pˇr´ıjemné, ˇze si m˚ uˇze snadno vytvoˇrit ˇsablony pro tvorbu dokument˚ u v aplikaci typu Office. Nakonec nemohu nezm´ınit, ˇze se jedná o formát, kter´ y podporuje ukládán´ı podpis˚ u v r˚ uzn´ ych formátech.

2.5

OpenDocument

OpenDocument (OD) je v plném znˇen´ı znám jako Open Document Format for Office Applications (ODF). Byl p˚ uvodnˇe vyvinut spoleˇcnosti SunMicrosystems jako formát OpenOffice.org XML. Poté byla jeho specifikace vydána or12


OpenDocument

ganizac´ı OASIS, nav´ıc byl pˇri vydán´ı verze 1.1 publikován také jako ISO/IEC standard (ISO/IEC 26300:2006/Amd 1:2012).

2.5.1

Struktura ODF

ODF podporuje dvˇe odliˇsné varianty reprezentace: ∙ Reprezentace pomoc´ı jedin´ eho XML souboru. Známá také jako ploché XML (Flat XML), nebo nekomprimované XML (Uncompressed XML). Tato reprezentace nen´ı ˇsiroce uˇz´ıvaná a nemá v technické specifikaci standardizované pˇr´ıpony. Bˇeˇznˇe se ale pouˇz´ıvaj´ı pˇr´ıpony .xml, .fodt, .fods aj. ∙ Jako kolekce poddokument˚ u v standardn´ım ZIP archivu s pevnˇ e danou strukturou. Kaˇzd´ y z poddokument˚ u má vlastn´ı koˇrenov´ y dokument. Pouˇz´ıvá standardizované pˇr´ıpony .odt, .ods, .odp a .odg. Stejnˇe jako OOXML, ODF podporuje ˇsablony (templates). Jedná se soubory, které obsahuj´ı informace o formátován´ı (vˇcetnˇe styl˚ u) bez samotného obsahu. ODT podporuje ukládán´ı metadat. Pro tento u ´ˇcel má vlastn´ı sadu metadat, kterou lze uˇzivatelsky rozˇs´ıˇrit. Objekty, které m˚ uˇze OD obsahovat, jsou dvoj´ıho druhu: ∙ Objekty, kter´ e jsou v OD zastoupeny (vzorce, grafy, tabulky, textové dokumenty, kresby, prezentace) ∙ Objekty, kter´ e nemaj´ı XML reprezentaci a maj´ı pouze bin´ arn´ı reprezentaci. Jedná se napˇr´ıklad o OLE objekty, bitmapy atd. ODF umoˇzn ˇuje referencován´ı uvnitˇr bal´ıku pomoc´ı takzvan´ ych IRIs (Internationalized Resource Identifiers) lokátor˚ u. Neumoˇzn ˇuje tedy na rozd´ıl od OOXML referencovat extern´ı zdroje.[9] Uncompressed varianta obsahuje standardnˇe následuj´ıc´ı ˇca´sti: ∙ XML soubory: 13


– – – –

OpenDocument

content.xml – nese nebinárn´ı obsah dokumentu styles.xml – obsahuje informace o stylech meta.xml – obsahuje metadata settings.xml – obsahuje data o nastaven´ıch, která se net´ ykaj´ı obsahu ani rozloˇzen´ı (napˇr´ıklad zoom, pozice kurzoru atd.)

∙ Ostatn´ı soubory: – mimetype – jednoˇra´dkov´ y soubor s informac´ı o mimetypu dokument ∙ Sloˇzky: – META-INF – obashuje manifest.xml s informacemi o souborech obsaˇzen´ ych v OD bal´ıku (seznam vˇsech obsaˇzen´ ych soubor˚ u, jejich media typ a pokud jsou ˇsifrované, tak i informace potˇrebné k deˇsifrován´ı) – Thumbnails – thumbnail.png – mˇelo by se jednat o náhled na prvn´ı stranu dokumentu o rozmˇerech 128x128 pixel˚ u[9]

2.5.2

Tvorba ODF

Pro práci s ODF existuje ˇrada knihoven, ale pouze nˇekolik je jich urˇceno pro platformu .NET. Nejznámˇejˇs´ı z nekomerˇcn´ıch knihovnen pro .NET je AODL. Jej´ı kvalita je vˇsak n´ızká, podporuje ODF pouze do verze 3.2 a nyn´ı se zdá b´ yt jej´ı v´ yvoj neaktivn´ı. Pro platformu .NET tedy nezb´ yvá jiná moˇznost neˇz pouˇz´ıt knihovny pro Javu (ODFDOM, Simple ODF API for Java, nebo JOpenDocument) a Java VM pro .NET, nebo zaplatit zhruba 7500 Kˇc za komerˇcn´ı knihovnu ODF.NET od spoleˇcnosti Independent. Nekomerˇcn´ı nástroje pro Javu umoˇzn ˇuj´ı veˇskerou základn´ı práci s dokumentem a na této u ´rovni jsou postaˇcuj´ıc´ı. Pokud bych chtˇel spojovat jiˇz existuj´ıc´ı dokumenty, musel bych si tuto funkˇcnost sám doplnit. Vysoko´ urovˇ nové skládán´ı, které by samo zajiˇst’ovalo shodu styl˚ u, bud’ nefunguje zcela dobˇre, nebo jej neum´ı v˚ ubec. Knihovna ODF.NET tuto funkˇcnost poskytuje.

2.5.3

Shrnut´ı ODF

ODF a OOXML jsou v mnoh´ ych smˇerech podobné formáty. Pouˇz´ıvaj´ı stejné technologie k ukládán´ı dat. ODF umoˇzn ˇuje intern´ı pˇripojován´ı elektronick´ ych 14


XSL-FO

Obrázek 2.5: Státy, které si ODF osvojily (zelenˇe), a ˇclenové NATO (modˇre), kterým byl uloˇzen jako standard povinnˇe (zdroj: wikipedia.org). podpis˚ u obdobnˇe jako formát OOXML. ODF ale, na rozd´ıl od OOXML, nepodporuje napˇr´ıklad referencován´ı extern´ıch zdroj˚ u a také má v´ yraznˇe horˇs´ı podporu pro platformu .NET. D˚ uvodem, proˇc je tento formát zaj´ımav´ y, je fakt, ˇze jej dosud jako národn´ı standard osvojila ˇrada zem´ı (napˇr´ıklad Braz´ılie, Chorvatsko, Japonsko a dalˇs´ı) a také byl zaveden povinnˇe jako standard ˇclen˚ um NATO (obrázek 2.5)[10]

2.6

XSL-FO

Extensible Stylesheet Language - Formatting Objects (XSL-FO) je znaˇckovac´ı jazyk, kter´ y lze chápat jako speciáln´ı pˇr´ıpad dokumentového formátu. Zjednoduˇsenˇe se jedná o spojen´ı XML dokumentu s XSL transformac´ı, která urˇcuje v´ ysledn´ y vzhled dokumentu. XSL-FO spadá do technologi´ı W3C. V roce 2001 byla vydána specifikace 1.0 a v roce 2006 vydala organizace W3C specifikaci verze 1.1. XSL-FO vyuˇz´ıvá v´ yhradnˇe prezentaˇcn´ıho a nikoliv sémantického znaˇcen´ı (na rozd´ıl od HTML). Jeho hlavn´ı myˇslenkou je, aby byl pouˇz´ıván jako formát pro transformace. Dokument by se tedy netvoˇril pˇr´ımo jako XSL-FO, ale byl by popsán v nˇejakém jiném XML jazyce (XHTML, DocBook, ale i jak´ ykoliv jin´ y XML jazyk). Dále by se takov´ y dokument pˇrevedl pomoc´ı XSLT transformace na XML-FO formát. XSL-FO dokument pak zpracovává takzvan´ y FO procesor, kter´ y z dokumentu m˚ uˇze vygenerovat jin´ y typ dokumentu (zpravidla PDF

15


XSL-FO

ˇci PostScript, m˚ uˇze ale napˇr´ıklad i RTF), nebo jej m˚ uˇze pˇr´ımo zobrazit na obrazovku.[11]

2.6.1

Struktura XSL-FO

XSL-FO má v zásadˇe velmi jednoduchou strukturu. Jedná se o XML dokument, kter´ y nemus´ı nutnˇe vyhovovat konkrétn´ımu DTD schématu. Staˇc´ı, kdyˇz bude vyhovovat XSL-FO specifikaci. XSL-FO dokument obsahuje dvˇe povinné ˇca´sti. Prvn´ı obsahuje seznam pojmenovan´ ych rozloˇzen´ı stránky. Druhá ˇcást obsahuje seznam dat se znaˇckován´ım, kter´ y odkazuje na rozloˇzen´ı stránek, a tak urˇcuje, jak obsahová data vypln´ı jednotlivé stránky. Prvn´ı ˇcást definuje veˇskeré nastaven´ı stránek. Mezi ty patˇr´ı hlavnˇe velikost stránek, odsazen´ı textu a napˇr´ıklad i definován´ı sekvenc´ı pro sudé a liché stránky. Druhá ˇcást je rozdˇelena na toky, které vˇzdy patˇr´ı urˇcité definici stránky. Ty pak dále obsahuj´ı seznam blok˚ u, kde kaˇzd´ y blok obsahuje seznam textov´ ych dat, ˇrádkov´ ych znaˇckovac´ıch prvk˚ u anebo kombinaci oboj´ıho. Bloky a ˇra´dkové prvky funguj´ı podobnˇe jako v CSS (tedy i vˇetˇsina formátovac´ıch prvk˚ u se dˇed´ı na vnoˇrené FO).[12]

2.6.2

Tvorba XSL-FO

Tvorbu XSL-FO lze rozdˇelit do nˇekolika fáz´ı: 1. Tvorba XML dokumentu s obsahem. V této fázi lze pouˇz´ıt celou ˇradu pˇr´ıstup˚ u. Je moˇzné vygenerovat si vlastn´ı XML, které bude m´ıt námi urˇcenou strukturu. Také je moˇzné vyuˇz´ıt nˇekter´ y formát, kter´ y je vyjádˇren pomoc´ı XML (napˇr´ıklad XHTML, DocBook a dalˇs´ı) - mnoho nástroj˚ u bude podporovat export do takov´ ych formát˚ u. 2. XSLT transformace na XSL-FO. K tomuto kroku je zapotˇreb´ı XSLT transformace a XSLT procesor. Na internetu je k nalezen´ı celá ˇrada ˇsablon XSLT transformac´ı pro pˇrevod XML na XSL-FO (zvláˇstˇe pak pro typizované formáty typu DocBook). Mezi kompilaˇcn´ı nástroje patˇr´ı napˇr´ıklad Saxon, xsltproc nebo MSXML. 16


Rich Text Format

3. Konverze do jin´ eho form´ atu / zobrazen´ı na monitor. Pokud je k dispozici XSL-FO soubor, je potˇrebné m´ıt jeˇstˇe XSL-FO procesor, aby bylo moˇzné si dokument prohlédnout nebo pˇrevést na jin´ y formát. Zde se nab´ız´ı kvalitn´ı open-source nástroj FOP (od spoleˇcnosti Apache) s podporou ˇceského jazyka, kter´ y je urˇcen pro Javu a existuje k nˇemu port pro .NET. Jmenuje se nfop a jedná se o port v jazyce J#. Alternativou je projekt FO.NET. Tato knihovna nab´ız´ı kvalitn´ı tvorbu PDF, vˇcetnˇe komprese. Knihovna FOP vˇsak podporuje v´ıce v´ ystupn´ıch typ˚ u soubor˚ u (napˇr´ıklad PostScript nebo PCL) a umoˇzn ˇuje zobrazit zformátované XSL-FO na obrazovku.

2.6.3

Shrnut´ı XSL-FO

XSL-FO zdaleka nen´ı ideáln´ım formátem. Neexistuje k nˇemu dosud ˇzádn´ y nástroj, kter´ y by poskytl uˇzivatelsky pˇr´ıjemné prostˇred´ı pro formátován´ı (ˇza´dn´ y WYSIWYG editor), tvorba sloˇzitˇejˇs´ıho vzhledu je nároˇcná nebo nejsou nˇekteré vlastnosti v˚ ubec podporovány. Nav´ıc si bˇeˇzn´ y uˇzivatel tento dokument ani nezobraz´ı ve zformátovaném stavu na monitor. Proˇc jsem jej tedy mezi zkoumané formáty zahrnul? D˚ uvodem je, ˇze t´ımto smˇerem XSL-FO nem´ıˇr´ı. Jeho c´ılem je stát se prostˇredkem pro dosaˇzen´ı c´ılového formátu (vˇetˇsinou PDF). Typick´ ym pˇr´ıkladem uˇzit´ı bude generován´ı PDF z dat obsaˇzen´ ych v objektu uloˇzeném v databázi – chceme do PDF vygenerovat seznam zamˇestnanc˚ u, fakturu, smlouvu – tedy cokoliv, co má jasnˇe danou, málo promˇenlivou strukturu a nelze oˇcekávat ˇcasté zmˇeny vzhledu dokumentu. Lze zajisté oponovat, ˇze takov´ ych konvertor˚ u existuje celá ˇrada nad r˚ uzn´ ymi formáty (XHTML i DocBook maj´ı také své konvertory do PDF), XSL-FO se ale neomezuje na jeden formát XML dokumentu, ale umoˇzn ˇuje generován´ı nad jak´ ymkoli XML. XSL-FO také podporuje vkládán´ı libovoln´ ych XML dat pomoc´ı tagu foreign-object (nejobl´ıbenˇejˇs´ımi objekty jsou SVG kˇrivky).

2.7

Rich Text Format

Rich Text Format (dále jen RTF) je platformˇe nezávisl´ y, proprietárn´ı dokumentov´ y formát vyvinut´ y spoleˇcnost´ı Microsoft. Jeho specifikace byla uveˇrejnˇena jiˇz v roce 1987 a jedná se tedy o nejstarˇs´ı dokumentov´ y formát z tˇech, které zde porovnávám. V pr˚ ubˇehu let byly vydávány novˇejˇs´ı verze specifikace (pˇreváˇznˇe spolu s vydán´ım nové verze MS Office) a v roce 2008 byla vydána 17


Rich Text Format

dosud posledn´ı verze 1.9.1. Po vydán´ı MS Office 2010 vydal Microsoft stanovisko, ˇze nebude specifikaci RTF dále rozv´ıjet, a tak nˇekteré vlastnosti MS Word 2010 a novˇejˇs´ıch nebudou s formátem RTF kompatibiln´ı.[13]

2.7.1

Struktura RTF

RTF je ukládán jako jeden soubor obsahuj´ıc´ı prost´ y text. Je konstruován tak, ˇze je i v neinterpretovaném stavu ˇciteln´ y ˇclovˇekem (Human readability). Pokud se jedná o RTF ukládané aplikac´ı MS Word, je ˇcitelnost zt´ıˇzena, protoˇze je pˇridáváno znaˇcné mnoˇzstv´ı ˇr´ıd´ıc´ıch znak˚ u. Ve formátovac´ım vyznaˇcován´ı se autoˇri (Richard Brodie, Charles Simonyi a David Luebbert) nechali inspirovat znaˇcen´ım formátu TeX. ˇ ıd´ıc´ı znaky: R´ ∙ Sloˇ zen´ e z´ avorky {} definuj´ı skupinu. Skupiny se mohou libovolnˇe zanoˇrovat. ∙ Zpˇ etn´ e lom´ıtko ∖ zaˇc´ıná ˇr´ıd´ıc´ı kód RTF. Kaˇzd´ y RTF dokument by mˇel zaˇc´ınat ˇr´ıd´ıc´ım kódem ∖rtf (napˇr´ıklad formátován´ı tuˇcného textu je ˇr´ızeno sekvenc´ı ∖b atd.). RTF dokument umoˇzn ˇuje pouˇz´ıt pouze 7bitové ASCII znaky. Pokud maj´ı b´ yt ve v´ ysledném textu jiné znaky, budou v RTF souboru zastoupeny pomoc´ı escape sekvence. Znaky z kódován´ı Windows budou vkládány ve tvaru ∖’ff (kde ff pˇredstavuje dvˇe hexadecimáln´ı ˇc´ıslice). Znaky z kódován´ı Unicode budou ve tvaru ∖u0000 (kde 0000 pˇredstavuje znaménkové 16bitové decimáln´ı ˇc´ıslo). Vloˇzené objekty: ∙ OLE objekty – pokud interpret formátu OLE objektu nerozum´ı, m˚ uˇze ho v zobrazen´ı nahradit bitmapou, nebo jej nezobrazit v˚ ubec. ∙ Obr´ azky – je umoˇznˇeno vkládat v nˇekolika vybran´ ych formátech (JPEG, PNG). Pokud program, kter´ y RTF vytváˇr´ı, má vloˇzit obrázek jiného formátu, zpravidla si program obrázek nejprve zkonvertuje do podporovaného formátu, nebo jej nevloˇz´ı v˚ ubec. Nˇekteré programy zapisuj´ı obrázky ve dvou r˚ uzn´ ych formátech zároveˇ n, kv˚ uli lepˇs´ı kompatibilitˇe s produkty MS Windows. Jeden bude ve formátu JPEG, nebo PNG a 18


Rich Text Format

druh´ y ve formátu Windows Meta File (WMF). Ukládán´ı obrázku ve dvou formátech pochopitelnˇe znaˇcnˇe zvˇetˇsuje velikost v´ ysledného RTF dokumentu. atd.). ∙ P´ısma – mohou b´ yt vloˇzena a zároveˇ n jsou podporovány generické názvy rodiny p´ısma pro nahrazen´ı chybˇej´ıc´ıch p´ısem. Ani jedna z tˇechto vlastnost´ı vˇsak nen´ı interprety ˇsiroce podporována. ∙ Tvary – RTF podporuje základn´ı kresl´ıc´ı objekty (obdéln´ıky, ˇca´ry, ˇsipky, mnoho´ uheln´ıky, elipsy a dalˇs´ı). Ani RTF tvary nejsou interprety pˇr´ıliˇs podporovány. RTF nepodporuje spouˇstˇen´ı maker, coˇz zvyˇsuje bezpeˇcnost formátu v˚ uˇci ˇs´ıˇren´ı vir˚ u. Samotná pˇr´ıpona ale nic neznamená, takˇze je moˇzné, aby ˇsiˇritel viru uloˇzil dokument obsahuj´ıc´ı ˇskodliv´ y kód ve formátu DOC a pˇr´ıponu souboru následnˇe zmˇenil na .rtf. V aplikaci MS Word je tento dokument otevˇren jako jak´ ykoliv jin´ y dokument formátu DOC (tedy vˇcetnˇe proveden´ı maker), aniˇz by byl uˇzivatel upozornˇen, ˇze se nejedná o RTF. Nejedná se tedy o zcela bezchybn´ y ochrann´ y prvek. Pokud by byla pˇr´ıpona zm´ınˇeného dokumentu zmˇenˇena z DOC na DOCX, je otev´ırán´ı souboru v aplikaci MS Word pˇreruˇseno chybou.[14]

2.7.2

Tvorba RTF

Pro práci s formátem RTF existuj´ı dva druhy knihoven: ∙ pro generován´ı RTF (jRTF, RTF Document Constructor Library) ∙ pro manipulaci s RTF (NRTFTree, Gios WORD .NET Library) Právˇe druhá kategorie je zaj´ımavˇejˇs´ı, protoˇze je vyuˇz´ıvána nejen pro tvorbu nového RTF, ale i pro skládán´ı z jiˇz existuj´ıc´ıch dokument˚ u. Takovou funkcionalitu sice neposkytuj´ı pˇr´ımo, dá se ale pomˇernˇe snadno pomoc´ı jejich prostˇredk˚ u naimplementovat. Vˇetˇs´ı problém je ohlednˇe souladu se specifikac´ı formátu. Knihovny bud’ odpov´ıdaj´ı pouze nˇekteré z historick´ ych verz´ı RTF, nebo nepodporuj´ı ˇzádnou konkrétn´ı verzi.

19


2.7.3

Rich Text Format

Shrnut´ı RTF

Specifikace RTF je zveˇrejnˇena pomˇernˇe dlouho dobu. Zpoˇcátku ale veˇrejnˇe dostupná nebyla, a proto mˇeli v´ yvojáˇri spoleˇcnosti Microsoft oproti ostatn´ım v´ yvojáˇr˚ um v´ yhodu. To vedlo k aktuáln´ımu stavu, ve kterém s t´ımto formátem (alespoˇ n v nˇejaké verzi) um´ı pracovat vˇetˇsina textov´ ych procesor˚ u, málokter´ y interpret vˇsak podporuje vˇsechny vlastnosti RTF dokumentu a v´ ysledky interpretace se liˇs´ı. Dalˇs´ı nev´ yhodou je, ˇze k formátu RTF neexistuj´ı knihovny, které by umoˇzn ˇovaly vysoko´ urovˇ novou manipulaci, zároveˇ n by plnˇe podporovaly nejnovˇejˇs´ı specifikaci a byly by aktivnˇe vyv´ıjené. Posledn´ı zjiˇstˇenou nev´ yhodou je, ˇze plochá struktura formátu RTF neumoˇzn ˇuje internˇe pˇripojovat elektronick´ y podpis ani ˇcasová raz´ıtka. Jak´ ykoliv podpis tedy mus´ı b´ yt pˇripojován externˇe. Spolu se skuteˇcnost´ı, ˇze Microsoft nebude formát RTF dále rozv´ıjet, jsou to d˚ uvody, proˇc se podporou RTF pˇr´ıliˇs nezab´ yvat. V kapitole 5.1 jsem provedl anal´ yzu v´ yˇse uveden´ ych informac´ı, zhodnocen´ı pˇr´ınosu jednotliv´ ych formát˚ u a jejich vzájemné porovnán´ı.

20

3 Elektronické podpisy a ˇcasová raz´ıtka 3.1

Z´ akladn´ı pojmy

Podle zákona ˇc. 227/2000 Sb. se elektronick´ ym podpisem rozum´ı u ´daje ” v elektronické podobˇe, které jsou pˇripojené k datové zprávˇe nebo jsou s n´ı logicky spojené, a které slouˇz´ı jako metoda k jednoznaˇcnému ovˇeˇren´ı identity podepsané osoby ve vztahu k datové zprávˇe“.[15] Pokud bych mˇel tuto definici vysvˇetlit, pak se elektronick´ ym podpisem m´ın´ı obecn´ y identifikátor pˇripojen´ y k datové zprávˇe, kter´ y umoˇzn ˇuje jednoznaˇcnou identifikaci podepsané osoby. V takovém smyslu se nejedná o elektronick´ y podpis, jak je bˇeˇznˇe chápán, a neposkytuje ˇzádnou v´ yznamnou informaci. Zákon ˇc. 227/2000 Sb. vˇsak zavád´ı dalˇs´ı pojmy: zaruˇ cen´ y elektronick´ y podpis a uzn´ avan´ y elektronick´ y podpis. Zaruˇcen´ y elektronick´ y podpis je takov´ y elektronický podpis, který splˇ nuje ” následuj´ıc´ı poˇzadavky 1) je jednoznaˇcnˇe spojen s podepisuj´ıc´ı osobou, 2) umoˇzn ˇuje identifikaci podepisuj´ıc´ı osoby ve vztahu k datové zprávˇe, 3) byl vytvoˇren a pˇripojen k datové zprávˇe pomoc´ı prostˇredk˚ u, které podepisuj´ıc´ı osoba m˚ uˇze udrˇzet pod svou výhradn´ı kontrolou, 4) je k datové zprávˇe, ke které se vztahuje, pˇripojen takovým zp˚ usobem, ˇze je moˇzno zjistit jakoukoliv následnou zmˇenu dat.“ [15] Podle tohoto znˇen´ı je zaruˇcen´ y elektronick´ y podpis t´ım, ˇc´ım je bˇeˇznˇe chápán elektronick´ y podpis. Proto pokud bude v následuj´ıc´ım textu uveden elektronick´ y podpis a zároveˇ n nebude zd˚ uraznˇeno, ˇze se jedná o elektronick´ y podpis bez pˇr´ıvlastku“, bude myˇslen jako zaruˇcen´ y elektronick´ y podpis. ” Uznávan´ y elektronick´ y podpis je podle téhoˇz zákona zaruˇcen´ y elektronick´ y podpis, kter´ y je nav´ıc zaloˇzen na kvalifikovaném certifikátu, vydaném bud’ akreditovan´ ym poskytovatelem certifikaˇcn´ıch sluˇzeb (jeho definice, práva a 21

Elektronické podpisy a ˇcasová raz´ıtka

Princip elektronického podpisu

povinnosti jsou uvedeny v témˇz zákonˇe), nebo jeho zahraniˇcn´ı obdobou. Kvalifikovan´ e ˇ casov´ e raz´ıtko je datová zpráva, kterou vydal kvalifiko” van´ y poskytovatel certifikaˇcn´ıch sluˇzeb a která d˚ uvˇeryhodn´ ym zp˚ usobem spojuje data v elektronické podobˇe s ˇcasov´ ym okamˇzikem, a zaruˇcuje, ˇze uvedená data v elektronické podobˇe existovala pˇred dan´ ym ˇcasov´ ym okamˇzikem“[15].

3.2

Princip elektronick´ eho podpisu

V definici zaruˇceného elektronického podpisu je d˚ uleˇzitá fráze je k datové ” zprávˇe, ke které se vztahuje, pˇripojen takov´ ym zp˚ usobem, ˇze je moˇzno zjistit jakoukoliv následnou zmˇenu dat“. Jedná se o zcela zásadn´ı fakt, kter´ y udává smysl elektronického podpisu. Jakmile kdokoli po podepsán´ı (prakticky) jakkoliv zmˇen´ı dokument, je to zjistitelné. Aby byla zajiˇstˇena tato vlastnost, vyuˇz´ıvá se k podpisu asymetrické ˇsifrován´ı. Pouˇz´ıvá se dvojice kl´ıˇc˚ u (soukrom´ y, veˇrejn´ y). Soukrom´ y kl´ıˇc je urˇcen pouze pro uˇzivatele, kter´ y k dokumentu pˇripojuje sv˚ uj podpis. Veˇrejn´ y kl´ıˇc je pak pˇridán pˇr´ımo do podpisu a m˚ uˇze ho pouˇz´ıt kdokoliv, aby zjistil, zda nebyla poruˇsena integrita dokumentu.

3.2.1

Proces podepisov´ an´ı

Proces podepisován´ı funguje následovnˇe. Hashovac´ı funkc´ı (napˇr´ıklad sha1, sha-2) je spoˇcten hash dokumentu, ten je následnˇe pomoc´ı soukromého kl´ıˇce zaˇsifrován a spolu s veˇrejn´ ym kl´ıˇcem a pˇr´ıpadn´ ymi dalˇs´ımi informacemi (certifikát, systémov´ y ˇcas podepsán´ı) pˇripojen jako elektronick´ y podpis k dokumentu na urˇcené m´ısto (mluv´ıme pak o intern´ım podpisu), nebo je pˇripojen jako samostatn´ y soubor (extern´ı podpis).

3.2.2

Proces ovˇ eˇ rov´ an´ı

Uˇzivatel, kter´ y si chce ovˇeˇrit platnost dokumentu, spoˇcte stejnou hashovac´ı funkc´ı hash dokumentu (pokud byl podpis pˇripojen jako intern´ı, pak samozˇrejmˇe bez nˇej) a deˇsifruje pomoc´ı veˇrejného kl´ıˇce pˇriloˇzen´ y hash. Pokud jsou 22


Proces ovˇeˇrován´ı

tyto dva hashe totoˇzné, znamená to, ˇze nebyl dokument zmˇenˇen (autentiˇcnost). Z principu je moˇzné, aby byl dokument pozmˇenˇen a uˇzivateli, kter´ y podpis ovˇeˇruje, byl poskytnut faleˇsn´ y veˇrejn´ y kl´ıˇc.

3.3

Proces ovˇ eˇ rov´ an´ı

K zabránˇen´ı podvrˇzen´ı veˇrejného kl´ıˇce slouˇz´ı certifikaˇcn´ı autority, které certifikáty vydávaj´ı. Certifikaˇcn´ı autority potvrzuj´ı, ˇze veˇrejn´ y kl´ıˇc opravdu patˇr´ı osobˇe, která je v certifikátu uvedena. Pokud uˇzivatel d˚ uvˇeˇruje certifikaˇcn´ı autoritˇe, m˚ uˇze d˚ uvˇeˇrovat i vydanému certifikátu. Certifikaˇcn´ı autoritu m˚ uˇze provozovat kaˇzd´ y sám a pak je problém v urˇcen´ı, komu m˚ uˇze vˇeˇrit. V praxi lze jako certifikaˇcn´ı autority uznávat napˇr´ıklad banky.

3.4

Platnost elektronick´ eho podpisu

K zabránˇen´ı podvrˇzen´ı veˇrejného kl´ıˇce slouˇz´ı certifikaˇcn´ı autority, které certifikáty vydávaj´ı. Certifikaˇcn´ı autority potvrzuj´ı, ˇze veˇrejn´ y kl´ıˇc opravdu patˇr´ı osobˇe, která je v certifikátu uvedena. Pokud uˇzivatel d˚ uvˇeˇruje certifikaˇcn´ı autoritˇe, m˚ uˇze d˚ uvˇeˇrovat i vydanému certifikátu. Certifikaˇcn´ı autoritu m˚ uˇze provozovat kaˇzd´ y sám a pak je problém v urˇcen´ı, komu m˚ uˇze vˇeˇrit. V praxi lze jako certifikaˇcn´ı autority uznávat napˇr´ıklad banky.

3.4.1

Nezpochybnitelnost

Pokud vˇsak uˇzivatel komunikuje se státn´ımi institucemi, je zákonem dáno, ˇze jako nezpochybniteln´ y je brán pouze uznávan´ y elektronick´ y podpis. Ten je zaloˇzen na kvalifikovaném certifikátu, tj. certifikátu vydaném kvalifikovanou ˇ e republice byly v roce 2012 pouze tˇri kvalificertifikaˇcn´ı autoritou. V Cesk´ kované (a zároveˇ n akreditované) certifikaˇcn´ı autority – PostSignum, I.CA a Eldentity. Dalˇs´ı moˇznost´ı je pouˇz´ıt uznávané zahraniˇcn´ı autority. Kvalifikovan´ y certifikát je vydán pouze na základˇe ovˇeˇren´ı identity ˇza´daj´ıc´ı osoby, a to pouze na omezenou dobu (podpisov´ y certifikát na dobu 1 roku). Certifikaˇcn´ı autorita ruˇc´ı za ˇcasovˇe omezenou platnost vydaného certifikátu, pokud bˇehem této doby nedojde k revokaci certifikátu (zneplatnˇen´ı na ˇza´dost majitele). 23


3.4.2

Platnost elektronického podpisu

Okamˇ zik posuzov´ an´ı platnosti podpisu

Jak bylo ˇreˇceno, certifikát plat´ı pouze po urˇcitou dobu. Nejjednoduˇsˇs´ı moˇznost´ı je zkoumat platnost certifikátu v okamˇziku, kdy podpis ovˇeˇrujeme. Nejedná se vˇsak o efektivn´ı vyuˇzit´ı elektronického podpisu. Pokud uˇzivatel podepsal dokument certifikátem, kter´ y byl vydán 1. 1. 2012 a k podpisu byl vyuˇzit 1. 12. 2012 (v té dobˇe stále platn´ y), pak pˇri posuzován´ı platnosti 2. 1. 2013 by bylo zjiˇstˇeno, ˇze certifikát, na jehoˇz základˇe byl podpis vystaven, nen´ı platn´ y, a proto nem˚ uˇze b´ yt podpis vyhodnocen jako platn´ y. Mnohem logiˇctˇejˇs´ı je tedy posuzovat platnost certifikátu v˚ uˇci okamˇziku, kdy byl podpis vytvoˇren. Problémem je takov´ y okamˇzik urˇcit. Elektronick´ y podpis v sobˇe sice zpravidla nese informaci o ˇcase vystaven´ı, ta se vˇsak vytváˇr´ı podle systémového ˇcasu, a m˚ uˇze tak b´ yt podvrˇzena. Z tohoto d˚ uvodu se zavád´ı nezpochybniteln´ y mechanismus – takzvané ˇcasové raz´ıtko.

3.4.3

ˇ Casov´ e raz´ıtko a kvalifikovan´ eˇ casov´ e raz´ıtko

ˇ Casov´ e raz´ıtko je znaˇcka, podobnˇe jako elektronick´ y podpis, kterou si vˇsak uˇzivatel nevystavuje sám, ale je mu vystavena ˇcasovou autoritou. Postup vytváˇren´ı ˇcasového raz´ıtka pˇripom´ıná do jisté m´ıry podepisován´ı dokumentu elektronick´ ym podpisem. Uˇzivatel, kter´ y má v u ´myslu dokument k danému okamˇziku opatˇrit ˇcasov´ ym raz´ıtkem, nejprve vypoˇcte hash dokumentu. Pokud má ˇcasové raz´ıtko dokazovat existenci elektronického podpisu v tomto ˇcase, je potˇreba zahrnout i elektronick´ y podpis do v´ ypoˇctu hashe. Tento hash uˇzivatel odeˇsle poskytovateli certifikaˇcn´ıch sluˇzeb. Ten k hashi pˇripoj´ı pˇresn´ y ˇcasov´ yu ´daj a celou tuto informaci zaˇsifruje vlastn´ım soukrom´ ym kl´ıˇcem. Zároveˇ n poskytne veˇrejn´ y kl´ıˇc pro ovˇeˇren´ı platnosti ˇcasového raz´ıtka a v´ ysledek poˇsle uˇzivateli, kter´ y m˚ uˇze následnˇe ˇcasové raz´ıtko pˇripojit k dokumentu. Proces ovˇeˇrován´ı pak prob´ıhá analogicky jako u elektronického podpisu. Kvalifikované ˇcasové raz´ıtko vydávaj´ı pouze kvalifikovan´ı poskytovatelé certifikaˇcn´ıch sluˇzeb, vydávaj´ıc´ı kvalifikovaná ˇcasová raz´ıtka (v roce 2012 to byly ˇ pouze spoleˇcnosti PostSignum, I.CA a Eldentity). Cesk´ ˇ a legislativa nev CR pouˇz´ıvá pojem ˇcasové raz´ıtko, ale rovnou zavád´ı pojem kvalifikované ˇcasové raz´ıtko. Pomoc´ı ˇcasov´ ych raz´ıtek lze z´ıskat ovˇeˇren´ y ˇcasov´ yu ´daj, ke kterému lze o platnosti podpisu uvaˇzovat. Pokud se vrát´ıme k pˇr´ıkladu uvedenému v kapitole 3.3.2 a dokument z 1.12.2013 by uˇzivatel nejen podepsal, ale i opatˇril ˇcaso24


Platnost elektronického podpisu

v´ ym raz´ıtkem, byl by dokument 2.1.2013 ovˇeˇren jako platn´ y. Pro certifikát ˇcasového raz´ıtka vˇsak stejnˇe jako pro certifikát elektronického podpisu existuje doba platnosti (na rozd´ıl od elektronického podpisu je to delˇs´ı ˇcasov´ y interval, bˇeˇznˇe od 3 do 6 let). Proto i zde mus´ı uˇzivatel poˇc´ıtat s t´ım, ˇze platnost certifikátu vyprˇs´ı. To je, hlavnˇe u dokument˚ u urˇcen´ ych k archivaci, neˇza´douc´ı. Aby uˇzivatel umoˇznil ovˇeˇrit podpis jako platn´ y po neomezenˇe dlouhou dobu, mus´ı jeˇstˇe pˇred vyprˇsen´ım certifikátu autority ˇcasového raz´ıtka opatˇrit dokument dalˇs´ım ˇcasov´ ym raz´ıtkem. U dokument˚ u urˇcen´ ych k archivaci to pˇredstavuje znaˇcnou reˇzii spojenou s kontrolou toho, zda se nebl´ıˇz´ı konec platnosti certifikátu.

3.4.4

Revokace certifik´ atu a jej´ı vyhodnocen´ı pˇ ri ovˇ eˇ rov´ an´ı podpisu

V kapitole 3.3.1 bylo zm´ınˇeno, ˇze si uˇzivatel m˚ uˇze nechat certifikát elektronického podpisu na vlastn´ı ˇza´dost revokovat. Prvoˇrad´ ym d˚ uvodem pro revokaci bude odcizen´ı certifikátu, respektive jeho soukromého kl´ıˇce. Konkrétn´ı proces revokace zákon neupravuje a je na kaˇzdé certifikaˇcn´ı autoritˇe, jak jej zavede. Obecnˇe vˇsak bude dostupn´ y mechanismus, pomoc´ı kterého se drˇzitel autentizuje a zaˇza´dá autoritu o revokaci. Ta má ze zákona 24 hodin na to, aby revokaci certifikátu zveˇrejnila. Bˇehem vyhodnocován´ı platnosti elektronického podpisu mus´ı b´ yt bráno v u ´vahu, zda byl certifikát revokován. Zjiˇstˇen´ı této informace m˚ uˇze b´ yt provedeno v reálném ˇcase, nebo opoˇzdˇenˇe. Zjiˇst’ován´ı platnosti certifikátu v reálném ˇcase b´ yvá nejˇcastˇeji realizováno pomoc´ı protokolu OSCP (Online Certificate Protocol). Protokol OSCP umoˇzn ˇuje vznést dotaz a obdrˇzet odpovˇed’ serveru certifikaˇcn´ı autority v reálném ˇcase. Jedná se o zp˚ usob, kter´ y prom´ıtá revokace v nejkratˇs´ım moˇzném ˇcase, kter´ y vˇsak nen´ı konkrétnˇe specifikován. Z ˇcesk´ ych certifikaˇcn´ıch autorit jej poskytuje od roku 2011 I.CA a novˇe od prosince 2012 i PostSignum. D˚ uvodem, proˇc tuto sluˇzbu ˇceské certifikaˇcn´ı autority neposkytuj´ı v˚ ubec, nebo aˇz v posledn´ı dobˇe, je, ˇze nen´ı vyˇzadována zákonem. Zákon vyˇzaduje poskytován´ı opoˇzdˇené informace pomoc´ı CRL (Certificate Revocation List) – seznam revokovan´ ych certifikát˚ u. Ani zde nejsou sluˇzby poskytuj´ıc´ı CRL jednotné. Jedn´ım druhem CRL jsou kumulativn´ı seznamy, které obsahuj´ıc´ı informace o vˇsech revokovan´ ych certifikátech dané certifikaˇcn´ı autority (po dobu alespoˇ n 10 let, po kterou má autorita ze zákona povinnost udrˇzovat informace). Takové ˇ autorita EIdentity. Druh´ CRL poskytuje v CR ym druhem jsou intervalové seznamy, které obsahuj´ı souhrn revokac´ı za urˇcit´ y ˇcasov´ y interval. Zákonem ˇ t´ımto jsou pˇr´ıpustné, ale nikde nen´ı urˇcena délka takového intervalu. V CR 25


Postup ovˇeˇrován´ı podpisu

Obrázek 3.1: Vývojový diagram ovˇeˇren´ı platnosti podpisu (zdroj: autor). zp˚ usobem poskytuj´ı CRL I.CA a PostSignum. Délka takového intervalu u PostSignum je zhruba 5 mˇes´ıc˚ u (aˇckoliv to nen´ı explicitnˇe ˇreˇceno). V praxi je délka platnosti ceritfikátu elektronického podpisu jeden rok, uˇzivatel tedy mus´ı informaci zjiˇst’ovat z nˇekolika CRL.

3.5

Postup ovˇ eˇ rov´ an´ı podpisu

Z v´ yˇse uveden´ ych poˇzadavk˚ u lze sestavit proces, jak´ ym mus´ı b´ yt podpis ovˇeˇren (schéma na obrázku 3.1).

26


3.6 3.6.1

Elektronický podpis v praxi

Elektronick´ y podpis v praxi Odpovˇ ednost za ˇ skodu

Jedn´ım z d˚ uvod˚ u, proˇc se elektronick´ ymi podpisy zab´ yvat, je osvˇeta uˇzivatel˚ u, kteˇr´ı mnohdy neznaj´ı jejich principy a vystavuj´ı se tak riziku, ˇze dojde ke ˇskodˇe, která na nich m˚ uˇze b´ yt vymáhána. Zejména se jedná o povinnost drˇzitele soukromého kl´ıˇce, aby se o kl´ıˇc staral tak, aby nemohlo doj´ıt k jeho zneuˇzit´ı a pokud by k nˇeˇcemu takovému doˇslo, povinnost vyuˇz´ıt revokaci certifikátu. Tato povinnost je uvedena v S5 zákona ˇc. 227/2000 Sb. ”

Podepisuj´ıc´ı osoba je povinna

a) zacházet s prostˇredky, jakoˇz i s daty pro vytváˇren´ı zaruˇceného elektronického podpisu s náleˇzitou péˇc´ı tak, aby nemohlo doj´ıt k jejich neoprávnˇenému pouˇzit´ı, b) uvˇedomit neprodlenˇe poskytovatele certifikaˇcn´ıch sluˇzeb, který vydal kvalifikovaný certifikát, o tom, ˇze hroz´ı nebezpeˇc´ı zneuˇzit´ı jej´ıch dat pro vytváˇren´ı zaruˇceného elektronického podpisu.“ [15] Z této povinnosti vypl´ yvá i odpovˇednost za ˇskodu: Za ˇskodu zp˚ usobenou poruˇsen´ım povinnost´ı podle odstavce 1 odpov´ıdá podepi” suj´ıc´ı osoba podle zvláˇstn´ıch právn´ıch pˇredpis˚ u. Odpovˇednosti se vˇsak zprost´ı, pokud prokáˇze, ˇze ten, komu vznikla ˇskoda, neprovedl veˇskeré u ´kony potˇrebné k tomu, aby si ovˇeˇril, ˇze zaruˇcený elektronický podpis je platný a jeho kvalifikovaný certifikát nebyl zneplatnˇen.“ [15] Druhá ˇca´st v´ yˇse uvedeného odstavce je taktéˇz d˚ uleˇzitá pro bˇeˇzného uˇzivatele. Pokud mu vznikne ˇskoda zp˚ usobená t´ım, ˇze spoléhal na podpis vznikl´ y zneuˇzit´ım podpisového certifikátu a zároveˇ n neprovedl vˇsechny kroky pro ovˇeˇren´ı platnosti podpisu, pak mu nárok na kompenzaci ˇskody zaniká.

27


3.6.2

Formáty pokroˇcilých el. podpis˚ u

Souˇ casn´ y stav podpory elektronick´ ych podpis˚ u v aplikac´ıch

Pokud si uvˇedom´ıme, jaké povinnosti máme, je dobré si zjistit, v jakém stavu je v˚ uˇci legislativˇe podpora elektronick´ ych podpis˚ u. V knize Bájeˇcn´ y svˇet elektronického podpisu RNDr. Ing. Jiˇr´ı Peterka poukazuje na to, ˇze Adobe Reader nem˚ uˇzeme povaˇzovat za bezpeˇcn´ y nástroj pro vyhodnocován´ı elektronického podpisu. Jeho chován´ı mus´ıme nejprve nastavit, aby fungovalo v souladu s ˇceskou legislativou. Napˇr´ıklad urˇcen´ı po” suzovaného okamˇziku“ platnosti certifikátu podpisu se ˇr´ıd´ı nastaven´ım. Toto nastaven´ı m˚ uˇze nab´ yvat jedné ze tˇr´ı hodnot – platn´ y ˇcas (aktuáln´ı systémov´ y ˇcas), bezpeˇcn´ y ˇcas (pokud je pˇripojeno ˇcasové raz´ıtko, zjist´ı se ˇcasov´ yu ´daj z nˇej, jinak se vezme aktuáln´ı systémov´ y ˇcas) a tˇret´ı moˇznost - ˇcas, kdy byl podpis vytvoˇren (bez ohledu na to, zda pocház´ı z ˇcasového raz´ıtka, nebo ze systémov´ ych hodin). Zaráˇzej´ıc´ı je fakt, ˇze implicitn´ı nastaven´ı aplikace Adobe Reader je moˇznost tˇret´ı, tedy ˇcas, kdy byl podpis vytvoˇren, bez ohledu na p˚ uvod. To je pochopitelnˇe ˇspatnˇe, nebot’ m˚ uˇze j´ıt o podvrˇzen´ y ˇcas (viz kapitola 3.3.2), uˇzivatel m˚ uˇze b´ yt klamán, ˇze se jedná o správn´ y podpis a jelikoˇz neprovedl ˇra´dnou kontrolu elektronického podpisu v souladu s legislativou, m˚ uˇze pˇrij´ıt o nárok na náhradu ˇskody. Správnou volbou tedy má b´ yt bez” peˇcn´ y ˇcas“. Dalˇs´ı nebezpeˇcnou funkcionalitou m˚ uˇze b´ yt zobrazován´ı identity z popisku podpisu a nikoliv z certifikátu, m˚ uˇze tedy doj´ıt k mylné identifikaci (aˇckoliv v detailech podpisu je jiˇz uvedeno správné jméno osoby).[16] Po prostudován´ı dalˇs´ıch pˇr´ıpad˚ u aplikac´ı v téˇze knize RNDr. Ing. Jiˇr´ıho Peterky lze konstatovat, ˇze stav aplikac´ı nen´ı ideáln´ı a témˇeˇr vˇsude nalezneme alespoˇ n zavádˇej´ıc´ı informace, které by si uˇzivatel bez znalost´ı digitáln´ıch podpis˚ u mohl ˇspatnˇe vyloˇzit.

3.7 3.7.1

Form´ aty pokroˇ cil´ ych el. podpis˚ u Pˇ rehled

V této práci budu ˇcasto zmiˇ novat formáty pokroˇcil´ ych elektronick´ ych podpis˚ u (Advanced Electronic Signatures). Z hlediska procesu podepisován´ı dokument˚ u elektronick´ ym podpisem a z hlediska následného ovˇeˇrován´ı elektro28



nického podpisu nepˇrináˇs´ı formáty pokroˇcil´ ych elektronick´ ych podpis˚ u nic nového. Jedná se o formáty, které jsou svoj´ı strukturou uzp˚ usobeny k tomu, aby veˇskeré informace, které jsou k ovˇeˇren´ı elektronického podpisu potˇrebné, byly uchovány v jedné struktuˇre. Kromˇe samotného elektronického podpisu se jedná o certifikát, na jehoˇz základˇe byl podpis vystaven, veˇskeré jemu nadˇrazené certifikáty, ke vˇsem uveden´ ym certifikát˚ um pˇr´ısluˇsné CRL seznamy a ˇcasová raz´ıtka, která udrˇz´ı ˇcasovou kontinuitu od doby podepsán´ı po dobu ovˇeˇren´ı. Dohromady tyto informace naplˇ nuj´ı koncept dlouhodobého ovˇeˇren´ı – LTV (Long Term Validation). Evropsk´ y institut pro telekomunikaˇcn´ı standardy (ETSI) vytvoˇril sadu norem, které se vztahuj´ı k elektronick´ ym podpis˚ um a ˇcasov´ ym raz´ıtk˚ um, mezi nimi i normy, které popisuj´ı tˇri standardy pokroˇcil´ ych elektronick´ ych podpis˚ u: ∙ PAdES – PDF Advanced Electronic Signatures (urˇcené pro elektronick´ y podpis dokument˚ u ve formátu PDF). ∙ XAdES – XML Advanced Electronic Signatures (urˇcené pro elektronick´ y podpis ve formátu XML, kter´ y umoˇzn ˇuje podepsán´ı ˇca´sti XML dokumentu nebo extern´ıho obsahu bez ohledu na to, v jakém formátu tento obsah je). ∙ CAdES – CMS Advanced Electronic Signatures (urˇcené pro elektronick´ y podpis ve formátu CMS, kter´ y umoˇzn ˇuje podepisován´ı zpráv vˇcetnˇe jejich veˇskerého obsahu). Evropská komise sv´ ym v´ ynosem 2011/130/EU tyto formáty (v u ńoru 2011) oznaˇcila jako referenˇcn´ı a uloˇzila ˇclensk´ ym stát˚ um, aby je pˇrijaly do své legislativy. Orgány státn´ı správy ˇclensk´ ych stát˚ u EU maj´ı povinnost pˇrijmout elektronick´ y dokument, pokud je ˇra´dnˇe podepsán elektronick´ ym podpisem v jednom z v´ yˇse uveden´ ych formát˚ u. V´ ynos pˇripouˇst´ı i pouˇzit´ı jiného formátu elektronického podpisu, pak ale mus´ı b´ yt splnˇena ˇrada dalˇs´ıch podm´ınek. ˇ Ceská legislativa tyto formáty pˇrijala ve své novele zákona o archivnictv´ı a spisové sluˇzbˇe (499/2004 Sb.) a zákona o elektronickém podpisu (227/2000 Sb.).

3.7.2

XAdES

V této práci se budu podrobnˇeji zab´ yvat formátem XAdES. XAdES formát vycház´ı z formátu XMLDSig a je rozliˇsován v nˇekolika u ´rovn´ıch podle toho, jaké informace obsahuje: 29



∙ XAdES-BES (Basic Electronic Signature) – je základn´ı rozˇs´ıˇren´ı podpisu (XMLDSig), které pˇridává vlastnosti podpisu, jeˇz jsou urˇceny k podepsán´ı, a vlastnosti, jeˇz k podepsán´ı urˇceny nejsou. ∙ XAdES-EPES (Explicit Policy based Electronic Signature) – je dalˇs´ım základn´ım rozˇs´ıˇren´ım, které je alternativou k XAdES-BES. Pˇrináˇs´ı to samé, co XAdES-BES, a nav´ıc obsahuje element, v nˇemˇz jsou vyjádˇrena pravidla podpisu (Signature Policy). ∙ XAdES-T (XML Advanced Electronic Signature with Time) – je rozˇs´ıˇren´ı, které vycház´ı z formátu XAdES-BES, nebo XAdES-EPES, a které pˇridává ˇcasové raz´ıtko podpisu. ∙ XAdES-C (Electronic signature with complete validation data references) – je rozˇs´ıˇren´ı formátu XAdES-T o kompletn´ı soubor odkaz˚ u na vˇsechny certifikáty, které jsou potˇrebné k validaci podpisu, a na jejich CRL seznamy. ∙ XAdES-X (Extended signatures with time forms) – je rozˇs´ıˇren´ı formátu XAdES-C, ke kterému je nav´ıc pˇridáváno ˇcasové raz´ıtko, u kterého rozliˇsujeme dva r˚ uzné druhy: RefsOnlyTimeStamp zahrnuje pouze odkazy na certifikáty a revokaˇcn´ı seznamy. SigAndRefsTimeStamp zahrnuje nav´ıc i hodnotu podpisu. ∙ XAdES-X-L (Extended long electronic signatures with time) – je rozˇs´ıˇren´ı formátu XAdES-X, které nav´ıc pˇridává i hodnoty certifikát˚ u a revokaˇcn´ıch seznam˚ u. ∙ XAdES-A (Archival electronic signatures) – je rozˇs´ıˇren´ım formátu XAdES-A a zároveˇ n nejkompletnˇejˇs´ı moˇzná u ´roveˇ n tohoto formátu. Umoˇzn ˇuje nav´ıc vkládat archivaˇcn´ı ˇcasová raz´ıtka a splˇ nuje tak koncept LTV. Struktura formátu XAdES podle u ´rovn´ı znázorˇ nuje schéma na obrázku 3.2.

30



´ Obrázek 3.2: Urovnˇ e formátu XAdES (zdroj: W3C.org).

31

4 Systém správy dokument˚ u Microsoft SharePoint Mezi nejrozˇs´ıˇrenˇejˇs´ı systémy správy dokument˚ u (Document Management System - DMS )patˇr´ı Microsoft SharePoint. V této práci se budu zab´ yvat systémem Microsoft SharePoint 2010. SharePoint 2010 je vydáván ve tˇrech r˚ uzn´ ych edic´ıch – Foundation, Standard a Enterprise, které se od sebe liˇs´ı sv´ ymi funkcemi a cenou licenc´ı. Pokud budou patˇrit nˇekteré informace pouze ke konkrétn´ı edici, bude to explicitnˇe uvedeno.

4.1

Pˇ rehled sluˇ zby

Microsoft rozdˇeluje sluˇzby platformy SharePoint do ˇsesti odd´ıl˚ u: ∙ Sites – tento odd´ıl poskytuje organizac´ım strukturu, na které mohou postavit své intern´ı weby. ∙ Communities – pˇredstavuje nástroje pro interakci s jin´ ymi uˇzivateli (poskytuje vlastn´ı, zjednoduˇsenou Wiki a podobnˇe). ∙ Content – z pohledu dokument˚ u se jedná o nejd˚ uleˇzitˇejˇs´ı odd´ıl SharePointu. Umoˇzn ˇuje ˇskálovat dokumenty a poloˇzky do typ˚ u, které lze definovat na základˇe metadat. Jednotliv´ ym typ˚ um obsahu lze nastavovat pˇredpisy ve formˇe pracovn´ıch postup˚ u (workflow), podle kter´ ych je pak s dokumenty zacházeno. ∙ Search – je modulem pro vyhledáván´ı. Zde se liˇs´ı pokroˇcilost vyhledáván´ı podle zvolené edice. Napˇr´ıklad edice Foundation poskytuje klasické vyhledáván´ı. Edice Standard nab´ız´ı nav´ıc integraci s vyhledáván´ım v operaˇcn´ım systému Windows 7, fonetické vyhledáván´ı, návrhy dotaz˚ u a nastavován´ı rozsahu. Edice Enterprise pˇridává vyuˇz´ıván´ı metadat, kontextové vyhledáván´ı na základˇe uˇzivatelského profilu a celkovˇe rozˇsiˇritelnou platformu vyhledáván´ı (ve skuteˇcnosti poskytuj´ı edice Standard a Enterprise mnohem v´ıce pokroˇcil´ ych funkc´ı). ∙ Insights – tento odd´ıl poskytuje ˇradu sluˇzeb pro anal´ yzu dat, Business Intelligence, Excel Services (tvorba interaktivn´ıch Excel list˚ u a jejich 32

Systém správy dokument˚ u Microsoft SharePoint

Architektura

moˇzná integrace do jin´ ych aplikac´ı pomoc´ı REST API) a dalˇs´ı. Tento odd´ıl je dostupn´ y pouze v edici Enterprise. ∙ Composites – je odd´ıl pro vytváˇren´ı vlastn´ıch ˇreˇsen´ı. Jednoduˇse jsou to nástroje pro pˇrizp˚ usoben´ı SharePointu – upgrade ze SharePoint 2007, SharePoint designer, klientské i serverové API, dotazován´ı pomoc´ı jazyka LINQ, podpora technologie Silverlight a v edici Enterprise i integrace se sluˇzbami InfoPath (tvorba formuláˇr˚ u).[17] Sluˇzba SharePoint vyˇzaduje ke svému bˇehu Windows Server 2008. Je hostována sluˇzbami IIS (Internet Information Services for Windows Server). Kromˇe v´ yˇse uveden´ ych edic je nab´ızen v rámci programu Office 365 i SharePoint Online. Jedná se o sluˇzbu SharePoint, která je hostována v Microsoft Data Center.

4.2

Architektura

Pro pochopen´ı jednotliv´ ych pojm˚ u, se kter´ ymi budu zacházet, je nutné znát architekturu SharePoint 2010. Sluˇzba SharePoint se skládá z jednoho, nebo v´ıce SharePoint server˚ u (lze je specializovat na poskytován´ı konkrétn´ı SharePoint sluˇzby). Mnoˇzina vˇsech SharePoint server˚ u, které jsou navzájem propojeny, je takzvaná Sharepoint farma (Farm). Kaˇzd´ y ze server˚ u farmy m˚ uˇze hostovat jednu, nebo v´ıce webových aplikac´ı (Web Application). Kaˇzdá webová aplikace m˚ uˇze hostovat jednu, nebo v´ıce kolekc´ı stránek (Sites Collection), ty obsahuj´ı jednu nebo v´ıce stránek (Site) a kaˇzdá stránka m˚ uˇze obsahovat seznamy (Lists). Speciáln´ım pˇr´ıpadem seznamu mohou b´ yt knihovny r˚ uzn´ ych typ˚ u (dokument˚ u, multimedi´ı, vlastn´ıch typ˚ u). Kompozice sluˇzeb SharePointu na u ´rovni farmy je dostupná vˇsem webov´ ym aplikac´ım, bez ohledu na to, na kterém serveru webová aplikace bˇeˇz´ı.

4.3

Word Automation Services

Z hlediska práce s dokumenty nás budou na sluˇzbˇe SharePoint zaj´ımat hlavnˇe Word Automation Services. Jedná se o sluˇzby, které jsou spuˇstˇeny na Share33

Systém správy dokument˚ u Microsoft SharePoint Word Automation Services

Point Serveru 2010, o sluˇzby, které jsou navrˇzeny pro doplnˇen´ı Open XML SDK na stranˇe SharePoint Serveru. Word Automation Services jsou urˇceny v´ yhradnˇe pro volán´ı ze strany serveru, nem˚ uˇzeme je tedy vyuˇz´ıvat v aplikaci, která je spuˇstˇena na stanici klienta SharePoint sluˇzeb. Tyto sluˇzby jsou dostupné pouze ve verz´ıch Standard a Enterprise.

34

5 Analýza 5.1

Form´ aty sloˇ zen´ ych dokument˚ u

Na základˇe informac´ı, které jsem o jednotliv´ ych dokumentov´ ych formátech uvedl v kapitole 2, a na základˇe kritéri´ı, které jsem si stanovil v kapitolách 2.1.1, 2.1.2 a 2.1.3, mohu mezi sebou dokumentové formáty porovnat a doporuˇcit nˇekteré k podpoˇre v DMS systému.

5.1.1

PDF

Uˇ zivatelsk´ a manipulace

Nen´ı urˇceno pro bˇeˇznou uˇzivatelskou manipulaci, je umoˇznˇena zpravidla placen´ ymi jedno´ uˇcelov´ ymi programy.

Automatick´ e skl´ ad´ an´ı dokument˚ u

Existuj´ı kvalitn´ı knihovny pro skládán´ı dokument˚ u, je moˇzné skládat PDF dokumenty pomoc´ı XSL-FO.

Archivace (el. podpisy aˇ casov´ a raz´ıtka)

Podpora standard˚ u pro podepisován´ı a archivaci, vnitˇrn´ı struktura uzp˚ usobená ke vkládán´ı podpis˚ u a ˇcasov´ ych raz´ıtek.

Dalˇ s´ı aspekty

Jedná se o archivaˇcn´ı a grafick´ y standard.

Tabulka 5.1: Shrnut´ı vlastnost´ı formátu PDF.

35

Analýza

5.1.2

Formáty sloˇzených dokument˚ u

OOXML


Podporována celou ˇradou (i bezplatn´ ych) aplikac´ı. Moˇznost tvorby ˇsablony.


Kvalitn´ı knihovny i pro vysoko´ urovˇ novou manipulaci s obsahy dokument˚ u.


Vnitˇrn´ı struktura uzp˚ usobená ke vkládán´ı podpis˚ u a ˇcasov´ ych raz´ıtek.

Dalˇ s´ı aspekty

Silnˇe podporováno na platformˇe .NET, standardn´ı formát pro SharePoint.

Tabulka 5.2: Shrnut´ı vlastnost´ı formátu OOXML.

5.1.3

ODF


Podporována celou ˇradou (i bezplatn´ ych) aplikac´ı. Moˇznost tvorby ˇsablon.


Kvalitn´ı knihovny jsou. Vysoko´ urovˇ nová manipulace s obsahem sp´ıˇse nen´ı.


Vnitˇrn´ı struktura uzp˚ usobená ke vkládán´ı podpis˚ u a ˇcasov´ ych raz´ıtek.

Dalˇ s´ı aspekty

Pˇrijat jako národn´ı standard v nˇekter´ ych zem´ıch.

Tabulka 5.3: Shrnut´ı vlastnost´ı formátu ODF.

36

Analýza

5.1.4


XSL-FO


Nen´ı moˇzná.


Nároˇcná pˇr´ıprava dokumentu mace). Následné plnˇen´ı snadné.


Dokument nen´ı urˇcen k archivaci. Lze jej podepsat pˇripojen´ım extern´ıho podpisu, ale po XSL transformaci nebude c´ılov´ y dokument podepsán.

Dalˇ s´ı aspekty

V´ yborná automatická tvorba PDF dokument˚ u (pokud nepotˇrebujeme ˇcasto mˇenit vzhled).

(transfor-

Tabulka 5.4: Shrnut´ı vlastnost´ı formátu XSL-FO.

5.1.5

RTF


´ Uroveˇ n uˇzivatelské manipulace se znaˇcnˇe liˇs´ı - záleˇz´ı na zvoleném programu. Obecnˇe lze ˇr´ıci, ˇze uˇzivatelská manipulace je podporována.


Absence spolehliv´ ych knihoven, které by odpov´ıdaly konkrétn´ı specifikaci. Pouze n´ızkou ´rovˇ nová manipulace obsahu.


Struktura dokumentu nen´ı pˇrizp˚ usobena pro vkládán´ı podpis˚ u a raz´ıtek. Je moˇzné vytvoˇrit extern´ı podpis (respektive raz´ıtko), pokud máte vhodn´ y program.

Dalˇ s´ı aspekty

Silnˇe rozˇs´ıˇren. Mnoho verz´ı specifikace, programy vˇetˇsinou zvládnou vˇsechny verze alespoˇ n ˇca´steˇcnˇe zpracovat. V´ ysledky se liˇs´ı.

Tabulka 5.5: Shrnut´ı vlastnost´ı formátu RTF. 37

Analýza

5.1.6


Porovn´ an´ı

Tyto souhrnné aspekty jsem objektivnˇe obodoval v jednotliv´ ych kritéri´ıch v rozmez´ı 0 - 5 bod˚ u (5 - nejlepˇs´ı) podle m´ıry naplnˇen´ı tˇechto oblast´ı (tabulka 5.6). Vˇsem kritéri´ım jsem pˇriˇradil stejnou váhu.

Formát dokumentu Oblast zkoum´ an´ı

PDF OOXML ODF XSL-FO RTF


1

5

5

0

3

Automatick´ e skl´ ad´ an´ı dok.

4

5

3

3

1

Archivace

5

3

3

0

1

Dalˇ s´ı aspekty

3

3

2

5

2

Souˇ cet

13

16

13

8

7

Tabulka 5.6: Ohodnocen´ı a porovnán´ı vlastnost´ı zkoumaných formát˚ u.

5.1.7

V´ ybˇ er

Z v´ ysledk˚ u porovnán´ı mohu konstatovat, ˇze mezi nejlepˇs´ımi formáty se um´ıstilo OOXML, PDF a ODF. M´ ym doporuˇcen´ım je pouˇz´ıvat formát PDF k archivaci dokument˚ u, nebot’ je k tomu ideálnˇe pˇrizp˚ usoben. Pro ostatn´ı u ´ˇcely doporuˇcuji pouˇz´ıt formát OOXML, nebot’ je silnˇe podporován na platformˇe .NET, je standardn´ım formátem systému MS SharePoint, hod´ı se pro uˇzivatelskou editaci a v neposledn´ı ˇradˇe je vhodn´ y pro automatizované skládán´ı. Formát ODF hodnot´ım také jako pouˇziteln´ y, avˇsak jedná se o formát s podobn´ ymi vlastnostmi jako OOXML. Na rozd´ıl od OOXML nemá takovou podporu. O jeho zaveden´ı bych uvaˇzoval v zem´ıch, které jej pˇrijaly jako sv˚ uj 38

Analýza

Kritéria aplikace

standard. Formát XSL-FO pochopitelnˇe v mnohém ztrác´ı, dá se vˇsak vyuˇz´ıt jako doplˇ nkov´ y formát pro tvorbu PDF. Formát RTF dopadl nejh˚ uˇre a k uˇz´ıván´ı jej nedoporuˇcuji. Na základˇe tohoto závˇeru upravila spoleˇcnost CCA Group své poˇzadavky a zadala implementaci formátu OOXML, konkrétnˇe formátu dokument˚ u DOCX.

5.2 5.2.1

Krit´ eria aplikace Platforma .NET

Spoleˇcnost CCA Group je partnerem spoleˇcnosti Microsoft a nab´ız´ı ˇreˇsen´ı systému správy dokument˚ u od této firmy (Microsoft SharePoint) a také vyv´ıj´ı systémy na bázi ASP.NET. Zároveˇ n nemá pro tuto platformu vlastn´ı ˇreˇsen´ı, které by umoˇzn ˇovalo skládán´ı dokument˚ u a pˇripojován´ı elektronick´ ych podpis˚ u. Mimo to lze pˇredpokládat, ˇze je na pracovn´ıch stanic´ıch uvnitˇr podnik˚ u pouˇz´ıván operaˇcn´ı systém Windows (ˇcasto ve verzi 7 nebo vyˇsˇs´ı) a mnohdy i kanceláˇrsk´ y bal´ık Office, kter´ y by bylo moˇzné touto aplikac´ı obohatit. Tyto d˚ uvody vy´ ustily v poˇzadavek spoleˇcnosti CCA Group, aby byla aplikace napsána pro platformu .NET.

5.2.2

Nez´ avislost datov´ ych zdroj˚ u

Aplikace mus´ı b´ yt navrˇzena tak, aby umoˇzn ˇovala vyuˇzit´ı r˚ uzn´ ych datov´ ych zdroj˚ u. Nelze se spolehnout, ˇze bude moˇzné ˇc´ıst a zapisovat soubory na pevn´ y disk stanice (respektive serveru). Je velmi pravdˇepodobné, ˇze systém bude fungovat tak, ˇze dokumenty budou ukládány a naˇc´ıtány z databáze a aplikace nebude m´ıt práva pˇristupovat k pevnému disku stanice.

5.2.3

Modularita jednotliv´ ych ˇ c´ ast´ı aplikace

Aplikace se bude skládat z oddˇelen´ ych logick´ ych celk˚ u (skládán´ı dokument˚ u, plnˇen´ı dokument˚ u, pˇripojován´ı podpis˚ u). Poˇzadavkem je, aby byly tyto ˇcásti navrˇzeny tak, aby byly snadno vymˇenitelné.

39

Analýza

5.2.4

Kritéria aplikace

Integrace aplikace do syst´ emu spr´ avy dokument˚ u

Spoleˇcnost CCA Group chce nad rámec standardn´ıho zadán´ı analyzovat stav moˇznosti skládán´ı dokument˚ u a pˇripojován´ı elektronick´ ych dokument˚ u v systému Microsoft SharePoint a pˇr´ıpadnˇe mnou navrˇzenou aplikaci integrovat do tohoto systému.

40

6 Základn´ı aplikace – MergeSignModul 6.1

Architektura

Na základˇe v´ yˇse uveden´ ych poˇzadavk˚ u a naˇsich dˇr´ıvˇejˇs´ıch zkuˇsenost´ı jsem pro tvorbu aplikace vybral jazyk C#. Aplikace bude m´ıt formu dynamické knihovny tˇr´ıd.

6.1.1

Kontext aplikace

Je naznaˇcen v diagramu na obrázku 6.1. Uˇzivatel Systém“ pˇredstavuje apli” kaci, která vyuˇz´ıvá funkcionalitu knihovny. M˚ uˇze se jednat napˇr´ıklad o webovou, nebo desktopovou aplikaci.

6.1.2

Struktura modulu

Aplikace poskytuje tˇri základn´ı funkˇcnosti, které jsou po n´ı poˇzadovány:

Obrázek 6.1: Kontextový diagram aplikace (zdroj: autor).

41

Základn´ı aplikace – MergeSignModul

Architektura

∙ Spojován´ı dokumentu typu OOXML z d´ılˇc´ıch dokument˚ u. ∙ Plnˇen´ı námi pˇreddefinovan´ ych OOXML ˇsablon vlastn´ımi daty. ∙ Podepisován´ı OOXML dokument˚ u elektronick´ ym podpisem a pˇripojován´ı elektronick´ ych ˇcasov´ ych raz´ıtek. Defaultn´ım jmenn´ ym prostorem aplikace je MergeSignModul. V tomto jmenném prostoru je implementován manaˇzer modulu. Dalˇs´ı jmenné prostory odpov´ıdaj´ı v´ yˇse uvedené funkcionalitˇe a kaˇzd´ y z nich pˇredstavuje samostatnˇe funguj´ıc´ı celek: ∙ MergeSignModul.Merge (spojován´ı dokument˚ u) ∙ MergeSignModul.Fill (plnˇen´ı ˇsablon daty) ∙ MergeSignModul.Sign (podepisován´ı elektronick´ ym podpisem a pˇripojován´ı ˇcasov´ ych raz´ıtek) Pro co nejvyˇsˇs´ı modularitu jsem ke kaˇzdé funkcionalitˇe navrhl rozhran´ı, které tˇr´ıdy s odpov´ıdaj´ıc´ı funkcionalitou implementuj´ı. Zároveˇ n jsem modul navrhl tak, aby odpov´ıdal návrhovému vzoru dependency injection. Na nejvyˇsˇs´ı u ´rovni aplikace je definován manaˇzer. Ten vytváˇr´ı instance tˇr´ıd, které implementuj´ı daná rozhran´ı, a zastává tak funkci tˇr´ıdy, která b´ yvá v dependency injection oznaˇcována assembler [18]. Informaci o tom, jakou implementaci má zvolit, z´ıskává manaˇzer z konfiguraˇcn´ıho kontejneru config.xml. T´ımto zp˚ usobem se odstiˇ nuje volba konkrétn´ıch implementac´ı od programového kódu a centralizuje se na jednom m´ıstˇe.

6.1.3

Pˇ red´ av´ an´ı dat a odst´ınˇ en´ı datov´ ych zdroj˚ u

V kapitole 5.2.2 jsem zm´ınil, ˇze modul mus´ı b´ yt nezávisl´ y na datov´ ych zdroj´ıch. Zároveˇ n je vhodné, aby jednotlivé ˇca´sti modulu fungovaly nezávisle na sobˇe, aby bylo napˇr´ıklad moˇzné dokument pouze podepsat. Z tˇechto d˚ uvod˚ u se dokumenty pˇredávaj´ı a zpracovávaj´ı ve formˇe obecn´ ych datov´ ych proud˚ u (zdˇedˇen´ ych od abstraktn´ı tˇr´ıdy System.IO.Stream).

42


6.1.4

Implementace

Pˇ rehled tˇ r´ıd

D˚ uleˇzité tˇr´ıdy jsou vyznaˇceny v diagramu na obrázku 6.1.4. Podrobnˇejˇs´ı popis d˚ uleˇzit´ ych tˇr´ıd naleznete v kapitole 6.2.

6.2

Implementace

V této kapitole budou popsány hlavn´ı tˇr´ıdy aplikace.

6.2.1

Tˇ r´ıda MFSManager

MFSManager je tˇr´ıda, která implementuje rozhran´ı IMFSManager a slouˇz´ı jako vstupn´ı bod modulu. Konstruktory této tˇr´ıdy zajiˇst’uj´ı naˇcten´ı konfigurace modulu a vytvoˇren´ı instanc´ı ostatn´ıch potˇrebn´ ych tˇr´ıd na základˇe této konfigurace. Pˇr´ıklad vytváˇren´ı instanc´ı podle nastaven´ı: this.mergeService = (IMergeService)System.Reflection.Assembly .GetExecutingAssembly().CreateInstance( "MergeSignModul.Merge." +(String)settings["MergeService"]);

Tˇr´ıda dále obsahuje veˇrejné metody pro volán´ı skládán´ı dokumentu Merge(), plnˇen´ı dokumentu Fill() a podepisován´ı dokumentu Sign(). Obsahuje také metody pro vyvolán´ı vˇsech u ´kon˚ u MergeFillSign() a FillMergeSign().

6.2.2

Tˇ r´ıda AltChunkMergeService

AltChunkMergeService je tˇr´ıda, která implementuje rozhran´ı IMergeService. Tato tˇr´ıda poskytuje funkˇcnost spojován´ı dokument˚ u pomoc´ı odkazován´ı na existuj´ıc´ı celky. To je realizováno pomoc´ı AltChunk element˚ u a obsahu ve formátu AlternativeFormatImportPart, které poskytuje OpenXML SDK. AltChunk je element Wordprocessing dokumentu, kter´ y slouˇz´ı jako kotva pro um´ıstˇen´ı importovaného obsahu do hlavn´ı ˇcásti dokumentu. Umoˇzn ˇuje vloˇzen´ı extern´ıho obsahu nebo obsahu, kter´ y je pˇr´ımo souˇca´st´ı OOXML bal´ıku. V obou pˇr´ıpadech je tento obsah importován jako AlternativeFormatImportPart. Tento kontejner umoˇzn ˇuje import dat v r˚ uzn´ ych formátech – 43


Implementace

Obrázek 6.2: UML diagram tˇr´ıd se znázornˇen´ım jmenných prostor˚ u (zdroj: autor).

44


Implementace

Text (.txt), Extensible HyperText Markup Language File (.xhtml), HyperText Markup Language File (.htm), Rich Text Foramt (.rtf), Wordprocessing (.docx) a dalˇs´ıch. Právˇe vkládán´ı celého DOCX dokumentu vyuˇz´ıvá tato metoda. Ve v´ ysledku AltChunkMergeService vrac´ı dokument, jehoˇz souˇca´st´ı jsou nezmˇenˇené d´ılˇc´ı dokumenty, a dokument, kter´ y definuje jejich um´ıstˇen´ı. Zaj´ımavou vlastnost´ı je, ˇze pokud dokument s importovan´ ym obsahem v aplikaci Microsoft Word znovu uloˇz´ıme, jsou importované ˇca´sti slouˇceny do hlavn´ıho dokumentu.

6.2.3

Tˇ r´ıda PTMergeService

PTMergeService je dalˇs´ı tˇr´ıda, která implementuje rozhran´ı IMergeService a umoˇzn ˇuje spojovat v´ıce DOCX dokument˚ u v jeden. Pˇredstavuje alternativu k pouˇzit´ı AltChunkMergeService a na rozd´ıl od této tˇr´ıdy nevyuˇz´ıvá import celk˚ u, ale vytváˇr´ı zcela nov´ y dokument pomoc´ı DocumentBuilder tˇr´ıdy, kterou poskytuje knihovna OpenXmlPowerTools. Tˇr´ıda DocumentBuilder se sama stará o správné slouˇcen´ı styl˚ u jednotliv´ ych dokument˚ u a umoˇzn ˇuje tak ˇcistˇe vysoko´ urovˇ nov´ y pˇr´ıstup. AltChunkMergeService a PTMergeService vyuˇz´ıvaj´ı zcela odliˇsné pˇr´ıstupy a tomu odpov´ıdaj´ı i specifické vlastnosti ohlednˇe v´ ykonnosti a kvality v´ ysledk˚ u. Tyto vlastnosti budou pozdˇeji v kapitole 9 rozebrány a podloˇzeny testován´ım.

6.2.4

Tˇ r´ıda SimpleFillService

SimpleFillService je tˇr´ıda, která implementuje rozhran´ı IFillService a umoˇzn ˇuje plnit ˇsablony dokumentu textem. Moˇznost´ı, jak naplnit dokument textem, je celá ˇrada. WordprocessingML napˇr´ıklad umoˇzn ˇuje definovat vlastn´ı metadata a zároveˇ n tato metadata vkládat do tˇela dokumentu. Dalˇs´ı moˇznost´ı je nadefinovat si vlastn´ı znaˇcku jako posloupnost znak˚ u a tuto znaˇcku nahrazovat konkrétn´ım textem. Vyh´ ybám se tak pouˇz´ıván´ı metadat v tˇele dokumentu a uˇzivatel, kter´ y bude cht´ıt tvoˇrit ˇsablonu, nebude potˇrebovat pokroˇcilé znalosti ovládán´ı aplikace Microsoft Word. SimpleFillService pouˇz´ıvá metodu FindTags() z rozhran´ı ITagsLoader, která v ˇsablonˇe nalezne znaˇcky pro um´ıstˇen´ı vlastn´ıho textu. Metoda Fill() tˇr´ıdy SimpleFillService v dokumentu nahrad´ı text znaˇcky za uˇzivatelsk´ y text.

45


6.2.5

Implementace

Tˇ r´ıda SimpleTagsLoader

SimpleTagsLoader je tˇr´ıda, která implementuje rozhran´ı ITagsLoader a vyhledává v textu znaˇcky ve tvaru <<jmeno_parametru>>. Mnou navrˇzen´ y mechanismus umoˇzn ˇuje snadnou v´ ymˇenu znaˇcek pro um´ıstˇen´ı textu. Staˇc´ı vytvoˇrit jinou implementaci rozhran´ı ITagsLoader a tˇr´ıda SimpleFillService bude fungovat bez jakékoliv zmˇeny.

6.2.6

Tˇ r´ıda XmlDsigService

Tˇr´ıda XmlDsigService implementuje rozhran´ı ISignService a umoˇzn ˇuje vkládat intern´ı podpisy ve formátu XMLDSig do WordprocessingML dokument˚ u pomoc´ı standardn´ıch knihoven platformy .NET (System.Security a System.IO.Packaging).

6.2.7

Tˇ r´ıda XadesService

Dalˇs´ı tˇr´ıdou, která implementuje rozhran´ı ISignService, je tˇr´ıda XadesService. Na rozd´ıl od XmlDsigService neposkytuje pouze základn´ı podpis typu XMLDSig, ale jeho rozˇs´ıˇrenou verzi – XAdES. Jak jsem uvedl v kapitole 3.6.2, podpis formátu XAdES je rozliˇsován v nˇekolika u ´rovn´ıch podle informac´ı, které jsou v nˇem obsaˇzeny. XadesService poskytuje u ´rovnˇe T (Timestamp), C (Complete), X (eXtended), X-L (eXtended Long term). Neposkytuje nevyˇsˇs´ı u ´roveˇ n A (Archival) a nejniˇzˇs´ı u ´roveˇ n BES, nebo také EPES (která se v podstatˇe neliˇs´ı od základn´ıho formátu XMLDSig). Tˇr´ıda tedy ˇreˇs´ı nejen samotné podepisován´ı, ale i pˇripojen´ı ˇcasového raz´ıtka, pˇridán´ı odkaz˚ u na veˇskeré pouˇzité certifikáty v certifikaˇcn´ım ˇretˇezci, kter´ y byl k podpisu pouˇzit, pˇripojen´ı ˇcasového raz´ıtka po pˇridán´ı tˇechto informac´ı a nakonec i pˇridán´ı samotn´ ych certifikát˚ u certifikaˇcn´ıho ˇretˇezce a hodnoty revokaˇcn´ıch list˚ u. XadesService vyuˇz´ıvá prostˇredk˚ u knihovny Microsoft.Xades, která byla vytvoˇrena jako open source projekt Signature avancée (XAdES) pour Microsoft .NET Framework v3.5 francouzského t´ ymu v´ yvojáˇr˚ u spoleˇcnosti Microsoft a která byla publikována pod svobodnou CeCILL-B licenc´ı. Samotná knihovna Microsoft.Xades nen´ı zcela bezproblémová, pˇresto pˇredstavuje oproti ostatn´ım knihovnám tu nejlepˇs´ı moˇznou volbu. Dalˇs´ı moˇznost´ı byla knihovna XadesNet. Jej´ı autoˇri uvádˇej´ı, ˇze ve fináln´ı verzi bude poskytovat podpisy 46


Implementace

formátu XMLDsig, XAdES BES, T a C. Avˇsak jiˇz delˇs´ı dobu se knihovna nacház´ı ve stavu Beta“, ve kterém poskytuje pouze Formát XMLDsig a ” XAdES BES. Neˇreˇs´ı tak v˚ ubec z´ıskáván´ı ˇcasov´ ych raz´ıtek ani dalˇs´ı pokroˇcilé ˇcásti XAdES podpisu. Z´ıskáván´ı ˇcasov´ ych raz´ıtek naopak poskytuje knihovna BouncyCastle, která vˇsak neposkytuje ˇzádnou podporu XAdES formátu, ani formátu XMLDSig. Nejlépe tak dopadla knihovna Microsoft.Xades, i pˇres skuteˇcnost, ˇze bylo nutné ji rozˇs´ıˇrit o podepisován´ı extern´ıch soubor˚ u ve formátu datov´ ych proud˚ u, o moˇznost z´ıskávat CRL pˇres HTTP protokol a opravit chybu, která v pˇr´ıpadˇe vkládán´ı v´ıce certifikát˚ u certifikaˇcn´ıho ˇretˇezce vypoˇc´ıtávala jejich hash pouze z prvn´ıho z nich. Podpisy vytváˇrené tˇr´ıdou XadesService je moˇzné v pˇr´ıpadˇe potˇreby dále rozˇs´ıˇrit o archivaˇcn´ı ˇcasová raz´ıtka (´ uroveˇ n A).

6.2.8

Logov´ an´ı modulu

Jelikoˇz je modul urˇcen pro r˚ uzné typy aplikac´ı, vˇcetnˇe webov´ ych, je vhodné, aby bylo chován´ı modulu logováno. Pro tyto u ´ˇcely jsem v základn´ı implementaci zvolil nástroj NLog. Tato knihovna umoˇzn ˇuje snadné nastaven´ı ve vlastn´ım konfiguraˇcn´ım souboru, nebo ve web.xml. Podporuje logován´ı do soubor˚ u i do databáze a pouˇzit´ı je snadné. Staˇc´ı z´ıskat instanci loggeru: static Logger logger = LogManager.GetCurrentClassLogger();

a pak uˇz pouze zapisovat logovac´ı zprávy: logger.Warn("Spojov´ an´ ı vol´ ano bez vstupn´ ıch datastream˚ u.");

6.2.9

Konfigurace modulu

V kapitole 6.1 jsem uvedl, ˇze konfigurace modulu je uchovávána v souboru config.xml. K z´ıskán´ı informac´ı z tohoto souboru slouˇz´ı tˇr´ıda Model.Settings, která k dat˚ um v config.xml pˇristupuje jako k data setu. Tento pˇr´ıstup umoˇzn ˇuje v pˇr´ıpadˇe potˇreby snadnou zmˇenu u ´loˇziˇstˇe ze souboru na databázi.

47

7 Pomocné aplikace Pro jednoduˇsˇs´ı nastavován´ı modulu, ukázku jeho ˇcinnosti a otestován´ı v´ ysledk˚ u vznikaly menˇs´ı jedno´ uˇcelové aplikace. V této kapitole je ve struˇcnosti pˇredstav´ım.

7.1

MergeSignModulConfig

Jak bylo uvedeno v kapitole 6.1, v konstruktoru tˇr´ıdy MFSManager docház´ı k naˇc´ıtán´ı konfiguraˇcn´ıho souboru config.xml. Aby byl modul snáze nastaviteln´ y, vytvoˇril jsem MergeSignModulConfig. Jedná se o jednoduchou Windows Forms aplikaci, kterou uˇzivatel modulu um´ıst´ı do sloˇzky, ve které se bude nacházet config.xml. Pˇri jej´ım spuˇstˇen´ı si naˇcte aktuáln´ı verzi konfiguraˇcn´ıho souboru, pokud je dostupná. Pokud nen´ı dostupná, je vytvoˇrena zcela nová konfigurace. V podstatˇe je to velmi jednoduch´ y nástroj a zaj´ımavˇejˇs´ı funkcionalitu pˇredstavuje pouze tlaˇc´ıtko v´ ybˇeru certifikátu pro elektronick´ y podpis. Zm´ınˇené tlaˇc´ıtko otev´ırá u ´loˇziˇstˇe certifikát˚ u uˇzivatele s dostupn´ ymi platn´ ymi certifikáty a uˇzivatel si tak m˚ uˇze vybrat konkrétn´ı certifikát bez znalosti, jak se do tohoto u ´loˇziˇstˇe dostat za pomoci systémov´ ych prostˇredk˚ u. Ukázku aplikace naleznete na obrázku 7.1 a pˇr´ıklad v´ ybˇeru certifikátu na obrázku 7.2.

7.2

MergeSignApp

MergeSignApp je jednoduchá Windows Forms aplikace, která demonstruje pouˇzit´ı modulu MergeSignModul a zároveˇ n umoˇzn ˇuje testovat dobu potˇrebnou pro spojován´ı a plnˇen´ı dokumentu (obrázek 7.3). Aplikace poskytuje uˇzivatelské rozhran´ı pro volbu ˇsablon a moˇznost naˇcten´ı parametr˚ u ve formátu XML. XSD schéma a ukázku XML s parametry naleznete v pˇr´ıloze A. Dále si uˇzivatel zvol´ı poˇcet opakován´ı, kolikrát se má dokument vytvoˇrit. Tato funkcionalita ukazuje znovupouˇzitelnost ˇsablon a zároveˇ n umoˇzn ˇuje z´ıskat pˇresnˇejˇs´ı v´ ysledky mˇeˇren´ı doby skládán´ı a plnˇen´ı, pokud zvol´ıme, aby se tento proces nˇekolikrát opakoval.

48

Pomocné aplikace

MergeSignApp

Obrázek 7.1: Ukázka konfiguraˇcn´ı aplikace (zdroj: autor).

49

Pomocné aplikace

MergeSignApp

Obrázek 7.2: Ukázka výbˇeru certifikátu (zdroj: autor).

Obrázek 7.3: Bˇeh ukázkové aplikace (zdroj: autor). 50

Pomocné aplikace

XadesVerifyTool

Obrázek 7.4: Ukázka ovˇeˇreného podpisu (zdroj: autor).

7.3

XadesVerifyTool

Dalˇs´ı z ˇrady podp˚ urn´ ych aplikac´ı je jednoduchá Windows Forms aplikace, která je urˇcena k ovˇeˇrován´ı podpis˚ u ve formátu XAdES. Vyuˇz´ıvá prostˇredk˚ u, které poskytuje knihovna Microsoft.Xades k urˇcen´ı validity podpisu a nav´ıc rozpoznává u ´roveˇ n formátu XAdES, které podpis dosahuje (obrázek 7.4).

7.4

TestTimeToOpenDocument

Posledn´ı z podp˚ urn´ ych utilit je VSTO (Visual Studio Tools for Office) Word 2010 doplnˇek, kter´ y rozˇsiˇruje aplikaci Microsoft Word 2010 o moˇznost naˇc´ıtán´ı dokumentu s mˇeˇren´ım doby otev´ırán´ı dokumentu (obrázek 7.5).

51

Pomocné aplikace


Obrázek 7.5: Doplnˇek do aplikace Microsoft Word 2010, který umoˇzn ˇuje mˇeˇrit ˇcas otev´ırán´ı dokumentu (zdroj: autor).

52

8 Integrace modulu do systému Microsoft SharePoint 2010 ´ Ukolem v zadán´ı diplomové práce od spoleˇcnosti CCA Group bylo vytvoˇrit modul, kter´ y by umoˇznil automaticky skládat dokumenty, plnit je textem a pˇripojovat k nim elektronické podpisy a ˇcasová raz´ıtka. Spoleˇcnost CCA Group na základˇe v´ ysledk˚ u z kapitoly 6 vznesla návrh, zda by bylo moˇzné diplomovou práci rozˇs´ıˇrit o praktickou integraci vzniklého modulu do systému Microsoft SharePoint 2010 Standard. Vzhledem k tomu, ˇze jsem implementaci v kapitolách 6 a 7 zvládl s ˇcasov´ ym pˇredstihem a ˇze integrace modulu do systému SharePoint bude znamenat velk´ y pˇr´ınos pro spoleˇcnost CCA Group, rozhodl jsem se tento návrh pˇrijmout a vytvoˇrit praktickou ukázku pouˇzit´ı modulu v tomto systému, doplnˇek SPMergeSign.

8.1

N´ avrh integrace

Integrace modulu neznamená pouze uvést tento modul do funguj´ıc´ıho stavu, ale také navrhnout pˇr´ıstup k jeho vyuˇz´ıván´ı. Systém SharePoint 2010 poskytuje moˇznost definovat vlastn´ı seznamy (lists), typy obsahu webu (content types) a sloupce webu (site columns). Sloupce webu umoˇzn ˇuj´ı definovat datov´ y typ na u ´rovni stránek. Typy obsahu webu jsou typy, které jsou oddˇedˇené od jin´ ych typ˚ u obsahu webu (tˇech, které jsou implicitnˇe definované v systému SharePoint, nebo tˇech, které jsme si sami vytvoˇrili) a které je moˇzné rozˇs´ıˇrit o dalˇs´ı vlastnosti pˇridán´ım sloupc˚ u webu (ukázka vztah˚ u na obrázku 8.1). Seznam má definovan´ y typ obsahu, kter´ y m˚ uˇze obsahovat, a také ˇsablonu dokumentu, kterou m˚ uˇze t´ımto typem obsahu plnit. Sloupce webu, které tento typ obsahuje, se stanou metadaty dokumentu, a pokud byly v dokumentu um´ıstˇeny znaˇcky pro umist’ován´ı metadat, jsou vytváˇreny automatizované dokumenty, jak bylo popsáno v kapitole 6.3.4. Z tohoto hlediska má systém SharePoint automatické plnˇen´ı dokument˚ u vyˇreˇsené. Na prvn´ı pohled je vˇsak patrné, ˇze se tento zp˚ usob silnˇe váˇze na typ obsahu webu a na konkrétn´ı seznam, se kter´ ym je spojena ˇsablona dokumentu.

53

Integrace Modulu

Pouˇzit´ı SharePoint 2010 SDK

Obrázek 8.1: Pˇr´ıklad seznam˚ u, typ˚ u obsahu a sloupc˚ u webu (zdroj: autor). M´ ym pˇr´ınosem je doplnit funkˇcnost, která bude poskytována nad obecn´ ymi datov´ ymi typy a v´ ybˇer ˇsablony nebude omezován. Za t´ımto u ´ˇcelem rozˇs´ıˇr´ım kontextové menu poloˇzky seznamu (v terminologii systému SharePoint je naz´ yváno EditControlBlock ) o poloˇzku vytváˇren´ı dokumentu. Tato poloˇzka bude vyvolávat modáln´ı dialogové okno, jehoˇz obsahem bude nová aplikaˇcn´ı stránka (ASPX), která bude zobrazovat dostupné ˇsablony ve sloˇzce, která byla urˇcena konfigurac´ı modulu. Bude umoˇzn ˇovat jejich v´ ybˇer, nastaven´ı názvu v´ ystupn´ıho dokumentu a po potvrzen´ı z´ıská datové proudy zvolen´ ych ˇsablon, pouˇzije modul MergeSignModul, následnˇe uloˇz´ı v´ ysledn´ y datov´ y proud (respektive v´ ysledné datové proudy, pokud jsme vytváˇreli dokument s extern´ım elektronick´ ym podpisem) do zvolené knihovny systému SharePoint a nakonec uˇzivatele pˇresmˇeruje na tuto knihovnu. Proces vytváˇren´ı dokumentu pomoc´ı navrhovaného rozˇs´ıˇren´ı je popsán sekvenˇcn´ım diagramem na obrázku 8.2.

8.2

Pouˇ zit´ı SharePoint 2010 SDK

Pro rozˇs´ıˇren´ı funkcionality platformy SharePoint slouˇz´ı SharePoint 2010 SDK a v´ yvojové prostˇred´ı Microsoft Visual Studio 2010. Visual Studio obsahuje

54

Integrace Modulu

Pouˇzit´ı SharePoint 2010 SDK

Obrázek 8.2: Sekvenˇcn´ı diagram popisuj´ıc´ı proces tvorby dokumentu (zdroj: autor).

55

Integrace Modulu

Implementace UI a kontroloru

sadu ˇsablon projekt˚ u, které jsou urˇceny platformˇe SharePoint a zamˇeˇruj´ı se na rozˇs´ıˇren´ı specifick´ ych ˇca´st´ı této platformy (vizuáln´ı webové ˇca´sti, sekvenˇcn´ı workflow, definice seznamu, typ obsahu a dalˇs´ı). Mnou vytváˇrená integrace modulu bude vyuˇz´ıvat r˚ uzné ˇca´sti, a proto jsem zvolil obecn´ y SharePoint projekt. V´ yvojáˇr pro platformu SharePoint je pˇri vytváˇren´ı projektu vyzván, aby rozhodl, zda se bude jednat o sandbox ˇreˇsen´ı (ˇreˇsen´ı na omezeném p´ısko” viˇsti“), nebo farm ˇreˇsen´ı (ˇreˇsen´ı, které ovlivˇ nuje chod celé SharePoint farmy). V´ yhoda sandbox ˇreˇsen´ı je, ˇze bˇeˇz´ı v omezeném prostoru, kter´ y je systémem SharePoint plnˇe kontrolován a v pˇr´ıpadˇe, ˇze by spotˇrebovával pˇr´ıliˇs mnoho zdroj˚ u, jej SharePoint m˚ uˇze doˇcasnˇe ukonˇcit. Zároveˇ n se jedná o bezpeˇcné ˇreˇsen´ı, které nemá pˇr´ıstup k pevn´ ym disk˚ um serveru a mnohá dalˇs´ı omezen´ı. Tyto v´ yhody sandbox ˇreˇsen´ı jsou zároveˇ n i jeho nev´ yhody. Bohuˇzel nen´ı napˇr´ıklad moˇzné v sandbox ˇreˇsen´ı vyuˇz´ıvat assembly, které nejsou poskytovány systémem SharePoint. Z tohoto d˚ uvodu musel b´ yt projekt implementován jako farmové ˇreˇsen´ı.

8.3


V kapitole 8.1 jsem uvedl, ˇze k vytváˇren´ı dokumentu budu pˇristupovat skrze novou poloˇzku v kontextovém menu poloˇzky seznamu a samotné ovládán´ı bude realizováno skrze modáln´ı dialogové okno.

8.3.1

Poloˇ zka kontextov´ eho menu

Je vytváˇrena jako SharePoint 2010 Empty Element, kter´ y naváˇzeme na obecn´ y typ obsahu webu, a kterému vytvoˇr´ıme akci na kliknut´ı. XML kód pro tento element bude následuj´ıc´ı: <Elements xmlns="http://schemas.microsoft.com/sharepoint/">

56

Integrace Modulu


Obrázek 8.3: Poloˇzka kontextového menu (zdroj: autor).

8.3.2

Mod´ aln´ı dialogov´ e okno

Vyvolán´ı tohoto okna je ukázáno v programovém kódu v kapitole 8.3.1. Tˇelo okna je bˇeˇzná stránka aplikace (ASPX) a k n´ı patˇriˇcn´ y code-behind. Pro co nejjednoduˇsˇs´ı integraci modulu do systému SharePoint nebylo provádˇeno vrstven´ı aplikace, a tak byl kód kontroloru jednoduˇse vloˇzen do code-behind stránky. Jedná se hlavnˇe o komunikaci se SharePoint Server-Side API (z´ıskán´ı názv˚ u ˇsablon, z´ıskán´ı a ukládán´ı datov´ ych proud˚ u) a volán´ı modulu MergeSignModul. Dále jsou uvedeny pˇr´ıklady volán´ı SharePoint Server-Side API: Pˇr´ıklad z´ıskán´ı názv˚ u a adres ˇsablon: SPFolder templatesFolder = SPContext.Current.Web.Lists[ioListName] .RootFolder.SubFolders[infolderName];

57

Integrace Modulu


foreach (SPFile file in templatesFolder.Files) { ListBoxTemplAvailable.Items.Add(new ListItem(file.Name, file.Url)); }

Pˇr´ıklad uloˇzen´ı souboru do specifického adresáˇre: SPFolder outputFolder = SPContext.Current.Web.Lists[ioListName] .RootFolder.SubFolders[outfolderName]; outputFolder.Files.Add(outputName, outStream, true);

Obrázek 8.4: Ukázka modáln´ıho dialogu (zdroj: autor).

58

Integrace Modulu

8.4

Zmˇeny v modulu oproti základn´ı implementaci

Zmˇ eny v modulu oproti z´ akladn´ı implementaci

Pˇrestoˇze jsem projekt integrace vytvoˇril jako farmové ˇreˇsen´ı, pˇrinesl systém SharePoint nˇekterá omezen´ı a doporuˇcen´ı, kv˚ uli kter´ ym bylo nutné provést nˇekolik zásah˚ u do modulu.

8.4.1

Logov´ an´ı modulu

V základn´ı implementaci modulu byl pro logován´ı zvolen nástroj NLog. S jeho pomoc´ı je stále moˇzné i v aplikace bˇeˇz´ıc´ı na platformˇe SharePoint logovat, avˇsak doporuˇcené logován´ı je za pomoci standardn´ıch logovac´ıch prostˇredk˚ u systému SharePoint. Pro logován´ı je pak pouˇzit následuj´ıc´ı kód: SPDiagnosticsService.Local.WriteTrace(802, new SPDiagnosticsCategory("SPMergeSign", TraceSeverity.Monitorable, EventSeverity.None), TraceSeverity.Monitorable, "Spojov´ an´ ı vol´ ano bez vstupn´ ıch datastream˚ u.", null);

8.4.2

Konfigurace modulu

Pouˇzité farmové ˇreˇsen´ı umoˇzn ˇuje ˇc´ıst soubory z disku, bylo by tedy moˇzné ˇc´ıst konfiguraˇcn´ı soubor config.xml. Zároveˇ n SharePoint server vyuˇz´ıvá MS SQL databázi. Bylo by moˇzné pouˇz´ıt naˇc´ıtán´ı a ukládán´ı konfigurace i z databáze. SharePoint platforma má vˇsak pro ukládán´ı nastaven´ı vlastn´ı standardn´ı pˇr´ıstup – takzvan´ y Property Bag. Jedná se o standardizovan´ y zp˚ usob ukládán´ı nastaven´ı, kter´ y vyuˇz´ıvá databázi SharePoint serveru a zároveˇ n umoˇzn ˇuje divergovat nastaven´ı podle kontextu stránek. Farmové ˇreˇsen´ı tak m˚ uˇze b´ yt aplikace, která bˇeˇz´ı na v´ıce kolekc´ıch stránek, která má zároveˇ n pro jednotlivé kolekce stránek individuáln´ı nastaven´ı. Pˇr´ıklad pouˇzit´ı Property Bag: SPSite site = SPContext.Current.Site; SPWeb sitePropWeb = site.RootWeb; SPPropertyBag properties = sitePropWeb.Properties; if (properties.ContainsKey(valueName)) { property = (String)properties[valueName]; }

59

Integrace Modulu

8.4.3

Výsledek integrace

IfillService

Ukázalo se, ˇze v prostˇred´ı systému SharePoint nefunguje metoda SearchAndReplace() tˇr´ıdy TextReplacer z knihovny OpenXmlPowerTools pro OpenXml soubor zpracovávan´ y jako datov´ y proud. Bylo tak nutné nahradit implementaci rozhran´ı IfillService tˇr´ıdu SimpleFillService za jinou tˇr´ıdu, která by nevyuˇz´ıvala této metody. Pro potˇrebu doplˇ nku SPMergeService jsem vytvoˇril novou tˇr´ıdu, která implementuje rozhran´ı IfillService – SPEWFillService. Ta tˇr´ıdu TextReplacer nahrazuje tˇr´ıdou SearchAndReplacer, jej´ımˇz autorem je Eric White.[19]

8.4.4

´ ziˇ Uloˇ stˇ e digit´ aln´ıch certifik´ at˚ u

Aplikace, která bˇeˇz´ı pod kontextem SharePoint serveru, nemá právo exportovat primárn´ı kl´ıˇce digitáln´ıch certifikát˚ u z u ´loˇziˇstˇe stávaj´ıc´ıho uˇzivatele. Nem˚ uˇze tedy tyto certifikáty pouˇz´ıt k tvorbˇe elektronického podpisu. Proto ve tˇr´ıdách XmlDSigService a XadesService bylo nutné zmˇenit pouˇz´ıvané u ´loˇziˇstˇe za u ´loˇziˇstˇe stroje.

8.5

V´ ysledek integrace

Integrace probˇehla tak, jak bylo v kapitole 8.1 navrˇzeno. Uˇzivatel si vybere poloˇzku seznamu, kterou chce pouˇz´ıt k naplnˇen´ı dat, zvol´ı Vytvoˇrit doku” ment“, vybere jednu nebo v´ıce ˇsablon a zvol´ı, zda v´ ysledn´ y dokument také podepsat. V´ ysledek je pak uloˇzen do pˇredem urˇcené sloˇzky. Problém nastává bˇehem ukládán´ı dokumentu do systému SharePoint. Ten jej patrnˇe pˇri ukládán´ı pozmˇen´ı a t´ım zneplatn´ı podpisy, které jsou k tomuto dokumentu vytvoˇreny. Problém zcela jistˇe nen´ı v implementaci modulu, ale je zp˚ usoben systémem SharePoint. V pˇr´ıpadˇe, ˇze v´ ysledn´ y soubor neuloˇz´ıme do systému SharePoint, ale uloˇz´ıme jej pˇr´ımo na souborov´ y systém, je vˇzdy podpis validn´ı. M´ ym návrhem je provést v´ yzkum na zjiˇstˇen´ı, k jak´ ym zmˇenám v dokumentu pˇri ukládán´ı docház´ı a zda nen´ı moˇzné toto chován´ı systému explicitnˇe zakázat, ˇci obej´ıt.

60

9 Porovnán´ı r˚ uzn´ ych metod skl´ ad´ an´ı dokument˚ u V kapitole 6.3 bylo zm´ınˇeno, ˇze jsem implementoval dvˇe r˚ uzné tˇr´ıdy, které jsou urˇceny pro skládán´ı DOCX dokument˚ u z jiˇz existuj´ıc´ıch dokument˚ u tohoto typu. Kaˇzdá z tˇechto tˇr´ıd vyuˇz´ıvá zcela odliˇsné pˇr´ıstupy a bylo naznaˇceno, ˇze kaˇzdá bude m´ıt specifické vlastnosti. Pro pˇripomenut´ı, tˇr´ıda AltChunkMergeService vyuˇz´ıvá moˇznosti importovat na urˇcité m´ısto v hlavn´ı ˇca´sti dokumentu (AltChunk kotva) jin´ y dokument jako AlternativeFormatImportPart. Tuto moˇznost poskytuje knihovna OpenXML SDK. Na prvn´ı pohled je zˇrejmé, ˇze tento pˇr´ıstup bude umoˇzn ˇovat rychlé skládán´ı dokument˚ u, nebot’ se nejedná o nic jiného neˇz pˇridán´ı referenc´ı v urˇcitém m´ıstˇe dokumentu. Otázkou je, zda bude m´ıt toto ˇreˇsen´ı dopad na dobu otev´ırán´ı dokumentu a na velikost v´ ysledného dokumentu. Dalˇs´ı nev´ yhodou ˇreˇsen´ı pomoc´ı importu je, ˇze importovan´ y obsah nelze prohledávat a nahrazovat pomoc´ı tˇr´ıdy SimpleFillService. Mus´ıme tedy nejprve ˇsablony naplnit a teprve poté je spojit. Tato nev´ yhoda m˚ uˇze b´ yt zásadn´ı, pokud potˇrebujeme do vytvoˇreného dokumentu doplnit data aˇz pozdˇeji. V tom pˇr´ıpadˇe nen´ı moˇzné tˇr´ıdu AltChunkMergeService pouˇz´ıt. Druhá tˇr´ıda PTMergeService pouˇz´ıvá tˇr´ıdu DocumentBuilder z knihovny OpenXmlPowerTools. Zde je moˇzné tˇr´ıdˇe DocumentBuilder pˇredat jednotlivé dokumenty a tˇr´ıda sama je dokáˇze spojit i vyˇreˇsit pˇr´ıpadné kolize (styl˚ u atd.). Lze pˇredpokládat, ˇze toto ˇreˇsen´ı bude pro vytváˇren´ı dokumentu pomalejˇs´ı neˇz prvn´ı uvedené. Na druhou stranu oˇcekávám, ˇze bude m´ıt pozitivn´ı dopad na dobu otev´ırán´ı dokumentu a na jeho v´ yslednou velikost. Na závˇer je dobré dodat, ˇze je moˇzné pˇri pouˇzit´ı tˇr´ıdy PTMergeService dokument nejprve spojit a pak teprve pomoc´ı tˇr´ıdy SimpleFillService naplnit. Testován´ı prob´ıhalo na testovac´ı sestavˇe s operaˇcn´ım systémem Windows 7 Professional 64-bit, procesorem Intel Core i5-2410M (frekvence 2,3 GHz – 2,6 GHz, L1 Cache 128 KB, L2 Cache 512 KB, L3 Cache 3072 KB), velikost pamˇeti RAM 4096 MB.

61

Porovnán´ı metod skládán´ı

9.1

Doba bˇehu a výsledná velikost souboru

Porovn´ an´ı doby bˇ ehu modulu a v´ ysledn´ e velikosti dokumentu

Porovnáván´ı doby skládán´ı dokumentu prob´ıhalo za pomoci aplikace MergeSignApp (kapitola 7.2). V kaˇzdém zkoumaném pˇr´ıpadˇe jsem dokument vygeneroval stokrát. V´ ysledn´ y ˇcas je pr˚ umˇer namˇeˇren´ ych ˇcas˚ u. V tabulce 9.1 naleznete v´ ysledky mˇeˇren´ı. Zkratka FM u názvu tˇr´ıdy znamená, ˇze nejprve doˇslo k plnˇen´ı ˇsablon a poté k jejich skládán´ı. Zkratka MF znamená, ˇze nejprve byly ˇsablony spojeny a pak plnˇeny. Z v´ ysledk˚ u vypl´ yvá nˇekolik fakt˚ u: ∙ Tˇr´ıda AltChunkMergeService je pˇri skládán´ı vˇetˇs´ıch dokument˚ u aˇz nˇekolikanásobnˇe rychlejˇs´ı neˇz tˇr´ıda PTMergeService (na námi zvolen´ ych datech byla i v´ıce neˇz 5krát rychlejˇs´ı). ∙ Tˇr´ıda PTMergeService generuje aˇz nˇekolikanásobnˇe menˇs´ı soubory (záleˇz´ı pochopitelnˇe na velikosti jednotliv´ ych soubor˚ u) neˇz tˇr´ıda AltChunkService (v extrémn´ıch pˇr´ıpadech naˇseho mˇeˇren´ı byl v´ ysledkem i 15krát menˇs´ı v´ ysledn´ y soubor). ∙ Tˇr´ıda AltChunkMergeService generuje v´ ysledn´ y soubor o velikosti, která zhruba odpov´ıdá velikosti vˇsech spojovan´ ych dokument˚ u dohromady. ∙ Pouˇzit´ı opaˇcného poˇrad´ı (nejdˇr´ıve spojovat a poté plnit) vede k mnohonásobnˇe horˇs´ım v´ ysledk˚ um doby plnˇen´ı neˇz u plnˇen´ı a následného spojován´ı. Z tohoto zjiˇstˇen´ı a z v´ ysledk˚ u doby plnˇen´ı nejvˇetˇs´ıch soubor˚ u vypl´ yvá, ˇze plnˇen´ı dokumentu daty pomoc´ı tˇr´ıdy SimpleFillService roste nelineárnˇe s mnoˇzstv´ım textu dokumentu. ∙ Doby spojován´ı pomoc´ı obou tˇr´ıd jsou v˚ uˇci dobám plnˇen´ı zanedbatelné. V´ ysledky mˇeˇren´ı byly pro názornost zaneseny do graf˚ u, které naleznete v pˇr´ıloze B.

62


Doba bˇehu a výsledná velikost souboru

Velikosti (kB) Pouˇzitá tˇr´ıda

n

ACMS (FM)

3

37

37

PTMS (FM)

3

37

PTMS (MF)

3

ACMS (FM)

Doby bˇehu (ms)

Vstupn´ı V´ ystupn´ı Skládán´ı

Plnˇen´ı

Celková

9,4

70,1

79,5

16

25,5

63,1

87,5

37

16

28,5

93,5

122,0

12

147

149

16,7

244,5

261,2

PTMS (FM)

12

147

21

68,2

250,2

317,3

PTMS (MF)

12

147

21

76,9

802,9

879,8

ACMS (FM)

24

294

298

27,1

471,3

498,4

PTMS (FM)

24

294

28

125,0

519,1

644,1

PTMS (MF)

24

294

28

141,8

2999,0

3140,8

ACMS (FM)

36

441

448

38,2

694,1

732,4

PTMS (FM)

36

441

35

192,2

729,1

921,4

PTMS (MF)

36

441

35

209,7

6255,6

6465,3

ACMS (FM)

48

589

597

45,8

943,2

991,0

PTMS (FM)

48

589

41

244,6

953,8

1197,8

PTMS (MF)

48

589

41

283,1

11224,5

11507,7

ACMS (FM) – PTMS (FM) – PTMS (MF) – n–

AltChunkMergeService (Fill -> Merge) PTMergeService (Fill -> Merge) PTMergeService (Merge -> Fill) Poˇcet vstupn´ıch ˇsablon

Tabulka 9.1: Doba bˇehu skládán´ı dokumentu a velikost výsledného souboru.

63


Doba otev´ırán´ı dokumentu

V´ ysledky pˇredchoz´ıho testu otevˇrely otázku, jak roste doba plnˇen´ı dokumentu v závislosti na délce jednotliv´ ych soubor˚ u. Pˇripravil jsem tedy test, ve kterém pln´ım jeden dokument, jehoˇz obsah má 1000 znak˚ u a 25 nahrazovan´ ych poloˇzek. Tento dokument jsem postupnˇe zvˇetˇsoval kop´ırován´ım p˚ uvodn´ıho obsahu na 5000 znak˚ u a 125 poloˇzek, 10000 znak˚ u a tak dále. V testu jsem porovnával ˇcas plnˇen´ı jednoho spojeného souboru s ˇcasem plnˇen´ı a následného sloˇzen´ı odpov´ıdaj´ıc´ıho poˇctu p˚ uvodn´ıch soubor˚ u o rozsahu 1000 znak˚ u. Z tabulky 9.2 je vidˇet, ˇze pokud pln´ıme elementárn´ı soubory a ty teprve skládáme v jeden, roste doba skládán´ı v závislosti na poˇctu znak˚ u lineárnˇe. Doba plnˇen´ı jediného souboru v závislosti na poˇctu znak˚ u roste zhruba kvadraticky (viz graf ˇc. 3, pˇr´ıloha B).

Poˇcet znak˚ u Poˇcet nahrazen´ı 𝑡1 (ms)

𝑡2 (ms)

1 000

25

152,3

160,4

5 000

125

2136,0

847,3

10 000

250

7528,5

1575,2

15 000

375

16852,0

2339,4

20 000

500

30977,2

3030,1

25 000

625

48097,6

3960,2

Tabulka 9.2: Doba bˇehu plnˇen´ı dokumentu v závislosti na velikosti ˇsablon (𝑡1 - doba plnˇen´ı jediného vstupn´ıho souboru, 𝑡2 - doba plnˇen´ı elementárn´ıch soubor˚ u a jejich sloˇzen´ı).

9.2

Porovn´ an´ı doby otev´ır´ an´ı dokumentu v aplikaci Office Word 2010

Porovnán´ı doby otev´ırán´ı dokumentu prob´ıhalo pomoc´ı doplˇ nku TestTimeToOpenDocument, jenˇz byl popsán v kapitole 7.4. Testovány byly dokumenty vytvoˇrené bˇehem prvn´ıho mˇeˇren´ı kapitoly 9.1.

64


Závˇery porovnán´ı

V´ ysledky (v tabulce 9.3) potvrdily pˇredpoklad, ˇze doba otev´ırán´ı dokument˚ u vytvoˇren´ ych tˇr´ıdou AltChunkMergeService je delˇs´ı neˇz doba otev´ırán´ı dokument˚ u vytvoˇren´ ych tˇr´ıdou PTMergeService.

n

𝑡𝐴𝐶𝑀 𝑆 (ms) 𝑡𝑃 𝑇 𝑀 𝑆 (ms)

3

103,5

74,4

12

230,4

87,9

24

422,2

103,2

36

601,8

115,1

48

785,9

124,9

Tabulka 9.3: Doba bˇehu otev´ırán´ı dokumentu podle poˇctu soubor˚ u, které byly pouˇzity k sestaven´ı testovac´ıho dokumentu (𝑡𝐴𝐶𝑀 𝑆 - doba otev´ırán´ı dokumentu vytvoˇreného tˇr´ıdou AltChunkMergeService,𝑡𝑃 𝑇 𝑀 𝑆 - Doba otev´ırán´ı dokumentu vytvoˇreného tˇr´ıdou PTMergeService, n - poˇcet vstupn´ıch ˇsablon, ze kterých byl dokument vytvoˇren).

9.3

Z´ avˇ ery porovn´ an´ı

Pokud shrnu v´ yˇse uvedené v´ ysledky, mohu konstatovat, ˇze doba skládán´ı dokumentu i doba otev´ırán´ı v´ ysledného dokumentu je v obou pˇr´ıpadech lineárnˇe závislá na poˇctu zdrojov´ ych dokument˚ u. V porovnán´ı s dobou plnˇen´ı ˇsablon jsou zanedbatelné a pro v´ ybˇer pouˇz´ıvané tˇr´ıdy nehraje zcela zásadn´ı roli. D˚ uleˇzitˇejˇs´ı roli hraje fakt, ˇze po pouˇzit´ı tˇr´ıdy AltChunkMergeService pro sloˇzen´ı dokumentu nelze do v´ ysledného dokumentu vkládat data pomoc´ı tˇr´ıdy SimpleFillService a ˇze velikost v´ ysledného dokumentu b´ yvá mnohonásobnˇe vˇetˇs´ı neˇz pˇri sloˇzen´ı dokumentu tˇr´ıdou PTMergeService. Z tˇechto d˚ uvod˚ u je praktiˇctˇejˇs´ı pouˇz´ıvat tˇr´ıdu PTMergeService vˇzdy, kdyˇz nemá systém problém s v´ ykonem.

65

10 Zhodnocen´ı pˇr´ınosu implementovan´ ych elektronick´ ych podpis˚ uaˇ casov´ ych raz´ıtek Zhodnocen´ı v´ ysledk˚ u implementace elektronick´ ych podpis˚ u a ˇcasov´ ych raz´ıtek nen´ı smˇerodatné provádˇet na základˇe mˇeˇren´ı doby bˇehu ani velikosti v´ ysledného raz´ıtka. Mnohem d˚ uleˇzitˇejˇs´ı je posuzovat je z hlediska ovˇeˇritelnosti platnosti, z hlediska dostupnosti nástroj˚ u pro ovˇeˇren´ı a z hlediska jedineˇcnosti.

10.1

XmlDsigService

V kapitole 6.3.6 jsem popsal, ˇze tato tˇr´ıda poskytuje intern´ı podpis DOCX dokument˚ u ve formátu XMLDSig pomoc´ı standardn´ıch knihoven platformy .NET. XMLDSig je jednoduch´ y formát elektronického podpisu, kter´ y neumoˇzn ˇuje vkládán´ı ˇcasov´ ych raz´ıtek, digitáln´ıch certifikát˚ u ani revokaˇcn´ıch list˚ u. Jeho vyuˇzit´ı je v praxi moˇzné, ale kv˚ uli komplikovanému ovˇeˇren´ı platnosti nen´ı pˇr´ıliˇs vhodné. Uˇzivatel, kter´ y dokument ovˇeˇruje, mus´ı posuzovat platnost certifikátu digitáln´ıho podpisu v˚ uˇci okamˇziku podepisován´ı, nebo m´ıt k dispozici samostatnˇe uloˇzené ˇcasové raz´ıtko. Zároveˇ n bude muset zjiˇst’ovat, zda nedoˇslo k revokaci certifikátu z jin´ ych zdroj˚ u neˇz z obsahu elektronického podpisu, coˇz znemoˇzn ˇuje ovˇeˇren´ı platnosti s delˇs´ım ˇcasov´ ym odstupem, pokud by uˇz tyto informace certifikaˇcn´ı autorita neposkytovala a uˇzivatel by si nevedl jejich záznamy. D˚ uvodem, proˇc se t´ımto typem podpisu v˚ ubec zab´ yvat je to, ˇze je moˇzné jej poskytnout standardn´ımi prostˇredky. Zároveˇ n existuje nástroj, kter´ y jej dokáˇze ovˇeˇrit - Microsoft Word. Ovˇeˇren´ı podpisu v aplikaci Microsoft Word se vˇsak liˇs´ı podle pouˇzité verze této aplikace. Microsoft Word 2007 kontroluje pouze integritu dokumentu a neˇreˇs´ı d˚ uvˇeryhodnost certifikátu, pomoc´ı kterého byl podpis vystaven. Microsoft Word 2010 kontroluje i d˚ uvˇeryhodnost certifikátu, podle této aplikace je ale podpis poskytnut´ y tˇr´ıdou XmlDsigService vyhodnocován jako ˇcásteˇcn´ y“. Pˇr´ınos této tˇr´ıdy je proto celkem ” mal´ y – z hlediska funkcionality nepˇrináˇs´ı nic nového (tato implementace je uˇz známá), z hlediska ovˇeˇrován´ı jej nástroje ˇca´steˇcnˇe podporuj´ı a k archivaci

66

Pˇr´ınos implementace el. podpisu a ˇcasových raz´ıtek

XadesService

dokumentu se rozhodnˇe nehod´ı.

10.2

XadesService

Tˇr´ıda XadesService poskytuje zcela odliˇsn´ y pˇr´ıstup neˇz tˇr´ıda XmlDsigService. Je urˇcena k tvorbˇe externˇe ukládaného elektronického podpisu ve formátu XAdES v u ´rovn´ıch (T, C, X, X-L). Umoˇzn ˇuje tak vkládán´ı ˇcasov´ ych raz´ıtek, odkazy na digitáln´ı certifikáty celého certifikaˇcn´ıho ˇretˇezce a na revokaˇcn´ı listy, dokonce i hodnoty tˇechto certifikát˚ u a revokaˇcn´ıch list˚ u. T´ımto zp˚ usobem ˇreˇs´ı problémy s ovˇeˇren´ım podpisu, které vznikaj´ı pˇri pouˇzit´ı jednoduchého formátu XMLDSig. Na rozd´ıl od formátu XMLDSig ovˇeˇrován´ı podpisu typu XAdES podporuje aplikace Microsoft Word aˇz od verze 2010 a to pouze internˇe pˇripojované podpisy tohoto typu. Moj´ı p˚ uvodn´ı myˇslenkou bylo implementovat podpis ve formátu XAdES také jako intern´ı podpis, aby bylo moˇzné jej ovˇeˇrit v aplikaci Word. Tato myˇslenka byla implementována, ale aplikace Word podpis vyhodnocovala jako nevalidn´ı (neshodoval se hash dokumentu), z tohoto v´ ysledku vˇsak nebylo dohledatelné, ve které ˇca´sti podpisu se vyskytoval problém. Porovnáván´ım s podpisem, kter´ y vytváˇr´ı aplikace Word, jsem zjistil, ˇze jednotlivé ˇcásti dokumentu (document parts) mˇely shodnou hodnotu hash v obou podpisech a ˇze zde problém patrnˇe nebyl. Dalˇs´ı souˇca´st´ı intern´ıho podpisu jsou odkazy na ˇca´sti dokumentu a ˇcást XAdES podpisu samotného. Tyto ˇcásti, které jsou ve formátu XML, nejsou podepisovány jako celek, ale jsou nad nimi provádˇeny transformace pro v´ ybˇer podepisovan´ ych element˚ u (Relationship Transform) a transformace pro standardizaci formátu XML (C14N Transform). Aˇckoliv jsem tyto transformace aplikoval tak, jak je popsáno v ECMA specifikaci formátu OpenXML, v´ ysledn´ y hash se vˇzdy liˇsil oproti hash vypoˇctenému v podpisu aplikace Word. Bohuˇzel nebylo moˇzné porovnat v´ ysledná XML, ze kter´ ych byl vypoˇcten hash, protoˇze se toto XML po aplikovan´ ych transformac´ıch nikde neukládá. Dalˇs´ım m´ıstem, ve kterém se podpis tˇr´ıdy XadesService neshodoval s podpisem vytváˇren´ ym v aplikaci Word, bylo poˇrad´ı jednotliv´ ych referenc´ı na jednotlivé podepisované ˇca´sti. Podle ECMA specifikace (Open Packaging Conventions) by mˇely b´ yt reference v podpisu ˇrazeny v abecedn´ım poˇrad´ı, v podpisu vytvoˇreném aplikac´ı Word jsou vˇsak ukládány neˇrazené (nebo ˇra-

67


XadesService

zené podle jiného kl´ıˇce). Otázkou je, zda jiné poˇrad´ı referenc´ı uvnitˇr podpisu m˚ uˇze m´ıt vliv na ovˇeˇrován´ı podpisu. Po vznesen´ı dotazu, jak´ ym postupem jsou aplikovány transformace na ˇca´sti rels v aplikaci Word, na v´ yvojáˇrském fóru MSDN zamˇeˇreném na formát OpenXML jsem byl Microsoft v´ yvojáˇri odkázán na obecnou literaturu o OpenXML a zároveˇ n mi bylo sdˇeleno, ˇze implementace formátu XAdES je ˇreˇsen´ım, ke kterému Microsoft neposkytuje podporu. Pˇri zkoumán´ı intern´ıho podpisu typu XAdES, kter´ y vytváˇr´ı aplikace Word, jsem narazil na znaˇcné nedostatky této implementace. Mezi ˇcástmi dokumentu, které jsou do podpisu zahrnuty, chyb´ı napˇr´ıklad metadata. Absence tˇechto dat uvnitˇr podpisu se mi jev´ı jako zcela zásadn´ı problém. V podepsaném dokumentu m˚ uˇze napˇr´ıklad kdokoliv zmˇenit autora a podpis dokumentu bude stále validn´ı. Kv˚ uli vˇsem v´ yˇse uveden´ ym d˚ uvod˚ um jsem se rozhodl pro implementaci externˇe ukládaného XAdES podpisu. Ten má stejnou strukturu jako XAdES intern´ı, je ukládán do samostatného souboru a v referenc´ıch obsahuje URI podepisovaného dokumentu. Nev´ yhodou tohoto formátu je pouze slabá podpora v oblasti nástroj˚ u na ovˇeˇren´ı platnosti. Z tohoto d˚ uvodu také vznikla aplikace na ovˇeˇren´ı platnosti podpisu - XadesVerifyTool (viz kapitola 7.3). Lze oˇcekávat, ˇze extern´ı XAdES podpisy budou stále populárnˇejˇs´ı. D˚ uvod˚ u je nˇekolik: ∙ XAdES podpis umoˇzn ˇuje pˇripojovat vˇsechny potˇrebné náleˇzitosti pro automatizované ovˇeˇrován´ı podpisu, bez nutnosti z´ıskávat jakékoliv extern´ı informace. ∙ Externˇe ukládan´ y XAdES podpis umoˇzn ˇuje podpis soubor˚ u v jak´ ychkoliv formátech a podepisován´ı nˇekolika soubor˚ u najednou. ∙ Zákon o elektronickém podpisu a zákon o spisové sluˇzbˇe a archivnictv´ı zahrnuj´ı formát XAdES mezi formáty podpisu, které mus´ı b´ yt akceptovány orgány státn´ı správy. V budoucnu doporuˇcuji rozˇs´ıˇrit ˇreˇsen´ı o u ´roveˇ n archivaˇcn´ı (XAdES-A), která poˇc´ıtá s pˇridáván´ım archivn´ıch raz´ıtek. Podpis typu XAdES-A lze vytvoˇrit z jiˇz existuj´ıc´ıho formátu XAdES-X-L. Celkov´ y pˇr´ınos tˇr´ıdy XadesService shledávám v tom, ˇze implementace takového ˇreˇsen´ı nebyla dosud nikde publiˇ sen´ı totiˇz vyuˇz´ıvá knihovnu Microsoft.Xades, která je v tuto chv´ıli kována. Reˇ 68


XadesService

patrnˇe nejkvalitnˇejˇs´ı open source knihovna pro práci s XAdES podpisy, kterou zároveˇ n rozˇsiˇruji o moˇznost tvorby podpisu pro soubory zpracovávané jako datové proudy a o moˇznost z´ıskávat revokaˇcn´ı listy pomoc´ı HTTP protokolu.

69

11 Závˇer Prvn´ım u ´kolem bylo prozkoumat dokumentové formáty, které jsou vhodné pro automatické skládán´ı dokument˚ u na platformˇe .NET, které jsou zároveˇ n vhodné pro dalˇs´ı uˇzivatelskou manipulaci a které umoˇzn ˇuj´ı pˇripojován´ı elektronick´ ych podpis˚ u a ˇcasov´ ych raz´ıtek. Tento u ´kol jsem naplnil. Mezi zkoumané formáty jsme urˇcil tˇechto pˇet zástupc˚ u – PDF, OOXML (respektive DOCX), ODF (resp. ODT), XSL-FO a RTF. Po jejich prozkoumán´ı a následné anal´ yze se mezi nejlépe hodnocené formáty podle kritéri´ı uveden´ ych v kapitole 2.1 dostaly formáty OOXML a PDF. Ve speciáln´ıch pˇr´ıpadech bych doporuˇcil také ODF a XSL-FO. Po konzultaci se zadavatelem byl pro implementaci urˇcen formát OOXML. Dále byly pˇredstaveny principy elektronick´ ych podpis˚ u a ˇcasov´ ych raz´ıtek, vˇcetnˇe jejich právn´ı platnosti. Následnˇe byla naznaˇcena aktuáln´ı u ´roveˇ n podpory elektronického podpisu v bˇeˇznˇe pouˇz´ıvan´ ych aplikac´ıch. Na závˇer byly uvedeny pokroˇcilé dokumentové formáty jako vhodná u ´loˇziˇstˇe pro ukládán´ı kompletn´ı informace o elektronickém podpisu. Následn´ ym u ´kolem bylo vytvoˇrit ˇreˇsen´ı automatického skládán´ı a plnˇen´ı dokumentu a pˇripojován´ı elektronick´ ych podpis˚ u a ˇcasov´ ych raz´ıtek. Pro splnˇen´ı tohoto u ´kolu jsem nejprve vytvoˇril ˇreˇsen´ı ve smyslu modulu, kter´ y poskytuje zm´ınˇenou funkcionalitu, je snadno rozˇsiˇriteln´ y a konfigurovateln´ y. Skládán´ı dokumentu z jiˇz existuj´ıc´ıch dokument˚ u jsem implementoval dvˇema r˚ uzn´ ymi zp˚ usoby, které jsou zcela odliˇsné a kaˇzd´ y z nich má specifické vlastnosti, které byly potvrzeny testován´ım v kapitole 9.1. Plnˇen´ı dokumentu textem bylo implementováno pouze jedn´ım zp˚ usobem. Následnˇe jsem testoval, jak´ y je rozd´ıl doby bˇehu plnˇen´ı, pokud pln´ım d´ılˇc´ı soubory a ty poté skládám, nebo pokud nejprve vytvoˇr´ım jeden sloˇzen´ y soubor a na závˇer jej napln´ım textem. Podepisován´ı dokumentu elektronick´ ym podpisem bylo implementováno dvˇema r˚ uzn´ ymi zp˚ usoby. Prvn´ı zp˚ usob poskytuje základn´ı tvorbu elektronického podpisu ve formátu XMLDSig, jak je pouˇz´ıváno v aplikaci Microsoft Word 2007. Druhá implementace umoˇzn ˇuje vytváˇret externˇe ukládan´ y podpis v pokroˇcilém formátu XAdES (T, C, X a X-L). Nakonec byla hodnocena pouˇzitelnost obou ˇreˇsen´ı v praxi a dalˇs´ı moˇzná rozˇs´ıˇren´ı. Nad rámec zadán´ı diplomové práce jsem navrhl a naimplementoval integraci modulu do systému pro správu dokument˚ u SharePoint 2010 (ve verzi Standard). Pˇredvedl jsem tak pouˇzit´ı modulu jako souˇca´st webové aplikace. 70

Literatura [1] The incredible persistence of email [online]. Cite World [cit. 2.5.2013] Dostupné z: http://www.citeworld.com/business/21082/email-persistssocial-collaboration [2] Email Statistics Report[online]. Radicati Group [cit. 2.5.2013] Dostupné z: http://www.radicati.com/wp/wpcontent/uploads/2012/04/Email-Statistics-Report-2012-2016Executive-Summary.pdf ´ [3] Uvod do správy dokument˚ u[online]. Microsoft [cit. 2.5.2013] Dostupné z: http://office.microsoft.com/cs-cz/sharepoint-serverhelp/uvod-do-spravy-dokumentu-HA010241399.aspx?CTT=1 [4] Dobˇre zvládnutá implementace DMS usnadˇ nuje práci a ˇsetˇr´ı ˇcas[online]. SystemOnLine.cz [cit. 2.5.2013] Dostupné z: http://www.systemonline.cz/sprava-dokumentu/dobrezvladnuta-implementace-dms-setri-cas.htm [5] ORION, Egan, PDF 1.7 is approved as ISO 32000, 2007 [online]. The Inquirer [cit. 2.5.2013] Dostupné z: http://www.theinquirer.net/inquirer/news/1030411/pdfapproved-iso-32000 [6] AIIM to Facilitate ISO Standards Process for Leading Electronic Document Format, 2007 [online]. Adobe Systems [cit. 2.5.2013] Dostupné z: http://www.adobe.com/aboutadobe/pressroom/pressreleases /200701/012907OpenPDFAIIM.html [7] Adobe PDF 101 — Quick overview of PDF file format[online]. Adobe Systems [cit. 2.5.2013] Dostupné z: http://partners.adobe.com/public/developer/tips /topic tip31.html 71

LITERATURA

LITERATURA

[8] Introducing the Office (2007) Open XML File Formats, 2006 [online]. MSDN [cit. 2.5.2013] Dostupné z: http://msdn.microsoft.com/enus/library/office/aa338205(v=office.12).aspx [9] Open Document Format for Office Applications (OpenDocument) v1.0, 2005 [online] OASIS Standard [cit. 2.5.2013] Dostupné z: https://www.oasis-open.org/committees/download.php /12572/OpenDocument-v1.0-os.pdf [10] NNEC Core Enterprise Services.[online] NATO Interoperability Standards & Profiles [cit. 2.5.2013] Dostupné z: http://nhqc3s.nato.int/architecture/ docs/NISPv2/ volume2/ch03s04.html [11] HOLMAN, Ken G., What Is XSL-FO, 2002 [online] O’Reilly’s XML.com [cit. 2.5.2013] Dostupné z: http://www.xml.com/pub/a/2002/03/20/xsl-fo.html [12] Extensible Stylesheet Language (XSL) Version 1.1, 2006 [online] W3C Recommendation [cit. 2.5.2013] Dostupné z: http://www.w3.org/TR/xsl11/ [13] Changes in Word 2010 (for ITPros), 2010 [online] Microsoft TechNet [cit. 2.5.2013] Dostupné z: http://technet.microsoft.com/enus/library/cc179199.aspx#BKMK Changed [14] Rich Text Format (RTF) Specification, version 1.6, 1999 [online] MSDN [cit. 2.5.2013] Dostupné z: http://msdn.microsoft.com/enus/library/aa140277(v=office.10).aspx [15] Zákon ˇc. 227/2000 Sb., o elektronickém podpisu, 2012 [online] Ministerˇ [cit. 2.5.2013] stvo vnitra CR Dostupné z: http://www.mvcr.cz/soubor/zakon-c-227-2000-sb-oelektronickem-podpisu.aspx [16] Peterka Jiˇr´ı, RNDr. Ing, Bájeˇcný svˇet elektronického podpisu, 2011, CZ.NIC, z.s.p.o.,1. vydán´ı. ISBN: 978-80-904248-3-8 [17] Informace o produktu (Microsoft SharePoint 2010 [online] Microsoft [cit. 2.5.2013] 72

LITERATURA

LITERATURA

Dostupné z: http://sharepoint.microsoft.com/cscz/product/capabilities/Pages/default.aspx [18] FOWLER, Martin, Inversion of Control Containers and the Dependency Injection pattern, 2004 [online] [cit. 2.5.2013] Dostupné z: http://martinfowler.com/articles/injection.html [19] WHITE, Eric, Search and Replace Text in an Open XML WordprocessingML Document, 2011 [online] OpenXMLDeveloper.org [cit. 2.5.2013] Dostupné z: http://openxmldeveloper.org/blog/b/openxmldeveloper /archive/2011/05/12/148357.aspx

73

A Pˇr´ıloha - Uˇzivatelská dokumentace A.1

MergeSignApp

Je aplikace, která slouˇz´ı k testován´ı funkcionality knihovny MergeSignModul. Tato aplikace je spustitelná z bin∖MergeSignApp∖MergeSignApp.exe. Pˇred spuˇstˇen´ım doporuˇcuji provést konfiguraci modulu pomoc´ı aplikace MergeSignModulConfig.exe (z téhoˇz adresáˇre). Nejd˚ uleˇzitˇejˇs´ım nastaven´ım je v´ ybˇer certifikátu (na záloˇzce Nastaven´ı podpisu), kter´ y bude pouˇz´ıván k tvorbˇe elektronického podpisu. Aplikace je otestována v prostˇred´ı Windows 7 Professional (64-bit) a pˇredpokládá nainstalovan´ y .NET Frawork 4.0 nebo vyˇsˇs´ı. Samotné pouˇzit´ı programu je intuitivn´ı. Program umoˇzn ˇuje vybrat a seˇradit ˇsablony vytváˇreného souboru. Minimáln´ı mnoˇzstv´ı je jedna ˇsablona, maximáln´ı poˇcet nen´ı nijak omezen´ y. Dále je moˇzné zadat parametry ve formátu XML. Jeho XSD naleznete v pˇr´ıloze B.

A.2

XadesVerifyTool

Je aplikace, která slouˇz´ı k testován´ı validity podpisu. Lze jsi spustit z bin∖XadesVerifyTool∖XadesVerifyTool.exe. Po spuˇstˇen´ı zvolte Vyber a ovˇeˇr podpis a následnˇe vyberte XML soubor, ve kterém je uloˇzen extern´ı podpis (podepisovan´ y dokument mus´ı b´ yt dostupn´ y v téˇze sloˇzce). Pokud validace neprobˇehla u ´spˇeˇsnˇe, budete informováni dialogov´ ym oknem s textem v´ yjimky. Aplikace je otestována v prostˇred´ı Windows 7 Professional (64-bit).

A.3


Je doplnˇek aplikace Microsoft Word 2010, kter´ y slouˇz´ı k testován´ı doby otev´ırán´ı dokumentu v aplikaci Microsoft Word 2010. Spust’te instalaci z bin∖TestTimeToOpenDocument∖setup.exe a potvrd’te Install. Doplnˇek se automaticky spouˇst´ı s aplikac´ı Word. Poznámka: Pokud byla aplikace Word otevˇrena nad novým dokumentem, je nutné pˇred pouˇzit´ım tlaˇc´ıtka Otevˇ ri a zmˇ eˇ r provést nejprve jakoukoliv zmˇenu dokumentu (jinak by se 74

Pˇr´ıloha - Uˇzivatelská dokumentace

SPMergeSign

p˚ uvodn´ı aplikace zavˇrela a výsledky mˇeˇren´ı by se nezobrazily). Pro odinstalován´ı doplˇ nku jdˇete na Start -> Ovl´ adac´ı panely -> Progamy a funkce. Vyberte TestTimeToOpenDocument a zvolte Odinstalovat. Aplikace je otestována v prostˇred´ı Windows 7 Professional (64-bit).

A.4

SPMergeSign

Struˇcn´ y postup nasazen´ı ˇreˇsen´ı je popsán pro operaˇcn´ı systém Windows ˇ sen´ı zahrnuje také zkrácen´ Server 2008 R2 Standard. Reˇ y popis instalace SharePoint Serveru. Instalaci je moˇzné provést i na operaˇcn´ı systém Windows 7, ˇci Windows Vista, avˇsak nejedná se o standardn´ı instalaci a je ˇ ast z nich je popsána na webu MSDN nutné provést ˇradu dalˇs´ıch krok˚ u. C´ (http://msdn.microsoft.com/en-us/library/ee554869(office.14).aspx). Budu pˇredpokládat, ˇze je na c´ılovém stroji novˇe nainstalovan´ y Windows Server R2 2008 Standard (English). Návod popisuje instalaci SharePoint Server 2010 SP1 64bit (Czech), která je pro v´ yukové u ´ˇcely dostupná z programu MSDNAA.

A.4.1

Instalace SharePoint serveru

1. Nainstalujte WCF Hotfix. Pro Windows Server 2008 R2 je ke staˇzen´ı zde: http://go.microsoft.com/fwlink/?LinkID=166231 (m˚ uˇze se stát, ˇze tato oprava je na vaˇsem serveru jiˇz nainstalována, v tom pˇr´ıpadˇe bude instalátor ukonˇcen). 2. Nainstalujte ADO.NET Data Services Update for .NET Framework 3.5 SP1. Pro Windows Server 2008 R2 je ke staˇzen´ı zde: http://go.microsoft.com/fwlink/?LinkId=163524 (m˚ uˇze se stát, ˇze tato oprava je na vaˇsem serveru jiˇz nainstalována, v tom pˇr´ıpadˇe bude instalátor ukonˇcen). 3. Pˇred samotnou instalac´ı SharePoint Server 2010 nainstalujte pˇredpokládané souˇca´sti systému. Ty je moˇzné nainstalovat pomoc´ı PrerequisiteInstaller.exe, kter´ y je dostupn´ y na instalaˇcn´ım médiu SharePoint Server 2010. Tento instalátor je moˇzné pouˇz´ıt pouze pro operaˇcn´ı systémy Windows Server 2010 SP2 a Windows Server 2010 R2. Na systémech Windows 7 a Vista je nutné tyto pˇredpokládané souˇca´sti nainstalovat jin´ ym zp˚ usobem. 75


SPMergeSign

4. Nyn´ı m˚ uˇzete spustit instalaci SharePoint Server 2010. Na instalaˇcn´ım médiu spust’te Setup.exe. 5. Pˇrijmˇete licenˇcn´ı podm´ınky a zvolte typ instalace Samostatnˇ e. 6. Dokonˇcete instalaci a povolte spuˇ stˇ en´ı konfiguraˇ cn´ı utility.

A.4.2

Nasazen´ı ˇ reˇ sen´ı

1. Otevˇre se uv´ıtac´ı obrazovka nové SharePoint instance, která vyb´ız´ı k v´ ybˇeru ˇsablony webu. Pˇrejdˇete odkazem do Galerie ˇ reˇ sen´ı, otevˇrete ˇ záloˇzku Reˇ sen´ı a zvolte poloˇzku Nahr´ at ˇ reˇ sen´ı. Vyberte pˇriloˇzené ˇreˇsen´ı bin∖SharePoint∖sablona sp dp.wsp a potvrd’te nahrán´ı. Ujistˇete se, ˇze je ˇreˇsen´ı aktivováno. 2. Pˇrejdˇete zpˇet na domovskou stránku, která vám v tuto chv´ıli nab´ız´ı v´ ybˇer ˇsablony webu. Pˇrejdˇete na záloˇzku Vlastn´ı, vyberte ˇsablonu sab´spˇeˇsné, lona sp dp a potvrd’te volbu. Pokud bude nastaven´ı ˇsablony u budete pˇresmˇerováni na Dom´ ac´ı str´ anku pˇrednastaveného webu. 3. Nyn´ı je potˇreba nasadit ˇreˇsen´ı SPMergeSign. Zároveˇ n nasad´ıte ˇreˇsen´ı, které umoˇzn ˇuje mˇenit nastaven´ı hodnot v Property Bag. Obˇe ˇreˇsen´ı jsou farmového typu“, proto je nutné je do farmy nahrát pomoc´ı SharePoint ” 2010 Management Shell. 4. Spust’te Start -> All programs -> Microsoft SharePoint 2010 Products -> Prostˇ red´ı SharePoint 2010 Management Shell. 5. Zadejte pˇr´ıkaz Add-SPSolution –LiteralPath (bal´ık je um´ıstˇen na DVD v adresáˇri bin∖SharePoint∖). 6. Zadejte pˇr´ıkaz Add-SPSolution –LiteralPath (bal´ık je um´ıstˇen na DVD v adresáˇr bin∖SharePoint∖). 7. Nyn´ı m˚ uˇzete obˇe ˇreˇsen´ı spustit na SharePoint farmˇe. To lze provést z administrátorského rozhran´ı aplikace, které spust´ıte: Start -> All programs -> Microsoft SharePoint 2010 Products -> Centr´ aln´ı spr´ ava sluˇ zby SharePoint 2010.

76


SPMergeSign

8. Pˇrejdˇete na Syst´ emov´ e nastaven´ı -> Spravovat ˇ reˇ sen´ı farmy. Zde kliknˇete na propertybagsettings2010.wsp a zvolte Nasadit ˇ reˇ sen´ı. Vyberte nasadit nyn´ı a potvrd’te OK. 9. Opakujte pˇredchoz´ı krok pro spmergesign.wsp. 10. Pokud probˇehlo nasazen´ı u ´spˇeˇsnˇe, uvid´ıte stav nasazen´ ych ˇreˇsen´ı Glob´ alnˇ e nasazeno. 11. Pˇrejdˇete na domovskou stránku ShrarePoint site (defaultnˇe je pouˇzit shodn´ y název stroje, jako u centráln´ıho nastaven´ı, port 80). Zde zvolte v levé horn´ı ˇcásti okna Akce webu -> Nastaven´ı webu. Vyberte Spravovat funkce webu (pod kategori´ı Akce webu) 12. Aktivujte funkci SPMergeSign Feature1.

A.4.3

Ovl´ ad´ an´ı SPMergeSign

1. Nyn´ı m˚ uˇzete vytváˇret dokumenty z existuj´ıc´ıch seznam˚ u. Pˇr´ıkladem je Seznam zamˇ estnanc˚ u. Vyvolejte kontextov´ e menu nad poloˇ zkou a zvolte Vytvoˇ r dokument. 2. Pˇri prvn´ım vytváˇren´ı dokumentu budete vyzváni k zadán´ı knihovny, která bude slouˇzit pro vstupy a v´ ystupy pˇri vytváˇren´ı dokument˚ u (defaultnˇe Sd´ılen´ e dokumenty), sloˇzku knihovny, ve které budou uloˇ ˇzeny ˇsablony (defaultnˇe Sablony) a sluˇzbu, kam se budou ukládat vytvoˇrené soubory (defaultnˇe V´ ystupy). 3. Nyn´ı vyberte ˇsablony, které chcete plnit a spojovat a potvrd’te. Pokud chcete dokument zároveˇ n podepsat, mus´ıte si nastavit certifikát, kter´ y chcete k podpisu pouˇz´ıt).

A.4.4

Nastaven´ı podpisu SPMergeSign

1. Spust’te Start -> MMC.exe. Zvolte File -> Add/Remove SnapIn. Pˇridejte poloˇzku Certificates. Vyberte moˇznost Computer account a následnˇe zvolte Local Computer. Potvrd’te Finish a následnˇe OK. 2. V levém sloupci pˇrejdˇete na Certificates -> Personal -> Certificates. V prostˇredn´ı ˇca´sti okna se vám zobraz´ı jiˇz nainstalované certifikáty. 77


SPMergeSign

Defaultnˇe by mˇel b´ yt alespoˇ n jeden certifikát serveru nainstalovan´ y. Pokud ne, budete si jej muset nejprve vytvoˇrit (nebo z´ıskat) a poté naimportovat. 3. Dvojklikem na certifikát otevˇrete detaily. V záloˇzce Details zkop´ırujte poloˇzku serial number. 4. Pˇrejdˇete na SharePoint stránkách do nastaven´ı. Akce webu -> Nastaven´ı webu -> Property Bag Settings. Upravte poloˇzku spmergesign signaturecertificate – vloˇzte tam zkop´ırované sériové ˇc´ıslo certifikátu (bez mezer). 5. Nyn´ı m˚ uˇzete testovat skládán´ı vˇcetnˇe pˇripojován´ı elektronického podpisu. Dalˇs´ı nastaven´ı m˚ uˇzete mˇenit taktéˇz v Property Bag (názvy vˇsech poloˇzek nastaven´ı SPMergeSign zaˇc´ınaj´ı spmergesign ).

78

B Pˇr´ıloha - XSD Pro moˇznost vytváˇren´ı vlastn´ıch XML soubor˚ u, jejichˇz pˇr´ıklady jsou k práci pˇriloˇzeny, uvád´ım jejich XSD schémata. Tato schémata naleznete na pˇriloˇzeném médiu ve sloˇzce doc∖XSD∖.

B.1

Config.xsd

Toto XSD definuje strukturu XML konfiguraˇcn´ıho souboru knihovny MergeSignModul.

<xs:schema id="Config" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"> <xs:element name="Config" msdata:IsDataSet="true" msdata:UseCurrentLocale="true"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="Settings"> <xs:complexType> <xs:sequence> <xs:element name="SignService" type="xs:string" minOccurs="1" /> <xs:element name="LoadTagService" type="xs:string" minOccurs="1" /> <xs:element name="FillService" type="xs:string" minOccurs="1" /> <xs:element name="MergeService" type="xs:string" minOccurs="1" /> <xs:element name="SignatureCertificate" type="xs:string" minOccurs="0" /> <xs:element name="TimeStampAthorityUrl" type="xs:string" minOccurs="0" /> <xs:element name="Country" type="xs:string" minOccurs="0" /> <xs:element name="PostalCode" type="xs:string" minOccurs="0" /> <xs:element name="Province" type="xs:string" minOccurs="0" /> <xs:element name="City" type="xs:string" minOccurs="0" /> <xs:element name="CrlUri" type="xs:string" minOccurs="0" /> <xs:element name="Role" type="xs:string" minOccurs="0" /> <xs:element name="TimeStampX" type="xs:string" minOccurs="0" /> <xs:element name="XadesLevel" type="xs:string" minOccurs="0" />

79

Pˇr´ıloha - XSD

B.2

Params.xsd

Params.xsd

Toto XSD definuje strukturu XML souboru, kter´ y nese informace o parametrech plnˇen´ı pro aplikaci MergeSignApp.

<xs:schema id="Params" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"> <xs:element name="Params" msdata:IsDataSet="true" msdata:UseCurrentLocale="true"> <xs:complexType> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="Param"> <xs:complexType> <xs:sequence> <xs:element name="Name" type="xs:string" minOccurs="1" /> <xs:element name="Value" type="xs:string" minOccurs="1" />

80

C Pˇr´ıloha - Výsledky test˚ u v grafech

Obrázek C.1: Graf ˇcasu skládán´ı dokumentu v závislosti na poˇctu spojovaných dokument˚ u (zdroj: autor).

Z prvn´ıho grafu (Obrázek C.1) je patrné, ˇze doba skládán´ı dokumentu pomoc´ı tˇr´ıdy DocumentBuilder (PTMergeService) je mnohonásobnˇe pomalejˇs´ı, neˇz pˇri pouˇzit´ı altChunk kotev a importu obsahu (AltChunkMergeService). Pokud také budeme dokument plnit daty, jsou tyto rozd´ıly zanedbatelné (graf na obrázku C.2). Doba plnˇen´ı v závislosti na velikosti ˇsablony pˇredstavuje hrozbu, kterou lze obej´ıt plnˇen´ım d´ılˇc´ıch soubor˚ u a jejich následn´ ym spojován´ım (graf na obrázku C.3). Grafy na obrázc´ıch C.4 a C.5 demonstruj´ı v´ yhodu pouˇzit´ı tˇr´ıdy DocumentBuilder ve velikosti v´ ysledného souboru a doby jeho otev´ırán´ı aplikac´ı Microsoft Word 2010.

81

Pˇr´ıloha - Grafy

Obrázek C.2: Graf ˇcasu skládán´ı a plnˇen´ı dokumentu v závislosti na poˇctu spojovaných dokument˚ u (zdroj: autor).

Obrázek C.3: Graf ˇcasu plnˇen´ı dokumentu v závislosti na poˇctu znak˚ u ˇsablony (zdroj: autor).

82

Pˇr´ıloha - Grafy

Obrázek C.4: Graf velikosti výsledného dokumentu v závislosti na velikosti vstupn´ıch dokument˚ u (zdroj: autor).

Obrázek C.5: Graf doby otev´ırán´ı dokumentu v závislosti na poˇctu spojovaných dokument˚ u (zdroj: autor).

83

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky a výpočetní techniky. fragmentů textu

Recommend Documents