Jämförda versioner

Gammal version 114

changes.mady.by.user Former user

Sparat den

jämfört med

Ny version 115

changes.mady.by.user Former user

Sparat den

Nyckel

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


Inledning

...

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.
PKCS#11Kryptografisk standard som definierar ett gränssnitt för hantering av kryptografiska nycklar.
LoA, TillitsnivåLevel of Assurance. Grad av säkerhet och tillförlitlighet för en given e-legitimation. Ju högre tillitsnivå en e-legitimation har desto säkrare är den, både när det gäller teknisk och administrativ säkerhet.
E-tjänstSystem som erbjuder en funktionalitet för användare eller andra system.
IdP (Identity Provider)Infrastrukturkomponent som använder olika metoder för att autentisera användare och förmedla ett identitetsintyg till e-tjänster som använder IdP för autentisering av användare. Ur Autentiseringstjänstens perspektiv agerar IdP en RP.
RP (Relying Party)Ett system som förlitar sig på ett annat system för någon funktionalitet. Som exempel så kan en e-tjänst agera RP mot en IdP om e-tjänsten använder sig av IdP för autentisering av användare. Men IdP:n kan också i sin tur agera RP mot Autentiseringstjänsten.
SP (Service Provider)Se begreppet e-tjänst ovan.
AT (Autentiseringstjänsten)Infrastrukturkomponent som förmedlar autentiseringsbegäran mellan IdP och SITHS eID-klienter, samt förmedlar begäran om certifikatsutfärdande mellan SITHS eID Mobilklient och Utfärdandeportalen.
UtfärdandeportalenInfrastrukturkomponent som låter användare utfärda Mobilt SITHS eID, och som förmedlar certifikatsbegäran och certifikat till och från CA.
Katalogtjänst HSAAnvändarkatalog. Datakälla för information om vårdpersonal, inklusive behörighetsinformation.

...

Innan SITHS e-legitimation på kort eller ett Mobilt SITHS eID kan användas för att utföra legitimering eller underskrift mot Autentiseringstjänsten behöver certifikaten registreras.

Realisering

  1. Användaren startar klienten eller laddar om huvudsidan.
  2. Klienten hämtar och validerar signerad konfiguration ifrån Utfärdandeportalen som innehåller information om vilka Autentiseringstjänster som klienten ska använda.
  3. Användaren sätter i kortet i kortläsaren.
  4. Klienten kontrollerar sitt/sina Credential IDs mot samtliga konfigurerade Autentiseringstjänster
  5. Om en eller flera Autentiseringstjänster saknar ett eller flera SITHS eID, och därmed kräver registrering, uppmanas användaren att mata in legitimeringskod för att utföra registreringen.
  6. Klienten använder de upplåsta certifikaten för att utföra registrering mot de Autentiseringstjänster som krävde detta.

Diagrammet nedan visar registreringsflödet:

...

Anropen i steg 3 och 5 i figuren nedan följer  och 

AF4 - Legitimering

Textuell beskrivning

Användaren vill autentisera sig med eID som är registrerat hos Autentiseringstjänsten enligt ovan.

Anrop 8 och 10 i bilden, mellan klienten och Autentiseringstjänsten, följer FIDO2 WebAuthn, för mer info se WebAuthn Client Authentication.

Autentisering för underskrift jämfört med autentisering för inloggning.

...

Realisering

  1. Användaren efterfrågar tillgång till en Tjänst (t.ex. klickar på webblänk).
  2. Användaren blir omdirigerad mot IdP/RP som startar uppdraget och triggar en appväxling.
  3. Beroende på hur Tjänsten konfigurerats får antingen Avnändaren välja eller så väljer IdP:n automatiskt mellan inloggning med SITHS eID på samma eller annan enhet
    1. Samma enhet - autostart-token förmedlas via appväxling.
      1. OBS! För SITHS eID Windowsklient fungerar endast denna metod
    2. Annan enhet - autostart-token förmedlas via inskanning av QR-kod
  4. Klienten måste öppnas, vilket kan ske olika beroende på vilken metod som väljs
    1. Samma enhet - Automatisk via appväxling
      1. Om flera kort finns anslutna till datorn vid användning av SITHS eID Windowsklient väljs ett av dessa som aktivt, annars används det kort som är valt sedan tidigare - användaren kan själv välja aktivt SITHS eID
    2. Annan enhet - Manuellt av Användaren
  5. Användaren uppmanas att ange sin legitimeringskod för att låsa upp certifikatet när:
    1. klienten är startad
    2. har en autostart-token dvs. en begäran om legitimering/underskrift som hämtats från någon Autentiseringstjänst,
    3. har ett godkänt och giltigt certifikat för aktuell autostart-token. Begäran via autostart-token kan filtreras på:
      1. Godkända certifikatsutfärdare för att styra accepterad tilltsnivå
      2. Person-ID
      3. Valet av godkänt certifikat görs av Autentiseringstjänsten
  6. Användaren matar in legitimeringskod och klienten utför legitimering.
  7. Legitimeringsflödet fortsätter och användaren får tillgång till Tjänsten.

Diagrammet nedan visar flödet vid Legitimering:

  • Klientens del i flödet startar i steg 6 när IdP förmedlar en autostarttoken till klienten, antingen via appväxling eller via en QR-kod.
  • För Windowsklienten sker förmedling av autostarttoken alltid m.h.a. appväxling (steg 6A).
  • Kommunikationen mellan klienten och Autentiseringstjänsten i steg 8 och 10 följer FIDO2 WebAuthn Client Authentication.

AF5 - Underskrift (Legitimering för Underskrift)

Textuell beskrivning

Användaren ska kunna använda SITHS e-legitimation för att elelktroniskt underteckna information (ex. dokument) via /wiki/spaces/INR/pages/3582230940

Realisering

Anropsflödet är i stort sett identiskt för Underskrift och Legitimering, se diagrammet i AF4 - Legitimering ovan.

Det som skiljer dessa två användningsfall är att i samband med angivelse av legitimeringskoden kommer appen förutom att visa upp vilken tjänst som begär underskrift även visa ett Underskriftsmeddelande, som talar om vilken information Användaren skriver under. Detta görs som en bekräftelse till Användaren för att undvika tveksamheter om vad man skriver under.

Meddelandet kommer från IdP / RP i steg 4 ovan, och förmedlas till klienten i steg 8.

Icke-funktionella krav

Denna information är låst åtkomst sker via länken nedan som kräver inloggning.

...