Jämförda versioner

Nyckel

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

...

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. 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 i ämnet. I synnerhet är Referensarkitekturen för Identitet och åtkomst en bra källa för att förstå principer och terminologi.

...

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 attribut. Källan till attributen kan vara e-legitimationen, metadata, klinetkonfiguration 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.

...

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.



Översikt över hur de olika tjänsterna i Ineras lösning samverkar. E-tjänsten begär inloggning via IdP, som i sin tur nyttjar Autentiseringstjänsten. Beroende på vilka attribut som e-tjänsten kräver, kommer IdP:n eventuellt att göra ett uppslag i katalogen. Resultatet levereras till e-tjänsten från IdP:n i form av en biljett eller ett identitetsintyg.

...

  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.


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

...

För att säkerställa en användares korrekta behörighet till e-tjänsterna behöver användarorganisationen uppdatera sina katalogdata, det man kallar för off-boarding.


mTLS (dubbelriktad TLS, in-band)

...

Eftersom normalfallet för en mTSL autentisering ger en identitet baserat på HSA-id så uppstår inte det användningsfall scenaoriot som finns beskrivet i exemplet för out-of-band autentisering. Dvs det blir aldrig någon växling från personnummer till HSA-id så att det går att använda en annan organisations SITHS eID-kort för att komma in i e-tjänsten.  En revokering av SITHS-kortet får omedelbar verkan om e-tjänsten bara stödjer mTLS och om IdP:n endast har tillit till HSA-id-certifikat.

Följande skulle hända vid en mTLS-autentisering med samma förutsättningar som för exemplet vid out-of-band autentisering, med det tillägget att IdP endast har tillit till HSA-id-certfikat.

...

I det här fallet så medförde revokeringen av e-legitimationen i organsisation A att användaren nekades åtkomst till e-tjänsten.

Misslyckad autentisering med en e-legitimatin från organisation B.

...

  • Personidentiteringshanteringen i autentiseringsflödet för out-of-band baseras på en prioritering i ordningen personnummer, samordningsnummer och HSA-id, vilket bestäms av Autentiseringstjänsten.
  • I praktiken innebär det att de IdP:er som har behov av att leverera personidentiteter i form av HSA-id behöver i princip alltid göra ett kataloguppslag mot t ex HSA-katalogen. Det HSA-id som IdP:n levererar till eTjänsten behöver nödvändigtvis inte matcha det som finns på användarens SITHS eID-kort. Som en konsekvens av detta förhållande behöver den ansvariga organisationen administrera sina katalogdata för att säkerställa att en specifik användare fråntas åtkomst om användaren inte längre har uppdrag hos den organisationen. Om användaren har flera SITHS eID-legitimationer, räcker det inte med att revokera en av dessa. Processen brukar kallas off-boarding.
  • Andra e-legitimationer än SITHS som bara innehåller personnummer, kommer att kunna hanteras på samma sätt av Ineras infrastruktur och kommer att kräva samma katalogdatahantering av användarorganisationerna.
  • För mTLS (in-band) gäller att backend-lösningen ska lita på de certifikat som man vill att användaren ska använda. På så sätt kan man styra till t ex HSA-id-certifikatet, om man så önskar.
  • I bägge fallen, out-of-band och mTLS, har klienterna inte någon inverkan på vilket certifikat som väljs. För en organisation som går över från NetID till Ineras klientprogramvara i sin mTLS-lösning så kommer lösningen att fungera som tidigare, dvs användaren styrs till det certifikat som backend har bestämt, i de flesta fall till HSA-id-certifikatet.
  • Ineras IdP fungerar både med out-of-band och mTLS enligt ovan. För out-of-band kommer i första hand personnummercertifikatet att väljas, för mTLS blir det HSA-id-idcertifikatetcertifikatet.

Referenser

Referensarkitektur för Identitet och åtkomst ARK_0046

...