Ale kommun Arkitektdokument

Ale kommun Arkitektdokument 2013-02-25 Version 1 Revison B

Versionshantering Obs Dokumentet bör revideras minst en gång per år. Datum Version Beskrivning Ändrat av 2012-09-03 1 JA 2013-02-25 1B Uppdaterade skisser och rättning av fel (bildnummer) JA Innehåll 1. Inledning 4 1.1 Avgränsningar 4 1.2 Målgrupp 4 2. Dokumentstruktur 4 2.1 Förkortningar 5 3. Referensmodell för IT-plattform 7 3.1 Referensmodell (logisk) 8 3.2 Referensmodell (fysisk) 9 3.3 Referensmodell och nuläge 10 3.4 Användargrupper 11 4. Övergripande arkitektur identitets och behörighetshantering 13 4.1 Nuvarande arkitektur 13 4.2 Målbild 14 5. Arkitektur för e-tjänster och integrationer 16 5.1 Nuvarande arkitektur integrationer 16 5.2 Målbild 18 6. Beskrivning avhuvudkomponenter/områden 20 6.1 BKS behörighetsåtkomst (Access Management) 20 6.2 Content management (extranet) 20 6.3 Katalogtjänster 20 6.3.1 Nätverkskatalog 20 6.3.2 Behörighetskatalog 20 6.4 Identitetshantering 20

6.5 Skolportal 20 6.6 Intranet 21 6.7 E-tjänster 21 6.8 Integrationsmotor/servicebuss (ESB) 21 7. Användningsfall och Scenarion 21 7.1 Användningsfall inloggning mot elevportal 21 7.2 Scenario E-tjänst mot verksamhetssystem 24 7.3 Scenario lös e-tjänst 25

1. Inledning Detta dokument beskriver arkitekturen för Ale kommuns grundläggande ITkomponenter. Syftet med dokumentet är att kunna visa vilka komponenter och produkter som finns samt hur de fungerar tillsammans. Primärt har fokus lagts på områden för att kunna hantera e-tjänster och behörighetshantering. Som utgångspunkt har en referensmodell använts för att kunna relatera befintliga produkter som används idag inom kommunen. Referensmodellen relaterar även till framtida komponenter som är under införande. 1.1 Avgränsningar Dokumentet syftar inte till att ge en detaljerad beskrivning av hur olika system är konfigurerade. Dokumentet beskriver endast olika produkter och komponenter utifrån ett övergripande perspektiv. 1.2 Målgrupp Dokumentet beskriver inte arkitektur för olika verksamhetsystem/områden inom kommunen. IT-arkitekter IT-samordnare IT-konsulter Konsulter 2. Dokumentstruktur Arkitektdokument Riktlinjer Processbeskrivning

2.1 Förkortningar Förkortning AD, Microsoft BIF BKS DSML EN 13606 ESB HSA IDM LDAP LDIF Metakatalog Microsoft FIM Microsoft NET Microsoft SharePoint NPÖ PKI Betydelse/Referens Windows baserad Katalogtjänst för att hantera användare och grupper (säkerhet och inloggning) http://en.wikipedia.org/wiki/active_directory Bastjänster för informationsförsörjning http://www.svrinfo.se/projekt-tjanster/bif/ Behörighetskontrollsystem, se även WAM Directory Service Markup Language, XML-baserat protokol för att hantera katalogrelaterad information http://en.wikipedia.org/wiki/directory_service_markup_language Europeisk standard för elektronisk kommunikation av vårdinformation (patientdata) http://en.wikipedia.org/wiki/en_13606 Enterprise Service Bus, komponent för att integrera olika system/applikationer som kommunicerar via webbtjänster http://en.wikipedia.org/wiki/enterprise_service_bus Hälso- och sjukvårdsadressregister http://www.svrinfo.se/projekt-tjanster/hsa/ Identity Management http://en.wikipedia.org/wiki/identity_management Lightweight Directory Access Protocol, protokoll för att kommunicera med LDAP-kataloger http://en.wikipedia.org/wiki/ldap LDAP Data Interchange Format, LDAP-baserat filformat för att hantera kataloginformation http://en.wikipedia.org/wiki/ldif Komponent för att hantera och konsolidera identitets- och behörighetsinformation mellan olika system/applikationer http://en.wikipedia.org/wiki/metadirectory Identitetsprodukt (metakatalog) från Microsoft http://en.wikipedia.org/wiki/forefront_identity_manager Utvecklingsramverk från Microsoft http://sv.wikipedia.org/wiki/dotnet_framework Webbutvecklingsplattform från Microsoft http://en.wikipedia.org/wiki/microsoft_sharepoint Nationell Patient Översikt http://www.svrinfo.se/projekt-tjanster/npo/ Public Key Infrastructure, standard för att hantera certifikat

SAML SITHS Sjunet SVPL Teis WAM XACML http://en.wikipedia.org/wiki/public_key_infrastructure Security Assertion Markup Language, XML-baserat federationsprotokoll http://en.wikipedia.org/wiki/saml Certifikatslösning för säker IT http://www.svrinfo.se/projekt-tjanster/siths/ Kommunikationslösning för vård och omsorgs http://www.svrinfo.se/projekt-tjanster/sjunet/ Samordnad vårdplanering Integrationsmotor från Tieto http://www.teis.se/ Web Access Management, komponent för att hantera säker åtkomst mot webb-baserade tjänster http://en.wikipedia.org/wiki/web_access_management extensible Access Control Markup Language, standard för att hantera behörighetsregler mellan organisationer http://en.wikipedia.org/wiki/xacml

3. Referensmodell för IT-plattform Referensmodellen utgår från en generell IT-plattform och har delats upp i tre olika områden, applikationslager, mellanprogramvara och data/informationslager. Syftet är att kunna se hur kommunens befintliga komponenter (produkter, programvara) mappar in mot referensmodellen, men även få möjligheten att se hur framtida lösningar relaterar mot modellen. Punkterna 3.1 och 3.2 är generella och är inte specifika för Ale kommun. Observera att referensmodellen endast har som syfte att relatera befintliga produkter till de som Ale har idag och de produkter som man planerar att införa. Syftet är inte att Ale kommun ska införskaffa alla de komponenter som finns omnämnda i referensmodellen.

3.1 Referensmodell (logisk) Visar en logisk bild över olika områden i referensmodellen. Bild 3-1-1: Referensmodell (logisk)

3.2 Referensmodell (fysisk) Visar en fysisk bild hur olika komponenter kan samverka. Bild 3-2-1: Referensmodell (fysisk)

3.3 Referensmodell och nuläge Bilden nedan beskriver ett antal produkter som finns idag inom Ale kommun och hur dessa förhåller sig till Referensmodellen. Bild 3-3-1: Referensmodell (logisk) komponent mappning

3.4 Användargrupper Mot referensmodellen finns ett antal användargrupper är identifierade och beskrivs nedan. Användarna kan ses som aktörer som ska kunna relateras mot kommunens IT-arkitektur. Bild 3-4-1: Identitetsrelation

Definition av aktörer Anställda Personer som innehar en tillsvidareanställning eller vistidsanställning. Elever Personer som är aktiva inom Ale kommuns utbildningsväsen Konsulter/inhyrd personal Personer som utför arbete åt Ale kommun och behöver komma åt kommunen IT-system men har sin anställning hos en annan arbetsgivare Politiker Personer med politiskt uppdrag inom Ale kommun Vårdnadshavare Person som har en relation med ett barn bosatt inom Ale kommun eller verksamt inom Ale kommuns utbildningsväsen Medborgare Person bosatt inom eller utom Ale kommun som vill kunna använda medborgarrelaterade tjänster Andra myndigheter Anställda tillhörande en annan myndighet som vill kunna använda Ale kommuns IT-tjänster Näringsidkare Person anställd i ett företag eller egenföretagare som vill kunna använda Ale kommuns IT-tjänster

4. Övergripande arkitektur identitets och behörighetshantering Denna punkt beskriver arkitekturen kring identitets och behörighetshantering. 4.1 Nuvarande arkitektur Nedanstående bild visar den nuvarande arkitekturen för identitetshantering med relation till portal och behörighetshantering. Bild 4-1-2: Nuvarande identitetslösning

4.2 Målbild Nedanstående bild 4-2-1 visar målbildsarkitekturen arkitekturen för identitetshantering med relation till portal och behörighetshantering. Bild 4-2-1: Översikt av framtida arkitektur för infrastruktur

I bild 4-2-1 (ovan) beskrivs en framtida lösning för att hantera identitetshantering som är baserad Microsoft FIM. En framtida ESBlösning bör även spela en viktig roll för att hantera olika typer av integrationer. Idag används främst Tietos Decapus för att hantera integrationer.

5. Arkitektur för e-tjänster och integrationer 5.1 Nuvarande arkitektur integrationer Idag är det merparten av integrationerna så kallade punkt till punkt integrationer mellan specifika system. En del integrationer hanteras via integrationsmotorn Decapus från Teito. Primärt är det synkrona/batchbaserade filöverföningar som hanteras av Decapus. Utöver Decapus finns även ESB-lösnigen Mule implementerad, Mule hanterar personuppgifter mellan ett lokalt personregister (qid) och Skatteverkets Navet. Bild 5-1-1 visar delar av hu nuläget ser ut kring integrationer. Bild 5-2-1 visar en framtidsbild hur systemen integreras via en gemensam servicebuss/integrationsmotor.

Bild 5-1-1: punkt till punkt integration (nuläge)

Bild 5-1-2: integrationer via servicebuss/integrationsmotor Endast större verksamhetssystem bör integreras mot en servicebuss då det varje integration är relativt kostsam. 5.2 Målbild Bild 5-2-1 beskrivs hur e-tjänster hanteras i en framtida arkitektur. Vissa verksamhetssystem har stöd för att hantera e-tjänster mot t.ex. medborgare. Systemen kommer med inbyggt stöd för att hantera E-tjänster vilket medför relativt begränsad arbetsinsatts för Ale kommun. I andra fall finns det inget verksamhetssystem med stöd för de e-tjänster som kommunen vill tillhandahålla. I de fallen kommer de krävas en större insatts för kommunen att kunna bygga en e-tjänst. Ale kommuns primära strategi är att de verksamhetssystem som finns och som köps in, ska tillhandhålla stöd för e-tjänster i den mån det är möjligt.

Bild 5-2-1: Översikt av framtida arkitektur för e-tjänster

6. Beskrivning avhuvudkomponenter/områden 6.1 BKS behörighetsåtkomst (Access Management) Extern behörighetshantering/åtkomst avser användare som ansluter utifrån Ale kommuns nätverk t.ex. via internet för att kunna nå interna resurser (IT-system). Behörighetslösningen har till uppgift att skydda interna resurser från intrång obehöriga användare mm. Behörighetslösningen ska kunna hantera inloggning/autentisering för anställda, elever, medborgare, näringsidkare, entreprenörer mm. Behörighetslösningen ska även kunna hantera federation med andra parter t.ex. via SAML v2. Behörighetslösningen är baserad på MobilityGuard. 6.2 Content management (extranet) Ale använder SiteVision för att hantera den externa webbsidan www.ale.se. 6.3 Katalogtjänster Inom Ale kommun finns det primärt två katalogtjänster. En katalog för att hantera interna användare som anställda och elever, samt en extern katalog för att hantera användare som ansluter från externt nät som Internet samt medborgare för att hantera åtkomst mot olika typer av E-tjänster. 6.3.1 Nätverkskatalog Nätverkskatalogen bygger idag på Microsoft Active Directory och används främst för att hantera behörigheter i klient och serverplattform. Primärt hanteras åtkomst till fil och applikationstilldelning för anställda och elever. 6.3.2 Behörighetskatalog Behörighetskatalogen baseras förnärvarande på Novell edirectory och hanterar primärt externa användare som vårdnadshavare mm. På sikt ska behörighetskatalogen avvecklas för att integreras i en gemensam katalog som även används för klientplattform och servrar (Microsoft Active Directory). 6.4 Identitetshantering Idag finns det två separata identitetslösningar en för skolan och för administrativa delen av Ale kommun. Båda lösningarna baseras på Novell Identity Manager. Under hösten 2012 kommer Ale kommun att påbörja ett kravarbete för att införa en ny gemensam identitetslösning både för skola och adm baserad på Microsoft FIM. 6.5 Skolportal Ale kommun kommer under 2012 att lansera en ny skolportal baserad på Microsoft Share Point.

6.6 Intranet Ale kommuns intranät baseras på Lotus Notes. Notes är under avveckling och en framtida intranätslösning är under utredning 6.7 E-tjänster Den övergripande strategin är att respektive verksamhetssystem/område ska ansvara för att tillhandahålla e-tjänster. D.v.s. E- tjänsterna ska kunna hanteras direkt i de verksamhetssystem som finns inom organisationen. E-tjänsterna publiceras i den gemensamma webbmiljön för externa användare. Vissa delar bör hanteras via gemensamma komponenter som inloggning med e- legitimation mm. I de fall där det inte finns något underliggande verksamhetssystem för en e-tjänst, bör e-tjänsten utvecklas i kommunens portal/webbmiljö. 6.8 Integrationsmotor/servicebuss (ESB) Ale kommun har idag inte någon generell integrationsmotor eller service buss för att hantera integrationer mellan olika system. Idag finns en del specifika lösningar för olika ändamål t.ex. används Mule ESB för att kunna kontrollera personuppgifter mot Navet. Även Tietos Decapus används för att hantera asynkrona integrationer som primärt baseras på filöverföringar mellan system. Ale avser att utvärdera möjligheterna att införa en gemensam/generell integrationsmotor/esb. 7. Användningsfall och Scenarion Denna punkt beskriver användningsfall och scenarion som beskriver hur olika komponenter i arkitekturen används. 7.1 Användningsfall inloggning mot elevportal Användningsfall Beskrivning Inloggning mot elevportal för Medborgare (Vårdnadshavare) Detta användningsfall beskriver hur en användare (aktör) loggar in mot elevportalen. Användningsfallet startar i samband med att användaren loggar in. Villkor (preconditions) Användaren har ett E-leg

Användaren finns registrerad som vårdandshavare i personregister för elev inom Ale Primär aktör(er) Vårdnadshavare Elev Sekundär aktör(er) Huvudflöde BKS (Behörighetskontroll) Skolportal Användarkatalog 1. Vårdnadshavare loggar in med E-legitimation i elevportalen 2. BKS verifierar E-legitimationen 3. BKS skapar ett användarkonto i användarkatalogen baserat på uppgifterna i E- legitimationen (personnummer, för- och efternamn) 4. Skolportalen verifierar mot personregistret vilken relation som finns mellan elev och vårdandshavare 5. Vårdandshavaren loggas in och presenteras med behörig information (klassrum IUP etc.) Sekundärt flöde Kommentar

Flödesdiagram

7.2 Scenario E-tjänst mot verksamhetssystem I detta scenario beskrivs hur en e-tjänst i ett verksamhetssystem kan hanteras. Verksamhetssystemet har inbyggd funktionalitet för hantering av e-tjänster. I detta fall exemplifieras en e-tjänst mot det digitala e-arkivet som har stöd för att hantera externa användare som medborgare. För att få åtkomst mot publikt arkivmaterial krävs ingen inloggning (verifiering). I de fall där användaren vill få tillgång till icke publikt arkivmaterial krävs en inloggning/användarverifikation t.ex. via behörighetssystemet (BKS). Bild 7-2-1: E-tjänst mot verksamhetssystem

7.3 Scenario lös e-tjänst Detta scenario beskriver hur lösa e-tjänster kan hanteras. Med lös e-tjänst menas att det inte finns något underliggande verksamhetssystem. E-tjänsten måste utvecklas specifikt för Ale kommuns ändamål. Detta ställer naturligtvis större krav på kommunens underliggande arkitektur. I detta scenario exemplifieras ansökan om grävningstillstånd som e-tjänst. E-tjänsten byggs i kommunens webbplattform. I scenariot beskrivs även hur en integration mot en underliggande servicebuss kan fungera för att kunna hämta information/verksamhetsdata som är nödvändig för e-tjänsten.

Bild 7-3-1: Lös e-tjänst