ARKITEKTUR 1(25) Version 0.13 Datum Diarienr / Arkitektur för Geodataportalen v2.0

Transkript

1 ARKITEKTUR 1(25) Arkitektur för Geodataportalen v2.0

2 ARKITEKTUR 2(25) Innehållsförteckning 1 Dokumenthistorik Inledning System Arkitektur Introduktion Applikationslagret Tjänstelager Datalager Användningsfallsvy Webbpubliceringssystem Integrerad sök- och kartkomponent SDI Säkerhetssystem Övervakningssystem Betalsystem Ickefunktionella krav Fysisk vy Geodata.se Sök- och kartkomponent Publiceringsmotorn Övervakare GeoRM Externa tjänster Logisk vy Sök- och kartkomponent GeoRM Publiceringsmotorn Dynamisk Vy Fallet Find-Bind Behörighetshantering 21 4 Driftsättningsvy Driftsättningsalternativ webbhotell Driftsättningsalternativ egna servrar 24

3 ARKITEKTUR 3(25) 5 Referenser...25 Figurförteckning Figur 1. Systemarkitektur för INSPIRE... 5 Figur 2. Systemarkitektur för Geodataportalen version Figur 3. Användningsfallsdiagram Integrerad sök- och kartkomponent... 8 Figur 4. Användningsfallsdiagram över säkerhetssystemet... 9 Figur 5. Komponenter i Geodata.se...11 Figur 6. Geospatial Rights Management paketet baserat på XACML auktorisationsmodell...12 Figur 7. Arkitektur för det integrerade sök- och kartgränssnittet...15 Figur 8. Den logiska strukturen av Geodata.se...17 Figur 9. Aktivitetsdiagram för fallet Find Bind...20 Figur 10. Behörighetskontroll med XACML...22 Figur 11. Sekvensfallsdiagram som beskriver flödet vid behörighetshantering i en federation av organisationer...22 Figur 12. Nätverk och servrar i Lantmäteriets webbhotell...23 Figur 13. Nätverk och servrar i egen serverpark...24

4 ARKITEKTUR 4(25) 1 Dokumenthistorik Datum Utfärdare Version Status Kommentar Jonas Jernunger, Fredrik Persäter 0.01 utkast Dokument skapat, Struktur, Fysisk vy Fredrik Persäter 0.02 utkast Logisk vy, dynamisk vy och Användningsfallsvy Jonas Jernunger 0.03 utkast Bakgrund och kompletteringar i Fysisk vy Fredrik Persäter 0.04 utkast Omarbetning av struktur och textmassa Fredrik Persäter 0.05 utkast Driftsättning och konfiguration, omarbetning Fredrik Persäter 0.06 granskning Förtydligande ang. hantering av anv. och roller Jonas Jernunger 0.07 granskning Förtydliganden kring konfiguration Fredrik Persäter 0.08 granskning Justeringar efter samtal med Kjell Hjorth Fredrik Persäter 0.09 granskning Justeringar efter remiss i teknisk arbetsgrupp Fredrik Persäter 0.10 granskning Komplettering kring katalog och kartgränssnitt Fredrik Persäter 0.11 granskning Synkroniserat begrepp/definitioner mot kravdokumentet Fredrik Persäter 0.12 granskning Kompletterat med arkitekturskiss för sök- och kartgränssnittet i den logiska vyn. Motiverat teknikval. Lagt till referenser. Fredrik Persäter 0.13 granskning Delat upp Sök- och kartkomponenten i två separata komponenter.

5 ARKITEKTUR 5(25) 2 Inledning Den nationella Geodataportalen tas fram inom ramen för den svenska geodatastrategien. Portalen kommer att ingå som en del i ett europeiskt nätverk av Nationella SDI:er 1 som tas fram i genomförandet av EU:s INSPIRE direktiv. Arkitekturen i det här dokumentet baseras till stor del på de intentioner som finns i Inspire-direktivets tekniska arkitektur. Figur 1. Systemarkitektur för INSPIRE Detta dokument syftar till att sammanställa arkitekturen för Geodataportalen V 2.0. Man bör vara medveten om att arkitekturen i sin helhet inte är implementerad inom ramen av V Spatial Data Infrastructure

6 ARKITEKTUR 6(25) 3 System Arkitektur 3.1 Introduktion Arkitekturen för Geodata.se är byggd på en treskiktslösning. De tre lagren benämns applikationslagret, tjänstelagret och datalagret. Applikationslager pekar generellt ut applikationer som vill konsumera tjänster i tjänstelagret. I detta dokument kommer dock endast den svenska geodataportalen att avhandlas. Systemet skall vara uppbyggt av löst knutna moduler enligt SOA 2 konceptet eller m.a.o. det skall vara enkelt att byta ut samt integrera nya moduler. Figur 2. Systemarkitektur för Geodataportalen version 2.0 Alla interna tjänster och moduler som är direkt knutna till systemet skall vara webbaserade. Öppna standarder skall användas för att underlätta interoperabilitet internt inom systemet, men även externa ut mot andra system. För att göra oss fri från låsningar mot vissa produkter och leverantörer bör öppen källkod nyttjas, så långt det är möjligt Applikationslagret Alla komponenter som ingår i applikationslagret skall kommunicera med datalagret via ett tjänstelager. Kommunikationen sker via standardiserade gränssnitt, på så vis är komponenterna i tjänstelagret och 2 Service Oriented Architecture. Den svenska benämningen är Tjänsteorienterad arkitektur

7 ARKITEKTUR 7(25) klientlagret löst knutna till varandra och kan vid behov ersättas utan att det leder till stora insatser. I applikationslagret hanteras användaren via sk. single sign-on (SSO) vilket innebär att användaren kan röra sig fritt mellan olika gränssnitt och applikationer inom sitt behörighetsområde när en autentisering väl är gjord Tjänstelager Tjänstelagret är det lager som hanterar logiken i systemet. All kommunikation mellan applikationslagret och datalagret går via tjänstelagret där det bearbetas och struktureras för att förmedlas vidare till avsett lager. I tjänstelagret ingår även externa tjänster med standardiserade gränssnitt ex. OGC 3 tjänster(wms 4,WFS 5 ), transformationstjänster, övervakningstjänster mm. Här finns även moduler för säkerhet, avtalsmodeller, prismodeller, betaltjänster och annat som är nödvändigt för att skapa en pålitlig och säker infrastruktur för geografiska resurser. I figuren är dessa moduler samlade under benämningen Geo Rights Management (GeoRM). GeoRM ligger som ett lager ovanför alla andra tjänster i tjänstelagret och kommunicerar själv direkt mot säkerhetsdatabasen Datalager Datalagret består av två databaser, Metadatakatalogen och SDI Säkerhetsdatabasen. Metadata katalogen lagrar metadata för geografiska resurser som publiceras in till systemet. Vissa logiska operationer byggs in för att hantera geografiska objekt samt optimera prestanda. Säkerhetsdatabasen lagrar information som rör behörigheter och rättigheter i systemet. Här ligger även information som reglerar avtal och licenser. Säkerhetsdatabasen skall kunna kopplas ihop i ett sammanhängande behörighetssystem som hanterar behörigheter inom och över organisationsgränser. 3.2 Användningsfallsvy Webbpubliceringssystem För att optimalt hantera den information som skall spridas behövs ett webbpubliceringssystem 6. 3 Open Geospatial Consortium 4 Web Map Service 5 Web Feature Service 6 Ett webbpubliceringssystem (eng. Web content management system WCMS) är ett innehållshanteringssystem för att förenkla kollaborativ utveckling av en webbplats.

8 ARKITEKTUR 8(25) I webbpubliceringssystemet skall all information finnas som har med Geodata.se att göra (med undantag av direkta hjälptexter för geodataportalen). Det är hit adressen skall peka, vilket gör systemet till den officiella ingången även för geodataportalen. Webbpubliceringssystemet och geodataportalen utgör tillsammans Geodata.se Integrerad sök- och kartkomponent Den integrerade sök- och kartkomponenten är det verktyg där användarna skall kunna söka efter, utvärdera metadata för, titta på och ladda ner geografiska resurser i enlighet med det beslut som är tagna i den svenska Geodatastrategien. Figuren visar de användningsfall som komponenten måste kunna hantera. Figur 3. Användningsfallsdiagram Integrerad sök- och kartkomponent Webbsidorna redigeras via ett webbgränsnitt. Användaren behöver vanligen inte använda HTML, utan kan använda enkel vad du ser är vad du får -redigering. Idén är att låta ett datasystem sköta den tekniska hanteringen av innehållet, stå för avancerade funktioner samt automatisera sysslor som annars skulle innebära massor av redundant manuellt arbete. (Wikipedia).

9 ARKITEKTUR 9(25) SDI Säkerhetssystem Önskemålet om att resurser skall vara mer allmänt tillgängliga i digital form över nätverk kräver ett system som ger en pålitlig och säker infrastruktur för att köpa, förvalta och skydda rättigheter till dessa resurser. Generellt sett krävs det att systemet skall hantera behörigheter för användarna, regler och rättigheter för användandet av resurser publicerade i Portalen, digitala avtal och licenser samt e-handel. Figuren nedan visar de användningsfall som skall lösa dessa frågor i systemet. 7 Figur 4. Användningsfallsdiagram över säkerhetssystemet Övervakningssystem För att säkerställa en hög kvalité på portalen måste metadatakatalogen, publiceringsmotor m.m. övervakas. Även tjänsterna som är publicerade i portalen bör övervakas så att användarna direkt kan få en uppfattning om tjänsterna är tillgängliga eller inte. Övervakningssy- 7 I figuren finns en användare benämnd Licensieringssystem. Licensieringssystemet representerar en maskinell lösning som med automatik skapar de licensmodeller som behövs utifrån vad mänskliga användare av geodata väljer att konsumera.

10 ARKITEKTUR 10(25) stemet omfattar även de mätningar som skall göras av SDI användningen och som skall rapporteras i enlighet med Inspire-direktivet Betalsystem Under utredning och kommer troligen inte att vara en del av version Ickefunktionella krav Systemet ska installeras och driftsättas i Lantmäteriets ITinfrastruktur. Följande är beslutat inom ramen för Inspire och utgör generella krav för V 2.0. Prestanda Svarstiden för avsändning av det första svaret på en söktjänstförfrågan ska under normala förhållanden vara högst 3 sekunder. Normala förhållanden är perioder utanför toppbelastning. De gäller under 90 % av tiden. Kapacitet Enligt tjänstekvalitetsprestandan ska det lägsta antalet begärda söktjänster som expedieras samtidigt vara 30 per sekund. Tillgänglighet Tillgängligheten hos en INSPIRE nättjänst är sannolikheten att systemet är igång. Värde: 99 %. Nertiden per dygn får inte överstiga 15 minuter under arbetstid. I övrigt hänvisar vi till kravspecifikationen för Geodataportalen version Fysisk vy I denna vy presenterar vi hur den fysiska miljön i geodataportalen kommer att se ut för version 2.0. Här beskrivs systemets alla ingående komponenter, deras fysiska placeringar och deras inbördes relationer Geodata.se Huvudkomponenterna i systemet som utgör den infrastruktur som har fått namnet Geodata.se är: Content Management System (CMS) eller på svenska Webbpubliceringssystem, Sök- och kartkomponenterna, Publiceringsmotorn, Övervakare samt Geo Rights Management System (GeoRM).

11 ARKITEKTUR 11(25) Figur 5. Komponenter i Geodata.se Sök- och kartkomponent Sök- och kartkomponenterna skall tillhandahålla grafiska användargränssnitt för att kunna söka efter, utvärdera metadata för, titta på och ladda ner geografiska resurser. Här ligger även logiken för kommunikationen med metadatakatalogen. De båda komponenterna har en nära koppling till varandra men fokus i sökkomponenten är att ge sökmöjligheter mot den information som finns i metadatakatalogen samt att presentera träffarna så att användaren kan utvärdera metadata för dessa. Kartkomponenten är ett verktyg där användaren kan utvärdera den geografiska informationen i form av rasterbilder och/eller vektordata Publiceringsmotorn Publiceringsmotorn är den komponent som skall göra det möjligt att publicera validerat metadata till metadatakatalogen. Publicering kan ske via webbaserat verktyg som ingår i geodataportalen, via externa metadataredigeringsverktyg eller via skördning från andra kataloger/katalogtjänster Övervakare Övervakaren består av dels en driftsövervakning av Geodata.se dvs katalog, skördningsverktyg och GeoRM och del den övervakning som

12 ARKITEKTUR 12(25) krävs för den årliga rapport som skall göras enligt Inspire-direktivet. Respektive tjänsteleverantör måste enligt direktivet mäta användningen av sina tjänster. Dessa mätningar skall rapporteras in till Geodata.se så att en sammanställd rapport kan levereras enligt kraven GeoRM GeoRM paketet tar hand om alla frågor som rör säkerhet, avtal, licenser och betalning. Arkitekturen baseras på XACML 8 och GeoXACML 9 auktorisationsmodell ([XACML]) och stereotyperna i figuren är hämtade från den. Figur 6. Geospatial Rights Management paketet baserat på XACML auktorisationsmodell Enligt modellen ingår följande stereotyper: PEP (Policy Enforcement Point): Komponenten tillhandahåller funktioner i enlighet med det beslut som görs av en PDP. I figuren kallar vi denna för Gatekeeper och huvuduppgiften är att kontrollera tillgången till OWS 10 tjänster och verkställa de regler och restriktioner som gäller. PIP (Policy Information Point): En komponent som tillhandahåller externa sammanhang och attribut till PDP. I figuren kallar vi den Autentisieringstjänst (WAS Web Authentication Service), huvuduppgif- 8 extensibel Access Control Markup Language 9 Ett tillägg till XACML för hantering av rumsligt data 10 OGC Web Services

13 ARKITEKTUR 13(25) ten är att ge den information som behövs om en viss användare för att utföra PDP beslutet. PDP (Policy Decision Point): En komponent som utvärderar en auktoriseringsförfrågan från t.ex. en PEP mot det regler och restriktioner som finns lagrade I en PAP. I figuren kallar vi den för Auktoriseringstjänst och huvuduppgiften är att ta beslut om åtkomst till en viss OWS. PAP (Policy Administration Point): En komponent som lagrar och underhåller åtkomstrestriktioner. I figuren kallas den för LicensManager och huvuduppgiften är att ansvara för licenser som omfattar det regler och restriktioner som gäller för en viss OWS. Licenserna används sedan som underlag för att godkänna och genomdriva beslut. Anledning/motivering till arkitekturval i denna del: De lösningar som vi kunnat hitta som hanterar säkring av tjänster använder sig av ovanstående standards. Valet av standards stämmer även väl överens med E-delegationens betänkande Strategi för myndigheternas arbete med e-förvaltning Externa tjänster Transformation Enklare former av koordinattransformationer som är generella och kan antas var efterfrågade av många kommer att tillhandahållas, däremot inte mer avancerade bearbetningstjänster. Nedladdning Här åsyftas en extern tjänst som skall kunna hantera beställningar och leverans av paketerat data i olika format men även nedladdning mha WFS. Tjänsten är under utredning men kommer i någon form att finnas tillgänglig i version 2.0. Övervakning Övervakningen av katalog, skördningsverktyg och GeoRM sker via Portalens driftorganisation men är en extern tjänst som vid behov kan bytas ut. Övervakning av nättjänster publicerade i Portalen förväntas ske hos respektive tjänsteleverantör, tjänstens status levereras till Portalen som ett RSS/GeoRSS flöde. WMS/WFS/WCS Dessa tjänster är externa tjänster som förväntas komma från olika tjänsteleverantörer. Geodata.se tillhandahåller en WFS som har till uppgift att serva säkerhetslösningen och kart- och kataloggränssnitt med avgränsningsområden.

14 ARKITEKTUR 14(25) CS-W Externa applikationer/system skall kunna söka i metadatakatalogen genom att anropa geodataportalens CSW-tjänst. 3.4 Logisk vy Här beskrivs systemets struktur, hur komponenterna relaterar till varandra och hur de samarbetar. I vissa delar tränger vi djupare ner i strukturen för att säkerställa förståelsen för systemets logik. Komponenternas uppdelning i arkitekturens olika lager presenteras inte i denna vy. Figur 8 nedan är en modell över den logiska strukturen i systemet. Strukturen är konstruerad på ett sätt så att varje del i systemet skall kunna bytas ut med en så liten påverkan som möjligt på systemet i övrigt. Geodata.se är benämningen på systemet och består av fem huvudkomponenter: CMS, Sök- och kartkomponent, GeoRM, Publiceringsmotorn och en Övervakare Sök- och kartkomponent Gränssnittet för den integrerade sök- och kartfunktionen är Javabaserat och bygger på följande externa öppna ramverk och API er: Mapfish Ext JS OpenLayers

15 ARKITEKTUR 15(25) Figur 7. Arkitektur för det integrerade sök- och kartgränssnittet Anledning/motivering till arkitekturval i denna del: Den kart- och sökkomponent som utvecklats inom ramen för V 1.0 bygger på redan tidigare utvecklade komponenter i denna arkitektur. Stora delar av komponenterna är tidigare utvecklade inom ramen för projekt med SKI, Banverket, SGU m fl. Komponenterna har vidareutvecklats av Planeringsportalen och tillhandahållits för vidare utveckling inom Geodataprojektet. Våra nordiska grannländer som vi samverkar med planerar för en nära nog identisk arkitektur. Den exempelportal som tagits fram av Inspire använder sig av i stort sett samma ramverk och API er (se figur ovan). Vi är medvetna om att arkitekturen till del skiljer sig från Lantmäteriets egna arkitekturval (JSF/Dojo/Spring webflow ) men ett byte av dessa delar skulle innebära ett betydande merarbete och möjligen även få konsekvenser för den funktionalitet vi önskar uppnå. Sök- och kartkomponenten består av tre delar (se figur nedan) som var och en har sin avgränsade uppgift. Den första klossen hanterar kommunikationen med den underliggande metadatakatalogen och har i

16 ARKITEKTUR 16(25) figuren fått namnet DbLogik. Här skall gränssnitt för CS-W 11 och CSW- T 12 implementeras. Den andra klossen skall hantera alla logiska operationer och benämns Affärslogik. Affärslogikkomponenten består av ett antal klasser som på ett strukturerat sätt samlar olika logiska operationer som hör samman. Vi har i figuren valt att inte specificera dessa klasser närmare därför att vi inte kan se att det påverkar arkitekturen. För att öka prestanda i kommunikationen med klienterna skall vi här implementera ett JSON 13 gränssitt. Här skall vi även implementera ett gränssnitt för nyhetsflöden via RSS/GeoRSS 14. Den sista klossen består av ett antal grafiska användargränssnitt som beskrivs lite mer utförligt nedan. Administrationsgränssnitt Vi behöver ett gränssnitt för att administrera systemet. Med det avser vi förutom att hantera användare och roller även hantering av den konfiguration som måste till för att kunna skörda metadata från andra metadatakataloger. Katalog Kataloggränssittet skall tillhandahålla möjlighet för användaren att söka efter och utvärdera metadata för resurser som är publicerade i metadatakatalogen. Karta Kartan skall tillhandahålla ett gränssnitt med en bakgrundskarta där användarna kan lägga till visningstjänster samt tjänster för direktåtkomst (ex. WFS) i utvärderings syfte. Gränssnittet skall innehålla de funktioner som förväntas finnas i en enkel kartvisare. Någon närmare beskrivning av gränssnittet görs inte här då det inte anses påverka arkitekturen. Hantering av dynamisk webbkartografi mha SLD 15 samt användningen av Web Map Context (WMC) i geodataportalen måste utredas vidare. 11 Catalog Service Web 12 Catalog Service Web - Transaction 13 JavaScript Object Notation 14 Really Simple Syndication (ibland även Rich Site Summary eller RDF Site Summary) 15 Styled Layer Description

17 ARKITEKTUR 17(25) Figur 8. Den logiska strukturen av Geodata.se Nedladdning Ett webbaserat nedladdningsgränssnitt som är nära knutet till kataloggränssnittet. Det är med andra ord enkelt att direkt från katalog gränssnittet komma åt nedladdningsfunktionerna. Nedladdningsgränssnittet kommunicerar endast mot externa tjänster. Från gränssnittet skall man kunna specificera område, format och leverans sätt. Förutom att ge möjlighet till nedladdning av enkla geografiska resurser direkt från kataloggränssnittet skall ett gränssnitt byggas för att hantera nedladdning av större datamängder. Metadata insamlingsgränssnitt Ett gränssnitt för insamling av metadata som uppfyller den svenska metadataprofilen. Gränssnittet skall vara webbaserat. Metadata publiceras från gränssnittet till katalogen via CSW-T.

18 ARKITEKTUR 18(25) Nyhetsflöden RSS/GeoRSS används för att erbjuda användare att prenumerera på nyheter från bland annat katalogen och övervakningsverktygen GeoRM Ett krav på systemet är att det måste det gå att begränsa möjligheten att använda publicerade resurser, vem som skall kunna nyttja resursen, vilka logiska operationer som får göras, begränsningar i geografiskt område, copyright mm. Tjänster som tar hand om dessa regler och restriktioner måste tas fram. För hanteringen av licens och avtalsfrågor måste tjänster byggas som ger möjlighet att skapa digitala licens- och prismodeller. När de tillämpas på någon tjänst skall de kunna presenteras on the fly för användarna direkt när hon försöker använda tjänsten. Licens- och avtalstjänsterna skall vara konstruerade på ett sådant sätt att flera licenser kan grupperas i paket. Användarna med en grupplicens kan därmed få tillgång till resurser från flera olika dataleverantörer med en och samma licens. Tjänster behöver också tas fram för att hantera betalning över Internet via kreditkort och faktura. Detta skall vara möjligt att göra i direkt anslutning till där användaren utvärderar och bestämmer sig för att köpa en viss tjänst (alltså inne i själva sök- och kartkomponenten) Publiceringsmotorn Tanken med Publiceringsmotorn är att tillhandahålla en möjlighet för externa redigeringsverktyg för metadata att publicera metadata till metadatakatalogen. Gränssnitt för CS-W och CSW-T kommer att implementeras i sök- och kartkomponenten. Användarna skulle kunna publicera in till portalen direkt via dessa gränssnitt men vi har då inte någon kontroll på det data som publiceras. Huvuduppgiften för publiceringsmotorn blir alltså att validera inkommande metadata i jämförelse med den svenska metadataprofilen. Motorn skall även se till att Redaktören och andra berörda meddelas om resultatet av publiceringen. 3.5 Dynamisk Vy Fallet Find-Bind Vi försöker här att beskriva flödet när en användare vill komma åt en viss geografisk resurs och använder systemet för att söka efter, utvärdera, använda och eventuellt köpa den (se figur). Användaren börjar med att logga in i portalen via en webbläsare. En förfrågan skickas till behörighetssystemet som kontrollerar användaren i förhållande till förfrågan (se Sekvensdiagram för behörighets-

19 ARKITEKTUR 19(25) hantering). Om användaren är behörig presenteras ett gränssnitt i Geodataportalen där hon får fylla i sina sökkriterier. Geodataportalen bygger en CS-W fråga i sin affärslogikkomponent utifrån kriterierna och skickar sedan denna till DbLogikkomponenten. CS-W frågan analyseras och görs om till SQL-frågor som hämtar ut data från metadatakatalogen. Svaret formateras till ett CS-W svar och skickas tillbaka till affärslogikkomponenten som levererar en resultatlista tillbaka till användaren. Användaren kan nu utvärderar metadata för resurserna som presenteras i listan. Beroende på resultatet av användarens utvärdering av listan samt vilka restriktioner som finns för den eventuella resursen kan ett antal scenarios inträffa. Senorio 1, användaren är inte nöjd med någon av resurserna och väljer att avbryta sökningen. Senario 2, användaren är inte nöjd med någon av resurserna och väljer att förändra sina sökkriterier och ställa en ny fråga mot katalogen. Senario 3 användaren hittar sin sökta resurs och har inget behov av ytterligare utvärdering. Avbryter. Senario 4, användaren vill ytterligare utvärdera en resurs genom att lägga till den i kartvisaren. Här kan ytterligare alternativa händelser uppstå. Senario 4a, användaren väljer att lägga till tjänsten i kartan. Ett anrop görs till GeoRM komponenten som kontrollerar vilka restriktioner som finns för den aktuella resursen. Komponenten avslår begäran och meddelar användare att behörighet saknas. Användaren återvänder till läget för utvärdering av resultatlistan från tidigare sökning.

20 ARKITEKTUR 20(25) Figur 9. Aktivitetsdiagram för fallet Find Bind Senario 4b, inleder som 4a med en kontroll i GeoRM komponenten. Användaren är behörig och tjänsten kräver inget avtal. Tjänsten läggs till i kartan med de restriktioner som gäller för tjänsten. Senario 4c, inleder som 4a med en kontroll i GeoRM komponenten. Användaren är behörig och tjänsten kräver avtal. GeoRM komponenten presenterar licensavtalet som gäller för tjänsten. Användaren godkänner inte avtalet. Användaren återvänder till läget för utvärdering av resultatlistan från tidigare sökning. Senario 4d, inleder som 4a med en kontroll i GeoRM komponenten. Användaren är behörig men tjänsten kräver avtal. GeoRM komponen-

21 ARKITEKTUR 21(25) ten presenterar licensavtalet som gäller för tjänsten. Användaren godkänner avtalet. Tjänsten kräver ingen betalning. Tjänsten läggs till i kartan med de restriktioner som gäller för avtalet. Senario 4e, inleder som 4a med en kontroll i GeoRM komponenten. Användaren är behörig men tjänsten kräver avtal. GeoRM komponenten presenterar licensavtalet som gäller för tjänsten. Användaren godkänner avtalet. Tjänsten kräver betalning. GeoRm komponenten presenterar sin betaltjänst. Användaren väljer att avbryta betalningen och återvänder till läget för utvärdering av resultatlistan från tidigare sökning. Senario 4f, inleder som 4a med en kontroll i GeoRM komponenten. Användaren är behörig men tjänsten kräver avtal. GeoRM komponenten presenterar licensavtalet som gäller för tjänsten. Användaren godkänner avtalet. Tjänsten kräver betalning. GeoRm komponenten presenterar sin betaltjänst. Användaren betalar för tjänsten. Tjänsten läggs till i kartan med de restriktioner som gäller för avtalet Behörighetshantering För att tydliggöra interaktionen mellan de ingående komponenterna i systemet vid en behörighetskontroll presenterar vi här ett typiskt scenario för behörighetshantering i XACML. Vi försöker även beskriva hur behörighetshanteringen går till i en federation av organisationer. Behörighetskontroll med XACML/GeoXACML En mänsklig eller maskinell användare vill vita någon åtgärd på en viss resurs. Den aktuella användaren skickar sin förfrågan till enheten som skyddar resursen (kallas Policy Enforcement Point - PEP). PEP formulerar i sin tur en fråga (använder sig av XACML s frågespråk) baserad på attribut från användaren, vilken åtgärd som avses, vilken resurs det gäller och annan relevant information. PEP skickar sedan denna fråga till en beslutstjänst (Policy Decision Point PDP), som analyserar förfrågan, hämtar de regler som gäller för resursen i detta fall (skrivna i XACML s regelspråk) och avgör om användaren skall tillåtas komma åt resursen enligt de restriktioner som är uppsatta för den aktuella användaren. Svaret skickas till PEP (uttryckt i XACML s svarsspråk) som då kan tillåta eller neka användaren åtkomst.

22 ARKITEKTUR 22(25) sd Sequence Access contol Människa/Maskin Geodataportalen PEP PDP Georesurs Lägg till georesurs i karta() Kontrollera förfrågan() Formulera XACML Fråga() Analysera förfrågan() Kontrollera behörighet() Meddela beslut() : XACML svarsspråk Hämta regler och restriktioner() :XACML regelspråk Meddela beslut() Lägg till i kartan() Figur 10. Behörighetskontroll med XACML Behörighetshantering i en federation Modellen innebär att en federation skapas mellan ett antal organisationer där man litar på varandras behörighetskontroll. Var och en av organisationerna kan ha egna system där användarna och rollerna lagras. När en användare har identifierats och godkänts av någon organisation i federationen så behövs ingen ytterligare identitetskontroll. Figuren nedan beskriver ett typiskt scenario. Figur 11. Sekvensfallsdiagram som beskriver flödet vid behörighetshantering i en federation av organisationer. 1. En användare försöker komma åt en skyddad resurs hos en Service Provider (SP).

23 ARKITEKTUR 23(25) 2. Användaren omdirigeras till WAYF för att välja sin ursprungliga organisation (IdP). 3. IdP ser till att användaren verifieras på något sätt som IdP finner lämpligt. 5. Efter lyckad autentisering genereras en identitetsbiljett för användaren som är giltig för den aktuella sessionen. 6. SP använder biljetten för att begära attribut information från IdP för användaren. 7. IdP tillåter eller nekar att attributinformation görs tillgänglig för aktuell SP. 8. Baserat på attributetinformationen tar SP beslut om godkännande, dvs. tillåter eller hindrar användaren tillgång till resursen. 4 Driftsättningsvy För driften av geodataportalen har vi två alternativ. Antingen driftsätter vi systemet i Lantmäteriets webbhotell, vilket är det mest önskvärda, eller så skapas en egen serverpark (den vi har idag). Alternativ två skall endast väljas om det medför allt för stora problem eller kostnader med att anpassa systemet till Lantmäteriets webbhotell. Konsekvens samt tidpunkt för eventuell driftsättning av det ena eller andra alternativet kommer att utredas vidare Driftsättningsalternativ webbhotell Om vi väljer att lägga driften av själva geodataportalen i Lantmäteriets webbhotell och driften av webbpubliceringssystemet (EPIServer) i en separat miljö, skulle det kunna se ut enligt figuren. Figur 12. Nätverk och servrar i Lantmäteriets webbhotell

24 ARKITEKTUR 24(25) Mest nytta av denna konfiguration får vi om det går att samköra driften av webbpubliceringssystemet med övriga delar i lantmäteriet som också bygger på samma plattform. Oracle databasen som systemet kräver placeras i Lantmäteriets Oracle cluster Driftsättningsalternativ egna servrar Bilden nedan visar en tänkbar konfiguration av systemet om vi väljer att gå på den linjen som vi har idag, dvs vi fortsätter att bygga en egen serverpark för de servrar som krävs för drift av Geodata.se Figur 13. Nätverk och servrar i egen serverpark

25 ARKITEKTUR 25(25) 5 Referenser INSPIRE direktivet EUROPAPARLAMENTETS OCH RÅDETS DIREKTIV 2007/2/EG av den 14 mars 2007 om upprättande av en infrastruktur för rumslig information i Europeiska gemenskapen (Inspire) pdf Geodatastrategien Nationell geodatastrategi _goedata/geodatastrategi2009/geodatastrategi_2009.pdf Kravspecifikationen Kravspecifikation för Geodataportalen V 2.0 E-delegationens betänkande Strategi för myndigheternas arbete med e-förvaltning, betänkande av E-delegationen df [XACML] OASIS Open (2003): extensible Access Control Markup Language (XACML) Version [GeoXACML] GeoXACML, a spatial extension to XACML, June 2005, OGC # [SAML] OASIS Open (2003): Assertions and Protocol for the OASIS Security Assertion Markup Language (SAML) V1.1 open.org/committees/download.php/3406/oasis-sstc-saml-core- 1.1.pdf