sou · H1B380 · 2013-12-05 00:00:00 — Figur 6 Exempel på webbsida i prototypen I prototypen finns ett antal sidor som inte varierar beroende på inloggning eller roll. Det är t.ex. startsidan, FAQ-sidor och kontaktinformation. I protypen är till största delen vara platshållare för att visa hur de kommer att fungera i slutgiltig lösning. Samtliga grafiska gränssnitt i lösningen har skapats med hjälp av Digiforms Designer, som är ett WYSIWYG-verktyg (What You See Is What You Get) som bygger på öppna standarder (XLS:FO, XML mfl.). I designverktyget skapades layout och kopplingen till XML-data på ett mycket effektivt sätt. Verktyget stöder en komponentbaserad modell, vilket reducerar både utvecklingskostnader och förvaltningskostnader. Alla formulär versionshanteras, och in- och utcheckning gör att flera utvecklare kan bidra till samma lösning. Formulär kan förhandsvisas innan de uppdateras i servern. Servern renderar effektivt formlären till neutral HTML för att stödja alla typer av webbläsare och ger stöd för mobila enheter. Formulären kan även generera PDF-filer för t.ex. kvittenser eller summeringar av information. Verktyget lämpar sig bra för iterativ utveckling och genom användning av CSS (stylesheets). För den grafiska designen kan prototypen enkelt tillgodogöra sig olika layout/formspråk. Inbyggt i verktygen finns även språkstöd om lösningen ska kunna hantera andra språk och minoritetsspråk Följande webbsidor har realiseras med hjälp av verktyget Digiforms Designer. Krav AF08, Fullgör aktuellt uppgiftskrav Krav AF11, Underhåll grunduppgifter Krav AF06, Anmäl uppgiftskrav KravAF07, Hantera uppgiftskrav Krav AF09, Ansök och anmäl Krav AF16, Avisera fullgjorda uppgiftskrav Myndighetens e-tjänst (körs på annan server) Färdiga sidor och formulär laddas upp till servern som betjänar anropande klienter. Prototypen har tagits fram genom att utgå ifrån användningsfall som kravställning på funktionaliteten. Användningsfallen har specificerats i uppgiftslämnarutredningens delredovisning (Dnr. 2013/4). Dessa krav tillsammans med beskrivna begränsningar och förtydliganden i uppdragsbeskrivningen, har legat till grund för att ta fram prototypen. Systemanvändningsfallen tillsammans med förtydliganden finns sammanställda i Bilaga 1. Krav AF01, Logga in med e-legitimation iipax har stöd för e-legitimationer enligt eId2008 och kommer att ha stöd för den nya infrastrukturen enligt e-legitimationsnämnden. Däremot valde projektgruppen att inte införa detta i prototypen eftersom det i testhänseende är mer komplicerat än en lösning som bygger på namn och pinkod (lösenord). För att underlätta åtkomst under förvaltnings- och testperioden beslöts i samråd med uppdragsgivaren att inte utföra en e-legitimationslösning i prototypen. Tekniskt sett så fångas oinloggade åtkomstförsök av ett servletfilter som styr om till en inloggningssida. Efter inloggning skapas en session för den aktuella användaren. Sessionen kommer att kopplas till rollregistret för att rätt behörighet ska kunna appliceras. Krav AF10, Ladda grunduppgifter iipax har gränssnitt för import/export av registerdata från filer i xml-format. Andra format som det nämnda tab-separerade formatet från SCB, hanteras genom en plugin som ett försteg som konverterar till xml. Krav AF13, Hämta grunduppgifter Överföringen sker i och med att en företagare klickar på en länk. I uppgiftskravsregistret ligger en länk till myndigheten finns. SHS används för både push och pull. I prototypen kör vi synkron SHS. Krav AF15, Avisera aktuella uppgiftskrav Överföringen av uppgifter från myndigheten till prototypen då ett nytt uppgiftskrav tillkommer. Kravet realiseras med asynkron SHS-kommunikation från myndigheten till prototypen. Samma SHS-noder som beskrivs för AF13 kommer att användas. Uppgiftskravet lagras som en xml-struktur i en fil som placeras på en given plats och sedan skickas med SHS till prototypen. Krav AF21, Gallra samordnade uppgifter Enkelt gränssnitt för gallring i registren för Samordnade uppgifter. Användaren kan göra en utsökning av objekt äldre än ett angivet datum plus eventuella ytterligare sökkriterier. Det är sedan möjligt att gallra de objekt som ingår i urvalet. 2.4Frågeställningar som har diskuterats under arbetet 2.4.1Lagring av uppgifter centralt eller lokalt Som beskrivet i uppgiftslämnarutredningens delredovisning (Dnr. 2013/4), finns det flera förhållningssätt till hur uppgifter ska hanteras. Ett sätt är att i systemet på SO (den centrala tjänsten) har registrerade uppgifter samlade i en central databas. Alternativt så kan man tänka sig att var och en av myndigheterna får ansvar för att samla ihop en delmängd av de gemensamma uppgifterna. De myndigheter ska då ansvara för dessa uppgifter för hela myndighetssfären. I det senare fallet får den centrala tjänsten en förmedlande roll. Uppgifterna ligger då distribuerade ute på myndigheterna. 2.4.2Hur ska uppgifter följa med användaren När en användare (företagsanvändare) i det centrala uppgiftslämnarsystemet ska fullgöra ett uppgiftskrav kommer tjänsten att vidarebefordra användaren till en e-tjänst på en myndighet för att lämna in uppgiften. I det fallet vill användaren få med sig sina uppgifter från den centrala tjänsten. Detta kan göras på ett antal olika sätt. Är det frågan om ett mindre antal uppgifter kan de lämnas över vid anropet av e- tjänsten på myndigheten. Detta kan göras som parametrar i url-en (adressen) till tjänsten. Detta är ett enkelt sätt att överföra data och det ställer inte heller krav på att e-tjänsten på myndigheten ska ha Single Sign On (SSO). När e-tjänsten ute på myndigheten, får ett anrop från den centrala tjänsten med en SAML biljett inkluderad får e-tjänsten reda på vem som vill lämna in uppgifter. E- tjänsten kan därefter hämta användaren och företagets uppgifter från den centrala tjänsten. Uppgifterna hämtas först efter att användaren har givit sitt medgivande eller att han/hon själv hämtar uppgifterna via en knapp på e-tjänsten på myndigheten. När e-tjänsten ute på myndigheten får ett anrop från den centrala tjänsten med en SAML biljett inkluderad, får e-tjänsten på myndigheten reda på vem som vill lämna in uppgifter. E-tjänsten kan därefter hämta användarens och företagets uppgifter från den centrala tjänsten automatiskt. Detta kräver dock att det är juridiskt möjligt att göra en automatisk uppgiftshämtning från den centrala tjänsten. Vilken teknik ska användas vid inloggning? I delredovisningen föreslås att e-legitimationer från federationen Svensk e-legitimation används när den infrastrukturen finns framme. För att kunna implementera dessa på ett kostnadseffektivt sätt behövs det köpas in produkter och tjänster för detta. Ska en lösning med SAML ticket användas behövs det i systemet finnas tillsammans med en validerings-tjänst/server, funktioner som Service Provider (SP) och Identity Provider (IdP). Figur 7: Principskiss Inloggning med e-legitimation 2.4.4Hur hanteras ett register för företagsföreträdare Det behöver upprättas ett register för de personer som ska ha tillgång till tjänsten från företagens sida. Frågan är om detta register ska vara knutet uppgiftslämnartjänsten eller om detta är ett register som hanteras av annan myndighet (t ex ). Projektet följde stort sett den projektplanen som var framtagen initialt. Följande aktiviteter har genomförts i kronologisk ordning. Tester och rättningar klara Det som återstår i projektet är en förvaltningsperiod som startar och som avslutas . Projektgruppen har bestått i av som mest 6 personer i form av projektledare, verksamhetsarkitekt, , systemutvecklare och testare. Från projektstart till och med projektavslut har har gjorts i projektet. Projektet var estimerat i avropssvaret till vilket gör att projektet i stort sett har följt den estimerade tiden. Det som återstår är förvaltning av prototypen fram till . För att bygga upp ett fullskaligt system för uppgiftslämning måste alla krav som finns beskrivna i delredovisningen uppfyllas. Systemet måste uppfylla de funktionella krav, prestandakrav och säkerhetskrav som ställs. Dessutom måste systemet vara felsäkert och uppfylla de driftkrav som ställts. Vilka funktioner behövs för att komplettera prototypen så att den uppfyller alla de krav som ställs på ett fullskaligt system? Vi har i denna slutrapport utgått ifrån de systemanvändningsfall som finns framtagna i delredovisningen (Dnr. 2013/4) för att uppskatta vad som ska utvecklas för att få fram de tillägg på systemet som måste finnas för att prototypen ska kunna växlas upp till ett fullskaligt system. Genom att titta på användningsfallen vart och ett kan man få ut en tidsuppskattning på arbetet som krävs för att implementera användningsfallet. De funktionella kraven som här tas fram är de som ingår i fas 1, fas 2 och fas 3 som beskrivet i Delredovisningen. 3.2.1Systemanvändningsfall som ingår i prototypen AF01 Logga in med e-legitimation Användningsfallet utförs då ett företag eller myndighet loggar in i systemet. Säkerhet hanteras för flera typer av roller, Enskild företagare, hos företag, Ombud för företag, Handläggare hos myndighet. Komplettering för fullskaligt system Förenklingar har gjorts i prototypen för detta krav. Lösningen ska hantera e-legitimationer och SAML-biljetter för att autentisering och inloggning ska kunna ske på ett tillfredställande sätt. kommer svensk e-legitimation att finnas på plats vilket självklart måste stödjas av det fullskaliga systemet. Användningsfallet utförs när handläggare hos en myndighet registrerar ett nytt uppgiftskrav i systemet. Komplettering för fullskaligt system Med vissa mindre modifieringar kan denna lösning tas med i ett fullskaligt system. Användningsfallet utförs när administrativ personal hos SO registrerar eller uppdaterar ett uppgiftskrav i systemet. Komplettering för fullskaligt system Med vissa modifieringar kan denna lösning tas med i ett fullskaligt system. AF08 Fullgör aktuellt uppgiftskrav Användningsfallet utförs när ett företag fullgör ett myndighetsinitierat uppgiftskrav via e- tjänsten Aktuella uppgiftskrav. Komplettering för fullskaligt system Hanteras med SHS i prototypen för att överföra data mellan SO och myndighet. Lösningen kan användas i ett fullskaligt system, här är det dock lite oklart hur detta ska gå till. Ska uppgifterna överföras i samband med överflytten av e-tjänsten eller ska myndigheten hämta uppgifter efter att användaren har kommit in i e-tjänsten. AF09 Ansök och anmäl Användningsfallet utförs när ett företag fullgör ett företagsinitierat uppgiftskrav via etjänsten Ansök och anmäl Komplettering för fullskaligt system Hanteras med SHS i prototypen. Lösningen kan användas i ett fullskaligt system där det är fråga om integration mot myndighetens verksamhetssystem. Användningsfallet utförs när SO laddar registret för samordnade uppgifter med företagsinformation från utvalda myndigheter. Komplettering för fullskaligt system Nuvarande lösning kan användas, men migreringsarbete kräver alltid mycket arbetet ofta beroende på dålig datakvalité. AF11 Underhåll grunduppgifter (e-tjänst) Användningsfallet utförs när ett företag uppdaterar sina uppgifter i registret samordnade uppgifter via e-tjänsten Underhåll grunduppgifter. Komplettering för fullskaligt system Med vissa mindre modifieringar kan denna lösning tas med i ett fullskaligt system. AF13 Hämta grunduppgifter (e-tjänst) Användningsfallet utförs när en myndighet hämtar ett företags uppgifter online via tjänsten Hämta grunduppgifter Komplettering för fullskaligt system Utförs med SHS , med modifiering kan denna lösning tas med i ett fullskaligt system. AF15 Avisera aktuella uppgiftskrav Användningsfallet utförs när en myndighet aviserar ett företags uppgiftskrav via tjänsten Avisera aktuella uppgiftskrav Komplettering för fullskaligt system Utförs med SHS , med modifiering kan denna lösning tas med i ett fullskaligt system. AF16 Avisera fullgjorda uppgiftskrav Användningsfallet utförs när en myndighet aviserar att ett företag fullgjort ett uppgiftskrav via tjänsten Avisera fullgjorda uppgiftskrav. Komplettering för fullskaligt system Utförs med SHS , med modifiering kan denna lösning tas med i ett fullskaligt system. AF21 Gallra samordnade uppgifter Användningsfallet utförs när en administratör på SO gallrar lagrade uppgifter ur registren. Komplettering för fullskaligt system Mer funktionalitet krävs i en fullskalig modell. Det ska bland annat gå att gallra flera företag i batch. AF02 Logga in internt Användningsfallet utförs när administrativ personal hos SO loggar in i systemet Handläggare eller Helpdesk. Nytt för fullskaligt system Kan göras med e-legitimation eller via lösenord. Lösenord är redan implementerat i prototypen men med fel säkerhetsnivå. Bland annat är lösenordet av administratören och är okrypterat. AF03 Autentisera pgm-pgm kommunikation Användningsfallet utförs när ett system hos en myndighet autentiseras i systemet Nytt för fullskaligt system Organisationscertifikat används i nuvarande prototyplösning, SHS är förberett för det. Användningsfallet utförs när handläggare hos en myndighet registrerar en ny uppgiftsdefinition i systemet Nytt för fullskaligt system Ny arbetsyta måste tas fram med tillhörande funktionalitet. Användningsfallet utförs när administrativ personal hos SO registrerar eller uppdaterar en uppgiftsdefinition i systemet. Nytt för fullskaligt system Möjlighet att lista uppgiftsdefinitoner och att göra förändringar på dessa. AF12 Underhåll grunduppgifter (fil) Användningsfallet utförs när ett företags uppgifter uppdateras i registret samordnade uppgifter via filgränssnittet Nytt för fullskaligt system Funktioner för filinlämning och hantering av uppgifter på fil. iipax hanterar själva filinlämningen. Pluginer för att hantera uppgifterna måste tas fram. AF14 Hämta grunduppgifter (fil) Användningsfallet utförs när en myndighet hämtar ett företags uppgifter online via filgränssnittet Nytt för fullskaligt system Funktioner för filinhämtning och hantering av uppgifter på fil. iipax har funktioner för att hämta filer. Pluginer för att hantera uppgifterna måste tas fram. Användningsfallet utförs när SO-handläggare registrerar eller uppdaterar användare och deras behörigheter i systemet. Behovet och utformningen av denna funktion kommer att vara en del av utredningen av auktoriseringen av användare. Nytt för fullskaligt system Lite oklart hur detta ska göras. Alla företag måste registreras och till dessa en eller flera användare på respektive företag. Ett befintligt register ska kunna användas. Denna typ av register finns på och men de är då framtagna för dessa myndigheters behov. Användningsfallet utförs när en administratör på SO schemalägger och hanterar batchkörningar i systemet. Nytt för fullskaligt system iipax innehåller funktioner för att schemalägga arbeten. En arbetsyta måste tas fram för att konfigurera schemaläggningen. AF19 Ta fram statistik Användningsfallet utförs när en administratör på SO tar ut statistik ur systemet. Nytt för fullskaligt system iipax analys finns som tilläggsprodukt. I produkten finns det möjlighet att skräddarsy rapporter som tar fram statistik på önskade uppgifter. AF20 Ta del av grunduppgifter Användningsfallet utförs när en PSI-intressent tar del av publicerade företagsuppgifter i systemet. Nytt för fullskaligt system Gränssnitt måste tas fram plus pluginer som hämtar data ur systemet. AF22 Producera grunduppgifter (fil) Användningsfallet utförs när systemet producerar en fil innehållande företagsuppgifter för vidare leverans till slutanvändare. Nytt för fullskaligt system Ny funktion för export av information till fil ska tas fram. Användningsfallet utförs när helpdesk på SO via ett gränssnitt mot systemet kan hjälpa en användare genom att guida dem genom ett problem. Nytt för fullskaligt system Ny arbetsysta måste tas fram för att kunna få uppgifter om ett visst företag och vilka uppgifter som ska lämnas in. Användaren (Service desk) på SO ska kunna gå in som en företagare och kontrollera status på företagarens sida. Ett fullskaligt system behöver vara uppbyggt på ett helt annat sätt än den prototyp som har tagits fram. föreslår därför att den blivande bygger infrastrukturen på ett sådant sätt att de kan hantera den trafikvolym som det har uppskatts i delredovisingen. Här är några exempel på åtgärder som bör vidtagas för att kunna uppfylla kraven: Inför en Klusterlösning för iipax communication för att öka prestanda och införa ett redundant system Använder sig av ett databaskluster för att öka prestanda och införa ett redundant system Ansluter minst 10 st webbservrar för att hantera alla inkommande inloggningar Bygger inlämningsregistret direkt i databasen och inte håller den som ett objekt i ett register. Nedanstående bild visar på hur en produktionsmässig driftmiljö kan bygga upp. Till detta tillkommer miljöer för test och utveckling. Figur 8 Skiss systemuppbyggnad Detta är en revision på de kostnadsberäkningar som har tagits fram i delredovisningen för utredningen. Vi har här fokuserat på systemutveckling och licenser för produkter som används för att ta fram lösningen. Övriga uppgifter bygger på de uppgifter som togs fram i delredovisningen. har med utgångspunkt på systemavändningsfallen tagit fram en tidsuppskattning på vad det skulle innebära att bygga ett system som uppfyller alla systemanvändningsfallen. I uppskattningen har tagits hänsyn till de övriga kraven vad det gäller prestanda och driftsäkerhet. uppskattar att systemutvecklingskostnaderna uppgår till . Det förutsätter att de produkter som specificeras kapitel 4.2 finns att tillgå för att bygga systemet på. Uppskattningen innefattar alla de delar som ingår i ett systemutvecklingsprojekt såsom projektledning, systemdesign, utveckling, tester, dokumentation, leveransarbete, installation och utbildning. Utöver detta tillkommer arbete med att integrera systemet med andra myndigheter. Det gäller då koordinering, men även arbetet med att integrera miljöerna (test och produktion) och att testa integrationen. Arbetet med den myndighetsövergripande integration har ofta en benägenhet att vara ett omfattande arbete med många parter inblandade (verksamhetspersoner, IT-projektledare, systemadministratörer, brandväggsexperter etc). I den lösningen som föreslås i delredovisningen ingår inga produkter för att bygga applikationen (e-tjänsten). Man utgår ifrån att alla funktionalitet ska byggas ifrån grunden. Det gör att kostnadsuppskattningen för mjukvara i delredovisningen hamnar lägre än i denna revidering (slutrapporten). I den här föreslagna lösningen ingår följande produkter: Digiforms Digiforms designer iipax receiver iipax communication DMZ proxy iipax communication iipax communication cluster iipax communication analyser Licenskostnaden för dessa produkter ligger på och med en årlig underhållskostnad på . Till detta kommer databasserver och applikationsserver. Detta hade dock Delredovisningen tagit hänsyn till i sin uppskattning. 4.3Säkerhetslösning – Autentisering (e-legitimation) Vad det gäller e-legitimationslösningen vill vi inte göra några förändringar från de siffror som togs fram i delredovisningen. I arbetet med prototypen har det inte framkommit några uppgifter som tyder på att den tidigare uträkningen inte stämmer. Inloggning via e-legitimation kräver produkter eller program som kan hantera funktionerna Service Provider och Identity Provider. Dessutom måste valideringen av certifikaten göras. Valideringen görs enklast via en molntjänst. Möjlighet finns dock att på särskild förfrågan från Utredningen, göra en ny prisuppskattning med priser från de leverantörer som använder sig av. 4.4Säkerhetslösning – Auktorisering (Behörigheter) Att implementera lösningen för auktorisering ingår inte i systemutvecklingen. Det finns dock ett behov av att utreda hur lösningen så kostnadseffektivt som möjligt kan sättas upp och implementeras i lösningen. Det finns även behov att utredas hur det register som behövs ska utformas. 4.5Spridnings och hämtningssystemet – SHS I kostnadskalkylen i delredovisningen togs SHS upp om en transaktionsbaserad kostnad. I detta lösningsförslag har vi använt oss av produkten iipax communcation. iipax communication innehåller de SHS funktioner som krävs för det fullskaliga systemet. Det innebär att det inte tillkommer någon kostnad av betydelse i denna post. Kostnaden för licens och underhåll har redan tagits i beräkningen för infrastruktur. Den enda utgift här är ett servercertifikat för att identifiera i SHS- nätverket. Priset för ett servercertifikat ligger på runt . De utredningar som förslås är relevanta. Genom att använda den i detta dokument föreslagna lösningen kan man svara på ett par frågor som här tas upp. Bland annat är prismodellen för SHS känd och vilka gränssnitt man stödjer i den föreslagan lösningen. För att åskådligöra kostnadsberäkningarna har vi gjort en sammaställning på dessa, på samma sätt som gjordes i delredovisningen (Bilagan till delredovisning sidan 26-27). 1 IT‐chef och 1 systemansvarig Integration (SHS) Summa Integration och e‐ Personal (5 IT‐drift) Vår uppskattning är att kostnaden för applikationsutveckling kan avsevärt reduceras genom att använda sig av en plattform, där grundfunktionalitet för systemlösningen redan finns framtagen. Visserligen kommer det till kostnader för licenser och en årlig kostnad för underhåll på produkterna. Men om man räknar på hela lösningen kommer den totala kostnaden att vara lägre både för investeringen och för den årliga driften. I och med att arbetet med applikationsutvecklingen inte blir så omfattande i det fall man använder sig av standardprodukter, kan posten Informationssystem underhåll revideras ned. I det reviderade förslaget är den kodmassan som behöver underhållas mindre, vilket ger en lägre underhållskostnad på den egenutvecklade koden. Detta beroende på att underhållet är proportionellt med den kodmassa som ska underhållas. I den reviderade kostnadsanalysen uppskattar vi att det behövs fler webbservrar än det som redovisas i den kostnadsuppskattning som togs fram i delredovisningen. För att kunna hantera samtidiga inloggade användare behövs ca 10 st webbservrar i produktionsmiljön. För att få med dessa kostnader har posten höjts med . Juridisk analys av användningsfall AF01: Användaren loggar in i servicetjänsten, E-legitimationer är alltid personliga. Om loggning av autentiseringar sker hos Om en autentiseringslogg förs måste den Att autentisera en e-legitimation bör inte vara autentiserad som fysisk person med hjälp av autentisera torde vara personuppgifts- bör de som alla Inte heller detta är en behandling där den autentiserande parten loggar betraktas som diarier (jfr RÅ 1999 lagstiftningens krav på att personuppgifter inte unik frågeställning för utredningen är personuppgiftsansvarig och behand- ref. 18 II), därmed allmän handling ska behandlas (förvaras) när de inte längre lingen är tillåten med stöd av samtycke (register som förs fortlöpande). eller 10 § e-f PuL. I den mån loggning av inte en unik frågeställning för utredningen, autentiseringar sker av Företagsdata- samma fråga gäller alla myndigheter som myndigheten ska de inte behandlas autentiserar e-legitimationer och loggar (förvaras) längre än nödvändigt, vilket i praktiken lär bli . AF02: Myndighetsanställd, antingen på Företags- datamyndigheten eller på insamlande myndigheter, loggar in internt i servicetjänsten, i syfte att administrera uppgiftskraven. Autentisering kan här ske på annat sätt än med e-legitimation, men om inloggnings- uppgifterna är anknutna till en fysisk person är det fråga om personuppgifts- behandling. Det är dock tänkbart att endast rollbaserade inloggningsuppgifter används, och i sådana fall sker ingen personuppgiftsbehandling i detta steg. Autentiserande part (rimligen Företags- datamyndigheten) är personuppgifts- ansvarig, och tillåtligheten följer av sam- tycke/anställningsavtal eller 10 § b eller e. Vad gäller loggning gäller samma som för AF01.