|

1.  Introduktion

Dokumentet beskriver Säkerhetstjänsternas arkitektur och plattform på en översiktlig nivå och bör för att få en fördjupad förståelse läsas tillsammans med de dokument som återfinns under kapitel 1.4 Referenser. 
SAD:ens målgrupp är utvecklare och systemförvaltare av Säkerhetstjänsterna, integratörer hänvisas istället till dokumentation för anpassning mot Säkerhetstjänsterna.

1.1. Syfte

Denna SAD (Software Architecture Document) avser att beskriva systemets arkitekturellt signifikanta delar i form av Användningsfallsvy, Logisk vy, Installationsvy samt Implementationsvy. 
Syftet med Säkerhetstjänsterna är att på ett enhetligt sätt säkerställa den funktionella informationssäkerheten avseende IT-tjänsters hantering av vårdinformation inom hälso- och sjukvården, såväl inom som mellan organisationer.

1.2. Omfattning

Denna SAD innehåller beskrivningar av generella och gemensamma byggblock som ingår i flera IT-bastjänster samt vissa specifika aspekter från vissa IT-bastjänster som anses som arkitekturellt signifikanta. 
SAD:en innehåller även implementationsdetaljer som är av intresse för utvecklare och Systemförvaltare.

1.3. Revisionsinformation 

1.4. Begrepps/förkortningslista

1.5. Referenser

För att få en djupare förståelse rörande de specifika IT-bastjänsterna och detaljer i systemets uppbyggnad bör förutom denna övergripande SAD även följande referenser studeras.

1.5.1. Dokument

1.5.2. Webb

2. Arkitektuella mål

2.1. Säkerhet

Säkerhetskonceptet i Säkerhetstjänsterna innebär att varje IT-bastjänst som mottar ett meddelande ska verifiera såväl meddelandets riktighet och ursprung som att anroparen har rättighet att genomföra den operationen i systemet. Oavsett om en operation genomförs eller nekas ska loggning av att meddelandet har inkommit ske.

2.2. Tjänstebaserad arkitektur

Basen för de IT-bastjänster som Säkerhetstjänsterna tillhandahåller är en Tjänstebaserad arkitektur (Service Oriented Architecture, SOA).
Principen för SOA är att tydligt urskiljbara delar med bestämda uppgifter och standardiserade gränssnitt grupperas till tjänster. Dessa tjänster kan därefter kombineras, genom att skicka meddelanden till dem, för att bygga upp den funktionalitet som systemet i sin helhet ska tillhandahålla. 

Figur 1 Beståndsdelar SOA

2.2.1. Konfigurerbarhet och utrymme för anpassningar

En löst bunden SOA-arkitektur ger stor frihet hur tjänster införs och nyttjas. För att uppnå lösa bindningar bygger Säkerhetstjänsterna på en flexibel lättviktsarkitektur med komponentbaserad modell.

2.3. IT-bastjänster i Säkerhetstjänsterna

Grundfunktionaliteten i Säkerhetstjänsterna indelas i sex IT-bastjänster (De översta rutorna i figuren nedan). 

Figur 2 IT-bastjänster inom Säkerhetstjänsterna 

Figur 3 Beroenden mellan IT-bastjänsterna

2.3.1. Autentisering

Autentiseringstjänsten har i uppgift att vid inloggning fastställa aktörens identitet samt sammanställa och intyga dennes egenskaper i en e-underskriven biljett (SAML assertion), som sedan kan användas som underlag för rättighetsstyrning i övriga IT-bastjänster. En aktör kan vara en fysisk person eller IT-tjänst som behöver åtkomst till andra IT-tjänster.

2.3.2. Loggrapport

Syftet med bastjänsten är söka ut, bearbeta och presentera logginformation för att möjliggöra uppföljning. Uppföljningen speglar regelverket och innehåller följaktligen samma information.

2.3.3. Loggning

Syftet med bastjänsten är att samla logginformation för att möjliggöra uppföljning.

2.3.4. Samtycke

Syftet med bastjänsten är att kunna avgöra om samtycke existerar samt registrera, lagra och återkalla samtyckesintyg. Även nödöppning hanteras av Samtyckestjänsten genom att registrera samtycke av typen nödöppning. Om verksamhetsreglerna är uppsatta så att samtyckeskontroller ska ske så kommer Åtkomstkontrolltjänsten att genomföra samtyckeskontroller via anrop till Samtyckestjänsten. För mer detaljerad information se SAD - Tjänster för Samtycke och Patientrelation enligt PDL [Ref-6].

2.3.5. Spärr

Stödtjänsten Spärr syftar till att stödja registrering och hantering av patientens önskan att spärra sina uppgifter i vårdens system enligt Patientdatalagen och Socialstyrelsens föreskrifter (SOSFS 2008:14 med handbok).
Tjänsten medger att spärren registreras och sedan tillgängliggörs för alla de vårdsystem som behöver utföra kontroll mot spärr. Spärren applicerar på informationshanteringen både inom det inre sekretessområdet (inom vårdgivarens verksamhet) och vid sammanhållen journalföring.
Om verksamhetsreglerna är uppsatta så att spärrkontroller ska ske så kommer Åtkomstkontrolltjänsten att genomföra spärrkontroller via anrop till Spärrtjänsten. För mer detaljerad information se SAD - Spärrtjänst [Ref-7].

2.3.6. Patientrelation

Syftet med bastjänsten är att administrera respektive intyga att hälso- och sjukvårdspersonal har vårdrelation till patient. Registrering av patientrelation utförs i Säkerhetstjänsterna eller via anrop från externt system. Om verksamhetsreglerna är uppsatta så att patientrelationskontroller ska ske så kommer Åtkomstkontrolltjänsten att genomföra patientrelationskontroller via anrop till Patientrelationstjänsten. För mer detaljerad information se SAD - Tjänster för Samtycke och Patientrelation enligt PDL [Ref-6].

2.4. RIV TA 2.1 anpassade tjänster

Följande tjänster publiceras med en policy som kräver dubbelriktad SSL och att WS-adressering nyttjas men som inte har några ytterligare begränsningar i policyn.
De tjänster som nyttjar denna policy är:

• Spärrtjänsten
• Samtyckestjänsten
• Patientrelationstjänsten
• Loggtjänsten
• Loggrapporttjänsten

Tjänsterna kan installeras och driftas som enskilda tjänster eller flera tjänster tillsammans. Samma grundplattform nyttjas oavsett om det gäller de ursprungliga säkerhetstjänsterna eller de nya RIV TA 2.1 anpassade. 

Figur 4 Gemensam plattform för nya och ursprungliga tjänster

2.4.1. RIV TA tjänst - anrop

För att anropa RIV TA tjänster krävs säker transport, i Säkerhetstjänsternas fall dubbelriktad SSL. 

Figur 5 Anrop till RIV TA 2.1 anpassad tjänst

2.4.2. Ursprunglig tjänst - anrop

För att anropa de ursprungliga ännu ej RIV TA anpassade tjänsterna krävs dubbelriktad SSL, SAML intyg och att vissa attribut signeras av avsändaren. 

Figur 6 Anrop till ursprunglig tjänst

2.5. Samverkan mellan IT-bastjänsterna

IT-bastjänsterna i Säkerhetstjänsterna samverkar i en tjänsteorienterad arkitektur (SOA) för att stödja informationssäker elektronisk hantering av vårdinformation. IT-tjänsterna har var för sig unik funktionalitet, men det erfordras full samverkan Säkerhetsbastjänsterna emellan för att informationssäkerhet skall uppnås avseende:

• Tillgänglighet
• Åtkomlighet för behöriga
• Skydd för obehörig insyn
• Riktighet/oförvanskad
• Spårbarhet och oavvislighet

2.6. Tillgänglighet

Säkerhetstjänsterna är designat för kontinuerlig drift vilket ställer krav på att de ingående komponenterna var för sig har hög tillgänglighet samt att konfigurering av systemet kan ske medan systemet är i drift.

2.7. Prestanda

Många av Säkerhetstjänsternas tjänster är tänkta att användas direkt och indirekt från andra system och klienter, där kraven på god prestanda är höga. Därför ska dessa IT-bastjänster och användargränssnitt ha så bra prestanda som möjligt, begränsat endast av de förutsättningar avseende säkerhet, uppföljning etc. som ges.
Vissa IT-bastjänster och användargränssnitt är endast tänkta att användas sporadiskt för att exempelvis konfigurera tjänsterna, och deras prestanda bör vara så pass bra att de inte blir ett irritationsmoment.

2.8. Driftsättningsalternativ

Bastjänsterna kan driftsättas både som nationella och/eller lokala instanser beroende på huvudmännens önskemål, detta kan även skilja från tjänst till tjänst. Serverdel av Säkerhetstjänsterna driftsätts på en Linux plattform eller Windows (enbart lokala instanser).

2.9. Open Source

De tredjepartsprodukter som används internt i Säkerhetstjänsterna är merparten Open Source produkter.

2.10. Bastjänstkonsumenter

3. Logisk vy

3.1. Arkitekturell översikt

3.1.1. Komponenter

3.1.1.1. Separat namnrymd för varje komponent

• Två komponenter har var sitt beroende till samma tredjepartsbibliotek men av olika versioner.
• Två komponenter har var sitt beroende till samma tredjeparts-API men med olika realiserande tredjepartsbibliotek.

I båda dessa fall finns möjligheten att det fungerar utan att man behöver göra någon åtgärd, men då får man leva med att använda sig av en konfiguration som inte har officiellt stöd. Ofta är det dessvärre så att det inte fungerar av sig självt och att det krävs krångliga vägar runt problemet om det ens går. Denna problematik försvinner i och med nyttjande av komponenter där klasser exekveras i komponentens namnrymd och där varje komponenten kan kapsla in och nyttja de specifika versioner av tredjepartsbibliotek den har beroenden till.

3.1.1.2. Versionshantering

Genom att kombinera namnet på en komponent med ett versionsnummer uppstår möjligheten att olika versioner av samma komponent kan arbeta sida vid sida utan att någon risk finns att de sammanblandas. På så sätt kan vi se till att en komponent kan vidareutvecklas med ett förändrat kontrakt utan att dess klienter är tvungna att uppgraderas. Det medger också möjligheten att man vid lansering av en ny version av komponenten har möjlighet att köra både den nya såväl som den gamla versionen av komponenten samtidigt för att säkerställa dess kompatibilitet såväl som funktion.

3.1.1.3. Plattformskomponenter

Förutom komponenter av verksamhetskaraktär finns det generella infrastruktur- eller plattformskomponenter. De tillhandahåller tjänster som webbtjänstegränssnitt, köhantering, resurspooler, transaktionshantering, webbservrar och så vidare. Genom att ha dessa som lösa komponenter i stället för som bastjänster i plattformen åstadkoms bättre flexibilitet och tydligare beroenden, och därmed även lägre komplexitet. Det ger också en lättviktsstack av tjänster som ger bättre möjlighet till kontroll, utbytbarhet såväl som ett system med bättre total prestanda.

3.1.1.4. Komponentbehållare

Komponenterna behöver en miljö att exekvera i, och detta gör de i en behållare (Eng: container). Behållaren är dynamisk vilket gör det möjligt att lägga till, ta bort, starta och stoppa komponenter under drift. Den ansvarar dessutom för att organisera komponenternas beroenden på varandra och tillåter dynamisk omkonfiguration av dessa.
Dynamisk omkonfiguration kan användas för att förändra beteende under drift utan driftavbrott. Ett exempel är att byta ut en komponent som representerar någon form av policy mot en komponent med en annan implementation. Det kan även användas vid driftsättning av en ny version som ersätter en tidigare. Den kan då driftsättas parallellt med den gamla för att verifiera att allt är som det ska innan man tar bort den gamla versionen. När det är gjort ersätts den gamla versionen i ett svep utan att klienter behöver märka något.

3.1.2. Generella komponenter

En komponent kan göras generell på flera sätt. Ett sätt är att den implementeras på ett sådant sätt att man genom driftsparametrar kan styra vad den ska göra. Detta förutsätter att man vid implementationstillfället har kännedom om vilken logik som kan behöva utföras, och förbereder för den. Ett annat sätt är att definiera utökningspunkter där man i stället kan plugga in programkod vid behov, och på detta sätt uppnå ännu större flexibilitet. 
I Säkerhetstjänsterna är IT-bastjänsterna uppbyggda av komponenter som erbjuder båda dessa möjligheter. Utökningspunkterna gestaltas av tjänstereferenser (i vissa fall ej obligatoriska) med väldefinierade gränssnitt. En enda tjänstereferens kan även vid behov referera till flera tjänsteinstanser. Genom att i många fall använda tjänstereferenser i stället för driftsparametrar ges stor flexibilitet, och i de fall man endast vill sätta ett enkelt värde så finns fördefinierade tjänsteinstanser som returnerar konstantvärden.

 
Figur 17 Schematisk bild av en komponent

3.1.3. Flexibel plattform

När en komponent installeras i plattformen (OSGi-behållaren) så garanteras att dess inre uppbyggnad är isolerad från omvärlden. Det finns ingenting som hindrar flera versioner av samma komponent eller olika realiseringar av samma tjänstegränssnitt att vara aktiva samtidigt. Detta är viktigt då det tillåter driftsättning av nya versioner samtidigt som äldre klienter kan kommunicera med en tidigare version av komponenten.
Vid driftsättning där den befintliga versionen ska tas ur bruk är det även praktiskt då det tillåter att den nya versionen startas parallellt med den gamla. Det går då att installera och testa den nya versionen i produktionsmiljön och när man har verifierat att den har allt den behöver för att fungera så kan man styra om de inkommande anropen. Detta går att utföra helt utan driftsavbrott. 
Plattformen sköter även om komponenternas beroenden till varandra och det finns där två huvudsakliga sätt som de kan skötas på: deklarativt och manuellt. 
Ett deklarativt beroende innebär att en komponent deklarerar att den behöver en viss sorts tjänst (och ifall det är tillämpligt, av en viss version). Detta kan t ex vara beroendet till loggtjänsten. Plattformen ser då till att ansluta tjänsteinstansen till tjänstereferensen när den finns tillgänglig. Om beroendet är obligatoriskt startas och stoppas tjänsten beroende på ifall det finns en tillgänglig instans som realiserar det obligatoriska beroendet. 
Ett manuellt beroende är (precis som det låter) konfigurerat manuellt. Detta används då det för önskat beteende krävs att tjänstereferensen refererar en specifik tjänsteinstans. 
Genom att koppla ihop flera komponenters publicerade tjänster, tjänstereferenser och egenskaper skapas en så kallas komposit som kan ses som en enhet, en komponent i sig. Då de olika IT-bastjänsterna i Säkerhetstjänsterna består av ett antal sammankopplade komponenter så kan även dessa ses som kompositer och således behandlas som enheter. 

Figur 18 Komposit uppbyggd av flera komponenter

3.1.4. OSGi

OSGi är en komponentmodell med stöd för att hantera olika versioner/implementationer av samma komponent samtidigt samt att dynamiskt kunna byta ut komponenter under drift. 
.  
Figur 19 OSGi Framework

3.1.4.1. OSGi ramverket

Huvudkomponenten i OSGi specifikationen är OSGi ramverket. Ramverket tillhandahåller en standardiserad miljö för applikationer (bundlar) och består av fyra lager.

3.1.4.2. OSGi applikationer - bundlar

En applikation i OSGi plattformen kallas för en bundle och kan beskrivas som ett vanlig Java ARchive (JAR) med ett utökat Manifest. Manifestet i en bundle specificerar vad den exporterar och vilka beroenden den har för att kunna exekvera i OSGi miljön. 
En OSGi bundel innehåller vanliga Java klasser (POJO) som inte behöver vara beroende av OGSi API:t eller känna till att de exekveras som en OSGi bundle.

3.1.4.3. Manifestfiler

För att konfigurera vad de olika bundlarna exporterar och importerar används manifestfiler.

3.1.4.4. Spring och OSGi

Dynamisk beroendeinjektion (Dependency Injection, DI) mellan bundlar uppnås med hjälp av Spring Dynamic Modules for OSGi(tm) Service Platforms [Web 2]. Spring DI kan användas för beroenden som inte behöver modifieras i runtime.

3.1.4.5. Specifika versioner av bundlar

Som konfigurationsinformation till ramverket kan även versionsinformation anges, t.ex. kan man specificera att en bundle behöver en http server av version 1.1 eller senare, denna information är nödvändig att kunna ange om man vill kunna köra med flera olika versioner parallellt.

3.1.5. Equinox

Equinox är en implementation av OSGi R4 core framework specification [Web 3], en uppsättning bundlar som implementerar infrastrukturen för att köra OSGi baserade system samt en uppsättning icke obligatoriska OSGi tjänster. 
Equinox är den OSGi implementation som används av Eclipse men kan även köras som OSGi plattform oberoende av Eclipse. 

 
Figur 20 Equinox

3.2. Webbtjänster

Webbtjänster erbjuder metoder för informationssystem att samverka, utbyta information och använda varandras funktionalitet på ett enhetligt, standardiserat och säkert sätt. I grunden finns XML, med ett antal påbyggnader i form av formella standarder som SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) m fl. Det bäddar för ett bättre utnyttjande av befintliga system och öppnar samtidigt vägen för helt nya affärsmodeller där tjänsteutvecklare erbjuder nischkomponenter, åtkomliga via Internet och integrerbara med andra tjänster så att hela virtuella system kan byggas genom att koppla samman olika webbtjänster.

3.2.1. Metro

Metro [Web 7] är den webbtjänstestack som används inom Säkerhetstjänsterna. Den inkluderar bl.a. JAX-WS, WSIT, JAXB och implementation för många av de WS-* standarder som nyttjas av Säkerhetstjänsterna. 

Figur 32 Metro webbtjänstestack

3.2.1.1. Java API for Web Services (JAX-WS)

JAX-WS är grundstommen för utveckling av SOAP baserade webbtjänster. JAX-WS ersätter JAX-RPC från och med Java 1.5.

3.2.1.2. Web Services Interoperability Technologies (WSIT)

WSIT [Web 6] är en komponent som utökar JAX-WS med implementationer av mekanismer för att kommunicera med andra webbtjänstestackar på ett interoperabelt sätt, i synnerhet då Windows Communication Foundation (WCF). 
WSIT innehåller stöd för meddelande optimering, säker meddelande transport, säkerhet osv. Det finns även stöd för bootstrapping och konfiguration. 
WSIT ramverket bygger på JAX-WS och JAXB. Bilden nedan visar vilka underliggande tjänster som är implementerade för varje område. 


Figur 33 WSIT Web Service Features

3.2.1.3. Java Architecture for XML Binding (JAXB)

JAXB [Web 4] binder XML schemat till Java klasser vilket gör det enkelt att hantera XML data. 

Figur 34 JAXB - Bindning av schema till klasser 

Figur 35 Komponenter i en JAXB implementation

3.2.2. Java Architecture for XML Processing (JAXP)

JAXP [Web 5] erbjuder stöd för att tolka SAX/DOM data, transformera XML data enligt XSLT, validera XML mot XML schemat samt ställa frågor via XPath mot XML data.

3.3. Standarder som berör webbtjänstutvecklingen

3.3.1. SOAP

SOAP 1.2 [Web 25] beskriver kuvert för meddelanden/felmeddelanden som används i Säkerhetstjänsterna.

3.3.2. WS-Addressing

WS-Addressing 1.0 [Web 23] används för att specificera vilken tjänst som efterfrågas och för att kommunicera information som behövs för att göra anrop till en specifik tjänst. Det innefattar naturligtvis dess adress men även andra saker, t ex metadata som beskriver dess gränssnitt.

3.3.3. WS-Policy

WS-Policy 1.2 [Web 8] är ett ramverk för att på ett generellt sätt beskriva vilka krav en webbtjänst ställer på en webbtjänstanvändare samt dess möjligheter. 
WS-PolicyAttachments 1.2 definierar flera metoder för att associera WS-Policy uttryck till Webbtjänster (WSDL).

3.3.4. WS-SecurityPolicy

WS-SecurityPolicy 1.2 [Web 24] ger en vokabulär för att uttrycka krav och garantier på säkerhet och integritet för en webbtjänst.

3.3.4.1. Säkerhetstjänsterna Policies

Här beskrivs de policies som ska användas av tjänster som vill nyttja Säkerhetstjänsterna (och som även nyttjas internt inom Säkerhetstjänsterna) som säkerhetslösning. 
Säkerhetstjänsterna tillhandahåller inte någon webbadress där dessa policies publiceras, nyttjare av en policy kan antingen själva publicera dessa eller helt enkelt klippa in dessa i WSDL:erna.

3.3.4.1.1. MutualSSLPolicy

Policy för att upprätta en dubbelriktad SSL förbindelse.

3.3.4.1.2. SecurityPolicy

Säkerhetspolicy vilken föreskriver att SAML intyg ska skickas med och att vissa attribut ska signeras om de förekommer.

3.3.4.1.3. Schema för AuthenticationChain

AuthenticationChain består av en lista av SAML intyg och används för att förmedla anropskedjan mellan olika servrar.

3.3.5. WS-Security (WSS)

WS-Security 1.0 [Web 9] beskriver hur signatur- och krypteringsfält läggs till i SOAP meddelanden. Den beskriver även hur binära värden såsom X.509 certifikat och sessionsnycklar biljetter läggs till i meddelandet.
WS-Security garanterar end-till-end punkt säkerhet på applikationsnivå.

3.3.6. SAML

Security Assertion Markup Language (SAML) 2.0 är en XML standard för hur utbyte av autentisering och åtkomstkontroll kan ske mellan olika säkerhetsdomäner, d.v.s. mellan intygsutfärdare och intygskonsumenter. SAML ingår idag som underliggande teknik i flera lösningar för Single Sign On i webbläsarmiljöer.

Figur 36 Exempel på en enkel SAML XML 
SAML-intyget innehåller subjektsegenskaper tillsammans med påståendet att någon som kan uppvisa ägandeskap av en viss nyckel är den som SAML-intyget gäller ("holder-of-key"). På så sätt kan en konsument säkert knyta subjektsegenskaperna till en specifik aktör som signerar sitt anrop med sin privata nyckel. 
SAML-standarden indelas på en övergripande nivå i fyra beståndsdelar: Profiler, Bindings, Protokoll och Påstående. 

Figur 37 SAML standardens huvudbeståndsdelar 
Ofta används SOAP som bärare av den information som specificeras i SAML-standarden. 

Figur 38 SAML via SOAP

3.3.7. XML Signature Syntax and Processing (XMLDSig)

När man använder XML för att skicka data kan det ibland vara viktigt att signera hela eller delar av det data som skickas, hur denna signering och validering av densamma ska genomföras beskrivs i en standard – XML Signature Syntax and Processing (Även kallad XMLDSig) [Web 21]. 
Inom Säkerhetstjänsterna används signaturer för att garantera integritet och oavvislighet, dels vid meddelandekommunikation och dels för verksamhetsdata som sparas. 
På en grundläggande konceptuell nivå består en XML signatur av fyra delar

• Referenser till det som signeras
• Signaturen
• (Ej obligatorisk) Nyckel eller ett sätt att identifiera den nyckel som kan användas för att verifiera signaturen
• (Ej obligatorisk) En del som kan innehålla diverse information som inte ingår i de andra tre delarna

Figur 39 Syntax för en XML-signatur 
I XML-Signature standarden omnämns tre grundtyper av signeringstransformeringar (Detached, Enveloping och Enveloped Signature). 

Figur 40 Olika typer av XML-signaturtransformeringar 
Detached Signature – I detta fall gäller signaturen något som ligger utanför själva signaturelementet och kan t.ex. refereras till via en URI i elementet – signaturen är frikopplad från det data den signerat men det signerade datat kan fortfarande ligga inom samma XML dokument.

Figur 41 Exempel på Detached Signature inom samma XML-dokument

Figur 42 Exempel på Detached Signature med signeringsdatat utanför XML-dokumentet 
Enveloping Signature – Signaturen gäller data inom det signaturelement som även innehåller signaturen, refereras via en URI eller en transform.

Figur 43 Exempel på Enveloping Signature 
Enveloped Signature – Signaturen gäller i detta fall data som innehåller signaturelement som underliggande data. OBS - Här är det viktigt att signaturelementet inte tas med vid generering och validering av signatur.

Figur 44 Exempel på Enveloped Signature

3.3.8. TLS (SSL)

TLS 1.0, som är efterföljaren till SSL 3.0, används för att garantera konfidentialitet, integritet och oavvislighet för webbapplikationer.

3.3.8.1. CIPHER

Följande ciphers kan nyttjas vid anslutning till säkerhetstjänsterna

3.4. Paketstruktur och subsystemindelning

3.4.1. IT-bastjänsternas paketstruktur

Alla IT-bastjänster i Säkerhetstjänsterna följer samma mall för paketstruktur även om alla IT-bastjänster inte innehåller alla paket och vissa innehåller paket som inte finns med i den generella strukturen. 

Figur 45 Paket inom IT-tjänst

3.4.1.1. Webbgränssnitt

För de IT-bastjänster som ska tillhandahålla ett webbgränssnitt läggs webbgränssnittet i ett eget paket som innehåller de JSP sidor som genererar webbsidorna samt de underliggande Java klasser som matar webbsidorna med data och styr flödet.

3.4.1.2. Tjänstegränssnitt

IT-bastjänstens gränssnitt (oberoende av hur den senare eventuellt distribueras), implementeras av både proxy för tjänstegränssnitt över webbtjänst och tjänsteimplementationen.

3.4.1.3. Proxy för tjänstegränssnitt över webbtjänst

Implementation av tjänstegränssnittet som en proxy som nyttjar webbtjänster för att kommunicera med serversidan.

3.4.1.4. Webbtjänstegränssnitt

Alla IT-bastjänster som har ett externt gränssnitt exponeras som en eller flera webbtjänster. Webbtjänsternas gränssnitt beskrivs med WSDL och XSD då gränssnittet ska vara plattforms- och implementationsoberoende och gå att anropa från alla miljöer som har stöd för att nyttja webbtjänster. 
Alla webbtjänstegränssnitt som skapas exponeras via funktionalitet inom fasadkomponenten. Fasadkomponenten sköter om gemensamma operationer på ett uniformt sätt såsom Single Sign On (SSO), säkerhet och loggning. 
Vid ett anrop till en webbtjänst som publicerats via Fasadkomponenten säkerställs meddelandets konfidentialitet, integritet och att eventuellt SAML intyg är giltig och går att knyta till avsändaren. Den information om avsändaren som går att uttyda (t.ex. klientcertifikat och IP-adress) och lagras temporärt kontexten för anropet medan SAML intyget (som kan återanvändas om giltighetstiden inte har gått ut) lagras som ett transient gemensamt objekt, se 4.8.4 Delade gemensamma objekt. 
Webbtjänstens gränssnitt, implementeras av webbtjänsteimplementationen.

3.4.1.5. Webbtjänsteimplementation

Implementation av webbtjänsten, nyttjar internt tjänstegränssnittet för verksamhetsrelaterade funktioner.

3.4.1.6. Tjänsteimplementation

Implementationen av den verksamhet som tjänsten ska stödja.

3.4.1.7. Enhetstest

Enhetstester finns per tjänsteimplementation.

3.4.1.8. Persistensgränssnitt

Innehåller metoder för persistens samt interface för entiteterna

3.4.1.9. Persistensimplementation

Implementerar persistering av de entiteter som finns i persistensgränssnittet.

3.4.2. Plattformens paketstruktur

Plattformen består av ett antal mer eller mindre fristående bundlar som delas in i tredjeparts bundlar, egenutvecklade generella bundlar samt egenutvecklade Säkerhetstjänste-specifika bundlar. Paketstrukturmässigt förändras inte paketstrukturen för tredjeparts bundlarna och de egenutvecklade får paketnamn utifrån om de är generella eller Säkerhetstjänste-specifika.

3.5.  Säkerhet

Vilken typ av autentisering som krävs för respektive webbtjänsteanrop styrs genom att ange vilken policy som skall användas för respektive webbtjänst. Vanligast för Säkerhetstjänsternas IT-bastjänster är en policy som säger att SAML-intyg skall användas, meddelanden ska skickas via en krypterad transportkanal och valda delar av payloaden ska vara signerad.

3.5.1. X.509

X.509 är en ITU-T standard som stödjs av WS-security som bland annat innehåller standardiserat format för certifikat enligt nedan:

• Certificate
  • Version
  • Serial Number
  • Algorithm ID
  • Issuer
  • Validity
    • Not Before
    • Not After
  • Subject
  • Subject Public Key Info
    • Public Key Algorithm
    • Subject Public Key
  • Issuer Unique Identifier (Optional)
  • Subject Unique Identifier (Optional)
  • Extensions (Optional)
    • KeyUsage
      • digitalSignature (0) - används för autentisering
      • nonRepudiation (1) - används för signering
      • keyEncipherment (2) - används för nyckeltransport
      • ...
    • ...
• Certificate Signature Algorithm
• Certificate Signature

För ytterligare detaljer rörande innehåll i X.509 certifikat, se RFC3280 - Internet X.509 Public Key Infrastructure Certificate [Web 20]

3.5.1.1. Förlitande

Förutom att genom signering kunna se att något är underskrivet måste Säkerhetstjänsterna även kunna avgöra om den som skrivit under är någon vi litar på. För att verifiera ett förlitande måste förlitandekedjan följas tills vi hittar en förlitanderot (certifikatsutgivare) Säkerhetstjänsterna litar på. 
För ytterligare detaljer rörande metoder för att verifiera certifikatkedjor, se RFC3280 - Internet X.509 Public Key Infrastructure Certificate [Web 20]

3.5.1.2. Giltighet

Även om någon presenterar ett certifikat utfärdat av någon Säkerhetstjänsterna litar på så kan det specifika certifikatet vara utgånget eller revokerat, därför måste kontroller genomföras. 
OCSP (Online Certificate Status Protocol) är en IETF-Standard för att kunna verifiera giltighet för digitala X.509 certifikat. OSCP har tagits fram som ett alternativ till CRL p.g.a. vissa specifika problem att inkorporera CRL i PKI lösningar. OSCP meddelande följer ASN.1 formatet. 
CRL (Certificate Revocation Lists) är en äldre men fortfarande vida spridd metod för att definiera att utfärdade certifikat inte längre är giltiga och därmed heller inte kan litas på.

3.5.2. Signering

Signering av SAML-intyg, verksamhetsdata och webbtjänsteanrop sker med hjälp av XMLDSig, se 4.5.8. På transportnivå används i webbapplikationsfallen även TLS, där integritet och oavvislighet garanteras med hjälp av binära signaturer, se 4.5.9.

3.5.3. Kryptering

Figur 46 Lager i en anropskedja där kryptering/dekryptering kan ske, i Säkerhetstjänsterna förekommer kryptering på transportnivån 

3.5.3.1. PKCS

PKCS (Public-Key Cryptography Standards) är en standard framtagen av RSA Laboratories och är som namnet säger en standard för kryptografi som bygger på öppna nycklar. 
PKCS#11 - Denna del av standarden specificerar ett API (kallat Cryptoki - cryptographic token interface) mot komponenter som håller kryptografisk information eller utför kryptografiska funktioner. 
Implementationen av PKSC#11 kan ske i både mjuk och hårdvara, genom att följa denna standard inom Säkerhetstjänsterna blir det möjligt att skala upp krypteringsstödet efter behov. 
Genom att i Säkerhetstjänsterna nyttja det API som specificeras i standarden kan t.ex. privata nycklar komma från ett mjuka certifikat, smart kort eller ett kryptokort helt transparent för den överliggande koden.

3.5.3.2. JCA/JCE

JCA (Java Cryptography Architecture) / JCE (Java Cryptography Extensions) definierar tillsammans ett API för kryptografi. JCA tillhandahåller ett grundramverk och JCE kompletterar JCA 
JCA/JCE används i Säkerhetstjänsterna för nyckelhantering, certifikathantering signering, kryptering, verifiering och liknande.

3.5.3.2.1. Java(TM) Cryptography Extension (JCE) Unlimited Strength

För att stödja kryptering med nycklar större än 128 bitar används Java(TM) Cryptography Extension (JCE) Unlimited Strength tillägget för Java på de maskiner som kör Säkerhetstjänsterna.

3.5.4. Intern säkerhet inom Säkerhetstjänsterna

Vid kommunikation mellan IT-bastjänster inom Säkerhetstjänsterna används samma mekanismer och policy som tillhandahålls för externa integratörer.

3.5.4.1. Hierarkiskdistribution

Regeldistribution mellan åtkomstkontrolltjänster sker enligt en hierarki där underliggande noder prenumererar på regelförändringar från ovanliggande nod. 

Figur 47 Regler för åtkomstkontrollen kan distribueras nedåt i en hierarki

3.5.4.2. Klustring

Den datareplikering som sker inom serverparken (via Infinispan) omfattas inte av någon specifik säkerhetsmekanism. Den skyddas genom begränsning på annan nivå, t ex ett skyddat nätverk eller liknande skalskydd.

3.6. Arkitekturella mekanismer

3.6.1. Versionsnumrering

3.6.1.1. Komponentversioner

För att veta om en ny version av en komponent är kompatibel med en tidigare version eller inte består en bundels versionsnummer av tre siffror som räknas upp enligt:

• 1:a siffran räknas upp om en icke bakåtkompatibel uppdatering har skett
• 2:a siffran räknas upp om komponentens gränssnitt har utökats utan att befintligt gränssnitt påverkas
• 3:e siffran räknas upp vid implementationsuppdateringar som inte påverkar gränssnittet

Figur 48 Versionsnumrering av komponenter

3.6.1.2. Övergripande Säkerhetstjänster Version

Den övergripande versionsnumreringen av Säkerhetstjänsterna har ingen koppling till de ingående komponenternas versionsnummer. 

Figur 49 Fiktivt exempel på Säkerhetstjänsternas Version med ingående komponentversioner

3.6.1.3. WSDL- och XSD-versioner

Versionsnumreringen på WSDL- och XSD-filer görs med bara två siffror då alla förändringar av en WSDL eller XSD rör gränssnittet .

• 1:a siffran räknas upp om en icke bakåtkompatibel uppdatering har skett
• 2:a siffran räknas upp up komponentens gränssnitt har utökats utan att befintligt gränssnitt påverkas

Det target namespace som används innehåller båda versionsnumren (t.ex. urn:carelink:bif:loganalysis-ws:1.0). 
WSDL-filer namnges med första versionssiffran i filnamnet t.ex. bif-context-ws-1.wsdl och den första wsdl-filen innehåller också bara första versionssiffran, t.ex. bif-context-ws-1.xsd. Vid en bakåtkompatibel ändring uppdateras innehållet i wsdl-filen men eventuella nya typer hamnar i en ny xsd-fil med första och andra versionssiffran i filnamnet, t.ex. bif-context-ws-1.1-xsd. 
Nya metoder i WSDL:en samt eventuella nya datatyper i den nya xsd:n läggs i ett namespace som innehåller både första och andra versionsiffran i sitt namespace, t.ex. urn:carelink:bif:context:1.1. 
Vid publicering av webbtjänster skall dessa, för att undvika krockar, publiceras på en context path som innehåller versionsnumret t.ex. <host>/services/BIFContextService/1.1. Detta gör att externa aktörer kan styras in mot olika URL:er och därmed olika versioner. 
Publiceringar och namnsättningar som inte innehåller versionsinformation enligt ovan ses som 1.0-versioner. 
För att omdirigera gamla klientapplikationer till nya bakåtkompatibla versioner av olika webbtjänster kan en omdirigering i lastbalanseraren ske t.ex. alla anrop till /service/BIFContextService omdirigeras till /sevice/BIFContextService/1.1 i lastbalanseraren för att därefter kunna stänga ner den gamla webbtjänsteimplementationen.

3.6.2. Persistens

De IT-bastjänster som behöver lagra och hämta data persistent innehåller två extra bundlar, en som definierar gränssnittet (med verksamhetsmässiga metoder) för persistensen och en bundel som innehåller implementationen av IT-bastjänstens persistens (CRUD metoder). Persistensgränssnittet använder databärande entiteter som parametrar i de metoder där det är lämpligt (i praktiken åtminstone Create, Retrieve och Update). Anledningen till att entiteter används som parametrar är att det då blir enklare att hantera om det tillkommer eller försvinner kolumner i databastabellerna, det blir då ingen förändring i repository interfacet utan bara en implementationsmässig förändring att hantera att entitetens utseende har förändrats. 
För att inte få en hård knytning till en specifik databas tilldelas en DataSource till implementationsbundeln via dependency injection. Implementationer av olika 
DataSource kommer att finnas i plattformen, t.ex. för mySql och SqlServer. 
För att via konfigurationen kunna välja en specifik DataSource får varje XADataSource en property vid namn sql.dialect (T.ex. med värdet MySql), denna kan sedan anges i ett filter när DataSource referensen konfigureras. 

Figur 50 Persistens 
Persistensen i IT-bastjänsterna är relativt okomplicerad så för tillfället nyttjas ren SQL och JDBC men om behovet skulle uppstå så skulle något ORM ramverk kunna nyttjas istället. 
I version 1.6 ingår persistensimplementation för:

• MySql

3.6.2.1. Inga lagrade procedurer

För att underlätta införande av persistenskomponenter för andra databashanterare och för att minska risken att funktionalitet som bara finns att tillgå i vissa databashanterare används inga lagrade procedurer i Säkerhetstjänsterna.

3.6.2.2. Konfiguration databaser

Konfigureringen av databaserna sker med hjälp av ManagedService gränssnittet enligt OSGi kompendiet [Web 1] via det generella konfigurationsgränssnittet.

3.6.2.3. UUID som databasnycklar

Som primärnycklar (och därmed också som främmande nycklar) i databastabellerna används UUID. Detta underlättar bland annat om man vid något tillfälle vill slå samman data från två instanser av samma databas utan att riskera att nycklarna krockar. UUID-referens: http://en.wikipedia.org/wiki/Universally_unique_identifier

3.6.2.4. Script för att generera upp databas

Varje repository.impl projekt innehåller script för att skapa upp sina egna tabeller i de olika databastyper som stöds av Säkerhetstjänsterna. Där det är möjligt skall bara databastyper som stöds av samtliga databaser användas i dessa skript, på så sätt minimerar vi risken att det krävs olika implementationer av repository-bundlarna för de olika databashanterarna.

3.6.2.5. Namngivningskonventioner databas

Nedan följer några riktlinjer vad det gäller namngivning av tabeller, kolumner o.s.v. i databasen. Bara gemener används och underscore _ kan användas för att separera termer.

På grund av begränsningar i de olika databashanterare (främst Oracle v9i som sätter begränsningarna http://www.mssqlcity.com/Articles/Compare/oracle_vs_db2.htm) som på sikt ska stödjas av Säkerhetstjänsterna gäller följande max längder på namnen.

3.6.2.6. Spring JDBC

Spring JDBC [Web 19] innebär en abstraktion av den underliggande databastypen och genom att i implementationen använda oss av Spring JDBC avskärmar vi oss från den faktiska databashanterarens typ. Spring JDBC har även stöd för att tolka om felkoder och statusar från de olika databashanterarna och istället konvertera dessa till den hierarki av RuntimExceptions som ingår i Spring JDBC så att även felhanteringen kan göras transparent och oberoende av underliggande databashanterarna. 
SimpleJDBCTemplate är den klass i Spring JDBC som primärt används för access mot databaserna.

3.6.3. Transaktionshantering

I huvudsak gäller att för de tjänster som är transaktionella så sker transaktionshantering på tjänstenivå, dvs varje tjänsteanrop är en transaktion.
Atomikos [Web 10] tillhandahåller en implementation av Java Transaction API (JTA) och används inom Säkerhetstjänsternas IT-bastjänsterna för transaktionshantering mot såväl köer som databaser.

3.6.3.1. Aspektorienterad programmering för att styra transaktionerna

För att ange vilka metoder som ska transaktionshanteras och på vilket sätt, används Aspect Oriented Programming (AOP) vilken konfigureras via Spring. Konfigurationen av AOP:n görs i service.impl bundelns bundle-context.xml. Motsvarande transaktionshantering kan AOP:as utan spring genom att direkt använda Spring-klasserna för AOP:n i sin kod där ManagedService implementationen sker.

3.6.4. Delade gemensamma objekt

Vissa objekt är viktiga att de är de samma i olika instanser av tjänsterna men som trots detta inte behöver vara långsiktigt persistenta (t.ex. SAML-intyg som är viktiga att de är lika för alla tjänster som efterfrågar dessa men som inte sparas persistent i databas då de bara gäller en begränsad tid). För att dela objekt mellan flera olika JVM:er används Infinispan [Web 14].

"Infinispan is an extremely scalable, highly available key/value data store and data grid platform. It is 100% open source, and written in Java. The purpose of Infinispan is to expose a data structure that is distributed, highly concurrent and designed ground-up to make the most of modern multi-processor and multi-core architectures. It is often used as a distributed cache, but also as a NoSQL key/value store or object database."

Citatet ovan kommer från Infinispans dokumentation. Det sammanfattar produkten på ett bra sätt. Infinispan kommunicerar mellan noder m.h.a multicast, en till flera kommunikation. Infinispan har den fördelen att den enkelt kan utöka säkerhetstjänster med fler noder utan att behöva anpassa tidigare noder, den nya noden ansluter till klustret direkt. Infinispan följer med säkerhetstjänsters installationspaket. Även om man bara installerar en nod installeras Infinispan, vilket gör det enklare att utöka till en klustrad uppsättning när det behövs.

Figur 51: Exempel på hur Infinispan kommunicerar mellan noder.

3.6.4.1. Klustring av konfigurationsförändringar

För att säkerställa att alla noder i ett kluster har samma konfiguration vid ett givet tillfälle måste finns lyssnare på vardera nod som inväntar konfigurationsförändringar hos de andra noderna.

Figur 52 Exempel på när administratör gör konfigurationsförändring som sedan uppdateras på övriga noder.

3.6.5. Autentisering för RIV TA 2.1 tjänster

Som en anpassning till RIV TA 2.1 har kraven på autenstisering förändrats så att de tjänster som följer den anvisningen kan anropas genom att dubbelriktad SSL upprättas med ett certifikat som Säkerhetstjänsterna litar på. Anpassningen innebär också att kravet på SAML-intyg har utgått och att de värden som behövs för åtkomstkontroll skickas som vanliga parametrar i tjänsteanropen. Säkerhetstjänsterna litar på anroparen och litar därmed också på att anroparen går i god för och skickar korrekta värden för att nyttja vid t.ex. åtkomstkontroll. 
De tjänster som i version 2.4 går att anropa på detta förenklade sätt är:

• Spärrtjänsten
• Samtyckestjänsten
• Patientrelationstjänsten
• Logg
• Loggrapport
• Commission Service

3.6.6. Loggtjänst / Loggrapporttjänst

Se SAD - Loggtjänsten

3.6.7. Spärr

Se SAD - Spärrtjanst

3.6.8. Samtycke och Patientrelation

Se SAD - Tjänster för Samtycke och Patientrelation

3.6.9. Systemteknisk loggning

Den LogHandler som används vid loggning av systemteknisk information kommer att använda den LogTarget med högst ranking som inte rapporterat otillgänglighet. 
Exempel:

1. LogTarget som sparar loggarna i MySql konfigurerar att ha högst ranking och används därmed i normalfallet men om något oväntat skulle inträffa.
   1. T.ex. att Diskyta på databasservern blir full
   2. LogTarget för MySql flaggar att den inte längre är tillgänglig
      1. I och med att en LogTarget blir otillgänglig sätts en statusvariabel som gör det möjligt att trigga ett larm i övervakninsverktyget
2. LogHandler kommer då att försöka med nästa LogTarget enligt rankingen
   1. I detta exempel säger vi att det är LogTarget för att skriva loggposterna till fil
3. LogTarget för filskrivning kommer då istället att persistera loggarna på fil på den server där loggningen sker
4. Problemet åtgärdas på databasservern
   1. Mera disk installeras i servern
5. LogTarget MySql markeras som tillgänglig igen
6. LogHandler upptäcker att det finns en LogTarget med högre ranking tillgänglig
   1. Loggposterna kommer åter att persisteras i databas istället för på fil

SLF4J loggerns gränssnitt och har fem nivåer att använda, se SLF4J [Web 18], nedan följer en rekommendation för när de olika nivåerna bör användas.

Nedan följer några exempel på när respektive loggnivå ska användas

De olika nivåerna kan också innebära att två loggningar kan ske t.ex. om man fångar ett exception. Exceptionets meddelande loggas till info medan själva exceptionet loggas till debug. 

try {
   ...
}
catch (JAXBException exception) {
   this.logger.info(
      Resources.ERROR_TECHNICAL.toString() + ": {}",
	  exception.getMessage());
   this.logger.debug(
      "Exception: {}",
      exception);
   throw new BIFNonBusinessException(exception);
}

Observera att merparten av den loggning som sker inne i systemet inte har någon koppling till IT-bastjänsten för loggning och därmed är innehållet inte heller tillgänglig för Loggrapport via IT-bastjänsten för Loggrapport.

3.6.9.1. Loggning av webbtjänsteanrop

För att få en likformig loggning av alla webbtjänsteanrop ersätts den PipelineAssembler som WSIT tillhandahåller av en egenutvecklad PipelineAssembler som skapar och sammanlänkar önskade Pipes för in- och ut-gående webbtjänsteanrop – en av dessa Pipes kommer att vara en LoggingPipe, se 4.8.13 Generell funktionalitet vid varje webbtjänsteanrop.

3.6.10. Felhantering rivta anpassade tjänster

Se respektive tjänsts SAD och tjänstekontraktsbeskrivning.

3.6.11. Webbgränssnitt

3.6.11.1. Google Web Toolkit

Säkerhetstjänstens webbsidor skapas med hjälp av Google Web Toolkit.

"Google Web Toolkit (GWT) is a development toolkit for building and optimizing complex browser-based applications. Its goal is to enable productive development of high-performance web applications without the developer having to be an expert in browser quirks, XMLHttpRequest, and JavaScript." [Web 26] 

Ovanstående citat är hämtat från GWT dokumentationen och summerar iden bakom ramverket. Det innebär i korthet att utvecklare kan nyttja sin Java kunskap vid webbutveckling utan att först behöva lära sig tekniker som HTML, JavaScript eller AJAX först. Java koden kompileras som tidigare men istället för att kompileras till byte kod så sker en kompilering med GWT kompilatorn till JavaScript istället. En fördel med GWT kompileringen är att den kan optimeras för varje enskild webbläsare som stödjs och på så vis även kapsla bort webbläsarspecifika egenheter från utvecklaren. 
En debugger som möjliggör debuggning av de genererade javascripten som om det vore vanlig Java kod ingår också i GWT, det innebär att utvecklarna kan kontrollera variabelvärden, köra steg för steg och evaluera olika uttryck på det sätt de är vana att göra. Att konna debugga webbapplikationer som om de vore skrivna i vanlig Java kod är en av de produktivitetshöjande egenskaper ramverket tillför då debuggning av JavaScript kan vara både svårt och tidskrävande.
När nya versioner av webbläsare dyker upp på marknaden kan kompabilitet med dessa uppnås genom att byta till en senare version av GWT som stödjer dessa webbläsare.

3.6.11.2. Webbmoduler

Varje IT-bastjänst består av (minst) en webbmodul (OSGi-bundle) som kan startas och stoppas i drift. Det betyder att en enskild IT-bastjänsts webbmodul kan stoppas i drift och därmed försvinna från Säkerhetstjänsternas webbgränssnitt, oberoende av de andra IT-bastjänsterna. Webbgränssnittet är därmed också komponentbaserat och anpassar sig dynamiskt till vilka webbmoduler som finns att presentera för användaren.

3.6.12. Generell administration

Generell komponent i plattformen för att hantera WS-ResourceFramework hanterade resurser. Känner till kopplingen mellan resursen och de metoder som kan förändra resursens värden.

3.6.13. Köhantering

Fuse Message Broker (paketering av Apache ActiveMQ) är en meddelandehanterare som bygger på öppen källkod, till fullo implementerar JMS och som finns paketerad som en OSGi bundle. Denna lämpade sig därför väl att använda i Säkerhetstjänsternas SDK där data persisteras på disk. På serversidan nyttjas en mindre komplex egenutvecklad kö som persisteras sina meddelanden i en databas. Programmeringsmässigt används Spring JMSTemplate för access till köer och poster på dessa köer. Köer används i Säkerhetstjänsterna i samband med loggningen för att uppnå icke blockerande loggning, se 3.1.2 AF301, 302 och 303 Loggning för djupare insikt i hur köerna används.

3.6.14. Generell funktionalitet vid varje webbtjänsteanrop

Viss funktionalitet (loggning, prestanda mätning, m.m.) skall genomföras för varje inkommande respektive utgående webbtjänsteanrop inom Säkerhetstjänsterna, för att hantera detta ersätter Säkerhetstjänsterna WSIT:s interna TubelineAssembler med en egenutvecklad variant som lägger till Tubes som varje meddelande måste passera. TubelineAssembler:n är konfigurerbar så att det går att lägga till godtyckligt antal Tubes som varje SOAP meddelande passerar i prioritetsordning. 

Figur 74 Generell funktionalitet för inkommande och utgående webbtjänsteanrop

3.6.14.1. Subjekt

För att på ett enkelt sätt ge tillgång till information rörande vem eller på vems vägnar ett webbtjänsteanrop skickas anropet via en SubjectSettingTube i den generella containern.
Denna Tube genomför då ett javax.security.auth.Subject.doAs() anrop men subjektet som parameter.

3.6.14.2. Loggning

För att logga parametrar in, returvärden ut samt vad som händer under ett webbtjänsteanrop skickas anropet via en LoggingTube i den generella containern. 
När man skapar en LoggingTube tar denna bland annat en LogHandler och en Loggger som inparametrar. Konfigurationsmässigt kan man sedan styra så att den Slf4jLogger som används inom respektive IT-bastjänst för loggning använder samma LogHandler som LoggingTube så att när ett webbtjänsteanrop passerat genom Pipen innehåller inparametrar, returvärden samt alla loggposter som skrivits till den Loghandler som använts inom IT-bastjänsten så att dessa kan skrivas ner i samma LogBatch.

Figur 75 LoggingTube 
Den LogHandler som normalt används under drift använder sedan den högst rankade LogTarget som finns tillgänglig för att ta hand om loggarna.

3.6.14.3. Prestandamätning

För att mäta prestanda för in och utgående webbtjänsteanrop skickas anropen via en Tube för att mäta tidsåtgången , mätresultaten publiceras därefter som statusvariabler i OSGi:n och som MBeans 
 
Figur 76 Prestandamätning webbserviceanrop 
Både inkommande och utgående webbserviceanrop tidsmäts per webbservicetjänst och min-, max-, medelvärden beräknas för samtliga anrop och de x senaste anropen. 

Figur 77 Tube för webbserviceanrop in och ut 
Nedan beskrivs ett scenario för hur ett webbserviceanrop kommer in till Säkerhetstjänste servern, tidsmäts och publiceras som en MBean. 
Bearbetning av webbserviceanrop

1. Klienten skapar ett packet som innehåller alla uppgifter om anropet
2. Anropet skickas till servern
3. Anropet anländer till PerformanceTube
4. PerformanceTube processar anropet
5. En timer startas
6. Webbservice operationens namn extraheras ur det packet som skickats
7. Anropet skickas till övriga Tubes
8. Övriga Tubes bearbetar anropet
9. Anropet skickas åter igen till Performance Tube för response hantering
10. PerformanceTube processar anropet
11. Timern stoppas
12. Mätresultatet från timern läggs på en kö för senare bearbetning

Bearbetning av prestandamätningsvärde

1. Värde läses från kö med mätvärden
2. Skapa eller hämta MonitorableContext för aktuell webbservicemetod
3. Lägg till mätvärdet till MonitorableContext
4. Publicera mätvärdet i OSGi miljön

Publicera mätvärde som MBean

1. MBeanPublisher märker att en ny monitorerbar statusvariabel publicerats i OSGi miljön
2. MBeanPublisher skapar motsvarande MBean för JMX publicering

Figur 78 Schematisk bild över vägen från mätvärde till MBean 
När det finns MBeans publicerade kan valfri JMX-klient användas för övervakning.

4.  Installationsvy

4.1. Målmiljö

För Nationella säkerhetstjänster gäller Linux (CentOS 6.5.x) som servermiljö och för Lokala säkerhetstjänster kan man installera säkerhetstjänster Windows eller Linux. Från och med version 2.10 av säkerhetstjänster används Java 8.

4.2. Övergripande

4.2.1. Säkerhetstjänsterna Server

En server installation för Säkerhetstjänsterna kan på en grov nivå anses innehålla följande byggblock

• Säkerhetstjänsterna Kärna – tredjepartsprodukter, Gemensamma generella komponenter, konfiguration
• Säkerhetstjänsterna IT-bastjänster – De IT-bastjänster som ingår i Säkerhetstjänsterna

Figur 79 Installationskomponenter server Säkerhetstjänsterna 
För att göra en minimal installation av Säkerhetstjänsterna krävs Kärnan och de Kärntjänster som innehåller grundläggande funktionalitet som nyttjas från IT-bastjänsterna, utan dessa går det inte att starta Säkerhetstjänsternas IT-bastjänster. Efter det att grunden installerats kan man då välja att installera en eller flera av de IT-bastjänster som ingår i Säkerhetstjänsterna.

4.3. Plattformsdomäner

En plattformsdomän (eller Säkerhetstjänstinstallation) består av en eller flera javaprocesser (JVM:er) som kan ligga på olika fysiska eller virtuella maskiner. Plattformsdomänen har en delad diskarea som används för den gemensamma konfigurationen. På den gemensamma diskarean lagras även de ingående bundlarna och loggarkiven ifrån loggtjänsten. Konfigurationsuppdateringar och regeluppdateringar synkroniseras (med hjälp av infinispan) inom domänen för att alla noder ska ha samma state. På ett mer verksamhetsmässigt plan kan man också tala om domäner, t.ex. samtyckesdomäner, men de bör inte förväxlas med plattformsdomäner. 

Nedan följer ett exempel på hur IT-bastjänsterna skulle kunna installeras i en driftmiljö, men IT-bastjänsternas placering på olika servrar styrs i slutändan av förväntas antal användare och krav på prestanda. 

4.4. Leverabler

4.4.1. Säkerhetstjänsterna Server

4.4.1.1. Säkerhetstjänsterna Kärna

Den del av Säkerhetstjänsterna som behövs på en server för att därefter kunna lägga in de olika IT-bastjänsterna.

4.4.1.2. Säkerhetstjänsterna IT-bastjänster

De respektive IT-bastjänsterna i Säkerhetstjänsterna läggs in ovanpå kärnan för att tillhandahålla systemets verksamhetsmässiga logik.

4.5. Installation

För en detaljerad anvisning av hur de olika delarna i Säkerhetstjänsterna installeras, se t.ex. 2.5 Installationsanvisning SÄK och övriga installationsdokument som ingår i en Säkerhetstjänsternas -leverans.

4.6. Konfiguration

För en detaljerad anvisning av hur de olika delarna i Säkerhetstjänsterna konfigureras, se 2.5 Installationsanvisning SÄK och övriga installationsdokument som ingår i en Säkerhetstjänste-leverans.

5. Implementationsvy

5.1. IT-bastjänsternas namn

Alla paket vars innehåll vi själva utvecklar ska inledas med com.logica.se.
Alla paket vars innehåll är framtaget specifikt för Säkerhetstjänsterna ska inledas med com.logica.se.bif.
Paket som innehåller generell funktionalitet som skulle kunna återanvändas i andra projekt ska ha prefixet com.logica.se.iac.

5.1.1. Plattform / Kärna

Plattformen kommer att bestå av tredjepartsbundlar och egenutvecklade bundlar, de egenutvecklade bundlarna kommer att ligga under följande paket com.logica.se.iac och i versionshanteringssystemet kommer tredjepartsbundlarna att ligga under platform/3pp och de egenutvecklade bundlarna under platform/logica.

5.1.2. Autentisering

Denna IT-bastjänst ska implementeras under följande paket: com.logica.se.bif.idp och i versionshanteringssystemet ligga under authentication.

5.1.3. Loggrapport

Denna IT-bastjänst ska implementeras under följande paket: com.logica.se.bif.logreport och i versionshanteringssystemet ligga under loganalysis.

5.1.4. Loggning

Denna IT-bastjänst ska implementeras under följande paket: com.logica.se.bif.log och i versionshanteringssystemet ligga under log.

5.1.5. Samtycke

Denna IT-bastjänst ska implementeras under följande paket: com.logica.se.bif.consent och i versionshanteringssystemet ligga under consent.

5.1.6. Patientrelation

Denna IT-bastjänst ska implementeras under följande paket: com.logica.se.bif.patientrelation och i versionshanteringssystemet ligga under carerelation.

5.2. Källkodsstruktur inom varje IT-bastjänst

5.2.1. Enhetstest

För att genomföra de mest grundläggande testerna, enhetstest, skapas ett vanligt Java projekt (ej Bundle). Detta Java projekt refererar till JUnit, EasyMock och liknande test ramverk samt de klasser inom IT-bastjänstens bundlarna som avses att testas. 
Enhetstesterna för samtliga andra projekt inom IT-bastjänsten samlas i detta Java projekt som heter unittest. 
T.ex. com.logica.se.bif.foo.unittest, detta projekt kommer att innehålla flera paket med suffixet unittest som speglar vad underliggande tester avser att testa 
T.ex. com.logica.se.bif.foo.agent.impl.unittest, som i sin tur innehåller testklasser med suffixet UnitTest, T.ex. FooAgentImplUnitTest.Java

5.2.2. Webbgränssnittimplementation

Webbgränssnittets implementation består av både Java-klasser som ska ligga i ett paket som heter web och JSP filer som ligger under WEB-INF/jsp. 
T.ex. com.logica.se.bif.foo.web – detta paket kan innehålla filer som vid namn FooController.java, FooValidator.java, klasser som motsvarar innehållet i olika formulär o.s.v.

5.2.3. Agentgränssnitt

Agentens interface ska ligga i ett paket som heter agent. 
T.ex. com.logica.se.bif.foo.agent – detta paket kommer att innehålla en fil vid namn FooAgent.java.

5.2.4. Agentimplementation

Agentens implementation ska ligga i ett paket som heter agent.impl. 
T.ex. com.logica.se.bif.foo.agent.impl – detta paket ska innehålla en fil vid namn FooAgentImpl.java.

5.2.5. Agentimplementation bundletest

Innehåller en bundle med syfte att enhetstesta agentimplementationsbundeln, den har samma paketnamn som det som avses att testas men med suffixet bundletest. 
Testet genomförs genom att OSGi miljön startas upp och testbundeln körs. 
T.ex. com.logica.se.bif.foo.agent.impl.bundletest – kan innehålla bl.a. en fil vid namn FooAgentImplBundleTest.java 
För detaljer rörande testbundelns implementation se 8.2.2 Bundletest.

5.2.6. Tjänstegränssnitt

Bastjänsternas interface ska ligga i ett paket som heter service. 
T.ex. com.logica.se.bif.foo.service - detta paket kommer att innehålla en fil vid namn FooService.java.

5.2.7. Proxy för tjänstegränssnitt över webbtjänst

Den proxyimplementation mot bastjänsten som använder webservicen för att göra anropet till servern ska ligga i ett paket som heter service.ws.proxyimpl. 
T.ex. com.logica.se.bif.foo.service.ws.proxyimpl - detta paket kommer att innehålla en fil vid namn FooWebServiceProxyImpl.java.

5.2.7.1. Felhantering

För att få en enhetlig felhantering som konverterar SOAPFaultException till Throwable används BIFExceptionHelper enligt nedan. 

try {
	...
} catch (SOAPFaultException soapFaultException) {
	throw BIFExceptionHelper.handleSOAPFaultException(CLASS.class.getClassLoader(), soapFaultException);
}

5.2.8. Proxy för tjänstegränssnitt över webbtjänst bundletest

Innehåller en bundle med syfte att enhetstesta bundeln proxy för tjänstegränssnittet över webbtjänst, den har samma paketnamn som det som avses att testas men med suffixet bundletest. 
Inte tvingande att enhetstesta på denna nivå om proxyn i sig inte genomför några komplicerade operationer och det finns en agent som nyttjar proxyn som testas istället. 
Testet genomförs genom att OSGi miljön startas upp och testbundeln körs. 
T.ex. com.logica.se.bif.foo.service.ws.proxyimpl.bundletest – kan innehålla bl.a. en fil vid namn FooServiceWsProxyImplBundleTest.java 
För detaljer rörande testbundelns implementation se 8.2.2 Bundletest.

5.2.9. Webbtjänstegränssnitt

Den wsdl som specificerar webbtjänsteinterfacet bot bastjänsten ska ligga i ett paket som heter service.ws. 
T.ex. com.logica.se.bif.foo.service.ws - detta paket kommer att innehålla en fil vid namn FooService.wsdl.

5.2.10. Webbtjänsetimplementation

Webbtjänstens implementation ska ligga i ett paket som heter service.ws.impl. 
T.ex. com.logica.se.bif.foo.service.ws.impl - detta paket kommer att innehålla en fil vid namn FooWebServiceImpl.java.

5.2.10.1. Felhantering

För att få en enhetlig felhantering som konverterar Throwable till SOAPFaultException används BIFExceptionHelper enligt nedan. 

try {
	...
}
catch(Throwable throwable) {
	throw BIFExceptionHelper.handleThrowableWS(throwable);
}

5.2.11. Tjänsteimplementation

Bastjänsternas implementation ska ligga i ett paket som heter service.impl. 
T.ex. com.logica.se.bif.foo.service.impl - detta paket kommer att innehålla en fil vid namn FooServiceImpl.java

5.2.11.1. Felhantering

För att få en enhetlig felhantering som wrappar Throwable utanför Säkerhetstjänsternas Exceptionhierarki till BIFNonBusinessException kan BIFExceptionHelper användas enligt nedan. 

try {
	...
}
catch(Throwable throwable) {
	throw BIFExceptionHelper.handleThrowable(throwable);
}

5.2.11.2. Transaktionshantering för tjänst via konfiguration

Transaktionshanteringen på tjänstenivån applicerar med hjälp av AOP antingen via konfiguration enligt exemplet nedan eller genom att anropa de motsvarande underliggande Java klasser direkt. Då normalfallet är att komponenten har en ManagedService används i merparten av Säkerhetstjänsternas tjänsterna det senare alternativet.
Observera att pointcut:en pekar ut interfacets metod inte den metod som implementerar interfacet.

5.2.12. Tjänsteimplementation bundletest

Innehåller en bundle med syfte att enhetstesta tjänsteimplementationsbundeln, har samma paketnamn som det som avses att testas men med suffixet bundletest. 
Testet genomförs genom att OSGi miljön startas upp och testbundeln körs. 
T.ex. com.logica.se.bif.foo.service.impl.bundletest – kan innehålla bl.a. en fil vid namn FooServiceImplBundleTest.java 
För detaljer rörande testbundelns implementation se 8.2.2 Bundletest.

5.2.13. Persistensgränssnitt

Innehåller metoder för persistens samt interface för entiteterna. 
T.ex. com.logica.se.bif.foo.repository – innehåller filen FooRepository.java

5.2.14. Persistensimplementation

Implementerar persistering av de entiteter som finns i persistensgränssnittet. 
T.ex. com.logica.se.bif.foo.repository.impl – innehåller filen FooRepositoryImpl.java

5.2.14.1. Felhantering

För att få en enhetlig felhantering som wrappar Throwable utanför Säkerhetstjänsternas Exceptionhierarki till BIFNonBusinessException kan BIFExceptionHelper användas enligt nedan. 

try {
	...
}
catch(Throwable throwable) {
	throw BIFExceptionHelper.handleThrowable(throwable);
}

5.2.15. Exceptions

Om det finns verksamhetsmässiga egendefinierade exceptions skall dessa ligga i ett eget paket (och i förlängningen också i en egen bundel). Detta p.g.a att paketet med interfacet inte ska innehålla någon implementation och att paketet som innehåller den faktiska implementationen av t.ex. agenten inte ska göras tillgänglig utanför OSGi miljön. 
T.ex. com.logica.se.bif.foo.agent.exception innehåller de exceptions som agenten deklarerar att den kastar.

5.3. Implementation av Webbtjänst

För en allmän beskrivning av hur webbtjänster kan implementeras se The Java Web Service Tutorial [Web 15].

5.3.1. JAXB eller Provider implementering

Webbtjänster kan implementeras på två sätt beroende på behov. Det rekommenderade sättet är att använda JAXB som förenklar mappningen mellan XML och Java objekt. Nackdelen med JAXB är att hanteringen av namnrymder är svår att styra, vilket ofta ställer till problem vid signering om ett SOAP-meddelande innehåller flera olika nivåer av signeringar, d.v.s. olika delar i meddelandet är signerade av olika aktörer. 
För att hantera meddelanden med flera signeringsdelar används istället Provider [Web 16] gränssnittet för implementering av webbtjänster. Hanteringen av SOAP-meddelandet sker då på en lägre nivå i ren XML.
En webbtjänst som använder Provider gränssnittet måste ange nyckelordet @WebServiceProvider i implementeringen.

5.3.2. Eclipse plugin för JAX Nature

För att underlätta generering av Java klasser att använda i webbtjänsterna har en Eclipse plugin tagits fram internt för utvecklingsprojektet. Denna plugin kör de underliggande genereringskommandona utifrån de bindingfiler som skapas i webbtjänsteprojekten. Bindingfilerna pekar i sin tur ut de wsdl- och xsd-filer som nyttjas vid genereringen. 
Det är webbtjänstegränssnittprojekten som ska konfigureras att använda denna Jax Nature, t.ex. com.logica.se.bif.foo.service.ws. 
När man har aktiverat Jax Nature för ett projekt ges tillgång till JAXWS Properties när man öppnar property fönstret för projektet. Där styr man vilka bindingfiler generatorn tar hänsyn till, var de genererade klasserna ska hamna samt vilken eller vilka av JAXB och WsImport generatorerna som ska köras. 

Figur 82 JAXWS Properties

5.3.2.1. Bindingfiler

De bindingfiler som nyttjas inom projektet skall placeras direkt under projektets resource katalog. 

Figur 83 Bindingfiler

5.3.2.2. Wsdl och xsd:er

Wsdl- och xsd-filer skall placeras under resource katalogen i en katalogstruktur som överensstämmer med projektet, t.ex. com.logica.se.bif.foo.service.ws. 
Tjänsten kan innehålla flera xsd:er där en xsd innehåller rena xml-datatyper och en xsd innehåller datatyper knutna till den specifika webbtjänsten. De Xsd:er som är hårt knutna till webbtjänsten ska innehålla "ws" i filnamnet. 

Figur 84 Wsdl och xsd filer

5.3.2.3. Constants.java

För att ge tillgång till de scheman tjänsten är beroende av skapas en klass konstantklass med namnet Constants.java som innehåller en metod med följande signatur: 
public static List<Source> getMetaData() 
Denna metod ansvarar för att läsa in de xsd:er webbtjänsten är beroende av och returnera dessa som en Source-lista. 

Figur 85 Constants.java

5.3.2.4. Genererade filer

De filer som pluginen genererar ska genereras till en katalog vid namn gensrc, denna katalog ska vara incheckad men inte innehållet i katalogen. 

Figur 86 Gensrc

5.4. KIF

Kif är ett genereringsspåk som CGI har tagit fram. Den genererar java kod, wsdl:er, dokumentation och databasskript.

5.4.1. Xtext och Xtend

Kif baseras på Xtext och Xtend. För allmän information se [Web 23] och [Web 24].

För att använda Kif krävs att man installerar Xtext SDK och Xtend SDK plugins i Eclipse.

Figur 87: Installation av Xtext och Xtend plugin

5.4.2. Installation av Kif plugin

När man har Xtext och Xtend så måste man installera eclipse plugin för Kif.

Figur 88: Installation av Kif plugin

När plugin är installerat så ska man starta kif bundlar i eclipse osgi konsoll.

Figur 89: Uppstart av Kif plugin

5.4.3. Generering av javakod

Java kod genereras av Kif. Den genererar ws gränssnitt, service interface, databasfrågor, dokumentation och GWT typer.

Den genererade koden landar i gensrc i respektive projekt.

Figur 90: Genererad java kod

5.4.4. Generering av dokumentation

Tjänstekontraktsbeskrivning genereras av Kif.

Figur 91: Genererade tjänstekontraktsbeskrivningar

5.4.5. Generering av skript för databas

Skript för att skapa upp databaser genereras av Kif.

Figur 92: Genererade databasskript

5.4.6. Generering av wsdl filer

Wsdl filer genereras av Kif.

Figur 93: Generering av wsdl filer

6.  Storlek och prestanda

Detta kapitel innehåller för tillfället ingen konkret information om just storlek och prestanda eftersom det inte finns något fastslaget underlag om volymer och laster att prestandamäta emot. Kapitlet kommer successivt att växa fram i samband med vidareutveckling av Säkerhetstjänsterna.

6.1. JProfiler

JProfiler [Web 17] användas inom utvecklingsprojektet för att göra prestandamätningar samt för att hitta eventuella flaskhalsar och onödiga minnesallokeringar i systemet. JProfiler är ett lämpligt verktyg att nyttja då det är en beprövad produkt som ger mycket detaljerad information om minnesallokering, trådaktivitet, etc. 
JProfiler har inga direkta kopplingar till eller krav på det system som skall instrumenteras utan nyttjar JVM:ens profileringsinterface för att samla in det data som behövs för profileringen.

7.  Kvalitet

7.1. Likformig kod

För att inom utvecklingsprojektet få källkod som till så hög grad som möjligt följer vår kodningsstandard har en formateringsmall till Eclipse tagits fram och för att den automatiskt ska användas när filer sparas skall varje projekt som innehåller egenutvecklad källkod innehålla "Save Actions" enligt nedan. 

Figur 94 Save Actions i Eclipse 
Det går att göra dessa inställningar på Workspace-nivå men då skulle inställningarna hamna utanför versionshanteringssystemet men ett tips är att ändra Workspace-inställningarna enligt ovan och sedan bara klicka i "Enable project specific settings" så får man direkt samma inställningar i projektet. 
Alla justeringar kan dock inte ske som save actions utan utvecklarna förutsätts utöver detta ha satt sig in i den konstruktionsanvisning för Java som finns på enheten.

7.2. Test

I denna SAD beskrivs endast enhetstest och bundletest, för övrig testrelaterad informations se Testplanen [Ref 2].

7.2.1. Enhetstest

Första steget i testkedjan är genomförande av enhetstest där systemets minsta beståndsdelar testas en enhet i taget. Beroenden till andra komponenter/enheter stubbas bort efter behov för att kunna begränsa testet till en enhet. 
I enhetstestarna ska enheterna testas både med avseende på normalflöden och alternativ/fel- flöden inom enheten samt gränsvärdeskontroller.

7.2.2. Övriga testnivåer och testtyper

Testerna utöver enhetstest delas in i tre stycken testnivåer: Funktionstest, Systemtest och Integrationstest. 
Testerna efter enhetstest startar på Funktionstestnivån. Om fel upptäcks under test som renderar i en rättning med omleverans till följd, så görs en ny installation i testmiljön och därefter en regressionstest. Efter det fortsätter testen där den slutade innan stoppet. Detta förfarande gäller i samtliga testnivåer om testerna måste avbrytas för rättning och omleverans.

Figur 95 Testnivåer utöver enhetstest och bundletest