1. Inledning

Autentiseringstjänsten syftar till stödja e-tjänster/applikationers behov av autentisering och behörighetshantering.

Tjänsten är baserad på två standarder, SAML2.0 samt OpenID Connect (OIDC). Dessa kan båda tillgodose tjänstens syfte, men gör så med två olika tekniska ramverk. SAML är den äldre av dessa två och har använts under en längre tid inom vården och de nationella tjänsterna. OIDC är en nyare teknik som bygger på OAuth2 standarden.

En aktör som vill autentisera sig via tjänsten gör detta genom att presentera ett personligt certifikat. Detta kan exempelvis vara ett SITHS certifikat. Aktörens certifikat förmedlas via mutual TLS. Aktörens attribut inhämtas från HSA-katalogen (nationell eller lokal beroende på installation). Identitetsbärare kan vara ett fysiskt kort.

Vid lyckad autentisering erhåller den e-tjänst som begärde autentiseringen att giltigt intyg enligt önskad standard (SAML2.0 eller OIDC).

^{Bilden illustrerar ett autentiseringsflöde med tillhörande tjänsteintegrationer.}

Övergripande flöde

Personal vill nyttja en e-tjänst som kräver autentisering och behörighet.

1. Aktören måste vid ett tidigare tillfälle ha erhållit ett personligt certifikat, av en för autentiseringstjänsten pålitlig utfärdare.
2. Aktören försöker ansluta till e-tjänsten.
3. E-tjänsten kräver autentisering av aktören via Autentiseringstjänsten.
4. Autentiseringstjänsten kräver att aktören identifierar sig. Detta sker via mutual TLS.
5. Aktören identifierar sig med sitt certifikat och anger tillhörande pin-kod i applikationen NetID Enterprise.
6. IDP:n säkerhetsställer att certifikatet är giltigt.
7. Personliga och behörighetsstyrande attribut inhämtas via HSA-katalogen (genom RIV-TA tjänster).
8. Intyg i form av SAML-assertion eller ID-token förmedlas till e-tjänsten som behörighetskontrollerar och ger access till aktören.

1.1. Syfte

• Att tillhandahålla en implementation av "referensarkitekturen för behörighet och åtkomst".
• Att tillhandahålla en nationell tjänst som ger ett gemensamt sätt att utföra autentisering och behörighetsstyrning för nationella e-tjänster.
• Att tillhandahålla en tjänst till regionala och lokala intressenter som vill installera och drifta en egen instans av tjänsten.
• Att på ett enhetligt, och distribuerat sätt, via HSA, kunna administrera behörighetsstyrande attribut.

1.2. Målgrupp

De huvudsakliga målgrupperna för detta dokument är: systemägare, systemförvaltare, systemarkitekter och utvecklingsteam samt Inera arkitektur & regelverk.

1.3. Referenser

1.3.1. Styrande dokument

1.3.2. Stödjande dokumentation

1.3.3. Versionshistorik

2. Arkitekturell översikt

Arkitekturen är baserad på standaderna SAML2.0 samt OIDC. E-tjänsterna kopplar sitt säkerhetslager (SP/RP) mot Autentiseringstjänsten via något av dessa protokoll. Själva Autentiseringstjänsten är dock bara en liten del av hela infrastrukturen för att utföra en autentisering och erhålla behörighetsstyrande attribut. Scopet för denna SAD är enbart Autentiseringstjänsten, men följande delar ingår i infrastrukturen för identitet och åtkomst.

^{Bilden illustrerar de parter som är en del av Identitets och åtkomst integrationerna för Autentiseringstjänsten.}

Autentiseringstjänsten tillhandahåller (vid lyckad autentisering) en SAML-Assertion eller ID-token (beroende på den standard som används av e-tjänsten) innehållande attribut från HSA-katalogen. Detta kan vara attribut kopplade till personen, ett medarbetaruppdrag, eller administrativa uppdrag. E-tjänsten använder sedan dessa attribut för att utföra behörighetskontroll och hantera användarinformation vid exempelvis presentation i dess tjänst eller vid audit-loggning.

Detaljerad information för SAML och OIDC är definierade i:

• SAML-Profil
• OIDC-Profil

Förutom funktion för SAML och OIDC så tillhandahåller Autentiseringstjänsten ett GUI för administration av tjänsten. Se "Administrationsgränssnitt" senare i dokumentet.

2.1. Arkitekturella mål

2.1.1. Mål

• Följsamhet mot "Referensarkitektur för identitet & åtkomst".
• 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)
• Följsamhet mot OpenID Connect
• Följsamhet mot HEART profile for OpenID Connect

2.1.2. Planerade avsteg

Frånsteg från ovan givna mål kan behöva göras för att tillgodose kravställning från Inera, eller i de fall två profiler är motstridiga i sina uppgifter.

2.2. Prioriterade områden

• Skapa en tjänst baserad på etablerade ramverk och tekniker. Detta för att minska långsiktiga förvaltningskostnader och underlätta utvecklingsarbetet.
• Basera tjänsten på standardprotokoll och följa specifikationer med så få avsteg som möjligt.
• Utveckla tjänsten för att fungera i en moduliserad driftmiljö - Paas. Detta för att minimera kostnader, underlätta deploy, möjliggöra anpassad skalning m.m.
• Ej bygga in "onödig" funktionalitet i tjänsten, utan nyttja externa tjänster där de lämpar sig bäst. Exempelvis för övervakning av metrics och logginsamling/sökning. Detta för att minska utvecklings och förvaltningskostnader, samt att externa tjänster oftast har mycket bättre funktionalitet än vad som kan byggas in i applikationen för rimlig kostnad.
• Undvika proprietära lösningar som kan försvåra flytt av förvaltning.

3. Följsamhet till T-boken

3.1. Följsamhet mot T-bokens styrande principer

4. Användningsfall

Här beskrivs systemet ur ett funktionellt perspektiv i form av en användningsfallsmodell i syfte att lyfta fram de funktionella krav som är drivande för arkitekturen.

4.1. Användningsfall - Översikt

^{Schematisk användningsfallsöversikt.}

4.2. Aktörsinformation

4.3. Logisk realisering av signifikanta användningsfall

4.3.1. AF1 - Administrera tjänsten

4.3.1.1. Textuell beskrivning

Autentiseringstjänsten tillhandahåller ett GUI för administration. Dessa beskrivs utförligt i Användahandboken. Nedan sammanfattas de administrativa möjligheter som tillhandahålls i detta GUI.

• Administrera behöriga SAML-klienter
• Administrera behöriga OIDC-klienter
• Administrera pålitliga Certifikatsutfärdare
• Administrera tjänstens Certifikat / Privata Nycklar
• Administrera behörigheter för administratörer av GUI
• Konfigurera kontaktuppgifter för tjänsten

4.3.1.2. Realisering

En aktör med behörighet vill administrera Autentiseringstjänsten.

1. Aktören loggar in i tjänsten, och en förutsättning är att aktören har behörighet genom sina attribut i HSA-katalogen.
2. Aktören är inloggad och utför den tilltänkta administrationen.
3. Aktören loggar ut ur tjänsten.

4.3.2. AF2 - Autentisera aktör

4.3.2.1. Textuell beskrivning

Användningsfallet beskriver hur en användare autentiseras i flödet.

Se Inledning för beskrivning av detta användningsfall.

4.3.2.2. Realisering

4.3.2.2.1. SAML

Flödet visar en Autentisering med SAML. Flödet är inte uttömmande utan visar enbart ett av många alternativ som kan ske under en autentisering. Exempelvis att aktören i detta fall måste ange medarbetaruppdrag i enlighet med begäran från SP, samt att aktören har mer än ett uppdrag att välja.

Likaså är flödet förenklat och visar exempelvis inte revokeringskontroll av certifikat.

4.3.2.2.2. OIDC

Flödet visar en Autentisering med OIDC. Kommentarer för SAML-flödet är applicerbart även i detta flöde.

4.3.3. AF3 - Logga ut aktör

4.3.3.1. Textuell beskrivning

Användningsfallet beskriver hur en utloggning går till inom tjänsten. Användningsfallet består av 2 alternativ.

1. SAML
   1. En inloggad SP skickar ett LogoutRequest (via användarens user-agent) till IdP'n. Detta LogoutRequest måste vara signerat.
   2. Vid ett giltigt request avslutar IdP'n den eventuella IdP-sessionen. Ingen propagering till andra SP/RP i samma IdP session sker.
   3. SSO för tidigare IdP-session är nu avslutad och ny AuthnRequest kommer resulterar i ny inloggning, och ny IdP-session.
   4. LogoutResponse returneras till SP i enlighet med efterfrågad binding.
   5. SP ansvarar för att avsluta den egna sessionen med användaren.
2. OIDC Logout
   1. En inloggad RP gör en Logout begäran (via användarens user-agent) till IdP'n. I detta anrop skickas idtoken med. Detta anrop görs efter det att aktören loggat ut från RP i enlighet med standard.
   2. Vid en giltig begäran avslutar IdP'n den eventuella IdP-sessionen, samt revokerar id-token, access-token, samt refresh-token som hör till det token som skickades in. Tokens utfärdade till andra RP revokeras ej. Ingen propagering till andra RP/SP i samma IdP session sker.
   3. SSO för tidigare IdP-session är nu avslutad
      
   4. Eventuellt redirectas användaren till en av RP angiven URL, URL:en måste finnas registrerad på servern för att redirekten ska tillåtas.

Dessa två flöden kan sammanfattas med följande:

• Vid en logoutbegäran inom antingen SAML eller OIDC så kommer IdP'n att avsluta IdP-sessionen och förhindra fortsatt SSO. Tokens utfärdade till andra RP fortsätter vara giltiga.

4.3.3.2. Realisering

Flöden nedan representerar de olika scenarion för utloggning som anges ovan.

4.3.4. AF4 - Revokera tokens

4.3.4.1. Textuell beskrivning

Användningsfallet beskriver hur en revokering av token går till inom tjänsten..

1. Token revokering
   1. En RP som har tillgång till en Access Token eller Refresh Token vill revokera denna. En revokeringsbegäran för denna token skickas till IdP'n.
   2. Vid giltig begäran revokerar idP'n det token som ingick i begäran samt eventuella tillhörande tokens (ID Token, Access Token, Refresh Token som utfärdades samtidigt).
   3. Ingen inverkan på den IdP-session som token utfärdades inom sker. Om IdP-sessionen fortfarande är giltig kan SSO fortsatt erhållas.
   4. IdP skickar svar på begäran med statuskod.

Detta flöde kan sammanfattas med följande:

• Vid revokeringsbegäran kommer enbart den/de tokens som hör till begäran att revokeras. Ingen inverkan på användaren IdP-session kommer att ske, och vid giltig IdP-session fortsätter användaren erhålla SSO.

4.3.4.2. Realisering

Flöden nedan representerar de olika scenarion för revokering som anges ovan.

4.3.5. AF5 - Biljettväxling

4.3.5.1. Textuell beskrivning

Biljettväxling beskrivs i RFC7522 och innebär att en E-tjänst med tillgång till en giltig SAML Assertion, kan använda denna för ett erhålla en AccessToken med motsvarande innehåll.

1. En e-tjänst har erhållit en giltig SAML Assertion, men behöver ett åtkomstintyg i form av en access-token för anrop till ett skyddat API.
2. e-tjänsten använder denna Assertion i ett anrop mot autentiseringstjänstens biljettväxlings endpoint.
3. Autentiseringstjänsten säkerställer att biljettväxling får ske.
4. Autentiseringstjänsten tillhandahåller en access, samt refresh-token tillbaka till e-tjänsten
5. e-tjänsten använder access-token gentemot det skyddade API't.
   1. Tjänsten med API't kan eventuellt vilja kontrollera den använda access-token gentemot autentiseringstjänsten.
   2. API-tjänsten returnerar ett svar

4.3.5.2. Realisering

Flödet nedan representerar en biljettväxling för en e-tjänst.

5. Icke-funktionella krav

5.1. Icke-funktionella krav från verksamheten

5.1.1. Svarstider

Ur ett användarperspektiv ingår inte bara Autentiseringstjänstens svarstider i den upplevda svarstiden, utan även den tid det tar att inhämta svar från Nias, HSA samt OCSP/CRL.

5.1.2. Tillgänglighet

Tjänsten är tillgänglig 24/7 på både Sjunet och Internet med en eftersträvad uptime på 99.xxx%.

5.2. Icke-funktionella krav från Systemägaren/Förvaltaren

5.2.1. Test

Tester sker löpande av förvaltningen under utvecklingsfasen. Acceptanstester sker av Inera/NMT, och eventuellt även med tillfrågade kunder.

Exempel på tester som genomförs utifrån behov:

• Förvaltning (CGI)
  • System / Integrationstester
  • Seleniumtester (GUI samt flöden)
  • Prestandatester
  • Regressionstester
• Drift (Basefarm)
  • Failover tester
  • Backup / restore tester
  • Deployment tester
• Kund / tredje part (NMT m.m.)
  • PEN-tester
  • Acceptenstester av kund / tredje part

5.2.2. Konfigurationsstyrning

Hanteras av förvaltningen tillsammans med Basefarm.

5.2.3. SLA-övervakning

Inera Kundservice mäter SLA på inkomna incidenter.

Basefarm mäter tjänstens uptime.

5.2.4. Visning av driftsstatus

Hanteras och presenteras av Basefarm.

6. Teknisk lösning

Autentiseringstjänsten är framtagen för att tillhandahålla en implementation av "Referensarkitektur för identitet & åtkomst", samt ge stöd för framtida krav och implementationer till densamma. Tjänsten bygger på standardprorokollen SAML2.0, OIDC samt OAuth2 och levereras komplett med funktioner för protokollen samt ett administrativt gränsnitt (GUI).

Tjänsten är byggd med Java SE8 och med Spring Boot / Spring Framework.

De ingående delarna i tjänsten kan summeras enligt följande:

• SAML funktionalitet
• OIDC/Oauth2 funktionalitet
• Identifiering av användare via mutual TLS
• Egenskaper via HSA-katalogen
• Autentiseringsgränssnitt
• Administrationsgränssnitt

6.1. Beskrivning av arkitekturellt signifikanta delar av lösningen

6.1.1. Standarder

Tjänstens primära funktion är att tillhandahålla en standardiserad lösning för autentisering och auktorisering i enlighet med internationella standarder. För att åstadkomma detta används följande standarder:

6.1.2. Tekniker och Ramverk

Applikationen är byggd på Java 8 och använder Maven för paketering. Utöver Java 8 SDK används flera tredjeparts bibliotek och ramverk. Dessa är väl etablerade inom branschen och de mest signifikanta beskrivs nedan.

6.1.3. Kodstruktur

6.1.3.1. Autentiseringstjänsten

Den kod som är specifik för Autentiseringstjänsten är indelad i Maven moduler enligt följande.

6.1.3.2. Inera Common bibliotek

Då många av de funktioner som ingår i Autentiseringstjänsten är gemensamma för flera av de tjänster som ingår i förvaltningsobjektet, skapas common bibliotek som tillhandahåller Maven moduler som kan nyttjas av tjänsterna. Dessa byggs som egna moduler och inkluderas som beroenden i applikationen. För common-gui används NPM för distribution. NPM är den vanligaste pakethanteraren för frontend kod.

6.1.3.3. Testning

För att kunna genomföra tester krävs, förutom testerna själva, även mockning av infrastrukturen som Autentiseringstjänster nyttjar. Detta är uppdelat enligt följande.

6.1.4.
Cookies

Autentiseringstjänsten använder sig av Cookies för hantering av sessioner. Detta är en central del av funktionaliteten i applikationen.

Det finns regler gällande "disclaimer" då en applikation nyttjar cookies, men för denna applikation har reglerna tolkats som att detta inte behövs. Detta beslut baseras på EU-direktiv http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm. Eftersom vi inte har cookies från tredje part, och enbart cookies nödvändiga för tjänsten så behövs ingen "disclaimer".

6.1.5. Deployment

6.1.5.1. Redis

Redis används för flyktigt data. Detta är exempelvis:

• HTTP-sessioner
• SSO-sessioner
• Distribuerad cache
• Transactions manager
• Pub/Sub (notifiering till noder)

Denna databas kräver ej backup, och vid eventuell krasch skall systemet själv kunna återhämta sig, om än med inverkan att användare tappar sina sessioner.

Redis kan sättas upp som en singelnod eller som ett sentinelkluster. I driftad miljö hos Basefarm används ett sentinel kluster.

För anslutning mot Redis från Autentiseringstjänsten används 2 olika klienter:

• Lettuce
  • HTTP-sessioner
• Redisson
  • Distribuerad Cache (inkluderar SSO-sessioner)
  • Transaction manager
  • Pub/Sub

Anledning till att två olika klienter används är för att de tillgodoser olika behov och har olika styrkor. I framtida releaser eftersträvas att kunna gå över enbart till en av dessa ( eller annan klient), men det kräver att utveckling i klienterna först sker för att undvika specialanpassningar i Autentiseringstjänsten vilket skulle försvåra uppgraderingar.

Se "Programvaror och Versioner" för aktuell information om version.

6.1.5.2. MongoDB

Persistent data som kräver backup. Detta är exempelvis:

• SAML-klienter
• OIDC-klienter
• Autentiseringstjänst inställningar
• Certifikatsutfärdare
• Privata nycklar och publika certifikat
• Verksamhetsstatistik

MongoDB kan sättas upp som en singelnod eller som ett sentinelkluster. I driftad miljö hos Basefarm används ett sentinel kluster.

Se "Programvaror och Versioner" för aktuell information om version.

6.1.5.3. Applikation

Byggs som "fat-jar" och paketeras som Docker image inom OpenShift. Denna baserar på RHEL 7 med OpenJDK 8.

I den "feta jaren" så ingår all funktionalitet för applikationen, som exempelvis webserver m.m.

6.1.5.4. Lastbalansering

Om Autentiseringstjänsten skall köras med mer än en nod krävs någon form av lastbalansering. Detta kan hanteras av eventuell PaaS såsom OpenShift, eller via fristående applikation såsom Apache eller Nginx. TLS-terminering läggs med fördel i lastbalanseraren, och HTTP används vidare till applikationen.

6.1.5.5. OpenShift

Autentiseringstjänsten är framtagen för att i nationell installation deployas i ett OpenShift kluster. Denna möjlighet finns även för lokala installationer där mottagande driftorganisation har kunskapen själva.

6.1.5.6. Övervakning

Applikationen tillhandahåller endpoints för övervakning. Dels tillhandahålls endpoints för kontroll om tjänsten är igång och svarar på anrop, och dels tillhandahålls Prometheus endpoint där hela applikationens metrics görs tillgängliga.

• Health Endpoint
  • (/actuator/health)
• Liveliness endpoint
  • (/actuator/health)
• Prometheus endpoint
  • (/actuator/prometheus)

Dessa endpoints behörighetstyrs via konfiguration genom att sätta vilka IP adresser/serier som tillåts.

6.1.5.7. Prometheus/Grafana

För insamling av metrics används med fördel Prometheus, som konfigureras för att "skrapa" alla noders Prometheus-endpoint.

För visualisering och larmsättning av metrics används med fördel Grafana som ansluter till Prometheus som en datasource.

Denna uppsättningen kan med fördel användas för övervakning av flera tjänster. I de fall en driftorganisation har andra verktyg för insamling av metrics så kan dessa användas. Enda kravet är ett de kan hantera data på Prometheus-format. Autentiseringstjänsten har inget krav på specifik metricsinsamling.

6.1.5.8. Loggning

I drift hos Basefarm tillhandahåller applikationen sina loggar till "standard-out" i dess individuella docker containers (poddar). Konfiguration av loggnivåer och ouput av loggar sker via extern logback konfigurering. Denna kan ändras i runtime. Med fördel används en loggningsstack för att enkelt kunna söka i en aggregerad loggkälla.

I de fall då loggning till fil är att föredra kan detta konfigureras i logback konfigurationen.

6.1.5.9. Logstack

För aggregering, indexering och visualisering av loggar använda med fördel Logstack (ELK/EFK). Denna består av tre verktyg som tillsammans ger en enkel logghantering. En sådan logstack kan med fördel användas för flera tjänster.

I de fall en driftorganisation har egen loggaggregeringsfunktion så kan denna med fördel användas. Autentiseringstjänsten har inget krav på specifik logginsamling.

6.2. Realisering av användargränssnitt

Tjänstens tillhandahåller användargränssnitt i form av webbapplikation. Denna är uppdelad i två delar, varav den första är den publika delen som används vid autentisering av användare, och den andra är ett internt (skyddat) GUI för administration av tjänsten.

GUI är realiserat via Angular. Användargränssnitten skall följa eKlient. Lägsta version av Internet Explorer som stöds är IE 11. I övrigt stöds evergreen browsers.

6.2.1. Angular "X"

Detta ramverk är framtaget och underhålls av bl.a. Google och används för att utveckla tjänstens frontend. Webbapplikationen skrivs med HTML, CSS och TypeScript. Vid paketering transpileras TypeScript till Javascript. Vid paketering (via Maven) av webbapplikation utförs följande:

• Installera Node.js samt Yarn
  • I de fall de saknas
• Ladda ner NPM paket
  • Feature modules
• Angular Lint
  • Stämmer av att koden är semantiskt korrekt och följer det definierade syntaxreglerna.
• Transpilering
  • Typescript transpileras till Javascript och byggs samman med HTML och CSS.

För ytterligare information om Angular se: https://angular.io/

6.2.2. Autententiseringsgränssnitt

Då en e-tjänst vill autentisera en användare (och SSO inte erhålls) presenteras ett webbgränssnitt för aktören. Dessa gränssnitt är responsiva och fungerar bra både på desktop och mobil-enheter.

Tabellen visar ett urval av de gränssnitt som ingår i autentiseringsflödet.

6.2.3. Administrationsgränssnitt

För att administrera tjänsten loggar en aktör in och med rätt behörighet presenteras ett webbgränssnitt. Gränssnittet är anpassat för desktop browsers.

Detta administrationsgränssnitt är i produktion skyddat med OIDC inloggning via Autentiseringstjänsten själv. Vid nyinstallation av tjänsten krävs konfiguration innan OIDC inloggning kan ske, och i dessa fall kan Autentiseringstjänsten startas med användarnamn/lösenord som inloggningsmetod. Detta återställs efter det att nödvändig konfiguration skett.

Tabellen visar ett urval av de gränssnitt som ingår i administrationsgränssnittet.

6.2.3.1. Funktioner

De administrativa funktioner som kan hanteras av tjänsten är:

6.3. Felhantering

Tjänsten tillhandahåller inga externa gränssnitt i enlighet med RIV-TA. Den felhantering som är aktuell faller inom ramarna för de standarder som implementerats. I detta fall SAML samt OIDC. För mer information om felhantering inom dessa hänvisas till:

• SAML-Profil
• OIDC-Profil

6.4. Integration med omvärlden

Autentiseringstjänsten är beroende av följande externa system:

^{Bilden illustrerar Autentiseringstjänstens externa beroenden.}

6.5. Utveckling & Kodkvalitet

För att upprätthålla kodkvalitet sker utvecklingen med specifika verktyg där samtliga utvecklare använder samma inställningar och arbetar på ett gemensamt sätt. Nedan är ett utdrag av de verktyg och riktlinjer som ligger till grund för utveckling av Autentiseringstjänsten. Detaljerade instruktioner anses inte vara en del av denna SAD utan hanteras utanför i annan förvaltningsdokumentation.

6.5.1. Integrated Development Environment, IDE

De verktyg som används av utvecklare i sitt arbete med källkoden.

6.5.1.1. Spring Tool Suite (Eclipse)

Spring Tool Suite (STS) är en anpassning av Eclipse som är speciellt ämnad för att utveckla applikationer för Spring Framework i allmänhet och Spring Boot i synnerhet. Förutom att vara en fullfjädrad IDE för javautveckling tillför STS anpassningen stöd som underlättar arbetet gentemot Spring. Tillsammans med denna IDE används ett verktyg som heter Lombok. Detta verktyg hjälper till med den kod som normalt sätt benämns som "boilerplate". Med detta menas kod som inte håller någon funktionalitet utan enbart ses som databärare (POJOs). Lombok gör så att enbart fältvariabler behöver deklareras medans resten av koden, såsom getters och setters genereras i runtime. Då verktyget integreras i STS får utvecklare även stöd i compile-time med tillgång till den del av koden som genereras (synlig i outline och vid code-completion).

För att koden skall formateras på ett enhetligt sätt används inställningar i STS för formatering och s.k. save-actions. Formateringen säkerställer att alla utvecklares kod formateras på samma sätt och med save-actions säkerställs det att operationerna utförs redan vid save, och inte kräver några manuella steg. Den formateringsmall som används är framtagen av CGI och är i skrivandes stund i version 2.0.

6.5.1.2. Visual Studio Code

Visual Studio Code är det verktyg som används för utveckling av frontendkoden (Angular). Till Visual Studio Code används verktyg för att jobba med Angular såsom stöd för Typescript, NPM m.m.

Plugins som används till VS Code är TSLint (Rödmarkerar kod som inte följer lint regler).

6.5.2. Repositories

6.5.2.1. Bitbucket

All källkod hanteras i ett GIT-repository, och då via Bitbucket. Denna Bitbucket instans är en av CGI lokalt installerad serverversion och är inte tillgänglig externt.

6.5.2.2. Nexus

Samtliga artefakter som skapas lagras i ett av CGI lokalt installerat Nexus-repository. Detta är inte åtkomligt externt. Förutom att lagra lokalt skapade Maven och Npm artefakter används även Nexus som en proxy för de artefakter som tillhandahålls via exempelvis publika Maven-repositories.

6.5.3. Kodgranskning

För att upprätthålla hög kodkvalitet och minska (undvika att skapa) teknisk skuld krävs Pull-requests för all kod som checkas in, och innan en sådan kan godkännas, måste en godkänd SonarQube analys ha skett. SonarQube analysen sker via en av CGI lokalt installerad SonarQube instans.

Först då både SonarQube och minst en utvecklare godkänt kodändringarna kan dessa mergas in i pågående release-branch.

6.5.4. Automatiska byggen

Alla byggen sker via Bamboo, och vid lyckat bygge deployas nya artefakter till Nexus-repository.

Bamboo används även lokalt för att deploya nya versioner till lokala testmiljöer i OpenShift. Detta sker genom att använda de artefakter som skapats vid tidigare bygge och använda dessa via build / deployconfigurations i OpenShift. CLI verktyget oc används för att integrera med det lokala OpenShift klustret.

7. Säkerhet

7.1. Säkerhetsklassificering av information

Information som hanteras av tjänsten klassas som personuppgift (namn, HSA-id m.m. som inhämtas från HSA).

7.2. Riskanalys

Riskanalys är genomförd tillsammans med Inera, Basefarm och CGI. Dokument och uppföljning sker kontinuerligt. Nedan bild visar de risker som identifierats September 2018.

^{Identifierade risker September 2018.}

Vid nya versioner av tjänsten görs ny riskanalys vid behov.

7.3. Riskminimering i den tekniska lösningen

• Använda etablerade ramverk och tekniker
• Att utforma systemet i linje med T-Bokens referensarkitektur.
• Att använda nationell infrastruktur och stödtjänster.
• Att använda nationella tjänstekontrakt.
• Att applikationen exekverar i en feltolerant driftmiljö
• Att tester utförs av flera parter

7.4. Principer för utveckling av säker programkod

Se kapitel "Utveckling och Kodkvalitet".

7.5. Intrångsskydd

• Tjänsten tillhandahålls via Basefarms OpenShift kluster.
• Skalskydd tillämpas
• Driftmiljön är uppdelad på lastbalansering (ssl-terminering), web/applikationsserver och databasservrar (Redis samt MongoDB).
• Tillgång till miljön är strikt reglerad. Endast driftpersonal har tillgång plattformens miljöer.
• Driftoperatör arbetar enligt ISO27001.
• Extern trafik krypteras.

7.6. Insynsskydd (kryptering)

All extern kommunikation sker via ”Transport Layer Security” för säkert utbyte mellan konsument och producent.

Följande versioner stödjs:

• TLS1.2

7.7. Riktighet

• Information som skickas mellan aktörer som webbklient och applikation Information skyddas under transporten med hjälp av TLS protokollet.
• SOAP/REST tjänster validerar input vid anrop (schema validering samt logik validering).
• Tillgång till plattformens information är behörighetsstyrd.

7.8. Autentisering

”stark” vid behov enligt infoklassning, dvs en tvåfaktorslösning krävs.

Detta innebär i praktiken att Autentiseringstjänstens GUI är skyddat av Autentiseringstjänsten själv via OIDC.

7.9. Lagkrav

7.10. Spårbarhet (loggning)

Se "Spårbarhet - loggning" under "Lagkrav".

8. Nyttjade tjänstekontrakt

9. Nyttjade plattformsfunktioner

10. Informationshantering

10.1. Domäninformationsmodell

Autentiseringstjänsten har ingen egen domäninformationstabell.

10.2. Informationens ursprung

10.2.1. Information som konsumeras

Information om egenskaper som förmedlas via Autentiseringstjänsten hämtas från nationell eller regional kataloger. HSA infrastrukturen används för detta.

Information om identitet som förmedlas via Autentiseringstjänsten hämtas från certifikat utfärdat av pålitlig certifikatsutfärdare. SITHS används för detta.

10.2.2. Information som skapas

Ingen information skapas utan paketeras enbart utifrån ovan nämnda källor.

11. Driftaspekter

11.1. Lösningsöversikt

Autentiseringstjänsten är etablerad i Basefarms OpenShift kluster. Inera har valt att etablera tjänsten som en s.k. PaaS för maximal teknisk flexibilitet samt minimera infrastrukturkostnader.

^{Bilden illustrerar Autentiseringsflöde lösningsöversikt av driftarkitektur.}

11.2. Fysisk miljö

Nationellt hanteras driften av Basefarm. Driftmiljön är baserad på Platform as a Service (PaaS) med OpenShift.

• Applikationen paketeras som en POD (Docker Image)
• Lastbalansering och SSL-terminering hanteras av OpenShift
• Redis hanteras i OpenShift (klustrad)
• MongoDB hanteras på servrar utanför OpenShift (klustrad)
• Tjänsten är tillgänglig på både Internet och Sjunet
• Integration med HSA sker internt inom Basefarms nät
• Externa tjänster är tillgängliga för Autentiseringstjänsten genom utförda portöppningar

11.3. Programvaror och Versioner

11.3.1. För Autentiseringstjänsten

11.3.2. För förvaltning / utveckling

11.4. Detaljerad information

Detaljerad information om driftsmiljön kan läsas i den driftshandbok som förvaltas av tjänstens driftsgrupp (Basefarm).

11.5. Produktionssättning och överlämning till förvaltning

Sker i samråd mellan Inera - Basefarm - CGI.