EXAMENSARBETE. Office Smart Client för dokumentsökning i Platina. Joakim Brännström. Luleå tekniska universitet

Transkript

1 EXAMENSARBETE 2005:287 CIV Office Smart Client för dokumentsökning i Platina Joakim Brännström Luleå tekniska universitet Civilingenjörsprogrammet Datateknik Institutionen för Systemteknik Avdelningen för Datorteknik 2005:287 CIV - ISSN: ISRN: LTU-EX--05/287--SE

2 Office Smart Client för dokumentsökning i Platina TM Författare: Joakim Brännström Kurskod: SMX020 Datum:

3 Förord/Preface Detta examensarbete har utförts inom Akademiker i företag ett projekt vars syfte är att bidra till utvecklingen av små och medelstora företag i Västerbotten och Norrbotten. Projektet Akademiker i Företag ger företagen i regionen möjlighet att få utvecklingsprojekt utförda av studenter, nyutexaminerade och forskare från universitet och högskolor i hela landet. Genom en omfattande besöksverksamhet identifieras företagens utvecklingsprojekt som sedan förmedlas via en databas på Internet; examensjobb.nu. Finansiärer är EU:s Strukturfonder, Länsstyrelsen i Västerbotten, Länsstyrelsen i Norrbotten samt deltagande kommuner och företag. EBI har ett tätt samarbete med Microsoft och efter att Microsoft tagit fram Smart Client teknologin så blev EBI intresserade av att undersöka hur denna teknologi kunde användas i Platina. Platina är ett informations- och verksamhetssystemet som utvecklats av EBI. Platina är utvecklat för att passa in i en miljö som använder sig av Microsoft Windows tillsammans med Microsoft Office och Microsoft Internet Explorer. Uppdraget att utforska och skapa en lösning som bygger på Smart Client teknologin resulterade i ett examensarbete som utförts av undertecknad våren 2005 hos EBI Systems AB i Skellefteå. Jag vill tacka följande: Mikael Drugge, min examinator på Luleå tekniska universitet, för utbyte av idéer samt stort stöd vid skapandet av denna rapport. EBI Systems AB med personal för en trevlig arbetsmiljö och ett betydande stöd under utvecklingsarbetet. Microsoft Sweden för stöd och support under utvecklingsarbetet. 2

4 Abstract Computer users these days utilize the Internet in their daily work, web applications frequently exists in this work. Performance in web applications (thin clients) is however very limited compared to the performance in rich clients, for many reasons. This limitation together with other limitations in thin clients has implied that a type of client that brings the benefits of both technologies together would be very useful. The Smart Client technology is the outcome of a fusion between rich clients and thin clients. The Smart Client model is fairly new and has been developed by Microsoft with the intention that clients should be easy to manage and update. At the same time, it should be possible to make use of local resources (both hardwareand software resources) for efficient calculations, visualizations and storing used by the client. Finally a Smart Client should make use of server-side functionality to supply the user with the most recent information. The Platina TM system, developed by EBI Systems AB, utilizes web applications for most of the user-interaction with the system, however, all of the user demands cannot be satisfied with this technology. For that reason a rich client has also been developed. When EBI Systems was informed of the Smart Client technology, they became very interested in finding out how they could make use of the technology in the Platina TM system. This report contains a summary of the technology behind Smart Clients and adjacent technologies. In addition to the summary, an Office Smart Client was constructed to show EBI Systems what the technology have to offer, the report contains selected information from this development. At first sight, it is easy to get the impression that the Smart Client technology contains flawless solutions to a several number of the problems developers encounter in their daily work. However, at a closer look, this shows to be a bit from the truth, the description of the technology is fuzzy enough for this statement to be true, but when theory meets reality, it shows fairly quick that some problems still remains. Even though the technology is not perfect, it contain great improvements for software developers, after examining the technology depending of what type of application that will be constructed it should be a reasonably simple thing to justify the choice of Smart Client technology for use in development. The technology could be described to be a union of many smart solutions to problems that software developers run into on a regular basis in their work. 3

5 Sammanfattning Datoranvändare nyttjar idag Internet i sitt dagliga arbete, webbapplikationer är vanligt förekommande vid detta arbete. Prestanda hos webbapplikationer (thin clients) är dock av många orsaker väldigt begränsad jämfört med rich clients, detta tillsammans med övriga begränsningar hos thin clients har medfört att en klienttyp som sammanfogar fördelarna hos rich clients med fördelarna hos thin clients blivit allt mer efterfrågad. Smart Clients bygger på en fusion mellan rich clients och thin clients, Smart Clients är ett relativt nytt koncept som utvecklats av Microsoft med utgångspunkten att klienter ska vara lätta att administrera och uppdatera. Samtidigt ska möjligheten att använda lokala resurser både i form av mjukvara och hårdvara finnas, för att effektivt hantera den beräkning, visualisering och lagring som klienten nyttjar. Slutligen bör en Smart Client dra nytta av funktionalitet hos servers för att ge användaren tillgång till aktuell information. Platina TM, som utvecklats av EBI Systems, använder till största delen webbapplikationer som gränssnitt mot användare, det är dock inte alla krav från användarna som kan uppfyllas med denna teknologi. Av denna anledning så har även en rich client skapats. När EBI Systems hörde talas om Smart Client teknologin så blev de väldigt intresserade av att ta reda på hur denna teknik kunde användas i Platina TM systemet. Denna rapport innehåller en sammanfattning av teknologin bakom Smart Clients samt en kort beskrivning av de närmast omkringliggande teknologierna. Utöver denna sammanfattning så har en Office Smart Client skapats för att visa EBI Systems vad Smart Client-teknologin kan erbjuda, rapporten innehåller utvald information från utvecklingen av denna klient. Det är lätt att få intrycket av att Smart Client teknologin innehåller perfekta lösningar till ett flertal av de problem som utvecklare stöter på i sitt arbete. Detta visar sig vid en närmare anblick vara en sanning med modifikation, beskrivningen av teknologin är tillräckligt svävande för att detta påstående skall vara sant, men då det är dags att omsätta teori till praktik så framträder det snabbt att vissa problem fortfarande kvarstår. Även om teknologin inte är perfekt så har stora steg tagits åt rätt håll, efter viss utforskning av teknologin så är det beroende på vilken typ av applikation som skall utvecklas förhållandevis enkelt att motivera valet att använda sig av Smart Client teknologin vid utveckling. Teknologin skulle kunna sägas vara en sammanställning av ett flertal smarta lösningar på problem som utvecklare ofta möter i sitt arbete. 4

6 Innehållsförteckning 1 Inledning Teori Introduktion till Smart Clients Prestanda hos Smart Clients Garbage Collection Kommunikation i.net Remoting i.net Webservices Säkerhet i.net Role Based Security Code Access Security Trådning i.net ThreadPool Thread class Delegates Webservice Proxy Tasks Installation och uppdatering av Smart Clients No-Touch deployment No-Touch deployment med en uppdateringsmodul Kod som körs från ett gemensamt utrymme Xcopy Windows installationspaket ClickOnce i.net application Distribution av Smart Client uppdateringar Automatisk uppdatering Visual Studio Tools for Office Metoder Kravspecifikation Kort beskrivning av analys Design Alternativa metoder Platina Office Smart Client Platina Logout Module Utvärdering, resultat Styrkor Begränsningar/Svagheter Diskussion Smart Clients Uppfyllande av kravspecifikationen Platina Office Smart Client Platina Security Service Möjligheter till vidareutveckling Färdigställande av klienten Uppladdning av lokala filer Skanningsstöd Digital signering

7 5.3.5 Utveckling av klienter för andra tjänster än dokumenthantering Referenser

8 1 Inledning I datorns begynnelse fanns endast rich clients, applikationer som kördes på den lokala datorn. Senare kom thin clients, applikationer som kördes på en central server via ett nätverk, ex. Internet. Idag används båda dessa typer, man har dock hittat både fördelar och nackdelar hos de två som motiverat en fusion för att undvika/minska nackdelarna samtidigt som fördelarna hos de båda kan nyttjas till fullo, Microsofts utformning av denna fusion kallas Smart Clients [19]. EBI Systems AB utvecklar och säljer ett informations- och verksamhetssystem vid namn Platina [22], detta system är under fortlöpande utveckling. EBI Systems har idag en rich client som skickas med produkten, den används i huvudsak för delar i dokumenthanteringen. Relativt många av de supportärenden som EBI Systems får rör just denna klient, nuvarande klient håller dessutom inte samma teknikhöjd som övriga Platina. Dessa problem var tillsammans två starka motiv till att undersöka ifall det fanns någon bättre teknik för att ta fram en ny klient. EBI Systems använder sig även av thin clients i sin produkt, men den tekniken räcker inte till för att lösa alla kundbehov. Då EBI fick höra talas om Smart Clients så blev de intresserade av att ta reda på hur denna teknik kunde nyttjas i Platina. Eftersom Smart Client-tekniken är relativt ny och EBI inte tidigare använt sig av denna så krävdes en övergripande undersökning av tekniken och omkringliggande teknologier, för att undersökningen inte skulle bli för omfattande så begränsades den till att resultera i en introduktion till Smart Clients samt en sammanfattning av de närmast omkringliggande teknologierna. Utöver detta så begränsades arbetet till Windows-plattformen eftersom Smart Client-tekniken är framtagen av Microsoft samt att Platina endast använder sig av Windows som plattform. Då EBI även ville se resultatet av denna undersökning i en praktisk tillämpning så ingick det i uppgiften att skapa en Office Smart Client för sökning i Platinas dokumentarkiv. 7

9 2 Teori 2.1 Introduktion till Smart Clients I datorns begynnelse fanns endast rich clients, applikationer som kördes lokalt. Senare kom thin clients, applikationer som kördes på en central server via ett nätverk, ex. Internet. Idag finns båda dessa typer, det finns både fördelar och nackdelar hos de två som har motiverat en fusion för att undvika/minska nackdelarna och samtidigt dra nytta av fördelarna hos de två teknologierna. Rich clients Fördelar: Nackdelar: Dessa klienter kan använda lokala resurser - både i form av hårdvara och mjukvara - för beräkningar, lagring, visualisering osv. Denna typ av klient medför dock ofta en omfattande administration. Thin clients Fördelar: Nackdelar: Dessa klienter har en enkel administration med hjälp av automatiska uppdateringar från en central server, snabb spridning och enkel åtkomst. Eftersom denna klienttyp körs från en central server så fungerar den endast om nätverket finns tillgängligt. Microsoft har utformat en teknisk specifikation som fått namnet Smart Clients, den specifikationen är resultatet av en fusion mellan de båda klienttyperna. Microsoft har givetvis försökt få med fördelarna från båda klienttyperna samtidigt som de gjort sitt bästa för att så få nackdelar som möjligt skulle följa med vid fusionen. Tekniken har delats in i tre typer: - Windows Smart Client, detta är en vidareutveckling av den traditionella fristående applikationen. - Office Smart Client, som använder Office plattformen och bygger in ny funktionalitet i denna. - Mobile Smart Client, vilka är utvecklade för att användas i PocketPC:s, smarta telefoner, osv, främst för åtkomst av viktig data och tjänster. Smarta klienter är gjorda för att vara online till så stor del som möjligt, för att därigenom använda de resurser som finns tillgängligt över nätverket. Smarta klienter kan ändå vara väldigt användbart för en användare som är sporadiskt uppkopplad, applikationen kan vid en sådan situation buffra utgående kommunikation utan att användaren påverkas, då nätverket sedan blir tillgängligt så sänds den buffrade kommunikationen till mottagaren. Några av de största problemen med en rich client består av installation och uppdateringar, det kan bli väldigt avancerade installationer samt ett oändligt arbete med dll:er som inte alltför sällan delas av flera applikationer vilket medför ytterligare komplexitet. En smart klient kan designas för att undvika dessa problem vilket i slutändan betyder högre produktivitet och lägre administrationskostnader. I det fallet att den smarta klienten buffrar data så finns det dock många aspekter att tänka på, vad händer t.ex. om klienten mot förmodan skulle krascha innan kommunikation med mottagaren har skett? Eller hur ska det nya priset i prislistan visas lokalt efter att användaren uppdaterat det, men databasen har inte mottagit det? En annan sak att tänka på med klienter som arbetar offline är hur de hanterar data som mottagits tidigare från nätverket, men som nu kanske är inaktuell. Hur man än löser detta så bör man designa applikationen så att den skiljer på information som överförts till mottagaren och information som ännu inte är 8

10 överfört. Microsofts förslag till en lösning på problemet med offline data består av att associera metadata till datat som skickas mellan server/klient, metadatat kan då användas för att t.ex. kontrollera när datat hämtades, hur länge det är giltigt, men förutom denna typ av information kan även andra egenskaper sättas, t.ex. angående säkerhetsaspekter. 2.2 Prestanda hos Smart Clients Det finns oändligt många punkter att begrunda när en applikation ska designas för att uppnå förbestämda prestandamål. Att redan vid designen tänka på prestanda möjliggör ofta att det i förväg kan urskiljas vilka delar av applikationen som kommer att kräva mycket tid/prestanda vid exekvering. Detta sätt kan vara avsevärt mycket mer kostnadseffektivt än att helt undvika prestandatänkandet vid designen för att sedan i efterhand upptäcka vilka delar av programmet som kräver optimering. Att då i efterhand försöka uppnå de prestandamål som satts kan medföra tidskrävande förändringar av designen. Det finns några punkter som i synnerhet bör begrundas: Uppstart av applikationen bör vara så snabb som möjligt för att användaren snabbt ska kunna börja sitt nyttjande av applikationen. Användargränssnitt bör inte låsa sig då långsamma operationer utförs eftersom detta kan uppfattas som att applikationen har kraschat. Kommunikation över nätverk och/eller mot andra applikationer bör vara genomtänkt för att få optimal prestanda, kan t.ex. viss data cachas eller måste alltid det senaste datat hämtas? Effektiv resurshantering med hjälp av Common Langue Runtime (CLR) Garbage Collection (GC) Garbage Collection.NET Framework innehåller en komponent som heter Common Language Runtime, en av uppgifterna som CLR har är att hantera Garbage Collection. När alla referenser till ett objekt är frigjorda så kommer det minne som använts av objektet automatiskt att frigöras av GC:n. Ett problem som kan uppstå vid denna automatiska hantering är att då man frigjort alla referenser till ett antal objekt som cirkulärt refererar till varandra så får GC problem att avgöra om objekten kan tas bort eller ej. Det är därför lämpligt att bryta objektens cirkulära referenser före den sista referensen till objekten släpps. En annan sak att tänka på när ett objekt skall tas bort är att ifall objektet har en Dispose-metod så ska denna metod anropas före objektet tas bort. Objekt kan även innehålla andra metoder som måste anropas före borttagning av objektet, för att ta reda på om ett specifikt objekt kräver speciell hantering innan borttagning så är manualen en bra referens. Om man vill att de objekt man själv skapat ska få en Dispose-metod så kan man lägga till IDisposable interfacet i dessa objekt. Klassen Object innehåller en Finalize-metod, eftersom alla klasser i C# har Object som basklass så finns denna metod i alla objekt, Finalize ska användas som backup ifall Dispose-metoden aldrig anropades före referensen till objektet frigjordes. Det går att explicit anropa GC:n för att den ska frigöra allt minne som inte längre används, detta är dock ej rekommenderat eftersom GC:n körs med mycket hög prioritet och kan medföra att t.ex. användargränssnitt låser sig under tiden som GC arbetar. 9

11 2.3 Kommunikation i.net Inte allt för sällan uppkommer behovet av att från en applikation kunna kommunicera med andra processer, ibland finns de andra processerna på samma dator och ibland sker kommunikationen över ett nätverk av något slag..net Framework innehåller flera bra kommunikationsalternativ att välja bland, t.ex. Webservices [4] och Remoting [20] Remoting i.net 2.0 Prestandamässigt så är Remoting det bättre alternativet jämfört med Webservices, men tidigare versioner av Remoting (HTTP samt TCP) är dock inte alltid optimala. Kommunikationsprotokollet tillsammans med det faktum att informationen som överförs måste serialiseras/deserialiseras före/efter överföringen bidrar till en flaskhals som i vissa fall kan undvikas helt. Då processerna som kommunicerar befinner sig på samma fysiska maskin så blir serialiseringen ett onödigt steg. Ett alternativ till Remoting via HTTP/TCP är Remoting via IPC [18], IPC står för InterProcess Communication och är i grunden Named Pipes. Med IPC så kan serialisering helt undvikas, anledningen till att serialisering ofta inte behövs när IPC används är att Named Pipes bygger på att processerna delar minnesutrymme, detta minnesutrymme används sedan för överföring av information vid kommunikationen. Nackdelen med IPC är dock avsaknad av inbyggd säkerhet samt de korta avstånden som kan överbryggas. IPC kan endast användas vid kommunikation inom den lokala maskinen, av denna anledning så finns inget säkerhetslager inbyggt eftersom det förutsätts att existerande hårdvara/mjukvara tar hand om säkerheten. Avsaknad av inbyggd säkerhet innebär emellertid inte att säkerheten helt försummats, accesslistor (ACL) kan t.ex. användas för att bestämma vilka användare/grupper som skall få tillgång till en specifik IPC-kanal. En annan nyhet i.net Framework 2 är att säkerheten för remoting via TCP har förstärkts markant med hjälp av nya stream-klasser, dessa klasser ger större kontroll över kryptering, signering och användarhantering vid remotinganrop. Serialisering i.net har tidigare haft problemet att när en ny version av ett serialiseringsobjekt skapats så kunde dessa objekt inte användas vid kommunikation med applikationer som använder sig av äldre versioner av denna objekttyp. En lösning på detta problem har införts i.net Framework 2, de delar som uppdaterats i serialiserings-objektet kan märkas med en tagg, denna tagg medför att olika versioner kan användas vid kommunikationen. 10

12 2.3.2 Webservices Webservices bryr sig inte om kommunikationsprotokoll, tekniken kan användas av alla typer av system så länge systemen kan använda XML för sin kommunikation. Eftersom det vanliga fallet är att kommunikationen går över HTTP/SOAP så blir Webservices med hög sannolikhet även användbart i miljöer där brandväggar används omkonfiguration av säkerhetsregler kan behövas i extrema fall. Webservices har dock sina nackdelar, eftersom Webservices innehåller en relativt stor mängd payload så kan andra alternativ vara att föredra i applikationer med hårda prestandakrav. Simple Object Access Protocol (SOAP) [13] är ett XML-baserat protokoll som skapats för kommunikation över Internet. Vad som överförs till/från en Webservice med hjälp av SOAP är helt upp till utvecklaren/användaren av tjänsten, protokollet dras dock med vissa brister på prestandafronten, så vid utveckling av en applikation som snabbt ska kunna överföra stora datamängder bör antagligen något annat överföringssätt väljas. SOAP går använda helt oberoende av vilket operativsystem, programmeringsspråk och överföringsprotokoll som används. Efter att SOAP blivit populärt så växte behovet av en metod för att beskriva meddelanden och hur de utbyts. Web Service Description Language (WSDL) är ett XML Schema som utvecklats av Microsoft och IBM, det är specifikt anpassat för att beskriva funktionaliteten hos Webservices som använder ett XML-baserat protokoll, t.ex. SOAP. WSDL tillåter att både meddelanden och operationer är abstrakt beskrivna, detta möjliggör att en Webservice som fysiskt finns på flera platser kan användas sig av samma wsdl-beskrivning. Efter att en metod för att beskriva Webservices tagits fram så kom idén om att kunna registrera och söka bland utexponerade Webservices. Universal Description, Discovery and Integration (UDDI) [14] är ett protokoll som används för att på ett snabbt och enkelt sätt söka och dynamiskt få tillgång till Webservices. Med hjälp av UDDI går det även att registrera Webservices som skall exponeras för omvärlden, definitionen av omvärlden bestäms av hur UDDI-servicen är konfigurerad, det kan vara allt ifrån det lokala nätverket till hela Internet. Skapa en Webservice on the fly I ett Visual Studio projekt är det möjligt att skapa referenser till Webservices, detta går snabbt och enkelt, nackdelen är dock att det blir svårt att ändra URL för denna Webservices vid exekvering av koden. Genom att istället skapa en proxy-klass för Webservicen så ges möjligheten att ändra URL till Webservicen under exekvering URL sätts vid skapandet av Webservice-proxy-objektet. För att automatiskt generera proxy-klasser till Webservices kan wsdl.exe (Web Services Description Language tool) användas. En god idé är att skapa en klass som ärver från den genererade klassen, i denna subklass utförs sedan de modifikationer som önskas anledningen till detta förfarande är att Webservice-proxys måste regenereras efter att Webservicen ändras på serversidan, ändringar och tillägg som gjorts i den tidigare genererade klassen måste då upprepas i den regenererade klassen. 11

13 2.4 Säkerhet i.net.net innehåller två huvudtyper för hantering av säkerheten, Role Based Security [21] samt Code Access Security (CAS) [7]. Role Based Security är baserat på användare och dess rättigheter, denna säkerhetstyp är nyttjad sedan länge. CAS är baserat på kod och dess rättigheter, att kunna identifiera och sätta rättigheter för kodavsnitt på liknande sätt som för användare är ett relativt nytt tankesätt och infördes samtidigt som första versionen av.net Role Based Security Idag är det väldigt vanligt att applikationer kommunicerar med varandra på ett eller annat sätt, samtidigt så har det blivit allt vanligare med bredbandsuppkopplingar mot Internet. Detta sammantaget har medfört att attacker från virus, trojaner, crackers och andra hot är något som vi mer eller mindre dagligen utsätts för. De som någon gång har blivit drabbad av detta elände är smärtsamt medvetna om hur viktigt det är med säkerheten hos datorsystem. Datorsäkerhet handlar givetvis inte bara om att skydda sig mot externa hot, säkerheten måste även gälla interna hot. Ett exempel på detta är hantering av känslig information som endast skall vara tillgänglig för utvalda personer, detta innebär att användarens identitet och behörighet måste kontrolleras noggrant även efter att användaren loggat in i ett visst system. Det händer att applikationer kommunicerar med ett flertal system av varierande typ, att hantera säkerheten i sådana miljöer kan vara väldigt krävande. För att trygga säkerheten hos en Smart Client så rekommenderar Microsoft att man förlitar sig på.net:s inbyggda funktionalitet för att kommunicera med operativsystemet och därigenom kontrollera identitet och behörighet hos användaren. Då man ser över säkerheten hos en applikation så är det viktigt med flera infallsvinklar, nedan följer en kort beskrivning av de vanligaste kategorierna. Autentisering Identifiering av användaren så att endast användare med rätt behörighet får åtkomst till hela eller delar av applikationen. Det finns en uppsjö av metoder för att autentisera användare, den metod som är bäst lämpad beror på hur applikationen skall användas och hur stallet av datorer ser ut. Mer information om detta kan hittas i [1], kap. 5 Authorization Bestämmelser för vilken åtkomst den identifierade användaren skall ha till applikationens olika funktioner. Efter att användaren än autentiserad så fastställs de rättigheter användaren har i systemet. Anonyma användare har ofta väldigt inskränkta rättigheter. Det finns två metoder som vanligtvis används i Windows operativsystem, resursbaserad authorization samt rollbaserad authorization. Den resursbaserade använder accesslistor för att reglera rättigheterna hos användarna. I den rollbaserade utnyttjas att användare ligger i olika grupper, grupper eller enstaka användare kan sedan tilldelas specifika rättigheter. Validering av data Kontroll så endast rätt typ av data skickas in till applikationen. Data som läses in av applikationen måste valideras för att säkerställa att det är rätt format före ytterligare behandling sker. Skydda applikationen mot buffer overflows. Tillåt aldrig användaren att mata in rena SQL-anrop, använd istället användardefinierade parametrar som efter inmatning kontrolleras noggrant. Kontrollera och filtrera inmatat data efter hur det ska se ut, filtrera inte efter hur det inte ska se ut det finns ofta oändliga kombinationer på hur datat inte ska se ut, men antagligen endast ett fåtal kombinationer på hur det ska se ut Regular Expressions [17] används med fördel vid denna operation. 12

14 Skydda känslig data Om applikationen hanterar mer eller mindre känslig information så måste denna information skyddas, både vid lagring (lokalt och centralt) samt vid kommunikation. Det finns färdiga verktyg att använda vid dessa operationer, t.ex. SSL vid kommunikation. Om en fysisk dator har flera användare så bör data associerad med varje användare anses vara känslig data och hanteras därefter. Med känslig data avses all data som en cracker kan använda sig av och eventuellt modifiera för att komma åt hemlig information eller för att bryta sig in i systemet. Om man verkligen måste spara känslig data lokalt så kan man ibland använda sig av hashvärden istället för det ursprungliga värdet användarnamn och tillhörande lösenord kan till exempel hashas före lagring, vid användarkontroll så hashas sedan inmatat data före det jämförs med de lagrade värdena. En bra hashfunktion ger ett unikt resultat för varje inmatat värde, samtidigt är det oerhört svårt att från resultatet kunna räkna fram det ursprungliga värdet i fallet med användarnamn/lösenord så har det ingen betydelse att namn/lösenord inte sparas i klartext, det intressanta är att kunna ta reda på om användaren finns i systemet och i så fall vilken behörighet användaren har, om man vid denna process kontrollerar användarens identitet med hjälp av hashvärden istället för okrypterade värden har ingen betydelse för systemets övriga funktion. Granskning och loggning Skapande av loggar över händelser i applikationen och över anrop från användare kan vara en god idé, detta kan underlätta för administratörer och utvecklare som efterhand vill ta reda på vad som lett fram till en viss händelse (t.ex. obehörig åtkomst av känslig data). Att spara loggar på annan plats än hos klienten bör övervägas, ett sådant förfarande kan undvika att loggarna blir ändrade/raderade av den som eventuellt brutit sig in i systemet. Hantering av Exceptions Hantering bör finnas för Exceptions för att undvika onödiga krascher och istället visa användarvänliga meddelanden med information om vad som gick fel. Detaljer om vad som hänt kan med fördel läggas till i loggen. Ändrings och konfigurations hantering Ansvariga personer måste se till att ha fullständig kontroll över konfiguration och ändringar/uppdateringar inom IT-miljön, med bra kontroll så blir det lättare att upptäcka förändringar som gjorts av obehöriga, det blir samtidigt även enklare att i förväg avgöra eventuella säkerhetsrisker som behöriga förändringar kan föra med sig. 13

15 2.4.2 Code Access Security Före CAS så fick användare ibland frågan ifall en applikation skulle tillåtas att exekvera, om användaren svarade ja så fick applikationen fullständiga rättigheter (samma rättigheter som användaren), ifall användaren istället svarade nej så kunde inte applikationen startas. Med CAS så har det tillkommit fler nivåer vid denna situation, en applikation kan få begränsade rättigheter. Kort sagt kan man säga att autentisering och authorization sker för den exekverande programkoden istället för den användare som startade exekveringen, därmed kan begränsningar för åtkomst till utvalda resurser sättas för den exekverande programkoden. Genom att använda CAS så går det att: Sätta begränsningar på vad den exekverande programkoden har tillåtelse att göra. Identifiera och sätta begränsningar för den programkod som anropar din programkod. CAS kan med fördel användas i en dll för att begränsa tillgången till den funktionalitet som erbjuds. Programkod som t.ex. gör anrop över remoting kontrolleras för behörighet till denna resurs CAS tar ingen hänsyn till användarens behörighet. Det är CLR som kontrollerar och ger koden tillåtelse att göra de operationer som den har behörighet till. Om behörighet skulle saknas så kastas ett SecurityException. CAS består av följande delar: Permissions Permission sets Code groups Evidence Policy Permissions Representerar access till skyddade resurser eller tillgången till att använda skyddade operationer. xxpermission är klasser som används för att representera de olika typer av permissions som används (xx representerar namnet för ett permission). För att skapa egna Permissions och lägga till dessa i systemets.net-inställningar så kan man följa guiden i [8]. Permission sets Det går att skapa grupperingar av permissions för att på ett mer överskådligt sätt administrera vilka rättigheter som de skyddade resurserna/operationerna skall kräva samt vilka rättigheter som den exekverande koden tilldelas. Det finns färdiga grupperingar, FullTrust, LocalIntranet, Internet, Execution samt Nothing FullTrust har obegränsade rättigheter medan Nothing inte ens har tillåtelse att exekvera, de övriga ligger någonstans däremellan. Code groups Logisk gruppering av kod med specificerade krav för att tillhöra denna grupp, t.ex. kod från en given URL eller kod med ett unikt Strong Name. Även här finns det färdiga grupperingar, My_computer_zone, Local_intranet_zone, Internet_zone etc. Det går givetvis skapa sina egna grupperingar [9] som baseras på Evidence. 14

16 Evidence Kod identifieras utifrån sitt bevis (Evidence), de olika beviskategorierna är: All Code, Application Directory, Custom Membership Condition, Hash, Software Publisher, Site, Strong Name [5], URL och Zone. Policy Säkerhetspolicyn är en konfigurerbar samling av regler som CLR följer när den bestämmer vilka rättigheter som skall tilldelas den exekverande koden. Det finns fyra policynivåer, Enterprise, Machine, User samt Application Domain (se figur 1). Varje nivå är oberoende av de andra nivåerna, varje nivå har även sina egna Code Groups och Permission Sets. Figur 1: Översikt av CAS olika säkerhetsnivåer. 15

17 Exekvering När en skyddad resurs/operation anropas så kommer Runtime Security System att vandra igenom stacken och kontrollera rättigheterna hos varje anrop som ledde fram till att denna säkerhetsförfrågan uppstod, se figur 2. Om det finns någon i stacken som saknar de rättigheter som krävs så kommer ett SecurityException att kastas. Figur 2: Hur en stack walk genomförs. Om man av någon anledning vill undvika proceduren med att kontrollera hela stacken så går det att förhindra genom att före anropet till den skyddade resursen/operationen anropa xxpermission.assert() (där xx är en typ av permission) samt att direkt efter anropet använda System.Security.CodeAccessPermission.RevertAssert() för att återställa till normal säkerhetskontroll igen. En varning är på sin plats här eftersom då man använder Assert öppnar för attackerare så de genom att anropa vår kod (efter Assert och före RevertAssert) skulle kunna komma åt skyddade resurser/operationer. Det finns även en metod för att explicit neka åtkomst till specifika resurser/operationer genom att använda xxpermission.deny() samt System.Security.CodeAccessPermission.RevertDeny() för att återställa till normalt beteende. På samma sätt kan man tillåta viss åtkomst till en resurs, för att göra detta använder man xxpermission.permitonly() och senare System.Security.CodeAccessPermission.RevertPermitOnly() för att återställa säkerheten. 16

18 2.5 Trådning i.net Eftersom man ibland utför operationer som kan ta tid att slutföra så kan trådar vara väldigt användbara, i.net finns det ett par olika vägar att välja bland vid trådning. Nedan följer en kort beskrivning av de olika metoder som finns samt när de bör användas ThreadPool.NET innehåller något som kallas för ThreadPool, det är en samling med trådar som hanteras av.net Framework, varje process har sin egen ThreadPool. ThreadPool innehåller två typer av trådar: Worker threads, dessa trådar finns i the standard system pool, en standard tråd som hanteras av ramverket, de flesta operationerna exekveras av dessa. Completion port threads, används för asynkrona I/O operationer, använder IOCompletionPorts API:et. Fördelen med ThreadPool är att det är väldigt enkelt att använda och lämpar sig bra för mindre oberoende rutiner som skall köras i bakgrunden Thread class För att få mer kontroll över de trådar som skapas så kan Thread-klassen vara ett bra alternativ, denna typ lämpar sig bra när: Tråden skall ha en specifik prioritet. Det kan förmodas att rutinen som skall köras kommer att ta lång tid annan typ av trådning kan blockera efterkommande anrop. Åtkomst till specifika resurser kontrolleras genom att använda en särskild tråd som handtag till dessa resurser. Tråden ska ha en speciell identitet. Fördelen med Thread Class är således stor kontroll över tråden och dess egenskaper Delegates En delegate är en funktions/metod-pekare, då en delegate definieras så specifieras de in/utparametrar som rutinen (funktionen/metoden) måste ha för att passa in på denna typ av delegate. En delegate kan anropas både synkront och asynkront, den metod som antagligen är den vanligaste är dock asynkrona anrop vid synkrona anrop så blockerar nämligen den anropande tråden fortsatt exekvering fram till att delegate-rutinen returnerar, vilket i praktiken medför samma beteende som om den anropande tråden själv hade exekverat delegate-rutinen. Fördelen med delegates är att denna metod har in/ut-parametrar, nackdelen är dock att delegates endast kan användas vid trådning där ingen kommunikation med användaren sker denna begränsning går emellertid att komma runt, om ett användargränssnitt skall uppdateras så kan delegate rutinen istället för att själv uppdatera gränssnittet anropa den tråd som innehåller användargränssnittet och i anropet skicka med den information som behövs för uppdateringen. 17

19 2.5.4 Webservice Proxy Webserviceanrop från användargränssnitt bör ej vara synkrona eftersom responstiden vid kommunikation över nätverk inte kan förväntas vara optimal. Då en webbreferens skapas i Visual Studio så skapar VS en proxyklass för den Webservice som anges, i proxyklassen skapas både synkrona och asynkrona metoder för varje metod som Webservicen erbjuder. Om större kontroll över Webservice proxyklasser önskas så kan verktyget wsdl användas, detta verktyg följer med i ramverkets SDK. Om ändringar eller tillägg behövs i proxyklasser som genererats med wsdl så kan det vara en god idé att skapa nya klasser som ärver från de genererade klasserna, ändringar/tillägg görs sedan i dessa subklasserna. Webservices kan ändras på serversidan, en sådan uppdatering ger till följd att nya proxyklasser måste genereras. Vid denna generering används antagligen wsdl, detta medför att eventuella ändringar som gjorts i de klasserna som tidigare genererats även måste göras i de nya proxyklasserna. Om ändringar/tillägg istället utförs i subklasser så medför en uppdatering av proxyklasser inget ytterligare arbete. Webservice proxys kan användas vid trådning där ingen kommunikation med användaren sker - detta går dock att komma runt, om ett användargränssnitt skall uppdateras när Webservicen är färdig så kan en callback-metod anges vid anropet av Webservicen. Denna callbackmeod anropas sedan då Webservicen är färdig, i callback-metoden (som i detta fall finns i en tråd som har ett användargränssnitt) kan sedan resultatet från Webservicen hämtas för att därefter användas när användargränssnitt uppdateras Tasks Genom att dela in sin applikation i olika arbetsuppgifter (tasks) så kan komplexiteten vid trådning hållas på en rimlig nivå, se figur 3. Tråden med användargränssnittet startar och stoppar tasks genom att kommunicera med task-objekt, ett task-objekt är ett handtag till en arbetsgrupp. Varje arbetsgrupp innehåller en eller flera trådar som utför arbete, då t.ex. nya resultat finns att hämta så meddelar task-objektet detta genom att skicka ett event till UItråden. Alla events som UI-tråden skall hantera bör finnas i UI-tråden av den enkla anledningen att UI-tråden inte ska behöva känna till uppbyggnaden av alla tasks. Figur 3: En grafisk representation över ett Task-mönster. 18

20 2.6 Installation och uppdatering av Smart Clients Det finns ett antal metoder att välja bland då man ska distribuera en Smart Client. No-Touch deployment No-Touch deployment med en uppdateringsmodul Kod som körs från ett gemensamt utrymme Xcopy Windows installationspaket Automatisk uppdatering ClickOnce i.net No-Touch deployment Kan användas för installation av mindre applikationer eller delar av större applikationer, det är dock inte speciellt lämpligt för full installation av avancerade Smart Clients. Alla filer som tillhör applikationen finns tillgängliga på en webbserver, när användaren klickar på en länk så laddar.net Framework ner applikationen och de filer som applikationen är beroende av. Standardinställningar för säkerhets policys medför att denna teknik har stora begränsningar, det går t.ex. inte att skriva till hårddisken (förutom till isolerat utrymme), anropa en databas eller lägga till länkar på startmenyn No-Touch deployment med en uppdateringsmodul Kan användas för installation av mindre applikationer eller delar av större applikationer, det är dock inte speciellt lämpligt för full installation av avancerade smarta klienter. Denna metod fungerar genom att en mindre applikation laddas hem och startas av.net Framework då en användare klickar på en länk, denna applikation laddar i sin tur ner resterande delar av den fullständiga applikationen. Begränsningarna hos denna metod är färre än hos No-Touch utan uppdateringsmodul, för att denna metod skall fungera så måste den dock ha tillräckligt med rättigheter för att ladda hem och spara de resterande delarna av applikationen på den lokala hårddisken Kod som körs från ett gemensamt utrymme Denna metod liknar No-Touch deployment, skillnaden - förutom var användaren går för att starta applikationen - är att det inte sker någon lokal cachning av programmet Xcopy Alla filer som hör till applikationen kopieras till den dator som skall köra den smarta klienten, för att avinstallera den smarta klienten så är det bara att ta bort alla de filer som tidigare kopierats in. Xcopy-metoden innebär t.ex. att förändringar i registret eller registrering av COM-komponenter inte sker automatiskt. Det går dock att åstadkomma dessa förändringar/registreringar manuellt efter att filerna kopierats in. Denna metod kan vara användbar i vissa fall, det finns dock oftast andra metoder som är både lämpligare och mer användbara än denna Windows installationspaket Det går att bygga egna installationspaket för den smarta klienten, genom att göra detta så begränsas man endast av de restriktioner som användaren som kör installationen har. Denna metod möjliggör väldigt komplexa installationer, detta betyder inte att man bör använda någon annan metod för mindre komplexa installationer utan denna metod kan vara förstahandsvalet även för enkla installationer. 19

21 2.6.6 ClickOnce i.net 2.0 Detta är en vidareutveckling av No-Touch deployment, denna nya teknik undviker vissa krav på säkerhetsinställningar för start av applikationer över nätverk. Säkerhetsinställningar kan göras automatiskt samtidigt som applikationen installeras/körs från webbservern rättigheter för att starta installationen från webbservern måste dock finnas. Den stora fördelen med ClickOnce är emellertid att en uppdatering av en applikation väldigt enkelt distribueras ut till användarna, om applikationen körs från webbservern så kommer den senaste versionen alltid att användas, om applikationen istället installeras lokalt så finns ett par olika förfaranden: Ingen automatisk kontroll av uppdateringar sker. Automatisk kontroll sker före applikationen startar. Automatisk kontroll sker efter att applikationen startat. System.Deployment-API används i applikationen för att bestämma när applikationen skall kontrollera ifall uppdateringar finns tillgängliga. Om inställningarna är satta till att ingen automatisk kontroll skall ske så får administratören eller användaren själv se till att hålla sin applikation uppdaterad. Om ClickOnce är konfigurerad för att automatiskt söka efter uppdateringar och en uppdatering finns tillgänglig så kommer - beroende på konfiguration av ClickOnce - antingen uppdateringarna att laddas hem före applikationen startat eller så kommer uppdateringarna att laddas hem i bakgrunden efter att applikationen startat för att sedan vid nästa start av applikationen meddela användaren om att en uppdatering finns tillgänglig. Det finns inställningar för hur ofta applikationen automatiskt skall söka efter uppdateringar, t.ex. max en gång per vecka. Ifall System.Deployment-API används så är det upp till utvecklaren att bestämma och implementera uppdaterings-funktionaliteten. Visual Studio har inbyggd funktionalitet för ClickOnce som gör att man på ett enkelt sätt kan publicera sitt projekt på den lokala hårddisken, på en nätverksplats, på en ftp-server eller på en webbserver. Visual Studio genererar vid publicering automatiskt de xml-dokument som används av ClickOnce för installation/uppdateringar. Det finns dock situationer där ClickOnce inte är att föredra, om t.ex. drivrutiner måste installeras samtidigt som applikationen så är msi-paket att föredra, generellt så går ClickOnce inte heller att använda till att distribuera addins till t.ex. MS Office eftersom sådana addins ofta kräver speciell registrering och aktivering i moder-applikationen application Då man använder det inbyggda verktyget i VS2005 för att skapa en ClickOnce-installation så kommer en installationsfil (applikationsnamn.application) att skapas på den plats man säger att installationen ska ligga. Denna fil är ett XML-dokument med information om applikationen och dess tillhörande delar samt hur den skall installeras/köras. XML-dokumentet är signerat med en RSA-nyckel, detta innebär att om någon inställning i filen ändras så kommer signeringen inte längre att vara giltig och en framtida installation kommer inte att fungera. För att ändra inställningar i installationsfilen eller skapa nya installationsfiler så kan de medföljande verktygen mage.exe eller mageui.exe användas, dessa följer med.net Framework SDK. 20

22 2.7 Distribution av Smart Client uppdateringar Bara för att en applikation är skapad och distribuerad så är inte arbetet slut, med stor sannolikhet så kommer uppdateringar av applikationen att ske. Hur dessa uppdateringar skall distribueras bör man tänka på före den första versionen av programmet finns ute hos användarna. Det finns samma typer av uppdateringsmetoder som installationsmetoder, med ett tillägg, automatisk uppdatering Automatisk uppdatering Applikationen kan skapas för att själv kontrollera om det finns nya uppdateringar att hämta, då uppdateringar finns så laddar applikationen automatiskt hem och installerar dessa. Detta förfarande är ofta det mest lämpade sättet att uppdatera en Smart Client, användaren av applikationen behöver inte involveras och så länge som klienten har tillgång till servern med uppdateringar så kommer applikationen alltid att använda de senaste uppdateringarna. En viktig sak att tänka på är att om man uppdaterar någon del av som innehåller Strong-Names så måste även de delar av applikationen som använder dessa Strong-Name-delar ingå i de uppdateringar man gör. Microsoft tillhandahåller ett paket för automatisk uppdatering, Updater Application Block [6]. Funktionalitet för automatisk uppdatering finns även inbyggd i den kommande versionen av Visual Studio (VS 2005), där kallas tekniken ClickOnce. 2.8 Visual Studio Tools for Office 2005 Visual Studio Tools for Office (VSTO) [15] är en samling verktyg för att integrera applikationer med MS Office. Tidigare har man kunnat använda Visual Basic for Applications (VBA) för att skapa och integrera applikationer med Office, detta är fortfarande möjligt, men VSTO medför stora fördelar i form av frihet för vilket utvecklingsspråk som kan användas, förbättrad säkerhet, ökade möjligheter för att skapa distributionspaket samt integration med Visual Studio. VSTO är till för att skapa lösningar för dokumenten i Office [12], inte för applikationerna i Office. Det går dock att skapa anpassade menyer och verktygsfält för dokument men om t.ex. en Add-In till Office skall skapas så finns det verktyg som är bättre anpassade för detta än VSTO. En av de stora fördelarna med VSTO är att det är integrerat med VS, detta innebär att det inte blir så stor skillnad för en utvecklare som är van vid VS då han/hon utvecklar lösningar för Office jämfört med då en vanlig lösning skapas. Office-objekt visas som.net-baserade kontroller i VS, data kan bindas till dokument, egenskaper hos Office-objekt visas under properties-fliken i VS. Med den senaste utgåvan av VSTO så har det tillkommit funktionalitet för att komma åt Taskpane objektet (åtgärdsfönstret) i Office 2003, i detta fönster är det bl.a. möjligt att lägga in ett GUI för den lösning man skapar. Om en lösning som skapats med VSTO skall felsökas så är det ingen skillnad mot att felsöka en vanlig applikation, breakpoints sätts på vanligt vis och exekveringen startas från Visual Studio. Säkerheten i VSTO [10] bygger på befintlig.net teknologi i form av användarbaserad säkerhet tillsammans med CAS. Detta kan ställa till vissa problem eftersom Office kräver att VSTO-lösningar explicit tilldelas CAS rättigheter, oberoende av var filer för exekveringen hämtas ifrån. Detta skiljer sig från det vanliga fallet då applikationer som körs från den lokala datorn erhåller fullständiga rättigheter (om standard inställningarna inte ändrats). 21

23 3 Metoder För att lösa uppgiften med utforskning av tekniken i och runt Smart Clients så användes i huvudsak elektroniska källor, en orsak till detta val är att tekniken är så pass ny att det var svårt att hitta bra källor som var utgivna i pappersformat. Två böcker införskaffades dock, se [20] och [21] för mer information om dessa. Verktyg som använts vid utvecklingsarbetet är: Rational Rose MS Visual Studio 2005 Team System Beta 1 samt MS Visual Studio 2005 Team System Beta 2 MS Windows 2000 samt MS Windows XP MS Office 2003 Professional 3.1 Kravspecifikation Se Appendix Kort beskrivning av analys Det resultat som EBI ville få ut av mitt arbete var 1. En Office Smart Client för sökning, nerladdning och uppladdning av dokument till/från Platinas databas 2. En Windows Service för hantering av klientapplikationers användaruppgifter. 3. En utloggningsmodul för att kunna logga ut den/de användare man är inloggad som. EBI hade en önskan om att i framtida klient-applikationer kunna använda hela och/eller delar av den funktionalitet som jag skulle realisera så det var ganska naturligt att försöka dela upp projektet i moduler. EBI hade vissa synpunkter på hur utformningen av dessa moduler skulle göras, EBI hade tänkt sig två övergripande moduler, en säkerhets-dll för att hantera inloggningsuppgifter och rättigheter samt en dokument-dll för att hantera sökning, nerladdning, visning, osv. av dokument. Då det även finns information i andra former än dokument i databasen så är tanken att bibliotek liknande dokument-dll:en skall kunna utvecklas i framtiden. Efter fortsatt analys och design så tillkom ytterligare två moduler, ett bibliotek för loggning samt ett service-bibliotek som innehåller ett par klasser för kommunikation mellan servicen och klienter. Förutom ovannämnda moduler så behövdes applikationspaket (för klient, service, utloggning) som använder sig av funktionaliteten i modulerna och sätter samman denna till att passa sitt specifika ändamål. Då Platina servern i dagsläget redan innehåller en mängd av Webservices med all möjlig funktionalitet som kan tänkas behöva för dokument- och säkerhetshantering i klientapplikationen så fanns det ingen anledning att välja något annat protokoll för kommunikation mot servern. I.NET ramverket finns det två inbyggda verktyg som i de flesta fall är lämpliga att använda för kommunikation, Webservices och Remoting. Mitt val för kommunikation mellan Officeklienten och säkerhets servicen blev Remoting, anledningen till detta val är att skillnaden i prestanda hos de två teknologierna kan bli stor (till Remotings fördel), speciellt om många mindre meddelanden skickas detta är precis vad som kommer att ske vid kommunikationen mellan klienten och servicen. 22