1. Inledning

1.1. Nomenklatur

1.2. Syfte

IdP:n syftar till stödja e-tjänster/applikationers behov av s k stark autentisering och behörighetshantering.

• Att tillhandahålla en implementation av en s k Identity Provider, IdP, enligt referensarkitekturen för identitet och åtkomst [S1].
• Att tillhandahålla en nationell tjänst som ger ett gemensamt sätt att utföra autentisering och tillhandahålla underlag för behörighetsstyrning för 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.3. Målgrupp

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

1.4. Referenser 

1.4.1. Nyttjade plattformsfunktioner

1.4.2. Nyttjade tjänstekontrakt

1.4.3. Styrande dokument 

1.4.4. Stödjande dokumentation

2. Arkitekturell översikt

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 användare som vill autentisera sig via tjänsten gör detta genom att presentera ett personligt eID. Detta kan exempelvis vara ett SITHS-certifikat. Aktörens e-id kan förmedlas med olika protokoll avsedda för autentisering (mTLS, WebAuthn eller dylikt). 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).

Ö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 eID, av en för IdP:n 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 IdP.
4. IdP kräver att aktören autentiserar sig genom någon av de tillgängliga autentiseringsmetoderna.
5. Aktören identifierar sig med sitt e-id genom att ange tillhörande legitimeringskod eller liknande (t.ex. fingeravtryck eller annan biometri) i sin autentiseringsklient..
6. IdP:n säkerstä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 avgör access till aktören.

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

Arkitekturen är baserad på standarderna SAML2.0 samt OIDC. E-tjänsterna kopplar sitt säkerhetslager (SP/RP) mot IdP via något av dessa protokoll. Själva IdP:n ä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 IdP, 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 IdP.}

IdP 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 IdP 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" [S1]
• Följsamhet mot Nationella IT-strategin, enligt T-Boken [S2]
• Följsamhet mot de OASIS standarder som berörs [S7]
• Följsamhet mot ”SAMBI SAML Profil” [S6]
• Följsamhet mot SAMBI:s tekniska ramverk [S5]
• Följsamhet mot OpenID Connect [S4]
• Följsamhet mot HEART profile for OpenID Connect [S4]

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

Idp:n har flera olika autentiseringsmetoder som kan användas. Dessa konfigureras per SP. Om det enbart finns 1 metod görs valet implicit och flödet fortsätter automatiskt.

Följande autentiseringsmetoder är för närvarande aktuella i IdP:

• mTLS via Net iD Enterprise
• SITHS eID på annan enhet
• SITHS eID på samma enhet

Se Guide till IdP för mer information om de olika autentiseringsmetoderna. Eventuellt skillnader i autentiseringsflödena illustreras i användningsfallen nedan.

4.3.1. MTLS

Användarens certifikat förmedlas via browser integration. En klient läser kortet och publicerar certet till browsern som använder det för att skapa en MTLS koppling till servern via browsern.

4.3.2. Autentiseringstjänst OOB

Autentisering baserad på OOB-teknik (Out Of Band) sker via Autentiseringstjänsten [P3]. Två typer av OOB-autentisering exponeras via IdP:n, autentisering med samma enhet och autentisering med annan enhet. Skillnaden mellan de två är enbart i hur IdP:n exponerar användarklienten. Vid samma enhet kommer IdP:n trigga uppstart av klientapplikation via webbläsaren och custom-protokollet "siths://". Vid annan enhet kommer IdP:n att visa en QR kod och användaren får själv starta sin applikation.

Se dokumentationen för Autentiseringstjänsten [P3] för mer detaljer.

4.4. Logisk realisering av signifikanta användningsfall

4.4.1. AF1 - Administrera tjänsten

4.4.1.1. Textuell beskrivning

IdP tillhandahåller ett GUI för administration. Dessa beskrivs utförligt i Användarhandboken. 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.4.1.2. Realisering

En aktör med behörighet vill administrera IdP.

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.4.2. AF2 - Autentisera aktör

4.4.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.4.2.2. Realisering

4.4.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.4.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.4.3. AF3 - Logga ut aktör

4.4.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.4.3.2.

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

4.4.4. AF4 - Revokera tokens

4.4.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.4.4.2. Realisering

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

4.4.5. AF5 - Biljettväxling

4.4.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 IdP:ns biljettväxlings-endpoint.
3. IdP säkerställer att biljettväxling får ske.
4. IdP 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 IdP.
   2. API-tjänsten returnerar ett svar

4.4.5.2. Realisering

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

4.4.6. Elektronisk underskrift

4.4.6.1. Introduktion

IdP:n har stöd för anslutning till Underskriftstjänst [P4] som följer SwedenConnects SAML-profil för underskrift [S11]. Detta innebär att kunder kan ansluta mot integrerande underskrifttjänst och utnyttja IdP:n för autentisering mot denna.
Underskrifter kan endast ske via autentiseringsmetoderna som nyttjar SITHS eID via Autentiseringstjänsten [P3].

4.4.6.2. Relevanta skillnader mot inloggningsflödet

Flödet för underskrift är i stort identiskt med flödet för Autentisering med SITHS eID. Följande listar relevanta skillnader:

• Enbart SAML stöds vid underskrift.
• Underskriftsfunktionaliteten förlitar sig på Autentiseringstjänsten och SITHS eID-klienterna, och funkar alltså inte med mTLS-inloggning via Net iD Enterprise.
• Metadata för underskriftsintegration publiceras separat och innehåller en delmängd av attributen som IdP:n kan producera.
• Underskrift följer standarden för Sweden Connect [S10] istället för Sambi [S7] .
• Det publiceras flera endpoints för underskrifts SAML-anrop, en för varje autentiseringsmetod. Detta för att kunna välja autentiseringsmetod redan vid anropet då det inte är önskvärt att användaren får val vid just underskrift.
• Vid anropet till IdP skickas en personidentifierare med som måste matcha identiteten som sedan autentiseras. Denna identifierare skickas vidare till Autentiseringstjänsten och efter autentisering valideras den i IdP.
• Vid anropet skickas ett meddelande om vad som ska undertecknas med, detta MÅSTE visas upp för användaren. Detta meddelande skickas vidare till Autentiseringstjänsten för vidare förmedling till autentiseringsklienterna.

5. Icke-funktionella krav

Icke-funktionella krav

6. Teknisk lösning

Teknisk lösning

7. Säkerhet

Säkerhet

8. Informationshantering

8.1. Domäninformationsmodell

IdP har ingen egen domäninformationstabell.

8.2. Informationens ursprung

8.2.1. Information som konsumeras

Information om egenskaper som förmedlas via IdP hämtas från nationell eller regional kataloger. Informationen hämtas från HSA via definerade tjänstekontrakt se 1.4.2.

Information om identitet som förmedlas via IdP hämtas antingen från Katalogtjänst HSA eller från certifikat utfärdat av betrodd certifikatsutfärdare, såsom SITHS CA.

8.2.2. Information som skapas

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

9. Driftaspekter

Driftaspekter