Tjänst under avveckling

Dessa sidor kommer att tas bort 2023-01-01

OBSERVERA: Supporten upphör 2023

I juni 2021 meddelade Inera i ett nyhetsbrev att lokala installationer av Lokala Säkerhetstjänsterna Spärr, Logg och Samtycke inte kommer att erbjudas eller supportas från och med 1 januari 2023.

Nya installationer av Lokala Säkerhetstjänster 2.17 rekommenderas av denna anledning inte för en i längden hållbar lösning.

För information om lokal installation av den nya IdP:n se denna sida.

Dokumenthistorik

Datum	Version	Namn	Förändring
20 Mar 2017	0.1	Unknown User (lexhagenm)	Dokument upprättat i confluence
12 Oct 2017	0.2	Örjan Olofsson	Uppdaterat för 2.17
18 Oct 2017	0.3	Okänd användare (sundbergs)	Uppdaterat instruktioner
30 Oct 2017	1.0	Okänd användare (h.ferm)	Fastställd
09 Nov 2017	1.1	Unknown User (lexhagenm)	Rättat adress till PU-tjänsten via NTjP
09 Nov 2017	1.2	Unknown User (lexhagenm)	Rättat adress för spärreplikering via NTjP
22 Nov 2018	1.3	Unknown User (lexhagenm)	Lagt till info om behovet av nerladdning av de nationella spärrarna.
18 Jul 2019	1.4	Unknown User (lexhagenm)	Ändrad/ny certifikatsinformation då SITHS-certifikat inte längre bör användas i front-end
13 Sep 2019	1.5	Unknown User (lexhagenm)	Tagit bort extern beroende till HSA-kontrakt GetPersonAuthorizedToSystemIncludingProtectedPerson som endast används i den nationella installationen.

Innehållsförteckning

1. Inledning

1.1. Allmänt

Säkerhetstjänster är en produkt som är utformad för att hantera patientuppgifter enligt patientdatalagen (PDL) och tillgodose användare av systemet med en säker autentisering. Produkten innehåller olika tjänster (som exempelvis Autentiseringstjänsten och Spärrtjänsten) som kan installeras separat eller tillsammans som ett komplett paket.

NOTERA: Att installera och konfigurera Säkerhetstjänster kräver en viss teknisk IT-kompetens inom nätverk, databaser, operativsystem och eventuell felsökning.

OBS! Från version 2.11 så är installationspaketet detsamma för både Linux och Windows, men med separata installationsförfaranden.

OBS! Från version 2.15 så har installationsprogrammet förbättrats. Installationen går till på samma sätt som tidigare, där man skall ange ett antal konfigurationsvärden för att systemet skall starta upp.
Det ges även möjlighet att när som helst under installationen spara dom konfigurationsvärden man matat in till en fil, för att vid ett senare tillfälle återuppta installationen, utan att behöva mata in alla värden på nytt igen.

SITHS-certifikat

Sedan april 2019 är det inte rekommenderat att använda SITHS-certifikat för Webbsidor (front-end) eftersom SITHS som utgivare har beslutat sig för att lämna Microsofts rotcertifikat-program.

Man vill fortfarande ha ett SITHS-certifikat för t.ex Spärrtjänstens WebService-gränssnitt och för att kunna kommunicera med t.ex NTjP men man bör alltså även beställa ett certifikat till front-end-domänerna från annan utgivare t.ex SSL-certifikat från Telia eller DigiCert.
Notera att till skillnad från SITHS så har övriga utgivare stöd för Subject Alternative Name, SAN, i sina certifikat så det ska räcka med ett certifikat för alla front-end-domäner i en installation (app, idp, secure.idp) och ett SITHS-certifikat för ws-domänen.

För befintliga installationer med SITHS-certifikat i front-end finns en guide skriven: Byta bort SITHS-cert i frontend

NOTERA: Titta igenom Checklistan innan man påbörjar installationen av Lokala Säkerhetstjänster. Den handlar om förberedelser som skall utföras i god tid innan installationen av Säkerhetstjänster påbörjas.

Checklista inför installation

Detta dokument beskriver installationen av lokala Säkerhetstjänster. Dokumentet beskriver i huvudsak:

Portval - SSL standardport 443 eller Säkerhetstjänster 8443-8446 portar.
Installation av databasserver MySQL
Installation av databasserver MongoDB
Installation av applikationsserver
Systemkonfiguration och uppsättning av behörighet
Administration, förvaltning och underhåll

Tabellen nedan beskriver vad installationspaketet innehåller.

Sökväg	Beskrivning
db	Konfigurationsfiler och databasskript (MySQL).
doc	All dokumentation
example	Exempelkod för hur man kan ansluta en SP (webb) mot IdP:n (lokal Autentiseringstjänst). Exempelkod i java och .NET för autentisering av rika klienter.
install	Installationsskript och systemkomponenter.
license	Samlad licenskatalog
rules	Behörighetsregler som ska modifieras och läsas in i systemet
schema_wsdl	Tjänstekontrakten för lokala Säkerhetstjänster
templates	Mall regel och metadatafil
upgrade	Uppgraderingspaket med program, skript och instruktioner

1.2. Begrepp

Begrepp	Beskrivning
Autentiseringstjänst	Även kallad för IdP. Den tjänst som kontrollerar användarens kreditiv och utfärdar en SAML-biljett.
Bundel	Komponent till ett program
CDC	Common Domain Cookie. En webbläsarkaka som lagrar historik från tidigare besökta IdP:er.
CRL	Certificate Revocation List En lista med certifikat och dess status (ex. revokerat den 12 december 2014). Dessa listor uppdateras oftast med jämna intervaller.
DRBD	Distributed Replicated Block Device. En delad diskyta för Linux.
GFS2 / NFS	Global File System 2 / Network File System. En delad diskarea/filsystem för Linux kluster.
HA	High Availability. En tjänst som har hög tillgänglighet.
HPTA	En HSA-policytillämpning (HPTA) skrivs av varje direktansluten verksamhet och beskriver hur den enskilda organisationen uppfyller kraven i HSA-policy.
HSA	Hälso- och sjukvårdens adressregister, HSA, är en elektronisk katalog som innehåller kvalitetssäkrade uppgifter om personer, funktioner och enheter i Sveriges kommuner, landsting och privata vårdgivare.
HSA-WS	Webbservicetjänst mot HSA-katalogen som säkerhetstjänster använder sig av.
IdP	Identity Provider (Autentiseringstjänst) Tjänst som autentiserar en aktör och utfärdar, i detta fall, en SAML-biljett. Autentiseringstjänsten (IdP) är en tjänst som levereras med Säkerhetstjänster.
Metadata	Konfigureringsdata skriven i XML-format. Används för att ge konsumentsystem behörighet till Säkerhetstjänster. SP-metadata importeras in i IdP:n och IdP:ns metadata importeras in i SP:n för att konfigurera/behörighetsstyra IdP:n och SP:n. http://docs.oasis-open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf
Multicast	Gruppsändning till en eller flera noder samtidigt Används av applikationsservrarna.
NTP	Network Time Protocol. Används för synkronisering av servrarnas realtidsklocka.
OCSP	Online Certificate Status Protocol En aktiv tjänst som svarar på certifikatstatusförfrågningar. Till skillnad från CRL tillhandahåller denna tjänst alltid aktuell status för certifikatet som efterfrågas.
PDL	Patientdatalagen http://www.datainspektionen.se/lagar-och-regler/patientdatalagen/
PU-tjänst	Personuppgiftstjänst
REST	Representational State Transfer. Beskriver hur tjänster för maskin-till-maskin kommunikation kan ske via webbteknologi
RIV	Regelverk för Interoperabilitet inom Vård och omsorg. www.rivta.se
RIV TA	RIV Tekniska anvisningar. Syftet med denna anvisning är att beskriva hur man realiserar utbytet av information mellan två parter. RIV Tekniska Anvisningar är en integrerad del i den nationella arkitekturen. http://rivta.se/
Sak_server	Tjänsten som kör Säkerhetstjänster på servern.
SAMBI	SAML-profil för samverkan för Behörighet och Identitet inom hälsa, vård och omsorg. Beskriver hur egenskaper namnsätts i SAML-biljetten. https://www.inera.se/kundservice/dokument-och-lankar/tjanster/sakerhetstjanster/
SAML	Security Assertion Markup Language En standard som beskriver hur egenskaper och dess värden skall beskrivas i XML-format. http://saml.xml.org/saml-specifications
SAML biljett	Ett intyg som Autentiseringstjänsten utfärdar som innehåller en samling med egenskaper enligt SAML. Inom hälsa, vård och omsorg används SAML-profilen SAMBI.
Single installation	En installationsform där endast en nod används.
SITHS	SITHS är en nationell lösning för säker IT i hälso- och sjukvården.
SP	Service Provider. Den som erbjuder en tjänst, kan vara ett lokalt vårdsystem eller en tjänst i de lokala säkerhetstjänsterna, t ex Samtyckestjänsten. De lokala tjänsterna i Säkerhetstjänsterna, förutom IdP:n, grupperas som en SP.
Tjänsteplattformen (TP)	Tjänsteplattformen är en nationell teknisk plattform som förenklar, säkrar och effektiviserar informationsutbytet mellan olika IT-system inom vård och omsorg. https://www.inera.se/Fordjupning/arkitektur-och-regelverk/om-tjansteplattformen/

1.3. Referenser

Referensnr	Namn	Adress
Ref 1	Inera AB	www.inera.se
Ref 2	Inera AB	Användarhandbok (lokal)

2. Systemkrav

Lokala Säkerhetstjänster levereras med installationsanvisningar för Linux Redhat/CentOS 64bit. Denna leverans är kvalitetssäkrad på CentOS 7.3 64bit (x86_64). Nedan föreslås riktvärden på hur en produktionsmiljö minst bör dimensioneras.

Applikationsservrarna bör vara flerkärniga med minst 12 GB RAM.
MySQL-databasservrarna bör vara flerkärniga med minst 12 GB RAM dedikerat för MySQL-servern.
MongoDB-servrarna bör vara flerkärniga och hur mycket RAM som krävs är beroende av hur mycket respektive vårdgivare loggar. En riktlinje är att 40 miljoner loggposter med dess index tar c:a 20 GB RAM.

2.1. Diskyta

För att kunna köra systemet med flera servrar i en HA-lösning krävs att samtliga noder har tillgång till en delad diskyta där bl.a. arkivloggar och systemets gemensamma konfiguration finns lagrat. Dessa kan sättas upp med t.ex GFS2, NFS (eller annan delad disk lösning) och mappas upp till en katalog på samtliga noder. Det är viktigt att det är en redundant lösning så att man inte får en "SinglePointOfFailure", då systemet kräver tillgång till den delade diskytan för att kunna starta.

Förvalt är namnet på katalogen: /share i konfigurationen nedan. Notera att även i en installation med bara en server så behöver dessa diskytor/sökvägar skapas och konfigureras för systemet, men delning behöver förstås inte vara aktiverat.

2.1.1. Delad diskyta för Säkerhetstjänster

Installationsdisken (working path: /sakerhetstjansten ) bör minst vara 20 GB (mer rekommenderas).
Den delade diskytan (/share) för applikationsservrarna bör minst vara 100 GB.

2.1.2. Diskyta för MySQL

Diskytan för MySQL bör minst vara 200 GB.

2.1.3. Diskyta för MongoDB

Diskytan för mongoDB bör minst vara 200GB initialt och beroende på vilka tjänster används kan den behöva vara större.

När databaserna för rapporthanteringen skapas vid installation, behövs ungefär 10 GB diskyta. MongoDB allokerar upp disk som senare används när loggar läggs till i databasen. Fyra databaser skapas vid installationen, som använder detta utrymme. Det är för:

Loggtjänsten:

PDL-loggar (lagras default i 18 månader).
Riktlinje är att 40 miljoner PDL-loggar kräver c:a 115 GB diskyta.
Arkivsökningar (PDL-loggar läggs till temporärt och raderas när rapporten är klar).

Autentiseringstjänsten:

Statistikloggar som loggar händelser vid inloggning och utloggning. (lagras som default i 3 månader).
Antalet loggar beror på hur många som använder systemet.

Audit loggning för systemet:

Systemloggar (används inte primärt utan är en backup om annan loggning inte kan köras eller om den konfigureras att användas).
Beroende på om MongoDB används för systemloggning kan antalet systemloggar öka dramatiskt, om t.ex. loggnivå ändras till TRACE. Det kan generera stora mängder loggar och diskyta kan snabbt konsumeras.

Lokala säkerhetstjänster i sig kommer inte att generera någon större mängd loggar. Behovet av den diskyta som krävs, är till största delen beroende på hur mycket externa tjänster kommer att använda Loggtjänsten respektive Autentiseringstjänsten.

2.2. Tidssynkronisering

Operativsystemen för Lokala Säkerhetstjänster skall vara tidssynkroniserade för att systemet skall fungera korrekt. Felaktigt inställd tid, kan få till följd att autentisering av klienter misslyckas samt att systemet lagrar och/eller uppger felaktiga tidpunkter för verksamhetsdata. Detta säkerställs på operativsystemnivå och är inte en del av produkten. För att synkronisera tiden kan t.ex. NTP användas.

2.3. Lastbalanserare

Från och med version 2.7 av Lokala Säkerhetstjänster går det att använda SSL standardport (443) för alla ingående tjänster istället för att man externt ansluter till tjänsterna mot en unik port. En förutsättning för att detta ska fungera är att en lastbalanserare finns och är konfigurerad att istället lyssna på, för tjänsterna, unika ip-adresser och som styr trafiken vidare mot applikationsserverns interna portar (som fortfarande måste vara unika för tjänsterna).

3. Plattform och tredjepartsprodukter

Följande tredjepartsprodukter och infrastruktur måste installeras först och utgör "plattformen" för lokala Säkerhetstjänster.

3.1. Java

För att köra applikationsservern krävs Oracle Java SE 8, JDK, 64 bitar, som finns att hämta på: http://www.oracle.com/technetwork/java/javase/downloads/index.html.

Notis om licensen för Oracles distribution av Java;
om man inte uttryckligen slå på användning av t ex Java Mission Control eller Flight Recorder triggas inte den kommersiella licensen. Säkerhetstjänster gör inte detta. Se https://docs.google.com/document/d/17OF811wWjjCnmDPJDD6v2c_nMO93e5evjravdCOkXMQ/edit för detaljerna

3.1.1. JCE - Java Cryptography Extension

Det krävs även ett tillägg, http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html, som måste installeras för att kunna nyttja 256-bitars kryptering.

3.2. MySQL

Lokala Säkerhetstjänster kräver databasservern MySQL. Systemet är kvalitetssäkrat med MySQL Community Server 5.6.37 och säkerhetstjänsterna kräver att ni använder en version ur 5.6-serien, dock senare än version 5.6.18. Tidigare 5.6 versioner har problem gällande minneshanteringen.

Databasen bör ha redundant lagring och/eller en backup-rutin vid produktionssättning. Eftersom detta är en driftrelaterad fråga som kan lösas på en mängd olika sätt så beskrivs det inte mer här.

I denna release av Lokala Säkerhetstjänster har vi valt att ligga kvar på MySQL Community Server 5.6.(37), då MySQL Community Server 5.7.x innehåller ett fel gällande hantering av XA-transaktioner i redundanta replikerings-miljöer (master-slave, master-master). Oracle är medvetna om detta, men kommer inte att hinna släppa någon patch inför denna release av Lokala Säkerhetstjänster 2.17

3.3. MongoDB

MongoDB är en lättviktig (NoSQL) databas som används för att hantera uppföljning av verksamhetsloggar (PDL-loggar). Databasen håller PDL-loggar i 18 månader (konfigurerbart) tillbaka i tiden och är den databas som loggrapporter genereras från. Loggposter som är äldre än 18 månader tas bort från MongoDB och finns arkiverade som zip-filer för långtidslagring.

MongoDB används för att snabbt kunna söka i stora mängder loggposter och generera rapporter för uppföljning. MongoDB är därför ett krav vid installation av lokal Loggtjänst.

Denna databas används även som reservkälla för systemets händelseloggar ifall anslutningen till MySQL-databasen skulle falla ifrån samt för insamlande av statistik runt autentiseringshändelser. Dessa funktioner går dock att inaktivera ifall man skulle behöva en lokal installation utan tillgång till MongoDB (se Installation utan databasen MongoDB som beskrivs senare i dokumentet)

Systemet är kvalitetssäkrat mot MongoDB-server 3.4.7. Hur databasen bör sättas upp för Säkerhetstjänster beskrivs i avsnitt Installationsanvisningar för MongoDB

3.4. Lastbalanserare

En lastbalanserare som klarar HTTPS krävs för att köra Säkerhetstjänster med skalskydd och trafikdirigering. Det innebär att lastbalanserare krävs för att kunna köra Säkerhetstjänster med standardport 443 för samtliga tjänster. Anvisningar för lastbalanserare beskrivs inte i detta dokument. Lastbalansering till applikationsserver kan ske med round-robin då all sessionsdata (SSL-sessioner) delas mellan applikationsservrarna och de externa HTTPS-portarna som används bör TCP-monitoreras, innan lastbalansering sker till applikationsservern.

3.5. Funktionscertifikat

Innan installation av lokala Säkerhetstjänster påbörjas måste funktionscertifikat för legitimering införskaffas, utfärdat för Lokala Säkerhetstjänsters olika domäner. Funktionscertifikat används för att identifiera applikationsservern vid all sorts kommunikation.

Sedan april 2019 är det inte rekommenderat att använda SITHS-certifikat för Webbsidor (front-end) eftersom SITHS som utgivare har beslutat sig för att lämna Microsofts rotcertifikat-program. Man vill dock fortfarande ha ett SITHS-certifikat för t.ex Spärrtjänstens WebService-gränssnitt och för att kunna kommunicera med t.ex NTjP men man bör alltså även beställa ett certifikat till front-end-domänerna från annan utgivare t.ex SSL-certifikat från Telia eller DigiCert. Notera att till skillnad från SITHS så har övriga utgivare stöd för Subject Alternative Name, SAN, i sina certifikat så det ska räcka med ett certifikat för alla front-end-domäner i en installation (app, idp, secure.idp) och ett SITHS-certifikat för ws-domänen

Funktionscertifikaten skall vara utfärdade till de DNS-namn som skall användas för applikationsservern. Var god kontakta Inera för information kring SITHS funktionscertifikat [Ref 1].

Det kan se ut som i tabellen nedan för de två nationella installationerna av Säkerhetstjänster:

Domän

SAN

Utgivare

Kommentar

CN = sakerhetstjanst.inera.se

DNS Name=sakerhetstjanst.inera.se
DNS Name=sakerhetstjanst.sjunet.org
DNS Name=idp2.sakerhetstjanst.inera.se
DNS Name=idp2.sakerhetstjanst.sjunet.org
DNS Name=secure.idp2.sakerhetstjanst.inera.se
DNS Name=secure.idp2.sakerhetstjanst.sjunet.org

DigiCert Inc

CN = DigiCert SHA2 High Assurance Server CA

CN = ws.sakerhetstjanst.inera.se

SITHS har inget SAN-stöd

SITHS

CN = SITHS Type 3 CA v1

För PreProd/testmiljöer är utgivaren

CN = SITHS Type 3 CA v1 PP

CN = ws.sakerhetstjanst.sjunet.org

SITHS har inget SAN-stöd

SITHS

CN = SITHS Type 3 CA v1

För PreProd/testmiljöer är utgivaren

CN = SITHS Type 3 CA v1 PP

3.5.1. Ytterligare funktionscertifikat

Om lokala Säkerhetstjänster ska nyttjas tillsammans med andra IdP:er i en federation, krävs ytterligare ett SITHS funktionscertifikat som är utfärdat för IdP:n på den gemensamma domänen inom federationen. T ex om den gemensamma domänen i federationen är commondomain.example.com, behöver även denna IdP ha ett funktionscertifikat t.ex. idp.commondomain.example.com.

3.6. CSP - Cryptographic Service Provider

Vid autentisering och anslutning till administrationsgränssnittet för lokala Säkerhetstjänster via webbläsare, krävs tillgång till en CSP på användarens dator. Detta för att kunna använda ”hårda certifikat” (t.ex SITHS-kort). T.ex. kan Net iD användas. Vänligen kontakta Inera för information kring SITHS och Net iD [Ref 1].

3.7. Kluster med Infinispan (Distributed in-memory cache)

Vår rekommendation är att Säkerhetstjänster installeras i ett kluster med två noder. Systemet har en inbyggd lösning med Infinispan, som hjälper noderna att dela resurser (som exempelvis systemets konfigurationer) som ska finnas på en delad diskyta. Fördelen med kluster är att det bidrar till att systemet får högre prestanda, tillgänglighet och kan skalas upp ytterligare.

Infinispan kommunicerar mellan noderna i klustret via UDP (multicast) eller TCP. Infinispan rekommenderar UDP för bäst prestanda. Förvalt vid installationen ges en multicastadress (239.0.10.1) men den lokala driftsorganisationen bör kontaktas för att bestämma vilken adress som ska användas. Mer information om multicast adresser hittar ni via följande länk: http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml. Väljer man TCP måste noderna i klustret anges i en statisk lista i konfigurationen (beskrivs närmare nedan).

3.8. Ciphersuites som används

Följande ciphersuties kan användas av en klient för att konsumera säkerhetstjänsters WS- och Webbgränssnitt:

Stöds bara i TLS 1.2
1. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
2. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
3. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
4. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
5. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
6. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
7. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
8. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
9. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
10. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
11. TLS_DHE_RSA_WITH_AES_256_CBC_SHA
12. TLS_DHE_RSA_WITH_AES_128_CBC_SHA
Stöds i TLS 1.0 och senare
13. TLS_RSA_WITH_AES_256_GCM_SHA384
14. TLS_RSA_WITH_AES_128_GCM_SHA256
15. TLS_RSA_WITH_AES_256_CBC_SHA256
16. TLS_RSA_WITH_AES_128_CBC_SHA256
17. TLS_RSA_WITH_AES_256_CBC_SHA
18. TLS_RSA_WITH_AES_128_CBC_SHA

3.9. Telnet

Installationen av Säkerhetstjänster kräver att man har en telnet-klient installerad på applikationsservrarna.

4. Säkerhetstjänsters beroenden till externa system

4.1. Behörighet externa system

Kommunikation med externa system sker alltid med mutual TLS vilket innebär att även den anropande tjänsten presenterar sig med ett certifikat. I vårdsverige är detta för detta certifikat ofta ett SITHS-certifikat.

Traditionellt har Säkerhetstjänster alltid använt front-end-certifikatet för huvud-domänen för extern kommunikation. När det inte längre är rekommenderat att använda SITHS-certifikat i front-end så går inte detta längre utan det blir WebService-certifikatet som måste användas.

Se alltså till att ange rätt certifikat vid beställning av accesser i NTjP och andra externa system.

HSA

Lokala Säkerhetstjänster har traditionellt använt HSA's äldre gränssnitt kallat HSA-WS. Detta gränssnitt är dock under avveckling och nya anslutningar tillåts därför inte. Som ny anslutning räknas även en befintlig installation som byter certifikat. Det är därför rekommenderat att man som ansvarig för en lokal installation av Säkerhetstjänster planerar en övergång till det nyare gränssnittet HSA-TK. Se nedan vilka av HSA's tjänstekontrakt man via Inera's elektroniska beställningsstöd måste ansöka om access till. Se även 2.17 Release Notes

4.2. HSA-WS

HSA-WS är under avveckling!

HSA-WS är en webbtjänsteanslutning till underliggande HSA-katalog. Lokala Säkerhetsjänster är kompatibelt med HSA-WS version 2.27 eller senare. Lokala Säkerhetstjänster ansluter sig till HSA-WS för att hämta information om användare, användares medarbetaruppdrag, vilka vårdenheter som tillhör en vårdgivare, namn på vårdenheter m.m. Applikationsserverns funktionscertifikat för legitimering behöver finnas i HSA-katalogen med behörighet att anropa följande operationer:

GetCareUnit
GetCareUnitList
GetHsaPerson
GetHsaUnit
GetMiuForPerson
Ping

För att en användare ska kunna autentisera sig krävs det att användaren finns upplagd i HSA-katalogen. Det finns dock inget krav på att användaren måste ha ett medarbetaruppdrag. Om användaren saknar medarbetaruppdrag kommer en ”tom” SAML-biljett att skapas, d.v.s utan egenskaper för användaren och det är upp till konsumenten av SAML-biljetten, SP:n, att avgöra vad som som då skall ske (t.ex. visa ett felmeddelande).

Notera: För att få behörigheterna till HSA-WS behöver man dels ha uppdaterat sin HPTA där ovanstående operationer finns med. Därefter får man skicka ett ärende till nationell kundservice med det HSA-id på det certifikat som säkerhetstjänster ska använda för att systemet ska få access till ovanstående operationer. Observera att dessa ärenden måste begäras av den/de som är HSA-ansvarig.

Adresser till HSA-WS:

Miljö	Adress
Test	https://wstest.hsa.sjunet.org/svr-hsaws2/hsaws
Produktion	https://ws.hsa.sjunet.org/svr-hsaws2/hsaws

4.3. HSA-RIVTA

Från och med version 2.15 finns möjlighet att använda sig av HSA-RIVTA kontrakt. Kontakta Inera för mer information om ni funderar över anslutning till HSA-RIVTA.

Patch krävs

För att kunna använda HSAs tjänstekontrakt via NTjP krävs en installation av en rättning

Behörighet att via NTjP anropa HSA-kontrakt via Nationella Tjänsteplattformen:

• GetEmployeeIncludingProtectedPerson
• GetCredentialsForPersonIncludingProtectedPerson
• GetHealthCareUnit
• GetHealthCareUnitList

4.4. Revokeringskontroll av certifikat

Applikationsservern för lokala Säkerhetstjänster använder i första hand OCSP och i andra hand CRL för att kontrollera om ett certifikat är spärrat och därmed inte godkänt för användning. Adressen till servrarna som används för OCSP och CRL hämtas från certifikaten och kan därför variera beroende på vilka certifikat som används. Dessa servrar måste kunna anropas från applikationsservern över HTTP (default port 80).

Exempel på adresser till crl och ocsp (Produktion):

Certifikat

CRL-adress

OCSP-adress

SITHS Type 1 CA v1

http://crl1.siths.se/sithsrootcav1.crl

http://crl2.siths.sjunet.org/sithsrootcav1.crl

http://ocsp1.siths.se/

http://ocsp2.siths.sjunet.org/

SITHS CA v3

SITHS CA v4

http://www.carelink.se/siths-ca/ca003.crl

http://sithsocsp.trust.telia.com/

Exempel på adresser till crl och ocsp (Test):

Certifikat

CRL-adress

OCSP-adress

SITHS_Type_1_CA_v1_PP

http://crl1pp.siths.se/sithsrootcav1pp.crl

http://crl2pp.siths.sjunet.org/sithsrootcav1pp.crl

http://ocsp1pp.siths.se/

http://ocsp2pp.siths.sjunet.org/

SITHS CA TEST v3

SITHS CA TEST v4

http://www.carelink.se/siths-ca/test-crl0003.crl

http://sithsocsp.preprod.trust.telia.com/

4.5. Personuppgiftstjänsten - Personuppgiftstjänsten

Personuppgiftstjänsten är en tjänst som innehåller personuppgifter. Lokala Säkerhetstjänster använder Personuppgiftstjänsten via NTjP för att hämta patienters namn i användargränssnittet.

Behörighet krävs för att via NTjP anropa följande metod:

GetPersonsForProfile v3

Adresser till Personuppgiftstjänsten via tjänsteplattformen:

Miljö	Adress
Test Sjunet	https://qa.esb.ntjp.sjunet.org:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21
Test Internet	https://qa.esb.ntjp.se:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21
Produktion Sjunet	https://esb.ntjp.sjunet.org:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21
Produktion Internet	https://esb.ntjp.se:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21

Uppgifter som matas in under Generell konfiguration → PU - V3 WS Proxy Impl 1.0.0

4.6. Nationell Spärrtjänst*

Den lokala Spärrtjänsten har inbyggd funktionalitet för synkronisering av spärrdata mot den nationella Spärrtjänsten. Innan replikeringen aktiveras måste förvaltningsorganisationen för nationell Spärrtjänst kontaktas för att öppna upp access till den nationella Spärrtjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].

Behörighet krävs för att via NTjP anropa följande metoder:

GetBlocks v4
RegisterBlock v4
UnregisterBlock v4
RegisterTemporaryRevoke v4
UnregisterTemporaryRevoke v4

Adresser spärreplikering:

Miljö	Adress
Test Sjunet	https://qa.esb.ntjp.sjunet.org:443/vp/informationsecurity/authorization/blocking
Test Internet	https://qa.esb.ntjp.se:443/vp/informationsecurity/authorization/blocking
Produktion Sjunet	https://esb.ntjp.sjunet.org:443/vp/informationsecurity/authorization/blocking
Produktion Internet	https://esb.ntjp.se:443/vp/informationsecurity/authorization/blocking

Uppgifter som matas in under Generell konfiguration → Block National V4 WS ProxyImpl for RIV 2.1 1.0.0.

Obs! Replikering av spärrar ska ske via tjänsteplattformen. För adresser/portar se kapitel Tjänsteplattformen nedan.Om det finns en existerande lokal installation av säkerhetstjänster och det inte är konfigurerat replikering via tjänsteplattformen, kan nedanstående adresser användas.

4.7. Nationell Loggtjänst*

Den lokala Loggtjänsten har inbyggd funktionalitet för att hämta hem den egna vårdgivarens PDL-loggar från den nationella Loggtjänsten via dess hämtningstjänst. Detta för att man lokalt ska kunna köra och få en loggrapport med loggar, både från de nationella systemen och ens lokala vårdsystem.

Innan hämtningstjänsten aktiveras måste förvaltningsorganisationen för nationell Loggtjänst kontaktas, för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].

Följande adresser används för hämtningstjänsten:

Miljö	Adress
Acceptanstest	https://ws.acctest.sakerhetstjanst.sjunet.org/
Produktion	https://ws.sakerhetstjanst.sjunet.org/

Tjänsterna Spärr och Samtycke behöver logga sina PDL-loggar till en loggtjänst. Detta kan vara en lokal Loggtjänst eller den nationella Loggtjänsten via tjänsteplattformen. För adresser/portar se avsnitt Tjänsteplattformen nedan.

Väljer man att använda den nationella Loggtjänsten, måste förvaltningsorganisationen för nationell Loggtjänst kontaktas för att öppna upp access till tjänsten samt konfigurera vilka vårdgivare som denna lokala Loggtjänst tillåts hantera nationellt. Hur detta görs beskrivs senare i dokumentet.
Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].

*Nationell Loggtjänst kan användas om någon av tjänsterna Spärr, Samtycke eller Logg installeras.

4.8. Tjänsteplattformen*

Installeras Samtyckestjänsten måste den lokala Säkerhetstjänsten registreras som producent i tjänsteplattformen. Detta för att samverkan ska kunna ske med de nationella tjänsterna. T ex en nationell tjänst som vill läsa från den lokala instansen, ifall ett samtycke finns registrerat.

Figuren nedan illustrerar hur en läsande nationell tjänst routas via den nationella tjänsteplattformen, genom en lokal tjänsteplattform (valfri) för att till sist hamna i den lokala Samtyckestjänsten.

Figur: Principer för samverkande tjänster för hantering av samtycke

Installeras någon av tjänsterna Spärr och Samtycke och konfigureras för att logga PDL-loggar till den nationella Loggtjänsten, måste de lokala Säkerhetstjänsterna registreras som konsument i tjänsteplattformen.

Tjänsten Spärr replikerar sina spärrar till den nationella Spärrtjänsten via tjänsteplattformen, vilket gör att den måste registreras som konsument i tjänsteplattformen.

Kontakta Ineras förvaltning i god tid före driftstart för att registrera tjänsterna i tjänsteplattformen [Ref 1].

Adresser till Tjänsteplattformen:

Miljö	Hostnamn	IP-adress	port	contextpath
QA-Sjunet	qa.esb.ntjp.sjunet.org	82.136.149.53	443	/vp
Produktion-Sjunet	esb.ntjp.sjunet.org	82.136.149.61	443	/vp

*Tjänsteplattformen kan användas om någon av tjänsterna Spärr, Samtycke och Logg har installerats.

5. Systemöversikt

Detta kapitel beskriver hur systemet sätts upp med maskiner och nätverksstruktur.

5.1. Ingående servrar

Lokala Säkerhetstjänster kan bestå av en eller flera applikationsservrar, en MySQL databasserver och en MongoDB databasserver beroende på vilka tjänster som ska installeras. Databasservrarna kan/bör även sättas upp på flera maskiner i ett kluster med någon typ av 'fail-over' lösning. På applikationsservern installeras en gemensam plattform. På plattformen kan man välja vilka av de fristående tjänsterna Spärr, Samtycke, Autentisering (IdP) och Logg som ska installeras.

Lokala Säkerhetstjänster kan konfigureras på två grundläggande sätt, med en nod eller flera noder i ett kluster. Vår rekommendation är att installera i ett kluster med två maskiner men flera går också bra. Säkerhetstjänsterna installerat i ett kluster ger en typ av active-active 'fail-over' då det ökar tillgängligheten och kapaciteten på systemet. För att kunna köra i ett kluster av noder krävs att alla noder har tillgång till en delad diskyta.

En lastbalanserare används för att dirigera trafiken till alla applikationsservrar (genom t.ex. round-robin). SSL-sessioner delas mellan applikationsservrarna, lastbalansering kan därför ske till vilken nod som helst. Om fel uppstår på någon av applikationsservrarna dirigeras trafiken bort från den felaktiga servern till de övriga applikationsservrarna. Alla maskiner i klustret bör vara identiska.

För hanteringen med att dela SSL-sessioner och andra objekt mellan applikationsservrarna är produkten Infinispan integrererat i systemet. Infinispan är en distribuerad cache-lösning som Säkerhetstjänsten använder för att kunna dela data mellan noderna. Det är konfigurerat att kommunicera med UDP och multicast eller TCP för att hitta alla noder i ett kluster.

Singelnodlösningen består av en applikationsserver, en MySQL databasserver och eventuellt en MongoDB databasserver, upp till totalt tre stycken maskiner.
För en installation av ett kluster tillkommer alltså ytterligare maskiner.

Figuren nedan visar ett exempel på en klustrad lösning.

Figur: Systemöversikt av Säkerhetstjänster installerat med en kluster lösning.

5.2. Exempelinstallation och konfiguration

5.2.1. Lokala Säkerhetstjänster installerade med Spärr och Autentisering

Bilden nedan visar en installation av lokal Spärrtjänst och Autentiseringstjänst. Spärreplikeringen till den nationella Spärrtjänsten sker via tjänsteplattformen, även Spärrtjänstens PDL-loggning går via tjänsteplattformen till den nationella Loggtjänsten. Detta kräver att den lokala Spärrtjänsten registreras som en konsument i tjänsteplattformen. Logguppföljning på händelser i den lokala Spärrtjänsten, måste i detta fall göras i den nationella Loggtjänsten. För att slå upp namn på patienter, använder Spärrtjänsten Personuppgiftstjänsten. HSA och Revokeringskontroll används av alla tjänster i lokala Säkerhetstjänster.

Figur: Lokala Säkerhetstjänster med Spärr och Autentisering installerade.

5.2.2. Lokala Säkerhetstjänster installerade med alla tjänster

Bilden nedan visar en installation där samtliga tjänster (Spärr, Samtycke, Logg och Autentisering) finns installerade lokalt. Spärreplikeringen till den nationella Spärrtjänsten sker via tjänsteplattformen, vilket kräver att den lokala Spärrtjänsten finns registrerad som konsument i tjänsteplattformen. Samtycke behöver registreras i tjänsteplattformen som producenter för att nationella system, t.ex. NPÖ, ska kunna registrera samtycken i rätt tjänst (via tjänsteplattformen).

Spärr, Samtycke och PDL-loggar till den lokala Loggtjänsten. Den lokala Loggtjänsten hämtar även hem de PDL-loggar som finns i den nationella Loggtjänsten via dess hämtningstjänst. För att slå upp namn på patienter används Personuppgiftstjänsten. HSA och Revokeringskontroll används av samtliga tjänster.

Figur: Lokala Säkerhetstjänster med alla tjänster installerade.

5.3. Översikt adresser och portar

Säkerhetstjänster är uppdelat i flera olika tjänster/delar. I tidigare versioner av Säkerhetstjänster har man anslutit till dessa tjänster via en och samma ip-adress med unika portnummer som identifierade tjänsterna (vi kallar i detta dokument denna konfiguration för 8443 ports). Från version 2.7 av den Lokala Säkerhetstjänsten kan man även använda SSL standardport 443 för samtliga tjänster men då krävs det att varje tjänst tilldelas en egen ip-adress (vi kallar i detta dokument denna konfiguration för 443 ports). För att kunna använda standardport 443 för alla tjänster måste dessa ip-adresser mappas i lastbalanseraren mot applikationsserverns interna portar som fortfarande måste vara unika för tjänsterna. Skillnaderna beskrivs av tabellen nedan. De interna portarna i tabellen avser föreslagen port men konfigureras manuellt vid installation. Dessa ska vid 443-port-konfiguration inte öppnas för extern åtkomst utan enbart vara åtkomlig från lastbalanseraren.

Det är alltså möjligt att konfigurera Säkerhetstjänster på båda dessa sätt och det är viktigt att vid installationen tänka på att ange samma port för interna och publika portar om man vill konfigurera med 8443-ports och port 443 som publika portar om man vill konfigurera med SSL Standard port 443.

SSL Standartport 443

Tänk också på att om man väljer en konfiguration med standardport 443 för alla tjänster och därmed flera olika URL:er så krävs det ett unikt certifikat per URL eller ett wildcard certifikat.

Tänk också på att för IdP-adresserna så måste secure.idp-adressen vara en underdomän till idp-adressen.

Publik adress (443 ports)	Publik adress (8443 ports)	Intern adress (internal ports)
https://ws.<Hostnamn-Applikationsserver>:443	https://<Hostnamn-Applikationsserver>:8080	https://<Hostnamn-Applikationsserver>:8080
https://secure.idp.<Hostnamn-Applikationsserver>:443	https://<Hostnamn-Applikationsserver>:8444	https://<Hostnamn-Applikationsserver>:8444
https://*idp.<Hostnamn-Applikationsserver*>:443	https://<Hostnamn-Applikationsserver>:8445	https://<Hostnamn-Applikationsserver>:8445
https://cd.<Hostnamn-Applikationsserver>:443	https://<Hostnamn-Applikationsserver>:8446	https://<Hostnamn-Applikationsserver>:8446
https://<Hostnamn-Applikationsserver>:443	https://<Hostnamn-Applikationsserver>:8443	https://<Hostnamn-Applikationsserver>:8443

5.3.1. Applikationsserver

Denna tabell visar vilka portöppningar som krävs för att lokala Säkerhetstjänster skall fungera. Portar i tabellen avser föreslagen port, men dessa konfigureras manuellt vid installation. In betyder inkommande trafik och Ut utgående trafik.

Server	Port	Beskrivning
Applikationsserver	8443 (in)	HTTPS (envägs-SSL, generellt administrationsgränssnitt). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration.
	8444 (in)	HTTPS (tvåvägs-SSL, IdP-webbgränssnitt för identifiera användare med certifikat t.ex. SITHS). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration. *Används endast vid installation av lokal IdP
	8445 (in)	HTTPS (envägs-SSL, IdP-webbgränssnitt med bla.val av identifikationsmetod och SSO). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration. *Används endast vid installation av lokal IdP
	8446 (in)	HTTPS (envägs-SSL, IdP-webbgränssnitt för CDC-hantering). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration.
	8080 (in)	HTTPS (tvåvägs-SSL, WebServices, t.ex.CheckBlocks). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration.
	8004 (in)	Java JMX-övervakning, behöver ej öppnas om inte övervakning används. Ska ej öppnas för extern åtkomst.
	1111 (in)	Telnet-port för systemkonsol. Ska ej öppnas för extern åtkomst.
	443 (in)	HTTPS för samtliga externa tjänster vid 443 port-konfiguration. Ska ej öppnas för extern åtkomst vid 8443 ports-konfiguration.
	443 (ut)	HTTPS-anrop till HSA, Personuppgiftstjänsten, replikering till nationell hämtningstjänst för loggar samt intern kommunikation med lastbalanseraren för routing.
	80 (ut)	Porten används av systemet för slagningar mot OCSP- och CRL-kontroll för verifiering av certifikat på exempelvis SITHS-certifikat. Använder man andra certifikat än SITHS kan andra portar vara aktuella för OCSP/CRL.
	3306 (ut)	Anrop till MySQL-databasservern.
	27017 (ut)	Anrop till MongoDB-databasservern
	443 (ut)	Anrop till tjänsteplattformen

5.3.2. Databasserver

Databasserver	Port	Beskrivning
MySQL	3306 (in)	Anslutningsport till MySQL-databas. Används av applikationsservern. Ska ej öppnas för extern åtkomst utan enbart vara åtkomlig ifrån applikationsservrarna.
MongoDB	27017 (in/ut)	Anslutningsport till MongoDB-Används av applikationsservern, samt i MongoDB Replica set. Ska ej öppnas för extern åtkomst utan enbart vara åtkomlig ifrån applikationsservrarna samt de andra MongoDB-noderna.
MongoDB (Arbiter)	30000 (in/ut)	Används av arbiters i Replica set. Ska ej öppnas för extern åtkomst utan endast vara öppen internt för de andra MongoDB-noderna.

5.4. Adressöversikt gränssnitt

Tabellen nedan visar adresser/URL:er till de webbgränssnitt som Säkerhetstjänsterna erbjuder och som kan användas av användare av den lokala Säkerhetstjänsten. Se respektive tjänstekontraktsbeskrivning för detaljerad beskrivning av tjänsterna och dess användning. Spärr, Samtycke och Logg är RIV TA 2.1 tjänster, se vidare http://www.rivta.se.

5.4.1. Webbgränssnitt admin-GUI

Prefix (443 ports)	Prefix (8443 ports)	Adress	Beskrivning
*https://<Hostnamn-Applikationsserver>/*	*https://<Hostnamn-Applikationsserver>:8443/*	block blocklocal	GUI för Spärr
		commonarchive	GUI för Arkivering
		consentpdl	GUI för Samtycke
		idpadmin statistics	GUI för Autentisering
		javamelody systemlog job	GUI för Övervakning
		logreportarchive	GUI för Arkivsökning
		logreport logreportnational	GUI för Loggrapport
		logstatusservice	GUI för Logg
		spinfo	GUI för Hjälp
		sysadmin spadmin accesscontrol	GUI för Administration
		general	GUI för felmeddelanden

5.4.2. Webbgränssnitt Autentiseringstjänsten

Prefix (443 ports)	Prefix (8443 ports)	Adress	Beskrivning
*https://idp.<Hostnamn-Applikationsserver>/*	*https://<Hostnamn-Applikationsserver>:8445/*	idp/saml/sso/{binding}	Autentiseringstjänst (IdP) SSO
		idp/saml/slo/{binding}	Autentiseringstjänst (IdP) SLO
		idp/saml	Metadata IdP

5.4.3. Webbtjänstegränssnitt för autentisering rika klienter - STS

Prefix (443 ports)	Prefix (8443 ports)	Adress	Beskrivning
*https://ws.<Hostnamn-Applikationsserver>/*	*https://<Hostnamn-Applikationsserver>:8080/*	ws/idp/sts	Autentiseringstjänst (STS) 2 vägs-SSL
*https://idp.<Hostnamn-Applikationsserver>/*	https://<Hostnamn-Applikationsserver>:8445/	ws/idp/sts	Autentiseringstjänst (STS) 1 vägs-SSL (meddelandesignering)

5.4.4. Webbtjänstegränssnitt WS-port - RIV TA-tjänster och REST-tjänst

Alla adresser för webbtjänstegränssnitt har följande prefix:

Prefix (443 ports)	Prefix (8443 ports)
*https://ws.<Hostnamn-Applikationsserver>/*	*https://<Hostnamn-Applikationsserver>:8080/*

Spärr version 2.0 RIV TA 2.1
blockingLocalService/DeleteExtendedBlock/2/rivtabp21
blockingLocalService/CancelTemporaryExtendedRevoke/2/rivtabp21
blockingLocalService/RegisterTemporaryExtendedRevoke/2/rivtabp21
blockingLocalService/RevokeExtendedBlock/2/rivtabp21
blockingLocalService/RegisterExtendedBlock/2/rivtabp21
blockingLocalService/GetExtendedBlocksForPatient/2/rivtabp21
blockingLocalService/GetPatientIds/2/rivtabp21
blockingLocalService/GetAllBlocks/2/rivtabp21
blockingLocalService/GetAllBlocksForPatient/2/rivtabp21
blockingLocalService/GetBlocksForPatient/2/rivtabp21
blockingLocalService/GetBlocks/2/rivtabp21
blockingLocalService/CheckBlocks/2/rivtabp21
blockingLocalService/PingForConfiguration/2/rivtabp21

Spärr version 3.0 RIV TA 2.1
blockingLocalService/CheckBlocks/3/rivtabp21
blockingLocalService3/PingForConfiguration/1/rivtabp21

Spärr version 4.0 RIV TA 2.1
blockingLocalService/PingForConfiguration/4/rivtabp21
blockingLocalService/DeleteExtendedBlock/4/rivtabp21
blockingLocalService/CancelTemporaryExtendedRevoke/4/rivtabp21
blockingLocalService/RegisterTemporaryExtendedRevoke/4/rivtabp21
blockingLocalService/RevokeExtendedBlock/4/rivtabp21
blockingLocalService/RegisterExtendedBlock/4/rivtabp21
blockingLocalService/GetExtendedBlocksForPatient/4/rivtabp21
blockingLocalService/GetPatientIds/4/rivtabp21
blockingLocalService/GetBlocks/4/rivtabp21
blockingLocalService/CheckBlocks/4/rivtabp21

Samtycke version 1.0 RIV TA 2.1
consentService/PingForConfiguration/1/rivtabp21
consentService/GetConsentsForCareProvider/1/rivtabp21
consentService/GetConsentsForPatient/1/rivtabp21
consentService/DeleteExtendedConsent/1/rivtabp21
consentService/CancelExtendedConsent/1/rivtabp21
consentService/RegisterExtendedConsent/1/rivtabp21
consentService/GetExtendedConsentsForPatient/1/rivtabp21
consentService/CheckConsent/1/rivtabp21

Samtycke version 2.0 RIV TA 2.1
consentService/PingForConfiguration/2/rivtabp21
consentService/CheckConsent/2/rivtabp21
consentService/DeleteExtendedConsent/2/rivtabp21
consentService/CancelExtendedConsent/2/rivtabp21
consentService/RegisterExtendedConsent/2/rivtabp21
consentService/GetExtendedConsentsForPatient/2/rivtabp21
consentService/GetConsentsForCareProvider/2/rivtabp21
consentService/GetConsentsForPatient/2/rivtabp21

Logg version 1 RIV TA 2.1
logService/PingForConfiguration/1/rivtabp21
logService/StoreLog/1/rivtabp21
logQueryingService/PingForConfiguration/1/rivtabp21
logQueryingService/GetInfoLogsForPatient/1/rivtabp21
logQueryingService/GetInfoLogsForCareProvider/1/rivtabp21
logQueryingService/GetAccessLogsForPatient/1/rivtabp21
logQueryingService/GetLogsForPatient/1/rivtabp21
logQueryingService/GetLogsForUser/1/rivtabp21
logQueryingService/GetLogsForCareProvider/1/rivtabp21
logReportServiceInternal/IsMaintenanceOngoingInternal/1/rivtabp21
logReportServiceInternal/GetLogReportsInfo/1/rivtabp21
logReportServiceInternal/GetAggregatedLogsForPatientInternal/1/rivtabp21
logReportServiceInternal/GetAggregatedLogsForUserInternal/1/rivtabp21
logReportServiceInternal/GetAggregatedLogsForCareProviderInternal/1/rivtabp21
logReportServiceInternal/GetLogsInternal/1/rivtabp21
logReportServiceInternal/GetLogProducersByCareProviderInternal/1/rivtabp21

Logg version 2 RIV TA 2.1
logService/PingForConfiguration/2/rivtabp21
logService/StoreLog/2/rivtabp21
logReportService/PingForConfiguration/2/rivtabp21
logReportService/GetLogs/2/rivtabp21
logReportService/GetInfoLogs/2/rivtabp21
logReportService/GetAccessLogsForPatient/2/rivtabp21

CommissionService version 1 RIV TA 2.1
commissionService/GetCommissionsForPerson/1/rivtabp21
commissionService/SetSelectedCommissionForPerson/1/rivtabp21
commissionService/PingForConfiguration/1/rivtabp21

Adress till REST-tjänst för att söka och ladda ner loggarkiv från Säkerhetstjänster (hämtningstjänst).

Loggarkiv hämtningstjänst
logdownload_v2/archives

Dokumentet Hämta loggarkiv 2.0 är en bilaga till tjänstekontraktet för logg. Det beskriver REST-tjänsten och hur hämta arkiv fungerar med parametrar osv.

6. Installation av databasserver

Det är av prestandaskäl rekommenderat att tilldela lokala Säkerhetstjänsters databasservrar egna fysiska maskiner.

6.1. Installera MySQL

OBS: Som tidigare nämnts så rekommenderas det att installera den senaste versionen av 5.6-serien (5.6.37).

MySQL har officiella installationsanvisningar här:

http://dev.mysql.com/doc/refman/5.6/en/installing.html

För utökad support och funktionalitet såsom online-backup finns samma version i Enterprise Edition-utförande som dock inte är kostnadsfri. Mer information om detta finns här: http://www.mysql.com/products/enterprise. Rekommenderbart är att nyttja en High Availability lösning.
Mer information om detta finns här: https://dev.mysql.com/doc/refman/5.6/en/ha-overview.html

Den MySQL-användare som används vid installationen kräver behörighet att ändra, uppdatera och lägga till nya tabeller i de scheman som skapas för systemet.

6.1.1. Specifika MySQL-inställningar

6.1.1.1. Teckenuppsättning

Default-installation av MySQL använder teckenuppsättningen latin1. Detta måste ändras till UTF-8 för att svenska tecken ska användas korrekt. I katalogen <Lokal_sakerhetstjanst>\db\example\ finns ett exempel på en MySQL-konfigurationsfil (anpassad för Linux) där teckenuppsättningen är ändrad till UTF-8, och även lite generella inställningar man kan använda för att få upp prestandan på MySQL. Dessa generella Inställningar kan man även lägga in i konfigurationsfilen för Windows (observera att det inte finns någon exempel-fil för Windows). Nedan visas dessa inställningar som behöver ändras i filen my.cnf i Linux-installationen och i filen my.ini i Windows.

Vi hänvisar till konfigurationsfilen för MySQL i exemplen nedan, för både Linux och Windows, då både Windows och Linux anvisningarna delar på denna information.

Exempel Linux: /etc/my.cnf

Exempel Windows: C:\ProgramData\MySQL\MySQL Server 5.6\my.ini

Observera: Att man måste aktivera valet "Show hidden files, folders, and drives" under Folder options för att kunna se katalogen C:\ProgramData

# Set default character sets to use UTF-8
init_connect='SET collation_connection = utf8_general_ci; SET NAMES utf8;'
character-set-server=utf8
character-set-client=utf8
collation-server=utf8_general_ci
skip-character-set-client-handshake

6.1.1.2. Minnestilldelning "innodb_buffer_pool_size"

För att minska diskaccess bör denna sättas upp till 4-8 GB RAM-tillgång. Upp till 80% av maskinens minnesstorlek på en dedikerad databasmaskin säger MySQL-dokumentationen.

Sätts i konfigurationsfilen (my.cnf på Linux och my.ini på Windows)

# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes...
innodb_buffer_pool_size = 6G

6.1.1.3. Binary logging "binlog_format"

Sätts till ROW för Säkerhetstjänster.

Sätts i konfigurationsfilen (my.cnf på Linux och my.ini på Windows)

# binary logging format
binlog_format=ROW

6.1.1.4. InnoDB Tablespace "innodb_file_per_table"

Default för senare versioner av MySQL (från 5.6.x) är att tabeller och index skrivs till en fil per schema istället för en enda stor fil.

För detta i tidigare versioner av MySQL, lägg till följande bland övriga innodb-parametrar i konfigurationsfilen (my.cnf på Linux och my.ini på Windows)

# Use one file per table
innodb_file_per_table

OBS! Har man ett befintligt system utan denna parameter kan man inte bara ändra utan att först dumpa ut all data och sedan läsa in den igen efter att detta ändrats (beskrivs inte i detta dokument). Denna inställning är dock inte tvingande så man kan i detta läge fortsätta utan denna inställning.

6.1.2. Skapa användare som applikationsservern ska använda

Skapa en användare i MySQL som har behörighet att ändra, uppdatera och lägga till nya tabeller i de scheman som skapas för systemet.
Det behövs två användare:

# sak@localhost : användaren sak kan enbart ansluta från ”localhost”.

# sak@% : användaren sak kan ansluta från ”any hosts”

Användarna behöver inte ha behörighet för att kunna skapa nya scheman.

OBS! Att tillåta att en användare kan ansluta från "any hosts" bör endast användas i en testmiljö. För en produktionsmiljö bör användningen låsas ytterligare, så att det bara är applikationsserverna som kan ansluta till databasservern.

OBS! För att skapa scheman krävs en användare som har root-rättigheter, vilket skapades upp under installationen av MySQL.

Starta ett terminal-fönster mot databasservern och skriv följande kommando:
```
mysql -u root -p
```
Ange det lösenord som angavs vid installationen.

Skapa ny användare (i detta exempel är användarnamnet sak vilket rekommenderas, samt ett lösenord) genom att skriva följande tre kommandon:

CREATE USER 'sak'@'localhost' IDENTIFIED BY 'password';
GRANT CREATE, DROP, EVENT, DELETE, INDEX, INSERT, SELECT, UPDATE, CREATE TEMPORARY TABLES, LOCK TABLES, TRIGGER, CREATE VIEW, SHOW VIEW, EXECUTE ON  *.* TO 'sak'@'localhost';
FLUSH PRIVILEGES;

Skapa ny användare (i detta exempel är användarnamnet sak vilket rekommenderas, samt ett lösenord) genom att skriva följande tre kommandon:

CREATE USER 'sak'@'%' IDENTIFIED BY 'password';
GRANT CREATE, DROP, EVENT, DELETE, INDEX, INSERT, SELECT, UPDATE, CREATE TEMPORARY TABLES, LOCK TABLES, TRIGGER, CREATE VIEW, SHOW VIEW, EXECUTE ON  *.* TO 'sak'@'%';
FLUSH PRIVILEGES;

Avsluta MySQL prompten med kommando:
```
quit
```

6.1.3. Skapa upp databasscheman

När databasanvändare har skapats, ska databasscheman som lokala Säkerhetstjänster använder skapas upp. I installationspaketet (under strukturen <Lokal_sakerhetstjanst>\db\mysql\) ligger samtliga databasscheman som behöver sättas upp.

Tabellen nedan visar vilka skript som tillhör de databasscheman som kommer sättas upp i nästkommande steg.

Schema	Skript
accesscontrol	accesscontrol.sql accesscontrol_data.sql
audit	audit.sql
blkloc	blkloc.sql
commission	commission_service.sql
consent	consent.sql
idp	idp.sql idp_data.sql
inftyp	inftyp.sql inftyp_data.sql
job	quartz.sql
logdb	logdb.sql
logreport	logreport.sql logreport_data.sql
logreportarchive	logreportarchive.sql logreportarchive_data.sql
logdlarchive	logdlarchive.sql
metadata	metadata.sql
sinkdb1	sinkdb1.sql
sp	sp.sql sp_data.sql

Skapa upp databaser:

Kopiera samtliga filer som finns i katalogen /Lokal_sakerhetstjanst/db/mysql/ till valfri katalog på er MySQL-server.
Gå till katalogen dit filerna kopierades;
```
Exempel: 
cd /tmp/mysql
```
Lista innehållet i katalogen och verifiera att alla skripten som tabellen ovan refererar till, finns i katalogen. Utöver de skript som listas i tabellen, ska skriptet create_databases_linux.sh finnas.

Ge skriptet create_databases_linux.sh exekveringsrättigheter (skriptet används för att att skapa upp scheman automatiskt). Lista innehållet i katalogen och säkerställ att create_databases_linux.sh har fått exekveringsbehörigheter. Se exempelbilden nedan.

Exempel:
 
[root@db1 mysql]# chmod +x create_databases_linux.sh
[root@db1 mysql]# ls -la
total 294
-rwxr-xr-x 1 root root 33655 Sep  6 10:39 accesscontrol_data.sql
-rwxr-xr-x 1 root root  1593 Sep  6 10:39 accesscontrol.sql
-rwxr-xr-x 1 root root  1665 Sep  6 10:39 audit.sql
-rwxr-xr-x 1 root root  7917 Sep  6 10:39 blkloc.sql
-rwxr-xr-x 1 root root   441 Sep  6 10:39 commission_service.sql
-rwxr-xr-x 1 root root  3920 Sep  6 10:39 consent.sql
-rwxr-xr-x 1 root root  8786 Sep  6 10:39 create_databases_linux.sh
-rwxr-xr-x 1 root root  5344 Sep  6 10:39 idp_data.sql
-rwxr-xr-x 1 root root 64649 Sep  6 10:39 idp.sql
-rwxr-xr-x 1 root root   934 Sep  6 10:39 inftyp_data.sql
-rwxr-xr-x 1 root root   408 Sep  6 10:39 inftyp.sql
-rwxr-xr-x 1 root root  2768 Sep  6 10:39 logdb.sql
-rwxr-xr-x 1 root root   591 Sep  6 10:39 logdlarchive.sql
-rwxr-xr-x 1 root root  1644 Sep  6 10:39 logreportarchive_data.sql
-rwxr-xr-x 1 root root  1516 Sep  6 10:39 logreportarchive.sql
-rwxr-xr-x 1 root root  9792 Sep  6 10:39 logreport_data.sql
-rwxr-xr-x 1 root root  2354 Sep  6 10:39 logreport.sql
-rwxr-xr-x 1 root root 62304 Sep  6 10:39 metadata.sql
-rwxr-xr-x 1 root root  7051 Sep  6 10:39 quartz.sql
-rwxr-xr-x 1 root root  2924 Sep  6 10:39 sinkdb1.sql
-rwxr-xr-x 1 root root   582 Sep  6 10:39 sp_data.sql
-rwxr-xr-x 1 root root 62112 Sep  6 10:39 sp.sql
[root@db1 mysql]#

Samtliga skript för databasscheman som ska skapas upp

Kör skriptet create_databases_linux.sh med följande parametrar:
- Målmiljö - Den databasserver som skall användas
- Användarnamn – det användarnamn som används till databasmiljön med root-rättigheter.
- Prefix – ej obligatoriskt. Ett prefix till tabellnamnet kan anges om så önskas. I exempelbilden nedan har vi angivit ”example_” som prefix.
  - Om prefix anges kommer namnet på scheman att få följande utseende:
    example_accesskontrol
    example_audit
    osv...
```
Exempel: 
./create_databases_linux.sh localhost root example_
```

När skriptet körs kommer en fråga om ni vill fortsätta att skapa upp scheman. Ange ”y” för att fortsätta med exekveringen, därefter anger man databasanvändarens lösenord.
OBS! Alla scheman kommer att tas bort och skapas igen så all befintlig data kommer att raderas.

Exempel:
 
[root@db2 mysql]# ./create_databases_linux.sh localhost root example_

Create MySQL databases for Lokala Sakerhetstjansten.

*NOTE* that by running this script all tables will be recreated and all existing data will be lost!!!

Do you really want to recreate these databases:
example_accesscontrol
example_audit
example_blkloc
example_commission
example_consent
example_idp
example_inftyp
example_job
example_logdb
example_logdlarchive
example_logreportarchive
example_logreport
example_metadata
example_sinkdb1
example_sp

DO YOU WANT TO CONTINUE?(y/n)
y
Enter password:

Creating schema "example_accesscontrol"...
...drop and recreate schema example_accesscontrol successful
...reading accesscontrol.sql successful
...database  "example_accesscontrol" created
Creating schema "example_audit"...
...drop and recreate schema example_audit successful
...reading audit.sql successful
...database  "example_audit" created
osv...
osv...
osv...

DONE

[root@db2 mysql]#

Skapa upp scheman

Om inget fel uppstod kommer meddelandet DONE att visas. Verifiera att scheman har skapats genom att logga in i mysql-prompten och exekvera följande:

Exempel: 
 
[root@db1 mysql]# mysql -u<username> -p<password>
mysql> show databases;
+---------------------------+
| Database                  |
+---------------------------+
| example_accesscontrol     |
| example_audit             |
| osv...                    |
| osv...                    |
+---------------------------+

Lista scheman

För att kontrollera om det finns tabeller i ett schema kan man gå in i schemat (t.ex.accesscontrol) och ange kommandot:

Exempel: 

mysql> use accesscontrol;
Database changed
mysql> show tables;
+-----------------------------+
| Tables_in_accesscontrol     |
+-----------------------------+
| action_resource             |
| action_resource__attributes |
| attribute 				  |
| data_template               |
+-----------------------------+
3 rows in set (0.00 sec)

Lista tabeller

6.2. Installera MongoDB

Här följer ett exempel på installation av databasen MongoDB för Säkerhetstjänster 2.17.

MongoDB har officiella installationsanvisningar för Linux här: http://docs.mongodb.org/manual/tutorial/install-mongodb-on-linux/

Paket

MongoDB tillhandahåller officiella paket vilka innehåller följande:

mongodb-org: Ett "meta-paket" som installerar nedanstående paket automatiskt.
mongodb-org-server: Innehåller "mongod deamon" samt konfiguration + init-skript.
mongodb-org-mongos: Innehåller "mongos deamon".
mongodb-org-shell: Innehåller "mongo shell".
mongodb-org-tools: Innehåller "mongoDB tools".

MongoDB 3.4 med engine WiredTiger på Linux (Redhat/Centos 7.x) rekommenderar man att använda filsystemet xfs, för bättre prestanda.

Konfigurationsfilen (/etc/mongo.conf) är baserad på YAML. Observera att YAML inte stödjer tab tecken.

6.2.1. MongoDB på en eller tre noder

Nedan följer installationsexempel för MongoDB med replikering samt singelnod. I det första fallet innebär det att installationen kommer att använda tre noder kallade Primary, Secondary och Arbiter. Att installera MongoDB på tre noder har två syften:

Prestanda
Tillgänglighet

I konfigurationen som följer efter installationen utser man vilka noder som ska ingå i uppsättningen. Vilka noder som ska vara datanoder och vilken av dessa som data ska läsas ifrån. Noden som har rollen Primary är den nod som data skrivs till. Arbitern bedömer vilken av noderna som ska fungera som Primary och vilken/vilka som ska fungera som Secondary.

Arbitern kan med fördel installeras på applikationsservern. Säkerhetstjänster kommer att begära att få läsa ifrån en Secondary-nod. Detta ökar prestandan avsevärt under hanteringen av verksamhetsloggar, då en nod hanterar alla inkommande loggar och läsning kan ske från en annan nod. Med rollen som ”domare” kan Arbitern sedan bestämma om noderna Primary och Secondary ska byta roller vid detekterade problem.

Det går även att sätta upp installationen på en nod, en så kallad singlenodinstallation, men av prestanda- och redundansskäl rekommenderar vi att ovan beskriven trenodsinstallation används.

6.3. Installera MongoDB 3.4.x

Skapa en ny fil i /etc/yum.repos.d med namnet mongodb-org-3.4.repo med följande innehåll:

[mongodb-org-3.4]
name=MongoDB Repository
baseurl=https://repo.mongodb.org/yum/redhat/$releasever/mongodb-org/3.4/x86_64/
gpgcheck=0
enabled=1

Installera med hjälp av yum på alla noder.
```
yum install -y mongodb-org
```
Skapa en katalogstruktur på alla data-noderna (PRIMARY och SECONDARY's) och sätt rättigheter (Avvakta med ARBITER-noden så länge)
```
mkdir /mongodb/data
chown mongod /mongodb/data
chgrp mongod /mongodb/data
chmod -R 775 /mongodb/*
```

Konfigurera data-noderna (ej ARBITER-noden) genom att editera /etc/mongo.conf

# Ändra dbpath:
dbpath=/mongodb/data

# Lägg till replSetName
replication:
   replSetName: rs_sak
 
# Kommentera bort bindIp
#  bindIp: 127.0.0.1

Starta mongo server på alla data-noder, samt enabla automatisk uppstart av mongod-service (avvakta Arbiter-noden)
```
systemctl start mongod
systemctl enable mongod
```
Starta mongo-klienten på ena noden (PRIMARY-noden)
```
[root@db1 mongodb]# mongo
```
MongoDB shell version v3.4.x
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.x
Server has startup warnings:
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten]
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten]
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten]
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten]
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2016-12-29T13:12:36.211+0100 I CONTROL [initandlisten]
```
- Varnar klienten för 'startup warnings' (se bild ovan). Kan man ändra till rekommenderade värden på transparent_hugepage genom att lägga till (se punkt nedan) nedanstående rader i /etc/rc.local.
```
```
Mer att läsa på:
http://docs.mongodb.org/manual/reference/transparent-huge-pages/
```

vim /etc/rc.local

# Lägg till:

if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
echo never > /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
echo never > /sys/kernel/mm/transparent_hugepage/defrag
fi

Exekvera kommandot:
```
source /etc/rc.local
```
Starta om mongoDB-server på datanoderna:
```
systemctl start mongod
```
Starta mongo-klienten:

[root@db1 mongodb]# mongo
MongoDB shell version v3.4.x
connecting to: mongodb://127.0.0.1:27017
MongoDB server version: 3.4.x
Server has startup warnings:
2016-12-29T13:14:29.464+0100 I CONTROL  [initandlisten]
2016-12-29T13:14:29.464+0100 I CONTROL  [initandlisten] ** WARNING: Access control is not enabled for the database.
2016-12-29T13:14:29.464+0100 I CONTROL  [initandlisten] **          Read and write access to data and configuration is unrestricted.
2016-12-29T13:14:29.464+0100 I CONTROL  [initandlisten]

::::::::::::::::::::::::::::::::::::::
Startup warningen ovan beror på att autentiseringen ej är konfigurerad, det kommer senare, så ignorera denna så länge.

6.3.1.1. Konfigurera replikeringen på ena noden (den som skall vara PRIMARY från start).

Initiera replikering
```
rs.initiate()
```
Visa replikeringsinformation
```
rs.status()
```
Noden ovan kommer automatiskt bli medlem i klustret.
Lägg nu till en andra datanod så att vi får en medlem som kan agera SECONDARY
```
rs.add("mongodb2.example.com")
```

Logga in på ARBITER-noden och skapa en katalogstruktur för konfiguration:

mkdir /mongodb/data
mkdir /mongodb/data/arb
chown mongod /mongodb/data/arb
chgrp mongod /mongodb/data/arb

Konfigurera ARBITER-noden genom att editera /etc/mongo.conf

# Ändra dbpath
dbpath=/mongodb/data/arb

# Lägg till replSetName
replication:
   replSetName: rs_sak

# Sätt portnummer
port=30000
 
# Kommentera bort bindIp
#  bindIp: 127.0.0.1

Starta ARBITER-noden, samt enbla automatisk uppstart av mongod-service
```
systemctl start mongod
systemctl enable mongod
```
Gå tillbaka till PRIMARY-noden och dess mongo-klient och lägg till ARBITER-noden
```
rs.addArb("mongodb0.example.com:30000")
```
Nu skall rs.status() visa att replikeringen är konfigurerat med en PRIMARY, två SECONDARY och en ARBITER.
```
rs.status()
```

Skapa ett superadmin-konto från PRIMARY-noden

rs_sak:PRIMARY> db=db.getSiblingDB('admin')

rs_sak:PRIMARY> db.createUser( { user: "adminuser", pwd: "password", roles: [ "userAdminAnyDatabase", "readWriteAnyDatabase", "dbAdminAnyDatabase", "clusterAdmin" ] } )

Detta konto skapas på PRIMARY-noden och kommer att synkas över till alla SECONDARYs.

Aktivera Autentisering i aktuellt "Replika Set" mellan dess noder.

Skapa upp katalogstruktur på alla noder (PRIMARY, ARBITER och SECONDARY's)
```
mkdir /mongodb/srv
mkdir /mongodb/srv/mongodb
cd /mongodb/srv/mongodb
```
Generera Keyfile. Det görs från första noden, den som är PRIMARY (används för autentisering mellan noderna).
```
Exekvera följande kommando:
openssl rand -base64 741 > keyfile
```
Samma keyfile-fil måste finnas på alla medlemsnoder (PRIMARY, ARBITER och alla SECONDARYs), som sagt, generera endast denna på första noden och kopiera sedan filen till de andra.

Kopiera filen till de övriga noderna

scp keyfile root@mongodb0.example.com:/mongodb/srv/mongodb/keyfile
scp keyfile root@mongodb2.example.com:/mongodb/srv/mongodb/keyfile

Filen får inte ha några grupp eller world rättigheter och ska ägas av mongod

Skapa rättigheter (måste utföras på alla noder)

cd /mongodb/srv
chown mongod -R mongodb
chgrp mongod -R mongodb
cd mongodb
chmod 600 keyfile

Uppdatera konfigurations-filen så att autentiseringen blir aktiverad, samt peka ut keyfile (måste utföras på alla noder).
```
vim /etc/mongod.conf

security:
   keyFile: /mongodb/srv/mongodb/keyfile 
```

Starta om alla noder (ARBITERN, SECONDARY's och slutligen PRIMARY)

ARBITERN> systemctl restart mongod
SECONDARY's> systemctl restart mongod
PRIMARY> systemctl restart mongod

Använda mongo-klienten med autentisering

Exempel:

[root@db1]# mongo
> use admin
switched to db admin
rs_sak:PRIMARY> db.auth("adminuser", "password")
1
rs_sak:PRIMARY> rs.conf()
...
rs_sak:PRIMARY> rs.status()
...
rs_sak:PRIMARY>

6.3.1.2. Konfiguration för singelnod-system

Starta MongoDB-servern:
```
systemctl start mongod
```
Starta mongoDB-klienten från Linux-prompten:
```
mongo
```

Skapa ett Admin-konto i MongoDB-klienten:

> db = db.getSiblingDB("admin")
> db.createUser({ user: "adminuser", pwd : "PASSWORD", roles: [ "userAdminAnyDatabase", "readWriteAnyDatabase", "dbAdminAnyDatabase","clusterAdmin" ] } )

Avsluta MongoDB-klienten:
```
> exit
```
Editera filen: /etc/mongod.conf
Aktivera autentiseringen i ett singelnod-system:
```
security:
 authorization: enabled
```
Kontrollera i konfigurationsfilen (mongod.conf) att logpath och dbpath passar för systemet.
Starta om MongoDB-servern
```
systemctl restart mongod
```

6.3.2. Skapa databaser, index och användare för Säkerhetstjänster

Med installationen medföljer ett konfigurationsskript för att skapa nödvändiga databaser, index och användare för Säkerhetstjänster. Det ligger i installationspaketet under /Lokal_sakerhetstjanst/db/mongodb/ med namnet mongo_db_setup.sh.

För att kunna köra skriptet, behöver MongoDB med klient vara installerat enligt ovan. Du måste ha skapat ett användarkonto med administratörsrättigheter och skriptet ska exekveras på den nod som är PRIMARY (i en replikerad miljö).

Skriptet kräver värdnamn, användarnamn och lösenord för administratören (admin-användaren som skapades ovan), användarnamn och lösenord för Säkerhetstjänsten (användaren som skriptet ska skapa per databas i MongoDB och som nedan anges vid installation av applikationsservern) samt eventuellt ett prefix för tabellerna (collections) för den specifika installationen. Man kan också välja ifall man vill ta bort eventuellt existerande databas eller bara tabellen (collection).

Skriptet måste ges exekveringsrättigheter t.ex. genom kommandot chmod och måste placeras i en katalog där den som exekverar skriptet har skrivrättigheter (då skriptet skapar en temporär fil i samma katalog). Man måste även stå i aktuell katalog (m.h.a. kommandot cd) när man exekverar skriptet. I exemplet nedan har vi kopierat skriptet till katalogen /tmp.

cd /tmp
chmod +x mongo_db_setup.sh

Med växeln -h kan man få mer information om användningen av skriptet

./mongo_db_setup.sh -h

Användning:

./mongo_db_setup.sh <hostname> <adminuser> <adminpassword> <username> <password> [prefix]

Exempel 1:

./mongo_db_setup.sh localhost adminuser <adminuser-pw> <sak-user> <sak-pw>

Skapar (om) collections med index, men utan tabellprefix.
Skapar databaser och sak-användare om dessa inte redan existerar.

Exempel 2:

./mongo_db_setup.sh localhost adminuser <adminuser-pw> <sak-user> <sak-pw> example_

Skapar (om) collections med index och tabellprefix example_
Skapar databaser och sak-användare om de inte redan existerar.

Kontrollera att skriptet exekverar utan felmeddelanden och rapporterar "Done recreating databases!"

[root@db1 tmp]# ./mongo_db_setup.sh localhost adminuser password sak-user password

This script will drop (delete) and recreate data in databases PDLLOG, AUDITLOG and ARCHIVESEARCH.
Are you sure that you would like to continue(y)? y

MongoDB shell version: 3.4.x
connecting to: localhost

Checking that we are on primary node...
WE ARE ON PRIMARY NODE. OK!

Logging in for admin rights...

Dropping collection 'audit' in database 'auditlog'
Creating user 'sak' for database 'auditlog'
{
        "user" : "sak",
        ...
}
Creating indexes for collection 'audit' in database 'auditlog'

Dropping collection 'log' in database 'pdllog'
Creating user 'sak' for database 'pdllog'
{
        "user" : "sak",
        ...
}
Creating indexes for collection 'log' in database 'pdllog'

Dropping collection 'log' in database 'statistics'
Creating user 'sak' for database 'statistics'
{
        "user" : "sak",
        ...
}
Creating indexes for collection 'log' in database 'statistics'

Dropping collection 'log' in database 'archivesearch'
Creating user 'sak' for database 'archivesearch'
{
        "user" : "sak",
        ...
}

DONE recreating databases!

[root@db1 tmp]#

6.3.3. Verifiera MongoDB-konfiguration

Nu ska de databaser, användare, collections och index vara skapade för Säkerhetstjänsten. Verifiera genom att starta mongo-klienten och lista databaser, användare och index för varje databas (archivesearch, auditlog, pdllog och statistics).

Databas	Collection (default utan prefix)	Index
archivesearch	Skapas dynamiskt av Säkerhetstjänster	-
auditlog	audit	"_id_", "timestamp_1" , "server_1", "tags_1", "level_1", "logger_1", "expireAt_1"
pdllog	log	"_id_", "sysname_1", "sysid_1_sysname_1_act_date_1", "cpid_1_act_date_1", "cpid_1_resources.cpid_1_act_date_1", "uid_1_act_date_1", "resources.pid_1_resources.pid_type_1_act_date_1, "cuid_1_act_date_1"
statistics	log	"_id_", "timestamp_1", "consumerid_1_timestamp_-1", "consumerid_1_eventtype_1_eventstatus_1_timestamp_1", "expireAt_1"

I mongo-klienten

[root@db1 ~]# mongo
MongoDB shell version: 3.4.x
connecting to: test
>
> use admin
switched to db admin
>
> db.auth("adminuser", "password")
1
rs_sak:PRIMARY> show dbs
admin       0.000GB
auditlog    0.000GB
local       0.000GB
pdllog      0.000GB
statistics  0.000GB
rs_sak:PRIMARY> use pdllog
switched to db pdllog
rs_sak:PRIMARY> show collections
log
system.indexes
system.users
rs_sak:PRIMARY> db.log.stats()
{
        "ns" : "pdllog.log",
        "count" : 0,
        "size" : 0,
        "storageSize" : 8192,
        "numExtents" : 1,
        "nindexes" : 8,
        "lastExtentSize" : 8192,
        "paddingFactor" : 1,
        "systemFlags" : 1,
        "userFlags" : 0,

		"totalIndexSize" : 32768,
        "indexSizes" : {
                "_id_" : 4096,
                "sysname_1" : 4096,
                "sysid_1_sysname_1_act_date_1" : 4096,
                "cpid_1_act_date_1" : 4096,
                "cpid_1_resources.cpid_1_act_date_1" : 4096,
                "uid_1_act_date_1" : 4096,
                "resources.pid_1_resources.pid_type_1_act_date_1" : 4096,
                "cuid_1_act_date_1" : 4096
        },
        "ok" : 1

}
rs_sak:PRIMARY> show users
{
        "_id" : ObjectId("548708f2dedc419d8bc106f7"),
        "user" : "sak",
        "pwd" : "cb77f010e5f31482d96a9986dbb12900",
        "roles" : [
                "readWrite"
        ]
}
rs_sak:PRIMARY> use statistics
...

6.3.4. Konfigurationsfil

Följande är ett exempel på hur en MongoDB-konfiguration kan se ut. Denna fil hittar man under: /etc/mongod.conf

# mongod.conf

# for documentation of all options, see:
#   http://docs.mongodb.org/manual/reference/configuration-options/

# where to write logging data.
systemLog:
  destination: file
  logAppend: false
  path: /var/log/mongodb/mongod.log

# Where and how to store data.
storage:
  dbPath: /mongodb/data
  journal:
    enabled: true
#  engine:
#  mmapv1:
#  wiredTiger:

# how the process runs
processManagement:
  fork: true  # fork and run in background
  pidFilePath: /var/run/mongodb/mongod.pid  # location of pidfile

# network interfaces
net:
  port: 27017
#  bindIp: 127.0.0.1  # Listen to local interface only, comment to listen on all interfaces.


security:
 keyFile: /mongodb/srv/mongodb/keyfile

#operationProfiling:

replication:
 replSetName: rs_sak

#sharding:

## Enterprise-Only Options

#auditLog:

#snmp:

Notera att parametrarna replSetName och keyFile är specifika för en uppsättning med replikering i ett MongoDB-kluster.

Konfiguration	Parameter	Värde	Beskrivning
systemLog:
	destination:	file	Händelselogg skrivs till fil
	logAppend:	true	Värdet satt till true säkerställer att mongod ej skriver över existerande logfil vid omstart.
	path:	/var/log/mongodb/mongod.log	Sökväg där MongoDB sina egna händelseloggar.

storage:
	dbPath:	/mongodb/data	Sökväg til MongoDBs datakatalog. Det är detta diskutrymme som måste möta utrymmeskraven för MongoDB
	journal: enabled:	true	Journaling säkerställer "singel-nods" skrivbarhet. 64-bit bygget av mongod har jornaling som default.

processManagement:
	fork:	true	Sätter mongod-deamon till server-deamon, vilket gör att den körs som en konventionell databasserver.
	pidFilePath:	/var/run/mongodb/mongod.pid	Vill man att MongoDB skapar en PID-fil specificerar man vart denna ska skapas med denna parameter. Valfritt men kan vara användbart ifall man vill automatisera övervakning av MongoDB-processen.

net: port:	27017		Portnummer som MongoDB-server lyssnar efter anslutningar på. För Arbiter-noden sätter vi denna till 30000 i vårt exempel.

security:
	keyFile:	/mongodb/srv/mongodb/keyfile	Autentiseringsnyckel aktiverar autentiseringen i ett replikeringskluster. Sökväg till en fil med den autentiseringsnyckel som används för autentisering mellan de noder som ingår i ett replikeringskluster. Denna nyckel/fil måste vara identisk på alla noder.

replication:
	replSetName:	<none>	Använd för att konfigurera replikering i ett kluster av MongoDB-noder. Ange ett namn på "replikeringsuppsättningen". Observera att alla noder måste ha samma värde på detta namn.

7. Installation av applikationsserver

Det är av prestandaskäl rekommenderat att tilldela lokala Säkerhetstjänsters applikationsserver en egen fysisk maskin.

7.1. Installera Java och JCE

Installera Java (jdk) och tillägget JCE Java Cryptography Extension, enligt avsnitt Java som anges tidigare i anvisningen.

7.2. Installation av lokala Säkerhetstjänster

När databasserver och applikationsserver är förberedda kan programvaran för lokala Säkerhetstjänster installeras. Detta görs på applikationsservern.

7.2.1. Installera systemet

Notera: Vid installationen krävs att användaren har root-behörighet, t.ex. root-användaren.
Notera: I exemplen nedan så har installationsmediet kopierats till katalogen /tmp och Install path satt till /share/Sakerhetstjanster<version>/local/

Från version 2.15 av Säkerhetstjänster har installationsprogrammet förbättrats. Man installerar på samma sätt som tidigare, där man skall ange konfigurationsvärden för att systemet skall fungera.
Mer om det kan ses i noteringarna lite längre ned i installationsguiden.

Under installationen kommer det att skapas en användare (”sak”) som sedan används för att köra systemets processer. Det är även möjligt att använda en befintlig användare.

Kopiera över installationsmediet till valfri katalog på servern (nod1).
Byt katalog till installationskatalogen. Detta är viktigt för att installationsskriptet ska hitta tillhörande installationsfil.
```
cd /tmp/Lokal_sakerhetstjanst/install/
```
Ge installationsprogrammet rätt att exekvera:
```
chmod +x install.sh
```
När installationen har startat ska man välja en installation (”target”). Detta är en konfigurationsfil med de default-parametrar som ska anges vid installation. Lokala Säkerhetstjänster 2.15 levereras med en konfigurationsfil (för både Linux och Windows) för 443-portar och en för 8443-portar (se Översikt adresser och portar).
```
Exempelbild för dom "targets" man kan välja, beroende på vilken portuppsättning man valt.
```
```
1. local.default.443.ports.linux.target.properties
2. local.default.443.ports.win.target.properties
3. local.default.8443.ports.linux.target.properties
4. local.default.8443.ports.win.target.properties
```
Alternativ 1. (local.default.443.ports.linux.target.properties) 443 port installation innebär att alla tjänster nås på samma port (443 som standard) med olika adresser för varje tjänst.
Alternativ 3. (local.default.8443.ports.linux.target.properties) 8443 port installation innebär att alla tjänster har samma adress men olika portar för varje tjänst (standard i Säkerhetstjänster < 2.7).
Någon av dessa (alternativ 1 eller 3) väljs om man inte har förberett en egen konfigurationsfil, som då kan användas istället. Vid användningen av någon av de medföljande konfigurationsfilerna får man förslag på defaultvärden men får ändå gå igenom alla värden så att man kan ändra manuellt efter behov. Vilka värden som efterfrågas beskrivs i Tabell: Konfigurationsvärden lite längre ned. I tabellen finns även utökad information som beskriver de parametrar som ska anges.
Ifall man vill göra en egen konfigurationsfil (t.ex. vid installation av en testmiljö som kommer installeras fler än en gång):

Kopiera undan den befintliga konfigurationskatalogen (target) som backup och ge den ett lämpligt namn. Ex backup.target:
```
cp -r /tmp/Lokal_sakerhetstjanst/install/resource/target/ /tmp/Lokal_sakerhetstjanst/install/resource/backup.target
```
Editera någon av filerna local.default.443.ports.linux.target.properties, local.default.8443.ports.linux.target.properties i mappen target. Uppdatera den med aktuella adresser, portar och funktionscertifikat m.m. Se Tabell: Konfigurationsvärden för vägledning omkring de olika parametrarna. När detta är klart kan installationen startas.

Nytt är att dom inmatade värdena automatiskt sparas i en propertiesfil (/Sakerhetstjanst<version>/install/resource/target/sak_installation.properties). Behöver man avbryta installationen Ctrl+c så sparas det i den filen.
Det innebär att nästa gång man startar installationsprogrammet, så kommer den att fråga om man vill fortsätta där man slutade, eller börja om på nytt.
Detected previous unfinished installation. Do you want to continue with this installation?
[1] Yes - continue previous installation
[2] No - Start new installation
Select option: 1

Starta installationen med följande kommando:
```
./install.sh
```

Välj typ av portkonfiguration ("targets") både om en failover lösning eller singel nod ska användas, se beskrivning: Översikt adresser och portar, och tryck Enter:

1. local.default.443.ports.linux.target.properties
2. local.default.443.ports.win.target.properties
3. local.default.8443.ports.linux.target.properties
4. local.default.8443.ports.win.target.properties


Choose environment:
3
[1] Sakerhetstjanster2.15 Linux instance
Select installation: 1
Running installation Sakerhetstjanster<version> Linux instance

Därefter görs de konfigurationer som behövs (för att använda defaultvärdet trycker man Enter), se Tabell: Konfigurationsvärden . Observera att man måste ange värden på konfigurationer för IdP även om inte den ska installeras, se noteringen (Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst) nedan.

NOTERA:
Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst
Om inte den medföljande Autentiseringstjänsten ska användas så är det möjligt att konfigurera Lokala Säkerhetstjänster att använda en annan IdP, detta hanteras då via metadata. Trots detta är det nödvändigt att ange något värde på konfigurationerna för IdP för att inte installationsskriptet ska fallera i ett senare skede. Lämpligen kan man ange samma värden som för application host för certifikat och publik port men välja en annan intern port som är ledig och som inte är reserverad, t.ex 8444 och 8445.

Nytt är också det sista som sker i konfigurationsförfarandet. Där har man möjlighet att välja att antingen exekvera igång installationen direkt eller verifiera alla inmatade värden, se exempel 1 nedan.
Exempel 1
All configuration groups has been checked.
1. Execute installation 2. Verify configuration values:
Väljer man att verifiera får man möjlighet välja om man man är nöjd med alla inmatade värden, eller om man behöver ändra något inmatat värde. Man får då stega sig igenom alla inmatade värden och byta där det behövs, se exempel 2 nedan.
Exempel 2
Are these Values correct?
[1] Yes
[2] No - edit values
När man ändrat och verifierat klart får man åter valet om man vill exekvera igång installationen eller verifiera, se exempel 3 nedan.
Exempel 3
All configuration groups has been checked.
1. Execute installation 2. Verify configuration values:

Vänta på att installationsscriptet körs klart och att meddelandet ”Installation Completed!” visas, se bild nedan. Observera att det kan ta nån minut att kopiera filerna.

-- Execute installation ------------------------------------------------------------------------------------------------
All configuration groups has been checked.
1. Execute installation  2. Verify configuration values:
1
Install ..//install/system/bundles to /delad/Sakerhetstjanster<version>/local/bundles
Install ..//install/system/config to /delad/Sakerhetstjanster<version>/local/config
Install ..//install/system/osgi to /delad/Sakerhetstjanster<version>/local/osgi
Install ..//install/system/bin to /delad/Sakerhetstjanster<version>/local/bin
Install ..//install/system/lib/resources to /delad/Sakerhetstjanster<version>/local/lib/resources
Install ..//doc/userguide to /delad/Sakerhetstjanster<version>/local/doc
Install ..//templates/metadata to /delad/Sakerhetstjanster<version>/local/data/templates/metadata
Install ..//templates/rules to /delad/Sakerhetstjanster<version>/local/data/templates/rules
#### Installation completed! ####

7.2.2. Tabell över installationsvärden vid installation

Parameter	Defaultvärde (8443 ports \| 443 ports)	Exempel	Info
(Core setup)
Java home	/usr/java/latest	/usr/java/jdk1.8_xx	Katalog där java JDK finns installerat.
Shared path	/share	/share	Säkerhetstjänstens delade diskarea (som används av alla noder). Här läggs t.ex. konfigurationsfiler och binärer.
Install path	/share/Sakerhetstjanster<version>/local		Säkerhetstjänstens delade filer läggs här (som används av alla noder). Här läggs t.ex. konfigurationsfiler och binärer.
Working path	/sakerhetstjansten/Sakerhetstjanster<version>/local		Säkerhetstjänstens arbetsyta, här sparas respektive nods loggar och övriga filer.
OSGi console port	1111		Konsol-porten för att ansluta till systemet.
Service user	sak		Systemanvändare som Säkerhetstjänstens process kommer att köras som.
Service user group	sakgroup		Användargruppen till systemanvändaren.
(Http(s) setup)
Application host address	--	8443: sakerhetstjanst.example.com 443: sakerhetstjanst.example.com	Säkerhetstjänstens publika adress.
Path to server PKCS#12	--		Sökvägen till där funktionscertifikatet för legitimering (certificate.p12-fil) för Säkerhetstjänsten är sparat. Bör inte vara ett SITHS-certifikat.
Server PKCS#12 password	--		Lösenord till ovan funktionscertifikat.
Application port (internal)	8443		Https port för Säkerhetstjänstens Admin-GUI för intern åtkomst.
Application port (public)	8443 \| 443		Https port för Säkerhetstjänstens Admin-GUI för extern åtkomst. Sätt värde 8443 för en 8443 port-installation och sätt värde 443 för en 443 port-installation.
Ws http(s) setup
Web Service host address	--	8080: sakerhetstjanst.example.com 443: ws.sakerhetstjanst.example.com	Adressen till Säkerhetstjänstens WebService-tjänster.
Path to WS PKCS#12	--		Sökväg till där man sparat funktionscertifikatet (certificate.p12-fil) för WebService-tjänster. Bör vara ett SITHS-certifikat.
WS PKCS#12 password	--		Lösenord till ovan funktionscertifikat
Web Service Port (internal)	8080		Port som Säkerhetstjänstens webbtjänster kommer att publiceras på för intern åtkomst.
Web Service Port (public)	8080 \| 443		Port som Säkerhetstjänstens webbtjänster kommer att publiceras på för extern åtkomst. Sätt värde 8080 för en 8443 port-installation och sätt värde 443 för en 443 port-installation.
(Cluster cache setup)
Infinispan protocol - UDP or TCP	UDP		Protokoll för kommunikation mellan klusternoder.
Infinispan multicast address	239.0.10.1		Multicastadress för kommunikation mellan klusternoder när protokollet UDP är valt.
Infinispan cluster members	HostA[7800],HostB[7800]		Statisk kommaseparerad lista på klusternoder när protokollet TCP är valt med portnumret inom 'hakparantes' såsom i exemplet.
(MySQL Database setup)
Host address	--	db.example.com	Adress till databas(MySQL)-servern.
Port	3306		Port till MySQL.
User name	sak		Den användare som Säkerhetstjänstens skall använda för att koppla upp sig mot databasen.
Password	--		Lösenord för databasanvändaren.
Database name prefix		example_	Namnen på databaserna kan ges ett prefix ifall så önskas. I annat fall lämnas detta fält tomt. (Vill man ha ett underscore mellan prefix och namn så måste detta ingå)
(Common Domain http(s) setup)
Path to common domain Identity PKCS#12	--		Sökväg till där funktionscertifikatet(legitimering) för common domain (cd-certificate.p12-fil) för Säkerhetstjänsten är sparat. (Om common domain inte används, dvs systemet ingår inte i en federation, ange samma funktionscertifikat som ovan.)
Common domain PKCS#12 password	--		Lösenord till ovan funktionscertifikat.
Host address on Common Domain	--	8446: sakerhetstjanst.example.com 443: cd.sakerhetstjanst.example.com	Säkerhetstjänsten publika Common Domain adress. (Om common domain inte används, dvs systemet ingår inte i en federation, ange "cd.host.example.com")
Common domain Port (internal)	8446		Port som används för intern åtkomst till Common Domain.
Common domain Port (public)	8446 \| 443		Port som används för extern åtkomst till Common Domain. Sätt värde 8446 för en 8443 port-installation och sätt värde 443 för en 443 port-installation.
Common domain address	--	commondomain.example.com
(IdP http(s) setup)
IdP host address	--	8445: sakerhetstjanst.example.com 443: idp.sakerhetstjanst.example.com	IdP tjänstens publika adress. Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras. Läs mer om den under noteringen - Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst
Path to IdP PKCS#12	--		Sökväg till där man sparat funktionscertifikatet,legitimering, (certificate.p12-fil) för IdP tjänsten. Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras. Läs mer om den under noteringen - Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst Bör inte vara ett SITHS-certifikat.
IdP PKCS#12 password	--		Lösenord till ovan funktionscertifikat. Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras. Läs mer om den under noteringen - Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst
IdP port (internal)	8445		Port som används av SSO-service internt. Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras. Läs mer om den under noteringen - Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst
IdP port (public)	8445 \| 443		Port som används av SSO-service externt. Sätt värde 8445 för en 8443 port-installation och sätt värde 443 för en 443 port-installation. Observera att ett värde måste anges även om inte autentiseringstjänsten ska installeras. Läs mer om den under noteringen - Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst
Secure Idp http(s) setup
Secure IdP host address	--	8444: sakerhetstjanst.example.com 443: secure.idp.sakerhetstjanst.example.com	Adress till IdP tjänsten som används för att identifiera/autentisera användare med SITHS-kort. Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras. Läs mer om den under noteringen - Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst
Path to secure IdP PKCS#12	--		Sökväg till där funktionscertifikatet(legitimering) för IdP (certificate.p12-fil) för Säkerhetstjänsten är sparat. Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras. Läs mer om den under noteringen - Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst Bör inte vara ett SITHS-certifikat.
Secure IdP PKCS#12 password	--		Lösenord till ovan funktionscertifikat. Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras. Läs mer om den under noteringen - Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst
Secure IdP port (internal)	8444		Port som används för att identifiera/autentisera användare med SITHS-kort internt. Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras. Läs mer om den under noteringen - Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst
Secure IdP port (public)	8444 \| 443		Port som används för att identifiera/autentisera användare med SITHS-kort externt. Sätt värde 8444 för en 8443 port-installation och sätt värde 443 för en 443 port-installation. Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras. Läs mer om den under noteringen - Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst
(HSA-WS setup)
Host address	ws.hsa.sjunet.org		Adress till HSA-WS tjänsten.
Port	443		Port för HSA-WS tjänsten.
Search base	c=SE		Sökbas för HSA-WS.
Context path	/svr-hsaws2/hsaws/		Context path för HSA-WS.
PU Service setup - Proxy
Host address	esb.ntjp.sjunet.org esb.ntjp.se		Adress till PU-tjänsten via tjänsteplattformen. (adresser till Sjunet och Internet)
Port	443		Port för PU-tjänsten.
(Log setup)
Log archive shared path	/share/xlog_archive		Sökväg till den delade area där komprimerade PDL-logg arkiv sparas. Kommer ej att användas om Loggtjänsten inte installeras.
Log store proxy address	ws.sakerhetstjanster.sjunet.org		Säkerhetstjänstens nationella publika adress. Anges för att skicka PDL-loggar till nationella Loggtjänsten, när lokal loggtjänst inte installeras.
(Logreport setup)
Log Reports shared path	/share/logreports		Sökväg till en delad filarea där färdiga loggrapporter sparas.
(Mongo Database setup)
Address replica server 1	--	mongodb1.example.com	Adress till MongoDB Primary server.
Address replica server 2	--	mongodb2.example.com	Adress till MongoDB Secondary server. (Vid singelnodinstallation ange samma adress som server 1).
Port	27017		Port för MongoDB.
Username	sak		Användare för MongoDB.
Password	--		Lösenord MongoDB.
Database name PDL log	pdllog		MongoDB databas för PDL-loggar
Database name archive search	archivesearch		MongoDB databas för arkivsökning
Database name audit log	auditlog		MongoDB databas för systemloggar
Database name statistics log	statistics		MongoDB databas för autentiseringsstatistik
Collection name prefix		example_	I databaserna skapas Collections som kan ges ett prefix ifall så önskas. I annat fall lämnas detta fält tomt. (Vill man ha ett underscore mellan prefix och namn så måste detta ingå)
Days to keep statistics data in database	92		Antal dagar som statistikloggarna sparas innan de automatiskt tas bort.
Days to keep audit logs in MongoDB	92		Antal dagar som auditloggarna sparas innan de automatiskt tas bort.

7.2.3. Installation av SingelServer eller Första noden i en fail-over lösning

Sätt exekveringsrättigheter på filen sak_server nu när Säkerhetstjänster är installerat i katalogen /share
```
chmod +x /share/Sakerhetstjanster<version>/local/bin/sak_server
```
Installera Lokal Säkerhetstjänst service genom att exekvera kommandot:
```
/share/Sakerhetstjanster<version>/local/bin/sak_server setup_first
```
Uppdatera därefter applikationsservern enligt avsnitt Linux-specifika inställningar för applikationsservern.

Om man råkade mata in fel värden vid installationen måste ovanstående kommandon exekveras på nytt. Dvs både ./install.sh samt /share/Sakerhetstjanster<version>/local/bin/sak_server setup_first

7.2.4. Installation på Andra noden i en failover lösning

Installera lokal Säkerhetstjänst på andra noden, om en failover lösning ska användas, genom att exekvera kommandot:
```
/share/Sakerhetstjanster<version>/local/bin/sak_server setup_other
```
Uppdatera därefter applikationsservern enligt avsnitt Linux-specifika inställningar för applikationsservern

7.3. Linux-specifika inställningar för applikationsservern

Lägg till i /etc/security/limits.conf så att antalet max öppna filer för användaren sak utökas:
```
sak           -     nofile          65572
```
Se till att ovanstående begränsningar läses in vid inloggning genom att lägga till följande rad i /etc/pam.d/login:
```
session    required     /lib/security/pam_limits.so
```

Förbättra UDP prestandan (OS UDP Buffer Limits)

Utöka skrivbufferten till 25 MB

echo 'net.core.wmem_max=26214400' >> /etc/sysctl.conf

Utöka läsbufferten till 25 MB

echo 'net.core.rmem_max=26214400' >> /etc/sysctl.conf

Kommentera bort tidigare värden i /etc/sysctl.conf

vim /etc/sysctl.conf
 
Exempelbild:
#net.core.rmem_max=5000000
#net.core.wmem_max=640000
net.core.wmem_max=26214400
net.core.rmem_max=26214400

Ladda om ändringarna
```
sysctl -p
```

Uppdatera behörighet för Säkerhetstjänsters delade diskyta. (default /share),
1. Säkerställ att den skapade användaren/gruppen (default sak och,sakgroup) har behörighet att skriva till den delade diskytan. Detta kan t.ex. utföras genom att sätta den skapade användaren som ägare:
```
chown sak:sakgroup /share
```
2. Vid installation med failover är det viktigt att användargruppen och användare som applikationen använder (sakgroup och sak) har samma UID på samtliga noder, för att man inte ska få problem med åtkomst till vissa resurser.
  Verifiera därför att användare och användargruppen har samma UID på samtliga noder i filerna /etc/passwd och /etc/group.
  Vid behov så använd kommandona usermod respektive groupmod för att sätta ett nytt likadant UID.

7.4. Installation Infinispan cluster cache över TCP

Har man valt TCP under installationen (Cluster cache setup -> Infinispan protocol - UDP or TCP) måste man nu manuellt ange nodens bind/IP-adress i en konfigurationsfil per nod. Ta reda på vilken IP-adress som gäller för noden med kommandot ifconfig och ändra attributet bind_addr i XML-taggen TCP_NIO från 0.0.0.0 till nodens IP-adress. Upprepa på samtliga noder.

vim /sakerhetstjansten/Sakerhetstjanster<version>/local/jgroups/jgroups-tcp.xml

Exempel:
 
<TCP_NIO
 bind_port="7800"
 bind_addr="10.0.1.1"
... />

Kontrollera också, i samma fil, listan över i klustret ingående noder i attributet initial_hosts i XML-taggen TCPPING. Detta ska vara en kommaseparerad lista över klustrets alla noder med den port som ska användas inom 'hakparantes'.

Exempel:

<TCPPING initial_hosts="10.0.1.1[7800],10.0.1.2[7800]" port_range="0"/>

Observera att attributet bind_addr i XML-taggen TCP_NIO kräver att man anger serverns riktiga IP-adress. Det fungerar inte om man exempelvis anger DNS-namn, 0.0.0.0 eller 127.0.0.1

7.5. Installation utan databasen MongoDB

NOTERA: MongoDB är ett krav för lokal Loggtjänst. Följande konfiguration kommer att inaktivera insamlandet av statistik för autentiseringshändelser samt ta bort MongoDB som reservkälla för loggning av systemhändelser, tar bort lokalt sparande av pdlloggar (för loggrapporter), samt lokalt sparande för arkivsök (för loggrapporter).

Öppna filen archivesearch.xml för editering i t.ex. vim. Sök upp och ändra värdet på attributet med nyckelnamn enabled till false.
vim /share/Sakerhetstjanster<version>/local/config/com.logica.se.iac.db.mongo.service.connection.factory/archivesearch.xml

<Attribute key="enabled" type="Boolean">
    	<Value>false</Value>

Gör likadant (längst ned i filen) med filen auditlog.xml
vim /share/Sakerhetstjanster<version>/local/config/com.logica.se.iac.db.mongo.service.connection.factory/auditlog.xml

<Attribute key="enabled" type="Boolean">
    	<Value>false</Value>

Gör likadant (längst ned i filen) med filen pdllog.xml
vim /share/Sakerhetstjanster<version>/local/config/com.logica.se.iac.db.mongo.service.connection.factory/pdllog.xml

<Attribute key="enabled" type="Boolean">
    	<Value>false</Value>

Gör likadant (längst ned i filen) med filen statistics.xml
vim /share/Sakerhetstjanster<version>/local/config/com.logica.se.iac.db.mongo.service.connection.factory/statistics.xml

<Attribute key="enabled" type="Boolean">
    	<Value>false</Value>

8. Uppstart av applikationsserver

NOTERA: Om installation av single nod valdes, fortsätt till avsnitt Uppstart av lokal säkerhetstjänst på nod 1

När man startar Säkerhetstjänster första gången efter installation måste man, på varje nod, installera de komponenter man har behov av. Det görs genom OSGi-konsolen som med standardkonfiguration nås genom telnet på port 1111.

Det skapas en uppstartsfil (loggfil) för varje nod, läs mer om detta i kaptiel Systemlogg (audit)

8.1. Uppstart av lokal Säkerhetstjänst på nod 1

Starta lokal Säkerhetstjänst på första noden genom att exekvera:
```
/etc/init.d/sak_server start
```

Logga in till systemkonsolen:

telnet localhost 1111

NOTERA: Det kan ta ca en minut innan servern har startat och att det går att logga in till systemkonsolen.
NOTERA: Om en annan port än defaultport 1111 har angivits i installationen, anger man denna istället.

NOTERA: Förändringar i OSGI-kommandon

osgi> package:pkglist (ersätter pkg list)

osgi> package:pkginstall (ersätter pkginstall)

Exempel: package:pkginstall -p 0 (installerar alla paket)

Exempel: package:pkgstart (startar igång alla installerade paket)

```
osgi> state (ersätter context state)
```

osgi> search (ersätter audit search)

Exempel: search -level error (söker i loggen efter alla error, error går att ersätta med warn, info)

Exempel: search -level error -time 10m (söker i loggen efter alla errors dom senaste 10 minuterna)

osgi> monitor (ersätter sys monitor)

Exempel: monitor -filter infinispan (monitorerar status för infinispan klustret)

osgi> spfilter -on (ersätter sys sp -on)

osgi> spfilter -off (ersätter sys sp -off)

osgi> acc -import file:///path/to/file (ersätter sys acc -import file:///path/to/file)

osgi> authz -on (ersätter sys authz -on)

osgi> authz -off (ersätter sys authz -off

```
osgi> plat:help (hjälp meny)
```

Man kan även använda pil upp/ned på tangentbordet för att nyttja tidigare slagna osgi-kommandon.

Verifiera i systemkonsolen att bundlarna för applikationsservern är uppstartade (ACTIVE), genom att exekvera kommandot: ss

Uppstartade Plattformsbundlar

-- Welcome to Platform ------------------------------
osgi> ss
"Framework is launched."
id State Bundle
0 ACTIVE org.eclipse.osgi_3.10.3
1 ACTIVE Fastinfoset_osgi_1_2_4_1.0.0
2 ACTIVE KerbLibrary_osgi_1.0.0
3 ACTIVE activemq_all_osgi_5.3.1.0_fuse_01_00_1.0.5
4 ACTIVE org.springframework.osgi.aopalliance.osgi_1.0.0
5 ACTIVE asm-osgi_3.1.0
6 ACTIVE atomikos_3.9.4
Fragments=15
7 ACTIVE org.springframework.osgi.cglib_nodep.osgi_1.0.0
8 ACTIVE com.google.gwt_2.6.3
9 ACTIVE com.logica.se.iac.accesscontrol.repository_3.0.0
10 ACTIVE com.logica.se.iac.accesscontrol.repository.impl_3.0.0
11 ACTIVE com.logica.se.iac.accesscontrol.service_3.0.0
12 ACTIVE com.logica.se.iac.accesscontrol.service.impl_3.0.5
13 ACTIVE com.logica.se.iac.accesscontrol.service.types_3.0.0
14 ACTIVE com.logica.se.iac.archive_3.0.0
15 RESOLVED com.logica.se.iac.atomikos.cm_3.0.0
Master=6
16 ACTIVE com.logica.se.iac.authorization.rule_3.0.0
17 ACTIVE com.logica.se.iac.authorization.service_3.1.0
18 ACTIVE com.logica.se.iac.bc_3.0.0
19 ACTIVE com.logica.se.iac.cache_3.0.2
20 ACTIVE com.logica.se.iac.cache.infinispan_3.0.5
21 ACTIVE com.logica.se.iac.check.jce_3.0.0
22 ACTIVE com.logica.se.iac.commandproviders_3.0.1
23 ACTIVE com.logica.se.iac.directory.service_3.0.0
24 ACTIVE com.logica.se.iac.event_3.0.0
25 ACTIVE com.logica.se.iac.equinox_3.0.3
26 ACTIVE com.logica.se.iac.file.storage_3.0.1
27 ACTIVE com.logica.se.iac.file.storage.impl_3.0.1
28 ACTIVE com.logica.se.iac.hsa.rivta.service_1.0.0
29 ACTIVE com.logica.se.iac.hsa.rivta.service.impl_1.0.0
30 ACTIVE com.logica.se.iac.hsa.rivta.service.types_1.0.0
31 ACTIVE com.logica.se.iac.hsa.service_3.1.4
32 ACTIVE com.logica.se.iac.hsa.service.impl_1.0.9
33 ACTIVE com.logica.se.iac.hsa.service.types_1.0.0
34 ACTIVE com.logica.se.iac.hsa.service.ws.proxy.impl_3.1.5
35 ACTIVE com.logica.se.iac.http.session.jetty_3.0.1
36 ACTIVE com.logica.se.iac.http_3.0.1
37 ACTIVE com.logica.se.iac.http.web_3.0.0
38 ACTIVE com.logica.se.iac.i18n_3.0.1
39 ACTIVE com.logica.se.iac.identity_3.0.0
40 ACTIVE com.logica.se.iac.identity.impl_3.0.0
41 ACTIVE com.logica.se.iac.identity.passwordprovider_3.0.0
42 ACTIVE com.logica.se.iac.identity.pkcs11_3.0.0
43 ACTIVE com.logica.se.iac.identity.pkcs12_3.0.1
44 ACTIVE com.logica.se.iac.identity.system_3.0.0
45 ACTIVE com.logica.se.iac.identity.system.impl_3.0.0
46 ACTIVE com.logica.se.iac.jaxb.lazy_3.0.0
47 RESOLVED com.logica.se.iac.jdbc.mysql_3.0.3
Master=157
48 ACTIVE com.logica.se.iac.job_3.0.3
49 ACTIVE com.logica.se.iac.job.quartz_3.0.10
50 ACTIVE com.logica.se.iac.key.keyinfo_3.0.0
51 ACTIVE com.logica.se.iac.key.keyinfo.impl_3.0.0
52 ACTIVE com.logica.se.iac.key.repository_3.0.0
53 ACTIVE com.logica.se.iac.key.repository.server.impl_3.0.0
54 ACTIVE com.logica.se.iac.keystore.pkcs11_3.0.0
55 ACTIVE com.logica.se.iac.keystore.soft_3.0.0
56 ACTIVE com.logica.se.iac.ldap.service.impl_3.0.0
57 ACTIVE com.logica.se.iac.logging_3.0.2
58 ACTIVE com.logica.se.iac.logging.console_3.0.0
59 ACTIVE com.logica.se.iac.logging.db_3.0.4
60 ACTIVE com.logica.se.iac.logging.file_3.0.0
61 ACTIVE com.logica.se.iac.logging.impl_3.0.11
62 ACTIVE com.logica.se.iac.oasis200401wsswssecuritysecext10_3.0.0
63 ACTIVE com.logica.se.iac.oasis200401wsswssecurityutility10_3.0.0
64 ACTIVE com.logica.se.iac.osgi_3.0.0
65 ACTIVE com.logica.se.iac.osgi.activation_3.0.0
66 ACTIVE com.logica.se.iac.osgi.cm_3.0.1
Fragments=67
67 RESOLVED com.logica.se.iac.osgi.cm.cache_3.0.0
Master=66
68 ACTIVE com.logica.se.iac.osgi.cm.common_3.0.0
69 ACTIVE com.logica.se.iac.osgi.cm.store_3.0.0
70 ACTIVE com.logica.se.iac.osgi.cm.store.xml_3.0.0
71 ACTIVE com.logica.se.iac.osgi.command_3.0.0
72 ACTIVE com.logica.se.iac.osgi.command.impl_3.0.5
73 ACTIVE com.logica.se.iac.osgi.context_3.0.1
74 ACTIVE com.logica.se.iac.osgi.context.extender_3.0.4
75 ACTIVE com.logica.se.iac.osgi.context.servlet_3.0.1
76 ACTIVE com.logica.se.iac.osgi.jmx_3.0.0
77 ACTIVE com.logica.se.iac.osgi.monitor_3.0.0
78 ACTIVE com.logica.se.iac.osgi.monitor.logger_3.0.0
79 RESOLVED com.logica.se.iac.osgi.spring.extender.config_3.0.0
Master=180
80 ACTIVE com.logica.se.iac.performance_3.0.0
81 ACTIVE com.logica.se.iac.performance.impl_3.0.0
82 ACTIVE com.logica.se.iac.person.identityid.validator_3.0.10
83 ACTIVE com.logica.se.iac.quartz_3.0.0
84 ACTIVE com.logica.se.iac.repository_3.1.1
85 ACTIVE com.logica.se.iac.repository.support_3.0.0
86 ACTIVE com.logica.se.iac.resource.service_3.0.0
87 ACTIVE com.logica.se.iac.resource.service.impl_3.0.0
88 ACTIVE com.logica.se.iac.rs_1.0.1
89 ACTIVE com.logica.se.iac.saml20.assertion_3.0.0
90 ACTIVE com.logica.se.iac.saml20.protocol_3.0.0
91 ACTIVE com.logica.se.iac.service.ws.util_3.0.2
92 ACTIVE com.logica.se.iac.servicecertificatelocator_3.0.0
93 ACTIVE com.logica.se.iac.servicecertificatelocator.impl_3.0.0
94 ACTIVE com.logica.se.iac.subject_3.0.1
95 ACTIVE com.logica.se.iac.subject.impl_3.0.1
96 ACTIVE com.logica.se.iac.system.accesscontrol_3.0.0
97 ACTIVE com.logica.se.iac.trust.service_3.0.2
98 ACTIVE com.logica.se.iac.trust.service.impl_3.0.6
99 ACTIVE com.logica.se.iac.util_3.0.6
100 ACTIVE com.logica.se.iac.util.core_3.0.6
101 ACTIVE com.logica.se.iac.util.factory_3.0.0
102 ACTIVE com.logica.se.iac.util.xml_3.0.3
103 ACTIVE com.logica.se.iac.ws_3.0.1
104 ACTIVE com.logica.se.iac.ws.callback.impl_3.0.0
105 ACTIVE com.logica.se.iac.ws.logicaladdress.service.impl_3.0.0
106 ACTIVE com.logica.se.iac.ws.proxy.impl_3.0.2
107 ACTIVE com.logica.se.iac.ws.publication.impl_3.0.0
108 ACTIVE com.logica.se.iac.wsaddressing200508.core_3.0.0
109 ACTIVE com.logica.se.iac.wsidentity10_3.0.0
110 ACTIVE com.logica.se.iac.wsit.tubelineassembler.impl_3.0.0
111 ACTIVE com.logica.se.iac.wspolicy200409_3.0.0
112 ACTIVE com.logica.se.iac.wsresourceframework12.basefault_3.0.0
113 ACTIVE com.logica.se.iac.wsresourceframework12.resource_3.0.0
114 ACTIVE com.logica.se.iac.wstrust10_3.0.0
115 ACTIVE com.logica.se.iac.wstrust13_3.0.0
116 ACTIVE com.logica.se.iac.wstrust14_3.0.0
117 ACTIVE com.logica.se.iac.xacml20.context_3.0.0
118 ACTIVE com.logica.se.iac.xacml20.policy_3.0.0
119 ACTIVE com.logica.se.iac.xacml20.saml.assertion_3.0.0
120 ACTIVE com.logica.se.iac.xacml20.saml.protocol_3.0.1
121 ACTIVE com.logica.se.iac.xacml30wd07.core_3.0.0
122 ACTIVE com.logica.se.iac.xacml30wd07.saml.assertion_3.0.0
123 ACTIVE com.logica.se.iac.xacml30wd07.saml.protocol_3.0.0
124 ACTIVE com.logica.se.iac.xacml30wd13.saml.assertion_3.0.0
125 ACTIVE com.logica.se.iac.xacml30wd13.saml.protocol_3.0.0
126 ACTIVE com.logica.se.iac.xacml30wd17.core_3.0.0
127 ACTIVE com.logica.se.iac.xadisk_3.0.0
128 ACTIVE com.logica.se.iac.xmldsig200009.core_3.0.0
129 ACTIVE com.logica.se.iac.xmlencryption200104_3.0.0
130 ACTIVE commons_collections_osgi_1.0.0
131 ACTIVE commons_compress_osgi_1.14.0
132 ACTIVE commons_io_osgi_1.3.1
133 ACTIVE commons-lang3_3.5.0
134 ACTIVE commons-net-osgi-3.2.0_3.2.0
135 ACTIVE commons-validator_1.5.1
136 ACTIVE com.jcraft.jsch-0.1.53_0.1.53
137 ACTIVE displaytag_osgi_1.0.0
138 ACTIVE fop_osgi_1.0.0
139 ACTIVE geronimo_jms_1.1_spec_1.0.0
140 ACTIVE iaik_wrapper_1.0.0
141 ACTIVE infinispan-8.0_8.2.1.Final
142 ACTIVE javax.mail_1.4.5
143 ACTIVE javax.ws.rs-api-2.1_2.1.0
144 ACTIVE jaxb_impl_osgi_1.0.0
145 ACTIVE jaxws_rt_osgi_2_1_7_1.1.3
146 ACTIVE jca-1.5_1.5.0
147 ACTIVE jetty_j2se6_osgi_1.0.1
148 ACTIVE org.mortbay.jetty.jsp_2.1_1.0.0
149 ACTIVE org.mortbay.jetty.server_1.0.3
Fragments=150
150 RESOLVED org.mortbay.jetty.security_1.0.0
Master=149
151 ACTIVE org.mortbay.jetty.util_1.0.0
152 ACTIVE jradius_osgi_1.1.4_1.0.0
153 ACTIVE org.mortbay.jetty.jsp_api_2.1_1.0.0
154 ACTIVE jsr250_api_osgi_1.0.0
155 ACTIVE jta_osgi_1.1_1.0.0
156 ACTIVE mail_activation_osgi_1.0.2
157 ACTIVE mysql-connector-5.1.30_1.0.1
Fragments=47
158 ACTIVE org.eclipse.equinox.event_3.4.0_1.0.0
159 ACTIVE org.eclipse.equinox.metatype_3.4.0_1.0.1
160 ACTIVE org.eclipse.osgi.services_3.4.0.201708291456
161 ACTIVE org.apache.felix.gogo.command_0.14.0.201708291456
162 ACTIVE org.apache.felix.gogo.runtime_0.16.2.201708291456
163 ACTIVE org.apache.felix.gogo.shell_0.10.0.201708291456
164 ACTIVE org.apache.mina.core_2.0.9
165 ACTIVE org.apache.sshd.core_0.7.0
166 ACTIVE org.eclipse.equinox.console_1.1.1.201708291456
167 ACTIVE org.eclipse.equinox.console.ssh_1.0.101.201708291456
Fragments=168
168 RESOLVED com.logica.se.iac.equinox.console.ssh_3.0.0
Master=167
169 ACTIVE osgi.cmpn_4.3.0.201708291456
170 ACTIVE org.quartz-2.2.1_2.2.1
171 ACTIVE servlet_api_1.0.0
172 ACTIVE slf4j_logica_osgi_1.6.2
173 ACTIVE org.springframework.bundle.spring.aop_1.0.0
174 ACTIVE org.springframework.bundle.spring.beans_1.0.0
175 ACTIVE org.springframework.bundle.spring.context_1.0.0
176 ACTIVE org.springframework.bundle.spring.core_1.0.0
177 ACTIVE org.springframework.bundle.spring.jdbc_1.0.0
178 ACTIVE org.springframework.bundle.spring.jms_1.0.0
179 ACTIVE org.springframework.bundle.osgi.core_1.0.0
180 ACTIVE org.springframework.bundle.osgi.extender_1.0.1
Fragments=79
181 ACTIVE org.springframework.bundle.osgi.io_1.0.0
182 ACTIVE org.springframework.bundle.osgi.web_1.0.2
183 ACTIVE org.springframework.bundle.spring.tx_1.0.0
184 ACTIVE org.springframework.bundle.spring.web_1.0.0
185 ACTIVE org.springframework.bundle.spring.webmvc_1.0.0
186 ACTIVE stax_ex_osgi_1.0.0
187 ACTIVE stax_utils_osgi_1.0.0.20070216_1.0.2
188 ACTIVE streambuffer_osgi_0_8_1.0.0
189 ACTIVE sun.pkcs11_1.6.0_1.0.0
190 ACTIVE woodstox_osgi_1.0.3
191 ACTIVE wsit_osgi_1_5_java_1_6_1.0.11
192 ACTIVE xadisk-1.0_1.0.2
193 ACTIVE xalan_osgi_1.0.4
194 ACTIVE xml_security_osgi_1.0.2
195 ACTIVE xmlgraphics_commons_osgi_1.4.0
osgi>

Förklaring av fältet ”State” i ovan utskrift:
INSTALLED - Bundeln är installerad i systemet men är inte startad.
STARTED - Bundeln är startad men ännu inte aktiv.
ACTIVE - Bundeln är startad och aktiv.
RESOLVED - Bundeln är stoppad.

Observera att bundlarna för applikationsservern installeras automatiskt under uppstart av tjänsten, se bild ovan.

Lista de komponenter som kan installeras med kommandot:

osgi> package:pkglist

Id    Name                          Description
0     All                           All available packages
1     Authorization Local           Local Authorization Service
2     IdP Local                     Identity Provider
3     Block Local                   Local Block Service
4     Commission                    Commission Service
5     Consent                       Local Consent Service
6     Log                           Local Log Service
7     Log Proxy                     Local Log Proxy
8     Log Report                    Local Log Report Service
9     PU Proxy                      Local PU Proxy

Välj de komponenter som skall installeras:
- All - Alla tjänster
- Authorization Local - Lokal åtkomsttjänst.
- Idp Local - Lokal Autentiseringstjänst.
- Block Local - Lokal Spärrtjänst.
- Commission - Lokal Commission .
- Consent - Lokal Samtyckestjänst.
- Log - Lokal loggtjänst.
- Log Proxy - Lokal loggproxytjänst.
- Log Report - Lokal loggrapportstjänst.
- Pu Proxy - Lokal proxytjänst för personuppgifter
Det är möjligt att installera enbart en av tjänsterna, t.ex. Spärr. Dock kräver tjänsterna Spärr, Samtycke tillgång till en intern/extern autentiseringstjänst (IdP) för att en användare ska kunna logga in och komma åt webbtjänsterna.
Exempel:
För att installera alla tjänster (komponent 0 i exemplet ovan):
```
osgi> package:pkginstall -p 0
```
För att installera endast IdP:
```
Exempel:
 
osgi> package:pkginstall -p 1,2,4,9
```
För att installera lokal Spärrtjänst med IdP och logg:
```
Exempel:
 
osgi> package:pkginstall -p 1,2,3,4,6,7,8,9
```
För att installera lokal Loggtjänst, Lograpport med IdP:
```
Exempel:
 
osgi> package:pkginstall -p 1,2,4,6,7,8,9
```
Säkerställ att de paket-id som anges i exemplet ovan stämmer med de komponenter som skall installeras. Hämta aktuellt paket-id med kommandot: package:pkglist.
Starta det installerade komponenterna med kommandot:
```
osgi> package:pkgstart
```
Vänta ett tag på att bundlarna startar upp, ca 2 min.
Verifiera att samtliga bundlar är uppstartade med kommandot dep. (Kommandot listar alla bundlar som ännu inte är startade.) Exekvera kommandot:
```
osgi> dep
 
Utskriftsexempel:
osgi> dep
  id  Bundle                                                   State                   Unsatisfied dependencies

Spring dependencies

osgi> 
```
Listas inte någon bundel här, är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel.
Om någon bundel inte startar igång, testa att starta om säkerhetstjänster.
Kvarstår problemet måste felsökning påbörjas:
1. Kontrollera systemloggen efter fel.
```
osgi> search -level error
```
2. Kontrollera även systemloggen efter fel. Systemloggen skapas i den lokala katalogen där Säkerhetstjänster körs och dit skrivs loggar innan systemet är helt startat och senare i vissa fall om det är loggning till fil, se exempel nedan.
```
Windows: C:\Program Files\Inera\Lokal Sakerhetstjanst<version>\local\log\outputlog_service.txt
Linux: /sakerhetstjansten/Sakerhetstjanster<version>/local/log/sak_yyyy-mm-dd_hh-mm-ss.log
```

Verifiera att alla beroenden är uppfyllda med kommandot:

osgi> state
 
Exempel:
osgi> state
Id   Context                                                                    State                    State Information
osgi>

Listas inte någon bundel här, är alla beroenden mellan bundlarna uppfyllda. I annat fall upprepa kommandot i intervaller, tills kommandot inte listar någon bundel.
Kan ta ett antal minuter vid uppstart.

Om state visar någon eller några bundlar så kan det bero på följande:

Om någon av tjänsterna Samtycke eller Spärr installeras, men inte lokal Loggtjänst, behöver tjänsterna konfigureras för att använda en extern loggtjänst. Följande ”fel” visas vid installation av enbart Spärr och IdP.

Exempel:
osgi> package:pkglist

Id    Name                          Description
0     All                           All available packages
1     Authorization Local           Local Authorization Service
2     IdP Local                     Identity Provider
3     Block Local                   Local Block Service
4     Commission                    Commission Service
5     Consent                       Local Consent Service
6     Log                           Local Log Service
7     Log Proxy                     Local Log Proxy
8     Log Report                    Local Log Report Service
9     PU Proxy                      Local PU Proxy
osgi>
osgi> package:pkginstall -p 1,2,3,4,5,7,9
osgi> package:pkgstart
osgi>
osgi> state
Id   Context                                                                    State                    State Information
306  com.logica.se.bif.block.web.war                                            UNRESOLVED DEPENDENCIES  com.logica.se.bif.log.agent.LogAgent
341  com.logica.se.bif.consent.web.war                                          UNRESOLVED DEPENDENCIES  com.logica.se.bif.log.agent.LogAgent
352  com.logica.se.bif.log.agent.impl                                           UNRESOLVED DEPENDENCIES  com.logica.se.bif.log.service.LogStoreService
                                                                                                         (name=Service)
353  com.logica.se.bif.log.agent.txwrapper.impl                                 UNRESOLVED DEPENDENCIES  com.logica.se.bif.log.agent.LogAgent
                                                                                                         (transactional=false)
232  com.logica.se.rivta.ping.ws.factory/log1                                   UNRESOLVED DEPENDENCIES  com.logica.se.rivta.ping.service.PingService
                                                                                                         (Bundle-SymbolicName=com.logica.se.bif.log.service.impl)
232  com.logica.se.rivta.ping.ws.factory/log2                                   UNRESOLVED DEPENDENCIES  com.logica.se.rivta.ping.service.PingService
                                                                                                         (Bundle-SymbolicName=com.logica.se.bif.log.service.impl)
232  com.logica.se.rivta.ping.ws.factory/logreport1                             UNRESOLVED DEPENDENCIES  com.logica.se.rivta.ping.service.PingService
                                                                                                         (Bundle-SymbolicName=com.logica.se.bif.logreport.service.impl)
232  com.logica.se.rivta.ping.ws.factory/logreport2                             UNRESOLVED DEPENDENCIES  com.logica.se.rivta.ping.service.PingService
                                                                                                         (Bundle-SymbolicName=com.logica.se.bif.logreport.service.impl)

Figur: Utskriftsexempel 1, state, Unresolved dependencies.

Spärr (Block) saknar beroenden, i detta fall saknas en lokalt installerad Loggtjänst som behöver konfigureras manuellt med adressen till en extern loggtjänst.

- Ändra värdet för logStoreService från Service till Proxy.
	Linux: /share/Sakerhetstjanster<version>/local/config/com.logica.se.bif.log.agent.impl.xml
	Windows: C:\share\Sakerhetstjanster<version>\local\config\com.logica.se.bif.log.agent.impl.xml

- Ange rätt värde för adress (hostname) och portnummer (portNumber) till den externa loggtjänsten.
	Linux: /share/Sakerhetstjanster<version>/local/config/com.logica.se.bif.log.v2.ws.proxyimpl.xml
	Windows: C:\share\Sakerhetstjanster<version>\local\config\com.logica.se.bif.log.v2.ws.proxyimpl.xml

Uppdatera bundlarna com.logica.se.bif.log.agent.impl.3.0.0 och com.logica.se.bif.log.v2.ws.proxyimpl.3.0.0 i systemkonsolen genom att först hitta rätt id med kommandot ss och sedan uppdatera bundle med aktuellt id. Se exempel nedan.

Exempel:
osgi> ss com.logica.se.bif.log.agent.impl
Framework is launched.
id      State       Bundle
352     ACTIVE      com.logica.se.bif.log.agent.impl_3.0.0

osgi> update 352
osgi> refresh 352

osgi> ss com.logica.se.bif.log.v2.ws.proxyimpl_3.0.0
Framework is launched.
id      State       Bundle
361     ACTIVE      com.logica.se.bif.log.v2.ws.proxyimpl_3.0.0

osgi> update 361
osgi> refresh 361

Verifiera beroenden igen med kommandot:

osgi> state

osgi> state
Id   Context                                                                    State                    State Information
232  com.logica.se.rivta.ping.ws.factory/log1                                   UNRESOLVED DEPENDENCIES  com.logica.se.rivta.ping.service.PingService
                                                                                                         (Bundle-SymbolicName=com.logica.se.bif.log.service.impl)
232  com.logica.se.rivta.ping.ws.factory/log2                                   UNRESOLVED DEPENDENCIES  com.logica.se.rivta.ping.service.PingService
                                                                                                         (Bundle-SymbolicName=com.logica.se.bif.log.service.impl)
232  com.logica.se.rivta.ping.ws.factory/logreport1                             UNRESOLVED DEPENDENCIES  com.logica.se.rivta.ping.service.PingService
                                                                                                         (Bundle-SymbolicName=com.logica.se.bif.logreport.service.impl)
232  com.logica.se.rivta.ping.ws.factory/logreport2                             UNRESOLVED DEPENDENCIES  com.logica.se.rivta.ping.service.PingService
                                                                                                         (Bundle-SymbolicName=com.logica.se.bif.logreport.service.impl)

Figur: Utskriftsexempel 2, state, Unresolved dependencies

Bundeln com.logica.se.bif.ping.ws.factory publicerar ping-tjänsten för alla tjänster, varav Logg och Loggrapporttjänsten visas som icke startade i figuren ovan. I exemplet ovan valde vi att installera Lokal Spärrtjänst och IdP och därför saknas nu bundlar för Logg, Loggrapport. Vi vill nu ta bort konfigurationsfilerna för de tjänster som inte installerats för att lösa de "UNRESOLVED DEPENDENCIES" vi har.

Åtgärd för att ta bort pingtjänster som inte används:

- Gå till installationskatalogen

Linux: /share/Sakerhetstjanster<version>/local/config/com.logica.se.rivta.ping.ws.factory/ 
Windows: C:\share\Sakerhetstjanster<version>\local\config\com.logica.se.rivta.ping.ws.factory\

Ta bort konfigurationsfilerna för de tjänster som inte installerats enligt tabellen nedan.

Tjänst	Konfigurationsfil
Spärr	blockLocalInternal.xml, blockLocalV2.xml,blockLocalV3.xml* blockLocalV4.xml*
Logg (Loggrapport)	log1.xml, log2.xml, logreport1.xml, logreport2.xml
Samtycke	consent_1.xml, consent_2.xml
Idp	commissionService.xml

Logga in i osgi konsolen. Uppdatera bundeln för pingtjänsten com.logica.se.bif.ping.ws.impl_3.0.0 med update och refresh enligt exempel nedan.
```
osgi> ss com.logica.se.rivta.ping.ws.impl

Framework is launched.


id      State       Bundle
232     ACTIVE      com.logica.se.bif.ping.ws.impl_3.0.0


osgi> update 232

osgi> refresh 232
```
Figur: Utskriftsexempel för att uppdatera pingtjänsten efter borttagning av konfiguration som ej används

Verifiera att alla beroenden är uppfyllda med kommandot:

osgi> state
 
Exempel:
osgi> state
Id   Context                                                                    State                    State Information
osgi>

Avsluta systemkonsolen med kommandot:
```
osgi> disconnect
```

8.2. Anslut till webbgränssnitt

Kontrollera att det går att ansluta till webbgränssnittet m.h.a en webbläsare på den första noden.

Om serverns adress inte finns i DNS-servern måste den lokala host-filen temporärt uppdateras på den klientdator som används för att ansluta till webbgränssnittet.
Lägg till följande i lokala host-filen: <server ip-adress nod1> nod1
Verifiera att det går att ansluta till webbgränssnittet via en webbläsare ex. https://[servernamn]:8443 för en 8443-installation där den publika app-porten satts till 8443 och https://[servernamn] för en 443-installation.
Om frågan, att servern inte har ett giligt certifikat visas, välj ”continue to this website”.

Figur: Säkerhetstjänsters admin-GUI

8.3. Uppstart av lokal Säkerhetstjänst på övriga noder

Starta igång lokal Säkerhetstjänst på de övriga noderna (nod2) genom att exekvera:
```
/etc/init.d/sak_server start
```

Vänta en stund på att systemet startar, det tar några min.
Logga in till systemkonsolen:
```
telnet localhost 1111
```

Lista installationspaketen som ska installeras med följande kommando:

osgi> package:pkglist

Id    Name                          Description
0     All                           All available packages
1     Authorization Local           Local Authorization Service
2     IdP Local                     Identity Provider
3     Block Local                   Local Block Service
4     Commission                    Commission Service
5     Consent                       Local Consent Service
6     Log                           Local Log Service
7     Log Proxy                     Local Log Proxy
8     Log Report                    Local Log Report Service
9     PU Proxy                      Local PU Proxy

Exekvera package:pkginstall-kommandot med samma komponentlista som för nod 1. I exemplet nedan 1,2,3,4,6,7,8,9 för lokal spärrtjänst med IdP och logg:
```
Exempel:
 
osgi> package:pkginstall -p 1,2,3,4,6,7,8,9
```
Starta de installerade bundlarna med kommandot nedan.
```
osgi> package:pkgstart
```
Vänta ett tag på att bundlarna startar upp, ca 2 min.
Verifiera att samtliga bundlar är uppstartade med kommandot dep. (Kommandot listar alla bundlar som inte har startat).
```
osgi> dep
 
Exempel:
osgi> dep
  id  Bundle                                                   State                   Unsatisfied dependencies

Spring dependencies

osgi> 
```
Listas inte någon bundel här är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel.
Om någon bundel inte startar, testa att starta om Säkerhetstjänster. Kvarstår problemet måste felsökning påbörjas.
Verifiera att alla beroenden är uppfyllda med kommandot:
```
osgi> state
 
Exempel:
osgi> state
Id   Context                                                                    State                    State Information
osgi>
```
Listas inte någon bundel här, är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel.

När nu alla noder är installerade och uppstartade kan det vara bra att kontrollera att de har anslutit till infinispan-klustret.

Man kan kontrollera att samtliga noder ingår i infinispan-klustret med ett kommando i OSGi-konsolen. Detta kommando bör verifieras på varje nod för att säkerställa att noderna känner till varandra i klustret.

Utför på varje installerad nod i klustret:

Gå in i systemkonsolen med:
```
telnet localhost 1111
```
Slå kommando:
```
monitor -filter infinispan
```

Konsolen kommer nu lista vilka noder som ingår i klustret.

osgi> monitor -filter infinispan
Id                                      Type        Timestamp                             Value               Description
com.logica.se.iac.cache.infinispan
members                                 String      2017-09-19 13:56:02:849               nod1-61437, nod2-41756
                                                                                                              Available cluster members
state                                   String      2017-09-19 13:56:02:848               ACTIVE              Context state which will show if configuration
                                                                                                              is needed, or if mandator OSGi service references
                                                                                                              are missing etc.

Exempel ovan på hur utskriften kan se ut när man ser över klustret i OSGi-konsolen. De noder här som ingår i klustret är "nod1-61437, nod2-41756".

Om samtliga noder listas, har klustret satts upp som det ska. I annat fall:
- Stoppa Säkerhetstjänster på alla noder.
```
/etc/init.d/sak_server stop
```
- Öppna sak_server med en lämplig text-editor.
```
vim /etc/init.d/sak_server
```
- Sök er fram till "# Infinispan protocol".
```
# Infinispan protocol (Multicast: "UDP" or static hosts list: "TCP")
INFINISPAN_PROTOCOL="UDP"
# Infinispan Name (used to identify the infinispan cluster by all nodes)
INFINISPAN_NAME="server.example.com_sakerhetstjanst<version>"
# Infinispan jgroups config dir path (with ending /)
INFINISPAN_CONFIG_DIR="/sakerhetstjansten/sakerhetstjanst<version>/local/jgroups/"
# Infinispan multicast address (when using UDP)
INFINISPAN_MULTICAST="239.0.2.3"
```
  Startskriptet sak_server med Infinispan-konfiguration
  - Kontrollera att INFINISPAN_PROTOCOL är satt till TCP eller UDP.
  - Kontrollera att INFINISPAN_CONFIG_DIR är en korrekt sökväg och att den innehåller två XML-filer (jgroups-tcp.xml och jgroups-udp.xml)
  - För UDP kontrollera att INFINISPAN_MULTICAST är satt till en giltig multicast-adress, att den är samma i startskriptet sak_server på alla noder samt att multicast är aktiverat/möjligt i ert system/nät.
  - För TCP kontrollera konfigurationsfilen jgroups-tcp.xml enligt Installation Infinispancluster cache över TCP på alla noder samt att vald port (default 7800) är öppen för kommunikation mellan noderna.
  - Kontrollera i senaste uppstartsloggen att utpekad konfigurationsfil verkligen används av applikationen.
```
cat /sakerhetstjansten/Sakerhetstjanster<version>/local/log/sak_2016-11-09_15-06-05.log | grep resolved
                ... Infinispan configuration file resolved to '/sakerhetstjansten/Sakerhetstjanster<version>/local/jgroups/jgroups-tcp.xml'
```

1. - Efter verifieringen starta sak_server igen
    /etc/init.d/sak_server start
  - Låt en nod starta upp ordentligt innan man startar nästa. Kontrollera klustermedlemmarna igen med kommandot
    monitor -filter infinispan
Avsluta systemkonsolen med kommandot:
```
osgi> disconnect
```
Verifiera att det går att ansluta till webbgränssnittet via en webbläsare ex:
https://[servernamn]/

9. Systemkonfiguration

Efter att den lokala Säkerhetstjänsten har installerats och startats, ska en systemkonfiguration genomföras. Säkerhetstjänster använder sig av två filter:

Autentiseringsfilter - Filtret kräver att användaren ska autentisera sig för att få åtkomst till Säkerhetstjänster.
Behörighetsfilter - Filtret styr vilken behörighet användaren har i Säkerhetstjänster. Det kan exempelvis innebära att en användare som har rollen som spärradministratör endast får hantera spärrar i systemet.

Filtren ska vara avstängda under pågående systemkonfiguration.

Verifiera att de är avslagna enligt:

Logga in till systemkonsolen med:
```
telnet localhost 1111
```
Inaktivera autentiseringsfiltret med kommando:
```
osgi> spfilter -off
```
Inaktivera behörighetsfiltret med kommando:
```
osgi> authz -off
```
Avsluta systemkonsolen med kommando:
```
osgi> disconnect
```

När konfigurationen av systemet är genomförd ska autentiseringsfiltret och behörighetsfiltret aktiveras.

Anslut till Säkerhetstjänsters webbgränssnitt med den host-adress som ni angav i installationsskedet: https://[servernamn]/spadmin och genomför konfiguration enligt nedan:

9.1. Konfigurera HSA

Vid installationen anges adressen till HSA-WS. Om fel adress angavs eller om adressen måste ändras går det att konfigurera om den enligt nedan.

9.1.1. HSA-WS

Dessa instruktioner gäller endast om ni använder HSA-WS för att anropa HSA, vilket är default.

Klicka på menyn Administration -> Generell Konfiguration.
Välj sedan konfiguration HSA-WS Factory 3.1.5 och verifiera/ändra inställningarna.

Timeout In Milliseconds och Lookup Cache Duration ska normal inte ändras.
Timeout In Milliseconds anger hur länge tjänsten skall vänta på svar från HSA-tjänsten. Lookup Cache Duration anger hur länge i millisekunder ett hämtat värde kan återanvändas, utan att åter fråga HSA-tjänsten.

Figur: Konfiguration av HSA-WS Factory

9.1.2. HSA-RIVTA

Dessa instruktioner gäller endast om ni använder HSA-RIVTA för att anropa HSA.

Klicka på menyn Administration -> Generell Konfiguration.
Välj sedan konfiguration HSA RIVTA Service 1.0.0 och ändra inställningarna.

Timeout In Milliseconds och Lookup Cache Duration ska normal inte ändras.
Timeout In Milliseconds anger hur länge tjänsten skall vänta på svar från HSA-tjänsten. Lookup Cache Duration anger hur länge i millisekunder ett hämtat värde kan återanvändas, utan att åter fråga HSA-tjänsten.

Figur: Konfiguration av HSA Directory Organization Service

Click here to expand...

HSA RIVTA Service 1.0.2

Verifiera att Context Path-raderna är rätt för NTjP [QA] [PROD]

/vp/infrastructure/directory/authorizationmanagement/getcredentialsforpersonincludingprotectedperson/2/rivtabp21
/vp/infrastructure/directory/employee/getemployeeincludingprotectedperson/2/rivtabp21
/vp/infrastructure/directory/organization/gethealthcareunit/2/rivtabp21
/vp/infrastructure/directory/organization/gethealthcareunitlist/2/rivtabp21
/vp/infrastructure/directory/authorizationmanagement/getpersonauthorizedtosystemincludingprotectedperson/2/rivtabp21

Verifiera att Host name-raden är rätt för NTjP

Nät	System	Hostname
Sjunet	Produktion	esb.ntjp.sjunet.org
Sjunet	QA	qa.esb.ntjp.sjunet.org
Internet	Produktion	esb.ntjp.se
Internet	QA	qa.esb.ntjp.se

HSA Service Impl 1.0.9

Klicka i Use HSA RIVTA 2.0 contracts

Om något går fel...

Om något går fel när man slår på Use HSA RIVTA 2.0 contracts så kanske man inte kan logga in igen eftersom IdP:n inte kan göra HSA-uppslag.

Först kan man då titta i loggarna genom OSGi-konsolen

osgi> search -level error -time 60s
osgi> search -level warn -time 60s

Har man fått en felkod från NTjP kan man tyda denna här: NTjP Felkoder

Vill man slå av Use HSA RIVTA 2.0 contracts via GUI så slår man av autentiseringen för en stund (om ett oskyddat system är acceptabelt för en stund) via OSGi:

osgi> spfilter -off
osgi> authz -off

...och slår på autentisering så fort man ändrat med växlarna -on för samma OSGi kommandon.

Vill man ändra tillbaka utan att stänga av autentiseringen ändrar man värdet useHsaRivtaContract till false direkt i XML-filen /share/Sakerhetstjanst2.17/local/config/com.logica.se.iac.hsa.service.impl.xml och startar om alla applikationsnoder.

9.2. Konfigurera Personuppgiftstjänsten

Personuppgiftstjänsten behöver endast konfigureras om någon av följande tjänster är installerade: Samtycke eller Spärr.

Om man går mot Ineras nationella Personuppgiftstjänst för namnuppslag behöver man konfigurera så att anropen går via tjänsteplattformen.

Klicka på menyn Administration -> Generell Konfiguration.
Välj sedan konfiguration Resident Information Lookup Service 3.0.0. och se över så att inställningarna är korrekta. Det är viktigt att Pu service interface är inställt på Proxy. Se exempelbilden nedan.

Figur: Konfiguration av Resident Information Lookup Service 3.0.0
Välj sedan konfiguration PU - V3 WS Proxy Impl 1.0.0 och se över så att inställningarna är korrekta. Se exempelbilden nedan.

Context Path PU version 3: vp/strategicresourcemanagement/persons/person

Figur: Konfiguration av PU - V3 WS Proxy Impl 1.0.0

9.3. Ta bort rotcertifikat för test vid en produktionssättning

I och med produktionssättning av systemet bör alla rotcertifikat som använts för test, tas bort ur listan med konfigurerade certifikatsutfärdare. Säkerställ först att inga ytterligare tester skall genomföras i systemet innan certifikaten tas bort.
Detta görs i två steg, först avmarkerar man i förtroendekällan att rotcertifikaten används, därefter tas rotcertifkaten bort.

Klicka på menyn Administration -> Webbserver.
Klicka på knappen Ändra för förtroendekällan "No Check Trust Service".

Figur: Ändra rotcertifikat för förtroendekälla
Avmarkera de rotcerfikat som ska tas bort och klicka på knappen Spara.

Figur: Ändra förtroendekälla
Gör motsvarande (punkt 2-3) för förtroendekällan "SAML Trust Service" samt "Trust Service".
Klicka på menyn Administration -> Certifikatsutfärdare.
Klicka på soptunnan som tillhör den certifikatutfärdaren ni vill ta bort. Se bilden nedan:

Figur: Ta bort certifikatsutfärdare

Om man får felmeddelandet ”En eller flera förtroendekällor använder denna certifikatsutfärdare....", används rotcertifikarten av någon webbserver.
Upprepa punkt 2-4 för berörda förtroendekällor för att ta bort användningen innan rotcertifikatet kan tas bort.

9.4. Lägg till rotcertifikat för front-end-certifikatet

Då det sedan april 2019 rekommenderas att skaffa ett certifikat till front-end-domänerna så vill man säkert lägga till tillit till en utgivare som inte finns med i installationspaketet.

Öppna menyn Administration → Certifikatsutfärdare
Klicka på knappen Lägg till
Välj filen med rotcertifikatet för utgivaren av det certifikat som ska användas till front-end och klicka Spara

9.5. Konfigurera System, IdP och SP att använda SITHS-certifikat

Säkerhetstjänster är förinställt att använda front-end-certifikatet till att kommunicera med externa parter som t.ex Nationella spärrtjänsten och HSA genom NTjP. Men detta blir fel om man inte längre har SITHS-certifikat i front-end och därför vill vi nu ställa in Säkerhetstjänster för att använda SITHS-certifikatet för WebService-gränssnittet där vi behöver ett SITHS-certifikat:

Systemets externa kommunikation
IdP:ns signering av meddelanden
SP:ns signering av meddelanden

Ändra till ws i följande konfiguration

Administration → Generell konfiguration → System Identity Implementation
Ändra Identity Name till ws
Administration → Generell konfiguration → IdP Service Implementation
Ändra Selected Key Identity till ws
Administration → Generell konfiguration → SP Service Implementation
Ändra Selected Key Identity till ws

9.6. Tilldela systemet egenskaper för interna anrop

Systemegenskapen systemRole med värde Internal gör det möjligt för interna tjänster att göra anrop.

Klicka på menyn Administration -> SP SAML.
Lägg till systemegenskapen systemRole:
1. Bläddra i listan Egenskap.
2. Välj http://sambi.se/attributes/1/systemRole.
3. Skriv in Internal i fältet Värde.
4. Klicka på knappen Lägg till.

Figur: Exempel på konfiguration av systemegenskaper.

9.7. Konfiguration av CDC - Common Domain Cookie

CDC är en typ av webbkaka som används för hålla rätt på vilken IdP som medarbetaren använde senast, för att på så vis få SingleSignOn då det finns flera IdP:er.
Finns det bara en IdP ska nedanstående inställningar vara avaktiverade.

Konfiguration av CDC görs under menyerna Administration -> SP SAML och Autentisering -> IdP SAML.

Det går att aktivera/inaktivera att CDC används. Detta görs genom att bocka i eller ur kryssrutorna för SP och IdP CDC. Se bilderna nedan.

Bocka i kryssrutan om SP ska läsa från CDC. Se bilden nedan.

Figur: SP CDC inställningar
Bocka i kryssrutan om IdP ska skriva till CDC. Se bilden nedan.

Figur: IdP CDC inställningar

9.8. Autentiseringstjänsten - IdP

Säkerhetstjänster består av två huvuddelar, de tjänster SP:ar (såsom Spärr och Logg) som installeras och Autentiseringstjänsten (IdP).

Installeras IdP:n behöver man i där konfigurera upp vilka SP:ar som får använda IdP:n.
På motsvarande sätt måste man i SP-delen konfigurera upp vilka IdP:er som denna kan använda.

Denna konfiguration görs med hjälp av SAML-metadatafiler:

SP-metadata beskriver hur SP:n fungerar och läses in i IdP:n.
IdP-metadata beskriver hur IdP:n kan användas och denna läser man in i SP:n.

Om lokal Autentiseringstjänst och en av de lokala tjänsterna (såsom t ex Spärr) installerats, behöver man göra följande:

9.8.1. Exportera Säkerhetstjänsters IdP/SP metadata

Öppna menyn Autentisering -> IdP SAML.
Fyll i formuläret IdP Metadata med aktuella kontaktuppgifter. Dessa kommer att specificeras i metadatafilen.
Uppdatera informationen genom att klicka på knappen Spara.
Exportera IdP metadata med knappen Exportera. Filen kommer läsas in i ett senare skede, spara den på ett lämpligt ställe.
Öppna nu menyn Administration -> SP SAML.
Utför motsvarande procedur som tidigare (steg 2-4) för SP metadata.

9.8.2. Inläsning av metadata

IdP och SP-metadata måste läsas in till Säkerhetstjänster. Denna import av metadata sker i Säkerhetstjänsters webbgränssnitt.

Importera metadata till Säkerhetstjänster:

Öppna menyn Administration ->SAML Metadata.
Klicka på Välj fil (man kan bara importera en fil i taget). Välj den ena av era metadata-filer (dvs. IdP- eller SP metadata).
Klicka på Importera.
Upprepa importen för den andra metadata-filen.
De importerade metadata-filerna ska nu visas i tabellen ”Manuellt importerad Metadata” under "SP Metadata" och/eller "IdP Metadata".

Figur: Exempel på sidan SAML Metadata

9.8.3. Exportera SAML metadata

Inlästa filer kan exporteras. Denna export av metadata sker i Säkerhetstjänsters webbgränssnitt.

Exportera metadata från säkerhetstjänster:

Öppna menyn Administration ->SAML Metadata.
Välj metadata att exportera genom att i kolumnen Operationer klicka på exportera ikonen. Filen laddas ner för vald metadata.

9.8.4. Extern Autentiseringstjänst

Om ingen lokal autentiseringstjänst installerades, måste systemet ansluta sig till en extern autentiseringstjänst (IdP) för att användare ska kunna logga in i systemet. Detta görs genom att exportera SP metadata, enligt ovan, skicka denna XML-fil till organisationen som tillhandahåller autentiseringstjänsten. Metadata-filen måste importeras i deras system samt att dess (autentiseringstjänstens) IdP-metadata-fil måste importeras i det lokala systemet (korsvis exportering och inläsning).

9.9. Spärrtjänsten

Spärr kan konfigureras upp att antingen gå mot tjänsteplattformen eller köras lokalt. Exempelbilderna nedan visar hur konfigurationen ser ut mot tjänsteplattformen. Hänvisade host-namn och portar för konfigurationerna som beskrivs nedan ska konfigureras mot tjänsteplattformen.

Samtliga konfigurationer av tjänsten ligger i menyn Administration -> Generell Konfiguration.

En lokal uppsättning av Spärr skall normalt replikera sina lokala spärrar till den nationella Spärrtjänsten för att nationella e-tjänster, såsom t.ex. Nationell Patientöversikt (NPÖ), skall få ett så komplett spärrunderlag som möjligt.

Nationell replikering

En lokal spärrtjänst skall endast behöva ladda ner nationellt replikerade spärrar ifall den lokala spärrtjänsten används av system som behandlar data som är registrerad utanför de vårdgivare som den lokala spärrtjänsten redan hanterar spärrar för. Exempel på sådana system är system för sammanhållen journalföring.

Har man t.ex. endast sitt egna journalsystem anslutet till den lokala spärrtjänsten skall man inte behöva lasta ner den lokala spärrtjänsten med alla rikets spärrar.

9.9.1. Block Local Service 3.0.4

Se exempelbilden nedan för konfigurationen.

Öppna konfigurationen Block Local Service 3.0.4.
National block interface ska vara satt till Proxy (Den nationella Spärrtjänsten stödjer endast replikering via RIV TA 2.1).
Synkronisering till nationell Spärrtjänst aktiveras om Replicate to/from national node är ikryssat.
Även valet Send local blocks to national node ska vara ikryssat för att nya spärrar skall replikeras till den nationella tjänsten.

Valet Download blocks from national node kryssas endast i ifall man även behöver hela rikets spärrar (se info-rutan ovan).
Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.

Figur: Block Local Service

9.9.2. Block Web Application 3.0.1

Se exempelbilden nedan för konfigurationen.

Öppna konfigurationen för Block Web Application 3.0.1.
Konfigurationen ska vara inställd efter bilden nedan, för att gå mot tjänsteplattformen.
Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.

Figur: Block Web Application

9.9.3. Block National Webservice V4 WS ProxyImpl for RIV 2.1 1.0.0

Se exempelbilden nedan för konfigurationen.

Öppna konfigurationen Block National Webservice V4 ProxyImpl for RIV 2.1 1.0.0.
Ange Context path for National Webservice, Host name och Port number.
Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.

Figur: Block National Webservice V4 ProxyImpl for RIV

9.10. Konfiguration av PDL-loggning

PDL-loggar kan styras att antingen gå mot lokalt installerad Loggtjänst eller så kan tjänsterna lokal Spärr, Samtycke logga dessa händelser till den nationella Loggtjänsten.

För att använda en extern loggtjänst konfigureras modulen Log Agent Impl till att använda en Proxy samt ange adress och portnummer till den externa loggtjänsten i modulen Log V2 WS Proxy Impl.
För att använda den lokala Loggtjänsten konfigureras modulen Log Agent Impl till att använda Service och ingen konfiguration behövs för modulen Log V2 WS Proxy Impl.

Exempelbilderna nedan visar hur konfigurationen styr PDL-loggar att lagras på en den nationella Loggtjänsten.

Samtliga konfigurationer av tjänsten Logg ligger i menyn Administration -> Generell Konfiguration. För att anslutningen till den nationella Loggtjänsten ska fungera måste förvaltningsorganisationen för nationella Säkerhetstjänster kontaktas för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].

9.10.1. Log Agent Impl 3.0.0

Öppna konfigurationen Log Agent Impl 3.0.0.
1. Om en extern loggtjänst ska användas, sätt Log service till Proxy.
2. Om den lokala Loggtjänsten ska användas, sätt Log service till Service.
Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.

Figur: Log Agent Impl

9.10.2. Log V2 WS Proxy Impl 3.0.0

OBS! Denna konfiguration behöver endast utföras ifall man använder en extern loggtjänst.

Öppna konfigurationen Log V2 WS Proxy Impl 3.0.0.
Ange Context Path, Host name och Port number.
Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.

Figur: Log V2 WS Proxy Impl

9.11. Loggtjänsten - hämtning av arkivloggar från den nationella Loggtjänsten

Om lokala Loggtjänsten installerats, kan den egna vårdgivarens loggar hämtas från den nationella Loggtjänsten via dess hämtningstjänst. För att den lokala installationen av Säkerhetstjänster ska kunna hämta arkiv från nationella Säkerhetstjänster måste förvaltningsorganisationen för nationella Säkerhetstjänster kontaktas för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1]. För att rätt behörighet ska ges, krävs det att det lokala Säkerhetstjänsters SP-metadata bifogas. Se avsnitt Exportera Säkerhetstjänsters IdP/SP metadata

9.11.1. Schemaläggning för automatisk hämtning av arkiv

När schemaläggaren är aktiv och ingen information om föregående arkivnedladdningar existerar, hämtar den gårdagens arkivloggar.
Om tidigare nerladdningar av arkivloggar har lyckats (dvs. har status ”Done”) så utgår schemaläggaren från den senaste arkivhämtningen nästkommande dag. Nedan följer två möjliga scenarion över hur detta kan se ut.

Scenario 1 - Ny installation och inga loggarkiv har hämtats tidigare.
Resultat: Schemaläggaren hämtar gårdagens arkivloggar.

Scenario 2 – Loggarkiv har hämtats tidigare och lokala Säkerhetstjänster har legat nere 3 dagar innan den har gått upp igen.
Resultat: Schemaläggaren hämtar arkivloggar för 3 dagar tillbaka.

Klicka på menyn Administration -> Generell Konfiguration.
Öppna konfigurationen Log Download Archive
I tabellen nedan, konfigurera följande:
1. Careproviders that’s supported – Vilka vårdgivare den lokala Säkerhetstjänsten ska ladda ner arkiv för. Lägg till flera med hjälp av ”+”-tecknet..
2. Context Path – Sökväg till tjänsten för att hämta loggarkiv. (Default: /logdownload_v2/archives/).
3. Host name – Domännamn till nationella tjänsten.
4. Port – Portnummer till nationella tjänsten.
5. Protocol – https eller http (Default: https).
Aktivera därefter schemaläggaren så att den hämtar gårdagens (eller från när den hämtade senast) arkiv per automatik genom att bocka i ”Scheduler enabled”.
Konfigurera när schemaläggaren ska starta, Scheduler start time, det görs i formatet HH:mm (00:00 – 23:59) Default: 02:00 på natten.

Figur: Log Download Archive

9.11.2. Manuell hämtning av (äldre) arkiv ifrån den nationella Loggtjänsten

När den automatiska hämtningen startar, hämtas bara gårdagens arkiv (eller från den tidpunkt när arkiven hämtade senast). Om behov finns, av att hämta äldre arkiv, måste detta utföras manuellt.

Logga in till systemkonsolen med:

telnet localhost 1111
 
osgi>plat:help

Följande kommandon finns att tillgå i systemkonsolen:

archive:dl <parametrar>

archive:status <parametrar>

---[ archive ]----------------------------------------------------------------------------------------------------------
   dl                   Download archives from national log service.
                                -careprovider     careprovider id (HSA-ID).
                                -from             From date (Format: yyyy-MM-dd). This parameter is required if -archive is
                                                  not in use!
                                -archive          Archive id. This parameter is required if -from is not in use!
                                -force            Force archives that already have the status 'Done' to be handled
                                -to               To date (Format: yyyy-MM-dd). If flag is not specified, todays date will
                                                  be used
   status               Archive download status. If limit is not specified limit will be set to 20
                                -code             List by status code (Download,Unzip,Log,Done,Error)
                                -test             Test the connection
                                -limit            How many records should be shown
                                -from             From date (Format: yyyy-MM-dd).
                                -to               To date (Format: yyyy-MM-dd).

Figur: Kommandon för manuell hämtning av arkivloggar

Exempel 1 - Hämta alla arkivloggar från 1:a januari 2017

osgi> archive:dl -careprovider SEMyCareProvider -from 2017-09-01

Exempel 2 - Hämta alla arkivloggar från 1:a januari 2017 till 1:a augusti 2017

osgi> archive:dl -careprovider SEMyCareProvider -from 2017-09-01 -to 2017-09-17

Exempel 3 – Visa status på alla hanterade arkivloggar som har gått fel

osgi> archive:status -code Error

Exempel 4 – Testa anslutningen mot nationella säkerhetstjänsten

osgi> archive:status -test

9.12. Arkivsökning

Syftet med arkivsökningstjänsten är att söka fram arkiverade loggrapporter som är äldre än 18 månader och innefattar sökning i komprimerade arkiv. Här kan man vilja se över de tider på dygnet som den processintensiva genereringen av denna rapport tillåts. Fälten Report execute start interval och Report execute stop interval beskriver det intervall som dessa jobb inte tillåts exekvera (klockan 22.00 till 05.00 i fallet nedan).

Notera att Arkivsökningen kommer att skapa en katalog på den delade diskytan för att lagra den komprimerade xml-filen som sökningen resulterar i.

10. Behörighet

Det är av största vikt att de behörighetsregler som används kontrollerar åtkomsten till den eller de vårdgivare och konsumentsystem som avses innan åtkomst till systemet ges. I Användarhandboken för Säkerhetstjänster [Ref 2] finns det mer information om systemets behörighetskriterier.

Säkerhetstjänster validerar vad en användare har behörighet att göra i systemet utifrån de egenskaperna som finns i dennes SAML-intyg. Användare som autentiserar sig till systemet med ett SITHS-kort får sina egenskaper från HSA-katalogen. En egenskap kan exempelvis vara BIF;Spärradministratör som innebär att användaren har behörighet att hantera spärrar.

Åtkomstkontrollen består av två delar.

Behörighetsregler som läses in i databasen via osgi consolen. Dessa regler kontrollerar behörighet för GUI och tjänster mot aktuell användare och system.
I SP-metadata anges vilka vårdgivare som ska få åtkomst från ett system. Här kommer resursens (spärr, samtyckes etc) vårdgivare att kontrolleras mot listade vårdgivare i SP-metadata för respektive system.

Gemensamt för dessa är kontrollen mot konsumentsystem där tillåtna vårdgivare ska specificeras på båda ställen, dvs i SP-metadata och behörighetsregler i XML-regelfil.

10.1. Behörighetsregler för användare

Säkerhetstjänster validerar vad en användare har behörighet att göra i systemet, utifrån de egenskaperna som finns i användarens SAML-intyg. Användare som autentiserar sig till systemet med ett SITHS-kort får sina egenskaper från HSA-katalogen. En egenskap kan exempelvis vara BIF;Spärradministratör som innebär att användaren har behörighet att hantera spärrar. Dessutom måste man i den lokala Säkerhetstjänsten konfigurera in vilken/vilka vårdgivare denna instans representerar, denna information jämförs sedan med innehållet i användarens SAML-biljett för att på så vis avgöra om användaren är behörig eller ej.

I installationspaketet ingår det en mall för de behörighetsregler som en lokal installation behöver. Reglerna måste anpassas efter era vårdgivare och vad dessa ska få behörighet att göra i systemet.

10.1.1. Behörighet för slutanvändare i Säkerhetstjänsters admin-GUI

För att slutanvändare skall få tillgång till administrationssidan krävs minst ett medarbetaruppdrag i HSA, för de SITHS-kort som används. Var god kontakta Inera [Ref 1] för mer information kring anslutning och dokumentation.

Användaren och medarbetaruppdraget måste innehålla minst följande:

Namn	Beskrivning
HSA Systemroll	Användarens systemroll(er). T ex För åtkomst till spärrar krävs rollen: BIF;Spärradministratör
HSA-id för medarbetaren	Användarens personliga HSA-id.
HSA-id för medarbetaruppdrag	Det valda medarbetaruppdragets HSA-id.
Namn på medarbetaruppdrag	Det valda medarbetaruppdragets namn.
HSA-id för vårdgivare	HSA-id för vårdgivaren som medarbetaruppdraget gäller inom.
Namn på vårdgivare	Namn på vårdgivaren som medarbetaruppdraget gäller inom.
HSA-id för vårdenhet	HSA-id för vårdenheten som medarbetaruppdraget gäller inom.
Namn på vårdenhet	Namn på vårdenheten som medarbetaruppdraget gäller inom.

Se Användarhandboken [Ref 2] för mer detaljerad information om åtkomst och regler i behörighetsadministrationen.

10.1.2. Skapande av behörighetsregler för användare

Från denna version kan man enkelt skapa behörighetsregler via administrationsgränssnittet, i tidigare versioner fanns endast möjlighet att göra detta i Säkerhetstjänsters OSGi-konsol (systemkonsol). Nedan beskrivs båda metoderna.

Skapa behörighetsregler via administrationsgränssnittet under Generell Konfiguration och menyn Behörighet, se bild nedan.

Det första som presenteras i menyn Behörighet är en panel där behöriga administratörer har möjlighet att anpassa systemets behörighetsregler efter en eller flera vårdgivare.

Vilken åtkomst som tilldelas till de olika tjänsterna som ingår i Säkerhetstjänster kommer att baseras per angivna vårdgivare.

Vårdgivarna används även vid generering av WS metadata. Detta är beskrivet mer i detalj i avsnitt Generera WS metadata.

Lägg till vårdgivare:

Fyll i vårdgivarens HSA-id i textfältet VårdgivarId.
Klicka på knappen Lägg till. Observera att systemet inte är anpassat efter vårdgivaren i detta läge.
Återupprepa steg 1-2 för varje vårdgivare som ska tilldelas behörighet. Klicka sedan på knappen Spara lista. Säkerhetstjänsters behörighetsregler kommer därefter att uppdateras efter de tillagda vårdgivarna. Det innebär att reglerna är inlästa och nästa steg är att slå på behörighetskontrollen, se kapitel 11.

Ta bort vårdgivare:

Klicka på soptunnan på den rad som vårdgivaren ni vill ta bort finns på.
Uppdatera behörighetsreglerna sedan genom att klicka på knappen Spara lista

Som alternativ till ovan nämnda metod kan man från installationspaketet hämta en mall för de behörighetsregler som en lokal installation behöver. Reglerna måste anpassas efter era vårdgivare och vad dessa ska få behörighet att göra i systemet.

Mallen ligger under mappstrukturen: <Lokal_sakerhetstjanst>/rules/regler_default_lokal.xml.

När samtliga vårdgivare (som ska ha behörighet att hantera de installerade tjänsterna) är inlagda i de lokala behörighetsreglerna, ska de läsas in i Säkerhetstjänster, antingen via administrationsgränssnittet eller OSGi-konsollen.

Läs in regler via administrationsgränssnittet:
Klicka på Övriga behörighetsfunktioner längst ner på sidan Behörghet. Välj sedan er anpassade regel-fil och importera den.

Via konsol:

Logga in till systemkonsolen. Ange den adress och port till konsolen som valdes i installationsskedet:
```
telnet localhost 1111
```

Läs in reglerna med kommandot:

osgi> acc -import file:///<sökväg till er anpassade regel-fil>

Reglerna är nu inlästa, Avsluta systemkonsolen med kommandot:
```
osgi> disconnect
```

10.1.3. SP-metadata

Förutom att ge andra system (SP) rätt att autentisera sig mot IdP:n används även SP-metadata för att kontrollera att externa vårdsystem och tjänsteplattformen har behörighet att nyttja Säkerhetstjänsternas tjänster. Denna kontroll sker på resursnivå och kontrollerar att resursens (spärr, samtycke etc) vårdgivare är listad i SP-metadata. Det som menas med vårdsystem är ett externt system som ska ha behörighet att anropa någon av de tjänster som ingår i Säkerhetstjänster (dvs. Samtycke, Logg och Spärr) som är definierade i tjänstekontrakten.

I leveransen ingår det en mall för SP-metadata. Metadata-filen anpassas efter följande kriterier:

Systemets HSA-id (entityID).
Systemroll (SystemRole) som kan anta värdet Internal, System eller SystemIgnoreCareProvider. Bara ett alternativ anges för respektive metadatafil.
- Internal: Är tänkt att bara används av proxy och internt av systemet (SP SAML). Alla vårdgivare är tillåtna på alla tjänster
- SystemIgnoreCareProvider: Är tänkt att användas av TP, NPÖ och ev. andra konsumentsystem. Alla vårdgivare är tillåtna men saknar åtkomst till vissa tjänster såsom rapportstatus, loggrapportinfo, loggstatus.
- System: Övriga konsumentsystem där även vårdgivare kontrolleras. Tillåtna vårdgivare listas i metadatafilen.
  - HSA-id för de vårdgivare som som ett systemet ska vara behörig till och då anges urn:sambi:names:attribute:careProviderHsaId=VårdgivareID. Används bara tillsammans med systemRole=System

Mallen ligger under mappstrukturen: <sakerhetstjanst>/example/metadata/example-system-metadata.xml.
Bilden nedan visar exempel på hur en metadata-fil för ett konsumentsystem ser ut för dessa alternativ. Värdet i entityID är det som ska ersättas med konsumentsystemets HSA-id. OBS! Lista med behöriga vårdgivare ska ej anges om systemrollen ärInternal eller SystemIgnoreCareProvider.

Figur: Exempel på SP-metadata fil som kan läsas in i systemet

10.1.4. Läs in SP-metadata

Läs in SP-metadata för de system som ska ha behörighet till Säkerhetstjänsten. Behörighet ska ges till Tjänsteplattformen om man väljer att ansluta sig via den.

Ta filerna som finns i katalogen:
- /tmp/Sakerhetstjanster<version>/metadata
Läs in dessa metadatafiler via Admin GUI. Se avsnitt Inläsning av metadata

10.1.5. Generera WS metadata

Menyn Behörighet innehåller en panel där behöriga administratörer kan generera webservice (WS) metadata. Som tidigare beskrivet används WS metadata för att tilldela åtkomst för externa vårdsystem och andra tjänster. Detta är beskrivet i djupare detalj i Användarhandbokens avsnitt Behörighet för externa vårdsystem och framåt.

Panelen innehåller alternativ för att generera WS metadata anpassat per vårdgivare eller WS metadata där anrop från, oavsett vårdgivare, tillåts. Behörighetsstyrningen sker i det senare alternativet istället i tjänsteplattformen (TP).

Figur: Panelen för att generera WS metadata.

Ett krav för att generera WS metadata, som behörighetsstyr per vårdgivare, är att dessa vårdgivare redan är konfigurerade. En rekommendation är att först kontrollera den listan innan generering sker. Se avsnitt Hantera vårdgivare i Användarhandboken. Om det anropande systemet ska tilldelas åtkomst, oavsett vårdgivare, ska kryssrutan Tillåt alla vårdgivare (TP) vara ikryssad.
Fyll i fältet Entity-id som WS metadata-filen ska gälla för. Entity-id är en unik identifierare för det anslutande systemets funktionscertifikat. Detta id listas under ”SERIALNUMBER” under ”Subject” i certifikatets detaljerade information. Man kan exempelvis använda en webbläsare för att ta del av informationen, förutsatt att certifikatet är installerat.
Klicka på knappen Generera metadata. En WS metadata-fil kommer nu att genereras och exporteras till ett XML-format. Se avsnitt WS Metadata i Användarhandboken för inläsning av filen.

10.1.6. Ta reda på HSA-id

Det går att ta reda på HSA-id:et för vårdsystemet eller tjänsteplattformens funktionscertifikat om man har tillgång till certifikatfilen.

Har man tillgång till certifikatfilen kan man öppna denna och ta reda på id:t genom:
Öppna certifikatets leg.cer fil och klicka på Details.
Bläddra i listan som visas. Klicka på informationsfältet Subject.
En informationsruta visas. Det Serial number som visas i rutan är certifikatets serienummer, dvs. det HSA-id som ni ska specificera i metadata-filen som ni anpassar till systemet.

11. Aktivera filter och logga in

11.1. Aktivering av filter för autentisering och åtkomstkontroll

Säkerhetstjänster använder sig av två filter:

Autentiseringsfilter - Filtret kräver att användaren ska autentisera sig för att få åtkomst till Säkerhetstjänster.
Behörighetsfilter - Filtret styr vilken behörighet användaren har i Säkerhetstjänster. Det kan t ex innebära att en användare som har rollen som spärradministratör endast får hantera spärrar i systemet.

Efter att systemet installerats och konfigurerats ska filtren aktiveras:

Logga in i systemkonsolen med:
```
telnet localhost 1111
```
Aktivera autentiseringsfiltret med kommandot:
```
osgi> spfilter -on
```
Aktivera behörighetsfiltret med kommandot:
```
osgi> authz -on
```
Avsluta systemkonsolen med kommandot:
```
osgi> disconnect
```

11.2. Logga in i Säkerhetstjänster

När ni har installerat och konfigurerat upp systemet, starta webbgränssnittet för lokala Säkerhetstjänster:

https://[servernamn]/spadmin

Kontrollera därefter att webbgrässnittet nu kräver SITHS-kort inloggning och att ett medarbetaruppdragsval är obligatoriskt om användaren har fler än ett medarbetaruppdrag i HSA-katalogen.

12. Systemadministration

12.1. Start och stopp

12.1.1. Stoppa lokala Säkerhetstjänster

Om en nod i klustret behöver stoppas, exekvera kommandot:

/etc/init.d/sak_server stop

12.1.2. Starta lokala Säkerhetstjänster

Om en nod i klustret behöver startas, exekvera kommandot:

/etc/init.d/sak_server start

Man bör alltid säkerställa att systemet startat korrekt genom att kontrollera att systemloggen inte innehåller några fel (Exceptions). Avvakta upp till en minut så att lokala Säkerhetstjänster har givits tid att starta upp och kontrollera därefter den senaste loggfilen (läs mer om loggning och felsökning i avsnitt Systemlogg (audit) .

12.2. Logga in i lokala Säkerhetstjänster

När ni har installerat servern kan ni gå till det grafiska webbgränssnittet för lokala Säkerhetstjänster: https://[servernamn]/spadmin

Där testas inloggningsförfarandet med val av SITHS-kort och val av medarbetaruppdragsval.

12.2.1. Logga in med SITHS-kort

Sätt in SITHS-kortet i kortläsaren. Öppna webbläsaren och ange adressen till webbgränssnittet.
Ange PIN-koden för SITHS-kortet i autentiseringsrutan. Klicka därefter ok. Fönstret ”Välj Medarbetaruppdrag” visas.
Klicka på ett presenterat uppdrag för att fortsätta.
1. Här presenteras enbart aktiva medarbetaruppdrag, alltså uppdrag på vårdenheter som är aktiva.
2. Om vyn ”Välj Medarbetaruppdrag” inte visas, beror det på att:
  1. Medarbetaren har bara ett uppdrag vilket då väljs automatiskt.
  2. Medarbetaren är redan inloggad och har en aktiv session (t.ex. om medarbetaren först loggar in i NPÖ och därefter i samma webbläsare startar Säkerhetstjänster’s webbgränssnitt). Det uppdragsval som gjordes vid första inloggningen används automatiskt vid efterföljande inloggning (SSO).
Inloggningen till webbgränssnittet är klart.

I webbgränssnittet gäller generellt att endast de knappar eller funktioner som medarbetaren har behörighet till visas och de övriga funktionerna döljs.Vid osäkerhet på vilket uppdrag som ger rättighet till vad, prova att först logga ut och därefter logga in igen i webbgränssnittet med något annat tänkbart uppdrag. Behörigheten styrs med hjälp av de uppdrag som är kopplade till SITHS-kortet och dessa hämtar systemet från HSA. Om behörighet till någon funktion saknas, kontakta HSA-support eller motsvarande för att lägga till de uppdrag och behörigheter som behövs.

12.3. Hantera aktiviteter i OSGi

Systemet har en inbyggd systemkonsol (OSGi-konsol) som är åtkomlig via Telnet på port 1111 (om inget annat angavs under installationen). Systemkonsolen används endast vid produktsupport eller felsökning, samt av- och påslag av autentiseringsfiltret.

12.3.1. Verifiera att systemets alla bundlar är uppstartade

Logga in till systemkonsolen:
```
telnet localhost 1111
```
Verifiera att alla beroenden är uppfyllda med kommandot:
```
osgi> state
 
Utskriftsexempel:
osgi> state
Id   Context                                                                    State                    State Information
osgi>
```
Listas inte någon bundel här är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel.
Om någon bundel ej startar igång, testa att starta om säkerhetstjänster. Kvarstår problemet måste felsökning påbörjas.

12.3.2. Aktivering av filter för autentisering och åtkomstkontroll

Gå in i systemkonsolen med:
```
telnet localhost 1111
```
Aktivera/Inaktivera autentiseringsfiltret med kommandot:
```
osgi> spfilter -on
osgi> spfilter -off
```
Aktivera/Inaktivera behörighetsfiltret med kommandot:
```
osgi> authz -on
osgi> authz -off
```
Avsluta systemkonsolen med kommandot:
```
osgi> disconnect
```

12.4. Systemlogg (audit)

Lokala Säkerhetstjänster producerar en systemlogg för teknisk förvaltning och felsökning, som lagras på filsystemet under uppstartsfasen. Systemloggen lagras i följande katalog (enligt standardinstallationen):

Exempel Linux:
/sakerhetstjansten/Sakerhetstjanst<version>/local/log/

Exempel Windows:
C:\Program Files\Inera\Lokal Sakerhetstjanst<version>\sakerhetstjansten\log

Systemet lagrar systemloggarna i första hand i databasen (schemat audit) och kan nås genom kommandot audit från systemkonsollen, se avsnitt Sök i systemloggen. Om inte databasen är uppsatt för att kunna hantera systemloggar (som sker i installationsskedet av Säkerhetstjänster) skrivs systemloggarna till filen ovan istället.

Vid uppstart av systemet kan systemloggningen temporärt ske till fil (för att få uppstartsloggar), men den övergår snabbt till att logga till databas när loggfunktionen är startad.

12.4.1. Sök i systemloggen

Logga in till systemkonsolen med:
```
telnet localhost 1111
```

Sök i loggen enligt:

(Alla error loggar den senaste timmen)
osgi> search -level error -time 1h
(Alla loggar den senaste timmen)
osgi> search -time 1h
(Alla loggar de senaste 5 minuterna)
osgi> search -time 5m

Avsluta systemkonsolen med kommandot:
```
osgi> disconnect
```

12.4.2. Status för loggfunktionen

Av olika anledningar (t ex nätverksproblem) kan lagring av systemloggar misslyckas till aktuell källa. Om lagring av loggar till t ex databas skulle misslyckas kommer systemet gå vidare med att lagra/skriva loggar till nästkommande källa enligt en förinställd prioritetsordning. Systemet kommer dock automatiskt att återgå till det normalläge när felet ej längre kvarstår.

Nedan följer en beskrivning hur detta kan utföras manuellt.

Logga in till systemkonsolen med:
```
telnet localhost 1111
```

Nedan kommando ger status för systemloggning:

osgi> monitor -filter LogTarget
Id                                      Type        Timestamp                             Value               Description
com.logica.se.iac.logging.impl.LogTarget
console                                 String      2017-09-11 14:30:21:907               Operational
db                                      String      2017-09-11 14:30:21:907               Error
db.errorCount                           String      2017-09-11 14:30:21:907               2
db.errorInstant                         String      2017-09-11 14:30:21:907               2017-09-11 14:23:06
db.errorLastRetry                       String      2017-09-11 14:30:21:907               2017-09-11 14:29:46
db.errorMessage                         String      2017-09-11 14:30:21:907               java.lang.Exception
file                                    String      2017-09-11 14:30:21:907               Operational
mongo                                   String      2017-09-11 14:30:21:907               Operational

Operational är normalläget. Är någon källa markerad med Error kan dessa återställas. Här visas att Mysql (db) är i status Error, samt information om felet, när felet först uppstod, senaste tidpunkt för återförsök att logga till källan samt totalt antal återförsök.

Återställa statusvariabler görs enligt:

(Kommando för att återställa Mysql)
osgi> monitor -reset com.logica.se.iac.logging.impl.LogTarget/db
(Kommando för att återställa Mongo)
osgi> monitor -reset com.logica.se.iac.logging.impl.LogTarget/mongo
(Kommando för att återställa File)
osgi> monitor -reset com.logica.se.iac.logging.impl.LogTarget/file
(Kommando för att återställa Console)
osgi> monitor -reset com.logica.se.iac.logging.impl.LogTarget/console

Avsluta systemkonsolen med kommandot:
```
osgi> disconnect
```

12.5. Felsökning

Om problem uppstår där lokala Säkerhetstjänster misstänks vara orsaken bör följande saker undersökas:

Monitorera MySQL-processen och kontrollera att databasen svarar på enkla förfrågningar.
Monitorera MongoBD-processen och kontrollera att databasen svarar på enkla förfrågningar.
Monitorera Java-processen på applikationsserver och kontrollera att att det går att logga in i det grafiska webbgränssnittet, https://[servernamn]/spadmin.
Vid akuta problem, starta om applikations- och/eller databasservern och kontrollera systemloggen.

Vid produktfelanmälan måste alla systemloggar kring felet samt ett beskrivande scenario kring vad som föranledde felet, bifogas felanmälan.

13. Test

För att verifiera systemet kan följande anvisning användas:

Test av installation eller uppgradering 2.17

14. Förvaltning och underhåll

14.1. Periodiskt underhåll

Läs Systemlogg (audit) för information angående hur systemloggar lagras och söks i.

Hantera aktiviteter i OSGi beskriver hur systemet kan hanteras och kontrolleras i systemkonsolen (OSGi).

14.2. Backup

14.2.1. Applikationsserver

Systemets delade diskyta - Innehåller Loggtjänstens arkivloggar och systemets gemensamma konfiguration bl.a.

Windows: default C:\share
Linux: default /share

Respektive applikationsserver data-katalog

Windows: default C:\Program Files\Inera\Lokal Sakerhetstjanst<version>\sakerhetstjansten\data)
Linux: default: /sakerhetstjansten/Sakerhetstjanst<version>/local/data

14.2.2. Databasserver Mysql

Allt data som säkerhetstjänster lagrar i mysql ska tas backup på. Se tillverkarens instruktioner för hur backup/restore görs.

14.2.3. Databasserver MongoDB

Då innehållet i MongoDB för Loggtjänsten kan återställas av applikationen från arkiv-loggarna är det inte nödvändigt att utifrån ett återställningsscenario ta backup av MongoDB-databasen. Dock går det betydligt snabbare att göra en restore med hjälp av mongoDB:s interna backup/restore funktionalitet vilket gör att det är den rekommenderande lösningen. Övrigt data som lagras i mongoDB är ej känsligt och behöver ej återställas vid en eventuell restore. Se tillverkarens instruktioner för hur backup/restore görs.

14.3. Uppgradering

Lokala Säkerhetstjänster kan mjukvaruuppgraderas då nyare versioner av produkten finns tillgängliga. Mer information om detta ges för respektive uppgradering. Var god kontakta Inera för information kring aktuella versioner [Ref 1].

15. Avinstallation

Avsnittet innehåller anvisningar för avinstallation av lokala Säkerhetstjänster. Avinstallationen tar bort tjänsten lokala Säkerhetstjänster.

15.1. Avinstallera lokal Säkerhetstjänst

Börja med att stoppa tjänsten, exekvera kommandot:

/etc/init.d/sak_server stop

Därefter avinstalleras tjänsten, exekvera kommandot:

/etc/init.d/sak_server removedaemon

Tjänsten ska tas bort på samtliga noder där Säkerhetstjänster är installerad. Upprepa samma procedur beskriven ovan på samtliga noder.

15.2. Efterarbete

När systemet är avinstallerat kan man genomföra en upprensning av resterande Säkerhetstjänster-relaterad data. De kataloger som då ska tömmas är följande:

/sakerhetstjansten (på samtliga noder)
/share (behövs endast rensas på en nod, då detta är en delad diskarea).

Obs! Det kan vara bra att ta en backup på den delade diskytan, om systemet behöver återställas.

Space shortcuts

Page tree

2.17 Installation och administration (Linux)

1. Inledning

1.1. Allmänt

1.2. Begrepp

1.3. Referenser

2. Systemkrav

2.1. Diskyta

2.1.1. Delad diskyta för Säkerhetstjänster

2.1.2. Diskyta för MySQL

2.1.3. Diskyta för MongoDB

2.2. Tidssynkronisering

2.3. Lastbalanserare

3. Plattform och tredjepartsprodukter

3.1. Java

3.1.1. JCE - Java Cryptography Extension

3.2. MySQL

3.3. MongoDB

3.4. Lastbalanserare

3.5. Funktionscertifikat

3.5.1. Ytterligare funktionscertifikat

3.6. CSP - Cryptographic Service Provider

3.7. Kluster med Infinispan (Distributed in-memory cache)

3.8. Ciphersuites som används

3.9. Telnet

4. Säkerhetstjänsters beroenden till externa system

4.1. Behörighet externa system

4.2. HSA-WS

4.3. HSA-RIVTA

4.4. Revokeringskontroll av certifikat

4.5. Personuppgiftstjänsten - Personuppgiftstjänsten

4.6. Nationell Spärrtjänst*

4.7. Nationell Loggtjänst*

4.8. Tjänsteplattformen*

5. Systemöversikt

5.1. Ingående servrar

5.2. Exempelinstallation och konfiguration

5.2.1. Lokala Säkerhetstjänster installerade med Spärr och Autentisering

5.2.2. Lokala Säkerhetstjänster installerade med alla tjänster

5.3. Översikt adresser och portar

5.3.1. Applikationsserver

5.3.2. Databasserver

5.4. Adressöversikt gränssnitt

5.4.1. Webbgränssnitt admin-GUI

5.4.2. Webbgränssnitt Autentiseringstjänsten

5.4.3. Webbtjänstegränssnitt för autentisering rika klienter - STS

5.4.4. Webbtjänstegränssnitt WS-port - RIV TA-tjänster och REST-tjänst

6. Installation av databasserver

6.1. Installera MySQL

6.1.1. Specifika MySQL-inställningar

6.1.1.1. Teckenuppsättning

6.1.1.2. Minnestilldelning "innodb_buffer_pool_size"

6.1.1.3. Binary logging "binlog_format"

6.1.1.4. InnoDB Tablespace "innodb_file_per_table"

6.1.2. Skapa användare som applikationsservern ska använda

6.1.3. Skapa upp databasscheman

6.2. Installera MongoDB

6.2.1. MongoDB på en eller tre noder

6.3. Installera MongoDB 3.4.x

6.3.1.1. Konfigurera replikeringen på ena noden (den som skall vara PRIMARY från start).

6.3.1.2. Konfiguration för singelnod-system

6.3.2. Skapa databaser, index och användare för Säkerhetstjänster

6.3.3. Verifiera MongoDB-konfiguration

6.3.4. Konfigurationsfil

7. Installation av applikationsserver

7.1. Installera Java och JCE

7.2. Installation av lokala Säkerhetstjänster

7.2.1. Installera systemet

7.2.2. Tabell över installationsvärden vid installation

7.2.3. Installation av SingelServer eller Första noden i en fail-over lösning

7.2.4. Installation på Andra noden i en failover lösning

7.3. Linux-specifika inställningar för applikationsservern

7.4. Installation Infinispan cluster cache över TCP

7.5. Installation utan databasen MongoDB

8. Uppstart av applikationsserver

8.1. Uppstart av lokal Säkerhetstjänst på nod 1

8.2. Anslut till webbgränssnitt

8.3. Uppstart av lokal Säkerhetstjänst på övriga noder

9. Systemkonfiguration