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 autentiseringmetoder i Ineras lösning med SITHS eID som användaren ser det vid inloggning.

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ä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 den realisering som Inera har gjort för out-of-band med nya autentiseringsmetoder, finns självklart användarens identitet med i biljetten. Dock är det en lös koppling mellan den identitet som finns på e-legitimationen och den identitet som levereras i biljetten.

Lösningen utgår från en prioriteringsordning för de identiteter som finns på e-legitimationen. Prioritetsordningen bestäms av Autentiseringstjänsten:

Personnummer
Samordningsnummer
HSA-id

Förenklat kan man beskriva detta med följande sekvens, där e-tjänsten begär en inloggning via IdP:n som i sin tur anropar Autentiseringstjänsten när användaren har valt out-of-band:

e-tjänst → IdP → Autentiseringstjänst → IdP → e-tjänst

IdP:n har också en koppling till HSA-katalogen för att hämta kompletterande information. På användarens klient måste det finnas klientprogramvaror, bl a en SITHS eID-app, men de har inget inflytande över prioritetsordningen, det styrs enbart av Autentiseringstjänsten.

E-tjänsten begär ett antal attribut från IdP:n, IdP:n i sin tur anropar Autentiseringstjänsten för att få fram certifikatinformation. Om användaren använder autentiseringsmetoden "SITHS eID på denna enhet" och sitter på en PC, kommer Autentiseringstjänsten i de flesta fall leverera ett personnummercertifikat.

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.

Användardialog för val av uppdrag-då e-tjänsten behöver uppdragsrelaterade attribut och det finns flera uppdrag för användaren.

Om användaren använder Mobilt SITHS eID som e-legitimation så kommer Autentiseringstjänsten alltid leverera ett personnummercertifikat till IdP:n, då det är det enda certifikat som finns på den e-legitimationen. Det i sin tur kan leda till ett användarval av HSA-id via IdP:n som ovan, då det kan finnas flera HSA-id knutna till samma personnummer. I andra fall då e-tjänsten begär attribut som relaterar till användarens uppdrag, leder det till ett uppdragsval för användaren.

Som framgår av beskrivningen så är den prioriterade personidentiteten i lösningen alltid personnummer, oavsett om det är SITHS eID på kort eller Mobilt SITHS eID, men e-tjänsten kan alltid styra vilken personidentitet som levereras i biljetten. En fördel med denna lösning är att samma princip kommer att gälla för andra e-legitimationer som baseras på personnummer, om man väljer att lägga till dessa i lösningen. Man skulle kunna uttrycka det så att det sker en växling till ett tjänsteid.

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.

Påverkan på organisationens användarhantering avseende behörighet och åtkomst vid out-of-band autentisering

Som en konsekvens av out-of-band-lösningen som den är realiserad, räcker det inte med att revokera själva e-legitimationen för att användaren ska spärras ut från e-tjänsterna. Så länge användaren har en giltig e-legitimation och HSA-katalogen innehåller behörighetsgrundande information får revokeringen av en e-legitimation ingen effekt. I det här exemplet så gäller följande förutsättningar;

En organisation A utfärdar en e-legitimation och ger e-legitimationens innehavare åtkomst till en e-tjänst via HSA-katalogen, baserat på att användaren tillhör organisation A.
En organisation B utfärdar en e-legitimation för samma person.
Organisationen A revokerar e-legitimationen för användaren för sin organisation men gör ingen uppdatering i HSA-katalogen, där finns fortfarande en personpost med ett HSA-id från organisation A, kopplat till personnummer och organisation A..
Användaren nyttjar SITHS eID på kort från organisation B, för att få åtkomst till en e-tjänst i organisation A.

En förenklad beskrivning av de steg som man genomgår vid autentisering och vad resultatet blir i detta fall:

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.
IdP:n frågar Autentiseringstjänsten efter användarens certifikat, användaren använder organisation B:s SITHS eID-kort.
Autentiseringstjänsten returnerar personnummercertifikatet, hämtat från SITHS eID-kortet från organisation B, till IdP:n, enligt den prioriteringsordning som gäller.
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.
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.
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.
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 autentisering med organisation A:s HSA-id, med en e-legitimation från organisation B.

Ett vanligt användningsfall när det gäller revokering av en e-legitimation är att användaren har tappat sitt SITHS eID-kort. Det betyder inte att användarorganisationen vill ta bort alla rättigheter som användaren har men man vill spärra e-legitimationen så inget missbruk kan ske. I ett sådant fall så finns användarens HSA-id kvar i katalogen.

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)

In-band autentiseringmetod i Ineras lösning som användaren ser det vid inloggning med Ineras IdP.

Säkerhet med TLS bygger på att servern har ett certifikt som en klient kan lita på. mTLS baseras på ömsesidig tillit mellan klient och server där bägge parter har certifikat som respektive part måste lita på. I Ineras lösning har Ineras IdP stöd för mTLS, med hjälp av de klientprogramvaror som ingår i Ineras leverans. Det är dock fullt möjligt att, via en egen IdP eller e-tjänst, bygga en egen mTLS-lösning. Klientprogramvarorna som är nödvändiga för en sådan realisering är en del av Identifieringstjänst SITHS och kan laddas ner kostnadsfritt.

Precis som för out-of-band lösningen så bestämmer backend, e-tjänsten eller den egna IdP:n, vilket certifikat som ska användas. I out-of-band är det Autentiseringstjänsten från Inera som gör priorteringen, för mTLS fungerar det genom att t ex e-tjänsten bara har tillit till de certifikat som ska användas. På så sätt är det möjligt att i en sådan lösning prioritera HSA-id-certifikatet så att e-etjänsten alltid får tillbaka ett HSA-id vid en lyckad autentisering. Klientprogramvarorna har inget inflytande över prioriteringsordningen.

Om användarorganisationen har gjort en realisering med standardiserade API:er mot operativssystemet och går över från NetID till Ineras klientprogramvaror, ska det inte krävas någon anpassning. HSA-id kommer att leveras precis som tidigare, om det har varit kravet.

Påverkan på organisationens användarhantering avseende behörighet och åtkomst vid mTLS autentisering

Eftersom normalfallet för en mTSL autentisering ger en identitet baserat på HSA-id så uppstår inte det 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.

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.
IdP:n frågar begär användarens HSA-id-certifikat, användaren använder organisation B:s SITHS eID-kort.
IdP:n tar emot certifikatet
IdP:n avtolkar certifikatinformationen och använder HSA-id i sin ingång mot katalogtjänsten för att få fram HSA-id och organisation för användaren.
Katalogtjänsten svarar med de organisationer som är knutna till det HSA-id som gäller för användaren. Då katalogen endast har ett HSA-id för organisation B för det givna HSA-id:et kommer organisation B:s HSA-id för användaren att returneras till IdP:n, tillsammans med organisation. Något uppdragsval behövs inte då det bara finns ett uppdrag att välja på.
IdP:n skapar en biljett med organisation B: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. Då så inte är fallet, nekas användare åtkomst.

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.

Sammanfattning

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

Referenser

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

Identifieringstjänst SITHS på Ineras hemsida

Webbläsaren stöds inte