Autentisering

Kontroll av uppgiven identitet, t.ex. vid inloggning, vid kommunikation mellan två system eller vid utväxling av meddelande mellan användare

Auktorisation / Behörighetskontroll

Kontroll av att en Autentiserad entitet (person eller system) är behörig att komma åt en begärd resurs.

e-legitimation, e-identitet, e-id

Elektronisk legitimation. Används för att identifiera en person eller ett system. T.ex. ett användarcertifikat på ett smartkort.

SITHS

Identifieringstjänst SITHS, en säkerhetslösning som används för att utfärda elektroniska identitetshandlingar (e-identiteter) till både personer och system.

SITHS eID

Den nya generationen SITHS e-identiteter, kan finnas både på smartkort och på mobila enheter.

Mobilt SITHS eID

SITHS eID på mobila enheter.

SITHS eID-klienter

SITHS eID Windowsklient och SITHS eID Mobilklient. Användarklienter på dator repektive mobila enheter som låter användare använda SITHS eID på kort eller i en mobil enhet för legitimation och underskrift.

CA (Certification Authority)

Certifikatutfärdare. System som utfärdar certifikat för användare och system.

OCSP/CRL

Protokoll för revokeringskontroll av certifikat.

PKCS#11

Kryptografisk standard som definierar ett gränssnitt för hantering av kryptografiska nycklar.

LoA, Tillitsnivå

Level of Assurance. Grad av säkerhet och tillförlitlighet för en given e-legitimation. Ju högre tillitsnivå en e-legitimation har desto säkrare är den, både när det gäller teknisk och administrativ säkerhet.

E-tjänst

System som erbjuder en funktionalitet för användare eller andra system.

IdP (Identity Provider)

Infrastrukturkomponent som använder olika metoder för att autentisera användare och förmedla ett identitetsintyg till e-tjänster som använder IdP för autentisering av användare. Ur Autentiseringstjänstens perspektiv agerar IdP en RP.

RP (Relying Party)

Ett system som förlitar sig på ett annat system för någon funktionalitet. Som exempel så kan en e-tjänst agera RP mot en IdP om e-tjänsten använder sig av IdP för autentisering av användare. Men IdP:n kan också i sin tur agera RP mot Autentiseringstjänsten.

SP (Service Provider)

Se begreppet e-tjänst ovan.

AT (Autentiseringstjänsten)

Infrastrukturkomponent som förmedlar autentiseringsbegäran mellan IdP och SITHS eID-klienter, samt förmedlar begäran om certifikatsutfärdande mellan SITHS eID Mobilklient och Utfärdandeportalen.

Utfärdandeportalen

Infrastrukturkomponent som låter användare utfärda Mobilt SITHS eID, och som förmedlar certifikatsbegäran och certifikat till och från CA.

Katalogtjänst HSA

Användarkatalog. Datakälla för information om vårdpersonal, inklusive behörighetsinformation.

P1

SITHS

https://www.inera.se/siths

P2

SITHS eID apparna

https://inera.atlassian.net/wiki/spaces/ST/pages/3475212527/Utgivning+och+anv+ndning+av+SITHS+eID

S1

Webauthn

https://w3c.github.io/webauthn/

S2

FIDO

https://fidoalliance.org/overview/

S3

W3C

https://www.w3.org/

S4

webauthn4j

https://github.com/webauthn4j/webauthn4j

S5

Registrering

https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/WebAuthn_Client_Registration.html

S6

Autentisering

https://developers.yubico.com/WebAuthn/WebAuthn_Developer_Guide/WebAuthn_Client_Authentication.html

S7

ARK_0046

Referensarkitektur - Identitet och åtkomst

R1

RIV-TA

http://rivta.se/documents.html 

R2

swagger

https://swagger.io/

IT2: Informationssäkerhet

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.

Applikationen är utvecklad för att fungera i PaaS miljö (containerbaserad) för att skapa maximal flexibilitet gällande tillgänglighet.

Applikationen tillämpar lös koppling för att integrera komponenter.

• Tjänsten själv (REST)

• Certifikatförmedlare (REST)

Vid bortfall av externa system kan inte certifikat utfärdas men autentisering kommer fortfarande vara möjlig.

Verksamhetskritiska gemensamma 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 gemensam master.

Applikationen är en autentiseringstjänst.

• Lokala instanser kan skapas genom att använda samma paketerade tjänst (container i PaaS miljö, eller anpassad installation av binär) 

Krav mellan integrerade parter måste regleras, informationsägaren ska godkänna att ett visst system får agera mot informationen genom ett visst tjänstekontrakt.

Exempelvis skall enligt integrationsprocessen för den gemensamma tjänsteplattformen ett överenskommelsesnummer för en integrationsöverenskommelse 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.

Anslutning för RP (IdP) gentemot applikationen sker via anslutningsavtal genom Inera.

Arkitekturen måste möjliggöra tillräcklig tillgänglighet vid flera samverkande system.

Applikationen är utformad för en hög tillgänglighet med horisontell skalning i PaaS miljö.

En sammantagen tolkning av tillämpliga lagar och förordningars konsekvenser för teknisk realisering av informationsfångst, utbyte och lagring.

Tjänsten hanterar personuppgifter.

• GDPR tillämpas

Förutsättningar för spårbarhet etableras i form av loggningsregler för komponenter som deltar i säkert informationsutbyte.

Se kapitel: Spårbarhet.

Interoperabla, internationellt beprövade och för leverantörer tillgängliga standarder tillämpas för kommunikation mellan parter som har upprättat tillit.

Applikationen tillämpar standardprotokoll.

• HTTPS/TLS

• FIDO2 Webauthn

IT3: Nationell funktionell skalbarhet

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)

Applikationen är utvecklad för att tillgängliggöras nationellt i form av PaaS.

Lokalt erhålls applikationen som binär (jar-fil). Denna kan köras som den är eller paketeras till exempelvis Docker image för installation i lokal Paas-miljö.

IT4: Lös koppling

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.

Lös koppling tillämpas alltid.

Där möjligt används:

• Nationella tjänsteplattformen

• Nationella tjänstekontrakt

En arkitektur som skapar lös koppling mellan konsumenter och producenter, avseende adressering och standarder för kommunikation.

Följer vedertagna standards. Se kapitel: "Standarder"

En nationell integrationspunkt ska kunna erbjudas för varje nationellt standardiserat tjänstekontrakt, som en fasad mot bakomliggande brokiga systemlandskap.

N/A

Inga tjänstekontrakt tillhandahålls av tjänsten.

Nationella tjänstekontrakt förvaltas i en nationellt koordinerad förvaltning.

N/A

Inga tjänstekontrakt tillhandahålls av tjänsten.

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.

Inga tjänstekontrakt tillhandahålls av tjänsten.

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:

• Nationellt bryggar informationen (semantisk översättning) eller

• 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.

N/A

Inga tjänstekontrakt tillhandahålls av tjänsten.

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.

N/A

Inga tjänstekontrakt tillhandahålls av tjänsten.

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).

Internationella standarder används. Se kapitel: "Standarder"

IT5: Lokalt driven e-tjänsteförsörjning

När utveckling av källkod är en del av en tjänsteleverans skall följande beaktas:

• Alla leveranser tillgängliggörs under öppen källkodslicens. Valet av licensformer samordnas nationellt genom rekommendationer.

• 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”).

• 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.  

• 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.

• Gemensam referensmodell för e-tjänsters interna uppbyggnad stimulerar och förenklar återanvändning och överföring av förvaltningsansvar mellan organisationer.

All dokumentation och källkod tillhörande applikationen återfinns i leverantörens Atlassian Suite. Förvaltnings organisationen har full tillgång till dessa system, och externa parter bereds tillgång vid efterfrågan. Samtliga leverabler kan flyttas över till förvaltningsorganisation då egen infrastruktur är framtagen.

Applikationen är utvecklad i Java och tillhandahålls lokalt i form av en jar binär. Denna kan paketeras till en Docker Image för lokal installation, eller körs direkt som den är. Docker kan exekvera på både Linux och Windows, eller i dedikerad PaaS (ex. OpenShift, Kubernetes osv).

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.

Se kapitel: "Standarder" samt "Teknik och Ramverk"

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.

Se kapitel: "Standarder" samt "Teknik och Ramverk"

För lokala installationer nyttjas Docker.

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.

Applikationen förvaltas av Inera/CGI. Driften hanteras av Ineras driftsleverantör.

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.

Följande regelverk tillämpas:

• Referensarkitektur för identitet och åtkomst [S7]

AF1

Administrera Autentiseringstjänsten

AF2

Utfärda nytt mobilt SITHS eID

AF3

Registrera SITHS eID i Autentiseringstjänsten

AF4

Autentisering