Ale kommun Arkitektdokument

Transkript

1 Ale kommun Arkitektdokument Version 1 Revison B

2 Versionshantering Obs Dokumentet bör revideras minst en gång per år. Datum Version Beskrivning Ändrat av JA B Uppdaterade skisser och rättning av fel (bildnummer) JA Innehåll 1. Inledning Avgränsningar Målgrupp 4 2. Dokumentstruktur Förkortningar 5 3. Referensmodell för IT-plattform Referensmodell (logisk) Referensmodell (fysisk) Referensmodell och nuläge Användargrupper Övergripande arkitektur identitets och behörighetshantering Nuvarande arkitektur Målbild Arkitektur för e-tjänster och integrationer Nuvarande arkitektur integrationer Målbild Beskrivning avhuvudkomponenter/områden BKS behörighetsåtkomst (Access Management) Content management (extranet) Katalogtjänster Nätverkskatalog Behörighetskatalog Identitetshantering 20

3 6.5 Skolportal Intranet E-tjänster Integrationsmotor/servicebuss (ESB) Användningsfall och Scenarion Användningsfall inloggning mot elevportal Scenario E-tjänst mot verksamhetssystem Scenario lös e-tjänst 25

4 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

5 2.1 Förkortningar Förkortning AD, Microsoft BIF BKS DSML EN 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) Bastjänster för informationsförsörjning Behörighetskontrollsystem, se även WAM Directory Service Markup Language, XML-baserat protokol för att hantera katalogrelaterad information Europeisk standard för elektronisk kommunikation av vårdinformation (patientdata) Enterprise Service Bus, komponent för att integrera olika system/applikationer som kommunicerar via webbtjänster Hälso- och sjukvårdsadressregister Identity Management Lightweight Directory Access Protocol, protokoll för att kommunicera med LDAP-kataloger LDAP Data Interchange Format, LDAP-baserat filformat för att hantera kataloginformation Komponent för att hantera och konsolidera identitets- och behörighetsinformation mellan olika system/applikationer Identitetsprodukt (metakatalog) från Microsoft Utvecklingsramverk från Microsoft Webbutvecklingsplattform från Microsoft Nationell Patient Översikt Public Key Infrastructure, standard för att hantera certifikat

6 SAML SITHS Sjunet SVPL Teis WAM XACML Security Assertion Markup Language, XML-baserat federationsprotokoll Certifikatslösning för säker IT Kommunikationslösning för vård och omsorgs Samordnad vårdplanering Integrationsmotor från Tieto Web Access Management, komponent för att hantera säker åtkomst mot webb-baserade tjänster extensible Access Control Markup Language, standard för att hantera behörighetsregler mellan organisationer

7 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.

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

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

10 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

11 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

12 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

13 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

14 4.2 Målbild Nedanstående bild 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

15 I bild (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.

16 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 visar delar av hu nuläget ser ut kring integrationer. Bild visar en framtidsbild hur systemen integreras via en gemensam servicebuss/integrationsmotor.

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

18 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 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.

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

20 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 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 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 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.

21 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

22 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

23 Flödesdiagram

24 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

25 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.

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