Installation och administration. Lokala Säkerhetstjänster 2.3 (Windows)

Transkript

1 2.3 (Windows)

2 Innehållsförteckning 1 INLEDNING Allmänt Konventioner Begrepp Referenser SYSTEMKRAV Operativsystem Diskyta Delad diskyta för Säkerhetstjänster Diskyta för MySQL Diskyta för MongoDB Tidssynkronisering PLATTFORM OCH TREDJEPARTSPRODUKTER Java JCE, Java Java Cryptography Extension MySQL MongoDB Lastbalanserare Certifikat Ytterligare certifikat CSP, Cryptographic Service Provider Terracotta Beroenden till externa system HSA-WS Revokeringskontroll av certifikat PU-tjänsten* Nationell Spärrtjänst* Tjänsteplattformen* SYSTEMÖVERSIKT Ingående servrar Portöversikt Adressöversikt gränssnitt INSTALLATION AV DATABASSERVER Installationsanvisningar för MySQL Skapa ny användare Installationsanvisningar för MongoDB Installera MongoDB på tre noder Indexering Skapa nödvändiga databaser Konfigurationsfil...36 Sid 2/115

3 6 INSTALLATION AV APPLIKATIONSSERVER Installera Java och JCE INSTALLATION AV LOKALA SÄKERHETSTJÄNSTER Installera systemet på Windowsmiljö Installation av SingleServer Installation på första noden i en fail-over lösning Installation på andra noden i en fail-over lösning Installation på övriga noder (nod3- nodx) i en fail-over lösning 50 8 UPPSTART AV SERVER Uppstart av Terracotta Uppstart av lokal Säkerhetstjänst på första noden Anslut till webbgränssnittet Uppstart av lokal Säkerhetstjänst på övriga noder SYSTEMKONFIGURATION Webbgränssnittet Koppling till HSA-WS Konfiguration av HSA-WS PU-tjänsten Konfiguration av spärr Block Local Service Block Web Application Block National Webservice Proxy for RIV Block Common Webservice Proxy v Block Common Webservice Proxy for National v Block National Accesscontrol Webservice Proxy Konfiguration av Loggtjänsten Log Agent Impl Log WS Proxy Impl Konfiguration av samtycke Consent Webservice Proxy ConsentPDL GWT Application Konfiguration av patientrelation Patientrelation Web Application Patientrelation Webservice Proxy Konfiguration av hämtningstjänsten Ta bort root-certifikat för test vid en produktionssättning Konfiguration av CDC BEHÖRIGHET Behörighetsregler för användare Uppsättning av behörighetsregler för användare Läsa in regler IdP/SP Metadata Behörigheter för konsumentsystem eller för tjänsteplattformen Anpassa metadata för konsumentsystem eller mot tjänsteplattformen 76 Sid 3/115

4 10.4 Inläsning av metadata Systemegenskaper Extern Autentiseringstjänst Aktivering av autentiseringsfilter och åtkomstkontroll SYSTEMADMINISTRATION Logga in i lokala Säkerhetstjänster Start och stopp Hantera aktiviteter i OSGi Aktivering och avaktivering av autentiseringsfilter Systemlogg Sök i systemlogg Felsökning FÖRVALTNING OCH UNDERHÅLL Hämtning av arkivloggar från nationella Säkerhetstjänster Manuell hämtning Schemaläggare Hämtning av nationella arkiv Periodiskt underhåll Övervakning Uppgradering AVINSTALLATION Avregistrera tjänster...88 I. APPENDIX A Skapa behörighetsregler och metadata manuellt 89 Manuell hantering av behörighetsregler...89 Manuell hantering av metadata för konsumentsystem...90 II. APPENDIX B - Konfigurera den lokala brandväggen 93 III. APPENDIX C - Skapa separat servicekonto 93 Lägg till behörigheter i registret IV. APPENDIX D - Förutsättningar för en fail-over lösning 115 Delad diskyta Sid 4/115

5 Revisionshistorik Version Författare Kommentar 0.1 Logica Dokument upprättat 0.2 Logica Förtydligande i text 0.3 Logica Uppdaterat portbeskrivning 0.4 Logica Uppdaterat installation, övervakning 0.5 Marcus Tinnsten Uppdaterat installationsguide 0.6 Marcus Tinnsten Uppdaterat portbeskrivning 1.0 Marcus Tinnsten Dokument färdigställt till systemversion Marcus Tinnsten Uppdaterat kapitlet systemkonfiguration 1.11 Marcus Tinnsten Nytt avsnitt i systemkonfiguration 1.2 Marcus Tinnsten Dokumentet justerat för Örjan Olofsson Uppdaterat installationsguide samt kapitlet systemkonfiguration 1.4 Örjan Olofsson Uppdaterat installationsguide (klustrat alternativ) samt kapitlet systemkonfiguration replikering till nationell spärrtjänst 1.5 Örjan Olofsson Uppdaterat 1.6 Stefan Eriksson Uppdaterad efter intern granskning 1.7 Marcus Tinnsten Uppdaterad för systemversion Örjan Olofsson Uppdaterad efter intern granskning 1.9 Magnus Lexhagen, Örjan Olofsson och Marcus Tinnsten 2.0 Magnus Lexhagen, Örjan Olofsson och Marcus Tinnsten Uppdaterad för systemversion 2.3 Dokument färdigställt till systemversion 2.0 Sid 5/115

6 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ärr) som kan installeras separat eller tillsammans som ett komplett paket. Detta dokument beskriver installationen av lokala Säkerhetstjänster för Windows. Dokumentet beskriver i huvudsak: Installation av databasserver (MySQL och 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 db doc example install rules schema_wsdl Beskrivning Konfigurationsfiler och databasskript All dokumentation Exempelkod för hur man kan ansluta en SP till IdP:n (lokal autentiseringstjänst) Installationsskript och systemkomponenter. Innehåller behörighetsregler som ska modifieras och läsas in i systemet Tjänstekontrakten för lokala Säkerhetstjänster 1.2 Konventioner I detta dokument finns vissa typografiska markeringar för att klargöra instruktioner. Dessa bör tolkas enligt följande: Konvention Kursiv Kommando [Ref nr] Beskrivning Används vid hänvisning till ett specifikt namn, adress, eller annat värde som inte är löpande text. Används för kommandon till systemet. Referensangivelse Sid 6/115

7 1.3 Begrepp Begrepp Autentiseringstjänst Bundle CDC CRL HA HSA IdP Metadata OCSP PDL PU-tjänst REST RIV RIV TA SAMBI Beskrivning Den tjänst som kontrollerar användaren kreditiv och utfärdar en SAML-biljett. Komponent till ett program Common Domain Cookie En webbläsarkaka som lagrar historik från tidigare besökta IdP:er. Certificate Revocation List En lista med certifikat och dess status (ex. revokerat den 12 december 2011). Dessa listor uppdateras oftast med jämna intervaller. High Availablity. En tjänst som har hög tillgänglighet. 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. Identity Provider. Tjänst som autentiserar en aktör och utfärdar, i detta fall, en SAML-biljett. Autentiseringstjänsten som levereras med Säkerhetstjänster är en IdP, som även kan installeras som en egen lokal IdP-tjänst. 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 IdP:n och SP:n. 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 aktuellt status för certifikatet som efterfrågas. Patientdatalagen Personuppgiftstjänst Representational State Transfer Regelverk för Interoperabilitet inom Vård och omsorg. 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. SAML-profil för samverkan för Behörighet och Identitet inom hälsa, vård och omsorg. Beksriver hur egenskaper namnsätts i SAMLbiljetten. janst/dokument-for-autentiseringstjansten/ Sid 7/115

8 SAML SAML biljett SITHS SP Tjänsteplattformen (TP) Security Assertion Markup Language En standard som beskriver hur egenskaper och dess värden skall beskrivas i XML format. Ett intyg som Autentiseringstjänsten utfärdar som innehåller en samling med egenskaper enligt SAML. Inom häsla, vård och omsorg används SAML profilen SAMBI. SITHS är en nationell lösning för säker IT i hälso- och sjukvården. Service Provider. Den som erbjuder en tjänst, t ex Samtyckestjänsten. De lokala tjänsterna i Säkerhetstjänsterna grupperas som en SP. Tjänsteplattformen är en nationell teknisk plattform som förenklar, säkrar och effektiviserar informationsutbytet mellan olika IT-system inom vård och omsorg Referenser Referensnr Namn Adress Ref 1 Inera AB Ref 2 Inera AB Anvandarhandbok_Sakerhetstjanster.pdf Sid 8/115

9 2 SYSTEMKRAV 2.1 Operativsystem levereras med installationsanvisningar för Windows Server 64bit. Denna leverans är kvalitetssäkrat på Windows Server 2008 R2 64bit. bör driftsättas med minst tre dedikerade maskiner, en applikationsserver och två databasservrar. Applikationsservern bör vara flerkärnig med minst 12 GB RAM. MySQL databasservern för bör vara flerkärnig med minst 8 GB RAM. MongoDB servern för bör vara flerkärnig och hur mycket RAM som krävs är beroende på hur mycket respektive vårdgivare loggar. Riktlinje är att 40 miljoner loggar med dess index tar c:a 20 GB RAM. 2.2 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. systemets gemensamma konfiguration finns lagrat. Den delade diskytan kan t.ex. sättas upp med hjälp av en samba-share, Microsoft cluster disk eller NFS delning och skall vara redundant så att man inte får en SinglePointOfFailure, då systemet kräver den delade diskytan för att kunna starta. Default är namnet på katalogen: <enhet>\share i konfigurationen nedan Delad diskyta för Säkerhetstjänster Den delade diskytan (<enhet>\share) för applikationsservrarna bör minst vara på 100 GB Diskyta för MySQL Diskytan för MySQL (<enhet>\mysql) bör minst vara på 200 GB Diskyta för MongoDB Diskytan för MongoDB (<enhet>\mongodb) är helt beroende av hur mycket som respektive vårdgivare loggar. Riktlinje är att 40miljoner loggar tar c:a 115 GB diskarea. Sid 9/115

10 2.3 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. Vi rekommenderar att rådfråga dom som ansvarar för just er server drift. Sid 10/115

11 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 starta tjänsten krävs Oracle Java SE 6 JDK (senaste update) 64-bitar, som finns att hämta på: Systemet är kvalitetssäkrat med JDK 6 update 35. Observera att man ännu inte kan köra med Java JCE, Java Java Cryptography Extension Det krävs även ett tillägg, download html, som måste installeras för att kunna nyttja 256-bitars kryptering. 3.2 MySQL kräver databasservern MySQL för Windows. Systemet är kvalitetssäkrat med MySQL Community Server och våra rekommendationer är därmed att ni använder en version ur 5.5-serien. 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. 3.3 MongoDB Mongodatabasen (MongoDB) är en lättviktig (NoSQL) databas som används för att hantera uppföljning av verksamhetsloggar (PDL-loggar). MongoDB håller PDL-loggar i ca 18 månader (konfigurerbart) tillbaka i tiden och är den databas 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 en rapport för uppföljning. MongoDB är inget som följer med Säkerhetstjänsters installationspaket, utan är en tredjepartsprodukt som måste hämtas från Internet. Systemet är kvalitetssäkrat mot MongoDB server Därför rekommenderas att man installerar en version ur 2.4-serien. Hur databasen ska sättas upp på bästa sätt diskuteras i kapitel 0 Det medföljer skript som hjälper till att skapa dessa scheman och läsa in tillhörande sql skript. Det finns ett skript för Windows och ett för Linux, create_databases_windows.bat och create_databases_linux.sh. Observera om det redan finns scheman med samma namn kommer dessa att tas bort. Sid 11/115

12 Det går genom att gå in i konfigurationsfilerna och manuellt ändra schema namnen om man önskar använda annan namnsättning, dock ej i den initiala installationen. Antingen redigerar man skriptet och lägger in användarnamn och lösenord eller så kan man starta skriptet med argument, första argumentet är användarnamn, andra är lösenord och tredje är prefix för databasnamnen. Exempel: create_databases.bat root password example_ Default användas inte prefix. När man startat scriptet får man frågan om man vill skapa om dessa databaser, se exempel i figur: Skapa databaser. Välj y för att fortsätta. Figur 4: Skapa databaser Då börjar den skapa om databasen. Finns inte databaserna sedan tidigare kommer man få ett felmeddelande database doesn t exist, detta kan man ignorera, se exempel i figur: Databas finns inte. Figur 5: Databas finns inte Finns däremot databaserna redan får man meddelande, se exempel i figur: Databas finns Figur 6: Databas finns Sid 12/115

13 Man får inget meddelande om att det gick bra att skapa databasen. Verifiera sedan att databaserna har skapats genom att logga in i mysql-prompten och skriva: show databases; se exempel i figur: Lista databaser. Figur 7: Lista databaser För att kolla om det finns tabeller i ett schema kan man gå in i schemat (t.ex. use accesscontrol;) och skriva show tables; se exempel i figur: Lista tabeller. Figur 8: Lista tabeller. 3.4 Lastbalanserare En lastbalanserare som klarar HTTPS krävs för att köra lokala Säkerhetstjänster med skalskydd och/eller trafikdirigering. Anvisningar för lastbalanserare ingår inte i detta dokument. Lastbalansering till applikationsservern kan ske med round-robin då all sessionsdata (SSLsessioner) delas mellan applikationsservrarna. Hur övervakning av applikationsservern kan ske finns beskrivet i kapitel 12.3Övervakning..Som ett minimum bör de externa HTTPS-portarna som används TCP-monitoreras innan lastbalansering sker till applikationsservern. Sid 13/115

14 3.5 Certifikat Innan installation av lokala Säkerhetstjänster i produktionsmiljö påbörjas måste ett SITHStjänstecertifikat (funktionscertifikat) för legitimering införskaffas, utfärdade för lokala Säkerhetstjänsters applikationsserver. Certifikat används för att identifiera applikationsservern vid all sorts kommunikation. Certifikaten skall vara utfärdade till det värdnamn som skall användas för applikationsservern. Var god kontakta Inera för information kring SITHScertifikat [Ref 1] Ytterligare certifikat Om lokala Säkerhetstjänster ska nyttjas tillsammans med andra IdP:er i en federation krävs ytterligare ett SITHS-tjänstecertifikat(legitimering) 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 denna IdP ha ett certifikat där också, t.ex. IdP.commondomain.example.com 3.6 CSP, Cryptographic Service Provider För att slutanvändare skall kunna använda hårda certifikat (t.ex. SITHS-certifikat) för att autentisera sig och ansluta sig till administrationsgränssnittet för lokala Säkerhetstjänster via webbläsare krävs tillgång till en CSP på användarens dator. T.ex. kan Net id användas. Var god kontakta Inera för information kring SITHS och Net id [Ref 1]. 3.7 Terracotta Vår rekommendation är att Säkerhetstjänster installeras med en klustrad uppsättning. Till det ändamålet används Terracotta för att koordinera den klustrade uppsättningen. Den ena Terracotta-noden agerar Master och den andra Terracotta-noden agerar Slave. Noderna delar resurser (som exempelvis systemets konfigurationer) på en delad diskyta. Fördelen med klustret är att det bidrar till att systemet får högre prestanda, skalbarhet och tillgänglighet. Om exempelvis en av noderna slutar fungera, går inte hela systemet ner. Kapitel 7 innehåller instruktioner för en klustrad uppsättning med Terracotta på två noder. Installation görs i samband med resterande installation av applikationsservern. Sid 14/115

15 3.8 Beroenden till externa system HSA-WS HSA-WS är en webtjänsteanslutning till underliggande HSA-katalog. Lokala Säkerhetsjänster använder HSA-WS version 2.19 eller senare. Applikationsserverns tjänstecertifikat för legitimering måste också läggas in i HSA-strukturen. Certifikatet behöver ha tillstånd att anropa följande operationer: GetCareUnit GetCareUnitList GetHsaPerson GetHsaUnit GetMiuForPerson Ping använder 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. För att en användare ska kunna autentisera sig krävs det att användaren finns upplagd i HSA. Det finns dock inget krav på att användaren måste ha ett medarbetaruppdrag. Ifall användaren saknar medarbetaruppdrag kommer en tom SAML-biljett att skapas utan egenskaper för användaren och det är upp till konsumenten av SAML-biljetten, SP:n, att avgöra vad som skall ske då (t.ex. visa ett felmeddelande). HSA-WS ingår inte i produkten lokala Säkerhetstjänster. Adresser som kan användas för att nyttja HSA-WS: Test: Produktion: 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 klientcertifikat är spärrat och därmed inte godkänt för autentisering. 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 SITHS CA v3 SITHS CA v Sid 15/115

16 Exempel på adresser till crl och ocsp (Test): Certifikat Crl adress Ocsp adress SITHS_Type_1_CA_v1 _PP SITHS CA TEST v3 SITHS CA TEST v pp.crl a.com PU-tjänsten* Personuppgiftstjänsten (PU-tjänsten) är en tjänst som innehåller personuppgifter. Lokala Säkerhetstjänster använder PU-tjänsten för att hämta patientens namn i användargränssnittet. Adresser som kan användas för att nyttja PU-tjänsten: Test: Produktion: *PU-tjänsten används enbart ifall man installerar någon av tjänsterna: Samtycke, Patientrelation och Spärr 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 tjänsten samt konfigurera vilka vårdgivare som denna lokala spärrtjä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]. Adresser som kan användas för att nyttja Nationell Spärrtjänst: Test: Produktion: *Nationell Spärrtjänst används enbart om tjänsten Spärr installeras. Sid 16/115

17 3.8.5 Tjänsteplattformen* Installerar man samtyckestjänsten och/eller patientrelationstjänsten måste man registrera dessa som producenter i tjänsteplattformen. Detta för att samverkan ska kunna ske med de nationella tjänsterna. Där t.ex. en nationell tjänst vill läsa ifrån denna lokala instans om ett samtycke finns registrerat. Figuren nedan illustrerar hur en läsande nationelltjänst routas via den nationella tjänsteplattformen, genom en lokal tjänsteplattform(optionell) för att till sist hamna i den lokala samtyckestjänsten. Figur 1: Principer för samverkande tjänster för hantering av samtycke Kontakta Ineras förvaltning i god tid före driftstart för att registrera tjänsterna i tjänsteplattformen [Ref 1]. *Tjänsteplattformen används enbart om någon av tjänsterna Samtycke eller Patientrelation har installerats. Adresser till Tjänsteplattformen: Miljö Hostnamn IP-adress port contextpath Test (Sjunet) test1.esb.ntjp.sjunet.org /vp Test test1.esb.ntjp.se /vp (Internet) Produktion esb.ntjp.sjunet.org /vp (Sjunet) Produktion (Internet) esb.ntjp.se /vp Sid 17/115

18 4 SYSTEMÖVERSIKT Detta kapitel beskriver hur systemet sätts upp med maskiner och nätverksstruktur. 4.1 Ingående servrar består av en applikationsserver och två databasservrar. På applikationsservern installeras en gemensam plattform. På plattformen kan man välja vilken/vilka utav de fristående tjänsterna Spärr, Samtycke, Patientrelation, Autentisering (IdP) och Logg som ska installeras. kan konfigureras på två grundläggade sätt, med eller utan så kallad "fail-over". Med fail-over avses en eller flera maskiner/servrar som används tillsammans med den primära servern för att höja tillgängligheten på systemet och öka kapaciteten på systemet. För att kunna köra med en eller flera fail-over servrar krävs att alla noder har en delad diskyta. En lastbalanserare (omnämns inte i detalj här) används för att dirigera trafiken till alla applikationsservrar (genom t.ex. round-robin). SSL-sessioner delas mellan applikationsservrarna, så 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 dom övriga applikationsservrana. Fail-over-maskinerna bör vara identiska med ordinarie maskiner. Singelserverlösning består av en (1) applikationsserver och en (2) databasservrar, total tre stycken maskiner. För fail-over tillkommer alltså ytterligare tre maskiner. Figur: Systemöversikt nedan visar ett exempel med fail-over. Sid 18/115

19 Användare Nationell spärrtjänst SJUNET HSA NPÖ PU-tjänsten Brandvägg CRL/OCSP Tjänsteplattformen Delad diskyta Lokal säkerhetstjänst Nod 1-x Nod 1 Lokal säkerhetstjänst TC master MongoDB arbiter Nod 2 Lokal säkerhetstjänst TC Slave Nod x Lokal säkerhetstjänst MongoDB 1 & 2 MySQL Master MySQL Slave Figur 2: Systemöversikt Sid 19/115

20 4.2 Portöversikt Denna tabell visar vilka portöppningar som krävs för att lokala Säkerhetstjänster skall fungera. Standardport avser föreslagen port, men dessa konfigureras manuellt vid installation. In betyder inkommande trafik och Ut utgående trafik). Server Standardport Beskrivning Applikationsserver 8443 (in) Extern HTTPS (envägs-ssl, generellt administrationsgränssnitt) 8444 (in) Extern HTTPS (tvåvägs-ssl, IdP webbgränssnitt för identifiera användare med certifikat t.ex. SITHS) *Används endast vid installation av lokal IdP 8445 (in) Extern HTTPS (envägs-ssl, IdP webbgränssnitt med bla.val av identifikationsmetod och SSO) *Används endast vid installation av lokal IdP 8446 (in) Extern HTTPS (envägs-ssl, IdP webbgränssnitt för CDC hantering) 8080 (in) Extern HTTPS (tvåvägs-ssl, WebServices, t.ex.checkblocks) 8004 (in) Java JMX-övervakning, behöver ej öppnas om inte övervakning används. Bör ej vara extern utanför DMZ (in) Telnet-port för systemkonsol. Bör ej öppnas externt (in/ut) Interna portar som används av terracotta-tjänsten då 9520 (in/ut) man använder fail-over. Ska ej öppnas externt utan 9530 (in/ut) endast vara öppen internt för de andra noderna. 443 (ut) HTTPS-anrop till HSA-WS. PU-tjänsten 80 (ut) Porten används av systemet för slagningar mot OCSP och CRL kontroll för verifiering av certifikat på exempelvis SITHS-kort. Använder man andra certifikat än SITHS kan andra portar vara aktuella för OCSP/CRL (ut) Replikering till nationell spärrtjänst *Används endast vid installation av lokal spärrtjänst och för bakåtkompatibilitet Replikering till nationell spärrtjänst *Används endast vid installation av lokal spärrtjänst 3306 (ut) Anrop till databasservern (ut) Anrop till MongoDb servern Databasserver Standarport Beskrivning MySQL 3306 (in) Anslutningsport till MySQL-databas. Används av applikationsservern. Bör ej vara extern utanför DMZ. MongoDB (in/ut) Anslutningsport till MongoDB-Används av Sid 20/115

21 applikationsservern, samt i MongoDB Replica set. Ska ej öppnas externt utan endast vara öppen internt för de andra noderna. MongoDB (Arbiter) (in/ut) Används av Arbiters i Replica set. Ska ej öppnas externt utan endast vara öppen internt för de andra noderna. En användare som nyttjar lokala Säkerhetstjänster kommer att behöva nyttja portar Externa system som ska använda tjänsten ansluter på port Adressöversikt gränssnitt Denna tabell 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änstekontraktsbeskrivningen för detaljerad beskrivning av tjänsterna och dess användning. Spärr, Samtycke, Patientrelation och Logg är RIV TA 2.1 tjänster, se vidare Alla adresser för webbgränssnitt har följande prefix: Adress Beskrivning Blockservice Consentpdlservice patientrelationservice logservice logqueryingservice Spadmin Monitor com.logica.se.bif.externalpages.web Administrations GUI för lokala Säkerhetstjänster. Där sidor för bl.a. spärr, samtycke, patientrelation, logg och loggrapport finns. Webbsida för administration Webbsida för att övervaka systemet. Samtyckes-dialog som externa tjänster kan nyttja Alla adresser för webbgränssnitt för IdP har följande prefix: Adress Beskrivning idp/saml/sso/{binding} Autentiseringstjänst (IdP) SSO idp/saml/slo/{binding} Autentiseringstjänst (IdP) SLO Idp/saml Metadata IdP Sid 21/115

22 Adresser för webbgränssnitt för STS har följande prefix: Adress Beskrivning :8080/ws/idp/sts Autentiseringstjänst (STS) 2 vägs-ssl :8445/ws/idp/sts Autentiseringstjänst (STS) 1 vägs-ssl (meddelandesignering) Alla adresser för webbtjänstegränssnitt har följande prefix: Spärr RIV TA 2.0 services/canceltemporaryextendedrevokeresponderservice services/checkblocksresponderservice services/deleteextendedblockresponderservice services/getallblocksresponderservice services/getblocksforpatientresponderservice services/getextendedblocksforpatientresponderservice services/registerextendedblockresponderservice services/registertemporaryextendedrevokeresponderservice services/revokeextendedblockresponderservice Spärr RIV TA 2.1 blockinglocalservice/canceltemporaryextendedrevoke/2/rivtabp21 blockinglocalservice/checkblocks/2/rivtabp21 blockinglocalservice/deleteextendedblock/2/rivtabp21 blockinglocalservice/getblocks/2/rivtabp21 blockinglocalservice/getblocksforpatient/2/rivtabp21 blockinglocalservice/getextendedblocksforpatient/2/rivtabp21 blockinglocalservice/getpatientids/2/rivtabp21 blockinglocalservice/pingforconfiguration/1/rivtab21 blockinglocalservice/registerextendedblock/2/rivtabp21 blockinglocalservice/registertemporaryextendedrevoke/2/rivtabp21 blockinglocalservice/revokeextendedblock/2/rivtabp21 Samtycke RIV TA 2.1 consentservice/cancelextendedconsent/1/rivtabp21 consentservice/checkconsent/1/rivtabp21 consentservice/deleteextendedconsent/1/rivtabp21 consentservice/getconsentsforcareprovider/1/rivtabp21 consentservice/getconsentsforpatient/1/rivtabp21 consentservice/getextendedconsentsforpatient/1/rivtabp21 consentservice/pingforconfiguration/1/rivtab21 Sid 22/115

23 consentservice/registerextendedconsent/1/rivtabp21 Patientrelation RIV TA 2.1 /patientrelationservice/getpatientrelationsforcareprovider/1/rivtabp21 /patientrelationservice/getpatientrelationsforpatient/1/rivtabp21 /patientrelationservice/deleteextendedpatientrelation/1/rivtabp21 /patientrelationservice/cancelextendedpatientrelation/1/rivtabp21 /patientrelationservice/registerextendedpatientrelation/1/rivtabp21 /patientrelationservice/getextendedpatientrelationsforpatient/1/rivtabp21 /patientrelationservice/checkpatientrelation/1/rivtabp21 /patientrelationservice/pingforconfiguration/1/rivtabp21 /patientrelationservice/getpatientrelationsforcareprovider/1/rivtabp21 /patientrelationservice/getpatientrelationsforpatient/1/rivtabp21 /patientrelationservice/deleteextendedpatientrelation/1/rivtabp21 Logg RIV TA 2.1 /logservice/storelog/1/rivtabp21 /logservice/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 /logqueryingservice/getlogreportsinfo/1/rivtabp21 /logqueryingservice/pingforconfiguration/1/rivtabp21 CommissionService RIV TA 2.1 /commissionservice/getcommissionsforperson/1/rivtabp21 /commissionservice/setselectedcommissionforperson/1/rivtabp21 Adress till REST tjänst för att söka och ladda ner loggarkiv från Säkerhetstjänster. Log Archive download REST service /logdownload/archives Dokumentet Hämta loggarkiv är en bilaga till tjänstekontraktet för logg och finns bifogat i leveransen. Det beskriver REST tjänsten för hur hämta arkiv fungerar med parametrar osv. Sid 23/115

24 Dokumentet som beskriver tjänsten ligger under mappstrukturen: <Lokal_sakerhetstjanst_win>doc\Hämta loggarkiv.pdf Sid 24/115

25 5 INSTALLATION AV DATABASSERVER Det är av prestandaskäl rekommenderat att tilldela lokala Säkerhetstjänsters databasserver en egen fysisk maskin. Servern bör vara flerkärnig med minst 8 GB RAM. För utökad support och funktionalitet såsom online-backup så finns samma version i Enterprise Edition-utförande som dock inte är kostnadsfri. Mer information om detta finns här: För att nyttja automatisk fail-over samt databasreplikering med MySQL så rekommenderas DRBD. Mer information om detta finns här: Den MySQL-användare som används kräver behörighet att kunna ändra, uppdatera och lägga till nya tabeller i de scheman som skapas för systemet, användaren behöver dock inte ha behörighet att kunna skapa nya scheman. Vid skapandet av scheman krävs en inloggning med en användare som har root-rättigheter. Konfigurationen av MySQL ska vara satt att använda UTF-8. UTF-8 används för att t.ex. svenska tecken ska skrivas korrekt. Öppna konfigurationsfilen my.ini och säkerställ att det är UTF-8 som används. Se bilden nedan för hur det ska se ut. Figur 3: MySQL konfiguration för UTF Installationsanvisningar för MySQL MySQL har officiella installationsanvisningar för Windows här: Skapa ny användare 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. Man behöver skapa 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 att kunna skapa nya scheman. Skapandet av scheman krävs en inloggning med en användare som har root-rättigheter, vilket skapas under installationen av MySQL. Sid 25/115

26 1. Logga in i MySQL-prompten, kommando: mysql u root p (Ange det lösenord som angetts) 2. Skapa ny användare (i detta exempel är användarnamnet sak vilket rekommenderas, samt ett lösenord) genom att skriva följande rader, varje rad avslutas med enter 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; 3. Skapa ny användare (i detta exempel är användarnamnet sak vilket rekommenderas, samt ett lösenord) genom att skriva följande rader, varje rad avslutas med enter 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; 4. Avsluta MySQL prompten med kommando: quit Nu behöver scheman för de olika tjänsterna skapas. Sql skripten som ska köras finns under mappstrukturen <Lokal_sakerhetstjanst_win>\db\mysql\ De skript som tillhör respektive schema visas i den högra kolumnen nedan. Schema Skript accesscontrol accesscontrol.sql audit audit.sql blkloc blkloc.sql commission_service commission_service.sql consent consent.sql idp idp.sql idp_data.sql inftyp inftyp.sql inftyp_data.sql logdb logdb.sql logreport logreport.sql logreport_data.sql logreportarchive logreportarchive.sql logreportarchive_data.sql logdlarchive logdlarchive.sql metadata metadata.sql Sid 26/115

27 patientrelation sinkdb1 sp patientrelation.sql sinkdb1.sql sp.sql Det medföljer skript som hjälper till att skapa dessa scheman och läsa in tillhörande sql skript. Det finns ett skript för Windows och ett för Linux, create_databases_windows.bat och create_databases_linux.sh. Observera om det redan finns scheman med samma namn kommer dessa att tas bort. Det går genom att gå in i konfigurationsfilerna och manuellt ändra schema namnen om man önskar använda annan namnsättning, dock ej i den initiala installationen. Antingen redigerar man skriptet och lägger in användarnamn och lösenord eller så kan man starta skriptet med argument, första argumentet är användarnamn, andra är lösenord och tredje är prefix för databasnamnen. Exempel: create_databases.bat root password example_ Default användas inte prefix. När man startat scriptet får man frågan om man vill skapa om dessa databaser, se exempel i figur: Skapa databaser. Välj y för att fortsätta. Figur 4: Skapa databaser Då börjar den skapa om databasen. Finns inte databaserna sedan tidigare kommer man få ett felmeddelande database doesn t exist, detta kan man ignorera, se exempel i figur: Databas finns inte. Figur 5: Databas finns inte Finns däremot databaserna redan får man meddelande, se exempel i figur: Databas finns Sid 27/115

28 Figur 6: Databas finns Man får inget meddelande om att det gick bra att skapa databasen. Verifiera sedan att databaserna har skapats genom att logga in i mysql-prompten och skriva: show databases; se exempel i figur: Lista databaser. Figur 7: Lista databaser För att kolla om det finns tabeller i ett schema kan man gå in i schemat (t.ex. use accesscontrol;) och skriva show tables; se exempel i figur: Lista tabeller. Figur 8: Lista tabeller Sid 28/115

29 5.2 Installationsanvisningar för MongoDB MongoDB har officiella installationsanvisningar för Windows här: Nedan följer ett exempel på installationsförfarande Installera MongoDB på tre noder Här beskrivs installation av MongoDB med replikering. Det innebär att installationen kommer att använda tre noder kallade Primary, Secondary och Arbiter. Att installera MongoDB på tre noder har två syften: Prestanda Fail-over I konfigurationen 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. Arbiterns roll i uppsättningen är att bedöma vilken av noderna som ska fungera som Primary och vilken/vilka som ska fungera som Secondary. Arbitern kan med fördel installera på applikationsservern. Säkerhetstjänsten 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 tar 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 single installation, men vi rekommenderar starkt att ovan beskriven trenodsinstallation används. MongoDB laddas ner från som ett zip-arkiv. Det uppackade arkivet innehåller ingen installer utan bara filer som kan exekveras fristående från vilken katalog som helst utan beroenden till systemfiler. Installationen ska göras på samtliga datanoder och Arbiter-noden men konfigurationen skiljer sig något nodtyperna emellan. 1. Hämta MongoDB för Windows-versionen i fråga 2. Packa upp zip-filen till C:\och döp eventuellt om den resulterande katalogen till C:\mongodb 3. Skapa en datakatalog för MongoDB. Som standard är denna i Windows satt till C:\data\db. 4. Skapa en katalog för MongoDBs loggfil: C:\mongodb\log. Sid 29/115

30 5. Skapa en konfigurationsfil genom att skapa ett nytt enkelt text-dokument med namn mongod.cfg i C:\mongodb. 6. Lägg till och spara följande information i C:\mongodb\mongod.cfg dbpath= C:\data\db replset = rs_sak logpath= C:\mongodb\log\mongod.log logappend=true port = #Arbiter port #port = # Uncomment when User and Keyfile has been created #auth = true #keyfile = C:\mongodb\keys\sak.key 7. Lägg till sökvägen C:\mongodb\bin i Windows PATH-variabel. 8. Starta en ny kommandoprompt. Installera MongoDB som en service genom att från kommandoprompten exekvera: # mongod --config C:\mongodb\mongod.cfg -install 9. Starta nu MongoDB på alla datanoder (ej Arbiter) genom att från kommandoprompten exekvera: # net start mongodb 10. Starta MongoDB-klienten på en av datanoderna: Starta MongoDB-klienten genom att i kommandoprompten skriva: # mongo Nu ska MongoDB-klienten vara startad och en ny prompt vara synlig (i resten av instruktionen annoterad med >). Initiera konfiguration av replikering genom att skriva: > rs.initiate() Visa replikeringsinformation genom att skriva: > rs.conf() Lägg till en slavnod genom att skriva: > rs.add( mongo2.exempel.com ) 11. Logga in på Arbiter-noden och konfigurera genom att i en vanlig texteditor editera: C:\mongodb\mongod.cfg Sid 30/115

31 Ändra portnummer: port= Starta mongo server på Arbiternoden: # net start mongodb 13. Gå tillbaka till datanoden och dess mongo-klient och lägg till Arbiter-noden genom att i mongo-klienten skriva: > rs.addarb( mongo0.exempel.com:30000 ) 14. Nu ska kommandot rs.status()i mongo-klienten visa att replikering är konfigurerat med en PRIMARY, en SEOCONDARY och EN ARBITER. Sid 31/115

32 Figur 9: Exempel på "rs.status()" Sid 32/115

33 15. Skapa ett Admin-konto i mongo-klienten: > db = db.getsiblingdb("admin") > db.adduser( { user: "admin", pwd: "PASSWORD", roles: [ "useradminanydatabase", "readwriteanydatabase", "dbadminanydatabase", "clusteradmin" ] } ) Detta skapar en superanvändare med rätt att hantera alla databaser, användare och replikering. För beskrivning av de olika behörighetsrollerna för en användare se Mongos egen dokumentation. 16. Generera keyfile (som används för autentisering mellan noderna): Det rekommenderas att OpenSSL ( används för att skapa en keyfile med slumpmässig data. # cd C:\mongodb\keys\ # openssl rand -base > sak.key Notera: Samma keyfile (sak.key) måste finnas på alla medlemsnoder (PRIMARY, ARBITER och alla SECONDARYs) så generera denna endast på första noden och kopiera till de andra. Aktivera autentisering och peka ut keyfile för alla noder genom att i en enkel texteditor ändra i konfigurationsfilen C:\mongodb\mongod.cfg auth = true keyfile = C:\mongodb\keys\sak.key 17. Starta nu om ARBITERN, SECONDARYs och slutligen PRIMARY-noden: # net stop mongodb # net start mongodb 18. Skapa ett User-konto: Detta kan uteslutas ifall man använder skriptet för skapandet av nödvändiga databaser som följer med installationen (se nedan). I mongo-klinten: > db = db.getsiblingdb("pdllog") > db.adduser( { user: "USER", pwd: "PASSWORD", roles: [ "readwrite" ] } ) Sid 33/115

34 5.2.2 Indexering Att rätt index är inlagda i databasen är helt avgörande för prestanda. Logga in med en användare som har skrivrättigheter i databasen för pdl-loggar och använd metoden ensureindex: Detta kan uteslutas ifall man använder skriptet för skapandet av nödvändiga databaser som följer med installationen (se nedan). Starta MongoDB-klienten: C:\> mongo MongoDB shell version: connecting to: TEST I mongo-klinten: > use admin switched to db admin > db.auth("_user_", "_PASSWORD_") 1 rs_sak:primary> use pdllog switched to db pdllog rs_sak:primary> show collections system.indexes system.users rs_sak:primary> db.log.ensureindex({"cpid": 1, "act_date" : 1}) rs_sak:primary> db.log.ensureindex({"resources.pid": 1, "act_date" : 1}) rs_sak:primary> db.log.ensureindex({"cpid": 1, "resources.pid": 1, "act_date" : 1}) rs_sak:primary> db.log.ensureindex({"cpid": 1, "cuid": 1, "act_date" : 1}) rs_sak:primary> db.log.ensureindex({"cpid": 1, "uid": 1, "act_date" : 1}) rs_sak:primary> db.log.stats() rs_sak:primary> show collections log system.indexes system.users Sid 34/115

35 5.2.3 Skapa nödvändiga databaser Med installationen medföljer ett konfigurationsskript för att skapa nödvändiga databaser, index och användare för Säkerhetstjänsten. Det ligger i installationskatalogen under <Lokal_sakerhetstjanst_windows>\db\mongodb\ med namnet mongo_db_setup.bat. För att kunna köra detta behöver MongoDB med klient vara installerat enligt ovan. Du måste ha skapat ett användarkonto med administratörsrättigheter och det ska i en replikerad miljö exekveras på noden som för tillfället kör som PRIMARY. Skriptet kräver användarnamn och lösenord för administratören, användarnamn och lösenord för Säkerhetstjänsten 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). Argumentet dropdb kommer att radera databasen och frigöra diskutrymme medan utelämnande av detta argument bara kommer att ta bort eventuell tabell (collection) vilket inte resulterar i frigörande av diskutrymme. Med växeln -h kan man få mer information om användingen av skriptet # mongo_db_setup.bat -h Usage: #mongo_db_setup.bat root <root-pw> <sak-user> <sak-pw> [prefix][dropdb] Exempel 1: # mongo_db_setup.bat root <root-pw> <sak-user> <sak-pw> Skapar (om) collections med index men utan tabellprefix. Skapar databaser och sak-användare om dessa inte redan existerar. Frigör inte något diskutrymme. Exempel 2: # mongo_db_setup.bat root <root-pw> <sak-user> <sak-pw> proxy Skapar (om) collections med index och tabellprefix proxy_ Skapar databaser och sak-användare om de inte redan existerar. Frigör inte något diskutrymme. Exempel 3: # mongo_db_setup.bat root <root-pw> <sak-user> <sak-pw> dropdb Skapar databaser, sak-användare och collections med index men utan tabellprefix OBS! Raderar all data i databaserna och frigör diskutrymme. Exempel 4: # mongo_db_setup.bat root <root-pw> <sak-user> <sak-pw> proxy dropdb Skapar databaser, sak-användare och collections med tabellprefix proxy_ OBS! Raderar all data i databaserna och frigör diskutrymme. Sid 35/115

36 5.2.4 Konfigurationsfil Följande är ett exempel på hur en MongoDB konfiguration kan se ut. Denna fil hittar man, ifall man följ denna guide, under: C:\mongodb\mongod.cfg dbpath= C:\data\db replset = rs_sak logpath= C:\mongodb\log\mongod.log logappend=true port = #Arbiter port #port = # Uncomment when User and Keyfile has been created #auth = true #keyfile = C:\mongodb\keys\sak.key Notera plats för loggfilen (logpath) för eventuell felsökning av databasservern. Sid 36/115

37 6 INSTALLATION AV APPLIKATIONSSERVER Det är av prestandaskäl rekommenderat att tilldela lokala Säkerhetstjänsters applikationsserver en egen fysisk maskin. Servern bör vara flerkärnig med minst 12 GB RAM. 6.1 Installera Java och JCE Installera java och tillägget JCE Java Cryptography Extension, enligt kapitel INSTALLATION AV LOKALA SÄKERHETSTJÄNSTER Innan man påbörjar installationen av lokala Säkerhetstjänster, så finns bl.a några operativspecifika områden som rekommenderaras att man gör. Konfiguration av den lokala brandväggen på applikationsservern, läs mer om detta under II APPENDIX B - Konfigurera den lokala brandväggen. Skapa ett separat servicekonto, se III APPENDIX C - Skapa separat servicekonto. Delad diskyta för en fail-over lösning, se IV APPENDIX D - Förutsättningar för en failover lösning. 7.1 Installera systemet på Windowsmiljö När databasserver och applikationsserver är förberedda kan programvaran för lokala Säkerhetstjänster installeras. Detta görs på applikationsservern. Att installera lokala Säkerhetstjänster kan som beskrivits tidigare göras på två sätt. SingleServer lösning utan fail-over lösning. Fail-over lösning, som vi rekommenderar för en produktionsmiljö Installation Installationsprogrammet ligger under katalogen Lokal säkerhetstjänst (win)/install/setup.exe. Starta installationen genom att exekvera setup.exe. För installation av en singleserver gå till kapitel Installation av SingleServer. Installation på första noden i en fail-over lösning gå till kapitel Installation på första noden i en fail-over lösning. Installation på andra noden i en fail-over lösning gå till kapitel Installation på andra noden i en fail-over lösning. Sid 37/115

38 Installation på övriga noder i en fail-over lösning gå till kapitel Installation på övriga noder (nod3- nodx) i en fail-over lösning Installation av SingleServer Denna installation kommer att kopiera in de filer som behövs för applikationsservern samt registrera en service Lokal Säkerhetstjänst. Efter installationen är det rekommenderat att man byter servicekonto, se Appendix B Skapa separat servicekonto. 1. Exekvera setup.exe (under katalogstrukturen \SakerhetstjanstX.X\Lokal_sakerhetstjanst_win\install\setup.exe ). Välj vart Säkerhetsjänster ska installeras och tryck på knappen Next. Ett konfigurationsfönster öppnas där man markerar produkten dist.target. Välj Single installation. Ange sökvägen till Java JDK:n genom att klicka på knappen Browse.. Om man vill kan man ändra de defaultportar som används för OSGi-konsolen och JMX. Se bilden nedan. Figur 10: Single installation Sid 38/115

39 2. Fortsätt till konfigurationsavsnittet. Klicka på pilen Log setup. Fyll i sökväg till den delade arkivarean. Se bilden nedan. Figur 11: Konfiguration Log setup 3. Klicka på pilen Logreport setup. Fyll i sökväg till den delade arkivarean där loggrapporterna skapas. Se bild nedan. Figur 12: Konfiguration Logreport Setup 4. Klicka på pilen http(s) setup. Fyll i fälten. Certifikatet du anger måste vara ett Leg (legitimeringscertifkatet,.p12-fil) certifikat. De certifikaten ni ska använda diskuteras i kapitel 3.5 Certifikat. Ett legitimeringscertifikat måste anges som identiferar servern på Common Domain. Ange lösenord för respektive certifikat. Ange port till Säkerhetstjänsters GUI och WS port som Säkerhetstjänster kommer att publiceras på. Systemets portar beskrivs i kapitel 4.2 Portöversikt. Sid 39/115

40 Figur 43: Konfiguration - Http(s) setup 1. Klicka på pilen Idp http(s) setup. Fyll i fälten. Certifikatet du anger måste vara ett Leg (legitimeringscertifkatet,.p12-fil) certifikat. De certifikaten du ska använda diskuteras i kapitel 3.5 Certifikat. Ange https port för Säkerhetstjänsters autentisering för envägs-ssl och tvågvägs-ssl, se kapitel 4.2 Portöversikt. Se bilden nedan. Sid 40/115

41 Figur 54: Konfiguration - Idp http(s) setup 2. Klicka på pilen Common Domain http(s) setup. Fyll i fälten. Ange port för Common Domain envägs-ssl, se kapitel 4.2 Portöversikt. Ange Säkerhetstjänsters publika Common Domain adress och Säkerhetstjänsters Common Domain adress. Se bilden nedan. Figur 65: Konfiguration - Common Domain http(s) setup 3. Klicka på pilen HSA-WS setup. Fyll i fälten; adress, port, sökbas och Context path för HSA-WS tjänsten. HSA-WS beskrivs i kapitel HSA-WS. Se bilden nedan. Sid 41/115

42 Figur 76: Konfiguration - HSA-WS setup 4. Klicka på pilen MySQL Database setup. Fyll i adress och port till databas (mysql)- servern. Ange den användare som Säkerhetstjänster skall använda för att koppla upp sig mot databasen och databasanvändarens lösenord. Se bilden nedan. Figur 87: Konfiguration MySQL Database setup 5. Klicka slutligen på knappen Continue. Se bilden nedan. Figur 98: Continue - Single installation Sid 42/115

43 6. Figur: Fortsätt Fortsätt till konfigurationsavsnittet. Klicka på pilen Mongo Database setup. Fyll i adress, port och användare med lösenord. Figur 109: Konfiguration - Mongo Database Setup Systemet installeras och meddelar användaren med en bekräftelsedialog hur installationen gick. Efter en lyckad installation ska tjänsten startas. Gå in i verktyget Server Manager och Services och verifiera att servicen för lokala Säkerhetstjänster (LokalSakerhetstjanstService) startar upp automatiskt. Notera att uppstarten kan ta någon minut. För uppstart av systemet, gå till kapitel 8 UPPSTART AV SERVER Installation på första noden i en fail-over lösning Denna installation kommer att kopiera in de filer som behövs för applikationsservern samt kopiera de gemensamma filerna som används till den delade diskytan samt registrera två tjänster: Lokal Säkerhetstjänst och Lokal Säkerhetstjänst Terracotta. Efter installationen är det rekommenderat att man byter servicekonto, se III APPENDIX C - Skapa separat servicekonto. En förutsättning att man ska kunna installera en fail-over lösning är att man har satt upp en delad diskyta, se IV APPENDIX D - Förutsättningar för en fail-over lösning som kan nås från samtliga noder. 1. Exekvera setup.exe (under katalogstrukturen \SakerhetstjanstX.X\Lokal_sakerhetstjanst_win\install\ setup.exe ). Välj vart Säkerhetsjänster ska installeras och tryck på knappen Next. Sid 43/115

44 2. Ett konfigurationsfönster öppnas där man markerar produkten dist.target. Välj Cluster installation Node 1 (With TC Master). Ange sökvägen till Java JDK:n genom att klicka på knappen Browse.. Om man vill kan man ändra de defaultportar som används för OSGi-konsolen och JMX. 3. Peka ut sökväg till den delade diskytan. Notera: Viktigt att uppmärksamma är att Windows kan göra om den symboliska-länken till en UNC-sökväg, vilket man då manuellt får ändra i textfältet till den korrekta sökvägen, se urklipp från installations-guit i figurerna nedan. Exempel: Figur 20: Share-katalogen Resulterar till: Figur 21: Ej modifierad sökväg till delad diskya Ändra manuellt till: Sid 44/115

45 Figur 22: Korrekt sökväg till delad diskyta 4. Fyll sedan i terracottaservrarnas DNS och Hostname i respektive fält. Om man vill kan man ändra de defaultportar som används av terracotta. Terracotta är en fristående applikation som kommer att installeras och köras på nod1 och nod2 (Master/Slave). Ange därför nods 1 respektive nods2 hostname respektive DNS enligt fältena: TC1 DNS Name = nod 1 DNS namn (t.ex. nod1.sakerhetstjanst.example.com) TC1 Host Name = nod 1 Hostname (t.ex. nod1) TC2 DNS Name = nod 2 DNS namn (t.ex. nod2.sakerhetstjanst.example.com) TC2 Host Name = nod 2 Hostname (t.ex. nod2). 5. Därefter fortsätter konfigurationen av systemet enligt instruktioner angivna från steg 2-8 i kapitel Installation av SingleServer. Klicka sedan på knappen Continue. Sid 45/115

46 Figur 113: GUI för installation, kluster nod Sista steget är installationen av Terracotta som sker automatiskt (det visas WARN, i texten, se figur: Installation av Terracotta nod 1, vilket i det här fallet är ok) Figur 124: Installation av Terracotta nod 1 7. Systemet installeras och meddelar användaren med en bekräftelsedialog hur installationen gick. Därefter skall installationen göras på nod 2, se kapitel Installation på andra noden i en fail-over lösning. Sid 46/115

47 7.1.4 Installation på andra noden i en fail-over lösning Denna installation görs på den andra noden och kommer att registrera två stycken servicar: Lokal Säkerhetstjänst och Lokal Säkerhetstjänst Terracotta. Efter installationen är det rekommenderat att man byter servicekonto, se APPENDIX C - Skapa separat servicekonto. 8. Ett konfigurationsfönster öppnas där man markerar produkten dist.target. Välj Cluster installation Node2 (with TC Slave) Ange sökväg till konfigirationsfilen Node1InstallationProperties.xml som skapades vid installationen på den första noden och ligger på den delade diskytan. (C:\share\Sakerhetstjanst<version>\Node1InstallationProperties.xml). Notera: Viktigt att uppmärksamma är att Windows kan göra om den symboliska-länken till en UNC-sökväg, vilket man då manuellt får ändra i textfältet till den korrekta sökvägen, se urklipp från installations-guit i figurerna nedan. Klicka sedan på knappen OK. Figur 135: Share-katalogen Sid 47/115

48 Resulterar till: Figur 146: Felaktig sökväg Ändra manuellt till: Figur 157: Korrekt sökväg 9. Därefter visas ett fönster som säger att det finns koppling till den delade diskytan, klicka ok för att färdigställa installationen för Node 2. Figur 168: Network share path detected 10. Klicka sedan på knappen Continue i gui-fönstret. Sid 48/115

49 Figur 179: GUI för installation, kluster nod Sista steget är installationen av Terracotta som sker automatiskt (det visas WARN, i texten, enligt bilden nedan, vilket i det här fallet är ok) Figur 3018: Installation av Terracotta nod Systemet installeras och meddelar användaren med en bekräftelsedialog hur installationen gick. Notera: För installation på övriga noder (nod3 nodx), se kapitel Sid 49/115

50 7.1.5 Installation på övriga noder (nod3- nodx) i en fail-over lösning Denna installation görs på övriga noder och kommer att registrera en service: Lokal Säkerhetstjänst Efter installationen är det rekommenderat att man byter servicekonto, se Appendix B Skapa separat servicekonto. 1. Ett konfigurationsfönster öppnas där man markerar produkten dist.target. Välj Cluster installation Other Node Ange sökväg till den delade diskytan och peka ut konfigirationsfilen Node1InstallationProperties.xml som skapades vid installationen på den första noden, (C:\share\Sakerhetstjanst<version>\Node1InstallationProperties.xml). Klicka sedan på knappen Continue. Figur 31: GUI för installation, kluster nod 3 övrig nod Sid 50/115

51 8 UPPSTART AV SERVER NOTERA: Om installation av singleserver utan Terracotta (alternativ 2) valdes, fortsätt till kapitel 8.2. Vid uppstart kommer först Terracotta-servrarna att startas och därefter startas den första noden för lokala Säkerhetstjänsterna. Den första noden kommer att ansluta sig till Terracotta-klustret som i det här läget inte innehåller något data (bundle states, om bundlarna är startade, stoppade, installerade, etc). Installera sedan de valda komponenterna för Säkerhetstjänsterna i Terracotta-klustret och starta dessa. När sedan de övriga servrarna startas och ansluter sig till klustret, t.ex. när nod 2 startas, så hämtar de all information om bundle states etc, dvs. övriga servrar kommer att bli en spegling av den första servern i klustret. 8.1 Uppstart av Terracotta Terracotta nod 1: 1. Starta Terracotta servern på första noden, gå in i verktyget Server Manager och services och gå till lokala Säkerhetstjänsters Terracotta tjänst (Lokal Säkerhetstjänst Terracotta) och klicka på Start. Terracotta nod 2: 2. Starta igång Terracotta servern på andra noden, gå in i verktyget Server Manager och services och gå till lokala Säkerhetstjänsters Terracotta tjänst (Lokal Säkerhetstjänst Terracotta) och klicka på Start. 8.2 Uppstart av lokal Säkerhetstjänst på första noden Säkerhetstjänster nod 1: 1. För att starta systemet, gå in i verktyget Server Manager och services och gå till lokala Säkerhetstjänsters tjänst (Lokal Säkerhetstjänst) och klicka på Start. 2. 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. Sid 51/115

52 3. I systemkonsolen verifiera att systembundeln med id 0 har startat, dvs har status ACTIVE, genom att exekvera kommandot: osgi> ss Utskriftsexempel: Framework is launched. id State Bundle 0 ACTIVE org.eclipse.osgi_1.0.3 Förklaring av fältet State i ovan utskrift: INSTALLED Bundeln finns installerad i systemet men är ej startad. STARTED Bundeln är startad men ännu ej aktiv. ACTIVE Bundeln är startad och aktiv. RESOLVED Bundeln är stoppad efter start. 4. Lista de komponenter som kan installeras med följande kommando: osgi> pkg list Id Name Description 1 Local server Includes all below services 2 IDP component Bundles for IDP 3 Patient/Consent dialog Bundles for Patient/Consent dialog 4 Block local component Bundles for local block installation 5 Patientrelation component Bundles for patientrelation installation 6 Consent component Bundles for consent installation 7 Log local component Bundles for local log installation osgi> 5. Välj de komponenter som skall installeras; en eller flera. Alla lokala tjänster, välj alternativ Local server. Sid 52/115

53 Autentiseringstjänst, alternativ IdP component Patient/samtyckes dialog, alternativ Patient/Consent dialog Spärr, alternativ Block component. Patientrelation, alternativ Patientrelation component Samtycke, alternativ Consent component. Loggtjänst, alternativ Log local component. Det är möjligt att installera enbart en av tjänsterna, t.ex. Spärr. Dock kräver tjänsterna Spärr, Samtycke och Patientrelation tillgång till en autentiseringstjänst för att en användare ska kunna logga in och komma åt webbtjänsterna. Det kan t.ex. vara en annan befintlig lokal autentiseringstjänst (IdP) eller den nationella autentiseringstjänsten (IdP:n) eller så installeras den lokala autentiseringstjänsten tillsammans med den/de övriga lokala tjänsterna som skall installeras. Exempel: För att installera alla tjänster (komponent 1 i exemplet ovan): pkg install package 1 För att installera lokal spärrtjänst (komponent 4 i exemplet ovan): pkg install package 4 För att installera lokal loggtjänst med autentisering: pkg install package 3,7 Observera att de paketnummer som anges i exemplet ovan kan variera. Hämta aktuellt paketnummer från kommandot pkg list. 6. Starta det installerade paketet med kommando: osgi> pkg start Vänta ett tag på att bundlarna startar upp, ca 2 min. 7. Verifiera att samtliga bundlar är uppstartade med kommandot dep. Kommandot listar alla bundlar som ännu ej startat. Exekvera kommandot: osgi> dep Utskriftsexempel: id Bundle State Unsatisfied dependencies Förklaring: 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. Ifall någon bundel ej startar igång, kan man testa att starta om säkerhetstjänster, kvarstår problemet får man starta felsökning. 8. Verifiera att alla beroenden är uppfyllda med kommandot: osgi> context state Sid 53/115

54 Utskriftsexempel: id Context State State Information Förklaring: 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. 9. Om enbart Spärrtjänsten eller enbart Loggtjänsten installerades i föregående steg visas följande fel : Figur 32: Utskriftsexempel 1, Context state, Unresolved dependencies Block och logmodulen saknar beroenden i detta fall saknar en lokalt installerad loggtjänst och behöver konfigureras manuellt med adressen till en extern loggtjänst. För att göra detta editera konfigurationsfilen <installationskatalog>\sakerhetstjanst<version>\local\config\com.logica.se.bif.log.agent.impl xml. Ändra värdet för logstoreservice från Service till Proxy. Editera sedan konfigurationsfilen com.logica.se.bif.log.ws.proxyimpl xml i samma katalog. Ange adress (hostname) och portnummer (portnumber) till den externa loggtjänsten. Uppdatera nu com.logica.se.bif.log.agent.impl i systemkonsolen med kommando: osgi> update 305 (siffran till vänster om com.logica.se.bif.log.agent.impl i bilden ovan). Nu ska bara modulen com.logica.se.bif.ping.ws.factory sakna beroenden. Figur 33: Utskriftsexempel 2, Context state, Unresolved dependencies Modulen com.logica.se.bif.ping.ws.factory väntar på en Loggtjänster Samtyckestjänst och en Patientrelationstjänst. Eftersom dessa tjänster inte installerades måste konfigurationen uppdateras. För att få bort felet så får man gå in i konfigurationskatalogen för com.logica.se.bif.ping.ws.factory och ta bort filerna som heter samtycke och patientrelation. Sid 54/115

55 Om man enbart installerat Samtycke så får man ta bort filerna för spärr och patientrelation osv. Gå till katalogen: <installationskatalog>\sakerhetstjanst<version>\local\config\com.logica.se.bif.ping.ws.factory.1.0.0\ Ta bort xml-filerna för de saknade tjänsterna. I fallet ovan consent.xml, log.xml, logreport.xml och patientrelation.xml. Uppdatera com.logica.se.bif.ping.ws.factory i systemkonsolen med kommando: osgi> update 63 (siffran till vänster om com.logica.se.bif.ping.ws.factory i bilden ovan). Efter uppdateringen skall felen oven försvinna. Kontrollera med kommandot osgi> context state. Figur 34: Beroenden upplösta 10. Avsluta systemkonsolen med kommandot: osgi> disconnect 8.3 Anslut till webbgränssnittet Kontrollera att det går att ansluta till webbgränssnittet m.h.a en webbläsare på den första noden. 1. 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 2. Anslut med SITHS-kort. 3. Verifiera att det går att ansluta till webbgränssnittet via en webbläsare ex När frågan om att servern inte har ett giligt certifikat visas, välj continue to this website. Sid 55/115

56 8.4 Uppstart av lokal Säkerhetstjänst på övriga noder Övriga noder för Säkerhetstjänster: 1. För att starta systemet, gå in i verktyget Server Manager och services och gå till lokala Säkerhetstjänsters tjänst (Lokal Säkerhetstjänst) och klicka på Start. 2. Vänta en stund, ca 5 min, på att systemet startar upp. 3. Logga in till systemkonsolen: telnet localhost Verifiera att samtliga bundlar är uppstartade med kommandot dep. Kommandot listar alla bundlar som ännu ej startat. Exekvera kommandot: osgi> dep Utskriftsexempel: id Bundle State Unsatisfied dependencies Förklaring: Listas inte någon bundel här så är samtliga bundlar startade, i annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel. 5. Verifiera att alla beroenden är uppfyllda med kommandot: osgi> context state Utskriftsexempel: id Context State State Information Förklaring: Listas inte någon bundel här så är samtliga bundlar startade, i annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel. 5. Avsluta systemkonsolen med kommandot: osgi> disconnect 6. Verifiera att det går att ansluta till webbgränssnittet via en webbläsare ex. Sid 56/115

57 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. För att slå av/på filtren utför följande: 1. Gå in i systemkonsolen med: telnet localhost Inaktivera/aktivera autentiseringsfiltret med kommando: osgi> sys spfilter off osgi> sys spfilter -on 3. Inaktivera/aktivera behörighetsfiltret med kommando: osgi> sys authz off osgi> sys authz -on När konfigurationen av systemet är genomförd ska autentiseringsfiltret och behörighetsfiltret aktiveras. 9.1 Webbgränssnittet Anslut till Säkerhetstjänsters webbgränssnitt med den host-adress som ni angav i installationsskedet: Koppling till HSA-WS För att slutanvändare skall få tillgång till administrationssidan krävs minst ett medarbetaruppdrag för de SITHS-kort som används. Var god kontakta Inera för mer information kring anslutning och dokumentation [Ref 1]. Användaren och medarbetaruppdraget måste innehålla minst följande: Namn HSA Systemroll HSA-id för medarbetaren Beskrivning Användarens systemroll(er). För åtkomst till spärrar krävs rollen: BIF;Spärradministratör Användarens personliga HSA-id. Sid 57/115

58 HSA-id för medarbetaruppdrag Namn på medarbetaruppdrag HSA-id för vårdgivare Namn på vårdgivare HSA-id för vårdenhet Namn på vårdenhet Det valda medarbetaruppdragets HSA-id. Det valda medarbetaruppdragets namn. HSA-id för vårdgivaren som medarbetaruppdraget gäller inom. Namn på vårdgivaren som medarbetaruppdraget gäller inom. HSA-id för vårdenheten som medarbetaruppdraget gäller inom. Namn på vårdenheten som medarbetaruppdraget gäller inom. Exempel: Om användaren innehar systemrollen BIF;Spärradministratör så ges tillgång till all funktionalitet rörande spärrar. Läs användarhandboken [Ref 2] för mer detaljerad information om åtkomst och regler i spärradministrationen Konfiguration av HSA-WS Vid installationen anges adressen till HSA-WS. Om fel adress angavs eller om adressen måste ändras går det att göra i menyn Autentisering i undermenyn Egenskapskälla. Ange adress och/eller ny sökbas och klicka på knappen Spara. Timeout och cachetimeout ska normal inte ändras. Timeout anger hur länge tjänsten skall vänta på svar från HSA tjänsten. Cachetimeout anger hur länge i millisekunder ett hämtat värde kan återanvändas utan att åter fråga HSA tjänsten. Figur 195: HSA-WS Egenskapkälla Sid 58/115

59 9.3 PU-tjänsten PU-tjänsten behöver endast konfigureras ifall någon av följande tjänster är installerade: samtycke, patientrelation eller spärr. Konfiguration för PU-tjänsten ligger i menyn Administration i undermenyn Generell Konfiguration. Välj sedan konfiguration Resident Information Lookup Service Impl Se exempelbilden nedan. Figur 206: Konfiguration av PU-tjänsten 9.4 Konfiguration av spärr Spärr kan konfigureras upp att antingen gå mot tjänsteplattformen eller för att köras lokalt. Exempelbilderna nedan visar hur konfigurationen ser ut mot tjänsteplattformen. Hänvisade hostnamn och portar för konfigurationerna som beskrivs nedan ska konfigureras mot tjänsteplattformen. Konfigurationer behöver endast göras om tjänsten Spärr är installerad. Samtliga konfigurationer av tjänsten ligger i menyn Administration i undermenyn 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. Sid 59/115

60 9.4.1 Block Local Service Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block Local Service National block interface ska vara satt till Proxy (Den nationella Spärrtjänsten stödjer replikering via RIV TA 2.0 och RIV TA 2.1. Det är rekommenderat att konsultera med Inera om vilken version som skall användas för replikeringen men i dagsläget ska National RIVTA version ska vara satt till Riv Synkronisering till nationell Spärrtjänst aktiveras om Replicate to/from national node är ikryssat. Även valen för Download blocks from national node och Send local blocks to national node bör vara ikryssade. Det går att välja vilken typ av replikering som skall ske med dessa val, men rekommenderat är att båda skall vara ikryssade. 4. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Sid 60/115

61 Figur 217: Block Local Service Block Web Application Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen för Block Web Application Konfigurationen ska vara inställd efter bilden nedan för att gå mot tjänsteplattformen. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Sid 61/115

62 Figur 228: Block Web Application Block National Webservice Proxy for RIV Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block National Webservice Proxy for RIV Ange Context path, Host name och portnummer. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 239: Block National Webservice Proxy for RIV Block Common Webservice Proxy v Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block Common Webservice Proxy v Ange Context path, Host name och portnummer. Sid 62/115

63 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 40: Block Common Webservice Proxy Block Common Webservice Proxy for National v Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block Common Webservice Proxy for National v Ange Context path, Host name och portnummer. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 4124: Block Common Webservice Proxy for National Sid 63/115

64 9.4.6 Block National Accesscontrol Webservice Proxy Se exempelbilden nedan för konfigurationen. 1. Öppna konfigurationen Block National Accesscontrol Webservice Proxy Ange Context path, Host name och portnummer. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 4225: Block National Accesscontrol Webservice Proxy 9.5 Konfiguration av Loggtjänsten PDL-loggar kan styras att antingen gå mot lokalt installerad loggtjänst eller så kan man för tjänsterna lokal spärr, samtycke och patientrelation välja att logga dessa händelser till den nationella loggtjänsten. Detta görs genom att konfigurera modulen Log Agent Impl till att använda en proxy samt ange adress och portnummer till den externa loggtjänsten i modulen Log WS Proxy Impl. Exempelbilderna nedan visar hur konfigurationen styr PDL-loggar att lagras på en hotelltjänst. Samtliga konfigurationer av tjänsten Logg ligger i menyn Administration i undermenyn Generell Konfiguration. För att anslutningen till den externa loggtjänsten ska fungera måste förvaltningsorganisationen för nationella tjänster kontaktas för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1] Log Agent Impl Öppna konfigurationen Log Agent Impl Logstore service ska vara satt till Proxy. Sid 64/115

65 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 4326 Log Agent Impl Log WS Proxy Impl Öppna konfigurationen Log WS Proxy Impl Ange Host name och Port number för loggtjänsten som ska användas. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 4427 Log WS Proxy Impl Sid 65/115

66 9.6 Konfiguration av samtycke Tjänsten samtycke kan konfigureras upp att antingen gå mot tjänsteplattformen eller för att köras lokalt. Exempelbilderna nedan visar hur konfigurationen ser ut mot tjänsteplattformen. Dessa konfigurationer behöver endast göras om tjänsten är installerad. Samtliga konfigurationer av tjänsten samtycke ligger i menyn Administration i undermenyn Generell Konfiguration. Hänvisade host-namn och portar för konfigurationerna som beskrivs nedan ska konfigureras mot tjänsteplattformen Consent Webservice Proxy Öppna konfigurationen Consent Webservice Proxy Ange Context path, Host name och portnummer. 6. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 4528: Consent Webservice Proxy ConsentPDL GWT Application Öppna konfigurationen ConsentPDL GWT Application Consent service ska vara satt till Proxy. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Sid 66/115

67 Figur 4629: ConsentPDL GWT Application 9.7 Konfiguration av patientrelation Tjänsten patientrelation kan konfigureras upp att antingen gå mot tjänsteplattformen eller för att köras lokalt. Exempelbilderna nedan visar hur konfigurationen ser ut mot tjänsteplattformen. Dessa konfigurationer behöver endast göras om tjänsten är installerad. Samtliga konfigurationer av tjänsten patientrelation ligger i menyn Administration i undermenyn Generell Konfiguration. Hänvisade host-namn och portar för konfigurationerna som beskrivs nedan ska konfigureras mot tjänsteplattformen Patientrelation Web Application Öppna konfigurationen Patientrelation Web Application Patientrelation service ska vara satt till Proxy. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Figur 307: Patientrelation Web Application Patientrelation Webservice Proxy Öppna konfigurationen Patientrelation Webservice Proxy Ange Context path, Host name och portnummer. 3. Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka. Sid 67/115

68 Figur 318: Patientrelation Webservice Proxy 9.8 Konfiguration av hämtningstjänsten Klicka på menyn Generell Konfiguration under huvudmenyn Administration. I tabellen som visas, klicka på den blå pilen för konfigurationen Log Download Archive. I tabellen nedan så måste man konfigurera följande: 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. Context Path Sökväg till tjänsten för att hämta loggarkiv. (Default: /logdownload/archives/) Host name Domännamn till nationella tjänsten Port Portnummer till nationella tjänsten Protocol https eller http (Default: https) Om man vill aktivera schemaläggaren så den hämtar gårdagens (eller från när den hämtade senast) arkiv per automatik så bockar man i Scheduler enabled. Man behöver även konfigurera när schemaläggaren ska starta, det görs med formatet HH:mm (00:00 23:59) Default: 02:00. Sid 68/115

69 Figur 49: Log Download Archive 9.9 Ta bort root-certifikat för test vid en produktionssättning I och med produktionssättning av systemet bör alla CA rotcertifikat som använts för test tas bort ur listan med konfigurerade certifikatsutfärdare. Detta görs i syfte att utesluta att certifikat för testsyften kan ges någon form av åtkomst till systemet. Säkerställ att inga tester skall genomföras i systemet innan certifikaten tas bort. En eller flera förtroendekällor kan ha certifikatutfärdaren under användning. För att ta bort en certifikatutfärdare måste därför först den webbserver som kopplingen går mot avmarkeras i Webbserveradministrationen. Observera att när en webbserver skall tas bort så måste först de konnektorer som är kopplade till denna att tas bort. Kontrollera att inga förtroendekällor använder certifikatutfärdaren ni vill ta bort, genom följande anvisningar: 1. Klicka på soptunnan som tillhör den certifikatutfärdaren ni vill ta bort. Se bilden nedan ( Sid 69/115

70 Figur 5032: Borttagning av certifikatsutfärdare 2. Navigera till menyvalet Webbserver om meddelandet En eller flera förtroendekällor använder denna certifikatsutfärdare. För att kunna ta bort denna certifikatsutfärdare måste den avmarkeras i Webbserveradministrationen visas. Figur 5133: Vy över Webbserver Börja med att ta bort den konnektor som är kopplad till webbservern. Gör så här: 1. Identifiera under tabellen Konnektorer vilken konnektor som skall tas bort. 2. Klicka på soptunnan längst till höger på den valda raden. Bilden ovan illustrerar vyn. Fortsätt sedan med att ta bort den berörda webbservern: 1. Klicka på soptunnan under menyn Webbservrar. Sid 70/115

71 Notera att det inte går att ta bort en webbserver om en konnektor är kopplad till denna. Följande felmeddelande visas i ett sådant scenario: [Webbserverns namn] har en eller flera konnektorer kopplad. 2. Bekräfta borttagningen genom att klicka på Ja eller avbryt genom att klicka på Tillbaka. Återgå till menyn för Certifikatutfärdare. Efter att kopplingarna är borttagna kan certifikatutfärdarna dedikerade för testsyften tas bort. Upprepa stegen ovan tills alla certifikatutfärdare för testsyften är borttagna från systemet Konfiguration av CDC CDC är en typ av webbkaka. För att hålla rätt på vilken IdP som medarbetaren använde senast, för att på så vis få SingleSignOn när man har flera IdP:er, används CDC. Kortfattat kan man beskriva detta att SP:ar läser ifrån den gemensamma kakan, medan IdP:er skriver till den. Konfigurering av CDC sker i menyerna SP SAML (under huvudmenyn Administration) och i IdP SAML (under huvudmenyn Autentisering). 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. CDC - SP SAML Bocka i kryssrutan om SP ska läsa från CDC. Se bilden nedan. Figur 5234: Konfiguration för CDC i SP SAML CDC - IdP SAML Bocka i kryssrutan om IdP ska skriva till CDC. Se bilden nedan. Figur 5335: Konfiguration för CDC i IdP SAML Sid 71/115

72 10 BEHÖRIGHET Ansvaret på vilka vårdgivare en lokal installation skall hantera, ligger på varje huvudmans vårdorganisation. 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 finns det mer information om systemets behörighetskriterier [Ref 2] 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 sitt SAML-intyg. Användare som autentiserar sig till systemet med ett SITHS-kort får sina egenskaper från HSA. En egenskap kan exempelvis vara BIF;Spärradministratör som innebär att användaren har behörighet att hantera spärrar. Samtliga vårdgivare som ska använda sig av någon av tjänsterna som har installerats måste specificera detta i de interna reglerna som läses in. En användare hämtar sina egenskaper från HSA-katalogen och sedan valideras dessa egenskaper mot de inlästa reglerna för att kontrollera att användaren har behörighet till någon installerad tjänst i systemet. Uppsättning av lokala behörighetsregler kan antingen göras med ett medföljande verktyg (som beskrivs i följande avsnitt) eller manuellt. Se APPENDIX A Skapa behörighetsregler och metadata manuellt för manuell uppsättning av lokala behörighetsregler Uppsättning av behörighetsregler för användare 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. Mallen ligger under mappstrukturen: <Lokal_sakerhetstjanst_win>\rules\regler_default_lokal.xml. Reglerna skapas med en applikation som följer med i installationspaketet tillsammans med mallen som beskrevs ovan. Applikationen ligger under mappstrukturen: <Lokal_sakerhetstjanst_win>\rules\RuleConfigGenerator\RuleConfigGenerator.exe. Starta applikationen RuleConfigGenerator.exe. Applikationen består av två huvudfunktioner: Generering av behörighetsregler. Generering av metadata för konsumentsystem. Funktionerna är uppdelat under två flikar. Bilden nedan visar fliken Generate rules, som används vid skapandet av lokala behörighetsregler. Sid 72/115

73 Figur 5436: Generering av behörighetsregler för användare I samma katalog där ni hittar regelapplikationen, finns textfilen CareProviders.txt som ska modifieras med era vårdgivare. För att sätta upp behörighetsregler för er lokala installation: 1. Öppna textfilen CareProviders.txt och ange era vårdgivare (en per rad). Följ instruktionerna som ges i filen. 2. Spara filen och kör applikationen RuleConfigGenerator.exe. Det är rekommenderat att ni sparar filen i samma katalog så applikationen kan välja den automatiskt till kommande steg. 3. Läs in er modifierade textfil med knappen Browse i fältet Care provider file path. Se förtydligande bild nedan. Applikationen hittar filen själv om ni sparade den med samma namn i den katalog som ni modifierade den i. Sid 73/115

74 Figur 5537: Ange sökvägar till nödvändiga filer 4. Välj fliken Generate rules i applikationen. 5. Läs in regelmallen med knappen Browse i fältet Rule template file path. Ni hittar mallen i installationspaketet under mappstrukturen <Lokal_sakerhetstjanst_win>\rules\regler_default_lokal.xml. 6. Klicka på knappen Generate Rules. Spara era regler på ett lämpligt ställe. Reglerna som ni skapat kommer att läsas in i systemet. Se kapitel Läsa in regler Läsa in regler 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änsters OSGi-konsol. Läs in regler: 1. Öppna Säkerhetstjänsters OSGi-konsol. Ange den adress och port till konsolen som valdes i installationsskedet. Exempelvis: telnet localhost 1111 Ange kommando: sys acc import file:///c:\regler_default_lokal.xml 2. Tryck på Enter för att exekvera kommandot. Reglerna har nu lästs in i systemet IdP/SP Metadata Metadata är en viktig beståndsdel av SAML och innehåller information som IdP:n och SP:n kommunicerar med varandra för att bestämma om ett system har den behörighet som krävs för att bli tilldelad åtkomst. Om en lokal autentiseringstjänst är installerad måste metadata-filer för IdP:en och SP:n exporteras och importeras i menyn SAML Metadata. Sid 74/115

75 Metadata-filer anpassade för konsumentsystem till Säkerhetstjänster importeras till systemet på samma sätt som beskrivs nedan för Säkerhetstjänsters IdP/SP metadata. Exportera Säkerhetstjänsters IdP/SP metadata: 1. Gå in i webbgrässnittet. Öppna menyn Autentisering och sedan undermenyn IdP SAML. 2. Fyll i formuläret IdP Metadata med era valda kontaktuppgifter. Dessa kommer att specificeras på metadata-filen. 3. Uppdatera informationen genom att klicka på knappen Spara (längst ner på sidan). 4. Exportera IdP metadata med knappen Exportera. Filen kommer läsas in i ett senare skede, så spara den på ett lämpligt ställe. 5. Öppna nu menyn Administration och sedan undermenyn SP SAML. 6. Utför motsvarande procedur som tidigare (steg 2-4) för SP metadata Behörigheter för konsumentsystem eller för tjänsteplattformen Metadata är till för dels att IdP ska lita på olika SP:er. Det är också till för att ge externa vårdsystem och tjänsteplattformen tillgång att använda Säkerhetstjänster. Till skillnad från användaren som får sina egenskaper från HSA-WS, hämtar systemen sina egenskaper från inläst metadata. Det som menas med vårdsystem är ett externt system som ska ha behörighet att anropa någon av de installerade tjänsterna i lokala säkerhetstjänster (dvs. samtycke, patientrelation och spärr) som är definierade i tjänstekontrakten. Tjänsteplattformen beskrivs i kapitel Error! Reference source not found. Error! Reference source not found.. System som skall ges behörighet till Säkerhetstjänster måste beskrivas i en metadata-fil där dess egenskaper anges. I leveransen ingår det en mall för metadata. Metadata-filen måste anpassas efter följande kriterier: Systemets HSA-id (entityid). HSA-id för de vårdgivare som ingår i konsumentsystemet (endast för uppsättning av metadata mot vårdsystem). Mallen ligger under mappstrukturen: <Lokal_sakerhetstjanst_win>\example\metadata\examplesystem-metadata.xml. Metadata-filen skapas med en applikation som följer med i installationspaketet tillsammans med mallen som beskrevs ovan. Starta applikationen RuleConfigGenerator.exe. Applikationen består av två huvudfunktioner: Generering av behörighetsregler. Generering av metadata för externa system (exempelvis vårdsystem eller tjänsteplattformen). Sid 75/115

76 Funktionerna är uppdelat under två flikar. Bilden nedan visar fliken Generate metadata, som används vid skapandet av metadata för externa system. För uppsättning av metadata till era vårdsystem ska textfilen CareProviders.txt modifieras med era vårdgivare. Filen hittar ni i regelgeneratorns katalog. Figur 5638: Generering av behörigheter för konsumentsystem Anpassa metadata för konsumentsystem eller mot tjänsteplattformen Nedan följer en beskrivning för hur regelgeneratorn ska användas vid generering av metadata till ett vårdsystem eller mot tjänsteplattformen. Följande bild visar beskrivningar för samtliga funktioner under fliken Generate metadata som används vid genereringen av metadata. Sid 76/115

77 Figur 5739: Beskrivningar av samtliga knappar och fält i fliken Öppna konsumentsystemets eller tjänsteplattformens klientcertifikat för att ta reda på vilket HSA-id systemet har och som ska specificeras i metadata-filen. 1. Öppna certifikatets leg.cer fil och klicka på Details. 2. Bläddra i listan som visas. Klicka på informationsfältet Subject. 3. En informationsruta visas. Det Serialnumber som visas i rutan är certifikatets serienummer, dvs. det HSA-id som ni ska specificera i metadata-filen som ni anpassar till systemet. 4. Observera: steg 4-6 behöver endast göras vid uppsättning av metadata för vårdsystem. Öppna textfilen CareProviders.txt och ange era vårdgivare (en per rad). Följ instruktionerna som ges i filen. 5. Spara filen och kör applikationen RuleConfigGenerator.exe. Det är rekommenderat att ni sparar filen i samma katalog så applikationen kan välja den automatiskt till kommande steg. 6. Läs in er modifierade textfil med knappen Browse i fältet Care provider file path. Se förtydligande bild nedan. Applikationen hittar filen själv om ni sparade den med samma namn i den katalog som ni modifierade den i. 7. Välj fliken Generate metadata i applikationen. 8. Ange det HSA-Id för konsumentsystemet som ni hämtade i steg 3 i fältet Entity id (Serial No). Se bilden ovan. 9. Läs in regelmallen med knappen Browse i fältet Meta template file path. Ni hittar mallen i installationspaketet under mappstrukturen <Lokal_sakerhetstjanst_win>\example\metadata\example-system-metadata.xml. 10. Bocka endast i kryssrutan Generera för Tjänsteplattformen om metadata-filen ska sättas upp mot tjänsteplattformen. I annat fall, fortsätt till steg Klicka på knappen Generate Metadata. Spara metadata-filen på ett lämpligt ställe. Metadata-filen ni skapat ska läsas in i systemet. Se kapitel 10.4 Inläsning av metadata. Sid 77/115

78 10.4 Inläsning av metadata IdP/SP metadata, samt eventuellt övriga metadata-filer anpassade för externa system till Säkerhetstjänster måste läsas in i systemet. Denna import av metadata sker i Säkerhetstjänster webbgränssnitt. Importera metadata till Säkerhetstjänster: 1. Öppna menyn Administration och sedan undermenyn SAML Metadata. 2. Klicka på knappen Välj fil. Välj en av era metadata-filer (dvs. IdP/SP metadata, samt eventuell metadata skapad för externa system). 3. Klicka på Importera. 4. Den importerade metadata-filen ska nu visas i tabellen Importerade IdP Metadata Entiteter (IdP metadata) och/eller i tabellen Importerade SP Metadata Entiteter (SP metadata) Systemegenskaper Interna tjänster får egenskaper från de inlagda systemegenskaperna. För att de interna tjänsterna ska få anropa andra interna tjänster så måste systemegenskapen systemrole bli tilldelad värdet Internal. En intern tjänst kan exempelvis kräva att ett anrop som kommer från en annan intern tjänst ska innehålla en viss vårdgivare. De vårdgivarna måste då läggas till i systemegenskaperna för att anropet ska beviljas behörighet till tjänsten. Lägg till systemegenskapen Internal : 1. Bläddra i listan Egenskap. 2. Välj urn:sambi:names:attribute:systemrole. 3. Skriv in Internal i fältet Värde. 4. Klicka på knappen Lägg till. Lägg till systemegenskaper för vårdgivare: 1. Bläddra i listan Egenskap. 2. Välj urn:sambi:names:attribute:careproviderhsaid 3. Skriv in HSA-id för vårdgivaren i fältet Värde. 4. Klicka på knappen Lägg till. 5. Upprepa steg 1-4 för samtliga vårdgivare som ska läggas till. Se exempelbilden nedan för hur det kan se ut. Vårdgivarna i bilden är fiktiva. Sid 78/115

79 Figur 5840: Systemegenskaper 10.6 Extern Autentiseringstjänst Om ingen lokal autentiseringstjänst installerades, måste systemet ansluta sig till en extern autentiseringstjänst/idp för att upprätthålla PDL. Detta görs genom att exportera SP metadata för det lokala system och skicka denna XML-fil till organisationen som tillhandahåller autentiseringstjänsten. Metadata-filen måste importeras i deras system samt att dess (autentiseringstjänstens) metadata-fil måste importeras i det lokala systemet (korsvis exportering och inläsning) Aktivering av autentiseringsfilter och åtkomstkontroll Avsluta konfigurationsavsnittet och aktivera autentiserings- och behörighetsfiltret från systemkonsolen. För att slå på filtren utför följande: 1. Gå in i systemkonsolen med: telnet localhost Aktivera autentiseringsfiltret med kommando: osgi> sys spfilter on 3. Aktivera behörighetsfiltret med kommando: osgi> sys authz -on Kontrollera därefter att webbgränssnittet nu kräver SITHS-kort inloggning genom att gå till webbgränssnittet för lokala Säkerhetstjänster via en webbläsare: Sid 79/115

80 11 SYSTEMADMINISTRATION 11.1 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: Denna testar inloggningsförfarandet, med val av certifikat, val av medarbetaruppdragsval Start och stopp För att starta systemet, gå in i verktyget Server Manager och services och gå till lokala Säkerhetstjänsters tjänst (LokalSakerhetstjanstService) och klicka på Start. För att stoppa systemet, gå in i verktyget Server Manager och services och gå till lokala Säkerhetstjänsters tjänst (LokalSakerhetstjanstService) och klicka på Stop. Tjänsten kan alternativt startas och stoppas genom att användaren trycker CTRL+ALT+DELETE, väljer Windows Task Manager och väljer tabben Services. När ni hittat tjänsten (LokalSakerhetstjanstService), högerklicka och välj att stoppa eller att starta tjänsten. 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 kapitel 11.4 Systemlogg) 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. Verifiera att samtliga bundlar är uppstartade med kommandot context state. Det kommandot listar alla bundlar som inte startat ännu. Exekvera kommandot: osgi> context state Se Figur: OSGi context state exempel, nedan av kommandot context state: Figur 5941: Exempelutskrift av OSGi context state Sid 80/115

81 Förklaring: Listas inte någon bundel här så är samtliga bundlar startade, i annat fall upprepa kommandot i intervallet tills kommandot inte listar någon bundel. Kommandot context state används för att verifiera att alla beroenden är uppfyllda. Avsluta systemkonsolen med kommandot: osgi> disconnect Aktivering och avaktivering av autentiseringsfilter Autentiseringsfiltret kontrollerar om en aktör måste logga in med SITHS-kort eller tjänstecertifikat. Observera att en aktiverad behörighetskontroll kräver att autentiseringsfiltret är aktiverat. För att slå av/på filtren utför följande: 1. Gå in i systemkonsolen med: telnet localhost Inaktivera/aktivera autentiseringsfiltret med kommando: osgi> sys spfilter off osgi> sys spfilter -on 3. Inaktivera behörighetsfiltret med kommando: osgi> sys authz off osgi> sys authz -on 11.4 Systemlogg för Windows producerar en logg som avser teknisk förvaltning och felsökning som lagras på filsystemet under uppstartsfasen. Systemlog lagras i följande katalog: <sökväg till installerad säkerhetstjänst>\sakerhetstjanst<version>\local\log\ Systemet lagrar loggarna i databasen (schemat audit) och kan nås genom kommandot audit från systemkonsollen, se kapitel Sök i systemlogg. Om inte databasen är uppsatt för att kunna hantera systemloggar (som sker i installationsskedet av Säkerhetstjänster) skriver Säkerhetstjänster backup av systemloggar till fil Sök i systemlogg Logga in i systemkonsollen och exekvera något av följande kommandon: audit search level error audit search level error time 1h (Alla error loggar) (Alla error loggar senaste timmen) Sid 81/115

82 audit search time 1h audit search time 5m (Alla loggar senaste timmen) (Alla loggar från de senaste 5 minuterna) 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 så fort som loggfunktionen är startad 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 Java-processen på applikationsserver och kontrollera att "monitor"-sidan svarar ( Vid akuta problem, starta om applikations- och/eller databasservern och kontrollera systemloggen. Om produktfelanmälan skall göras måste alla systemloggar kring felet samt ett beskrivande scenario kring vad som föranledde felet bifogas. Sid 82/115

83 12 FÖRVALTNING OCH UNDERHÅLL 12.1 Hämtning av arkivloggar från nationella Säkerhetstjänster Vid en ny installation så kan man vilja hämta loggarkiv för den egna vårdgivaren/vårdgivarna från nationella Säkerhetstjänster. Det kan göras manuellt och via en schemaläggare. För konfiguration av hämtningstjänsten, se kapitel 9.8 Konfiguration av hämtningstjänsten Manuell hämtning Följande kommandon finns att tillgå i OSGi-konsolen: archive dl <parametrar> archive status <parametrar> Figur 6042: Kommandon för manuell hämtning av arkivloggar Exempel 1 - Hämta alla arkivloggar från 1:a januari 2013 archive dl -from Exempel 2 - Hämta alla arkivloggar från 1:a januari 2013 till 1:a augusti 2013 archive dl -from to Exempel 3 Visa status på alla hanterade arkivloggar från 1:a januari 2013 archive status -from Exempel 4 Visa status på alla hanterade arkivloggar som har gått fel archive status code Error Exempel 5 Testa anslutningen mot nationella säkerhetstjänsten archive status test Sid 83/115

84 Schemaläggare För att slippa hämta arkivloggar manuellt så finns det möjlighet att aktivera en schemaläggare som hämtar arkivloggar automatiskt. 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 Hämtning av nationella arkiv För att den lokala installationen av Säkerhetstjänster ska kunna hämta arkiv från nationella Säkerhetstjänster så behöver nationella Säkerhetstjänster innehålla den lokala installationens metadata. För att skapa upp metadata till nationella Säkerhetstjänster, se kapitel Anpassa metadata för konsumentsystem. Notera att den lokala installationen är ett konsumentsystem till nationella Säkerhetstjänster. Kontakta en behörig administratör av nationella Säkerhetstjänster för att sedan läsa in den lokala installationens metadata Periodiskt underhåll Läs kapitel 11.4 Sök i systemlogg för information angående hur systemloggar lagras och hur de loggas med hjälp av Loggtjänsten. Kapitel 11.3 Hantera aktiviteter i beskriver hur systemet kan hanteras och kontrolleras i systemkonsolen (OSGi) Övervakning Applikationsserver publicerar en mängd systemmoduler som kan övervakas över JMXprotokollet som är Javas teknik för generell övervakning. Med valfritt JMX-verktyg kan applikationsserverns webbtjänster övervakas, se kapitel 4.2 för gällande port. Observera att JMX-porten inte får tillgängliggöras för någon annan part annat än den maskin som skall sköta övervakningen. Standardinställningarna för JMX kan ändras i <installationskatalog>\localsakerhetstjanstconfig.xml Sid 84/115

85 Alla systemkomponenter publiceras som monitorerbara JMX-bönor. Nedan visas en exempelbild från programmet JConsole som medföljer Java SE. Figur 6143: Exempelbild från programmet JConsole Alla bönor med namn com.logica.se.iac.performance.impl.inbound respektive.outbound är övervakade webbtjänster som vid behov kan övervakas för att samla in statistik. Inbound avser alla för servern inkommande anrop och outbound de utgående. Övriga bönor är interna systemkomponenter och innehåller ingen övervakningsbar information. Varje webbtjänst har en uppsättning attribut med värden enligt följande lista: Attribut delta.maxtime delta.meantime delta.mintime delta.size name total.exceptions total.maxtime total.meantime total.mintime Beskrivning Det anrop som tagit längst tid att exekvera (ms) inom aktuellt mätfönster/delta. Snittid för alla anrop (millisekunder) inom aktuellt mätfönster/delta. Det anrop som tagit kortast tid att exekvera (ms) inom aktuellt mätfönster/delta. Antal paket/anrop som ingår i delta-beräkningarna, t.ex. "de 50 senaste". Namn på webbtjänsten. Totalt antal exceptions/fel som inträffat för webbtjänsten sedan systemet startades. Det anrop som tagit längst tid att exekvera (ms) sedan systemet startades. Snittid för alla anrop (millisek.) sedan systemet startades. Det anrop som tagit kortast tid att exekvera (ms) sedan systemet startades. Sid 85/115

86 total.packets Totalt antal paket/anrop som behandlats sedan systemet startades Uppgradering kan mjukvaruuppgraderas då nyare versioner av produkten görs tillgängliga. Mer information om detta ges för respektive uppgradering. Var god kontakta Inera för information kring aktuella versioner [Ref 1]. Sid 86/115

87 13 AVINSTALLATION Avinstallationen tar bort de flesta filer och kataloger som skapats. Dock får man manuellt ta bort installationskatalogen i efterhand om så önskas, samt manuellt avregistrera tjänster (services). Det görs med hjälp av SC.exe och beskrivs lite längre ner. Om installationen var en Cluster Installation node 1, så skapades även en katalogstruktur på den delade diskytan. Innehållet på diskytan tas också bort manuellt. Oberservera att det kan vara bra att ta en backup på den delade diskytan, om man behöver återställa systemet. För att avinstallera: 1. Stoppa först tjänsten Lokal Säkerhetstjänst <version>, sedan Lokal Säkerhetstjänst <version> Terracotta. Se bilden nedan. Figur 62: exempelbild från services under verktyget Server Manager 2. Avinstallera sedan systemet enligt standardiserat sätt via Windows kontrollpanel. Se bilden nedan. Figur 63: förtydligande bild över avinstallation av tjänsten Sid 87/115

88 3. Välj Uninstall a program under menyn Programs. 4. Dubbelklicka på Lokal Sakerhetstjanst. (lokala Säkerhetstjänster kommer nu avinstalleras Avregistrera tjänster Avregistrera tjänster och ta bort register värden med hjälp av kommandot sc.exe Avregistrera tjänst: 1. Öppna kommando prompten. 2. Skriv sc delete Lokal Säkerhetstjänst 2.1 Terracotta (servicen för Terracotta avregistreras) 3. Skriv sc delete Lokal Säkerhetstjänst 2.1 ( servicen för lokala Säkerhetstjänster avregistreras). Se bilden nedan. Figur 64: förtydligande bild över användandet av kommandot sc.exe Sid 88/115

89 I. APPENDIX A Skapa behörighetsregler och metadata manuellt Regler och metadata kan skapas upp manuellt utan att använda applikationen som beskrevs tidigare. Det är lämpligt att använda texteditorn Notepad++ för att skapa regler/metadata enligt instruktionerna nedan. Manuell hantering av behörighetsregler I leveransen 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. Mallen ligger under mappstrukturen: <Lokal_sakerhetstjanst_win>/rules/regler_default_lokal.xml. Reglerna är uppdelade för respektive tjänst. Om exempelvis endast autentiseringstjänsten och spärr är installerade, är det endast dessa tjänster som måste anpassas för vårdgivarna som ska använda dem. Om en full installation har valts så ska samtliga tjänster anpassas. Bilden nedan visar ett exempel på tjänsten spärr i reglerna. Figur 6544: Regler för tjänsten Spärr utan vårdgivare Observera det rödmarkerade värdet i bilden. Detta värde, ${replace_this_careprovider}, är det som ska bytas ut till det specifika HSA-Id:et för er vårdgivare. Kopiera raden för varje vårdgivare ni har och som ska ges behörighet. Bilden nedan visar ett exempel på hur det kan se ut när fyra fiktiva vårdgivare har blivit specificerade. Sid 89/115

90 Figur 6645: Regler för tjänsten Spärr med vårdgivare När reglerna är skapade ska de läsas in i systemet. Se beskrivning för detta i kapitel Läsa in regler. Manuell hantering av metadata för konsumentsystem Vårdsystem som skall ges behörighet till systemet måste beskrivas i en metadata-fil där dess egenskaper anges. I leveransen ingår det en mall för metadata. Metadata-filen måste anpassas efter följande kriterier: HSA-id för de vårdgivare som ingår i konsumentsystemet. Konsumentsystemets HSA-id (entityid). Mallen ligger under mappstrukturen: <Lokal_sakerhetstjanst_win>\example\metadata\examplesystem-metadata.xml. Bilden nedan visar ett exempel på hur en metadata-fil som hanterar den fiktiva vårdgivaren ExampleCareProvider_1 ser ut. Värdet i entityid är konsumentsystemets HSA-id. Sid 90/115

91 Figur 6746: Anpassning av metadata för konsumentsystem Öppna konsumentsystemets klientcertifikat för att ta reda på vilket HSA-id konsumentsystemet har som ska specificeras i metadata-filen. 1. Öppna certifikatets leg.cer fil och klicka på Details. 2. Bläddra i listan som visas. Klicka på informationsfältet Subject. 3. En informationsruta visas. Det Serialnumber som visas i rutan är certifikatets serienummer, dvs. det HSA-id som ni ska specificera i metadata-filen som ni anpassar till systemet. 4. Öppna mallen för metadata-filen. <Lokal_sakerhetstjanst_win>\example\metadata\example-system-metadata.xml 5. Ange konsumentsystemets HSA-id för värdet i entityid. 6. Kontrollera att värdet för urn:sambi:names:attribute:systemrole är satt till system. 7. Byt ut värdet ExampleCareProvider_1 till HSA-id:et för den vårdgivare ni vill lägga till. 8. Kopiera raden för varje vårdgivare som ska ingå i filen och följ sedan instruktionen som gavs i föregående steg. Bilden nedan exemplifierar hur en metadata-fil kan se ut med flera vårdgivare. Observera att vårdgivarna är fiktiva och ska ersättas med korrekt HSA-id för respektive vårdgivare. Sid 91/115

92 Figur 6847: Exempel på en metadata-fil anpassat för ett konsumentsystem Läs in metadata-filen enligt beskrivningarna i kapitel Inläsning av metadata. Sid 92/115

93 II. APPENDIX B - Konfigurera den lokala brandväggen Konfigurera brandväggen lokalt för windows servrarna (om man valt att att slå av den lokala brandväggen, kan man direkt hoppa till kapitel Installation). Konfigurera inställningarna, se tabell regler brandvägg nedan, för brandväggen genom att starta verktyget Windows Firewall with Advanced Security som ligger under Adminstrative Tools. Skapa en ny regel under Inbound rules. Steg Val Beskrivning Rule Type Port Regel som kotrollerar anslutningar för TCP eller UDP port Protocol and Ports TCP Specific local ports Ange dom portar som beskrivs i tabellen under kapitel 3.2. Action Allow the connection Inkluderar anslutningar som vare sig är skyddade eller ej utav IPsec Profile Domain, Private, Regeln gäller för alla dessa val. Public Name Lokala Namn och beskrivning för regeln, säkerhetsjänster Tabell regler brandvägg III. APPENDIX C - Skapa separat servicekonto Vid installation av servicarna Lokal Säkerhetstjänst och Lokal Säkerhetstjänst Terracotta installeras de och körs default som Local System. Det är rekommenderat att man skapar ett separat servicekonto som servicen körs som i stället för detta. Sätt upp ett service konto 1. Skapa upp ett nytt servicekonto. Klicka på Start och sedan Run. 2. Skriv in följande kommando: lusrmgr.msc. Se figur: Run -> lusrmgr.msc nedan. Sid 93/115

94 Figur 69: Run -> lusrmgr.msc 3. Klicka på knappen OK. Vyn Local Users and Groups (Local) visas följande. Högerklicka på gruppen Users som figur: Lägg till ny användare nedan visar. Välj New user Figur 70: Lägg till ny användare 4. Ett fönster öppnas med ett formulär som ska fyllas i. Välj namn på användaren, beskrivning och lösenord med specifika inställningar. Se figure: fyll i användaruppgifter nedan. Sid 94/115

95 Figur 71: Fyll i användaruppgifter 5. Klicka på knappen Create. Klicka på knappen Close för att stänga fönstret. 6. En ny användare är nu skapad. Högerklicka på den nya användaren och välj Properties. Se figure: Properties nedan. Figur 72: Properties Sid 95/115

96 7. Klicka på fliken Member of och sedan på knappen Add. Se figur: katergorisering av användaren nedan. Figur 73: Kategorisering av användaren 8. Ett fönster visas följande där man får välja vilken grupp som användaren ska ingå i. Skriv in Users i textfältet, enligt figur: Lägg till användaren till gruppen Users nedan. Klicka sedan på Check Names. Sid 96/115

97 Figur 74: Lägg till användaren till gruppen "Users" 9. Användaren blir följande inlagd i administratörsgruppen. Se figure: Exempelresultat nedan. Figur 75: Exempelresultat 10. Klicka på knappen OK. Skapandet av kontot är nu klart. Sid 97/115

98 11. För att användaren ska få behörighet att köra en service behöver den tilldelas en policy för detta och det gör man genom att starta Local Security Policy som återfinns under Control Panel\System and Security\Administrative Tools, se figur: Administrative Tools vyn nedan. Figur 76: "Administrative Tools" vyn 12. Klicka på Local Policies samt User Rights Assignment i menyn till höger. 13. Lokalisera Policyn Log on as a service i listan till höger och dubbelklicka på den. Se figur: Local Policies vyn nedan. Sid 98/115

99 Figur 77: "Local Policies" vyn Sid 99/115

100 Figur 78: "Log in as a service" vyn 14. Välj Add User or Group, se figur: Log in as a service vyn ovan och peka ut den användare du vill servicen ska köras som. I exemplet är det den lokala användaren stservice som vi skapade i tidigare steg, se figur: Select users or group vyn nedan. Sid 100/115

101 Figur 79: "Select users or group" vyn Välj Check Names för att verifiera användaren du lagt till. Har du angivit en giltig användare som finns på den plats du pekat ut kommer användarnamnet i textboxen bli understruken, se figur: Select users or group vyn ovan. Välj sedan OK. Sid 101/115

102 Figur 80: "Log in as a service" vyn Verifiera att din användare nu ligger med i listan över användare som har Log on as a service. Välj OK, se figur: Log in as a service vyn ovan. Sid 102/115

103 Figur 81: "Administrative tools" vyn Nästa steg är att berätta för Servicen vilken användare den ska köras som. Detta gör du genom att gå till Services som återfinns under Control Panel\System and Security\Administrative Tools, se figur: Administative tools vyn ovan. Sid 103/115

104 Figur 82: "Services" vyn Leta rätt på servicen Lokal Säkerhetstjänst i listan och dubbelklicka på den, se figur Services vyn ovan. Sid 104/115

105 Figur 83: Lokal säkerhetstjänst inställningar Välj sedan Log On fliken i dialogen. Default är värdet satt till Local Systen Account men vi ska nu ange en specifik användare som ska köra servicen så välj istället This account och välj Browse för att peka ut den användare vi vill köra servicen som, se figur: Lokal säkerhetstjänst inställningar ovan. Sid 105/115

106 Figur 84: Val av användare som Lokala säkerhetstjänster ska köras som Ange den användare du vill servicen ska köras som. I exemplet är det den lokala användaren stservice som vi skapade i tidigare steg. Välj Check Names för att verifiera användaren du lagt till. Har du angivit en giltig användare som finns på den plats du pekat ut kommer användarnamnet i textboxen bli understruken, se på figur: Val av användare som Lokala säkerhetstjänster ska köras som ovan. Välj sedan OK. Sid 106/115

107 Figur 85: Lokal säkerhetstjänst inställningar Ange lösenordet för användare och bekräfta det. Välj sedan på OK. Nu när Säkerhetstjänster körs som en specifik använder så måste vi även ge denna användare behörighet till filerna och katalogerna som systemet ligger i, se figur: Lokal säkerhetstjänst inställningar ovan. Sid 107/115

108 Figur 86: Lokal säkerhetstjänst installationskatalog Välj utforskaren och bläddra fram dig till den katalog system är installerat i, se figur: Lokal säkerhetstjänst installationskatalog ovan. I exemplet ligger systemet installerat under C:\Program Files\Inera\Lokal Sakerhetstjanst. Höger klicka på katalogen Lokal Sakerhetstjanst eller motsvarande katalog i er miljö och välj Properties samt välj Security fliken, se figur: Security vyn nedan. Sid 108/115

109 Figur 87: Security vyn Välj Edit, se figur: Security vyn ovan. Sid 109/115

110 Figur 88: Behörighetsinstallningar Välj Add, se figur: Behörighetsinställningar ovan. Sid 110/115

111 Figur 89: Lägg till användare Peka ut användaren som vår service körs som och välj sedan OK, se figur: Lägg till användare ovan. Sid 111/115

112 Figur 90: Behörigheter för stservice Se till att vår nytillagda användare sedan är vald och kryssa i Full Control och avsluta sedan genom att trycka OK och även OK i föregående dialog, se figur: Behörigheter för stservice ovan. Lägg till behörigheter i registret Användaren behöver även behörighet att läsa och skriva i registret. 1. Klicka på Start och skriv in regedit. 2. Kör Regedit.exe. Sid 112/115

113 3. Sök fram till katalogstrukturen (under HKEY_LOCAL_MACHINE ) där Säkerhetstjänster är installerad. Se bild nedan. Figur 91: Registry Editor Sid 113/115

114 4. Högerklicka på motsvarande huvudkatalog till Säkerhetstjänster. Se bild nedan. Figur 92: Permissions 5. Välj er serveranvändare. Lägg till följande behörigheter (permissions) för användaren: Full Control och Read. Dessa behörigheter sätts med kryssrutorna som bilden nedanvisar. Klicka sedan på knappen OK. Figur 93: Behörigheter för användare Sid 114/115

115 IV. APPENDIX D - Förutsättningar för en fail-over lösning Förutsättningarna som diskuteras i detta avsnitt är endast relevant om en fail-over lösning skall installeras. Det vill säga, en installation med fler än en nod. Om endast en nod (en så kallad SingleServer ) ska nyttjas kan man gå vidare till Installation av SingleServer. Delad diskyta Samtliga noder i fail-overlösningen skall använda samma sökväg till den delade diskytan. UNCsökvägar (Nätverkssökväg, t.ex. \\my.share.domain.se\share) stöds inte. För att uppnå det kan man skapa en symbolisk länk på respektive nod, genom att använda kommandot mklink. Exempel - Windows share (CGI rekommenderar att INTE använda ett vanligt Windows share pga. prestandaproblem) Sökväg som valts till delad diskyta på nod #1, nod #2, nod #n: C:\share Sökväg till nätverksresurs: \\my.share.domain.se\share På samtliga noder skapar man en symbolisk länk, se figur: mklink share domän nedan, från C:\share till \\my.share.domain.se\share med hjälp av kommandot mklink i kommandokonsolen: mklink /D C:\share \\my.share.domain.se\share Figur 94: mklink share domän Under installationsförfarandet skall man ange sökvägen till den delade diskytan (symboliska länken C:\share). Sid 115/115