Jämförda versioner

Nyckel

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

...

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.

...

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-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å det HSA-id för användaren som organisation A har utfärdat.
  • En organisation B utfärdar en e-legitimation för samma person.
  • Organisationen A revokerar e-legitimationen för sin organisation men gör ingen uppdatering i HSA-katalogen.
  • Användaren nyttjar SITHS eID på kort från organisation B.

...

  1. Användaren vill använda e-tjänsten men är inte autentiserad så e-tjänsten begär att få en biljett med HSA-id 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 för användaren.
  5. Katalogtjänsten svarar med de HSA-id som är knutna till personnumret. 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.
  6. IdP:n skapar en biljett med organisation A:s HSA-id för användaren och skickar biljetten till e-tjänsten, vilket, i det här fallet, möjliggör användarens tillgång till e-tjänsten i organisation A, med en e-legitimation 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 å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.
  • 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 behörighetshantering 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.

...