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

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 autentiersingsbegäran att medarbetarval inte skal 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) 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.

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 [Copy of 2.15 SAD - Autentiseringstjänsten#S2].
• Följsamhet mot de OASIS standarder som berörs
• Följsamhet mot ”SAMBI SAML Profil” [Copy of 2.15 SAD - Autentiseringstjänsten#S9].
• 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” [Copy of 2.15 SAD - Autentiseringstjänsten#S9], gällande dessa.
• Tjänstegränssnitten transportsäkras enligt ”SAMBI SAML Profil” [Copy of 2.15 SAD - Autentiseringstjänsten#S9].
• Tjänsten baserar sin förlitandemodell på information som förmedlas med hjälp av SAML Metadata, enligt ”SAMBI SAML Profil” [Copy of 2.15 SAD - Autentiseringstjänsten#S9]. 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” [Copy of 2.15 SAD - Autentiseringstjänsten#S10] .
• 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
• Om användaren har exakt 1 medarbetaruppdrag ska SAML-biljetten alltid innehålla alla egenskaper för det uppdraget.
• Har användaren fler än 1 medarbetaruppdrag kan IdP:n utfärda antingen en bas-biljett eller en uppdrags-biljett beroende på scenario. Se exempel nedan.
• 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” [Copy of 2.15 SAD - Autentiseringstjänsten#S9].

4. Teknisk lösning

4.1. Översikt – Autentiseringstjänst

Bilden nedan visar översiktligt beroenden till andra system och tjänster som Autentiseringstjänsten har.

Figur 1 Systemberoende till andra system

• HSA-WS 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). Målet är dock att få åtkomst till HSA-information via Tjänstekontrakt när dessa är tillgängliga.
• 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 sex 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.
• Meta Data, 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 [Copy of 2.15 SAD - Autentiseringstjänsten#R2]. 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” [Copy of 2.15 SAD - Autentiseringstjänsten#S9]) 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 presenterars 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 [Copy of 2.15 SAD - Autentiseringstjänsten#S11] .

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” [Copy of 2.15 SAD - Autentiseringstjänsten#S9]) 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” [Copy of 2.15 SAD - Autentiseringstjänsten#S9].

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/oasis-wss-saml-token-profile-1.1#SAMLV2.0).

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:

• http://www.w3.org/2000/09/xmldsig#rsa-sha1
• http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

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)

1. Användaren startar rik klient ("första" autentiseringen för arbetspasset, dvs inget uppdrag finns valt)
   1. Saknar användaren medarbetaruppdrag fås en bas-biljett.
   2. Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
   3. Har användaren fler än 1 medarbetarupppdrag fås en bas-biljett.
2. Om den rika klienten inte kräver uppdragsbiljett är "autentiseringen" klar och applikationen kan användas.
3. Om den rika klienten kräver uppdrags-biljett behöver följande göras:
   1. Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
      1. Om användaren inte har några uppdrag, presentera felmeddelande för användaren om att uppdrag saknas.
      2. Om användaren har exakt 1 uppdrag, men det inte ger access till systemet. Presentera felmeddelande till användaren.
      3. 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

9.2. Scenario 2: Användaren gör en inloggning i rik klient med uppdrags-biljett enligt scenario 1, därefter byter uppdrag

1. Användaren startar den rika klienten och genomfört ett uppdragsval enligt scenario 1 (dvs användaren har fler än ett uppdrag)
   1. 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.
      1. 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.
      2. 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.)
         1. IdP:n hämtar upp vilket uppdrag som användaren ska erhålla ifrån uppdragstjänsten och skapar den efterfrågade uppdrags-biljetten.

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.

1. Användaren startar den rika klienten och genomför ett uppdragsval enligt scenario 1 (dvs användaren har fler än ett uppdrag)
2. Användaren stänger applikationen.
3. Användaren startar den rika klienten på nytt
   1. Användaren startar den rika klienten direkt efter den stängts ned (efter 5min):
      1. Idp:n kontaktar uppdragstjänsten och frågar efter det aktiva uppdraget:
         
         1. Har användaren 1 uppdrag eller mer, levereras en uppdrags-biljett med det val som gjordes i 1.
         2. Har inte användaren något uppdrag levereras en bas-biljett
      2. Om den rika klienten inte kräver uppdragsbiljett är "autentiseringen" klar och applikationen kan användas.
      3. Om den rika klienten kräver uppdrags-biljett behöver följande göras:
         1. 1. Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
               1. Om användaren inte har några uppdrag, presentera felmeddelande för användaren om att uppdrag saknas.
               2. Om användaren har exakt 1 uppdrag, och uppdrags-biljetten inte ger access till systemet. Presentera felmeddelande till användaren.
               3. 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
      : 
   2. Användaren startar den rika klienten efter att ha väntat mer än 12h (dvs startar applikationen nästa dag)
      1. 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:
         1. Saknar användaren medarbetaruppdrag fås en bas-biljett.
         2. Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
         3. Har användaren fler än 1 medarbetarupppdrag fås en bas-biljett.
      2. Om den rika klienten inte kräver uppdragsbiljett är "autentiseringen" klar och applikationen kan användas.
      3. Om den rika klienten kräver uppdrags-biljett behöver följande göras:
         1. Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
            1. Om användaren inte har några uppdrag, presentera felmeddelande för användaren om att uppdrag saknas.
            2. Om användaren har exakt 1 uppdrag, men det inte ger access till systemet. Presentera felmeddelande till användaren.
            3. 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

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

1. Användaren startar rik klient (enligt scenario 1) utan att göra ett uppdragsval.
2. Därefter startar användaren en tunn klient
   1. Saknar användaren medarbetaruppdrag skapas en bas-biljett.
   2. Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
   3. 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)

1. Användaren startar en tunn klient och gör en autentisering
   1. Saknar användaren medarbetaruppdrag skapas en bas-biljett.
   2. Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
   3. 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

1. Användaren startar den tunna klienten och genomför en autentisering enligt scenario 5
   
   1. 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.
   2. 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.
      1. 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.
2. Den tunna klienten gör på nytt en autentiseringsbegäran till IDP:n
   1. Saknar användaren medarbetaruppdrag skapas en bas-biljett.
   2. Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
   3. 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.

1. Användaren startar den tunna klienten och genomför en autentisering enligt scenario 5.
2. Användaren stänger webbläsaren.
   1. Användaren startar webbläsaren på nytt efter att ha väntat mer än 12h (dvs startar applikationen nästa dag)
      1. 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:
         1. Saknar användaren medarbetaruppdrag skapas en bas-biljett.
         2. Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
         3. 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
   2. Användaren startar webbläsaren på nytt efter att ha väntat 20 sekunder.
      1. 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)

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.

1. Användaren startar den tunna klienten och genomför en autentisering enligt scenario 5
2. Användaren startar den rika klienten:
   1. Användaren startar den rika klienten direkt efter att den tunna klienten startats:
      1. Idp:n kontaktar uppdragstjänsten och frågar efter det aktiva uppdraget:
         
         1. Har användaren 1 uppdrag eller mer, levereras en uppdrags-biljett med det val som gjordes i 1.
         2. Har inte användaren något uppdrag levereras en bas-biljett
      2. Om den rika klienten inte kräver uppdragsbiljett är "autentiseringen" klar och applikationen kan användas.
      3. Om den rika klienten kräver uppdrags-biljett behöver följande göras:
         1. 1. Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
               1. Om användaren inte har några uppdrag, presentera felmeddelande för användaren om att uppdrag saknas.
               2. Om användaren har exakt 1 uppdrag, och uppdrags-biljetten inte ger access till systemet. Presentera felmeddelande till användaren.
               3. 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
                  
                  
   2. Användaren startar den rika klienten efter att ha väntat mer än 12h (dvs startar applikationen nästa dag)
      1. 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:
         1. 1. Saknar användaren medarbetaruppdrag fås en bas-biljett.
            2. Har användaren exakt 1 medarbetaruppdrag fås en uppdrags-biljett med det uppdraget.
            3. Har användaren fler än 1 medarbetarupppdrag fås en bas-biljett.
      2. Om den rika klienten inte kräver uppdragsbiljett är "autentiseringen" klar och applikationen kan användas.
      3.  Om den rika klienten kräver uppdrags-biljett behöver följande göras:
         1. 1. Kontakta Uppdragstjänsten för att se hur många uppdrag användaren har:
            2. Om användaren inte har några uppdrag, presentera felmeddelande för användaren om att uppdrag saknas.
            3. Om användaren har exakt 1 uppdrag, men det inte ger access till systemet. Presentera felmeddelande till användaren.
            4. 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

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.

11. Logisk arkitektur

11.1. Mappning mot signifikanta användningsfall

Se Användningsfallsöversikt.

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. Transportofö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 [Copy of 2.15 SAD - Autentiseringstjänsten#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 [Copy of 2.15 SAD - Autentiseringstjänsten#S8] som är styrande.

14. Datamodell

Här ges ett urval av datatyper som används i tjänsterna. För mer information se [T1] och [T2].

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
• JCE - Java Cryptography Extension
• MySQL Server version 5.6 – 64-bit

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

17. Referenser

17.1. Bilagor

17.2. Styrande dokument

17.3. Stödjande dokument

17.4. Nyttjade integrationstjänster

17.5. Nyttjade plattformsfunktioner