Inledning
Detta är en beskrivning på hur personidentifierare hanteras när Ineras tjänster samverkar vi en autentisering. Specifikt besvarar beskrivning på frågan om vilken personidentifierare som blir slutresultatet av en lyckad identifiering i den biljett som e-tjänsten får men även vilken inverkan det får vid livscykelhantering och åtkomst för användare.
Out-of-band autentisering med SITHS eID
Out-of-band autentiseringmetoder i Ineras lösning med SITHS eID som användaren kan välja emellan
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.
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 då lösningen baseras på en prioriteringsordning för Autentiseringstjänsten:
- Personnummer
- Samordningsnummer
- HSA-id
Förenklat kan man beskriva detta med följande sekvens:
e-tjänst → IdP → Autentiseringstjänst
IdP:n har också en koppling till HSA-katalogen för att hämta kompletterande information. På användarens klient måste det också 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 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.
Det är valet av HSA-id som avgör vilket HSA-id som levereras till e-tjänsten, vilket kan skilja sig från det som finns på SITHS eID-kortet.
Om användaren använder Mobilt SITHS eID som e-legitimation så kommer Autentiseringstjänsten alltid leverera personnummer 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 framgår av beskrivningen så är den prioriterade personidentiteten i lösningen alltid personnummer, men e-tjänsten kan alltid styra vilken personidentitet som levereras i biljetten.
Vill e-tjänsten ha personnummer som identitet krävs inget uppslag i HSA.
Översikt över hur de olika tjänsterna i Ineras lösning samverkar
Påverkan på organisationens användarhantering avseende behörighet och åtkomst
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 ger användaren behörighet får revokeringen av en e-legitimationen ingen effekt. Ett exempel;
- En organisation A utfärdar en e-legitimation och ger e-legitimationens innehavare åtkomst till en e-tjänst via HSA-katalogen.
- En organisation B utfärdar en e-legitimation för samma person.
- Organisationen A revokerar e-legitimationen men gör ingen uppdatering i HSA-katalogen.
- Personen använder sin e-legitimation från organisation B för att autentisera sig i organisation A:s e-tjänst.
- IdP:n kommer att utfärda en biljett med ett HSA-id från organisation A till e-tjänsten, personen kommer att få åtkomst till A:s e-tjänst.
Summering
Personidentiteringshanteringen i autentiseringsflödet för out-of-band baseras på en prioritering i ordningen personnummer, samordningsnummer och HSAID, 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 HSAid 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-kort. Som en konsekvens av detta förhållande behöver den ansvariga organisationen administrera åtkomsträttigheterna i katalogen 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.
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.
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.