Inledning
Detta är en beskrivning på artikel om hur personidentifierare hanteras när Ineras tjänster samverkar vi en autentisering. Specifikt besvarar beskrivning på artikeln 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.
...
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: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.
...
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 ovan, då det kan finnas flera HSA-id knutna till samma personnummer.
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.
...
Ö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 identitetsintyg.
Påverkan på organisationens användarhantering avseende behörighet och åtkomst
...