Jämförda versioner

Version Gammal version 5 Ny version Aktuell
Ändringar gjorda av

Stefan Ehlert

Stefan Ehlert

Sparat den

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.


Expandera
titleVisa revisionshistorik


Version

Datum

Utförare

Kommentar

0.1

 

Johan Karlsson

  • Kopierat från IdP 2.5
0.2 Stefan Ehlert
  • Uppdaterat versioner för ramverk och paket
  • Länkat om dokument
1.0 Pietu HammarströmGodkänd



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.

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.

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.

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

Inledning

Nomenklatur

BegreppDefinition
AutentiseringKontroll av uppgiven identitet, t.ex. vid inloggning, vid kommunikation mellan två system eller vid utväxling av meddelande mellan användare
Auktorisation / BehörighetskontrollKontroll av att en Autentiserad entitet (person eller system) är behörig att komma åt en begärd resurs.
e-legitimation, e-identitet, e-idElektronisk legitimation. Används för att identifiera en person eller ett system. T.ex. ett användarcertifikat på ett smartkort.
SITHSIdentifieringstjä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 eIDDen nya generationen SITHS e-identiteter, kan finnas både på smartkort och på mobila enheter.
Mobilt SITHS eIDSITHS eID på mobila enheter.
SITHS eID-klienterSITHS 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/CRLProtokoll för revokeringskontroll av certifikat.
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.
SAMLSecurity Assertion Markup Language – XML-baserat ramverk för skapande och utfärdande av autentiserings- och attribut-information mellan between betrodda system över internet.
OIDCOpenID Connect – internetcentrerat, federerat identitets- och autentiseringsprotokoll utökandes behörighetsramverket OAuth2.0 och det kryptografiskt systemet ’JSON Object Signing and Encryption’ (JOSE)
E-tjänstSystem som erbjuder en funktionalitet för användare eller andra system.
IdP (Identity Provider)Komponent i infrastrukturen som efter godkänd autentisering av en användare, tillhandahåller elektroniska intyg (SAML biljett alternativt ”ID token” inom OIDC) med identitet och attribut tillhörande användaren och/eller hens organisation. Syftar i detta dokument även på OpenID Provider (OP) för OIDC.
SP (Service Provider)E-tjänst som begär och erhåller elektroniska intyg för en användare från en IdP. Oftast en e-tjänst som tillhandahåller funktionalitet och information till användare. Syftar i detta dokument även på Relying Party (RP) för OIDC.
OP (OpenID Provider)OIDC-term. Se IdP.
RP (Relying Party)OIDC-term. Se SP.
Katalogtjänst HSAAnvändarkatalog. Datakälla för information om vårdpersonal, inklusive behörighetsinformation.
AutentiseringstjänstenInfrastrukturkomponent 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ärdandeportalenInfrastrukturkomponent som låter användare utfärda Mobilt SITHS eID, och som förmedlar certifikatsbegäran och certifikat till och från CA.
UnderskriftstjänstenInfrastrukturkomponent som tillhandahåller underskrift för e-tjänster, via IdP, Autentiseringstjänsten och användarnas SITHS eID-klienter.
ClaimOIDC-term. Ett användar- eller autentisreingsattribut som RP efterfrågar i sin autentiseringsbegäran till OP.
ScopeOIDC-term. Omfång eller omfattning av ett eller flera claims.
JWTJSON Web Token, datatyp innehållandes nycklar:värdepar för roll- eller attributbaserade säkerhetsmodeller.

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 
Ankare
refs
refs

Nyttjade plattformsfunktioner

RefDokument IDDokument inom kategori
P1HSA

https://www.inera.se/hsa

HSA används i lösningen för att tillhanda kvalitetssäkrade uppgifter om personer och funktioner/system.
Grundläggande rättighetshetstilldelning utgår från HSA.

P2SITHS

https://www.inera.se/siths

SITHS-kort används för säker inloggning, ger stöd för stark autentisering av användare.

P3Autentiseringstjänsten

Autentiseringstjänst SITHS

P4Underskriftstjänsten/wiki/spaces/UST/pages/3475212609
P5LoA administrationLoA administration


Nyttjade tjänstekontrakt

RefDokument IDDokument inom kategori
T1HSA TK

Nationella tjänstekontrakt (TK) för integration med HSA-katalogen:

infrastructure:directory:authorizationmanagement

  • GetAdminCredentialsForPersonIncludingProtectedPerson
  • GetCredentialsForPersonIncludingProtectedPerson

infrastructure:directory:employee

  • GetEmployeeIncludingProtectedPerson
T2Autentiseringstjänstens
Relying Party API 		Autentiseringstjänstens API-dokumentation (swagger)


Styrande dokument 

Ref

Dokument ID

Dokument länk

Ankare
S1
S1
S1

ARK_0046Referensarkitektur - Identitet och åtkomst
S2ARK_0019Referensarkitektur för vård och omsorg - T-boken Rev. B
S4ARK_0060Referensarkitektur för
elektronisk underskrift och stämpel
S5

SAML2

S6OIDC

Ankare
S7
S7
S7

SAMBIhttps://www.sambi.se/teknik/
S8SAML-profilSAML-Profil
S9OASIShttps://www.oasis-open.org/

Ankare
S10
S10
S10

SwedenConnecthttps://swedenconnect.se/tekniskt-ramverk.html
S11Sweden Connect Deployment Profile (2019-308)Deployment Profile for the Swedish eID Framework


Stödjande dokumentation

Ref

Dokument ID

Dokument/länk

R1

RIV-TA

http://rivta.se/documents.html 





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.

E-tjänsterDe tjänster/system som vill använda IdP för att autentisera sina användare
CertifikatsutfärdareUtfärdar certifikat till användare. Hanterar även revokering av dessa.
Regional HSA FörvaltningFörvaltar lokal HSA-katalog. Replikering till Nationell HSA.
Nationell HSA FörvaltningFörvaltar nationell HSA-katalog. Det är gentemot denna som IdP hämtar användares attribut.
Internetstiftelsen i Sverige (IIS)Ansvarar för federationen SAMBI. IdP kan hämta ner federerat metadata härifrån.
AutentiseringstjänstFörmedlar autentisering med SITHS eID
UtfärdandeportalUtfärdar mobila certifikat för SITHS eID



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:

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

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

IT2: Informationssäkerhet

Förutsättningar att uppfylla

Uppfyllnad

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 (OIDC, SAML, REST)
  • Attributkälla (RIV-TA)

Då applikationen i sig har till uppgift att förmedla identifierande/behörighetsstyrande attribut innebär ett bortfall av externa tjänster att applikationens uppgift inte kan uppfyllas.

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 identifierings- och auktoriseringstjä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.

Applikationen informationsförsörjs via nationella RIV-TA tjänstekontrakt.

Anslutningsprocess för HSA RIV-TA sker via informationsägaren.

Anslutning för e-tjänst 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ö. Respektive tjänsteproducent av tjänstekontrakt skall leverera enligt SLA.

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
  • SAMLv2
  • OIDC 1.0
  • RIV-TA
  • SOAP-WS


IT3: Nationell funktionell skalbarhet

Förutsättningar att uppfylla

Uppfyllnad

Nationella tjänstekontrakt definieras med nationell täckning som funktionell omfattning. Det är möjligt för ett centraliserat verksamhetssystem som användas av alla verksamheter i Sverige att realisera varje standardiserat tjänstekontrakt. Det får inte finnas underförstådda funktionella avgränsningar till regioner, kommuner, landsting eller andra organisatoriska avgränsningar i nationella tjänstekontrakt.

Applikationen informationsförsörjs via nationella tjänstekontrakt (HSA) med SOAP-WS.

SLA ska definieras för varje tjänstekontrakt. Detta SLA ska ta hänsyn till framtida kapacitet för tjänstekontraktet med avseende på transaktionsvolym, variationer i användningsmönster och krav på tillgänglighet, i kombination med förmåga till kontinuerlig förändring.

SLA definieras i TKB som nyttjas.

Övriga SLA’er för Applikationen hanteras av systemförvaltare.

Integration ska ske över en integrationsinfrastruktur (t.ex. virtualiseringsplattform) som möjliggör uppföljning av tjänsteproducenters fullföljande av SLA.

Nationella tjänsteplattformen kan används för informationsförsörjning (HSA).

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

Förutsättningar att uppfylla

Uppfyllnad

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.

SAML, Oauth2 samt OIDC standard följs.

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

Förutsättningar att uppfylla

Uppfyllnad

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 Orange och NoGUICleura.

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:

  • Nationell referensarkitektur tillämpas
  • RIV-TA
  • Referensarkitektur för identitet och åtkomst 


IT6: Samverkan i federation

Förutsättningar

Uppfyllnad

Att gemensamma gränssnitt i alla federativa utbyten finns framtagna och beskrivna, vilket möjliggör kostnadseffektiva och leverantörsneutrala lösningar.

Attributhantering utgår från SAMBI profil.

Det behövs organ och processer för att godkänna utgivare av elektroniska identitetsintyg och certifikat som är giltiga i federationen.

Användare registreras i regionala kataloger (tillgängliggörs via HSA)

SITHS används.

Aktörer i olika nät, inklusive öppna nät ska vara välkomna i elektronisk samverkan genom att samverkande komponenter är säkra.

Infrastrukturen är ansluten till internet och sjunet.

Att Ingående parter i federationen är överens om ett antal gemensamma ståndpunkter:

  • att stark autentisering likställs med 2-faktors autentisering
  • att vid samverkan acceptera följande metoder för stark autentisering; eID, PKI med lagring av nyckelpar på SmartCard eller motsvarande och metoder baserade på engångslösenord, antingen genererade i en fysisk enhet eller säkert distribuerad till fysisk enhet
  • att tillämpa en gemensam certifikat- och utfärdarpolicy, likvärdig med SITHS, som ett minimikrav för egen eller annans PKI
  • att sträva mot en autentiseringslösning, framför flera olika, för att realisera stark autentisering i den egna organisationen och i federation
  • att enbart acceptera SAMLv2, eller senare version, vid identitetsfederering samt tydliggöra att det i förekommande fall är det enda sättet att logga in och säkerställa det inte finns någon bakväg in
  • att tillämpa ett gemensamt ramverk för att ingå i en federation
  • att tillämpa en gemensam katalogpolicy, med utgångspunkt från HSA policy, som ett minimikrav för egna kataloger
  • att sträva mot att all gränsöverskridande kommunikation skall vara möjlig både över Sjunet och Internet. Det är den egna organisationen som beslutar vilken tillgänglighet som är tillräcklig för anslutningen
  • att sträva efter att möjliggöra kontroll av trafik till och från den egna infrastrukturen i en eller få kontrollpunkter
  • Att utgå från att kommunikation över Internet och Sjunet har ett likvärdigt skyddsbehov

Applikationen är en IdP / OP.

Se kapitel: "Standarder"


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

Ref

Användningsfall

AF1

Administrera tjänsten

AF2

Autentisera aktör

AF3Logga ut aktör
AF4Revokera tokens
AF5Biljettväxling
AF6

Elektronisk underskrift


Schematisk användningsfallsöversikt.

Aktörsinformation

AktörBeskrivning

Personal

Användaren som använder en e-tjänst.
E-tjänstE-tjänsten använder IdP för att autentisera och auktorisera personal.
Katalogtjänst (HSA)Informationskälla för personliga och behörighetsgrundande egenskaper (behörighetsroller).
SystemförvaltarePerson som administrerar IdP. Aktiverare-tjänster som skall använda IdP.

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:

  • SITHS eID på annan enhet (SITHS_EID_OTHER_DEVICE)

  • SITHS eID på denna enhet (SITHS_EID_SAME_DEVICE)

  • SITHS-kort på denna enhet (MTLS)

Nedan beskrivningar av Autentiseringsmetoderna gäller bara:

  • OM IdP INTE har en giltig SSO-session
  • Eller för autentisering via Autentiseringstjänsten (OOB) om SP/IdP begär en:
    • Förnyad autentisering eller
    • Legitimering för Underskrift (ForceAuthn)

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

Dubbelriktad TLS (mTLS)

Användarens certifikat förmedlas via webbläsaren integration mot operativsystemet. En klient på användarens dator läser kortet och publicerar certet till operativsystemet/webbläsaren som använder det för att skapa en mTLS-anslutning till servern via webbläsaren. Finns det flera certifikat som accepteras av servern erbjuder webbläsaren en certifikatvalsdialog som ligger utanför serverns kontroll.

Användaren kommer vid varje nytt inloggningsförsök bli omdirigerad till en annan subdomän för att undvika att certifikatet som valdes vid förra inloggningsförsöket väljs igen av webbläsaren. Rent praktiskt kommer användaren bli omdirigerad till subdomäner som börjar med secure0.idp.inera.se och sedan inkrementera det numeriska värdet ända tills den högsta tillåtna subdomänen nås som IdP:n är konfigurerad till att omdirigera användare till, exempelvis secure24.idp.inera.se. Efter att användaren har förbrukat subdomänen med det högsta numeriska värdet blir användaren ombedd att starta om sin webbläsare för att rensa certifikatsvalen som webbläsaren kommit ihåg. Efter omstarten kommer användaren få börja om med secure0.idp.inera.se som första subdomän.

Användaren får dessutom möjlighet att göra nya inloggningsförsök ifall inget certifikat har förmedlats till IdP:n, exempelvis genom att inget kort har suttit i kortläsaren eller om användaren råkat trycka på Avbryt när certifikatsväljaren har presenterats i webbläsaren. I dessa fall kommer användaren hamna på en felsida som berättar att ett certifikat saknas för att slutföra inloggningen. Här har dock användaren möjlighet att trycka på kanppen Försök igen som dirigerar om användaren till nästa subdomän i kedjan. Väl där får användaren en ny chans att välja ett certifikat som förmedlas till IdP:n.

En detalj att känna till här är webbläsarnas omförmåga att rensa sessionskakor när en särskild inställning i webbläsaren används. Inställningen handlar om i vilket läge webbläsaren ska starta upp i. I fallet då användaren har valt att webbläsaren ska starta om med samma flikar och session som när webbläsaren stängdes ner senast kommer denna funktionalitet ha en negativ konsekvens i form av att användaren kan behöva starta om webbläsaren oftare än vad som skulle vara nödvändigt. Ett sådant scenario kan se ut såhär. Användaren har gjort 23 inloggningar med dubbelriktad TLS i den pågående webbläsarsessionen och väljer att stänga ner sin webbläsare. Senare startar användaren upp sin webbläsare igen. Då webbläsaren inte har rensat sessionskakorna kommer nästa inloggning med dubbelriktad TLS leda till att användaren autentiserar sig på subdomänen secure24.idp.inera.se. Vid nästa inloggningsförsök får användaren varningen att webbläsaren behöver startas om då för många inloggning gjorts i den pågående webbläsarsessionen även fast användaren bara gjort ett inloggningsförsök sedan senaste omstart.

Autentiseringstjänst (OOB - out-of-band)

Autentisering baserad på OOB-teknik (Out Of Band) sker via Autentiseringstjänsten [P3]. Två typer av Autentiseringsmetoder för OOB exponeras via IdP:n, autentisering med samma enhet och autentisering med annan enhet. Skillnaden mellan de två är enbart i hur IdP:n exponerar autostart-token för SITHS eID-appen.

  • SITHS eID på denna enhet - IdP:n triggar uppstart av klientapplikation via webbläsaren och custom-protokollet "siths://" tillsammans med autostart-token i anropet.
  • SITHS eID på annan enhet - IdP:n visar en QR-kod och användaren får själv starta sin applikation för att skanna QR-koden med kameran på den mobila enheten.

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

Logisk realisering av signifikanta användningsfall

AF1 - Administrera tjänsten

Textuell beskrivning

IdP har en tillhörande administrativ komponent. Komponenten och sina funktioner beskrivs utförligt i Användarhandboken. Nedan sammanfattas de administrativa möjligheter som tillhandahålls.

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

Image Added

OIDC


HTML-kommentar
anchor
hidden
oidcflow
true
oidcflow
Ankare
realiseringrealisering
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"
  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 medarbetaruppdrag
  activate hsa #lightcoral
  hsa -> idp: Svar med medarbetaruppdrag
  deactivate hsa
  idp -> ua: Begär val av medarbetaruppdrag
  user -> ua: Val av uppdrag
  ua -> idp: Meddela uppdragsval
  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

OIDC

Ankare
oidcflow
oidcflow

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.


Image Added

HTML-kommentar
hiddentrue
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 "Client" as client<<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 "Secure IdP" 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"
  idp -> ua: Redirect till säkerthetskanal (mutual TLS)
  ua -> secure: Anslut till Secure IdP
  activate secure #lightgreen
  secure -> ua: Krav på autentisering
  activate client #gold
  user -> client: Starta app
  client-> user: Begär PIN
  user -> client: Anger PIN
  client-> user: PIN Godkänd
  deactivate client
  ua -> secure: Skickar autentiseringsuppgifter
  secure -> ua: Autentiserad, redirect till idP
  deactivate secure
  ua -> idp
  idp -> hsa: Hämta medarbetaruppdrag
  activate hsa #lightcoral
  hsa -> idp: Svar med medarbetaruppdrag
  deactivate hsa
  idp -> ua: Begär val av medarbetaruppdrag
  user -> ua: Val av uppdrag
  ua -> idp: Meddela uppdragsval
  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
deactivate idp
idp -> sp1: Returnera tokens
sp1 -> sp1: Skapar aktörs-session
sp1 -> ua: Aktör inloggad\nVisa begärt data
deactivate sp1
deactivate ua

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.

Ankare
realisering
realisering

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

Image Added


HTML-kommentar
hiddentrue
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 medarbetaruppdrag krävs"
    idp -> ua: Begär val av medarbetaruppdrag
    user -> ua: Val av uppdrag
    ua -> idp: Meddela uppdragsval
  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


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.

Image Added


HTML-kommentar
hiddentrue
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]] ></ac:plain-text-body></ac:structured-macro><h3>AF4 - Revokera tokens</h3><h4>Textuell beskrivning</h4><p>Anv&auml;ndningsfallet beskriver hur en revokering av token g&aring;r till inom tj&auml;nsten..</p><ol><li>Token revokering<ol><li>En RP som har tillg&aring;ng till en Access Token eller Refresh Token vill revokera denna. En revokeringsbeg&auml;ran f&ouml;r denna token skickas till IdP'n.</li><li>Vid giltig beg&auml;ran revokerar idP'n det token&nbsp;som ingick i beg&auml;ran samt eventuella tillh&ouml;rande tokens (ID Token, Access Token, Refresh Token som utf&auml;rdades samtidigt).</li><li>Ingen inverkan p&aring; den IdP-session som token utf&auml;rdades inom sker. Om IdP-sessionen fortfarande &auml;r giltig kan SSO fortsatt erh&aring;llas.</li><li>IdP skickar svar p&aring; beg&auml;ran med statuskod.</li></ol></li></ol><p>Detta fl&ouml;de kan sammanfattas med f&ouml;ljande:</p><ul><li>Vid revokeringsbeg&auml;ran kommer enbart den/de tokens som h&ouml;r till beg&auml;ran att revokeras. Ingen inverkan p&aring; anv&auml;ndaren IdP-session kommer att ske, och vid giltig IdP-session forts&auml;tter anv&auml;ndaren erh&aring;lla SSO.</li></ul><h4>Realisering</h4><p><span>Fl&ouml;den nedan representerar de olika scenarion f&ouml;r revokering som anges ovan.</span></p><ac:structured-macro ac:name="plantuml" ac:schema-version="1" ac:macro-id="c2dbb2aa-ee4f-495e-8f7b-41f5379e51f6"><ac:parameter ac:name="align">left</ac:parameter><ac:parameter ac:name="atlassian-macro-output-type">BLOCK</ac:parameter><ac:plain-text-body><![CDATA[@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

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.

Image Added


HTML-kommentar
hiddentrue
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

AF6 - Elektronisk underskrift
Ankare
digital-signatures
digital-signatures

Expandera
titleVisa AF6 - Elektronisk underskrift


Inkludera sida
2.4 6 SAD - IdP - Elektronisk underskrift
2.4 6 SAD - IdP - Elektronisk underskrift

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

Expandera
titleVisa icke-funktionella krav


Inkludera sida
2.4 5 SAD - IdP - Icke-funktionella krav
2.4 5 SAD - IdP - Icke-funktionella krav

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

Expandera
titleVisa Teknisk lösning


Inkludera sida
2.4 5 SAD - IdP - Teknisk lösning
2.4 5 SAD - IdP - Teknisk lösning

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

Expandera
titleVisa Säkerhet


Inkludera sida
2.6 5 SAD - IdP - Säkerhet
2.6 5 SAD - IdP - Säkerhet

LoA administration
Ankare
loa-administration
loa-administration

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

Expandera
titleVisa LoA administration

/wiki/spaces/ST/pages/3475216715

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

Expandera
titleVisa Driftaspekter


Inkludera sida
2.6 5 SAD - IdP - Driftaspekter
2.6 5 SAD - IdP - Driftaspekter


...