Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.
Kommentera: Automatic update to correct links

Innehållsförteckning

Inledning

Målet för en autentisering är att fastställa en användares identitet och behörighetsstyrande attribut, oftast när användaren till ha åtkomst till en e-tjänst.

Detta är en artikel om hur personidentifierare hanteras när Ineras tjänster samverkar vi en autentisering. Specifikt besvarar artikeln frågan om vilken personidentifierare som blir slutresultatet av en lyckad autentisering i den biljett som e-tjänsten får men även vilken inverkan det får vid livscykelhantering och auktorisation av användare. Den besvarar också frågan om vilket certifikat på e-legitimationen som används.

För att kunna ta del av denna beskrivning, förutsätts grundläggande kunskap i området identitet och åtkomst, (på engelska: identity access management).

Beskrivningen omfattar både mTLS och out-of-band. I slutet av artikeln finns referenser till dokument för den som vill fördjupa sig ytterligare i ämnet. I synnerhet är Referensarkitekturen för Identitet och åtkomst en bra källa för att förstå principer och terminologi.

För den som vill veta mer om motsvarande funktionalitet för elektronisk underskrift rekommenderar vi Hantering av personidentiteter vid signering, se Referenser.

Out-of-band autentisering med SITHS eID

...

Out-of-band som autentiseringsmetod går ut på att splittra informationskanal och säkerhetskanal, till skillnad från in-band där det bara finns en gemensam kanal för information och säkerhet. Med det uppnår man en rad fördelar, t ex är det relativt lätt att införa nya autentiseringsmetoder utan påverkan på e-tjänsterna. De senare har en standardiserad anslutning till en IdP där man via metadata och klientkonfiguration bestämmer vilka attribut som en e-tjänst behöver för säker autentisering och auktorisering av användarna. Resultatet levereras till e-tjänsten i form av en biljett eller ett identitetsintyg, med begärada begärda attribut. Källan till attributen kan vara e-legitimationen, metadata, klientkonfiguration eller en katalog. Med metadata ska man i första hand förstå SAML-metadata då styrningen av OICD sker mera med hjälp av klientkonfiguration.

Som syns på bilden ovan leder out-of-band autentisering till att användaren kan använda en annan enhet för inloggning än den enhet som levererar informationen.

Ineras lösning för out-of-band med SITHS eID

...

I många fall är behörigheten i e-tjänsten baserat på HSA-id, inte personnummer.  Om e-tjänsten har begärt HSA-id som personidentitet, kommer IdP:n att använda det personnummer som den fick från autentiseringstjänsten för att slå mot katalogen för att få fram de HSA-id som motsvarar det framtagna personnumret. Finns det flera HSA-id knutna till personnumret, måste användaren välja ett av dem, via en tjänsteid-väljare, eller i bland via en uppdragsväljare. I HSA-katalogen representeras varje instans av ett unikt HSA-id som en personpost. Förutom personnummer finns ytterligare attribut som kan levereras som är knutna till personposten i HSA-katalogen. Om e-tjänsten vill ha attribut som är relaterade till ett medarbetaruppdrag och användaren har flera uppdrag, kommer det att leda till ett uppdragsval. En förteckning över attributen och vilka som leder till de olika valen finns beskrivna i Anslutningsguiden och Attributlistan.

 

Användardialog för val av tjänste-id-då det finns flera HSA-id för samma personnummer.

...

Info
Vill e-tjänsten ha personnummer som identitet, krävs inget uppslag i katalogen, förutsatt att e-tjänsten väljer rätt attribut. I de användningsfall som artikeln tar upp finns det attribut som kan hämtas från IdP:n. För detaljer om hur man t ex får ut organisationsnummer enskilt eller i kombination med organisation (orgAffliation), se Attributlista bland referenser sist i artikeln.

...

  1. Användaren vill använda e-tjänsten från organisation A men är inte autentiserad så e-tjänsten begär att få en biljett med HSA-id och organisation från IdP:n.
  2. IdP:n frågar Autentiseringstjänsten efter användarens certifikat, användaren använder organisation B:s SITHS eID-kort.
  3. Autentiseringstjänsten returnerar personnummercertifikatet, hämtat från SITHS eID-kortet från organisation B, till IdP:n, enligt den prioriteringsordning som gäller.
  4. IdP:n avtolkar certifikatinformationen från Autentiseringstjänsten och använder personnummer i sin ingång mot katalogtjänsten för att få fram HSA-id och organisation för användaren.
  5. Katalogtjänsten svarar med de organisationer som är knutna till personnumret och de  HSA-id som gäller för användaren. Då katalogen har ett HSA-id för organisation A för det givna personnumret kommer organisation A:s HSA-id för användaren att returneras till IdP:n, med ytterligare HSA-id:n, t ex det som finns för organisation B, med vilken organisation som användaren tillhör Varje unikt HSA-id representeras av en personpost i katalogen, kopplat till samma personnummer. Denna personpost är knuten till en organisation.
  6. Eftersom e-tjänsten efterfråga organisation så kommer detta att leda till ett uppdragsval, där användaren väljer ett uppdrag för organisation A.
  7. IdP:n skapar en biljett med organisation A:s HSA-id för användaren, med tillhörande organisation och skickar biljetten till e-tjänsten. E-tjänsten gör en åtkomstkontroll för att se om användaren tillhör organisation A och ger behörighet till användaren.


Lyckad utentisering autentisering med organisation A:s HSA-id, med en e-legitimation från organisation B.

...

Referensarkitektur för Identitet och åtkomst ARK_0046

Att ansluta e-tjänster (till SITHS eID)

Attributlista

Anslutningsguide IdP

Klientprogramvaror för SITHS eID

Hantering av personidentiteter vid signering

Säkerhetstjänster på Ineras hemsida

...