Tjänst under avveckling
Dessa sidor kommer att tas bort 2023-01-01
OBSERVERA: Supporten upphör 2023
I juni 2021 meddelade Inera i ett nyhetsbrev att lokala installationer av Lokala Säkerhetstjänsterna Spärr, Logg och Samtycke inte kommer att erbjudas eller supportas från och med 1 januari 2023.
Nya installationer av Lokala Säkerhetstjänster 2.17 rekommenderas av denna anledning inte för en i längden hållbar lösning.
För information om lokal installation av den nya IdP:n se denna sida.
Dokumenthistorik
Datum | Version | Namn | Förändring |
---|---|---|---|
| 0.1 | Dokument upprättat i Confluence | |
| 0.2 | Uppdaterat för 2.17 | |
0.3 | Okänd användare (sundbergs) | Uppdaterat instruktioner | |
| 1.0 | Fastställd | |
| 1.1 | Rättat adress till PU-tjänsten via NTjP | |
| 1.2 | Unknown User (lexhagenm) | Rättat adress för spärreplikering via NTjP |
| 1.3 | Lagt till info om behovet av nerladdning av de nationella spärrarna. | |
| 1.4 | Ändrad/ny certifikatsinformation då SITHS-certifikat inte längre bör användas i front-end | |
| 1.5 | Tagit bort extern beroende till HSA-kontrakt GetPersonAuthorizedToSystemIncludingProtectedPerson som endast används i den nationella installationen. |
Innehållsförteckning
1. Inledning
1.1. Allmänt
Säkerhetstjänster är en produkt som är utformad för att hantera patientuppgifter enligt patientdatalagen (PDL) och tillgodose användare av systemet med en säker autentisering. Produkten innehåller olika tjänster (som exempelvis Autentiseringstjänsten och Spärrtjänsten) som kan installeras separat eller tillsammans som ett komplett paket.
NOTERA: Att installera och konfigurera Säkerhetstjänster kräver en viss teknisk IT-kompetens inom nätverk, databaser, operativsystem och eventuell felsökning.
OBS! Från version 2.11 så är installationspaketet detsamma för både Linux och Windows, men med separata installationsförfaranden.
OBS! Från version 2.15 så har installationsprogrammet förbättrats. Installationen går till på samma sätt som tidigare, där man skall ange ett antal konfigurationsvärden för att systemet skall starta upp.
Det ges även möjlighet att när som helst under installationen spara dom konfigurationsvärden man matat in till en fil, för att vid ett senare tillfälle återuppta installationen, utan att behöva mata in alla värden på nytt igen.
SITHS-certifikat
Sedan april 2019 är det inte rekommenderat att använda SITHS-certifikat för Webbsidor (front-end) eftersom SITHS som utgivare har beslutat sig för att lämna Microsofts rotcertifikat-program.
Man vill fortfarande ha ett SITHS-certifikat för t.ex Spärrtjänstens WebService-gränssnitt och för att kunna kommunicera med t.ex NTjP men man bör alltså även beställa ett certifikat till front-end-domänerna från annan utgivare t.ex SSL-certifikat från Telia eller DigiCert.
Notera att till skillnad från SITHS så har övriga utgivare stöd för Subject Alternative Name, SAN, i sina certifikat så det ska räcka med ett certifikat för alla front-end-domäner i en installation (app, idp, secure.idp) och ett SITHS-certifikat för ws-domänen.
För befintliga installationer med SITHS-certifikat i front-end finns en guide skriven: Byta bort SITHS-cert i frontend
NOTERA: Titta igenom Checklistan innan man påbörjar installationen av Lokala Säkerhetstjänster. Den handlar om förberedelser som skall utföras i god tid innan installationen av Säkerhetstjänster påbörjas.
Detta dokument beskriver installationen av lokala Säkerhetstjänster. Dokumentet beskriver i huvudsak:
- Portval - SSL standardport 443 eller Säkerhetstjänster 8443-8446 portar.
- Installation av databasserver MySQL
- Installation av databasserver MongoDB
- Installation av applikationsserver
- Systemkonfiguration och uppsättning av behörighet
- Administration, förvaltning och underhåll
Tabellen nedan beskriver vad installationspaketet innehåller.
Sökväg | Beskrivning |
---|---|
db | Konfigurationsfiler och databasskript (MySQL). |
doc | All dokumentation |
example | Exempelkod för hur man kan ansluta en SP (webb) mot IdP:n (lokal Autentiseringstjänst). Exempelkod i java och .NET för autentisering av rika klienter. |
install | Installationsskript och systemkomponenter. |
license | Samlad licenskatalog |
rules | Behörighetsregler som ska modifieras och läsas in i systemet |
schema_wsdl | Tjänstekontrakten för lokala Säkerhetstjänster |
templates | Mall regel och metadatafil |
upgrade | Uppgraderingspaket med program, skript och instruktioner |
1.2. Begrepp
Begrepp | Beskrivning |
---|---|
Autentiseringstjänst | Även kallad för IdP. Den tjänst som kontrollerar användarens kreditiv och utfärdar en SAML-biljett. |
Bundel | Komponent till ett program |
CDC | Common Domain Cookie. En webbläsarkaka som lagrar historik från tidigare besökta IdP:er. |
CRL | Certificate Revocation List En lista med certifikat och dess status (ex. revokerat den 12 december 2011). Dessa listor uppdateras oftast med jämna intervaller. |
HA | High Availability. En tjänst som har hög tillgänglighet. |
HPTA | En HSA-policytillämpning (HPTA) skrivs av varje direktansluten verksamhet och beskriver hur den enskilda organisationen uppfyller kraven i HSA-policy. |
HSA | Hälso- och sjukvårdens adressregister, HSA, är en elektronisk katalog som innehåller kvalitetssäkrade uppgifter om personer, funktioner och enheter i Sveriges kommuner, landsting och privata vårdgivare. |
HSA-WS | Webbservicetjänst mot HSA-katalogen som säkerhetstjänster använder sig av. |
IdP | Identity Provider (Autentiseringstjänst) Tjänst som autentiserar en aktör och utfärdar, i detta fall, en SAML-biljett. Autentiseringstjänsten (IdP) är en tjänst som levereras med Säkerhetstjänster. |
Metadata | Konfigureringsdata skriven i XML-format. Används för att ge konsumentsystem behörighet till Säkerhetstjänster. SP-metadata importeras in i IdP:n och IdP:ns metadata importeras in i SP:n för att konfigurera/behörighetsstyra IdP:n och SP:n. |
Multicast | Gruppsändning till en eller flera noder samtidigt Används av applikationsservrarna. |
NTP | Network Time Protocol. Används för synkronisering servrarnas realtidsklocka. |
OCSP | Online Certificate Status Protocol En aktiv tjänst som svarar på certifikatstatusförfrågningar. Till skillnad från CRL tillhandahåller denna tjänst alltid aktuell status för certifikatet som efterfrågas. |
PDL | Patientdatalagen http://www.datainspektionen.se/lagar-och-regler/patientdatalagen/ |
Personuppgiftstjänst | En nationell tjänst som på ett effektivt sätt hanterar personuppgifter från Skatteverket (Navet), för till exempel adressuppgifter som finns i befolkningsregistret. |
REST | Representational State Transfer. Beskriver hur tjänster för maskin-till-maskin kommunikation kan ske via webbteknologi. |
RIV | Regelverk för Interoperabilitet inom Vård och omsorg. www.rivta.se |
RIV TA | RIV Tekniska anvisningar. Syftet med denna anvisning är att beskriva hur man realiserar utbytet av information mellan två parter. RIV Tekniska Anvisningar är en integrerad del i den nationella arkitekturen. |
SAMBI | SAML-profil för samverkan för Behörighet och Identitet inom hälsa, vård och omsorg. Beskriver hur egenskaper namnsätts i SAML-biljetten. http://www.inera.se/TJANSTER--PROJEKT/Sakerhetstjanster/Dokument/ |
SAML | Security Assertion Markup Language En standard som beskriver hur egenskaper och dess värden skall beskrivas i XML-format. |
SAML biljett | Ett intyg som Autentiseringstjänsten utfärdar som innehåller en samling med egenskaper enligt SAML. Inom hälsa, vård och omsorg används SAML-profilen SAMBI. |
Single installation | En installationsform där endast en nod används. |
SITHS | SITHS är en nationell lösning för säker IT i hälso- och sjukvården. |
SP | Service Provider. Den som erbjuder en tjänst, kan vara ett lokalt vårdsystem eller en tjänst i de lokala säkerhetstjänsterna, t ex Samtyckestjänsten. De lokala tjänsterna i Säkerhetstjänsterna, förutom IdP:n, grupperas som en SP. |
Tjänsteplattformen (TP) | Tjänsteplattformen är en nationell teknisk plattform som förenklar, säkrar och effektiviserar informationsutbytet mellan olika IT-system inom vård och omsorg. http://www.inera.se/TJANSTER--PROJEKT/ICC-Integration-Competence-Center/ |
1.3. Referenser
Referensnr | Namn | Adress |
---|---|---|
Ref 1 | Inera AB | |
Ref 2 | Inera AB |
2. Systemkrav
Lokala Säkerhetstjänster levereras med installationsanvisningar för Windows Server 64bit. Denna leverans är kvalitetssäkrad på Windows Server 2012 R2 64bit. Lokala Säkerhetstjänster bör driftsättas med minst tre dedikerade maskiner, en applikationsserver och två databasservrar.
Applikationsservern bör vara flerkärniga med minst 12 GB RAM.
MySQL databasservern för bör vara flerkärniga med minst 8 GB RAM dedikerat för MySQL-servern.
MongoDB servern för bör vara flerkärniga och hur mycket RAM som krävs är beuppstart av lokal Säkerhetstjänst på övriga noderroende på hur mycket respektive vårdgivare loggar. Riktlinje är att 40 miljoner loggposter med dess index tar c:a 20 GB RAM dedikerat för MongoDB-servern.
2.1. Diskyta
För att kunna köra systemet med flera servrar i en HA-lösning krävs att samtliga noder har tillgång till en delad diskyta där bl.a. 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.
Den delade diskytan rekommenderas att vara redundant så att man inte får en Single Point Of Failure, då systemet kräver den delade diskytan för att kunna starta. Default är namnet på katalogen: C:\share i konfigurationen nedan.
Den delade diskytan måste sättas upp med en symbolisk länk, se Appendix C - Krav på delad diskyta vid en fail-over installation
2.1.1. Delad diskyta för Säkerhetstjänster
Installationsdisken bör minst vara 20 GB (mer rekommenderas).
Den delade diskytan (<enhet>\share) för applikationsservrarna bör minst vara 100 GB.
2.1.2. Diskyta för MySQL
Diskytan för MySQL bör minst vara 200 GB.
2.1.3. Diskyta för MongoDB
När databaserna för rapporthanteringen skapas vid installation, behövs ungefär 10 GB diskyta. MongoDB allokerar upp disk som senare används när loggar läggs till i databasen. Fyra databaser skapas vid installationen, som använder detta utrymme. Det är för:
PDL-loggar (lagras default i 18 månader)
Arkivsökningar (PDL-loggar läggs till temporärt och raderas när rapporten är klar)
Statistikloggar som loggar händelser vid inloggning och utloggning. (Lagras som default i 3 månader)
Systemloggar (Används inte primärt utan är en backup om annan loggning inte kan köras eller om den konfigureras att användas)
Ytterligare diskyta för MongoDB är helt beroende av hur mycket systemet används:
Riktlinje är att 40 miljoner PDL-loggar tar c:a 115 GB diskarea.
Detsamma gäller för statistikloggning och antalet loggar beror på hur många som använder systemet.
Beroende på om MongoDB används för systemloggning kan antalet systemloggar öka dramatiskt om t.ex. loggnivå ändras till TRACE. Det kan generera stora mängder loggar och diskyta kan snabbt konsumeras.
2.2. Tidssynkronisering
Operativsystemen för lokala Säkerhetstjänster skall vara tidssynkroniserade för att systemet skall fungera korrekt. Felaktigt inställd tid kan få till följd att autentisering av klienter misslyckas samt att systemet lagrar och/eller uppger felaktiga tidpunkter för verksamhetsdata. Detta säkerställs på operativsystemnivå och är inte en del av produkten. Vi rekommenderar att rådfråga dem som ansvarar för just er serverdrift.
2.3. Lastbalanserare
Från och med version 2.7 av Lokala Säkerhetstjänster går det att använda SSL standardport (443) för alla ingående tjänster istället för att man externt ansluter till tjänsterna mot en unik port. En förutsättning för att detta ska fungera är att en lastbalanserare finns och är konfigurerad att istället lyssna på, för tjänsterna, unika ip-adresser och som styr trafiken vidare mot applikationsserverns interna portar (som fortfarande måste vara unika för tjänsterna).
3. Plattform och tredjepartsprodukter
3.1. Java
För att köra applikationsservern krävs Oracle Java SE 8, JDK, 64 bitar, som finns att hämta på: http://www.oracle.com/technetwork/java/javase/downloads/index.html.
Notis om licensen för Oracles distribution av Java;
om man inte uttryckligen slå på användning av t ex Java Mission Control eller Flight Recorder triggas inte den kommersiella licensen. Säkerhetstjänster gör inte detta. Se https://docs.google.com/document/d/17OF811wWjjCnmDPJDD6v2c_nMO93e5evjravdCOkXMQ/edit för detaljerna
3.1.1. JCE - Java Cryptography Extension
Det krävs även ett tillägg, http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html, som måste installeras för att kunna nyttja 256-bitars kryptering.
3.2. MySQL
Lokala Säkerhetstjänster kräver databasservern MySQL. Systemet är kvalitetssäkrat med MySQL Community Server 5.6.37 och säkerhetstjänsterna kräver att ni använder en version ur 5.6-serien, dock senare än version 5.6.18. Tidigare 5.6 versioner har problem gällande minneshanteringen.
Databasen bör ha redundant lagring och/eller en backup-rutin vid produktionssättning. Eftersom detta är en driftrelaterad fråga som kan lösas på en mängd olika sätt så beskrivs det inte mer här.
I denna release av Lokala Säkerhetstjänster har vi valt att ligga kvar på MySQL Community Server 5.6.(37), då MySQL Community Server 5.7.x innehåller ett fel gällande hantering av XA-transaktioner i redundanta replikerings-miljöer (master-slave, master-master). Oracle är medvetna om detta, men kommer inte att hinna släppa någon patch inför denna release av Lokala Säkerhetstjänster 2.17
3.3. MongoDB
MongoDB är en lättviktig (NoSQL) databas som används för att hantera uppföljning av verksamhetsloggar (PDL-loggar). Databasen håller PDL-loggar i 18 månader (konfigurerbart) tillbaka i tiden och är den databas som loggrapporter genereras från. Loggposter som är äldre än 18 månader tas bort från MongoDB och finns arkiverade som zip-filer för långtidslagring.
MongoDB används för att snabbt kunna söka i stora mängder loggposter och generera rapporter för uppföljning. MongoDB är därför ett krav vid installation av lokal Loggtjänst.
Denna databas används även som reservkälla för systemets händelseloggar ifall anslutningen till MySQL-databasen skulle falla ifrån samt för insamlande av statistik runt autentiseringshändelser. Dessa funktioner går dock att inaktivera ifall man skulle behöva en lokal installation utan tillgång till MongoDB (se Installation utan databasen MongoDB som beskrivs senare i dokumentet)
Systemet är kvalitetssäkrat mot MongoDB-server 3.4.7. Hur databasen bör sättas upp för Säkerhetstjänster beskrivs i avsnitt Installationsanvisningar för MongoDB
3.4. Lastbalanserare
En lastbalanserare som klarar HTTPS krävs för att köra Säkerhetstjänster med skalskydd och trafikdirigering. Det innebär att lastbalanserare krävs för att kunna köra Säkerhetstjänster med standardport 443 för samtliga tjänster. Anvisningar för lastbalanserare beskrivs inte i detta dokument. Lastbalansering till applikationsserver kan ske med round-robin då all sessionsdata (SSL-sessioner) delas mellan applikationsservrarna och de externa HTTPS-portarna som används bör TCP-monitoreras, innan lastbalansering sker till applikationsservern.
3.5. Funktionscertifikat
Innan installation av lokala Säkerhetstjänster påbörjas måste funktionscertifikat för legitimering införskaffas, utfärdat för Lokala Säkerhetstjänsters olika domäner. Funktionscertifikat används för att identifiera applikationsservern vid all sorts kommunikation.
Sedan april 2019 är det inte rekommenderat att använda SITHS-certifikat för Webbsidor (front-end) eftersom SITHS som utgivare har beslutat sig för att lämna Microsofts rotcertifikat-program. Man vill dock fortfarande ha ett SITHS-certifikat för t.ex Spärrtjänstens WebService-gränssnitt och för att kunna kommunicera med t.ex NTjP men man bör alltså även beställa ett certifikat till front-end-domänerna från annan utgivare t.ex SSL-certifikat från Telia eller DigiCert. Notera att till skillnad från SITHS så har övriga utgivare stöd för Subject Alternative Name, SAN, i sina certifikat så det ska räcka med ett certifikat för alla front-end-domäner i en installation (app, idp, secure.idp) och ett SITHS-certifikat för ws-domänen
Funktionscertifikaten skall vara utfärdade till de DNS-namn som skall användas för applikationsservern. Var god kontakta Inera för information kring SITHS funktionscertifikat [Ref 1].
Det kan se ut som i tabellen nedan för de två nationella installationerna av Säkerhetstjänster:
Domän | SAN | Utgivare | Kommentar |
---|---|---|---|
CN = sakerhetstjanst.inera.se | DNS Name=sakerhetstjanst.inera.se DNS Name=sakerhetstjanst.sjunet.org DNS Name=idp2.sakerhetstjanst.inera.se DNS Name=idp2.sakerhetstjanst.sjunet.org DNS Name=secure.idp2.sakerhetstjanst.inera.se DNS Name=secure.idp2.sakerhetstjanst.sjunet.org | DigiCert Inc CN = DigiCert SHA2 High Assurance Server CA | |
CN = ws.sakerhetstjanst.inera.se | SITHS har inget SAN-stöd | SITHS CN = SITHS Type 3 CA v1 | För PreProd/testmiljöer är utgivaren CN = SITHS Type 3 CA v1 PP |
CN = ws.sakerhetstjanst.sjunet.org | SITHS har inget SAN-stöd | SITHS CN = SITHS Type 3 CA v1 | För PreProd/testmiljöer är utgivaren CN = SITHS Type 3 CA v1 PP |
3.5.1. Ytterligare funktionscertifikat
Om lokala Säkerhetstjänster ska nyttjas tillsammans med andra IdP:er i en federation, krävs ytterligare ett SITHS funktionscertifikat som är utfärdat för IdP:n på den gemensamma domänen inom federationen. T ex om den gemensamma domänen i federationen är commondomain.example.com, behöver även denna IdP ha ett funktionscertifikat t.ex. idp.commondomain.example.com.
3.6. CSP - Cryptographic Service Provider
Vid autentisering och anslutning till administrationsgränssnittet för lokala Säkerhetstjänster via webbläsare, krävs tillgång till en CSP på användarens dator. Detta för att kunna använda ”hårda certifikat” (t.ex SITHS-kort). T.ex. kan Net iD användas. Vänligen kontakta Inera för information kring SITHS och Net iD [Ref 1].
3.7. Kluster med Infinispan (Distributed in-memory cache)
Vår rekommendation är att Säkerhetstjänster installeras i ett kluster med två noder. Systemet har en inbyggd lösning med Infinispan, som hjälper noderna att dela resurser (som exempelvis systemets konfigurationer) som ska finnas på en delad diskyta. Fördelen med kluster är att det bidrar till att systemet får högre prestanda, tillgänglighet och kan skalas upp ytterligare.
Infinispan kommunicerar mellan noderna i klustret via UDP (multicast) eller TCP. Infinispan rekommenderar UDP för bäst prestanda. Förvalt vid installationen ges en multicastadress (239.0.10.1) men den lokala driftsorganisationen bör kontaktas för att bestämma vilken adress som ska användas. Mer information om multicast adresser hittar ni via följande länk: http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xhtml. Väljer man TCP måste noderna i klustret anges i en statisk lista i konfigurationen (beskrivs närmare nedan).
3.8. Ciphersuites som används
Följande ciphersuties kan användas av en klient för att konsumera säkerhetstjänsters WS- och Webbgränssnitt:
Stöds bara i TLS 1.2 1. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 2. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 3. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 4. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 5. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA 6. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA 7. TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 8. TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 9. TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 10. TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 11. TLS_DHE_RSA_WITH_AES_256_CBC_SHA 12. TLS_DHE_RSA_WITH_AES_128_CBC_SHA Stöds i TLS 1.0 och senare 13. TLS_RSA_WITH_AES_256_GCM_SHA384 14. TLS_RSA_WITH_AES_128_GCM_SHA256 15. TLS_RSA_WITH_AES_256_CBC_SHA256 16. TLS_RSA_WITH_AES_128_CBC_SHA256 17. TLS_RSA_WITH_AES_256_CBC_SHA 18. TLS_RSA_WITH_AES_128_CBC_SHA
3.9. Telnet
Installationen av Säkerhetstjänster kräver att man har en telnet-klient installerad på applikationsservrarna.
4. Säkerhetstjänsters beroenden till externa system
4.1. Behörighet externa system
Kommunikation med externa system sker alltid med mutual TLS vilket innebär att även den anropande tjänsten presenterar sig med ett certifikat. I vårdsverige är detta för detta certifikat ofta ett SITHS-certifikat.
Traditionellt har Säkerhetstjänster alltid använt front-end-certifikatet för huvud-domänen för extern kommunikation. När det inte längre är rekommenderat att använda SITHS-certifikat i front-end så går inte detta längre utan det blir WebService-certifikatet som måste användas.
Se alltså till att ange rätt certifikat vid beställning av accesser i NTjP och andra externa system.
HSA
Lokala Säkerhetstjänster har traditionellt använt HSA's äldre gränssnitt kallat HSA-WS. Detta gränssnitt är dock under avveckling och nya anslutningar tillåts därför inte. Som ny anslutning räknas även en befintlig installation som byter certifikat. Det är därför rekommenderat att man som ansvarig för en lokal installation av Säkerhetstjänster planerar en övergång till det nyare gränssnittet HSA-TK. Se nedan vilka av HSA's tjänstekontrakt man via Inera's elektroniska beställningsstöd måste ansöka om access till. Se även 2.17 Release Notes
4.2. HSA-WS
HSA-WS är under avveckling!
HSA-WS är en webbtjänsteanslutning till underliggande HSA-katalog. Lokala Säkerhetsjänster är kompatibelt med HSA-WS version 2.27 eller senare. Lokala Säkerhetstjänster ansluter sig till HSA-WS för att hämta information om användare, användares medarbetaruppdrag, vilka vårdenheter som tillhör en vårdgivare, namn på vårdenheter m.m. Applikationsserverns funktionscertifikat för legitimering behöver finnas i HSA-katalogen med behörighet att anropa följande operationer:
- GetCareUnit
- GetCareUnitList
- GetHsaPerson
- GetHsaUnit
- GetMiuForPerson
- Ping
För att en användare ska kunna autentisera sig krävs det att användaren finns upplagd i HSA-katalogen. Det finns dock inget krav på att användaren måste ha ett medarbetaruppdrag. Om användaren saknar medarbetaruppdrag kommer en ”tom” SAML-biljett att skapas, d.v.s utan egenskaper för användaren och det är upp till konsumenten av SAML-biljetten, SP:n, att avgöra vad som som då skall ske (t.ex. visa ett felmeddelande).
Notera: För att få behörigheterna till HSA-WS behöver man dels ha uppdaterat sin HPTA där ovanstående operationer finns med. Därefter får man skicka ett ärende till nationell kundservice med det HSA-id på det certifikat som säkerhetstjänster ska använda för att systemet ska få access till ovanstående operationer. Observera att dessa ärenden måste begäras av den/de som är HSA-ansvarig.
Adresser till HSA-WS:
Miljö | Adress |
---|---|
Test | https://wstest.hsa.sjunet.org/svr-hsaws2/hsaws |
Produktion | https://ws.hsa.sjunet.org/svr-hsaws2/hsaws |
4.3. HSA-RIVTA
Från och med version 2.15 finns möjlighet att använda sig av HSA-RIVTA kontrakt. Kontakta Inera för mer information om ni funderar över anslutning till HSA-RIVTA.
Patch krävs
För att kunna använda HSAs tjänstekontrakt via NTjP krävs en installation av en rättning
Behörighet att via NTjP anropa HSA-kontrakt via Nationella Tjänsteplattformen:
• GetEmployeeIncludingProtectedPerson
• GetCredentialsForPersonIncludingProtectedPerson
• GetHealthCareUnit
• GetHealthCareUnitList
4.4. Revokeringskontroll av certifikat
Applikationsservern för lokala Säkerhetstjänster använder i första hand OCSP och i andra hand CRL för att kontrollera om ett certifikat är spärrat och därmed inte godkänt för användning. Adressen till servrarna som används för OCSP och CRL hämtas från certifikaten och kan därför variera beroende på vilka certifikat som används. Dessa servrar måste kunna anropas från applikationsservern över HTTP (default port 80).
Exempel på adresser till crl och ocsp (Produktion):
Certifikat | CRL-adress | OCSP-adress |
---|---|---|
SITHS Type 1 CA v1 | http://crl1.siths.se/sithsrootcav1.crl http://crl2.siths.sjunet.org/sithsrootcav1.crl | http://ocsp1.siths.se/ http://ocsp2.siths.sjunet.org/ |
SITHS CA v3 SITHS CA v4 | http://www.carelink.se/siths-ca/ca003.crl | http://sithsocsp.trust.telia.com/ |
Exempel på adresser till crl och ocsp (Test):
Certifikat | CRL-adress | OCSP-adress |
---|---|---|
SITHS_Type_1_CA_v1_PP | http://crl1pp.siths.se/sithsrootcav1pp.crl http://crl2pp.siths.sjunet.org/sithsrootcav1pp.crl | http://ocsp1pp.siths.se/ http://ocsp2pp.siths.sjunet.org/ |
SITHS CA TEST v3 SITHS CA TEST v4 | http://www.carelink.se/siths-ca/test-crl0003.crl | http://sithsocsp.preprod.trust.telia.com/ |
4.5. Personuppgiftstjänsten - Personuppgiftstjänsten
Personuppgiftstjänsten är en tjänst som innehåller personuppgifter. Lokala Säkerhetstjänster använder Personuppgiftstjänsten via NTjP för att hämta patienters namn i användargränssnittet.
Behörighet krävs för att via NTjP anropa följande metod:
- GetPersonsForProfile v3
Adresser till Personuppgiftstjänsten via tjänsteplattformen:
Miljö | Adress |
---|---|
Test Sjunet | https://qa.esb.ntjp.sjunet.org:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21 |
Test Internet | https://qa.esb.ntjp.se:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21 |
Produktion Sjunet | https://esb.ntjp.sjunet.org:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21 |
Produktion Internet | https://esb.ntjp.se:443/vp/strategicresourcemanagement/persons/person/GetPersonsForProfile/3/rivtabp21 |
Uppgifter som matas in under Generell konfiguration → PU - V3 WS Proxy Impl 1.0.0
4.6. Nationell Spärrtjänst*
Den lokala Spärrtjänsten har inbyggd funktionalitet för synkronisering av spärrdata mot den nationella Spärrtjänsten. Innan replikeringen aktiveras måste förvaltningsorganisationen för nationell Spärrtjänst kontaktas för att öppna upp access till den nationella Spärrtjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].
Behörighet krävs för att via NTjP anropa följande metoder:
- GetBlocks v4
- RegisterBlock v4
- UnregisterBlock v4
- RegisterTemporaryRevoke v4
- UnregisterTemporaryRevoke v4
Adresser spärreplikering:
Miljö | Adress |
---|---|
Test Sjunet | https://qa.esb.ntjp.sjunet.org:443/vp/informationsecurity/authorization/blocking |
Test Internet | https://qa.esb.ntjp.se:443/vp/informationsecurity/authorization/blocking |
Produktion Sjunet | https://esb.ntjp.sjunet.org:443/vp/informationsecurity/authorization/blocking |
Produktion Internet | https://esb.ntjp.se:443/vp/informationsecurity/authorization/blocking |
Uppgifter som matas in under Generell konfiguration → Block National V4 WS ProxyImpl for RIV 2.1 1.0.0.
4.7. Nationell Loggtjänst*
Den lokala Loggtjänsten har inbyggd funktionalitet för att hämta hem den egna vårdgivarens PDL-loggar från den nationella Loggtjänsten via dess hämtningstjänst. Detta för att man lokalt ska kunna köra och få en loggrapport med loggar, både från de nationella systemen och ens lokala vårdsystem.
Innan hämtningstjänsten aktiveras måste förvaltningsorganisationen för nationell Loggtjänst kontaktas, för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].
Följande adresser används för hämtningstjänsten:
Miljö | Adress |
---|---|
Acceptanstest | https://ws.acctest.sakerhetstjanst.sjunet.org/ |
Produktion | https://ws.sakerhetstjanst.sjunet.org/ |
Tjänsterna Spärr och Samtycke behöver logga sina PDL-loggar till en loggtjänst. Detta kan vara en lokal Loggtjänst eller den nationella Loggtjänsten via tjänsteplattformen. För adresser/portar se avsnitt Tjänsteplattformen nedan.
Väljer man att använda den nationella Loggtjänsten, måste förvaltningsorganisationen för nationell Loggtjänst kontaktas för att öppna upp access till tjänsten samt konfigurera vilka vårdgivare som denna lokala Loggtjänst tillåts hantera nationellt. Hur detta görs beskrivs senare i dokumentet.
Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].
*Nationell Loggtjänst kan användas om någon av tjänsterna Spärr, Samtycke eller Logg installeras.
4.8. Tjänsteplattformen*
Installeras Samtyckestjänsten måste den lokala Säkerhetstjänsten registreras som producent i tjänsteplattformen. Detta för att samverkan ska kunna ske med de nationella tjänsterna. T ex en nationell tjänst som vill läsa från den lokala instansen, ifall ett samtycke finns registrerat.
Figuren nedan illustrerar hur en läsande nationell tjänst routas via den nationella tjänsteplattformen, genom en lokal tjänsteplattform (valfri) för att till sist hamna i den lokala Samtyckestjänsten.
Figur: Principer för samverkande tjänster för hantering av samtycke
Installeras någon av tjänsterna Spärr och Samtycke och konfigureras för att logga PDL-loggar till den nationella Loggtjänsten, måste de lokala Säkerhetstjänsterna registreras som konsument i tjänsteplattformen.
Tjänsten Spärr replikerar sina spärrar till den nationella Spärrtjänsten via tjänsteplattformen, vilket gör att den måste registreras som konsument i tjänsteplattformen.
Kontakta Ineras förvaltning i god tid före driftstart för att registrera tjänsterna i tjänsteplattformen [Ref 1].
Adresser till Tjänsteplattformen:
Miljö | Hostnamn | IP-adress | port | contextpath |
---|---|---|---|---|
QA-Sjunet | qa.esb.ntjp.sjunet.org | 82.136.149.53 | 443 | /vp |
Produktion-Sjunet | esb.ntjp.sjunet.org | 82.136.149.61 | 443 | /vp |
*Tjänsteplattformen kan användas om någon av tjänsterna Spärr, Samtycke och Logg har installerats.
5. Systemöversikt
Detta kapitel beskriver hur systemet sätts upp med maskiner och nätverksstruktur.
5.1. Ingående servrar
Lokala Säkerhetstjänster kan bestå av en eller flera applikationsservrar, en MySQL databasserver och en MongoDB databasserver beroende på vilka tjänster som ska installeras. Databasservrarna kan/bör även sättas upp på flera maskiner i ett kluster med någon typ av 'fail-over' lösning. På applikationsservern installeras en gemensam plattform. På plattformen kan man välja vilka av de fristående tjänsterna Spärr, Samtycke, Autentisering (IdP) och Logg som ska installeras.
Lokala Säkerhetstjänster kan konfigureras på två grundläggande sätt, med en nod eller flera noder i ett kluster. Vår rekommendation är att installera i ett kluster med två maskiner men flera går också bra. Säkerhetstjänsterna installerat i ett kluster ger en typ av active-active 'fail-over' då det ökar tillgängligheten och kapaciteten på systemet. För att kunna köra i ett kluster av noder krävs att alla noder har tillgång till en delad diskyta.
En lastbalanserare används för att dirigera trafiken till alla applikationsservrar (genom t.ex. round-robin). SSL-sessioner delas mellan applikationsservrarna, lastbalansering kan därför ske till vilken nod som helst. Om fel uppstår på någon av applikationsservrarna dirigeras trafiken bort från den felaktiga servern till de övriga applikationsservrarna. Alla maskiner i klustret bör vara identiska.
För hanteringen med att dela SSL-sessioner och andra objekt mellan applikationsservrarna är produkten Infinispan integrererat i systemet. Infinispan är en distribuerad cache-lösning som Säkerhetstjänsten använder för att kunna dela data mellan noderna. Det är konfigurerat att kommunicera med UDP och multicast eller TCP för att hitta alla noder i ett kluster.
Singelnodlösningen består av en applikationsserver, en MySQL databasserver och eventuellt en MongoDB databasserver, upp till totalt tre stycken maskiner.
För en installation av ett kluster tillkommer alltså ytterligare maskiner.
Figuren nedan visar ett exempel på en klustrad lösning.
Figur: Systemöversikt av Säkerhetstjänster installerat med en kluster lösning.
5.2. Exempelinstallation och konfiguration
5.2.1. Lokala Säkerhetstjänster installerade med Spärr och Autentisering
Bilden nedan visar en installation av lokal Spärrtjänst och Autentiseringstjänst. Spärreplikeringen till den nationella Spärrtjänsten sker via tjänsteplattformen, även Spärrtjänstens PDL-loggning går via tjänsteplattformen till den nationella Loggtjänsten. Detta kräver att den lokala Spärrtjänsten registreras som en konsument i tjänsteplattformen. Logguppföljning på händelser i den lokala Spärrtjänsten, måste i detta fall göras i den nationella Loggtjänsten. För att slå upp namn på patienter, använder Spärrtjänsten Personuppgiftstjänsten. HSA och Revokeringskontroll används av alla tjänster i lokala Säkerhetstjänster.
Figur: Lokala Säkerhetstjänster med Spärr och Autentisering installerade.
5.2.2. Lokala Säkerhetstjänster installerade med alla tjänster
Bilden nedan visar en installation där samtliga tjänster (Spärr, Samtycke, Logg och Autentisering) finns installerade lokalt. Spärreplikeringen till den nationella Spärrtjänsten sker via tjänsteplattformen, vilket kräver att den lokala Spärrtjänsten finns registrerad som konsument i tjänsteplattformen. Samtycke behöver registreras i tjänsteplattformen som producenter för att nationella system, t.ex. NPÖ, ska kunna registrera samtycken i rätt tjänst (via tjänsteplattformen).
Spärr, Samtycke och PDL-loggar till den lokala Loggtjänsten. Den lokala Loggtjänsten hämtar även hem de PDL-loggar som finns i den nationella Loggtjänsten via dess hämtningstjänst. För att slå upp namn på patienter används Personuppgiftstjänsten. HSA och Revokeringskontroll används av samtliga tjänster.
Figur: Lokala Säkerhetstjänster med alla tjänster installerade.
5.3. Översikt adresser och portar
Säkerhetstjänster är uppdelat i flera olika tjänster/delar. I tidigare versioner av Säkerhetstjänster har man anslutit till dessa tjänster via en och samma ip-adress med unika portnummer som identifierade tjänsterna (vi kallar i detta dokument denna konfiguration för 8443 ports). Från version 2.7 av den Lokala Säkerhetstjänsten kan man även använda SSL standardport 443 för samtliga tjänster men då krävs det att varje tjänst tilldelas en egen ip-adress (vi kallar i detta dokument denna konfiguration för 443 ports). För att kunna använda standardport 443 för alla tjänster måste dessa ip-adresser mappas i lastbalanseraren mot applikationsserverns interna portar som fortfarande måste vara unika för tjänsterna. Skillnaderna beskrivs av tabellen nedan. De interna portarna i tabellen avser föreslagen port men konfigureras manuellt vid installation. Dessa ska vid 443-port-konfiguration inte öppnas för extern åtkomst utan enbart vara åtkomlig från lastbalanseraren.
Det är alltså möjligt att konfigurera Säkerhetstjänster på båda dessa sätt och det är viktigt att vid installationen tänka på att ange samma port för interna och publika portar om man vill konfigurera med 8443-ports och port 443 som publika portar om man vill konfigurera med SSL Standard port 443.
SSL Standartport 443
Tänk också på att om man väljer en konfiguration med standardport 443 för alla tjänster och därmed flera olika URL:er så krävs det ett unikt certifikat per URL eller ett wildcard certifikat.
Tänk också på att för IdP-adresserna så måste secure.idp-adressen vara en underdomän till idp-adressen.
Publik adress (443 ports) | Publik adress (8443 ports) | Intern adress (internal ports) |
---|---|---|
https://ws.<Hostnamn-Applikationsserver>:443 | https://<Hostnamn-Applikationsserver>:8080 | https://<Hostnamn-Applikationsserver>:8080 |
https://secure.idp.<Hostnamn-Applikationsserver>:443 | https://<Hostnamn-Applikationsserver>:8444 | https://<Hostnamn-Applikationsserver>:8444 |
https://idp.<Hostnamn-Applikationsserver>:443 | https://<Hostnamn-Applikationsserver>:8445 | https://<Hostnamn-Applikationsserver>:8445 |
https://cd.<Hostnamn-Applikationsserver>:443 | https://<Hostnamn-Applikationsserver>:8446 | https://<Hostnamn-Applikationsserver>:8446 |
https://<Hostnamn-Applikationsserver>:443 | https://<Hostnamn-Applikationsserver>:8443 | https://<Hostnamn-Applikationsserver>:8443 |
5.3.1. Applikationsserver
Denna tabell visar vilka portöppningar som krävs för att lokala Säkerhetstjänster skall fungera. Portar i tabellen avser föreslagen port, men dessa konfigureras manuellt vid installation. In betyder inkommande trafik och Ut utgående trafik.
Server | Port | Beskrivning |
---|---|---|
Applikationsserver | 8443 (in) | HTTPS (envägs-SSL, generellt administrationsgränssnitt). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration. |
8444 (in) | HTTPS (tvåvägs-SSL, IdP-webbgränssnitt för identifiera användare med certifikat t.ex. SITHS). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration. *Används endast vid installation av lokal IdP | |
8445 (in) | HTTPS (envägs-SSL, IdP-webbgränssnitt med bla.val av identifikationsmetod och SSO). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration. *Används endast vid installation av lokal IdP | |
8446 (in) | HTTPS (envägs-SSL, IdP-webbgränssnitt för CDC-hantering). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration. | |
8080 (in) | HTTPS (tvåvägs-SSL, WebServices, t.ex.CheckBlocks). Ska ej öppnas för extern åtkomst vid 443 port-konfiguration. | |
8004 (in) | Java JMX-övervakning, behöver ej öppnas om inte övervakning används. Ska ej öppnas för extern åtkomst. | |
1111 (in) | Telnet-port för systemkonsol. Ska ej öppnas för extern åtkomst. | |
443 (in) | HTTPS för samtliga externa tjänster vid 443 port-konfiguration. Ska ej öppnas för extern åtkomst vid 8443 ports-konfiguration. | |
443 (ut) | HTTPS-anrop till HSA, Personuppgiftstjänsten, replikering till nationell hämtningstjänst för loggar samt intern kommunikation med lastbalanseraren för routing. | |
80 (ut) | Porten används av systemet för slagningar mot OCSP- och CRL-kontroll för verifiering av certifikat på exempelvis SITHS-certifikat. Använder man andra certifikat än SITHS kan andra portar vara aktuella för OCSP/CRL. | |
3306 (ut) | Anrop till MySQL-databasservern. | |
27017 (ut) | Anrop till MongoDB-databasservern | |
443 (ut) | Anrop till tjänsteplattformen |
5.3.2. Databasserver
Databasserver | Port | Beskrivning |
---|---|---|
MySQL | 3306 (in) | Anslutningsport till MySQL-databas. Används av applikationsservern. Ska ej öppnas för extern åtkomst utan enbart vara åtkomlig ifrån applikationsservrarna. |
MongoDB | 27017 (in/ut) | Anslutningsport till MongoDB-Används av applikationsservern, samt i MongoDB Replica set. Ska ej öppnas för extern åtkomst utan enbart vara åtkomlig ifrån applikationsservrarna samt de andra MongoDB-noderna. |
MongoDB (Arbiter) | 30000 (in/ut) | Används av arbiters i Replica set. Ska ej öppnas för extern åtkomst utan endast vara öppen internt för de andra MongoDB-noderna. |
5.4. Adressöversikt gränssnitt
Tabellen nedan visar adresser/URL:er till de webbgränssnitt som Säkerhetstjänsterna erbjuder och som kan användas av användare av den lokala Säkerhetstjänsten. Se respektive tjänstekontraktsbeskrivning för detaljerad beskrivning av tjänsterna och dess användning. Spärr, Samtycke och Logg är RIV TA 2.1 tjänster, se vidare http://www.rivta.se.
5.4.1. Webbgränssnitt admin-GUI
Prefix (443 ports) | Prefix (8443 ports) | Adress | Beskrivning |
---|---|---|---|
https://<Hostnamn-Applikationsserver>/ | https://<Hostnamn-Applikationsserver>:8443/ | block | GUI för Spärr |
commonarchive | GUI för Arkivering | ||
consentpdl | GUI för Samtycke | ||
idpadmin statistics | GUI för Autentisering | ||
javamelody systemlog job | GUI för Övervakning | ||
logreportarchive | GUI för Arkivsökning | ||
logreport | GUI för Loggrapport | ||
logstatusservice | GUI för Logg | ||
spinfo | GUI för Hjälp | ||
sysadmin | GUI för Administration | ||
general | GUI för felmeddelanden |
5.4.2. Webbgränssnitt Autentiseringstjänsten
Prefix (443 ports) | Prefix (8443 ports) | Adress | Beskrivning |
---|---|---|---|
https://idp.<Hostnamn-Applikationsserver>/ | https://<Hostnamn-Applikationsserver>:8445/ | idp/saml/sso/{binding} | Autentiseringstjänst (IdP) SSO |
idp/saml/slo/{binding} | Autentiseringstjänst (IdP) SLO | ||
idp/saml | Metadata IdP |
5.4.3. Webbtjänstegränssnitt för autentisering rika klienter - STS
Prefix (443 ports) | Prefix (8443 ports) | Adress | Beskrivning |
---|---|---|---|
https://ws.<Hostnamn-Applikationsserver>/ | https://<Hostnamn-Applikationsserver>:8080/ | ws/idp/sts | Autentiseringstjänst (STS) 2 vägs-SSL |
https://idp.<Hostnamn-Applikationsserver>/ | https://<Hostnamn-Applikationsserver>:8445/ | ws/idp/sts | Autentiseringstjänst (STS) 1 vägs-SSL (meddelandesignering) |
5.4.4. Webbtjänstegränssnitt WS-port - RIV TA-tjänster och REST-tjänst
Alla adresser för webbtjänstegränssnitt har följande prefix:
Prefix (443 ports) | Prefix (8443 ports) |
---|---|
https://ws.<Hostnamn-Applikationsserver>/ | https://<Hostnamn-Applikationsserver>:8080/ |
Spärr version 2.0 RIV TA 2.1 |
---|
blockingLocalService/DeleteExtendedBlock/2/rivtabp21 |
blockingLocalService/CancelTemporaryExtendedRevoke/2/rivtabp21 |
blockingLocalService/RegisterTemporaryExtendedRevoke/2/rivtabp21 |
blockingLocalService/RevokeExtendedBlock/2/rivtabp21 |
blockingLocalService/RegisterExtendedBlock/2/rivtabp21 |
blockingLocalService/GetExtendedBlocksForPatient/2/rivtabp21 |
blockingLocalService/GetPatientIds/2/rivtabp21 |
blockingLocalService/GetAllBlocks/2/rivtabp21 |
blockingLocalService/GetAllBlocksForPatient/2/rivtabp21 |
blockingLocalService/GetBlocksForPatient/2/rivtabp21 |
blockingLocalService/GetBlocks/2/rivtabp21 |
blockingLocalService/CheckBlocks/2/rivtabp21 |
blockingLocalService/PingForConfiguration/2/rivtabp21 |
Spärr version 3.0 RIV TA 2.1 |
---|
blockingLocalService/CheckBlocks/3/rivtabp21 |
blockingLocalService3/PingForConfiguration/1/rivtabp21 |
Spärr version 4.0 RIV TA 2.1 |
---|
blockingLocalService/PingForConfiguration/4/rivtabp21 |
blockingLocalService/DeleteExtendedBlock/4/rivtabp21 |
blockingLocalService/CancelTemporaryExtendedRevoke/4/rivtabp21 |
blockingLocalService/RegisterTemporaryExtendedRevoke/4/rivtabp21 |
blockingLocalService/RevokeExtendedBlock/4/rivtabp21 |
blockingLocalService/RegisterExtendedBlock/4/rivtabp21 |
blockingLocalService/GetExtendedBlocksForPatient/4/rivtabp21 |
blockingLocalService/GetPatientIds/4/rivtabp21 |
blockingLocalService/GetBlocks/4/rivtabp21 |
blockingLocalService/CheckBlocks/4/rivtabp21 |
Samtycke version 1.0 RIV TA 2.1 |
---|
consentService/PingForConfiguration/1/rivtabp21 |
consentService/GetConsentsForCareProvider/1/rivtabp21 |
consentService/GetConsentsForPatient/1/rivtabp21 |
consentService/DeleteExtendedConsent/1/rivtabp21 |
consentService/CancelExtendedConsent/1/rivtabp21 |
consentService/RegisterExtendedConsent/1/rivtabp21 |
consentService/GetExtendedConsentsForPatient/1/rivtabp21 |
consentService/CheckConsent/1/rivtabp21 |
Samtycke version 2.0 RIV TA 2.1 |
---|
consentService/PingForConfiguration/2/rivtabp21 |
consentService/CheckConsent/2/rivtabp21 |
consentService/DeleteExtendedConsent/2/rivtabp21 |
consentService/CancelExtendedConsent/2/rivtabp21 |
consentService/RegisterExtendedConsent/2/rivtabp21 |
consentService/GetExtendedConsentsForPatient/2/rivtabp21 |
consentService/GetConsentsForCareProvider/2/rivtabp21 |
consentService/GetConsentsForPatient/2/rivtabp21 |
Logg version 1 RIV TA 2.1 |
---|
logService/PingForConfiguration/1/rivtabp21 |
logService/StoreLog/1/rivtabp21 |
logQueryingService/PingForConfiguration/1/rivtabp21 |
logQueryingService/GetInfoLogsForPatient/1/rivtabp21 |
logQueryingService/GetInfoLogsForCareProvider/1/rivtabp21 |
logQueryingService/GetAccessLogsForPatient/1/rivtabp21 |
logQueryingService/GetLogsForPatient/1/rivtabp21 |
logQueryingService/GetLogsForUser/1/rivtabp21 |
logQueryingService/GetLogsForCareProvider/1/rivtabp21 |
logReportServiceInternal/IsMaintenanceOngoingInternal/1/rivtabp21 |
logReportServiceInternal/GetLogReportsInfo/1/rivtabp21 |
logReportServiceInternal/GetAggregatedLogsForPatientInternal/1/rivtabp21 |
logReportServiceInternal/GetAggregatedLogsForUserInternal/1/rivtabp21 |
logReportServiceInternal/GetAggregatedLogsForCareProviderInternal/1/rivtabp21 |
logReportServiceInternal/GetLogsInternal/1/rivtabp21 |
logReportServiceInternal/GetLogProducersByCareProviderInternal/1/rivtabp21 |
Logg version 2 RIV TA 2.1 |
---|
logService/PingForConfiguration/2/rivtabp21 |
logService/StoreLog/2/rivtabp21 |
logReportService/PingForConfiguration/2/rivtabp21 |
logReportService/GetLogs/2/rivtabp21 |
logReportService/GetInfoLogs/2/rivtabp21 |
logReportService/GetAccessLogsForPatient/2/rivtabp21 |
CommissionService version 1 RIV TA 2.1 |
---|
commissionService/GetCommissionsForPerson/1/rivtabp21 |
commissionService/SetSelectedCommissionForPerson/1/rivtabp21 |
commissionService/PingForConfiguration/1/rivtabp21 |
Adress till REST-tjänst för att söka och ladda ner loggarkiv från Säkerhetstjänster (hämtningstjänst).
Loggarkiv hämtningstjänst |
---|
logdownload_v2/archives |
Dokumentet Hämta loggarkiv 2.0 är en bilaga till tjänstekontraktet för logg. Det beskriver REST-tjänsten och hur hämta arkiv fungerar med parametrar osv.
6. Installation av databasserver
6.1. Installera MySQL
OBS: Som tidigare nämnts så rekommenderas det att installera den senaste versionen av 5.6-serien (5.6.37).
MySQL har officiella installationsanvisningar här:
http://dev.mysql.com/doc/refman/5.6/en/installing.html
För utökad support och funktionalitet såsom online-backup finns samma version i Enterprise Edition-utförande som dock inte är kostnadsfri. Mer information om detta finns här: http://www.mysql.com/products/enterprise. Rekommenderbart är att nyttja en High Availability lösning.
Mer information om detta finns här: https://dev.mysql.com/doc/refman/5.6/en/ha-overview.html
Den MySQL-användare som används vid installationen kräver behörighet att ändra, uppdatera och lägga till nya tabeller i de scheman som skapas för systemet.
6.1.1. Specifika MySQL-inställningar
6.1.1.1. Teckenuppsättning
Default-installation av MySQL använder teckenuppsättningen latin1. Detta måste ändras till UTF-8 för att svenska tecken ska användas korrekt. I katalogen <Lokal_sakerhetstjanst>\db\example\ finns ett exempel på en MySQL-konfigurationsfil (anpassad för Linux) där teckenuppsättningen är ändrad till UTF-8, och även lite generella inställningar man kan använda för att få upp prestandan på MySQL. Dessa generella Inställningar kan man även lägga in i konfigurationsfilen för Windows (observera att det inte finns någon exempel-fil för Windows). Nedan visas dessa inställningar som behöver ändras i filen my.cnf i Linux-installationen och i filen my.ini i Windows.
Vi hänvisar till konfigurationsfilen för MySQL i exemplen nedan, för både Linux och Windows, då både Windows och Linux anvisningarna delar på denna information.
Exempel Linux: /etc/my.cnf
Exempel Windows: C:\ProgramData\MySQL\MySQL Server 5.6\my.ini
Observera: Att man måste aktivera valet "Show hidden files, folders, and drives" under Folder options för att kunna se katalogen C:\ProgramData
# Set default character sets to use UTF-8 init_connect='SET collation_connection = utf8_general_ci; SET NAMES utf8;' character-set-server=utf8 character-set-client=utf8 collation-server=utf8_general_ci skip-character-set-client-handshake
6.1.1.2. Minnestilldelning "innodb_buffer_pool_size"
För att minska diskaccess bör denna sättas upp till 4-8 GB RAM-tillgång. Upp till 80% av maskinens minnesstorlek på en dedikerad databasmaskin säger MySQL-dokumentationen.
Sätts i konfigurationsfilen (my.cnf på Linux och my.ini på Windows)
# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes...
innodb_buffer_pool_size = 6G
6.1.1.3. Binary logging "binlog_format"
Sätts till ROW för Säkerhetstjänster.
Sätts i konfigurationsfilen (my.cnf på Linux och my.ini på Windows)
# binary logging format
binlog_format=ROW
6.1.1.4. InnoDB Tablespace "innodb_file_per_table"
Default för senare versioner av MySQL (från 5.6.x) är att tabeller och index skrivs till en fil per schema istället för en enda stor fil.
För detta i tidigare versioner av MySQL, lägg till följande bland övriga innodb-parametrar i konfigurationsfilen (my.cnf på Linux och my.ini på Windows)
# Use one file per table
innodb_file_per_table
OBS! Har man ett befintligt system utan denna parameter kan man inte bara ändra utan att först dumpa ut all data och sedan läsa in den igen efter att detta ändrats (beskrivs inte i detta dokument). Denna inställning är dock inte tvingande så man kan i detta läge fortsätta utan denna inställning.
6.1.2. Skapa användare som applikationsservern ska använda
Skapa en användare i MySQL som har behörighet att ändra, uppdatera och lägga till nya tabeller i de scheman som skapas för systemet.
Det behövs två användare:
# sak@localhost : användaren sak kan enbart ansluta från ”localhost”.
# sak@% : användaren sak kan ansluta från ”any hosts”
Användarna behöver inte ha behörighet för att kunna skapa nya scheman.
OBS! För att skapa scheman krävs en användare som har root-rättigheter, vilket skapades upp under installationen av MySQL.
Starta ett terminal-fönster mot databasservern och skriv följande kommando:
mysql -u root -p
Ange det lösenord som angavs vid installationen.
Skapa ny användare (i detta exempel är användarnamnet sak vilket rekommenderas, samt ett lösenord) genom att skriva följande tre kommandon:
CREATE USER 'sak'@'localhost' IDENTIFIED BY 'password'; GRANT CREATE, DROP, EVENT, DELETE, INDEX, INSERT, SELECT, UPDATE, CREATE TEMPORARY TABLES, LOCK TABLES, TRIGGER, CREATE VIEW, SHOW VIEW, EXECUTE ON *.* TO 'sak'@'localhost'; FLUSH PRIVILEGES;
Skapa ny användare (i detta exempel är användarnamnet sak vilket rekommenderas, samt ett lösenord) genom att skriva följande tre kommandon:
CREATE USER 'sak'@'%' IDENTIFIED BY 'password'; GRANT CREATE, DROP, EVENT, DELETE, INDEX, INSERT, SELECT, UPDATE, CREATE TEMPORARY TABLES, LOCK TABLES, TRIGGER, CREATE VIEW, SHOW VIEW, EXECUTE ON *.* TO 'sak'@'%'; FLUSH PRIVILEGES;
Avsluta MySQL prompten med kommando:
quit
6.1.3. Skapa upp databasscheman
När databasanvändare har skapats, ska databasscheman som lokala Säkerhetstjänster använder skapas upp. I installationspaketet (under strukturen <Lokal_sakerhetstjanst>\db\mysql\) ligger samtliga databasscheman som behöver sättas upp.
Tabellen nedan visar vilka skript som tillhör de databasscheman som kommer sättas upp i nästkommande steg.
Schema | Skript |
---|---|
accesscontrol | accesscontrol.sql accesscontrol_data.sql |
audit | audit.sql |
blkloc | blkloc.sql |
commission | commission_service.sql |
consent | consent.sql |
idp | idp.sql idp_data.sql |
inftyp | inftyp.sql inftyp_data.sql |
job | quartz.sql |
logdb | logdb.sql |
logreport | logreport.sql logreport_data.sql |
logreportarchive | logreportarchive.sql logreportarchive_data.sql |
logdlarchive | logdlarchive.sql |
metadata | metadata.sql |
sinkdb1 | sinkdb1.sql |
sp | sp.sql sp_data.sql |
Skapa upp databaserna:
- För över samtliga komponenter som finns i katalogen <Lokal_sakerhetstjanst>\db\mysql\ till en tmp katalog på er MySQL-server.
Öppna ett kommandofönster (cmd.exe - Command prompt).
Gå till katalogen dit filerna kopierats.
Exempel: cd c:\tmp\mysql
Lista innehållet i katalogen. Utöver de sql-skript som listas i tabellen, finns skript-filen create_databases_windows.bat.
Editera create_databases_windows.bat scriptet och ändra sökväg om ni installerat mysql i en annan katalog.
Exempel: set mysql="C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql.exe"
- Skript-filen create_databases_windows.bat ska köras med följande parametrar:
- Målmiljö - Den databasserver som skall användas.
- Användarnamn – det användarnamn som används till databasmiljön med root-rättigheter.
- Prefix – ej obligatoriskt. Ett prefix till tabellnamnet, kan anges om så önskas. I exempelbilden nedan har vi angivit ”exemple_” som prefix.
- Om prefix anges kommer namnet på databaserna att få följande utseende som exempel:
example_accesskontrol
example_audit
osv...
- Om prefix anges kommer namnet på databaserna att få följande utseende som exempel:
Exempel: create_databases_windows.bat localhost root example_
När skriptet körs kommer en fråga om ni vill fortsätta att skapa upp databaserna. Ange ”y” för att fortsätta med exekveringen.
OBS! Alla databaser kommer att tas bort och skapas igen så all befintlig data kommer att raderas.
Exempel:Exempel: C:\temp\mysql>create_databases_windows.bat localhost root example_ "C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql.exe" "C:\Program Files\MySQL\MySQL Server 5.6\bin\mysql_config_editor" Create MySQL databases for Lokala Sakerhetstjansten. *NOTE* that by running this script all tables will be recreated and all existing data will be lost!!! DO YOU WANT TO CONTINUE?(y/n)y Enter password: ****** Do you really want to recreate these databases: Creating schema "example_accesscontrol"... ...drop and recreate schema example_accesscontrol successful ...reading accesscontrol.sql successful ...database "example_accesscontrol" created Creating schema "example_audit"... ...drop and recreate schema example_audit successful ...reading audit.sql successful ...database "example_audit" created osv... osv... osv... Creating schema "example_sp"... ...drop and recreate schema example_sp successful ...reading sp.sql successful ...reading sp_data.sql successful ...database "example_sp" created DONE C:\temp\mysql>
Om inget fel uppstod kommer meddelandet DONE att skrivas ut. Verifiera att databaserna har skapats genom att logga in i mysql-prompten och exekvera följande:
Exempel: c:\tmp\mysql>"c:\Program Files\MySQL\MySQL Server 5.6\bin\mysql.exe" -uroot -p mysql> show databases;
För att kontrollera om det finns tabeller i ett schema (t.ex. accesscontrol;) ange kommandot:
Exempel: mysql> use accesscontrol; mysql> show tables; +-----------------------------+ | Tables_in_accesscontrol | +-----------------------------+ | action_resource | | action_resource__attributes | | attribute | | data_template | +-----------------------------+ 3 rows in set (0.00 sec)
Lista tabeller
6.2. Installationsanvisningar för MongoDB
Här följer ett exempel på installation av databasen MongoDB för Säkerhetstjänster. MongoDB kan laddas ner som ett MSI-paket.
MongoDB har officiella installationsanvisningar här: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-windows/
6.2.1. Installera MongoDB på en eller tre noder
Nedan följer installationsexempel för MongoDB med replikering samt singelnod. I det första fallet innebär det att installationen kommer att använda tre noder kallade Primary, Secondary och Arbiter. Att installera MongoDB på tre noder har två syften:
- Prestanda
- Tillgänglighet
I konfigurationen som följer efter installationen utser man vilka noder som ska ingå i uppsättningen. Vilka noder som ska vara datanoder och vilken av dessa som data ska läsas ifrån. Noden som har rollen Primary är den nod som data skrivs till. Arbitern bedömer vilken av noderna som ska fungera som Primary och vilken/vilka som ska fungera som Secondary.
Arbitern kan med fördel installeras på applikationsservern. Säkerhetstjänster kommer att begära att få läsa ifrån en Secondary-nod. Detta ökar prestandan avsevärt under hanteringen av verksamhetsloggar, då en nod hanterar alla inkommande loggar och läsning kan ske från en annan nod. Med rollen som ”domare” kan Arbitern sedan bestämma om noderna Primary och Secondary ska byta roller vid detekterade problem.
Det går även att sätta upp installationen på en nod, en så kallad singlenodinstallation, men av prestanda- och redundansskäl rekommenderar vi att ovan beskriven trenodsinstallation används.
MongoDB 3.4 kan laddas ner från https://www.mongodb.com/download-center#community
För en installation med replikering ska installationen uföras på samtliga datanoder och Arbiter-noden. Singelnodinstallationen installeras på samma sätt men konfigurationen skiljer sig något mellan nodtyperna.
6.2.1.1. Installation
- Hämta MongoDB för Windows.
- Kopiera msi-paketet till valfri katalog på alla datanoder samt arbiternoden.
- Skapa en datakatalog för MongoDB (alla noder), exempelvis: C:\mongodb\data
- Skapa en katalog för MongoDBs loggfil (alla noder), exempelvis: C:\mongodb\log
- Skapa en nyckelfils katalog för autentisering (gäller enbart i ett replicaset och görs på alla noder), exempelvis: C:\mongodb\keys
- Skapa en konfigurationsfil genom att först skapa ett temporärt text-dokument med namnet mongod_.cfg i C:\mongodb\
- Skapa en cfg-fil. Öppna txt-filen mongod_.cfg och välj därefter att spara ned den tom i mappen C:\mongodb\
- Välj "save as" i menyn file. Välj sedan "save as type" och "all" med filnamnet mongod.cfg
(högerklicka sedan på filen och verifiera i properties att filen nu är en cfg-fil. Den temporära txtfilen mongod_.cfg kan tas bort) - Editera sedan filen och lägg till dom värden som visas nedan och spara följande information i C:\mongodb\mongod.cfg
Kopiera mongod.cfg filen till övriga noder.
Obs! I en singelnodinstallation utelämnar man parametrarna security och keyFile samt replication och replSetName. Exemplet nedan gäller för ett replikaset i ett flernodssystem.systemLog: destination: file logAppend: false path: C:\mongodb\mongod.log # Where and how to store data. storage: dbPath: C:\mongodb\data journal: enabled: true # network interfaces net: port: 27017 # Replicaset security: keyFile: C:\mongodb\keys\keyfile replication: replSetName: rs_sak
Kontrollera att sökvägarna är korrekta för ert system.
- Lägg till sökvägen C:\Program Files\MongoDB\Server\3.4\bin i Windows PATH-variabel (kontrollera att sökvägen är korrekt för ert system).
Starta en kommandoprompt och installera MongoDB som en service genom att exekvera kommandot:
mongod --config C:\mongodb\mongod.cfg -install
6.2.1.2. Konfiguration av ett flernods-system med replikering:
I exemplet nedan använder vi två servrar för data, mongodb1.example.com och mongodb2.example.com, och en annan server som får agera Arbiter, mongodb0.example.com.
Starta nu MongoDB på datanoderna (ej Arbiter) genom att exekvera kommandot:
net start mongodb
Starta MongoDB-klienten via ett terminalfönster på noden (mongodb1.example.com) som ska vara Master och konfigurera replikeringen:
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("mongodb2.example.com")
Logga in på Arbiter-noden och konfigurera den genom att editera C:\mongodb\mongod.cfg:
Ändra portnummer:
port=30000Begränsa storleken på den lokala databasen opLog (endast på Arbiter):
oplogSize=1Starta nu MongoDB på Arbiter-noden:
net start mongodb
Gå tillbaka till Masternoden (Primary) och dess MongoDB-klient.
Lägg till Arbiter-noden genom att i MongoDB-klienten skriva:> rs.addArb("mongodb0.example.com:30000")
Nu ska rs.status() visa att replikering är konfigurerat med en primary, en secondary och en arbiter.
rs_sak:PRIMARY> rs.status() { "set" : "rs_sak", "date" : ISODate("2017-09-27T07:24:16Z"), "myState" : 1, "members" : [ { "_id" : 1, "name" : "mongodb1.example.com:27017", "health" : 1, "state" : 1, "stateStr" : "PRIMARY", "uptime" : 14426352, "optime" : Timestamp(1430115853, 1), "optimeDate" : ISODate("2017-09-27T06:24:13Z"), "self" : true }, { "_id" : 2, "name" : "mongodb0.example.com:30000", "health" : 1, "state" : 7, "stateStr" : "ARBITER", "uptime" : 6410836, "lastHeartbeat" : ISODate("2017-09-27T07:24:14Z"), "lastHeartbeatRecv" : ISODate("2017-09-27T07:24:15Z"), "pingMs" : 0 }, { "_id" : 3, "name" : "mongodb2.example.com:27017", "health" : 1, "state" : 2, "stateStr" : "SECONDARY", "uptime" : 6410834, "optime" : Timestamp(1430115853, 1), "optimeDate" : ISODate("2017-09-27T06:24:13Z"), "lastHeartbeat" : ISODate("2017-09-27T07:24:14Z"), "lastHeartbeatRecv" : ISODate("2017-09-27T07:24:15Z"), "pingMs" : 0, "syncingTo" : "mongodb2.example.com:27017" } ], "ok" : 1 } rs_sak:PRIMARY>
Exempel på rs.status()
Skapa ett Admin-konto i MongoDB-klienten:
> db = db.getSiblingDB("admin") > db.createUser({ user: "adminuser", pwd : "SECRETPASSWORD", 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 se MongoDBs egen dokumentation.
Generera en keyfile (som används för autentisering mellan noderna). Det rekommenderas att OpenSSL (http://www.openssl.org/) används för att skapa en keyfile med slumpmässig data:
cd C:\mongodb\keys\ openssl rand -base64 741 > keyfile
Aktivera autentisering och peka ut keyfile i alla noders konfigurationsfil. Editera filen C:\mongodb\mongod.cfg
Ta bort # (avkommentera) framför security och keyFile samt replication och replSetNameKopirera den nygenerade keyfile till övriga noder så att den ligger i mappen C:\mongodb\keys\keyfile
Starta nu om ARBITER-, SECONDARY- och slutligen PRIMARY-noden:
net stop mongodb net start mongodb
6.2.1.3. Konfiguration för singelnod-system
Starta nu MongoDB
net start mongodb
Starta MongoDB-klienten i kommandoprompten:
mongo
Nu ska MongoDB-klienten vara startad och en ny prompt vara synlig, i resten av instruktionen annoterad med >.
Skapa ett Admin-konto i MongoDB-klienten:
> db = db.getSiblingDB("admin") > db.createUser({ user: "adminuser", pwd : "SECRETPASSWORD", roles: [ "userAdminAnyDatabase", "readWriteAnyDatabase", "dbAdminAnyDatabase","clusterAdmin" ] } )
- Aktivera autentisering genom att editera filen C:\mongodb\mongod.cfg
Se konfigurationsexemplet för singelnod längre ned
Starta om MongoDB-servern
net stop mongodb net start mongodb
6.2.2. Skapa databaser, index och användare för Säkerhetstjänster
Med installationen medföljer ett konfigurationsskript för att skapa nödvändiga databaser, index och användare för Säkerhetstjänster. Skriptet ligger i installationskatalogen under <Lokal_sakerhetstjanst>\db\mongodb\ med namnet mongo_db_setup.bat.
För att kunna köra detta skript behöver MongoDB med klient, vara installerat enligt ovan.
Det måste finnas ett användarkonto med administratörsrättigheter.
I en replikerad miljö exekveras skriptet på noden som för tillfället är PRIMARY. Skriptet kräver användarnamn och lösenord för administratören. Användarnamn och lösenord för Säkerhetstjänster samt eventuellt ett prefix för tabellerna (collections) för den specifika installationen.
Med växeln -h fås mer information om användningen av skriptet.
mongo_db_setup.bat -h
Användning:
mongo_db_setup.bat <host> <admin-user> <admin-secretpassword> <sak-user> <sak-password> [prefix]
Exempel 1:
mongo_db_setup.bat <host> <admin-user> <admin-secretpassword> <sak-user> <sak-password>
- Skapar (om) collections med index men utan tabellprefix.
- Skapar databaser och sak-användare om dessa inte redan existerar.
Exempel 2:
mongo_db_setup.bat <host> <admin-user> <admin-secretpassword> <sak-user> <sak-password> proxy_
- Skapar (om) collections med index och tabellprefix proxy_
- Skapar databaser och sak-användare om de inte redan existerar.
Kontrollera att skriptet exekverar utan felmeddelanden och rapporterar "Done recreating databases!"
C:\temp>mongo_db_setup.bat localhost adminuser secretpassword sak password MongoDB shell version: 3.4.7 connecting to: test This script will drop (delete) and recreate data in databases PDLLOG, AUDITLOG and ARCHIVESEARCH. Are you sure that you would like to continue? [Y/N]:y MongoDB shell version: 3.4.7 connecting to: test Checking that we are on primary node... WE ARE ON PRIMARY NODE. OK! Logging in for admin rights... Dropping collection 'audit' in database 'auditlog' Creating user 'sak' for database 'auditlog' { "user" : "sak", ... } Creating indexes for collection 'audit' in database 'auditlog' Dropping collection 'log' in database 'pdllog' Creating user 'sak' for database 'pdllog' { "user" : "sak", ... } Creating indexes for collection 'log' in database 'pdllog' Dropping collection 'log' in database 'statistics' Creating user 'sak' for database 'statistics' { "user" : "sak", ... } Creating indexes for collection 'log' in database 'statistics' Dropping collection 'log' in database 'archivesearch' Creating user 'sak' for database 'archivesearch' { "user" : "sak", ... } DONE recreating databases! C:\temp>
6.2.3. Konfigurationsfil - Replikaset
Följande är ett exempel på hur en MongoDB-konfiguration kan se ut för datanoderna i ett replikeringskluster.
Denna fil skapar vi ovan i mappen: C:\mongodb\mongod.cfg
systemLog: destination: file logAppend: false path: C:\mongodb\mongod.log # Where and how to store data. storage: dbPath: C:\mongodb\data journal: enabled: true # network interfaces net: port: 27017 security: keyFile: C:\mongodb\keys\keyfile replication: replSetName: rs_sak
6.2.4. Konfigurationsfil - Singelnod
Följande är ett exempel på hur en MongoDB-konfiguration kan se ut för ett MongoDB-singelnod med autentisering aktiverad.
Denna fil skapar vi ovan i mappen: C:\mongodb\mongod.cfg
systemLog: destination: file logAppend: false path: C:\mongodb\mongod.log # Where and how to store data. storage: dbPath: C:\mongodb\data journal: enabled: true # network interfaces net: port: 27017 security: authorization: enabled
Notera att parametrarna replSetName och keyFile är specifika för en uppsättning med replikering i ett MongoDB-kluster.
Konfiguration | Parameter | Värde | Beskrivning |
---|---|---|---|
systemLog: | |||
destination: | file | Händelselogg skrivs till fil | |
logAppend: | true | Värdet satt till true säkerställer att mongod ej skriver över existerande logfil vid omstart. | |
path: | C:\mongodb\mongod.log | Sökväg där MongoDB sina egna händelseloggar. | |
storage: | |||
dbPath: | C:\mongodb\data | Sökväg til MongoDBs datakatalog. Det är detta diskutrymme som måste möta utrymmeskraven för MongoDB | |
journal: | true | Journaling säkerställer "singel-nods" skrivbarhet. 64-bit bygget av mongod har jornaling som default. | |
net: port: | 27017 | Portnummer som MongoDB-server lyssnar efter anslutningar på. För Arbiter-noden sätter vi denna till 30000 i vårt exempel. | |
security: | |||
keyFile: | C:\mongodb\keys\keyfile | Autentiseringsnyckel aktiverar autentiseringen i ett replikeringskluster. | |
replication: | |||
replSetName: | <none> | Använd för att konfigurera replikering i ett kluster av MongoDB-noder. Ange ett namn på "replikeringsuppsättningen". Observera att alla noder måste ha samma värde på detta namn. | |
För en komplett lista med beskrivningar över konfiguration av MongoDB gå till MongoDBs hemsida.
7. Installation av applikationsserver
Det är av prestandaskäl rekommenderat att tilldela lokala Säkerhetstjänsters applikationsserver en egen fysisk maskin.
7.1. Installera Java och JCE
Installera Java (jdk) och tillägget JCE Java Cryptography Extension, enligt avsnitt Java.
7.2. Installation av lokala Säkerhetstjänster
Innan installationen av lokala Säkerhetstjänster påbörjas, finns några operativspecifika uppgifter som måste utföras:
- Konfiguration av den lokala brandväggen på applikationsservern, se Appendix A - Exempel på konfiguration av den lokala brandväggen för windows servrarna.
- Delad diskyta för en fail-over lösning, se Appendix C - Krav på delad diskyta vid en fail-over installation
När databasserver och applikationsserver är förberedda, kan lokala Säkerhetstjänster installeras på applikationsservern.
Att installera lokala Säkerhetstjänster kan utföras på två sätt:
- Singleserver lösning utan fail-over.
- Fail-over lösning, som vi rekommenderar för en produktionsmiljö.
7.2.1. Val av installationstyp
Kopiera <Lokal_sakerhetstjanst> till valfri katalog på applikationsservern. Installationsprogrammet ligger under katalogen <Lokal_sakerhetstjanst>\install\.
7.2.2. Installation utan lokala Säkerhetstjänsters Autentiseringstjänst
Om inte den medföljande Autentiseringstjänsten ska användas så är det möjligt att konfigurera lokala Säkerhetstjänster att använda en annan IdP, detta hanteras då viametadata. Trots detta är det nödvändigt att ange något värde på konfigurationerna för IdP för att inte installationsskriptet ska falera i ett senare skede. Lämpligen kan man ange samma värden som för application host för certifikat och publik port men välja en annan intern port som är ledig och som inte är reserverad, t.ex 8444 och 8445.
Installation av SingelServer eller första noden i en fail-over lösning
Från version 2.15 av Säkerhetstjänster har installationsprogrammet förbättrats. Man installerar på samma sätt som tidigare, men varje konfigurationsavsnitt har ett eget fönster i installationsprogrammet.
Sedan kan man när som helst spara undan konfigurationen genom att klicka på save-knappen. Detta kan vara bra att veta om man av någon anledning behöver pausa installationen för att återuppta denna vid ett senare tillfälle utan att behöva mata in alla värden på nytt igen.
Installationen kommer att kopiera in de filer som behövs för applikationsservern, samt registrera en service ”Lokal Säkerhetstjänst <version>”.
Efter installationen är det rekommenderat att byta servicekonto, se Appendix B - Skapa separat servicekonto.
Exekvera SakerhetstjansterSetup.exe, under katalogstrukturen …<Lokal_sakerhetstjanst>\install\ .
Välkomstsidan visas. Klicka på knappen Next .Välj "installation first node" och klicka på knappen Next .
Tryck på Browse och välj vilken konfiguration-fil som ska användas. Det finns en katalog i installationspaketet som innehåller fördiefinerade konfigurationsfiler under följande struktur: <Lokal_sakerhetstjanst>\install\resource\target .
Välj beroende på typ av portkonfiguration, se beskrivning: Översikt adresser och portar.8443 port installation (local.default.8443.ports.win.target.properties) innebär att alla tjänster har samma adress men olika portar för varje tjänst (standard i Säkerhetstjänster < 2.7).
443 port installation (local.default.443.ports.win.target.properties) innebär att alla tjänster nås på samma port (443 som standard) med olika adresser för varje tjänst.
Observera att en konfiguration med samma port för alla tjänster (port 443) även kräver flera ip-adresser samt en korrekt konfigurerad lastbalanserare!
Tryck sedan på knappen Next .
Save knappen är till för att man i installationsflödet ska kunna spara undan en kopia av konfigurationerna. Denna properties fil kommer då att innehålla de värden som man har fyllt i under installationens gång. De värden man inte har fyllt i kommer att hämtas från den konfigurationsfil som man utgick ifrån.
Ange sökvägen till katalog där java JDK finns installerat (exkludera katalogen bin), vart Säkerhetstjänsten ska installeras, sökväg till Säkerhetstjänstens delade diskarea (som används av alla noder),
samt port för OSGI konsolen. I den delade diskarean läggs t.ex. konfigurationsfiler och binärer. Denna behöver i en Singleserver-installation ej vara delad.
Tryck sedan på knappen Next .
Parameter
Defaultvärde
Exempel
Beskrivning
Path to Java JDK
C:\Program Files\Java\jdk1.8.0_xx
Katalog där java JDK finns installerat. Exkludera katalogen bin.
Path to installation directory
C:\Program Files\Inera\Lokala Säkerhetstjänster 2.17
Katalog där Säkerhetstjänster ska installeras.
Path to shared disk space
--
C:\share
Katalog till Säkerhetstjänstens delade diskarea (som används av alla noder).
OSGI Consol Port
1111
1111
Port för OSGI konsolen
Fyll i fälten för Log archive shared path och Log store proxy address.
Tryck sedan på knappen Next .Parameter
Defaultvärde
Exempel
Beskrivning
Log archive shared path
<share>\xlog_archive
Sökväg till den delade area där komprimerade PDL-logg arkiv sparas. Kommer att användas om lokala Loggtjänsten installeras.
Log store proxy address
ws.sakerhetstjanst.example.com
Säkerhetstjänstens nationella publika adress.
Anges för att skicka PDL-loggar till nationella Loggtjänsten, när lokal loggtjänst inte installeras.
Fyll i fältet för Log Reports shared path.
Tryck sedan på knappen Next .
Parameter
Defaultvärde
Exempel
Beskrivning
Log Reports shared path
<share>\logreports
Sökväg till en delad filarea där färdiga rapporter sparas.
Fyll i fälten. De funktionscertifikat som ska användas beskrivs i avsnitt SITHS funktionscertifikat.
Systemets portar beskrivs i avsnitt Översikt adresser och portar.
Tryck sedan på knappen Next .
Parameter
Defaultvärde
Exempel
Beskrivning
Application Host address
--
8443: sakerhetstjanst.example.com
443: sakerhetstjanst.example.com
Säkerhetstjänstens publika adress.
Path to server PKCS#12 certificate
--
Sökvägen till där funktionscertifikatet för legitimering (certificate.p12-fil) för Säkerhetstjänsten är sparat.
Bör inte vara ett SITHS-certifikat.
Server PKCS#12 certificate password
--
Lösenord till ovan funktionscertifikat.
Application port (interna - server port)
8443
Https port för Säkerhetstjänstens Admin-GUI för intern åtkomst.
Application port (public - load balancer port)
8443 | 443
Https port för Säkerhetstjänstens Admin-GUI för extern åtkomst. Sätt värde 8443 för en 8443 port-installation och sätt värde 443 för en 443 port-installation. Se figurerna ovan.
Fyll i fälten. De funktionscertifikat som ska användas beskrivs i avsnitt SITHS funktionscertifikat.
Systemets portar beskrivs i avsnitt Översikt adresser och portar.
Tryck sedan på knappen Next .Parameter
Defaultvärde
Exempel
Beskrivning
Web Service host address
--
8080: sakerhetstjanst.example.com
443: ws.sakerhetstjanst.example.com
Adressen till Säkerhetstjänstens webbtjänster.
Path to WS PKCS#12 certificate
--
Sökväg till där man sparat funktionscertifikatet (certificate.p12-fil) för webbtjänsterna.
Bör vara ett SITHS-certifikat.
WS PKCS#12 certificate password
--
Lösenord till ovan funktionscertifikat
Web Service Port (internal - server port)
8080
Port som Säkerhetstjänstens webbtjänster kommer att publiceras på för intern åtkomst.
Web Service Port (public - server port)
8080 | 443
Port som Säkerhetstjänstens webbtjänster kommer att publiceras på för extern åtkomst. Sätt värde 8080 för en 8443 port-installation och sätt värde 443 för en 443 port-installation. Se figurerna ovan.
Välj typ av kommunikation mellan noderna. Se beskrivning i kapitel Kluster med Infinispan (Distributed in-memory cache) .
Vid UDP - Kontrollera att det andra fältet är en gilitg multicast-adress. (Tredje fältet används ej i detta läge)
Vid TCP - Ange i tredje fältet en kommaseparerad lista med alla noder och dess portnummer(inom hakparantes) som ska användas. (Andra fältet används ej i detta läge)
Tryck sedan på knappen Next .Parameter
Defaultvärde
Exempel
Beskrivning
Infinispan protocol - UDP or TCP
UDP
Protokoll för kommunikation mellan klusternoder.
Infinispan multicast address
239.0.10.1
Multicastadress för kommunikation mellan klusternoder när protokollet UDP är valt.
Infinispan cluster members
nod1.sakerhetstjanst.example.com[7800],nod2.sakerhetstjanst.example.com[7800]
Statisk kommaseparerad lista på klusternoder när protokollet TCP är valt med portnumret inom 'hakparantes' såsom i exemplet.
Fyll i fälten. De funktionscertifikat som ska användas beskrivs i avsnitt SITHS funktionscertifikat.
Systemets portar beskrivs i avsnitt Översikt adresser och portar.
Tryck sedan på knappen Next .Parameter
Defaultvärde
Exempel
Beskrivning
IdP host address
--
8445: sakerhetstjanst.example.com
443: idp.sakerhetstjanst.example.com
IdP tjänstens publika adress.
Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras, se Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst.Path to IdP PKCS#12
--
Sökväg till där man sparat funktionscertifikatet,legitimering, (certificate.p12-fil) för IdP tjänsten.
Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras, se Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst.Bör inte vara ett SITHS-certifikat.
IdP PKCS#12 password
--
Lösenord till ovan funktionscertifikat. Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras, se Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst.
IdP port (internal)
8445
Port som används av SSO-service internt. Observera att ett värde måste anges även om inte autentiseringstjänsten ska installeras, se Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst.
IdP port (public)
8445 | 443
Port som används av SSO-service externt. Sätt värde 8445 för en 8443 port-installation och sätt värde 443 för en 443 port-installation. Se figurerna ovan.
Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras, se Installation utan Lokala Säkerhetstjänsters autentiseringstjänst.Fyll i fälten. De funktionscertifikat som ska användas beskrivs i avsnitt SITHS funktionscertifikat.
Systemets portar beskrivs i avsnitt Översikt adresser och portar.
Tryck sedan på knappen Next .
Secure IdP host address
--
8444: sakerhetstjanst.example.com
443: secure.idp.sakerhetstjanst.example.com
Adress till IdP tjänsten som används för att identifiera/autentisera användare med SITHS-kort.
Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras, se Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst.Path to secure IdP PKCS#12
--
Sökväg till där funktionscertifikatet(legitimering) för IdP (certificate.p12-fil) för Säkerhetstjänsten är sparat.
Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras, se Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst.Bör inte vara ett SITHS-certifikat.
Secure IdP PKCS#12 password
--
Lösenord till ovan funktionscertifikat.
Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras, se Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst.Secure IdP port (internal)
8444
Port som används för att identifiera/autentisera användare med SITHS-kort internt.
Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras, se Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst.Secure IdP port (public)
8444 | 443
Port som används för att identifiera/autentisera användare med SITHS-kort externt. Sätt värde 8444 för en 8443 port-installation och sätt värde 443 för en 443 port-installation. Se figurerna ovan.
Observera att ett värde måste anges även om inte Autentiseringstjänsten ska installeras, se Installation utan Lokala Säkerhetstjänsters Autentiseringstjänst.Fyll i fälten. De funktionscertifikat som ska användas beskrivs i avsnitt SITHS funktionscertifikat.
Systemets portar beskrivs i avsnitt Översikt adresser och portar.
Tryck sedan på knappen Next .Parameter
Defaultvärde
Exempel
Beskrivning
Host address on Common Domain
--
8446: sakerhetstjanst.example.com
443: cd.sakerhetstjanst.example.com
Säkerhetstjänsten publika Common Domain adress.
(Om common domain inte används, dvs systemet ingår inte i en federation, ange "cd.sakerhetstjanst.example.com")
Path to common domain Identity PKCS#12
--
Sökväg till där funktionscertifikatet(legitimering) för common domain (cd-certificate.p12-fil) för Säkerhetstjänsten är sparat.
(Om common domain inte används, dvs systemet ingår inte i en federation, ange samma funktionscertifikat som ovan.)
Common domain PKCS#12 password
--
Lösenord till ovan funktionscertifikat.
Common domain Port (internal)
8446
Port som används för intern åtkomst till Common Domain.
Common domain Port (public)
8446 | 443
Port som används för extern åtkomst till Common Domain. Sätt värde 8446 för en 8443 port-installation och sätt värde 443 för en 443 port-installation. Se figurerna ovan.
Common domain adress
--
commondomain.sakerhetstjanst.example.com
Fyll i fälten. Se adresser som kan användas för test respektive produktion i avsnitt HSA-WS.
Tryck sedan på knappen Next .Parameter
Defaultvärde
Exempel
Beskrivning
Host address
example.com
Adress till HSA tjänsten.
Port
443
Port för HSA tjänsten.
Search base
c=SE
Sökbas för HSA.
Context path
/svr-hsaws2/hsaws
Context path för HSA.
Fyll i fälten. Tryck sedan på knappen Next .
Parameter
Defaultvärde
Exempel
Beskrivning
Host address
ntjp.example.com
Adress till Personuppgiftstjänsten.
Port
443
Port för Personuppgiftstjänsten.
Fyll i fälten. Tryck sedan på knappen Next .
Parameter
Defaultvärde
Exempel
Beskrivning
Host address
db.sakerhetstjanst.example.com
Adress till databas(MySQL)-servern.
Port
3306
Port till MySQL.
User name
sak
Den användare som Säkerhetstjänstens skall använda för att koppla upp sig mot databasen.
Password
Lösenord för databasanvändaren.
Database name prefix
example_
Namnen på databaserna kan ges ett prefix ifall så önskas. I annat fall lämnas detta fält tomt.
(Vill man ha ett underscore mellan prefix och namn så måste detta ingå).
Fyll i fälten. Tryck sedan på knappen Next .
Parameter
Defaultvärde
Exempel
Beskrivning
Address replica server 1
mongodb1.sakerhetstjanst.example.com
Adress till MongoDB Primary server.
Address replica server 2
mongodb2.sakerhetstjanst.example.com
Adress till MongoDB Secondary server.
(Vid singelnodinstallation ange samma adress som server 1).
Port
27017
Port för MongoDB.
Username
sak
Användare för MongoDB.
Password
Lösenord MongoDB.
Fyll i fälten. Tryck sedan på knappen Next .
Parameter
Defaultvärde
Exempel
Beskrivning
Database name PDL log
pdllog
MongoDB databas för PDL-loggar
Database name archive search
archivesearch
MongoDB databas för arkivsökning
Database name audit log
auditlog
MongoDB databas för systemloggar
Database name statistics log
statistics
MongoDB databas för autentiseringsstatistik
Collection name prefix
example_
I databaserna skapas Collections som kan ges ett prefix ifall så önskas. I annat fall lämnas detta fält tomt. (Vill man ha ett underscore mellan prefix och namn så måste detta anges)
Days to keep statistics data in database
92
Antal dagar som statistikloggarna sparas innan de automatiskt tas bort.
Days to keep audit logs in MongoDB
92
Antal dagar som auditloggarna sparas innan de automatiskt tas bort.
Klicka på knappen Next för att starta installationen.
Systemet installeras och meddelar användaren med en bekräftelsedialog hur installationen gick. Klicka på knappen Exit för att avsluta.
Klicka på knappen Done för att avsluta installationen. För uppstart av systemet, gå till avsnitt Uppstart av applikationsserver.
7.2.3. Installation på övriga noder (nod2, nod3 osv...) i en fail-over lösning
Denna installation görs på övriga noder och kommer att registrera en tjänst: ”Lokal Säkerhetstjänst<version>”.
Efter installationen är det rekommenderat att byta servicekonto, se Appendix B - Skapa separat servicekonto.
Exekvera SakerhetstjansterSetup.exe, under katalogstrukturen c:\share\<Lokal_sakerhetstjanst>\
Klicka på knappen Next.
Välj "Installation other nodes". Klicka på knappen Next.
Ange sökväg till konfigurationsfilen installation_inputs_<version>.properties som skapades vid installationen på den första noden och ligger på den delade diskytan. (ex. C:\share\Sakerhetstjanst<version>\installation_inputs_<version>.properties).
Klicka på knappen Next.
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 bild ovan.
Ändra till den symboliska länken, exempelvis: C:\share\installation_inputs_2.17.propertiesSystemet installeras och meddelar användaren med en bekräftelsedialog hur installationen gick.
Klicka på knappen Done för att avsluta installationen.
7.3. Installation Infinispan cluster cache över TCP
Har man valt TCP under installationen (Cluster cache setup -> Infinispan protocol - UDP or TCP) måste man nu manuellt ange nodens bind/IP-adress i en konfigurationsfil per nod. Ta reda på vilken IP-adress som gäller för noden på samtliga noder och ändra attributet bind_addr i XML-taggen TCP_NIO från 0.0.0.0 till nodens IP-adress på samtliga noder:
C:\Program Files\Inera\Lokal Sakerhetstjanster<version>\local\jgroups\jgroups-tcp.xml
Exempel: <TCP_NIO bind_port="7800" bind_addr="0.0.0.0" ... />
Kontrollera också, i samma fil, listan över i klustret ingående noder i attributet initial_hosts i XML-taggen TCPPING. Detta ska vara en kommaseparerad lista över klustrets alla noder med den port som ska användas inom 'hakparantes'.
Exempel: <TCPPING initial_hosts="nod1.sakerhetstjanst.example.com[7800],nod2.sakerhetstjanst.example.com[7800]" port_range="0"/>
Observera att attributet bind_addr i XML-taggen TCP_NIO kräver att man anger serverns riktiga IP-adress. Det fungerar inte om man exempelvis anger DNS-namn, 0.0.0.0 eller 127.0.0.1
Installation utan databasen MongoDB
NOTERA: MongoDB är ett krav för lokal loggtjänst. Följande konfiguration kommer att inaktivera insamlandet av statistik för autentiseringshändelser, tar bort MongoDB som reservkälla för loggning av systemhändelser, tar bort lokalt sparande av pdlloggar (för loggrapporter), samt lokalt sparande för arkivsök (för loggrapporter).
Öppna filen archivesearch.xml för editering i ett program lämpligt för xml. Ändra värdet på attributet med nyckelnamn enabled till false.
C:\share\Sakerhetstjanster<version>\local\config\com.logica.se.iac.db.mongo.service.connection.factory\archivesearch.xml
<Attribute key="false" type="Boolean">
Gör likadant med filen auditlog.xml
C:\share\Sakerhetstjanster<version>\local\config\com.logica.se.iac.db.mongo.service.connection.factory\auditlog.xml
<Attribute key="false" type="Boolean">
Gör likadant med filen pdllog.xml
C:\share\Sakerhetstjanster<version>\local\config\\com.logica.se.iac.db.mongo.service.connection.factory\pdllog.xml
<Attribute key="false" type="Boolean">
Gör likadant med filen statistics.xml
C:\share\Sakerhetstjanster<version>\local\config\com.logica.se.iac.db.mongo.service.connection.factory\statistics.xml
<Attribute key="false" type="Boolean">
8. Uppstart av applikationsserver
Innan uppstart av lokal Säkerhetstjänst som Windows-service bör man ha skapat ett servicekonto med korrekta rättigheter. Har man inte redan gjort det så följ guiden i Appendix B och återkom efter det till denna punkt.
NOTERA: Om installation av singelserver valdes, fortsätt till avsnitt Uppstart av lokal säkerhetstjänst på nod 1.
När man startar Säkerhetstjänster första gången efter installation måste man, på varje nod, installera de komponenter man har behov av. Det görs genom OSGi-konsolen som med standardkonfiguration nås genom telnet på port 1111.
Det finns en uppstartslogg <enhet\Program Files\Inera\Lokal Sakerhetstjanst<version>\local\log\outputlog_service.txt>. Där loggas det som sker under uppstarten av systemet.
En telnet-klient behövs under installationen för att koppla upp sig mot Säkerhetstjänsters OSGI-konsol där Säkerhetstjänster konfigureras.
8.1. Uppstart av lokal säkerhetstjänst på nod 1
För att starta systemet, gå in i verktyget Server Manager och Services och leta upp Lokala Säkerhetstjänsters tjänst (Lokal Säkerhetstjänst <version>). Starta servicen.
telnet localhost 1111
NOTERA: Det kan ta ca en minut innan servern har startat och att det går att logga in till systemkonsolen.
NOTERA: Om en annan port än defaultport 1111 har angivits i installationen, anger man denna istället.
NOTERA: Förändringar i OSGI-kommandon
osgi> package:pkglist (ersätter pkg list)
osgi> package:pkginstall (ersätter pkginstall)
Exempel: package:pkginstall -p 0 (installerar alla paket)
Exempel: package:pkgstart (startar igång alla installerade paket)
osgi> state (ersätter context state)
osgi> search (ersätter audit search)
Exempel: search -level error (söker i loggen efter alla error, error går att ersätta med warn, info)
Exempel: search -level error -time 10m (söker i loggen efter alla errors dom senaste 10 minuterna)
osgi> monitor (ersätter sys monitor)
Exempel: monitor -filter infinispan (monitorerar status för infinispan klustret)
osgi> spfilter -on (ersätter sys sp -on)
osgi> spfilter -off (ersätter sys sp -off)
osgi> acc -import file:///path/to/file (ersätter sys acc -import file:///path/to/file)
osgi> authz -on (ersätter sys authz -on)
osgi> authz -off (ersätter sys authz -off
osgi> plat:help (hjälp meny)
Verifiera i systemkonsolen att bundlarna för applikationsservern är uppstartade (ACTIVE), genom att exekvera kommandot: ss
Förklaring av fältet ”State” i ovan utskrift:
INSTALLED - Bundeln är installerad i systemet men är inte startad.
STARTED - Bundeln är startad men ännu inte aktiv.
ACTIVE - Bundeln är startad och aktiv.
RESOLVED - Bundeln är stoppad.Observera att bundlarna för applikationsservern installeras automatiskt under uppstart av tjänsten, se bild ovan.
Lista de komponenter som kan installeras med kommandot:
osgi> package:pkglist Id Name Description 0 All All available packages 1 Authorization Local Local Authorization Service 2 IdP Local Identity Provider 3 Block Local Local Block Service 4 Commission Commission Service 5 Consent Local Consent Service 6 Log Local Log Service 7 Log Proxy Local Log Proxy 8 Log Report Local Log Report Service 9 PU Proxy Local PU Proxy
Välj de komponenter som skall installeras:
- All - Alla tjänster
- Authorization Local - Lokal åtkomsttjänst.
- Idp Local - Lokal Autentiseringstjänst.
- Block Local - Lokal Spärrtjänst.
- Commission - Lokal Commission .
- Consent - Lokal Samtyckestjänst.
- Log - Lokal loggtjänst.
- Log Proxy - Lokal loggproxytjänst.
- Log Report - Lokal loggrapportstjänst.
- Pu Proxy - Lokal proxytjänst för personuppgifter
Det är möjligt att installera enbart en av tjänsterna, t.ex. Spärr. Dock kräver tjänsterna Spärr, Samtycke tillgång till en intern/extern autentiseringstjänst (IdP) för att en användare ska kunna logga in och komma åt webbtjänsterna.
Exempel:
För att installera alla tjänster (komponent 0 i exemplet ovan):osgi> package:pkginstall -p 0
För att installera endast IdP:
Exempel: osgi> package:pkginstall -p 1,2,4,9
För att installera lokal Spärrtjänst med IdP och logg:
Exempel: osgi> package:pkginstall -p 1,2,3,4,6,7,8,9
För att installera lokal Loggtjänst, Lograpport med IdP:
Exempel: osgi> package:pkginstall -p 1,2,4,6,7,8,9
Säkerställ att de paket-id som anges i exemplet ovan stämmer med de komponenter som skall installeras. Hämta aktuellt paket-id med kommandot: package:pkglist.
Starta det installerade komponenterna med kommandot:
osgi> package:pkgstart
Vänta ett tag på att bundlarna startar upp, ca 2 min.
Verifiera att samtliga bundlar är uppstartade med kommandot dep. (Kommandot listar alla bundlar som ännu inte är startade.) Exekvera kommandot:
osgi> dep Utskriftsexempel: osgi> dep id Bundle State Unsatisfied dependencies Spring dependencies osgi>
Listas inte någon bundel här, är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel.
Om någon bundel inte startar igång, testa att starta om säkerhetstjänster.
Kvarstår problemet måste felsökning påbörjas:Kontrollera systemloggen efter fel.
osgi> search -level error
Kontrollera även systemloggen efter fel. Systemloggen skapas i den lokala katalogen där Säkerhetstjänster körs och dit skrivs loggar innan systemet är helt startat och senare i vissa fall om det är loggning till fil, se exempel nedan.
Windows: C:\Program Files\Inera\Lokal Sakerhetstjanst<version>\local\log\outputlog_service.txt Linux: /sakerhetstjansten/Sakerhetstjanster<version>/local/log/sak_yyyy-mm-dd_hh-mm-ss.log
Verifiera att alla beroenden är uppfyllda med kommandot:
osgi> state Exempel: osgi> state Id Context State State Information osgi>
Listas inte någon bundel här, är alla beroenden mellan bundlarna uppfyllda. I annat fall upprepa kommandot i intervaller, tills kommandot inte listar någon bundel.
Kan ta ett antal minuter vid uppstart.
Om state visar någon eller några bundlar så kan det bero på följande:Om någon av tjänsterna Samtycke eller Spärr installeras, men inte lokal Loggtjänst, behöver tjänsterna konfigureras för att använda en extern loggtjänst. Följande ”fel” visas vid installation av enbart Spärr och IdP.
Exempel: osgi> package:pkglist Id Name Description 0 All All available packages 1 Authorization Local Local Authorization Service 2 IdP Local Identity Provider 3 Block Local Local Block Service 4 Commission Commission Service 5 Consent Local Consent Service 6 Log Local Log Service 7 Log Proxy Local Log Proxy 8 Log Report Local Log Report Service 9 PU Proxy Local PU Proxy osgi> osgi> package:pkginstall -p 1,2,3,4,5,7,9 osgi> package:pkgstart osgi> osgi> state Id Context State State Information 306 com.logica.se.bif.block.web.war UNRESOLVED DEPENDENCIES com.logica.se.bif.log.agent.LogAgent 341 com.logica.se.bif.consent.web.war UNRESOLVED DEPENDENCIES com.logica.se.bif.log.agent.LogAgent 352 com.logica.se.bif.log.agent.impl UNRESOLVED DEPENDENCIES com.logica.se.bif.log.service.LogStoreService (name=Service) 353 com.logica.se.bif.log.agent.txwrapper.impl UNRESOLVED DEPENDENCIES com.logica.se.bif.log.agent.LogAgent (transactional=false) 232 com.logica.se.rivta.ping.ws.factory/log1 UNRESOLVED DEPENDENCIES com.logica.se.rivta.ping.service.PingService (Bundle-SymbolicName=com.logica.se.bif.log.service.impl) 232 com.logica.se.rivta.ping.ws.factory/log2 UNRESOLVED DEPENDENCIES com.logica.se.rivta.ping.service.PingService (Bundle-SymbolicName=com.logica.se.bif.log.service.impl) 232 com.logica.se.rivta.ping.ws.factory/logreport1 UNRESOLVED DEPENDENCIES com.logica.se.rivta.ping.service.PingService (Bundle-SymbolicName=com.logica.se.bif.logreport.service.impl) 232 com.logica.se.rivta.ping.ws.factory/logreport2 UNRESOLVED DEPENDENCIES com.logica.se.rivta.ping.service.PingService (Bundle-SymbolicName=com.logica.se.bif.logreport.service.impl)
Figur: Utskriftsexempel 1, state, Unresolved dependencies.
Spärr (Block) saknar beroenden, i detta fall saknas en lokalt installerad Loggtjänst som behöver konfigureras manuellt med adressen till en extern loggtjänst.
- Ändra värdet för logStoreService från Service till Proxy. Linux: /share/Sakerhetstjanster<version>/local/config/com.logica.se.bif.log.agent.impl.xml Windows: C:\share\Sakerhetstjanster<version>\local\config\com.logica.se.bif.log.agent.impl.xml - Ange rätt värde för adress (hostname) och portnummer (portNumber) till den externa loggtjänsten. Linux: /share/Sakerhetstjanster<version>/local/config/com.logica.se.bif.log.v2.ws.proxyimpl.xml Windows: C:\share\Sakerhetstjanster<version>\local\config\com.logica.se.bif.log.v2.ws.proxyimpl.xml
Uppdatera bundlarna com.logica.se.bif.log.agent.impl.3.0.0 och com.logica.se.bif.log.v2.ws.proxyimpl.3.0.0 i systemkonsolen genom att först hitta rätt id med kommandot ss och sedan uppdatera bundle med aktuellt id. Se exempel nedan.
Exempel: osgi> ss com.logica.se.bif.log.agent.impl Framework is launched. id State Bundle 352 ACTIVE com.logica.se.bif.log.agent.impl_3.0.0 osgi> update 352 osgi> refresh 352 osgi> ss com.logica.se.bif.log.v2.ws.proxyimpl_3.0.0 Framework is launched. id State Bundle 361 ACTIVE com.logica.se.bif.log.v2.ws.proxyimpl_3.0.0 osgi> update 361 osgi> refresh 361
Verifiera beroenden igen med kommandot:
osgi> state
osgi> state Id Context State State Information 232 com.logica.se.rivta.ping.ws.factory/log1 UNRESOLVED DEPENDENCIES com.logica.se.rivta.ping.service.PingService (Bundle-SymbolicName=com.logica.se.bif.log.service.impl) 232 com.logica.se.rivta.ping.ws.factory/log2 UNRESOLVED DEPENDENCIES com.logica.se.rivta.ping.service.PingService (Bundle-SymbolicName=com.logica.se.bif.log.service.impl) 232 com.logica.se.rivta.ping.ws.factory/logreport1 UNRESOLVED DEPENDENCIES com.logica.se.rivta.ping.service.PingService (Bundle-SymbolicName=com.logica.se.bif.logreport.service.impl) 232 com.logica.se.rivta.ping.ws.factory/logreport2 UNRESOLVED DEPENDENCIES com.logica.se.rivta.ping.service.PingService (Bundle-SymbolicName=com.logica.se.bif.logreport.service.impl)
Figur: Utskriftsexempel 2, state, Unresolved dependencies
Bundeln com.logica.se.bif.ping.ws.factory publicerar ping-tjänsten för alla tjänster, varav Logg och Loggrapporttjänsten visas som icke startade i figuren ovan. I exemplet ovan valde vi att installera Lokal Spärrtjänst och IdP och därför saknas nu bundlar för Logg, Loggrapport. Vi vill nu ta bort konfigurationsfilerna för de tjänster som inte installerats för att lösa de "UNRESOLVED DEPENDENCIES" vi har.
Åtgärd för att ta bort pingtjänster som inte används:
- Gå till installationskatalogen
Linux: /share/Sakerhetstjanster<version>/local/config/com.logica.se.rivta.ping.ws.factory/ Windows: C:\share\Sakerhetstjanster<version>\local\config\com.logica.se.rivta.ping.ws.factory\
Ta bort konfigurationsfilerna för de tjänster som inte installerats enligt tabellen nedan.
Tjänst Konfigurationsfil Spärr blockLocalInternal.xml, blockLocalV2.xml,blockLocalV3.xml blockLocalV4.xml Logg (Loggrapport) log1.xml, log2.xml, logreport1.xml, logreport2.xml Samtycke consent_1.xml, consent_2.xml Idp commissionService.xml Logga in i osgi konsolen. Uppdatera bundeln för pingtjänsten com.logica.se.bif.ping.ws.impl_3.0.0 med update och refresh enligt exempel nedan.
osgi> ss com.logica.se.rivta.ping.ws.impl Framework is launched. id State Bundle 232 ACTIVE com.logica.se.bif.ping.ws.impl_3.0.0 osgi> update 232 osgi> refresh 232
Figur: Utskriftsexempel för att uppdatera pingtjänsten efter borttagning av konfiguration som ej används
Verifiera att alla beroenden är uppfyllda med kommandot:
osgi> state Exempel: osgi> state Id Context State State Information osgi>
Avsluta systemkonsolen med kommandot:
osgi> disconnect
8.2. Anslut till webbgränssnitt
- Om serverns adress inte finns i DNS-servern måste den lokala host-filen temporärt uppdateras på den klientdator som används för att ansluta till webbgränssnittet.
Lägg till följande i lokala host-filen: <server ip-adress nod1> nod1 - Verifiera att det går att ansluta till webbgränssnittet via en webbläsare ex. https://[servernamn]:8443 för en 8443-installation där den publika app-porten satts till 8443 och https://[servernamn] för en 443-installation.
Om frågan, att servern inte har ett giligt certifikat visas, välj ”continue to this website”.
Figur: Säkerhetstjänsters admin-GUI
8.3. Uppstart av lokal Säkerhetstjänst på övriga noder
För att starta systemet, gå in i verktyget Server Manager och Services och leta upp Lokala Säkerhetstjänsters tjänst (Lokal Säkerhetstjänst <version>). Starta servicen.
Vänta en stund på att systemet startar, det tar några min.
Logga in till systemkonsolen:
telnet localhost 1111
Lista installationspaketen som ska installeras med följande kommando:
osgi> package:pkglist Id Name Description 0 All All available packages 1 Authorization Local Local Authorization Service 2 IdP Local Identity Provider 3 Block Local Local Block Service 4 Commission Commission Service 5 Consent Local Consent Service 6 Log Local Log Service 7 Log Proxy Local Log Proxy 8 Log Report Local Log Report Service 9 PU Proxy Local PU Proxy
Exekvera package:pkginstall-kommandot med samma komponentlista som för nod 1. I exemplet nedan 1,2,3,4,6,7,8,9 för lokal spärrtjänst med IdP och logg:
för lokal Spärrtjänst med IdP och logg
Exempel: osgi> package:pkginstall -p 1,2,3,4,6,7,8,9
Starta de installerade bundlarna med kommandot nedan.
osgi> package:pkgstart
Vänta ett tag på att bundlarna startar upp, ca 2 min.
Verifiera att samtliga bundlar är uppstartade med kommandot dep. (Kommandot listar alla bundlar som inte har startat).
osgi> dep Exempel: osgi> dep id Bundle State Unsatisfied dependencies Spring dependencies osgi>
Listas inte någon bundel här är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel.
Om någon bundel inte startar, testa att starta om Säkerhetstjänster. Kvarstår problemet måste felsökning påbörjas.Verifiera att alla beroenden är uppfyllda med kommandot:
osgi> state Exempel: osgi> state Id Context State State Information osgi>
Listas inte någon bundel här, är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel.
När nu alla noder är installerade och uppstartade kan det vara bra att kontrollera att de har anslutit till infinispan-klustret.
Man kan kontrollera att samtliga noder ingår i infinispan-klustret med ett kommando i OSGi-konsolen. Detta kommando bör verifieras på varje nod för att säkerställa att noderna känner till varandra i klustret.
Utför på varje installerad nod i klustret:
Gå in i systemkonsolen med:
telnet localhost 1111
Slå kommando:
monitor -filter infinispan
Konsolen kommer nu lista vilka noder som ingår i klustret.
osgi> monitor -filter infinispan Id Type Timestamp Value Description com.logica.se.iac.cache.infinispan members String 2017-09-19 13:56:02:849 nod1-61437, nod2-41756 Available cluster members state String 2017-09-19 13:56:02:848 ACTIVE Context state which will show if configuration is needed, or if mandator OSGi service references are missing etc.
Exempel ovan på hur utskriften kan se ut när man ser över klustret i OSGi-konsolen. De noder här som ingår i klustret är "nod1-61437, nod2-41756".
- Stoppa Säkerhetstjänster på den nod som inte var listad i konsolen.
- Öppna kontrollpanelen och gå till tjänster.
Stoppa tjänsten ”Lokal Säkerhetstjänster <version>
- Stoppa Säkerhetstjänster på den nod som inte var listad i konsolen.
Starta Service Managern: C:\Program Files\Inera\Lokal Sakerhetstjanster <version>\services\Lokal Säkerhetstjänst <version>.exe
- Sök i Java Options efter argumenten -Dcom.logica.se.iac.cache.infinispan.protocol, -Djgroups.udp.mcast_addr och -Dcom.logica.se.iac.cache.infinispan.config.dir
Kontrollera att -Dcom.logica.se.iac.cache.infinispan.protocol är satt till TCP eller UDP.
- Kontrollera att -Dcom.logica.se.iac.cache.infinispan.config.dir är en korrekt sökväg och att denna katalog innehåller två XML-filer (jgroups-tcp.xml och jgroups-udp.xml)
- För UDP kontrollera att -Djgroups.udp.mcast_addr är satt till en giltig multicast-adress samt att multicast är aktiverat/möjligt i ert system/nät.
- För TCP kontrollera konfigurationsfilen jgroups-tcp.xml enligt Installation Infinispancluster cache över TCP på alla noder samt att vald port (default 7800) är öppen för kommunikation mellan noderna.
Kontrollera i senaste uppstartsloggen att utpekad konfigurationsfil verkligen används av applikationen.
C:\Program Files\Inera\Lokal Sakerhetstjanst <version>\local\log\outputlog_service_1.txt ... Infinispan configuration file resolved to 'C:\Program Files\Inera\Lokal Sakerhetstjanst<version>\local\jgroups\jgroups-tcp.xml
- Efter verifieringen: starta Säkerhetstjänsten igen.
- Öppna kontrollpanelen och gå till tjänster.
- Starta tjänsten ”Lokal Säkerhetstjänster <version>"
Låt en nod starta upp ordentligt innan man startar nästa. Kontrollera klustermedlemmarna igen med kommandot
monitor -filter infinispan
10. Avsluta systemkonsolen med kommandot:
osgi> disconnect
11. Verifiera att det går att ansluta till webbgränssnittet via en webbläsare ex:
https://[servernamn]
9. Systemkonfiguration
- Autentiseringsfilter - Filtret kräver att användaren ska autentisera sig för att få åtkomst till Säkerhetstjänster.
- Behörighetsfilter - Filtret styr vilken behörighet användaren har i Säkerhetstjänster. Det kan exempelvis innebära att en användare som har rollen som spärradministratör endast får hantera spärrar i systemet.
Filtren ska vara avstängda under pågående systemkonfiguration.
Verifiera att de är avslagna enligt:
Logga in till systemkonsolen med:
telnet localhost 1111
Inaktivera autentiseringsfiltret med kommando:
osgi> spfilter -off
Inaktivera behörighetsfiltret med kommando:
osgi> authz -off
Avsluta systemkonsolen med kommando:
osgi> disconnect
Anslut till Säkerhetstjänsters webbgränssnitt med den host-adress som ni angav i installationsskedet: https://[servernamn]/spadmin och genomför konfiguration enligt nedan:
9.1. Konfigurera HSA
Vid installationen anges adressen till HSA-WS. Om fel adress angavs eller om adressen måste ändras går det att konfigurera om den enligt nedan.
9.1.1. HSA-WS
Dessa instruktioner gäller endast om ni använder HSA-WS för att anropa HSA, vilket är default.
- Klicka på menyn Administration -> Generell Konfiguration.
- Välj sedan konfiguration HSA-WS Factory 3.1.5 och verifiera/ändra inställningarna.
Timeout In Milliseconds och Lookup Cache Duration ska normal inte ändras.
Timeout In Milliseconds anger hur länge tjänsten skall vänta på svar från HSA-tjänsten. Lookup Cache Duration anger hur länge i millisekunder ett hämtat värde kan återanvändas, utan att åter fråga HSA-tjänsten.
Figur: Konfiguration av HSA-WS Factory
9.1.2. HSA-RIVTA
Dessa instruktioner gäller endast om ni använder HSA-RIVTA för att anropa HSA.
- Klicka på menyn Administration -> Generell Konfiguration.
- Välj sedan konfiguration HSA RIVTA Service 1.0.0 och ändra inställningarna.
Timeout In Milliseconds och Lookup Cache Duration ska normal inte ändras.
Timeout In Milliseconds anger hur länge tjänsten skall vänta på svar från HSA-tjänsten. Lookup Cache Duration anger hur länge i millisekunder ett hämtat värde kan återanvändas, utan att åter fråga HSA-tjänsten.
Figur: Konfiguration av HSA Directory Organization Service
9.2. Konfigurera Personuppgiftstjänsten
Personuppgiftstjänsten behöver endast konfigureras om någon av följande tjänster är installerade: Samtycke eller Spärr.
Om man går mot Ineras nationella Personuppgiftstjänst för namnuppslag behöver man konfigurera så att anropen går via tjänsteplattformen.
- Klicka på menyn Administration -> Generell Konfiguration.
- Välj sedan konfiguration Resident Information Lookup Service 3.0.0. och se över så att inställningarna är korrekta. Det är viktigt att Pu service interface är inställt på Proxy. Se exempelbilden nedan.
Figur: Konfiguration av Resident Information Lookup Service 3.0.0
- Välj sedan konfiguration PU - V3 WS Proxy Impl 1.0.0 och se över så att inställningarna är korrekta. Se exempelbilden nedan.
Context Path PU version 3: vp/strategicresourcemanagement/persons/person
Figur: Konfiguration av PU - V3 WS Proxy Impl 1.0.0
9.3. Ta bort rotcertifikat för test vid en produktionssättning
I och med produktionssättning av systemet bör alla rotcertifikat som använts för test, tas bort ur listan med konfigurerade certifikatsutfärdare. Säkerställ först att inga ytterligare tester skall genomföras i systemet innan certifikaten tas bort.
Detta görs i två steg, först avmarkerar man i förtroendekällan att rotcertifikaten används, därefter tas rotcertifkaten bort.
- Klicka på menyn Administration -> Webbserver.
Klicka på knappen Ändra för förtroendekällan "No Check Trust Service".
Figur: Ändra rotcertifikat för förtroendekälla
Avmarkera de rotcerfikat som ska tas bort och klicka på knappen Spara.
Figur: Ändra förtroendekälla
- Gör motsvarande (punkt 2-3) för förtroendekällan "SAML Trust Service" samt "Trust Service".
- Klicka på menyn Administration -> Certifikatsutfärdare.
Klicka på soptunnan som tillhör den certifikatutfärdaren ni vill ta bort. Se bilden nedan:
Figur: Ta bort certifikatsutfärdareOm man får felmeddelandet ”En eller flera förtroendekällor använder denna certifikatsutfärdare....", används rotcertifikarten av någon webbserver.
Upprepa punkt 2-4 för berörda förtroendekällor för att ta bort användningen innan rotcertifikatet kan tas bort.
9.4. Lägg till rotcertifikat för front-end-certifikatet
Då det sedan april 2019 rekommenderas att skaffa ett certifikat till front-end-domänerna så vill man säkert lägga till tillit till en utgivare som inte finns med i installationspaketet.
- Öppna menyn Administration → Certifikatsutfärdare
- Klicka på knappen Lägg till
- Välj filen med rotcertifikatet för utgivaren av det certifikat som ska användas till front-end och klicka Spara
9.5. Konfigurera System, IdP och SP att använda SITHS-certifikat
Säkerhetstjänster är förinställt att använda front-end-certifikatet till att kommunicera med externa parter som t.ex Nationella spärrtjänsten och HSA genom NTjP. Men detta blir fel om man inte längre har SITHS-certifikat i front-end och därför vill vi nu ställa in Säkerhetstjänster för att använda SITHS-certifikatet för WebService-gränssnittet där vi behöver ett SITHS-certifikat:
- Systemets externa kommunikation
- IdP:ns signering av meddelanden
- SP:ns signering av meddelanden
Ändra till ws i följande konfiguration
- Administration → Generell konfiguration → System Identity Implementation
Ändra Identity Name till ws - Administration → Generell konfiguration → IdP Service Implementation
Ändra Selected Key Identity till ws - Administration → Generell konfiguration → SP Service Implementation
Ändra Selected Key Identity till ws
9.6. Tilldela systemet egenskaper för interna anrop
Systemegenskapen systemRole med värde Internal gör det möjligt för interna tjänster att göra anrop.
- Klicka på menyn Administration -> SP SAML.
Lägg till systemegenskapen systemRole:
Bläddra i listan Egenskap.
Skriv in Internal i fältet Värde.
Klicka på knappen Lägg till.
Figur: Exempel på konfiguration av systemegenskaper.
9.7. Konfiguration av CDC - Common Domain Cookie
CDC är en typ av webbkaka som används för hålla rätt på vilken IdP som medarbetaren använde senast, för att på så vis få SingleSignOn då det finns flera IdP:er.
Finns det bara en IdP ska nedanstående inställningar vara avaktiverade.
Konfiguration av CDC görs under menyerna Administration -> SP SAML och Autentisering -> IdP SAML.
Det går att aktivera/inaktivera att CDC används. Detta görs genom att bocka i eller ur kryssrutorna för SP och IdP CDC. Se bilderna nedan.
Bocka i kryssrutan om SP ska läsa från CDC. Se bilden nedan.
Figur: SP CDC inställningarBocka i kryssrutan om IdP ska skriva till CDC. Se bilden nedan.
Figur: IdP CDC inställningar
9.8. Autentiseringstjänsten - IdP
Säkerhetstjänster består av två huvuddelar, de tjänster SP:ar (såsom Spärr och Logg) som installeras och Autentiseringstjänsten (IdP).
- Installeras IdP:n behöver man i där konfigurera upp vilka SP:ar som får använda IdP:n.
- På motsvarande sätt måste man i SP-delen konfigurera upp vilka IdP:er som denna kan använda.
Denna konfiguration görs med hjälp av SAML-metadatafiler:
- SP-metadata beskriver hur SP:n fungerar och läses in i IdP:n.
- IdP-metadata beskriver hur IdP:n kan användas och denna läser man in i SP:n.
Om lokal Autentiseringstjänst och en av de lokala tjänsterna (såsom t ex Spärr) installerats, behöver man göra följande:
9.8.1. Exportera Säkerhetstjänsters IdP/SP metadata
- Öppna menyn Autentisering -> IdP SAML.
- Fyll i formuläret IdP Metadata med aktuella kontaktuppgifter. Dessa kommer att specificeras i metadatafilen.
- Uppdatera informationen genom att klicka på knappen Spara.
- Exportera IdP metadata med knappen Exportera. Filen kommer läsas in i ett senare skede, spara den på ett lämpligt ställe.
- Öppna nu menyn Administration -> SP SAML.
- Utför motsvarande procedur som tidigare (steg 2-4) för SP metadata.
9.8.2. Inläsning av metadata
IdP och SP-metadata måste läsas in till Säkerhetstjänster. Denna import av metadata sker i Säkerhetstjänsters webbgränssnitt.
Importera metadata till Säkerhetstjänster:
- Öppna menyn Administration ->SAML Metadata.
- Klicka på Välj fil (man kan bara importera en fil i taget). Välj den ena av era metadata-filer (dvs. IdP- eller SP metadata).
- Klicka på Importera.
- Upprepa importen för den andra metadata-filen.
De importerade metadata-filerna ska nu visas i tabellen ”Manuellt importerad Metadata” under "SP Metadata" och/eller "IdP Metadata".
Figur: Exempel på sidan SAML Metadata
9.8.3. Exportera SAML metadata
Inlästa filer kan exporteras. Denna export av metadata sker i Säkerhetstjänsters webbgränssnitt.
Exportera metadata från säkerhetstjänster:
- Öppna menyn Administration ->SAML Metadata.
- Välj metadata att exportera genom att i kolumnen Operationer klicka på exportera ikonen. Filen laddas ner för vald metadata.
9.8.4. Extern Autentiseringstjänst
Om ingen lokal autentiseringstjänst installerades, måste systemet ansluta sig till en extern autentiseringstjänst (IdP) för att användare ska kunna logga in i systemet. Detta görs genom att exportera SP metadata, enligt ovan, skicka denna XML-fil till organisationen som tillhandahåller autentiseringstjänsten. Metadata-filen måste importeras i deras system samt att dess (autentiseringstjänstens) IdP-metadata-fil måste importeras i det lokala systemet (korsvis exportering och inläsning).
9.9. Spärrtjänsten
Spärr kan konfigureras upp att antingen gå mot tjänsteplattformen eller köras lokalt. Exempelbilderna nedan visar hur konfigurationen ser ut mot tjänsteplattformen. Hänvisade host-namn och portar för konfigurationerna som beskrivs nedan ska konfigureras mot tjänsteplattformen.
Samtliga konfigurationer av tjänsten ligger i menyn Administration -> Generell Konfiguration.
En lokal uppsättning av Spärr skall normalt replikera sina lokala spärrar till den nationella Spärrtjänsten för att nationella e-tjänster, såsom t.ex. Nationell Patientöversikt (NPÖ), skall få ett så komplett spärrunderlag som möjligt.
Nationell replikering
En lokal spärrtjänst skall endast behöva ladda ner nationellt replikerade spärrar ifall den lokala spärrtjänsten används av system som behandlar data som är registrerad utanför de vårdgivare som den lokala spärrtjänsten redan hanterar spärrar för. Exempel på sådana system är system för sammanhållen journalföring.
Har man t.ex. endast sitt egna journalsystem anslutet till den lokala spärrtjänsten skall man inte behöva lasta ner den lokala spärrtjänsten med alla rikets spärrar.
9.9.1. Block Local Service 3.0.4
Se exempelbilden nedan för konfigurationen.
- Öppna konfigurationen Block Local Service 3.0.4.
- National block interface ska vara satt till Proxy (Den nationella Spärrtjänsten stödjer endast replikering via RIV TA 2.1).
Synkronisering till nationell Spärrtjänst aktiveras om Replicate to/from national node är ikryssat.
Även valet Send local blocks to national node ska vara ikryssat för att nya spärrar skall replikeras till den nationella tjänsten.
Valet Download blocks from national node kryssas endast i ifall man även behöver hela rikets spärrar (se info-rutan ovan).Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.
Figur: Block Local Service
9.9.2. Block Web Application 3.0.1
Se exempelbilden nedan för konfigurationen.
- Öppna konfigurationen för Block Web Application 3.0.1.
- Konfigurationen ska vara inställd efter bilden nedan, för att gå mot tjänsteplattformen.
Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.
Figur: Block Web Application
9.9.3. Block National Webservice V4 WS ProxyImpl for RIV 2.1 1.0.0
Se exempelbilden nedan för konfigurationen.
- Öppna konfigurationen Block National Webservice V4 ProxyImpl for RIV 2.1 1.0.0.
- Ange Context path for National Webservice, Host name och Port number.
Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.
Figur: Block National Webservice V4 ProxyImpl for RIV
9.10. Konfiguration av PDL-loggning
PDL-loggar kan styras att antingen gå mot lokalt installerad Loggtjänst eller så kan tjänsterna lokal Spärr, Samtycke logga dessa händelser till den nationella Loggtjänsten.
- För att använda en extern loggtjänst konfigureras modulen Log Agent Impl till att använda en Proxy samt ange adress och portnummer till den externa loggtjänsten i modulen Log V2 WS Proxy Impl.
- För att använda den lokala Loggtjänsten konfigureras modulen Log Agent Impl till att använda Service och ingen konfiguration behövs för modulen Log V2 WS Proxy Impl.
Exempelbilderna nedan visar hur konfigurationen styr PDL-loggar att lagras på en den nationella Loggtjänsten.
Samtliga konfigurationer av tjänsten Logg ligger i menyn Administration -> Generell Konfiguration. För att anslutningen till den nationella Loggtjänsten ska fungera måste förvaltningsorganisationen för nationella Säkerhetstjänster kontaktas för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1].
9.10.1. Log Agent Impl 3.0.0
- Öppna konfigurationen Log Agent Impl 3.0.0.
- Om en extern loggtjänst ska användas, sätt Log service till Proxy.
- Om den lokala Loggtjänsten ska användas, sätt Log service till Service.
Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.
Figur: Log Agent Impl
9.10.2. Log V2 WS Proxy Impl 3.0.0
- Öppna konfigurationen Log V2 WS Proxy Impl 3.0.0.
- Ange Context Path, Host name och Port number.
Klicka på knappen Spara när konfigurationen är klar och återgå till Generell konfiguration med knappen Tillbaka.
Figur: Log V2 WS Proxy Impl
9.11. Loggtjänsten - hämtning av arkivloggar från den nationella Loggtjänsten
Om lokala Loggtjänsten installerats, kan den egna vårdgivarens loggar hämtas från den nationella Loggtjänsten via dess hämtningstjänst. För att den lokala installationen av Säkerhetstjänster ska kunna hämta arkiv från nationella Säkerhetstjänster måste förvaltningsorganisationen för nationella Säkerhetstjänster kontaktas för att öppna upp access till tjänsten. Kontakta Ineras förvaltning i god tid före driftstart [Ref 1]. För att rätt behörighet ska ges, krävs det att det lokala Säkerhetstjänsters SP-metadata bifogas. Se avsnitt Exportera Säkerhetstjänsters IdP/SP metadata
9.11.1. Schemaläggning för automatisk hämtning av arkiv
När schemaläggaren är aktiv och ingen information om föregående arkivnedladdningar existerar, hämtar den gårdagens arkivloggar.
Om tidigare nerladdningar av arkivloggar har lyckats (dvs. har status ”Done”) så utgår schemaläggaren från den senaste arkivhämtningen nästkommande dag. Nedan följer två möjliga scenarion över hur detta kan se ut.
Scenario 1 - Ny installation och inga loggarkiv har hämtats tidigare.
Resultat: Schemaläggaren hämtar gårdagens arkivloggar.
Scenario 2 – Loggarkiv har hämtats tidigare och lokala Säkerhetstjänster har legat nere 3 dagar innan den har gått upp igen.
Resultat: Schemaläggaren hämtar arkivloggar för 3 dagar tillbaka.
- Klicka på menyn Administration -> Generell Konfiguration.
- Öppna konfigurationen Log Download Archive
- I tabellen nedan, konfigurera följande:
- 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_v2/archives/).
- Host name – Domännamn till nationella tjänsten.
- Port – Portnummer till nationella tjänsten.
- Protocol – https eller http (Default: https).
- Aktivera därefter schemaläggaren så att den hämtar gårdagens (eller från när den hämtade senast) arkiv per automatik genom att bocka i ”Scheduler enabled”.
- Konfigurera när schemaläggaren ska starta, Scheduler start time, det görs i formatet HH:mm (00:00 – 23:59) Default: 02:00 på natten.
Figur: Log Download Archive
9.11.2. Manuell hämtning av (äldre) arkiv ifrån den nationella Loggtjänsten
När den automatiska hämtningen startar, hämtas bara gårdagens arkiv (eller från den tidpunkt när arkiven hämtade senast). Om behov finns, av att hämta äldre arkiv, måste detta utföras manuellt.
Logga in till systemkonsolen med:
telnet localhost 1111 osgi>plat:help
Följande kommandon finns att tillgå i systemkonsolen:
archive:dl <parametrar>
archive:status <parametrar>
---[ archive ]---------------------------------------------------------------------------------------------------------- dl Download archives from national log service. -careprovider careprovider id (HSA-ID). -from From date (Format: yyyy-MM-dd). This parameter is required if -archive is not in use! -archive Archive id. This parameter is required if -from is not in use! -force Force archives that already have the status 'Done' to be handled -to To date (Format: yyyy-MM-dd). If flag is not specified, todays date will be used status Archive download status. If limit is not specified limit will be set to 20 -code List by status code (Download,Unzip,Log,Done,Error) -test Test the connection -limit How many records should be shown -from From date (Format: yyyy-MM-dd). -to To date (Format: yyyy-MM-dd).
Figur: Kommandon för manuell hämtning av arkivloggar
Exempel 1 - Hämta alla arkivloggar från 1:a januari 2017
osgi> archive:dl -careprovider SEMyCareProvider -from 2017-09-01
Exempel 2 - Hämta alla arkivloggar från 1:a januari 2017 till 1:a augusti 2017
osgi> archive:dl -careprovider SEMyCareProvider -from 2017-09-01 -to 2017-09-17
Exempel 3 – Visa status på alla hanterade arkivloggar som har gått fel
osgi> archive:status -code Error
Exempel 4 – Testa anslutningen mot nationella säkerhetstjänsten
osgi> archive:status -test
9.12. Arkivsökning
Syftet med arkivsökningstjänsten är att söka fram arkiverade loggrapporter som är äldre än 18 månader och innefattar sökning i komprimerade arkiv. Här kan man vilja se över de tider på dygnet som den processintensiva genereringen av denna rapport tillåts. Fälten Report execute start interval och Report execute stop interval beskriver det intervall som dessa jobb inte tillåts exekvera (klockan 22.00 till 05.00 i fallet nedan).
Notera att Arkivsökningen kommer att skapa en katalog på den delade diskytan för att lagra den komprimerade xml-filen som sökningen resulterar i.
10. Behörighet
Säkerhetstjänster validerar vad en användare har behörighet att göra i systemet utifrån de egenskaperna som finns i dennes SAML-intyg. Användare som autentiserar sig till systemet med ett SITHS-kort får sina egenskaper från HSA-katalogen. En egenskap kan exempelvis vara BIF;Spärradministratör som innebär att användaren har behörighet att hantera spärrar.
Åtkomstkontrollen består av två delar.
- Behörighetsregler som läses in i databasen via osgi consolen. Dessa regler kontrollerar behörighet för GUI och tjänster mot aktuell användare och system.
- I SP-metadata anges vilka vårdgivare som ska få åtkomst från ett system. Här kommer resursens (spärr, samtyckes etc) vårdgivare att kontrolleras mot listade vårdgivare i SP-metadata för respektive system.
Gemensamt för dessa är kontrollen mot konsumentsystem där tillåtna vårdgivare ska specificeras på båda ställen, dvs i SP-metadata och behörighetsregler i XML-regelfil.
10.1. Behörighetsregler för användare
Säkerhetstjänster validerar vad en användare har behörighet att göra i systemet, utifrån de egenskaperna som finns i användarens SAML-intyg. Användare som autentiserar sig till systemet med ett SITHS-kort får sina egenskaper från HSA-katalogen. En egenskap kan exempelvis vara BIF;Spärradministratör som innebär att användaren har behörighet att hantera spärrar. Dessutom måste man i den lokala Säkerhetstjänsten konfigurera in vilken/vilka vårdgivare denna instans representerar, denna information jämförs sedan med innehållet i användarens SAML-biljett för att på så vis avgöra om användaren är behörig eller ej.
I installationspaketet ingår det en mall för de behörighetsregler som en lokal installation behöver. Reglerna måste anpassas efter era vårdgivare och vad dessa ska få behörighet att göra i systemet.
10.1.1. Behörighet för slutanvändare i Säkerhetstjänsters admin-GUI
För att slutanvändare skall få tillgång till administrationssidan krävs minst ett medarbetaruppdrag i HSA, för de SITHS-kort som används. Var god kontakta Inera [Ref 1] för mer information kring anslutning och dokumentation.
Användaren och medarbetaruppdraget måste innehålla minst följande:
Namn | Beskrivning |
---|---|
HSA Systemroll | Användarens systemroll(er). T ex För åtkomst till spärrar krävs rollen: BIF;Spärradministratör |
HSA-id för medarbetaren | Användarens personliga HSA-id. |
HSA-id för medarbetaruppdrag | Det valda medarbetaruppdragets HSA-id. |
Namn på medarbetaruppdrag | Det valda medarbetaruppdragets namn. |
HSA-id för vårdgivare | HSA-id för vårdgivaren som medarbetaruppdraget gäller inom. |
Namn på vårdgivare | Namn på vårdgivaren som medarbetaruppdraget gäller inom. |
HSA-id för vårdenhet | HSA-id för vårdenheten som medarbetaruppdraget gäller inom. |
Namn på vårdenhet | Namn på vårdenheten som medarbetaruppdraget gäller inom. |
Se Användarhandboken [Ref 2] för mer detaljerad information om åtkomst och regler i behörighetsadministrationen.
10.1.2. Skapande av behörighetsregler för användare
Från denna version kan man enkelt skapa behörighetsregler via administrationsgränssnittet, i tidigare versioner fanns endast möjlighet att göra detta i Säkerhetstjänsters OSGi-konsol (systemkonsol). Nedan beskrivs båda metoderna.
Lägg till vårdgivare:
- Fyll i vårdgivarens HSA-id i textfältet VårdgivarId.
- Klicka på knappen Lägg till. Observera att systemet inte är anpassat efter vårdgivaren i detta läge.
- Återupprepa steg 1-2 för varje vårdgivare som ska tilldelas behörighet. Klicka sedan på knappen Spara lista. Säkerhetstjänsters behörighetsregler kommer därefter att uppdateras efter de tillagda vårdgivarna. Det innebär att reglerna är inlästa och nästa steg är att slå på behörighetskontrollen, se kapitel 11.
Ta bort vårdgivare:
- Klicka på soptunnan på den rad som vårdgivaren ni vill ta bort finns på.
Uppdatera behörighetsreglerna sedan genom att klicka på knappen Spara lista
Som alternativ till ovan nämnda metod kan man från installationspaketet hämta en mall för de behörighetsregler som en lokal installation behöver. Reglerna måste anpassas efter era vårdgivare och vad dessa ska få behörighet att göra i systemet.
Mallen ligger under mappstrukturen: <Lokal_sakerhetstjanst>/rules/regler_default_lokal.xml.
När samtliga vårdgivare (som ska ha behörighet att hantera de installerade tjänsterna) är inlagda i de lokala behörighetsreglerna, ska de läsas in i Säkerhetstjänster, antingen via administrationsgränssnittet eller OSGi-konsollen.
Läs in regler via administrationsgränssnittet:
Klicka på Övriga behörighetsfunktioner längst ner på sidan Behörghet. Välj sedan er anpassade regel-fil och importera den.
Via konsol:
Logga in till systemkonsolen. Ange den adress och port till konsolen som valdes i installationsskedet:
telnet localhost 1111
Läs in reglerna med kommandot:
osgi> acc -import file:///<sökväg till er anpassade regel-fil>
Reglerna är nu inlästa, Avsluta systemkonsolen med kommandot:
osgi> disconnect
10.1.3. SP-metadata
Förutom att ge andra system (SP) rätt att autentisera sig mot IdP:n används även SP-metadata för att kontrollera att externa vårdsystem och tjänsteplattformen har behörighet att nyttja Säkerhetstjänsternas tjänster. Denna kontroll sker på resursnivå och kontrollerar att resursens (spärr, samtycke etc) vårdgivare är listad i SP-metadata. Det som menas med vårdsystem är ett externt system som ska ha behörighet att anropa någon av de tjänster som ingår i Säkerhetstjänster (dvs. Samtycke, Logg och Spärr) som är definierade i tjänstekontrakten.
I leveransen ingår det en mall för SP-metadata. Metadata-filen anpassas efter följande kriterier:
- Systemets HSA-id (entityID).
- Systemroll (SystemRole) som kan anta värdet Internal, System eller SystemIgnoreCareProvider. Bara ett alternativ anges för respektive metadatafil.
- Internal: Är tänkt att bara används av proxy och internt av systemet (SP SAML). Alla vårdgivare är tillåtna på alla tjänster
- SystemIgnoreCareProvider: Är tänkt att användas av TP, NPÖ och ev. andra konsumentsystem. Alla vårdgivare är tillåtna men saknar åtkomst till vissa tjänster såsom rapportstatus, loggrapportinfo, loggstatus.
- System: Övriga konsumentsystem där även vårdgivare kontrolleras. Tillåtna vårdgivare listas i metadatafilen.
- HSA-id för de vårdgivare som som ett systemet ska vara behörig till och då anges urn:sambi:names:attribute:careProviderHsaId=VårdgivareID. Används bara tillsammans med systemRole=System
- HSA-id för de vårdgivare som som ett systemet ska vara behörig till och då anges urn:sambi:names:attribute:careProviderHsaId=VårdgivareID. Används bara tillsammans med systemRole=System
Mallen ligger under mappstrukturen: <sakerhetstjanst>/example/metadata/example-system-metadata.xml.
Bilden nedan visar exempel på hur en metadata-fil för ett konsumentsystem ser ut för dessa alternativ. Värdet i entityID är det som ska ersättas med konsumentsystemets HSA-id. OBS! Lista med behöriga vårdgivare ska ej anges om systemrollen ärInternal eller SystemIgnoreCareProvider.
Figur: Exempel på SP-metadata fil som kan läsas in i systemet
10.1.4. Läs in SP-metadata
Läs in SP-metadata för de system som ska ha behörighet till Säkerhetstjänsten. Behörighet ska ges till Tjänsteplattformen om man väljer att ansluta sig via den.
- Ta filerna som finns i katalogen:
- /tmp/Sakerhetstjanster<version>/metadata
- Läs in dessa metadatafiler via Admin GUI. Se avsnitt Inläsning av metadata
10.1.5. Generera WS metadata
Menyn Behörighet innehåller en panel där behöriga administratörer kan generera webservice (WS) metadata. Som tidigare beskrivet används WS metadata för att tilldela åtkomst för externa vårdsystem och andra tjänster. Detta är beskrivet i djupare detalj i Användarhandbokens avsnitt Behörighet för externa vårdsystem och framåt.
Panelen innehåller alternativ för att generera WS metadata anpassat per vårdgivare eller WS metadata där anrop från, oavsett vårdgivare, tillåts. Behörighetsstyrningen sker i det senare alternativet istället i tjänsteplattformen (TP).
Figur: Panelen för att generera WS metadata.
Ett krav för att generera WS metadata, som behörighetsstyr per vårdgivare, är att dessa vårdgivare redan är konfigurerade. En rekommendation är att först kontrollera den listan innan generering sker. Se avsnitt Hantera vårdgivare i Användarhandboken. Om det anropande systemet ska tilldelas åtkomst, oavsett vårdgivare, ska kryssrutan Tillåt alla vårdgivare (TP) vara ikryssad.
Fyll i fältet Entity-id som WS metadata-filen ska gälla för. Entity-id är en unik identifierare för det anslutande systemets funktionscertifikat. Detta id listas under ”SERIALNUMBER” under ”Subject” i certifikatets detaljerade information. Man kan exempelvis använda en webbläsare för att ta del av informationen, förutsatt att certifikatet är installerat.
Klicka på knappen Generera metadata. En WS metadata-fil kommer nu att genereras och exporteras till ett XML-format. Se avsnitt WS Metadata i Användarhandboken för inläsning av filen.
10.1.6. Ta reda på HSA-id
Det går att ta reda på HSA-id:et för vårdsystemet eller tjänsteplattformens funktionscertifikat om man har tillgång till certifikatfilen.
- Har man tillgång till certifikatfilen kan man öppna denna och ta reda på id:t genom:
- Öppna certifikatets leg.cer fil och klicka på Details.
- Bläddra i listan som visas. Klicka på informationsfältet Subject.
- En informationsruta visas. Det Serial number som visas i rutan är certifikatets serienummer, dvs. det HSA-id som ni ska specificera i metadata-filen som ni anpassar till systemet.
11. Aktivera filter och logga in
11.1. Aktivering av filter för autentisering och åtkomstkontroll
Säkerhetstjänster använder sig av två filter:
- Autentiseringsfilter - Filtret kräver att användaren ska autentisera sig för att få åtkomst till Säkerhetstjänster.
- Behörighetsfilter - Filtret styr vilken behörighet användaren har i Säkerhetstjänster. Det kan t ex innebära att en användare som har rollen som spärradministratör endast får hantera spärrar i systemet.
Efter att systemet installerats och konfigurerats ska filtren aktiveras:
Logga in i systemkonsolen med:
telnet localhost 1111
Aktivera autentiseringsfiltret med kommandot:
osgi> spfilter -on
Aktivera behörighetsfiltret med kommandot:
osgi> authz -on
Avsluta systemkonsolen med kommandot:
osgi> disconnect
11.2. Logga in i Säkerhetstjänster
När ni har installerat och konfigurerat upp systemet, starta webbgränssnittet för lokala Säkerhetstjänster:
Kontrollera därefter att webbgrässnittet nu kräver SITHS-kort inloggning och att ett medarbetaruppdragsval är obligatoriskt om användaren har fler än ett medarbetaruppdrag i HSA-katalogen.
12. Systemadministration
12.1. Start och stopp
12.1.1. Stoppa lokala Säkerhetstjänster
För att stoppa systemet, gå in i verktyget Server Manager och Services och gå till lokala Säkerhetstjänsters tjänst (Lokal Säkerhetstjänst <version>) och klicka på Stop.
12.1.2. Starta lokala Säkerhetstjänster
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 <version>) och klicka på Start.
Man bör alltid säkerställa att systemet startat korrekt genom att kontrollera att systemloggen inte innehåller några fel (Exceptions). Avvakta upp till en minut så att lokala Säkerhetstjänster har givits tid att starta upp och kontrollera därefter den senaste loggfilen (läs mer om loggning och felsökning i avsnitt Systemlogg (audit)
12.2. Logga in i lokala Säkerhetstjänster
När ni har installerat servern kan ni gå till det grafiska webbgränssnittet för lokala Säkerhetstjänster: https://[servernamn]/spadmin
Där testas inloggningsförfarandet med val av SITHS-kort och val av medarbetaruppdragsval.
12.2.1. Logga in med SITHS-kort
- Sätt in SITHS-kortet i kortläsaren. Öppna webbläsaren och ange adressen till webbgränssnittet.
- Ange PIN-koden för SITHS-kortet i autentiseringsrutan. Klicka därefter ok. Fönstret ”Välj Medarbetaruppdrag” visas.
- Klicka på ett presenterat uppdrag för att fortsätta.
- Här presenteras enbart aktiva medarbetaruppdrag, alltså uppdrag på vårdenheter som är aktiva.
- Om vyn ”Välj Medarbetaruppdrag” inte visas, beror det på att:
- Medarbetaren har bara ett uppdrag vilket då väljs automatiskt.
- Medarbetaren är redan inloggad och har en aktiv session (t.ex. om medarbetaren först loggar in i NPÖ och därefter i samma webbläsare startar Säkerhetstjänster’s webbgränssnitt). Det uppdragsval som gjordes vid första inloggningen används automatiskt vid efterföljande inloggning (SSO).
- Inloggningen till webbgränssnittet är klart.
I webbgränssnittet gäller generellt att endast de knappar eller funktioner som medarbetaren har behörighet till visas och de övriga funktionerna döljs.Vid osäkerhet på vilket uppdrag som ger rättighet till vad, prova att först logga ut och därefter logga in igen i webbgränssnittet med något annat tänkbart uppdrag. Behörigheten styrs med hjälp av de uppdrag som är kopplade till SITHS-kortet och dessa hämtar systemet från HSA. Om behörighet till någon funktion saknas, kontakta HSA-support eller motsvarande för att lägga till de uppdrag och behörigheter som behövs.
12.3. Hantera aktiviteter i OSGi
Systemet har en inbyggd systemkonsol (OSGi-konsol) som är åtkomlig via Telnet på port 1111 (om inget annat angavs under installationen). Systemkonsolen används endast vid produktsupport eller felsökning, samt av- och påslag av autentiseringsfiltret.
12.3.1. Verifiera att systemets alla bundlar är uppstartade
Logga in till systemkonsolen:
telnet localhost 1111
Verifiera att alla beroenden är uppfyllda med kommandot:
osgi> state Utskriftsexempel: osgi> state Id Context State State Information osgi>
Listas inte någon bundel här är samtliga bundlar startade. I annat fall upprepa kommandot i intervaller tills kommandot inte listar någon bundel.
Om någon bundel ej startar igång, testa att starta om säkerhetstjänster. Kvarstår problemet måste felsökning påbörjas.
12.3.2. Aktivering av filter för autentisering och åtkomstkontroll
Gå in i systemkonsolen med:
telnet localhost 1111
Aktivera/Inaktivera autentiseringsfiltret med kommandot:
osgi> spfilter -on osgi> spfilter -off
Aktivera/Inaktivera behörighetsfiltret med kommandot:
osgi> authz -on osgi> authz -off
Avsluta systemkonsolen med kommandot:
osgi> disconnect
12.4. Systemlogg (audit)
Lokala Säkerhetstjänster producerar en systemlogg för teknisk förvaltning och felsökning, som lagras på filsystemet under uppstartsfasen. Systemloggen lagras i följande katalog (enligt standardinstallationen):
Exempel Linux: /sakerhetstjansten/Sakerhetstjanst<version>/local/log/
Exempel Windows: C:\Program Files\Inera\Lokal Sakerhetstjanst<version>\sakerhetstjansten\log
Systemet lagrar systemloggarna i första hand i databasen (schemat audit) och kan nås genom kommandot audit från systemkonsollen, se avsnitt Sök i systemloggen. Om inte databasen är uppsatt för att kunna hantera systemloggar (som sker i installationsskedet av Säkerhetstjänster) skrivs systemloggarna till filen ovan istället.
Vid uppstart av systemet kan systemloggningen temporärt ske till fil (för att få uppstartsloggar), men den övergår snabbt till att logga till databas när loggfunktionen är startad.
12.4.1. Sök i systemloggen
Logga in till systemkonsolen med:
telnet localhost 1111
Sök i loggen enligt:
(Alla error loggar den senaste timmen) osgi> search -level error -time 1h (Alla loggar den senaste timmen) osgi> search -time 1h (Alla loggar de senaste 5 minuterna) osgi> search -time 5m
Avsluta systemkonsolen med kommandot:
osgi> disconnect
12.4.2. Status för loggfunktionen
Av olika anledningar (t ex nätverksproblem) kan lagring av systemloggar misslyckas till aktuell källa. Om lagring av loggar till t ex databas skulle misslyckas kommer systemet gå vidare med att lagra/skriva loggar till nästkommande källa enligt en förinställd prioritetsordning. Systemet kommer dock automatiskt att återgå till det normalläge när felet ej längre kvarstår.
Nedan följer en beskrivning hur detta kan utföras manuellt.
Logga in till systemkonsolen med:
telnet localhost 1111
Nedan kommando ger status för systemloggning:
osgi> monitor -filter LogTarget Id Type Timestamp Value Description com.logica.se.iac.logging.impl.LogTarget console String 2017-09-11 14:30:21:907 Operational db String 2017-09-11 14:30:21:907 Error db.errorCount String 2017-09-11 14:30:21:907 2 db.errorInstant String 2017-09-11 14:30:21:907 2017-09-11 14:23:06 db.errorLastRetry String 2017-09-11 14:30:21:907 2017-09-11 14:29:46 db.errorMessage String 2017-09-11 14:30:21:907 java.lang.Exception file String 2017-09-11 14:30:21:907 Operational mongo String 2017-09-11 14:30:21:907 Operational
Operational är normalläget. Är någon källa markerad med Error kan dessa återställas. Här visas att Mysql (db) är i status Error, samt information om felet, när felet först uppstod, senaste tidpunkt för återförsök att logga till källan samt totalt antal återförsök.
Återställa statusvariabler görs enligt:
(Kommando för att återställa Mysql) osgi> monitor -reset com.logica.se.iac.logging.impl.LogTarget/db (Kommando för att återställa Mongo) osgi> monitor -reset com.logica.se.iac.logging.impl.LogTarget/mongo (Kommando för att återställa File) osgi> monitor -reset com.logica.se.iac.logging.impl.LogTarget/file (Kommando för att återställa Console) osgi> monitor -reset com.logica.se.iac.logging.impl.LogTarget/console
Avsluta systemkonsolen med kommandot:
osgi> disconnect
12.5. Felsökning
Om problem uppstår där lokala Säkerhetstjänster misstänks vara orsaken bör följande saker undersökas:
- Monitorera MySQL-processen och kontrollera att databasen svarar på enkla förfrågningar.
- Monitorera MongoBD-processen och kontrollera att databasen svarar på enkla förfrågningar.
- Monitorera Java-processen på applikationsserver och kontrollera att att det går att logga in i det grafiska webbgränssnittet, https://[servernamn]/spadmin.
- Vid akuta problem, starta om applikations- och/eller databasservern och kontrollera systemloggen.
Vid produktfelanmälan måste alla systemloggar kring felet samt ett beskrivande scenario kring vad som föranledde felet, bifogas felanmälan.
13. Test
För att verifiera systemet kan följande anvisning användas:
Test av installation eller uppgradering 2.17
14. Förvaltning och underhåll
14.1. Periodiskt underhåll
Läs Systemlogg (audit) för information angående hur systemloggar lagras och söks i.
Hantera aktiviteter i OSGi beskriver hur systemet kan hanteras och kontrolleras i systemkonsolen (OSGi).
14.2. Backup
14.2.1. Applikationsserver
Systemets delade diskyta - Innehåller Loggtjänstens arkivloggar och systemets gemensamma konfiguration bl.a.
- Windows: default C:\share
- Linux: default /share
Respektive applikationsserver data-katalog
- Windows: default C:\Program Files\Inera\Lokal Sakerhetstjanst<version>\sakerhetstjansten\data)
- Linux: default: /sakerhetstjansten/Sakerhetstjanst<version>/local/data
14.2.2. Databasserver Mysql
Allt data som säkerhetstjänster lagrar i mysql ska tas backup på. Se tillverkarens instruktioner för hur backup/restore görs.
14.2.3. Databasserver MongoDB
Då innehållet i MongoDB för Loggtjänsten kan återställas av applikationen från arkiv-loggarna är det inte nödvändigt att utifrån ett återställningsscenario ta backup av MongoDB-databasen. Dock går det betydligt snabbare att göra en restore med hjälp av mongoDB:s interna backup/restore funktionalitet vilket gör att det är den rekommenderande lösningen. Övrigt data som lagras i mongoDB är ej känsligt och behöver ej återställas vid en eventuell restore. Se tillverkarens instruktioner för hur backup/restore görs.
14.3. Uppgradering
Lokala Säkerhetstjänster kan mjukvaruuppgraderas då nyare versioner av produkten finns tillgängliga. Mer information om detta ges för respektive uppgradering. Var god kontakta Inera för information kring aktuella versioner [Ref 1].
15. Avinstallation
Lägg märke till att avinstalltionen ej tar bort installationskatalogen (C:\Program Files\Inera\*). Den behövs för en eventuell rollback. Behövs inte det kan katalogen tas bort med valfri filhanterare.
Om installationen var en redundant installation med flera noder, så skapades även en katalogstruktur på den delade diskytan. Innehållet på diskytan måste tas bort manuellt då den behövs för en rollback!
Obs! Det kan vara bra att ta en backup på den delade diskytan, om systemet behöver återställas.
För att avinstallera:
- Stoppa först tjänsten Lokal Sakerhetstjanst <version>. Se bilden nedan.
Figur: Exempelbild från services under verktyget Server Manager - Avinstallera sedan systemet enligt standardiserat sätt via Windows kontrollpanel -> Avinstallera och ändra program. Se bilden nedan.
- Välj ”Uninstall a program” under menyn Programs.
- Dubbelklicka på Lokal Sakerhetstjanst <version>
Figur: Avinstallation av tjänsten
- Lokala Säkerhetstjänster avinstalleras.
16. Appendix
16.1. Appendix A - Exempel på konfiguration av den lokala brandväggen för windows servrarna
- Använd Windows sökfunktion för att söka efter verktyget Windows Firewall with Advanced Security
- Konfigurera inställningarna för brandväggen genom att starta verktyget Windows Firewall with Advanced Security.
- Skapa en ny regel under Inbound rules, se tabellen nedan.
- Använd tabellmallen nedan för att skapa upp den nya regeln.
Steg | Val | Beskrivning |
---|---|---|
Rule Type | Port | Regel som kontrollerar anslutningar för TCP eller UDP port |
Protocol and Ports | TCP Specific local ports | Ange dom portar som beskrivs i tabellen under avsnitt Översikt adresser och portar |
Action | Allow the connection | Inkluderar anslutningar som vare sig är skyddade eller ej utav IPsec |
Profile | Domain, Private, Public | Ange om regeln ska gälla för Domain/Private/Public |
Name | Lokala säkerhetsjänster | Namn och beskrivning för regeln, |
16.2. Appendix B - Skapa separat servicekonto
Vid installation av service Lokal Säkerhetstjänst installeras den och körs default som Local System.
Det är rekommenderat att skapa ett separat servicekonto som servicen använder. Nedan visar på ett exempel hur detta skapas. Användaren för kontot har vi i exemplet nedan namngett till sak
16.2.1. Skapa en användare
För att skapa ett nytt servicekonto:
- Använd Windows sökfunktion och sök efter verktyget för Local Users and Groups genom att söka efter lusrmgr.msc
I sökfältet skriv in lusrmgr.msc och starta verktyget Local Users and Groups (lusrmgr.msc)
Högerklicka på gruppen Users och välj New user…
Figur: Lägg till ny användareEtt 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.Avaktivera "User must change password at next logon"
Klicka i "Password never exipires"
Figur: exempel på skapande av användare
- Klicka på knappen Create och därefter på knappen Close. En ny användare är nu skapad.
16.2.2. Tilldela användaren "Log on as a service" behörighet
För att användaren ska få behörighet att köra en service, behöver den tilldelas en policy för detta.
- Använd Windows sökfunktion och sök och starta verktyget Local Security Policy.
Figur :Administrative Tools vyn. - Expandera Local Policies och klicka på User Rights Assignment i menyn.
- Lokalisera policyn Log on as a service i listan till höger och dubbelklicka på den.
Figur: Local Polices vyn. - Klicka på knappen Add User or Group och peka ut den användare du vill servicen ska köras som.
I exemplet är det den lokala användaren sak som vi skapade i tidigare steg.
Figur: Add User or Group. - Klicka på knappen OK och verifiera att användaren sak finns med i listan (i bilden ovan).
- Klicka på knappen OK.
16.2.3. Ändra användare på den installerade servicen
För att ändra användare på servicen:
Använd Windows sökfunktion och sök och starta verktyget Services
Figur: Administrative tools-vyn.Leta rätt på servicen under verktyget Server Manager Lokal Säkerhetstjänst <version> i listan och dubbelklicka på den.
Figur: Services-vyn.Klicka på Log On fliken i dialogen.
Förvalt är värdet satt till Local System Account, men sök istället fram och välj den användare som skapades innan (i detta exempel sak), genom att klicka på knappen Browse.
Figur: Service egenskaper.Klicka på knappen OK.
16.2.4. Uppdatera behörighet till filer och kataloger som säkerhetstjänster använder
Starta utforskaren och bläddra fram dig till de kataloger systemet är installerat på och använder.
(C:\Program Files\Inera)
(C:\share)
Högerklicka på katalogen Inera och C:\share eller motsvarande katalog i er miljö.
Välj Properties samt Security-fliken.
Figur: Security vyn.
Klicka på knappen Edit och knappen Add och peka ut användaren som service körs med (som skapades innan). Tilldela användaren sak - Full Control och klicka på knappen OK.
Figur: Security - Add.
16.2.5. Lägg till behörigheter i registret
Användaren sak behöver även behörighet att läsa och skriva i registret.
- Använd Windows sökfunktion för att söka och starta verktyget regedit
- Sök fram till katalogstrukturen (under ”(HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\CGI)”) där Säkerhetstjänster är installerad. Se bild nedan.
Figur: Registry editor. - Högerklicka på motsvarande huvudkatalog till Säkerhetstjänster och välj Permissions...
Figur: Permissions - Välj serviceanvändaren sak som skapades tidigare och lägg till följande behörigheter (permissions) för användaren: Full Control.
Dessa behörigheter sätts med kryssrutan som bilden nedan visar. Klicka på knappen OK.
Figur: Behörigheter för användare
16.3. Appendix C - Krav på delad diskyta vid en fail-over installation
Samtliga noder i fail-overlösningen skall använda samma sökväg till den delade diskytan. UNC-sökvägar (Nätverkssökväg, t.ex. \\my.share.domain.se\share) stöds inte.
För att uppnå det kan en symbolisk länk skapas på respektive nod, genom att använda kommandot mklink.
Den delade diskytan kan t.ex. sättas upp med hjälp av en samba-share, Microsoft cluster disk eller NFS delning.
Exempel
Sökväg som valts till delad diskyta på nod #1, nod #2, och övriga noder: C:\share
Sökväg till nätverksresurs: \\my.share.domain.se\share
På samtliga noder, skapa en symbolisk länk C:\Share till den delade resursen "\\my.share.domain.se\share" med hjälp av kommandot:
mklink /D C:\Share "\\my.share.domain.se\share"
C:\>mklink Creates a symbolic link. MKLINK [[/D] | [/H] | [/J]] Link Target /D Creates a directory symbolic link. Default is a file symbolic link. /H Creates a hard link instead of a symbolic link. /J Creates a Directory Junction. Link specifies the new symbolic link name. Target specifies the path (relative or absolute) that the new link refers to. C:\> C:\> mklink /D C:\Share "\\my.share.domain.se\share" Symbolic link created for C:\share <<===>> \\my.share.domain.se\share C:\>
Figur: mklink exempel
Använd därefter sökvägen till den delade diskytan (symboliska länken C:\share) under installationsförfarandet.