1. Dokumentinformation
1.1. Syfte
Syftet med detta dokument är att beskriva arkitekturen för autentiseringstjänsten.
1.2. Målgrupp
De huvudsakliga målgrupperna för detta dokument är beställare, arkitekturledningen, systemarkitekter och utvecklingsteam.
1.3. Revisionsinformation
Version | Datum | Författare | Kommentar |
---|---|---|---|
0.9 | 2012-06-28 | Per Jonsson, Roger Öberg | Första utgåva |
0.91 | 2012-10-26 | Björn Skeppner | Vissa textjusteringar |
0.92 | 2013-12-06 | Daniel Fjällström | Flyttat dokument till confluence |
0.93 | 2014-01-13 | Roger Öberg | Uppdaterad med krav på rika klienter bl.a. |
0.94 | 2014-01-16 | Daniel Fjällström | Uppdateringar efter synpunkter från Björn Skeppner. |
0.95 | 2014-06-03 | Uppdaterad efter granskning | |
0.96 | 2014-07-09 | Uppdaterat efter granskning av Björn Skeppner | |
0.97 | 2015-06-04 | Uppdaterat SAD struktur samt Java/MySQL version | |
0.98 | Gått igenom dokument för 2.11 | ||
1.0 | Granskad för 2.12 | ||
1.0 |
| Granskad för version 2.14 (ingen ändring) | |
1.1 |
| Reviderad för 2.16 | |
1.2 |
| Granskad för 2.18 |
2. Översiktlig beskrivning
2.1. Sammanfattning
Autentiseringstjänsten syftar till att erbjuda vårdgivare och dess vårdsystem en säker autentisering av aktörer/vårdpersonal. Autentiseringstjänsten tillhandahåller s.k. single sign on (SSO) inom webbapplikationer, enligt väl definerade standarder, så som SAML Web SSO Profile.
Utöver detta rättar sig tjänsten efter den profil som begränsar, samt identifierar tekniker som måste realiseras, för att med säkerhet tillgodose funktionalitet i en federering mellan flertalet autentiseringstjänster (IdP:er).
Tjänsten tillhandahåller också funktion för att på ett enhetligt sätt logga ut aktören från samtliga inloggade tjänsteleverantörer, s.k. koordinerad utloggning eller single logout (SLO), förutsatt att tjänsteleverantören stödjer detta enligt SAML 2.0
Standardiseringsorganet OASIS har ett flertal standarder som identifierar problem, samt föreslår lösningar för dess problem. Dessa standarder, ex. SAML 2.0, används för att på ett standardiserat sätt implementera tjänsten. Vid en lyckad autentisering ställs ett s.k. SAML-intyg ut som beskriver aktören, samt dess egenskaper, som är tänkta att användas av ett ABAC (Attribute Based Access Control) behörighetssystem, dvs behörighet på egenskapsnivå, till skillnad från RBAC (Role Based Access Control) som har behörighet på roll nivå.
Aktörer som skall autentiseras måste vara upplagda i HSA katalogen. Om aktörer har två eller flera medarbetaruppdrag, måste aktören välja aktuellt uppdrag för autentiseringen, alternativt att initierande part anger sin autentiseringsbegäran att medarbetarval inte skall göras. Detta baseras på vilka attribut som efterfrågas. Om endast ett uppdrag finns väljs detta implicit. SAML profilen definierar vilken mängd egenskaper som tillhandahålls av tjänsten. Vid autentisering utan uppdragsval (dvs aktören saknar medarbetaruppdrag, eller SP aktivt anger att uppdragsval ej skall ske) innehåller utfärdat SAML-intyg endast sådana egenskaper som inte är uppdragsspecifika.
3. Målbild och principer
3.1. Verksamhetsmässig målbild
Tillhandahålla en IdP tjänst som möjliggör SSO mellan vårdgivarens lokala vårdsystem, samt mellan vårdgivarens lokala vårdsystem och nationella vårdsystem. Detta skall vara fallet oavsett vart man initialt autentiserar sig (lokalt eller nationellt).
Denna produkt uppfyller följsamhet gällande IdP mot ”SAML V2 Conformance”, [SAML2Conf], enligt nedan tabell.
Feature Matrix | |||
---|---|---|---|
Feature | IdP | IdP Lite | Autentiseringstjänsten |
Web SSO, <AuthnRequest>,HTTP redirect | MUST | MUST | STÖDJER |
Web SSO, <Response>, HTTP POST | MUST | MUST | STÖDJER |
Web SSO, <Response>, HTTP artifact | MUST | MUST | STÖDJER |
Artifact Resolution, SOAP | MUST | MUST | STÖDJER |
Enhanced Client/Proxy SSO, PAOS | MUST | MUST | STÖDJER |
Name Identifier Management,HTTP redirect (IdP-initiated) | MUST | MUST NOT | STÖDJER INTE |
Name Identifier Management, SOAP (IdP-initiated) | MUST | MUST NOT | STÖDJER INTE |
Name Identifier Management, HTTP redirect | MUST | MUST NOT | STÖDJER INTE |
Name Identifier Management, SOAP (SP-initiated) | MUST | MUST NOT | STÖDJER INTE |
Single Logout (IdP-initiated) – HTTP redirect | MUST | MUST | STÖDJER |
Single Logout (IdP-initiated) – SOAP | MUST | OPTIONAL | STÖDJER |
Single Logout (SP-initiated) – HTTP redirect | MUST | MUST | STÖDJER |
Single Logout (SP-initiated) – SOAP | MUST | OPTIONAL | STÖDJER |
Identity Provider Discovery (cookie) | MUST | MUST | STÖDJER |
3.2. Arkitekturella mål
Följande verksamhetskopplade mål och krav finns för tjänsterna:
3.2.1. Generella mål
- Följsamhet mot Nationella IT-strategin, enligt T-Boken.
- Följsamhet mot de OASIS standarder som berörs
- Följsamhet mot ”SAMBI SAML Profil”.
- Följsamhet mot SAMBI:s tekniska ramverk (www.sambi.se)
3.2.2. Specifika mål
- Tjänstegränssnitt realiseras enligt SAML SOAP bindning, och tar hänsyn till ”SAMBI SAML Profil”., gällande dessa.
- Tjänstegränssnitten transportsäkras enligt ”SAMBI SAML Profil”.
- Tjänsten baserar sin förlitandemodell på information som förmedlas med hjälp av SAML Metadata, enligt ”SAMBI SAML Profil”. Dvs endast entiteter, som har förmedlats via SAML Metadata, kan nyttja tjänsten.
- Stöd för distribuerad arkitektur, där det är möjligt för en intressent (region/landsting/kommun) att upprätthålla egna instanser av tjänsen. Alternativt kan intressenter gemensamt använda tjänsten via central tjänst (molnbaserad).
- Löst kopplad arkitektur för att dynamiskt erhålla identifikationsmetoder, så som X.509 certifikatsidentifikation, engångslösen (one-time password), samt andra metoder i framtiden.
- Presentationslager som tillhandahåller statusinformation för tekniska mätpunkter, som underlättar övervakningen i driftmiljö, se ”Driftanvisning”.
- Administrativa funktioner, så som att administrera de olika identifikationsmetoderna, och tjänsten i sig.
- Erhålla minst upplevd SSO mellan rika klienter och webb-applikationer under förutsättning att samma IdP används. Upplevd SSO defineras genom att certifikat (SITHS) används för inloggning, och att aktören inte aktivt behöver välja detta certifikat, samt att uppdragsval endast presenteras vid första inloggning.
- Uppfylla PDL krav på rika klienter gällande säker inloggning.
- Tjänstegränssnitt av rika klienter realiseras enligt standard (STS ,WS-Trust 1.3).
- Enbart metoden Issue ska stödjas.
- Tjänsten ska enbart stödja klientautentisering med hjälp av X.509 certifikat (dvs SITHS eller motsvarande).
- Tjänsten skall kunna installeras på både Windows och Linux
- Tjänsten ska kunna skala vertikalt och horisontellt för att kunna ge hög tillgänglighet,hög kapacitet och låga svarstider.
- Användaren måste finnas i HSA eller motsvarande för att en autentisering ska kunna ske.
- Om användaren finns i HSA men saknar medarbetaruppdrag ska bas-biljett med följande egenskaper skapas.
- urn:sambi:names:attribute:authnMethod
- urn:sambi:names:attribute:x509IssuerName
- urn:sambi:names:attribute:levelOfAssurance
- http://sambi.se/attributes/1/employeeHsaId
- SP skall via kombination av SP-metadata och autentiseringsbegäran ange vilka attribut som skall erhållas.
- Uppdragsval presenteras enbart om attribut som kräver detta efterfrågas och mer än ett medarbetaruppdrag finns att välja.
- Om inga specifika attribut efterfrågas (att explicit efterfråga 0 attribut räknas som att attribut efterfrågats) returnerar IdP:n alla tillgängliga attribut med eventuellt uppdragsval.
- För att stödja uppdragsval ska en separat tjänst,Commission Service, tas fram baserat på RIV TA 2.1. Tjänsten CommissionService ska ingå i leveransen utav säkerhetstjänster.
- Ett aktivt val i CommissionService gäller i 12h innan det nollställs. (vilket resulterar i ett nytt medarbetaruppdragsval för användaren ifall denna har mer än 1 medarbetaruppdrag).
- Rik och tunn klient ska använda Commission Service för att binda ihop uppdragsvalet mellan rik och tunn klient inom en IdP.
- IdP:n ska använda Commission Service vid varje autentisering för att avgöra vilket medarbetaruppdrag som är aktuellt att ställa ut en SAML-biljett för.
- Upplevd SSO ska erhållas under förutsättning att samma IdP och Commission Service används.
- Idp:n ska stödja 2-vägs ssl och meddelandesignering vid identifikation utav slutanvändare.
- Klienten kan inte specificera nyckel med useKey utan det är alltid nyckeln från SSL/meddelandesignaturen som används (Detta för att inte behöva kontrollera om angiven nyckel går att "lita på").
- Endast stöd för SAML 2.0 intyg.
- SAML-intygen ska utställas med HolderOfKey, HoK, med stöd för både assymetriska(dvs den rika klientens certifikat/privata nyckel) och symmetrisk nycklar (IdP genererad nyckel).
- SAML-metadata ska användas för att erhålla trust mellan rika klienter (SP) och autentiseringstjänsten (IdP).
3.2.3. Planerade avsteg
Inga planerade avsteg.
3.3. Prioriterade områden
I denna utveckling är prioriterat att anpassa tjänsten enligt ”SAMBI SAML Profil”.
4. Teknisk lösning
4.1. Översikt – Autentiseringstjänst
Bilden nedan visar översiktligt beroenden till andra system och tjänster som Autentiseringstjänsten har. För integration med HSA se [T1].
Figur 1 Systemberoende till andra system
- HSA-RIVTA används för att erhålla aktörers medarbetaruppdrag, samt för att inhämta aktörens egenskaper vid utställande av identifikationsintyg (typ SAML v2.0).
- OTP används vid identifiering när aktören nyttjar PIN och SMS kod (s.k. engånglösen).
- PKI (OCSP/CRL) används för att kontrollera spärrstatus för certifikat.
- Commission Service används för att hantera medarbetaruppdrag, samt val av aktivt uppdrag.
- SAMBI metadatatjänst - en central metadatatjänst där federationens metadata samlas.
Autentiseringstjänsten har realiserats enligt nedan figur. Den består av sju huvudmoduler som hanterar och möjliggör ”pluggbarhet” i systemet.
Figur 2 Intern uppbyggnad av tjänsten
Följande huvudmoduler finns.
- Identifikationsmetoder, hanterar installerade identifikationsmoduler, så som X.509 certifikat, OTP.
- Bindningar, hanterar de bindningar som SAML har definierat. Initial stöds de som visas i figur 2.
- Webb, tillhandahåller webbapplikationer för uppdragsval och administration av tjänsten.
- Meddelandehantering, denna modul ansvarar för att de meddelanden som inkommer/skickas hanteras enligt den logik som krävs för respektive meddelande.
- Egenskapskällor, tillgängliggör/hämtar egenskaper för aktörer vid lyckad identifiering.
- Metadata, tillhandahåller meta data till den egna tjänsten, samt publicerar för externa parter.
- WS, tillhandahåller WS-Trust 1.3 STS (Security Token Service)
4.2. Översikt – Plattform
Tjänsten har implementerats på en gemensam plattform, som är baserad på ett OSGi-ramverk utvecklat av bl.a. Eclipse. I plattformen ingår grundläggande teknik så som system-loggning, övervakning, konfiguration, webbtjänstestack, webbapplikationsserver och transaktionell databashantering.
Autentiseringstjänstimplementationen paketeras som moduler (s.k. bundlar) som installeras i plattformen.
Följande skiktning gäller för tjänsten
Figur 3 Intern vy av applikationslagren
- Persistenslager – Hanterar databaskommunikationen
- Tjänstelager – Hanterar affärslogiken för autentiseringstjänsten.
- Webbtjänstelager – Hanterar SAML HTTP-SOAP bindning.
- Webbapplikationslager – Hanterar HTTP-Redirect, HTTP-Post samt HTTP-Artifact bindingar, och även de administrativa webbapplikationerna. Identifikationsmetoderna som initialt tillhandahålls installeras som webbapplikationer, dels för identifiering av aktör, och dels för administration av dessa.
4.3. Signifikanta delar av lösningen
4.3.1. Tjänsteinteraktioner - princip för tekniska gränssnitt
Alla integrationsmönster som ingår i denna arkitekturbeskrivning baseras på nyttjande av löst kopplade tjänstegränssnitt mot tjänsterna (tjänstekontrakt), utan beroende till specifika agenter eller programmeringsbibliotek (SDK:er).
Det är självklart möjligt att använda och alternativt tillverka ett programmeringsbibliotek för en specifik plattform, men integrationspunkterna (kontrakten) mellan systemen är de bakomliggande tjänstekontrakten.
I tjänsten finns det tre typer av tjänstegränssnitt:
4.3.1.1. Commission Service (RIV TA)
Commission Service är realiserad med hjälp av rivta-tjänstekontrakt ("fråga-svar")
Nedan figur visar principen för de tjänsteinteraktioner som ingår i tjänstekontrakten. Kontraktet reglerar hela samspelet mellan konsument och producent.
Figur 4 Tjänsteinteraktion, typfall "fråga - svar"
Integrerande vårdsystem anropar tjänsterna med webbtjänsteteknik enligt profilen RIV TA 2.1. Det innebär i korthet att
- att tjänstekonsumenten har ett servercertifikat och kan hantera TLS/SSL med klientautentisering för säker kommunikation med tjänsteproducenten.
- att tjänstekonsumenten kan skicka och ta emot XML över HTTPS
4.3.1.2. Webb SSO/SLO (SAML 2.0)
Autentiseringstjänsten för Webb (Single Sign On/ Single Log Out för tunna klienter) är realiserad utifrån SAML 2.0 specifikationerna. Tjänstekontrakten här är realiserade med hjäp av bindningstyperna HTTP POST, HTTP artifact, HTTP Redirect och SOAP. För SOAP-binding krävs att tjänstekonsumenten har ett servercertifikat och kan hantera TLS/SSL med klientautentisering för säker kommunikation med tjänsteproducenten. Behörighet till tjänsterna regleras med hjälp av SAML metadata.
4.3.1.3. SSO för rika klienter (WS-Trust 1.3)
Autentiseringstjänsten för rika klienter (Single Sign On) är realiserad utifrån WS-Trust 1.3 specifikationerna. Klientautentisering sker med hjälp av X.509 certifikat, antingen genom ömsesidig SSL/TLS handskakning, alternativt meddelandesignering enligt WS-Security/WS-Security Policy.
4.3.2. Ramverk för realisering av ingående tjänsteproducenter
Tjänsteproducenterna är internt uppbyggda med hjälp av följande tekniska ramverk:
- Java SE 8
- OSGi (Eclipse)
Java används för att realisera tjänsterna och möjliggöra exekvering på olika miljöer.
4.3.3. OSGi ramverk
Den Java-plattform som tjänsteproducenterna bygger på är i botten en OSGi-lösning som medger löst kopplade komponenter, så kallade bundlar, som kan uppgraderas individuellt. Det är också möjligt att på ett smidigt sätt växla mellan olika implementationer av samma gränssnitt. Detta skapar en mycket flexibel och pluggbar plattform. OSGi är en komponentmodell med stöd för att hantera olika versioner/implementationer av samma komponent samtidigt samt att dynamiskt kunna byta ut komponenter under drift.
Ramverket tillhandahåller en standardiserad miljö för applikationer (bundlar) och består av fyra lager.
L0: Execution Environment – Exekverande miljö
L1: Modules – Moduler/Komponenter
L2: Life Cycle – Livscykel hantering
L3: Service Registry - Tjänsteregister
Figur 5 OSGi uppbyggnad
L0: Execution environment – Specificerar Java miljön.
Java 2 konfigurationer och profiler som J2SE, CDC, CLDC, MIDP o.s.v. är alla möjliga att använda som exekveringsmiljöer.
L1: Modules – Definierar policies för klass laddning.
OSGi ramverket är en kraftfull och strikt modell för class loading som bygger på Javas mekanismer för att ladda klasser men är utbyggt för att bättre hantera moduler/komponenter. I Java finns det normalt bara en classpath som innehåller alla klasser och resurser men med OSGi Modules får varje modul en egen privat classpath och allt som ska exponeras utanför en modul måste specificeras explicit.
L2: Life Cycle – Hanterar dynamisk installation, start, stopp, uppdatering och avinstallation av bundlar. Life Cycle använder sig av Modules för att utföra klassladdning men tillhandahåller ett API för hantering av moduler under drift.
L3: Service Registry – Tillhandahåller en dynamisk samarbetsmodell för bundlar. Bundlar kan samarbeta via traditionell klassdelning vilket inte är så kompatibelt med dynamisk installtion och avinstallation av kod, därför tillhandahåller Service Registry en modell för att kunna dela objekt mellan olika bundlar. Ett antal händelser är specificerade för att hantera att tjänster kommer och går, tjänster i detta fall är vanliga Java objekt. Många tjänster motsvarar server funktionalitet t.ex. en HTTP server medan andra kan vara vilket verksamhetsobjekt som helst.
En applikation i OSGi plattformen kallas för en bundle och kan beskrivas som ett vanlig Java ARchive (JAR) med ett utökat Manifest. Manifestet i en bundle specificerar vad den exporterar och vilka beroenden den har för att kunna exekvera i OSGi miljön.
En OSGi bundel innehåller vanliga Java klasser (POJO) som inte behöver vara beroende av OGSi API:t eller känna till att de exekveras som en OSGi bundle.
Figur 6 Schematisk överblick över en OSGi bundle
Varje komponent/bundle specificerar vad den tillhandahåller och vad den använder.
Om Servicekontraktet överensstämmer kopplar OSGi miljön ihop den komponent som tillhandahåller tjänsten med den som nyttjar tjänsten.
4.3.4. Metro
Metro är den webbtjänstestack som används inom tjänsteproducenterna. Den inkluderar bl.a. JAX-WS, WSIT, JAXB och implementation för många av de WS-* standarder som nyttjas av tjänsteproducenterna.
Figur 7 Metro webbtjänstestack
JAX-WS är grundstommen för utveckling av SOAP baserade webbtjänster inom Java och är en standardteknologi i Java.
JAX-WS tillhandahåller funktionalitet för att publisera samt kommunicera över webbtjänstegränssnitten.
JAXB tillhandabåller bindingen mellan XML och JAVA POJO. Vilket underlättar hanteringen av XML data som skickas/tas emot över webbtjänstegränssnittet.
Figur 8 JAXB - Bindning av schema till Java klasser
WSIT (Web Services Interoperability Technologies) är en implementation som utökar JAX-WS med mekanismer för att kommunicera med andra webbtjänstestackar på ett interoperabelt sätt, i synnerhet för Windows Communication Foundation (WCF).
WSIT innehåller stöd för meddelande optimering, säker meddelande transport, säkerhet osv. Det finns även stöd för bootstrapping och konfiguration.
Bilden nedan visar vilka underliggande tjänster som är implementerade för varje område.
Figur 9 WSIT Web Service Features
4.3.5. Tjänstepaketering
Tjänsteproducenterna följer internt samma mönster för paketstruktur för att möjliggöra olika deployment scenarier, för att t ex möjliggöra skalbarhet för att öka prestanda.
Figur 10 Tjänstepaketering
4.3.6. Ramverk för realisering av ingående användargränssnitt/webbklienter
Ingående användargränssnitt realiseras av ramverket Google Web Toolkit (GWT), som är kompatibelt med alla de större webbläsarna på marknaden idag.
4.3.7. Identifikationsmetod
En identifikationsmetod realiseras som en webbapplikation (bundle) som installeras i tjänsten. Följande identifikationsmetoder levereras med tjänsten.
- X.509 certifikat genom klientautentiserad SSL/TLS
För den nationella tjänsten kommer dessutom följande idententifikationsmetoder att finnas.
- OTP(engångslösen via SMS)
5. Användargränssnitt
De administrativa användargränssittet tillgängliggörs som tjänst (enligt service provider), som använder normalt autentiseringförfarande (se ”SAMBI SAML Profil”) för att säkert autentisera aktörer. Detta innebär att SSO/SLO erhålls för administration av autentiseringstjänsten.
5.1. Användargränssnitt vid autentisering
5.1.1. Val av autentiseringsmetod
Följande dialog visas för aktören då man ska välja autentiseringsmetod. (visas endast då fler än en autentiseringsmetod finns tillgängliga, för närvarande gäller detta enbart nationell autentiseringstjänst)
Figur 11 Dialog för val av autentiseringsmetod (om flera finns)
5.1.2. Val av medarbetaruppdrag
Följande dialog presenteras för aktören när denna skall välja medarbetaruppdrag.
Figur 12 Dialog för val av uppdrag (om flera finns)
5.2. Användargränssnitt för administration
För den administration som behövs, finns ett särskilt användargränssnitt mot tjänsten. Se vidare användarhandbok.
5.3. Behörighetskontroll
För att få behörighet till de administrativa delarna, kan man vid installation konfigurera de egenskaper och värden som behövs för att få tillgång till de administrativa funktioner systemet tillhandahåller.
5.4. Utformning av användargränssnitt
Användargränssnitt för administratörer innehåller tre huvudområden enligt figuren nedan. 1 är menyn för funktionsval, 2 är toppmenyn med allmän information och 3 är vyn som visar information beroende på funktionsval.
Figur 13 Utformning av användargränssnitt.
Användargränssnittet är utformat efter principerna
- Enkelhet och avskalat men informativt
- Intuitiv navigering genom dialogerna.
5.5. Systemkrav för ingående användargränssnitt
Genom användande av Google Web Toolkit (GWT) teknik görs användargränssnitt kompatibla med dagens vanliga webbläsare.
Som minimum kommer följande webbläsare att verifieras i tester:
- Internet Explorer 11
Programvara för hantering av X.509 certifikat testas med NetiD 6.x, dock skall andra ”vanliga” kort klienter fungera.
Operativsystem: Windows 7.
Framtida versioner av programvara för eTjänstekort/eID, webbläsare och operativsystem måste kvalitetssäkras löpande.
6. Användningsfallsöversikt
6.1. Primära användningsfall IdP
Figur 14 Primära användningsfall IdP
6.1.1. P_IDP01: Autentisera
Aktören identifierar sig genom att presentera sitt certifikat/PIN varpå IdP verifierar certifikatet med OCSP/CRL. Därefter presenterar ett medarbetaruppdragsval, om användaren har mer än ett uppdrag. Finns bara ett uppdrag väljs detta automatiskt. Vid lyckad autentisering utställs ett SAML-intyg, som identiferar aktören.
6.1.2. P_IDP02: Autentiserad aktör
IdPn kontrollerar att aktören redan har en befintlig SSO session, varpå ett nytt SAML-intygt utställs (med samma uppdragsval/egenskaper) för den redan identifierade aktören.
6.1.3. P_IDP03: Byta uppdrag
Realiseras genom att användaren först gör en utloggning (SLO) och därefter gör en inloggning på nytt, enligt användningsfallen P_IDP04 och P_IDP01.
6.1.4. P_IDP04: Logga ut aktör, SLO
IdPn erhåller en utloggningsbegäran (typ SLO), varpå IdPn meddelar alla applikationer (SP) som deltagit i SSO sessionen att logga ut aktören.
6.2. Sekundära användningsfall IdP
Figur 15 Sekundära användningsfall IdP
6.2.1. S_IDP01: Administrera tjänsten
Möjlighet att konfigurera betrodda certifikatsutfärdare, SAML attribut ex. giltighetstid etc. Möjlighet att konfigurera SAML Meta Data.
6.2.2. S_IDP02: Hämta meddelande, ”Artifact Resolve”
Möjliggöra för en service provider att hämta ett meddelande med hjälp av en artifakt (ex. hämta ett AuthnResponse innehållande ett SAML-intyg).
6.2.3. S_IDP03: Hantering av federationens metadata.
Möjliggöra för synkronisering av federationens SAML metadata med hjälp av SAMBI:s metadatatjänst.
6.3. Primära användningsfall SP
Figur 16 Primära användningsfall SP
6.3.1. P_SP01: Hantera ej autentiserad aktör
SP identiferar att aktören ej är autentiserad. IdP identifiering (enligt ”SAMBI SAML Profil”) och SAML Metadata används för att identifiera aktuell IdP.
Initierar autentisering enligt användningsfall P_IDP01.
6.3.2. P_SP02: Hantera IdP initierad autentisering
Aktören kommer in till SP med ett redan befintlig SAML-intyg (unsolicitated response). Om SP litar på utställaren får aktören tillgång till SP.
Unsolicitated response, skall hanteras i enlighet med ”SAMBI SAML Profil”.
6.3.3. P_SP03: Hantera SP initierad autentisering
Aktören kommer tillbaka till SP med SAML-intyg. SP verifierar att det kommer från tidigare gjord begäran. Om SP litar på utställaren får aktören tillgång till SP.
6.3.4. P_SP04: Logga ut aktör, SLO
Aktören klickar på ”logga ut”, varpå SP skickar en utloggningsbegäran till IdP enligt användningsfall P_IDP04.
6.3.5. P_SP05: Byta uppdrag
SP initierar en SLO enligt AF P_SP04 för att sedan på nytt autentisera aktören enligt P_SP01
6.3.6. P_SP06: Förnya SAML-intyget
Aktörens SAML-intyg har gått ut, eller är på väg att gå ut. Varpå SP autentiserar aktören på nytt enligt användningsfall P_IDP02.
6.4. Sekundära användningsfall SP
Figur 17 Sekundära användningsfall SP
6.4.1. S_SP01: Aktören stänger webbläsaren utan att logga ut
Det kommer att vara konfigurerbart i IdP:n att antingen tolka detta som att användaren har ”loggat ut” och presentera uppdragsval på nytt när användaren loggar in igen(default). Alternativt att uppdragsvalet är cachat i IdP:n så att valet görs automtiskt utan interaktion ifrån användaren.
6.4.2. S_SP02: Aktören rycker kortet
Detta hanteras av NetID, och är konfigurerbart hur det fungerar. Om webbläsaren stängs ned kommer uppdragsvalen att hanteras enligt S_SP01. Detsamma gäller även scenariot där användaren t.ex. rycker kortet och går till en annan dator för att starta en ny vårdapplikation. Observera att detta inte betraktas som en säker utloggning.
6.4.3. S_SP03: Administrera tjänsten
Tekniska administratörer måste ha möjlighet att konfigurera SAML Meta Data som skall gälla för SP.
6.5. Aktörsinformation
Nedan sammanställs de aktörer som behöver agera i användningsfallen.
6.5.1. Aktörstyp 1: Personal
Personal anställda inom vården eller kommun, som är upplagda i HSA.
6.5.2. Aktörstyp 2: Administratör
Teknisk administratör inom verksamheten
6.5.3. Aktörstyp 3: System
Applikationer, typ SP eller IdP.
7. Tjänstekontrakt
Tjänstekontrakt : tunna klienter - följer standarden för SAML 2.0.
Tjänstekontrakt: rika klienter - följer standarden WS-Trust 1.3
Tjänstekontrakt: CommissionService enligt rivta 2.1.
8. WS-Trust (Security Token Service)
Det måste även vara möjligt att autentisera en rik klient. För att göra detta används WS-Trust version 1.3.
8.1. Begär säkerhetsintyg (SAML 2.0)
På serversidan finns en STS (SecurityTokenService) som är en webservice för att skapa Token (SAML-biljett) till en rik klient.
Klienten anropar webservicen, gör en RST (Request Security Token) och får tillbaka från klienten en Token som sedan kan användas vid kommunikation med backend.
8.1.1. Autentiseringsmetoder
Klientautentisering sker med hjälp av X.509 certifikat, antingen genom ömsesidig SSL/TLS handskakning, alt meddelandesignering enligt WS-Security/WS-Security Policy.
8.1.2. Request Type
Den metoden STS:en kommer att stödja är Issue.
8.1.3. Token Type
STS:en stödjer SAML 2.0 Assertion (http://docs.oasis-open.org/wss-m/wss/v1.1.1/wss-SAMLTokenProfile-v1.1.1.html).
8.1.4. Key Type
STS:en stödjer Public key samt Symmetric key.
Symmetric key Stödjer max 256 key size.
8.1.5. Canonicalization Algorithm
STS:en stödjer dessa versioner av Canonicalization:
- Exclusive XML Canonicalization Version 1.0 (http://www.w3.org/2001/10/xml-exc-c14n#)
- Canonical XML Version 1.0 (http://www.w3.org/TR/2001/REC-xml-c14n-20010315)
8.1.6. Signature Algorithm
STS:en stödjer dessa signeringsalgorithmer:
8.2. Commission Service
Eftersom WS-Trust 1.3 inte har stöd för uppdragsval, så finns det en separat tjänst som sköter detta. Denna tjänst har två ingångar.
Den första ingången är för att hämta vilka uppdrag en användare har, vilket uppdrag användaren valde senast samt om valet fortfarande är aktivt. De vill säga att användaren inte behöver göra ett nytt uppdragsval.
Den andra ingången är för att utföra själva valet. Så att STS vet vilket uppdrag som gäller för användaren.
Anropet till CommissionServicen sker normalt från Backend.
Gör användaren inget val av uppdrag eller saknar uppdrag i HSA så kommer biljetten enbart innehålla basuppgifter:
- urn:sambi:names:attribute:authnMethod
- urn:sambi:names:attribute:x509IssuerName
- urn:sambi:names:attribute:levelOfAssurance
- http://sambi.se/attributes/1/employeeHsaId
Har användaren enbart ett uppdrag behöver man inte göra ett aktivt val utan STS:en kommer att välja detta uppdrag.
Ett uppdragsval är giltigt i 12 timmar. (är konfigurerbart)
8.2.1. Tjänstekontrakt
Tjänstekontraktet för CommissionService finns att ladda ner här: http://rivta.se/domains/ehr_commission.html
9. Sekvenser
Nedan följer exempel på typiska sekvenser.
Definitioner:
bas-biljett = SAML-biljett med endast användarens basegenskaper:
- urn:sambi:names:attribute:authnMethod
- urn:sambi:names:attribute:x509IssuerName
- urn:sambi:names:attribute:levelOfAssurance
- http://sambi.se/attributes/1/employeeHsaId
uppdrags-biljett = SAML-biljett inklusive egenskaperna från 1 av användarens uppdrag
Förutsättningar:
- Användaren finns i HSA. Finns inte användaren i HSA kommer alltid ett felmeddelande att returneras till klienten (tunn och rik)
- Samma IdP används för autentisering av både tunn och rik klient
9.1. Scenario 1: Användaren startar rik klient ("första" autentiseringen för arbetspasset, dvs inget uppdrag finns valt)
- Användaren startar rik klient ("första" autentiseringen för arbetspasset, dvs inget uppdrag finns valt)
- Saknar användaren medarbetaruppdrag fås en bas-biljett.
- Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
- Har användaren fler än 1 medarbetarupppdrag fås en bas-biljett.
- Om den rika klienten inte kräver uppdragsbiljett är "autentiseringen" klar och applikationen kan användas.
- Om den rika klienten kräver uppdrags-biljett behöver följande göras:
- Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
- Om användaren inte har några uppdrag, presentera felmeddelande för användaren om att uppdrag saknas.
- Om användaren har exakt 1 uppdrag, men det inte ger access till systemet. Presentera felmeddelande till användaren.
- Om användaren har fler än 1 uppdrag, låt användaren/applikationen göra ett uppdragsval med hjälp av uppdragstjänsten, samt gör en ny autentisering för att erhålla uppdrags-biljetten med de valda uppdraget
- Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
9.2. Scenario 2: Användaren gör en inloggning i rik klient med uppdrags-biljett enligt scenario 1, därefter byter uppdrag
- Användaren startar den rika klienten och genomfört ett uppdragsval enligt scenario 1 (dvs användaren har fler än ett uppdrag)
- Efter att ha jobbat aktivt ett tag (4h) i den rika klienten (utan att ha startat någon annan applikation/webbapplikation), vill användaren byta uppdrag i applikationen för att t.ex. göra administrativa saker vilket kräver ett annat medarbetaruppdrag.
- Rika klienten kontaktar Uppdragstjänsten, om användaren har fler än 1 uppdrag, låt användaren/applikationen göra ett uppdragsval med hjälp av uppdragstjänsten.
- Därefter görs en ny autentisering av den rika klienten (vid det här laget har sessionen hos IdP timat ut, och en ny autentisering görs (men då netId används kan den cacha pinkoden så användaren slipper knappa in det på nytt.)
- IdP:n hämtar upp vilket uppdrag som användaren ska erhålla ifrån uppdragstjänsten och skapar den efterfrågade uppdrags-biljetten.
- Efter att ha jobbat aktivt ett tag (4h) i den rika klienten (utan att ha startat någon annan applikation/webbapplikation), vill användaren byta uppdrag i applikationen för att t.ex. göra administrativa saker vilket kräver ett annat medarbetaruppdrag.
9.3. Scenario 3: Användaren gör en inloggning i rik klient med uppdrags-biljett enligt scenario 1, stänger applikationen och startar den igen.
- Användaren startar den rika klienten och genomför ett uppdragsval enligt scenario 1 (dvs användaren har fler än ett uppdrag)
- Användaren stänger applikationen.
- Användaren startar den rika klienten på nytt
- Användaren startar den rika klienten direkt efter den stängts ned (efter 5min):
- Idp:n kontaktar uppdragstjänsten och frågar efter det aktiva uppdraget:
- Har användaren 1 uppdrag eller mer, levereras en uppdrags-biljett med det val som gjordes i 1.
- Har inte användaren något uppdrag levereras en bas-biljett
- Om den rika klienten inte kräver uppdragsbiljett är "autentiseringen" klar och applikationen kan användas.
- Om den rika klienten kräver uppdrags-biljett behöver följande göras:
- Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
- Om användaren inte har några uppdrag, presentera felmeddelande för användaren om att uppdrag saknas.
- Om användaren har exakt 1 uppdrag, och uppdrags-biljetten inte ger access till systemet. Presentera felmeddelande till användaren.
- Om användaren har fler än 1 uppdrag, låt användaren/applikationen göra ett uppdragsval med hjälp av uppdragstjänsten, samt gör en ny autentisering för att erhålla uppdrags-biljetten med det valda uppdraget
- Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
- Idp:n kontaktar uppdragstjänsten och frågar efter det aktiva uppdraget:
- Användaren startar den rika klienten efter att ha väntat mer än 12h (dvs startar applikationen nästa dag)
- Idp:n kontaktar uppdragstjänsten och frågar om det finns ett "aktivt" uppdrag för användaren. Då det gått 12h sedan senaste uppdragsvalet gjordes, finns inget aktivt uppdrag utan en ny autentisering/uppdragsval görs enligt:
- Saknar användaren medarbetaruppdrag fås en bas-biljett.
- Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
- Har användaren fler än 1 medarbetarupppdrag fås en bas-biljett.
- Om den rika klienten inte kräver uppdragsbiljett är "autentiseringen" klar och applikationen kan användas.
- Om den rika klienten kräver uppdrags-biljett behöver följande göras:
- Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
- Om användaren inte har några uppdrag, presentera felmeddelande för användaren om att uppdrag saknas.
- Om användaren har exakt 1 uppdrag, men det inte ger access till systemet. Presentera felmeddelande till användaren.
- Om användaren har fler än 1 uppdrag, låt användaren/applikationen göra ett uppdragsval med hjälp av uppdragstjänsten, samt gör en ny autentisering för att erhålla uppdrags-biljetten med de valda uppdraget
- Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
- Idp:n kontaktar uppdragstjänsten och frågar om det finns ett "aktivt" uppdrag för användaren. Då det gått 12h sedan senaste uppdragsvalet gjordes, finns inget aktivt uppdrag utan en ny autentisering/uppdragsval görs enligt:
- Användaren startar den rika klienten direkt efter den stängts ned (efter 5min):
9.4. Scenario 4: Användaren gör en inloggning i rik klient utan krav på uppdrags-biljett enligt scenario 1, därefter startar tunn klient
- Användaren startar rik klient (enligt scenario 1) utan att göra ett uppdragsval.
- Därefter startar användaren en tunn klient
- Saknar användaren medarbetaruppdrag skapas en bas-biljett.
- Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
- Har användaren fler än 1 medarbetaruppdrag presenteras ett uppdragsval för användaren där det senast valda uppdraget finns förvalt (om det finns).. Efter att användaren valt uppdrag, meddelas uppdragstjänsten vilket som aktivt valts och därefter levereras en uppdrags-biljett till den tunna klienten.
9.5. Scenario 5 Användaren gör en inloggning i tunn klient ("första" autentiseringen för arbetspasset, dvs inget uppdrag finns valt sedan tidigare)
- Användaren startar en tunn klient och gör en autentisering
- Saknar användaren medarbetaruppdrag skapas en bas-biljett.
- Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
- Har användaren fler än 1 medarbetaruppdrag presenteras ett uppdragsval för användaren där det senast valda uppdraget finns förvalt (om det finns). Efter att användaren valt uppdrag, meddelas uppdragstjänsten vilket som aktivt valts och därefter levereras en uppdrags-biljett till den tunna klienten.
9.6. Scenario 6 Användaren gör en inloggning i tunn klient scenario 5, därefter byter uppdrag
- Användaren startar den tunna klienten och genomför en autentisering enligt scenario 5
- Efter att ha jobbat aktivt ett tag (4h) i den tunna klienten (utan att ha startat någon annan applikation/webbapplikation), vill användaren byta uppdrag i applikationen för att t.ex. göra administrativa saker vilket kräver ett annat medarbetaruppdrag.
- Den tunna klienten gör en SingleLogOut (SLO) för att på så vis meddela IdP:n att användarens session (och användarens aktiva uppdragsval) ska sluta gälla.
- IdP:n kontaktar Uppdragstjänsten och meddelar att uppdragsval ska göras vid nästa autentiseringen. Därefter görs SLO mot alla anslutna SP:ar för att till sist svara den initierade tunna klienten att SLO gått bra.
- Den tunna klienten gör på nytt en autentiseringsbegäran till IDP:n
- Saknar användaren medarbetaruppdrag skapas en bas-biljett.
- Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
- Har användaren fler än 1 medarbetaruppdrag presenteras ett uppdragsval för användaren där det senast valda uppdraget finns förvalt (om det finns). Efter att användaren valt uppdrag, meddelas uppdragstjänsten vilket som aktivt valts och därefter levereras en uppdrags-biljett till den tunna klienten.
9.7. Scenario 7 Användaren gör en inloggning i tunn klient enligt scenario 5, stänger webbläsaren och startar webbläsaren/tunna klienten igen.
- Användaren startar den tunna klienten och genomför en autentisering enligt scenario 5.
- Användaren stänger webbläsaren.
- Användaren startar webbläsaren på nytt efter att ha väntat mer än 12h (dvs startar applikationen nästa dag)
- Idp:n kontaktar uppdragstjänsten och frågar om det finns ett "aktivt" uppdrag för användaren. Då det gått 12h sedan senaste uppdragsvalet gjordes, finns inget aktivt uppdrag utan en ny autentisering/uppdragsval görs enligt:
- Saknar användaren medarbetaruppdrag skapas en bas-biljett.
- Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
- Har användaren fler än 1 medarbetaruppdrag presenteras ett uppdragsval för användaren där det senast valda uppdraget finns förvalt (om det finns). Efter att användaren valt uppdrag, meddelas uppdragstjänsten vilket som aktivt valts och därefter levereras en uppdrags-biljett till den tunna klienten
- Idp:n kontaktar uppdragstjänsten och frågar om det finns ett "aktivt" uppdrag för användaren. Då det gått 12h sedan senaste uppdragsvalet gjordes, finns inget aktivt uppdrag utan en ny autentisering/uppdragsval görs enligt:
- Användaren startar webbläsaren på nytt efter att ha väntat 20 sekunder.
- Idp:n kontaktar uppdragstjänsten och frågar om det finns ett "aktivt" uppdrag för användaren. Då det finns ett aktivt uppdrag skapas uppdrags-biljetten direkt (alternativt att en bas-biljett skapas ifall användaren saknar medarbetaruppdrag)
- Användaren startar webbläsaren på nytt efter att ha väntat mer än 12h (dvs startar applikationen nästa dag)
9.8. Scenario 8 Användaren gör en inloggning i tunn klient (enligt scenario 5), och därefter startar rik klient.
Se scenario #5, för att därefter följa scenario #3.
- Användaren startar den tunna klienten och genomför en autentisering enligt scenario 5
- Användaren startar den rika klienten:
- Användaren startar den rika klienten direkt efter att den tunna klienten startats:
- Idp:n kontaktar uppdragstjänsten och frågar efter det aktiva uppdraget:
- Har användaren 1 uppdrag eller mer, levereras en uppdrags-biljett med det val som gjordes i 1.
- Har inte användaren något uppdrag levereras en bas-biljett
- Om den rika klienten inte kräver uppdragsbiljett är "autentiseringen" klar och applikationen kan användas.
- Om den rika klienten kräver uppdrags-biljett behöver följande göras:
- Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
- Om användaren inte har några uppdrag, presentera felmeddelande för användaren om att uppdrag saknas.
- Om användaren har exakt 1 uppdrag, och uppdrags-biljetten inte ger access till systemet. Presentera felmeddelande till användaren.
- Om användaren har fler än 1 uppdrag, och uppdrags-biljetten som levereras inte ger access till systemet behöver applikationen upplysa användaren att den är inloggad med ett uppdrag som ej ger access till applikationen. Applikationen bör sen ge användaren relevanta förslag på åtgärder. Ex begära uppdragsbyte, samt därefter göra en ny autentisering för att erhålla uppdragsbiljetten med det nya uppdraget
- Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
- Idp:n kontaktar uppdragstjänsten och frågar efter det aktiva uppdraget:
- Användaren startar den rika klienten efter att ha väntat mer än 12h (dvs startar applikationen nästa dag)
- Idp:n kontaktar uppdragstjänsten och frågar om det finns ett "aktivt" uppdrag för användaren. Då det gått 12h sedan senaste uppdragsvalet gjordes, finns inget aktivt uppdrag utan en ny autentisering/uppdragsval görs enligt:
- Saknar användaren medarbetaruppdrag fås en bas-biljett.
- Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
- Har användaren fler än 1 medarbetarupppdrag fås en bas-biljett.
- Om den rika klienten inte kräver uppdragsbiljett är "autentiseringen" klar och applikationen kan användas.
- Om den rika klienten kräver uppdrags-biljett behöver följande göras:
- Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
- Om användaren inte har några uppdrag, presentera felmeddelande för användaren om att uppdrag saknas.
- Om användaren har exakt 1 uppdrag, men det inte ger access till systemet. Presentera felmeddelande till användaren.
- Om användaren har fler än 1 uppdrag, låt användaren/applikationen göra ett uppdragsval med hjälp av uppdragstjänsten, samt gör en ny autentisering för att erhålla uppdrags-biljetten med de valda uppdraget
- Idp:n kontaktar uppdragstjänsten och frågar om det finns ett "aktivt" uppdrag för användaren. Då det gått 12h sedan senaste uppdragsvalet gjordes, finns inget aktivt uppdrag utan en ny autentisering/uppdragsval görs enligt:
- Användaren startar den rika klienten direkt efter att den tunna klienten startats:
9.9. Scenario 9 Single Log-out från tunn klient.
10. Uppfyllande av icke-funktionella krav
10.1. Icke-funktionella krav från verksamheten
10.1.1. Svarstider
- Tjänsten ska kunna skala vertikalt och horisontellt för att kunna ge hög tillgänglighet,kapacitet och låga svarstider.
10.1.2. Tillgänglighet
Systemet går att köra i s.k. klustrad miljö, där 1..n noder (server-instanser) körs parallellt med en lastbalanserare som delar lasten dem emellan. För att dela filer såsom konfiguration mellan noderna används en delad diskyta, och för data används bl,a databasen och infinispan.
10.1.2.1. Nationell Säkerhetstjänst
Tillgängligheten på den centrala instansen (Säkerhetstjänsten) är specificerad till 99,8 %.
10.1.2.2. Lokal Säkerhetstjänst
Ansvaras av respektive huvudmans driftorganisation och är inte en del av systemet.
10.2. Icke-funktionella krav från Systemägaren/Förvaltaren
10.2.1. Test
För att underlätta för test finns systemloggning som kan justeras att logga på olika nivåer. Kan konfigureras att logga på nivåerna Trace, Debug, Info, Warning och Error.
10.2.2. Konfigurationsstyrning
Tjänsterna kan konfigureras vid installation men även under drift via Generella konfiguration (GUI).
10.2.3. SLA-övervakning
Tjänsterna övervakas via ett inbyggt övervakningsgränssnitt i java (JMX). Det används till att monitorera tjänsterna för att kunna se status på dessa. Till detta kan larmfunktioner kopplas på specificerade parametrar för att få snabb information vid eventuella fel och hitta värden som inte visar önskat värde.
10.2.4. Ping
Commission Service levereras med en ping-tjänst. Ping är avsett för att användas av tjänsteplattformen för övervakning.
Adress |
---|
https://<server address>/commissionService/PingForConfiguration/1/rivtabp21 |
11. Logisk arkitektur
11.1. Mappning mot signifikanta användningsfall
11.2. Beskrivning av arkitektuellt signifikanta delar av lösningen
Se Signifikanta delar av lösningen.
12. Säkerhet
12.1. Infrastruktursäkerhet
Infrastrukturen för autentiseringstjänsten kräver att full tillgång till applikationsserver och databasserver begränsas. Om tillgång ges till någon av dessa kan användaren komma åt ex.tjänstens nyckelpar och missbruka dessa. Att begränsa åtkomsten löses normalt sett med en brandvägg samt att servrarna skyddas med användarnamn och ett starkt lösenord och att servrarna är skyddade inom låst datahall.
12.2. Riskanalys
12.2.1. 10.2.1. Lokala instanser
Riskerna hanteras av respektive huvudmans egen infrastruktur och är inte en del av systemet.
12.3. Riskminimering i den tekniska lösningen
Riskerna med den tekniska lösningen motverkas genom
- att använda beprövade integrationsmönster och standardiserade tekniker
- att integrationspunkterna är löst kopplade tjänstekontrakt, vilket minskar risk för förvaltningsproblematik
- att arkitekturen medför skalbarhet genom att fler noder kan kopplas in efter behov
- att användagränssnitten baseras på GWT som bl.a förhindrar cross-site-scripting och POSTning av felaktiga formulärer m.m.
12.4. Intrångsskydd
Intrångsskyddet för de lokala installationerna beror på respektive huvudmans egen infrastruktur.
12.5. Insynsskydd (kryptering)
SSL/TLS används i all kommunikation med stödtjänsterna, säkerhetstjänsterna samt HSA.
12.6. Transportförvanskning
SSL/TLS används i all kommunikation med stödtjänsterna, säkerhetstjänsterna samt HSA.
12.7. Presentationskorrekt
Validering sker vid all registrering av data enligt de principer som gäller för respektive data vilket säkerställer att data är korrekt.
12.8. Dataintegritet (Oförvanskat över tid), riktighet
Riktigheten i systemloggar och persistent data (databas) skyddas med hjälp av respektive huvudmans egen infrastruktur och är inte en del av systemet.
12.9. Autentisering (”stark” vid behov enligt infoklassning)
Kopplar till krav vid åtkomst av vårdinformation enligt PDL. Samtliga inloggade användare ska vara starkt autentiserade.
Realiseras genom att inloggning sker med siths-kort eller otp.
12.10. Lagkrav
Se sammanställning i [S8].
12.11. Spårbarhet (verksamhetsloggning)
Autentiseringstjänsten loggar följande händelser (utöver detta loggas det även tekniska systemhändelser). Dessa loggposter ska vara tillgängliga i 3 månader.
- Lyckad autentisering.
- Misslyckad autentisering
- Administration av tjänsten, vem har gjort vad.
- Spärrförfrågan mot OCSP/CRL
- Slagningar mot OTP (om aktuellt)
Lyckad autentisering
- Aktörens valda kreditiv (vid ex. certifikat skall utfärdaren loggas, samt aktörens certifikats serienummer)
- Aktörens identitiet
- Tidpunkt
- Uppdragsval (om aktuellt)
- Egenskaper
Misslyckad autentisering
- Tidpunkt
- Aktörens identitet (om möjligt)
- Orsak
Administration av tjänsten (t.ex. inläsning av nytt metadata)
- Aktörens identifikation
- Berörd resurs
- Meddelande (vad har gjorts)
- Tidpunkt
Spärrförfrågan mot OCSP/CRL
- OCSP alt CRL address
- Serienummer på aktörens certifikat
- Namn på utfärdare
- OCSP/CRL svar (unknown/trusted/revoked)
Slagning mot OTP
- Tidpunkt
- Aktörens identification (om aktuell)
- Meddelande (vad hände)
13. Informationsmodell
Se [S8] som är styrande.
14. Datamodell
Autentiseringstjänstens datamodell består av lagrat Metadata enligt SAML2.
15. Driftaspekter
(Skalbarhet, Versionshantering, Uppdatering utan avbrott)(Deployment vy)
<tillhör implementering, se dock översikt>
Produkten är skalbara vertikalt och horisontellt, för att möjliggöra kapacitetsökning vid behov.
Produkten kan installeras och driftas under Windows Server 2008 R2, samt RedHat version 5 eller senare.
15.1. Applikationsberoenden
Proukten kräver följande applikationer:
- Java SE 8 – 64-bit
- MySQL Server version 5.6 eller högre – 64-bit
- MongoDB 3.4
15.2. Detaljerad information
Ej specificerat.
15.3. Produktionssättning och överlämning till förvaltning
För mer information se dokumentation för installation och administration.
16. Följsamhet mot T-bokens styrande principer
16.1.1. IT2: Informationssäkerhet | |
Förutsättningar att uppfylla | Uppfyllnad |
Verksamhetskritiskt IT-stöd designas för att möta verksamhetens krav på tillgänglighet vid frånfall av ett externt beroende. Ju fler beroenden till andra komponenters tillgänglighet, desto lägre egen tillgänglighet. | Säkerhetstjänsterna är designade för dubblerade instanser för fail-over vid problem med hårdvara. Det finns olika möjligheter att driftsätta säkerhetstjänsterna, antingen i lokal eller nationell regi för att maximera tillgängligheten efter behov. Ett grundläggande krav är att användaren kan loggas in på ett säkert sätt med korrekta rättigheter från nationell katalogtjänst. För SITHS-korten finns reservkortsrutiner som kan användas vid borttappade eller trasiga kort |
Verksamhetskritiska nationella stödtjänster (t.ex. tillgång till behörighetsstyrande information) erbjuder möjlighet till lokala instanser som med tillräcklig aktualitet hålls uppdaterade med nationell master. | Autentiseringstjänst kan vid behov sättas upp som lokal instans. Tillgång till HSA-data lokalt torde stödjas genom möjligheterna till distribuerad kataloghantering. Detta kräver också att HSA-tjänsten implementeras lokalt. |
Krav mellan integrerande parter regleras genom integrationsavtal. Integrationsavtal är det avtal där informationsägaren godkänner att en ett visst system får agera mot information genom ett visst tjänstekontrakt. Exempelvis skall enligt integrationsprocessen för den nationella tjänsteplattformen ett avtalsnummer för ett integrationsavtal registreras i samband med att man "öppnar dörren" för en viss tjänstekonsument mot en viss kombination av informationsägare och tjänstekontrakt. | Tillämpas för - HSA-integrationen genom HSA-RIVTA - Säkerhetstjänster genom integrationsavtal |
Arkitekturen måste möjliggöra tillräcklig tillgänglighet vid flera samverkande system. | Uppfylls genom design för hög tillgänglighet enligt ovan samt möjlighet till lokal implementation. |
En sammantagen tolkning av tillämpliga lagar och förordningars konsekvenser för teknisk realisering av informationsfångst, utbyte och lagring. | Se RIV-specifikation PDLiP [S8]. |
Förutsättningar för spårbarhet etableras i form av loggningsregler för komponenter som deltar i säkert informationsutbyte. | Se kapitel 12.11 |
Interoperabla, internationellt beprövade och för leverantörer tillgängliga standarder tillämpas för kommunikation mellan parter som har upprättat tillit. | Uppfylls för stödtjänsterna genom nyttjande av - tekniska profilen RIV-TA BP 2.1
För webbklienter som ingår nyttjas för autentisering, SSO och auktorisation: - SSL/TLS - SAMBI SAML specification [S9] |
16.1.2. IT3: Nationell funktionell skalbarhet | |
Förutsättningar att uppfylla | Uppfyllnad |
Nationella tjänstekontrakt definieras med nationell täckning som funktionell omfattning. Det är möjligt för ett centraliserat verksamhetssystem som användas av alla verksamheter i Sverige att realisera varje standardiserat tjänstekontrakt. Det får inte finnas underförstådda funktionella avgränsningar till regioner, kommuner, landsting eller andra organisatoriska avgränsningar i nationella tjänstekontrakt. | Uppfylls (såsom konsument) |
SLA ska definieras för varje tjänstekontrakt. Detta SLA ska ta hänsyn till framtida kapacitet för tjänstekontraktet med avseende på transaktionsvolym, variationer i användningsmönster och krav på tillgänglighet, i kombination med förmåga till kontinuerlig förändring. | Ej relevant |
Integration ska ske över en integrationsinfrastruktur (t.ex. virtualiseringsplattform) som möjliggör uppföljning av tjänsteproducenters fullföljande av SLA. | Uppfylls |
System och e-tjänster som upphandlas kan utökas med fler organisationer som kunder utan krav på infrastrukturella ingrepp (jämför s.k. SaaS) | Uppfylles genom att - Tjänsterna kan delas mellan vårdgivare efter behov genom s k logisk uppdelning. - Stöd för godtycklig vårdgivare i HSA |
16.1.3. IT4: Lös koppling | |
Förutsättningar att uppfylla | Uppfyllnad |
Meddelandeutbyte baseras på att kommunikation etableras utgående från vem som äger informationen som ska konsumeras eller berikas, inte vilket system, plattform, datalager eller tekniskt gränssnitt som informationsägaren för stunden använder för att hantera informationen. Genom centralt administrerad förmedlingstjänst skapas lös koppling mellan informationskonsument och informationsägarens tekniska lösning. |
|
En arkitektur som skapar lös koppling mellan konsumenter och producenter, avseende adressering och standarder för kommunikation. |
|
En nationell integrationspunkt ska kunna erbjudas för varje nationellt standardiserat tjänstekontrakt, som en fasad mot bakomliggande brokiga systemlandskap. |
|
Nationella tjänstekontrakt förvaltas i en nationellt koordinerad förvaltning. |
|
För en process inom vård och omsorg kan flera tjänstekontrakt ingå. Därför är det viktigt att alla tjänstekontrakt baseras på en gemensam referensmodell för informationsstruktur. |
|
Parter som samverkar i enlighet med arkitekturen integrerar med system hos parter som lyder under annan styrning (t.ex. myndigheter, kunder och leverantörer). Det kan leda till att vård- och omsorgsgivare antingen: o Nationellt bryggar informationen (semantisk översättning) eller o Nationellt införlivar externt förvaltat tjänstekontrakt som standard. Observera att semantisk bryggning av information till vårdens referensmodell förutsätter en nationell förvaltning av bryggningstjänster. För att införliva ett externt förvaltat tjänstekontrakt förutsätts en transparent, robust och uthållig tjänstekontraktsförvaltning hos den externa parten. |
|
Befintliga system behöver anpassas till nationella tjänstekontrakt. Detta kan göras av leverantörer direkt i produkten, eller genom fristående integrationskomponenter (”anslutningar”). En anslutning bör ligga nära (logiskt vara en del av) det system som ansluts, oavsett om det är i rollen som konsument eller producent för anslutningen som genomförs. |
|
Interoperabla standarder för meddelandeutbyte tillämpas, så att integration med till exempel en Web Service kan utföras utan att anropande system behöver tillföras en för tjänsteproducenten specialskriven integrationsmodul (s.k. agent). | . |
16.1.4. IT5: Lokalt driven e-tjänsteförsörjning | |
Förutsättningar att uppfylla | Uppfyllnad |
När utveckling av källkod är en del av en tjänsteleverans skall följande beaktas: o Alla leveranser tillgängliggörs under öppen källkodslicens. Valet av licensformer samordnas nationellt genom rekommendationer. o Utvecklingen bedrivs från start i en allmänt tillgänglig (över öppna nätverk) projektinfrastruktur där förvaltningsorganisation kan förändras över tiden inom ramen för en kontinuerligt tillgänglig projektinfrastruktur (analogi: ”Projektplatsen för e-tjänsteutveckling”). o Det innebär full insyn och åtkomst för utvecklare till källkod, versionshantering, ärendehantering, stödforum och andra element i en projektinfrastruktur under projektets och förvaltningens hela livscykel. o Upphandlade e-tjänster fungerar på de vanligaste plattformarna hos vårdgivarna och hos nationella driftspartners (Windows, Linux, Unix) t.ex. genom att vara byggda för att exekvera på en s.k. Java virtuell maskin. o Gemensam referensmodell för e-tjänsters interna uppbyggnad stimulerar och förenklar återanvändning och överföring av förvaltningsansvar mellan organisationer.- |
|
Minsta möjliga – men tillräcklig – mängd standarder och stödjande gemensamma grundbultar för nationella e-tjänstekanaler säkerställer att även utvecklingsenheter i mindre organisationer kan bidra med e-tjänster för en integrerad användarupplevelse och att en gemensam back-office för anslutning av huvudmän till e-tjänster finns etablerad. I den mån etablerade standarder med bred tillämpning i kommersiella e-tjänster finns (t.ex. för single-sign-on), bör de användas i syfte att möjliggöra upphandling av hyllprodukter. |
|
Utveckling sker mot globalt dominerande portabilitetsstandarder i de fall mellanvara (applikationsservrar) tillämpas. Det är möjliggöraren för nyttjande av free-ware och lågkostnadsverktyg i organisationer som inte orkar bära tunga licenskostnader för komplexa utvecklingsverktyg och driftsplattformar. |
|
Nationell (eller regional – beroende på sammanhang vård/omsorg) förvaltning är etablerad (t.ex. s.k. Portal Governance), med effektiva processer för att införliva lokalt utvecklade e-tjänster i nationella e-tjänstekanaler. Systematisk och effektiv allokering av resurser för drift är en viktig grundförutsättning. |
|
Genom lokal governance och tillämpning av det nationella regelverket får lokala projekt den stöttning som behövs för att från början bygga in förutsättningar för integration i samordnade (t.ex. nationella) e-tjänstekanaler. |
|
16.1.5. IT6: Samverkan i federation | |
Förutsättningar | Uppfyllnad |
Att gemensamma gränssnitt i alla federativa utbyten finns framtagna och beskrivna, vilket möjliggör kostnadseffektiva och leverantörsneutrala lösningar. |
|
Det behövs organ och processer för att godkänna utgivare av elektroniska identitetsintyg och certifikat som är giltiga i federationen. |
|
Aktörer i olika nät, inklusive öppna nät ska vara välkomna i elektronisk samverkan genom att samverkande komponenter är säkra. |
|
Att Ingående parter i federationen är överens om ett antal gemensamma ståndpunkter: o att stark autentisering likställs med 2-faktors autentisering o att vid samverkan acceptera följande metoder för stark autentisering; eID, PKI med lagring av nyckelpar på SmartCard eller motsvarande och metoder baserade på engångslösenord, antingen genererade i en fysisk enhet eller säkert distribuerad till fysisk enhet o att tillämpa en gemensam certifikat- och utfärdarpolicy, likvärdig med SITHS, som ett minimikrav för egen eller annans PKI o att sträva mot en autentiseringslösning, framför flera olika, för att realisera stark autentisering i den egna organisationen och i federation o att enbart acceptera SAMLv2, eller senare version, vid identitetsfederering samt tydliggöra att det i förekommande fall är det enda sättet att logga in och säkerställa det inte finns någon bakväg in o att tillämpa ett gemensamt ramverk för att ingå i en federation o att tillämpa en gemensam katalogpolicy, med utgångspunkt från HSA policy, som ett minimikrav för egna kataloger o att stäva mot att all gränsöverskridande kommunikation skall vara möjlig både över Sjunet och Internet. Det är den egna organisationen som beslutar vilken tillgänglighet som är tillräcklig för anslutningen o att sträva efter att möjliggöra kontroll av trafik till och från den egna infrastrukturen i en eller få kontrollpunkter o Att utgå från att kommunikation över Internet och Sjunet har ett likvärdigt skyddsbehov |
17. Referenser
17.1. Bilagor
Ref | Dokument ID | Dokument/Beskrivning |
---|---|---|
17.2. Styrande dokument
Ref | Dokument ID | Dokument/Beskrivning |
---|---|---|
S1 | IT-strategi | http://rivta.se/documents/ARK_0022/ |
S2 | T-boken | http://rivta.se/documents/ARK_0019/ |
S3 | RIV | Dokument kan laddas ner från http://www.rivta.se/ |
S4 | ||
S5 | VIT-boken | Dokumentet kan laddas ner från: http://www.inera.se/TJANSTER--PROJEKT/Arkitektur-och-regelverk/ |
S6 | RIV Tekniska Anvisningar | http://www.rivta.se/ |
S7 | Nationella tjänsteplattformen | http://skltp.se/ |
S8 | RIV PDLiP | RIV-specifikation för PDL i praktiken |
S9 | SAMBI SAML Profil | Säkerhetstjänsters (2.18) SAML Profil |
S10 | Driftanvisning | Installationsanvisning för Lokala Säkerhetstjänster: |
S11 | Användarhandbok | Användarhandbok Nationella Säkerhetstjänster |
17.3. Stödjande dokument
Ref | Dokument ID | Dokument/Beskrivning |
---|---|---|
R1 | SAD-mall | Arkitekturledningens mall för SAD |
R2 | RIVTA BP2.1 | RIV Tekniska Anvisningar Basic Profile 2.1 |
R3 | Binära bilagor | RIV Tekniska Anvisningar Binära bilagor |
17.4. Integrationstjänster
I tabellen kan referenser förekomma som inte direkt är nyttjade i tjänsten. Enbart rader refererade i denna SAD nyttjas.
Ref | Dokument ID | Dokument/Beskrivning | ||||||
---|---|---|---|---|---|---|---|---|
T1 | HSA | Uppslag av uppgifter från HSA sker via RIV-kontrakt, men stöd för HSA-WS finns.
| ||||||
T2 | Personuppgifter | Tjänstedomän: riv:masterdata:citizen:citizen https://bitbucket.org/rivta-domains/riv.masterdata.citizen.citizen Tjänstedomän: riv:strategicresourcemanagement:persons:person https://bitbucket.org/rivta-domains/riv.strategicresourcemanagement.persons.person | ||||||
T3 | TK-Logg | Tjänstedomän: riv:ehr:log https://bitbucket.org/rivta-domains/riv.ehr.log Tjänstedomän: riv:informationsecurity:auditing:log https://bitbucket.org/rivta-domains/riv.informationsecurity.auditing.log | ||||||
T4 | TK-Spärr | Tjänstedomän: riv:ehr:blocking https://bitbucket.org/rivta-domains/riv.ehr.blocking Tjänstedomän: riv:informationsecurity:authorization:blocking https://bitbucket.org/rivta-domains/riv.informationsecurity.authorization.blocking | ||||||
T6 | TK-Samtycke | Tjänstedomän: riv:ehr:patientconsent https://bitbucket.org/rivta-domains/riv.ehr.patientconsent Tjänstedomän: riv:informationsecurity:authorization:consent https://bitbucket.org/rivta-domains/riv.informationsecurity.authorization.consent |
17.5. Plattformsfunktioner
I tabellen kan referenser förekomma som inte direkt är nyttjade i tjänsten. Enbart rader refererade i denna SAD nyttjas.
Ref | Dokument ID | Dokument/Beskrivning |
---|---|---|
P1 | Säkerhetstjänster | http://www.inera.se/TJANSTER--PROJEKT/Sakerhetstjanster/ Allmän anslutningsdokumentation och förutsättningar för nyttjande. |
P2 | HSA | HSA används i lösningen för att tillhanda kvalitetssäkrade uppgifter om personer och funktioner/system. Befintlig koppling till HSA-tjänsten nyttjas i den webbapplikation som finns för administration av stödtjänsterna. Stödtjänsten själv nyttjar inte HSA-tjänsten. |
P3 | SITHS | SITHS-kort används för säker inloggning, ger stöd för stark autentisering av användare. |
P4 | Tjänsteplattform | Tjänsteplattform, lokalt såväl som nationellt, är en möjlig förmedlare av tjänsterna. Tillför möjlighet till internetanslutning samt förenkling av integrationspunkterna och vägval för att hitta viss producerande tjänst. |