Inledning

Nomenklatur

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.

Målgrupp

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

Referenser 

Nyttjade plattformsfunktioner

Nyttjade tjänstekontrakt

Styrande dokument 

Stödjande dokumentation

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.

Arkitekturella mål

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]

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.

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.

Följsamhet till T-boken

Följsamhet mot T-bokens styrande principer

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.

Användningsfall - Översikt

^{Schematisk användningsfallsöversikt.}

Aktörsinformation

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.

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.

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.

Logisk realisering av signifikanta användningsfall

AF1 - Administrera tjänsten

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

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.

AF2 - Autentisera aktör

Textuell beskrivning

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

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

Realisering

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 välja ett tjänste-id/medarbetaruppdrag i enlighet med begäran från SP, samt att aktören har mer än ett uppdrag att välja. Likaså att inget tjänste-id, organisationsnummer, personnummer eller orgAffiliation har pekats ut med hjälp av PrincipalSelection för att förenkla inloggningsflödet för en användare.

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

@startuml

hide stereotype

skinparam note {
	BackgroundColor gold
	FontSize 10
}

skinparam sequence {
	
	ArrowColor black
	ArrowFontColor black
	ArrowFontSize 10
	LifeLineBorderColor black
	LifeLineBackgroundColor lightblue
	
	ParticipantBorderColor black
	ParticipantBackgroundColor<<ext>> lightblue
	ParticipantBackgroundColor<<int>> lightgreen
	ParticipantBackgroundColor<<device>> gold
	ParticipantBackgroundColor<<hsa>> lightcoral
	ParticipantFontColor black
	ParticipantFontSize 10
	
	ActorFontSize 10
	ActorBorderColor black
	ActorBackgroundColor gold
	
	
}

box "Client side" #lightgrey
	actor "Personal" as user
	participant "Browser" as ua<<device>>
	participant "Net iD Enterprise" as nie<<device>>
end box

participant "E-tjänst 1 - Backend\n(Client, Relying Party, SP)" as sp1<<ext>>
'participant "E-tjänst 2 - Backend\n(Client, Relying Party, SP)" as sp2<<ext>>
'participant "API\n(Resource Server)" as api<<ext>>

box "Idp" #darkorange
	participant "IdP\n(SAML, OIDC, Oauth2)" as idp<<int>>
	participant "IdP\n(Secure endpoint)" as secure<<int>>
end box

participant "HSA\n(Katalog)" as hsa<<hsa>>


user -> ua: SP URL
activate ua #gold
ua -> sp1: Begär data
activate sp1 #lightblue
sp1 -> ua: Oinloggad aktör\nRedirect med AuthnRequest
ua -> idp: AuthnRequest
activate idp #lightgreen

alt "IdP-session saknas"
	alt	"Metadata hämtas från IdP:n"
		idp -> idp: Läs in e-tjänstens SAML metadata 
	else "Metadata hämtas via URL från e-tjänsten"
		idp -> sp1: Begär e-tjänstens SAML metadata
		sp1 -> idp: Svar med SAML metadata
	end
	idp -> ua: Redirect till säkerhetskanal (mutual TLS)
	ua -> secure: Anslut till IdP:s mTLS-endpoint
	activate secure #lightgreen
	secure -> ua: Krav på autentisering
	ua -> nie: Starta app
	activate nie #gold	
	nie -> user: Begär PIN
	user -> nie: Anger PIN
	nie -> ua: PIN Godkänd\nAnvändarcertifikat
	deactivate nie	
	ua -> secure: Skickar autentiseringsuppgifter
	secure -> ua: Autentiserad, redirect till idP
	deactivate secure
	ua -> idp
	idp -> hsa: Hämta användarinformation
	activate hsa #lightcoral
	hsa -> idp: Svar med användarinformation
	deactivate hsa
	opt "Val av tjänste-id/medarbetaruppdrag krävs"
		idp -> ua: Begär val av tjänste-id/medarbetaruppdrag
		user -> ua: Val av tjänste-id/medarbetaruppdrag
		ua -> idp: Meddela val av tjänste-id/medarbetaruppdrag
	end
	idp -> idp: Skapa IdP-session
end
idp -> ua: SAML response med Assertion
deactivate idp
ua -> sp1: SAML response med Assertion\nAutomatisk POST
sp1 -> sp1: Skapar aktörs-session
sp1 -> ua: Aktör inloggad\nVisa begärt data
deactivate sp1
deactivate ua
	


@enduml

OIDC

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

Nämnvärt i det här fallet är att möjligheten till filtrering (likvärdigt PrincipalSelection för SAML) av tjänste-id, organisationsnummer, personnummer eller orgAffiliation inte synliggjorts i flödet.

@startuml

hide stereotype

skinparam note {
	BackgroundColor gold
	FontSize 10
}

skinparam sequence {
	
	ArrowColor black
	ArrowFontColor black
	ArrowFontSize 10
	LifeLineBorderColor black
	LifeLineBackgroundColor lightblue
	
	ParticipantBorderColor black
	ParticipantBackgroundColor<<ext>> lightblue
	ParticipantBackgroundColor<<int>> lightgreen
	ParticipantBackgroundColor<<device>> gold
	ParticipantBackgroundColor<<hsa>> lightcoral
	ParticipantFontColor black
	ParticipantFontSize 10
	
	ActorFontSize 10
	ActorBorderColor black
	ActorBackgroundColor gold
	
	
}

box "Client side" #lightgrey
	actor "Personal" as user
	participant "SITHS eID Klient\n(Windows eller mobil)" as client<<device>>
	participant "Net iD Enterprise" as nie<<device>>
	participant "Browser" as ua<<device>>
end box

participant "E-tjänst 1 - Backend\n(Client, Relying Party, SP)" as sp1<<ext>>
'participant "E-tjänst 2 - Backend\n(Client, Relying Party, SP)" as sp2<<ext>>
'participant "API\n(Resource Server)" as api<<ext>>
participant "Autentiseringstjänsten" as at<<ext>>

box "IdP" #darkorange
	participant "IdP\n(SAML, OIDC, Oauth2)" as idp<<int>>
	participant "IdP\n(Secure endpoint, mTLS)" as secure<<int>>
end box

participant "HSA\n(Katalog)" as hsa<<hsa>>

user -> ua: SP URL
activate ua #gold
ua -> sp1: Begär data
activate sp1 #lightblue
sp1 -> ua: Oinloggad aktör\nRedirect med AuthnRequest
ua -> idp: AuthnRequest
activate idp #lightgreen
opt "IdP-Session saknas"
	alt "Flera autentiseringsmetoder valbara"
		idp -> ua: Valbara metoder
		user -> ua: Val av metod
	else "Endast en autentiseringsmetod tillgänglig"
		idp -> ua: Redirect till autentiserings-endpoint
	end

	alt "Inloggning med SITHS-kort och Net iD (mTLS)"
		ua -> secure: Anslut till mTLS-endpoint
		activate secure #lightgreen
		secure -> ua: Krav på autentisering	
		ua -> nie: Starta app
		activate nie #gold	
		nie -> user: Begär PIN
		user -> nie: Anger PIN
		nie -> ua: PIN Godkänd\nAnvändarcertifikat
		deactivate nie		
		ua -> secure: Användarcertifikat
		secure -> ua: Autentiserad, redirect till idP
		deactivate secure
		ua -> idp: 
	

	else "Inloggning med SITHS eID på samma enhet"
		ua -> idp: Endpoint för "same_device"
		idp -> at: Inloggningsbegäran med meddelande
		activate at #lightblue
		at -> idp: Autostarttoken
		idp -> ua: Autostarttoken
		ua -> client: Starta klient med autostarttoken
		activate client #gold
		client -> at: Autostarttoken
		at -> client: Autentiseringsbegäran med meddelande
		client -> user: Visa meddelande, begär pinkod
		user -> client: Knappa in pinkod
		client -> at: Autentiseringssvar med användarcertifikat
		deactivate client
		at -> at: Verifier autentiseringssvaret
		idp -> at: Begär status
		at -> idp: Autentiseringssvar med användarcertifikat
		deactivate at
	


	else "Inloggning med SITHS eID på annan enhet"
		ua -> idp: Endpoint för "other_device"
		idp -> at: Inloggningsbegäran med meddelande
		activate at #lightblue
		at -> idp: Autostarttoken
		idp -> ua: Autostarttoken för QR-kod
		ua -> user: Visa QR-kod
		user -> client: Starta mobilklient
		activate client #gold
		client -> ua: Scanna QR-kod
		ua -> client
		client -> at: Autostarttoken
		at -> client: Autentiseringsbegäran med meddelande
		client -> user: Visa meddelande, begär pinkod
		user -> client: Knappa in pinkod
		client -> at: Autentiseringssvar med användarcertifikat
		deactivate client
		at -> at: Verifier autentiseringssvaret
		idp -> at: Begär status
		at -> idp: Autentiseringssvar med användarcertifikat
		deactivate at
	end
	
	idp -> idp: Extrahera användar-id från användarcertifikat
	idp -> hsa: Hämta användarinformation
	activate hsa #lightcoral
	hsa -> idp: Svar med användarinformation
	deactivate hsa  
	opt "Val av tjänste-id/medarbetaruppdrag krävs"
		idp -> ua: Begär val av tjänste-id/medarbetaruppdrag
		user -> ua: Val av tjänste-id/medarbetaruppdrag
		ua -> idp: Meddela val av tjänste-id/medarbetaruppdrag
	end
	idp -> idp: Skapa\nIdP-session, AccessToken,\nIDToken, RefreshToken
end

idp -> ua: Redirect med code för Token
ua -> sp1: Code för Token
sp1 -> idp: Byt code mot tokens
idp -> sp1: Returnera tokens
deactivate idp
sp1 -> sp1: Skapar aktörs-session
sp1 -> ua: Aktör inloggad\nVisa begärt data
deactivate sp1
deactivate ua
	


@enduml

AF3 - Logga ut aktör

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.

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

@startuml

hide stereotype

skinparam note {
	BackgroundColor gold
	FontSize 10
}

skinparam sequence {
	
	ArrowColor black
	ArrowFontColor black
	ArrowFontSize 10
	LifeLineBorderColor black
	LifeLineBackgroundColor lightblue
	
	ParticipantBorderColor black
	ParticipantBackgroundColor<<ext>> lightblue
	ParticipantBackgroundColor<<int>> lightgreen
	ParticipantFontColor black
	ParticipantFontSize 10
	
	ActorFontSize 10
	ActorBorderColor black
	ActorBackgroundColor lightblue
}

actor "Personal\n(Browser)" as ro<<ext>>
participant "E-tjänst 1 - Backend\n(Client, Relying Party, SP)" as sp1<<ext>>
participant "E-tjänst 2 - Backend\n(Client, Relying Party, SP)" as sp2<<ext>>
participant "IdP\n(SAML, OIDC, Oauth2)" as idp<<int>>

note over sp1, sp2: I dessa flöde har sedan tidigare\ntvå inloggningar skett och SSO har erhållits.\nE-tjänst 2 visar att ingen propagering av logout sker.

alt SAML
	activate ro
	ro -> sp1: LogoutRequest
	activate sp1
	sp1 -> ro: LogoutRequest Redirect URL
	ro -> idp: LogoutRequest
	activate idp #lightgreen
	idp -> idp: End IdP Session
	idp -> ro: LogoutResponse POST or Redirect
	deactivate idp
	ro -> sp1: LogoutResponse
	sp1 -> sp1: End user session
	sp1 -> ro: Logged out page
	deactivate sp1
end

alt OIDC
	ro -> sp1: LogoutRequest
	activate sp1
	sp1 -> sp1: End user session
	sp1 -> ro: LogoutRequest Redirect URL
	deactivate sp1
	ro -> idp: LogoutRequest
	activate idp #lightgreen
	idp -> idp: End IdP Session
	idp -> idp: Revoke token in request
	idp -> ro: Redirect to specified URL
	deactivate idp
	deactivate ro
end

@enduml

AF4 - Revokera tokens

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.

Realisering

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

@startuml

hide stereotype

skinparam note {
	BackgroundColor gold
	FontSize 10
}

skinparam sequence {
	
	ArrowColor black
	ArrowFontColor black
	ArrowFontSize 10
	LifeLineBorderColor black
	LifeLineBackgroundColor lightblue
	
	ParticipantBorderColor black
	ParticipantBackgroundColor<<ext>> lightblue
	ParticipantBackgroundColor<<int>> lightgreen
	ParticipantFontColor black
	ParticipantFontSize 10
	
	ActorFontSize 10
	ActorBorderColor black
	ActorBackgroundColor lightblue
}

actor "Personal\n(Browser)" as ro<<ext>>
participant "E-tjänst 1 - Backend\n(Client, Relying Party, SP)" as sp1<<ext>>
participant "E-tjänst 2 - Backend\n(Client, Relying Party, SP)" as sp2<<ext>>
participant "IdP\n(SAML, OIDC, Oauth2)" as idp<<int>>

sp1 -> idp: Revoke token
activate sp1
activate idp #lightgreen
idp -> idp: Revoke token
idp -> sp1: Token revoked response
	
deactivate sp1
deactivate idp

@enduml

AF5 - Biljettväxling

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

Realisering

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

@startuml

hide stereotype

skinparam note {
	BackgroundColor gold
	FontSize 10
}

skinparam sequence {
	
	ArrowColor black
	ArrowFontColor black
	ArrowFontSize 10
	LifeLineBorderColor black
	LifeLineBackgroundColor lightblue
	
	ParticipantBorderColor black
	ParticipantBackgroundColor<<ext>> lightblue
	ParticipantBackgroundColor<<int>> lightgreen
	ParticipantBackgroundColor<<device>> gold
	ParticipantFontColor black
	ParticipantFontSize 10
	
	ActorFontSize 10
	ActorBorderColor black
	ActorBackgroundColor gold
	
	
}

participant "E-tjänst 1 - Backend\n(Client, Relying Party, SP)" as sp1<<ext>>
participant "API\n(Resource Server)" as api<<ext>>
participant "IdP\n(SAML, OIDC, Oauth2)" as idp<<int>>

note over sp1
	SAML Assertion
	har erhållits tidigare
end note

activate sp1
sp1 -> idp: Biljettväxling med giltig Assertion

activate idp
idp -> idp: Kontrollerar att biljettväxling får ske
idp -> sp1: Returnera Access- samt Refresh-tokens
deactivate idp

sp1 -> api: anropa API med Access-token
activate api
alt vid behov
	api -> idp: Kontrollera Access-token
	activate idp
	idp -> api: Status på Access-token
	deactivate idp
end alt
api -> sp1: Returnera svar på API anrop
deactivate api
deactivate sp1

@enduml

AF6 - Elektronisk underskrift

Denna information är låst och behörighetsstyrd. Åtkomst sker genom att expandera fältet nedan efter inloggning om du är behörig

Icke-funktionella krav

Denna information är låst och behörighetsstyrd. Åtkomst sker genom att expandera fältet nedan efter inloggning om du är behörig

Teknisk lösning

Denna information är låst och behörighetsstyrd. Åtkomst sker genom att expandera fältet nedan efter inloggning om du är behörig

Säkerhet

Denna information är låst och behörighetsstyrd. Åtkomst sker genom att expandera fältet nedan efter inloggning om du är behörig

Informationshantering

Domäninformationsmodell

IdP har ingen egen domäninformationstabell.

Informationens ursprung

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.

Information som skapas

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

Driftaspekter

Denna information är låst och behörighetsstyrd. Åtkomst sker genom att expandera fältet nedan efter inloggning om du är behörig