Jämförda versioner

Nyckel

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

...

Inera erbjuder flera sätt att låta e-tjänster nyttja SITHS eID för autentisering av användare. Alla dessa sätt möjliggör för användaren autentisering med SITHS eID-kort eller mobilt SITHS eID.  Alla metoderna förutsätter att användarna har en giltig SITHS eID e-legitimation och tillgång till en autentiseringsapp, antingen i mobilen eller på datorn.

Innan du som kund väljer vilket sätt som är bäst för din organisation bör du noggrannt överväga vad som passar dig bäst. Ju mer av infrastrukturen du väljer att bygga själv, desto större flexibilitet men också mera utveckling och förvaltning tar du på dig i din organisation.

Anslut e-tjänst till Ineras IdP

...

  • Standardiserade protokoll i form av SAML eller OIDC som e-tjänsten använder i integrationen med IdP:n.
  • Slutanvändaren väljer autentiseringsmetod i en dialog som IdP:n tillhandahåller. Detta inkluderar möjligheten att låta e-tjänsten nyttja MTLS som autentiseringsmetod.
  • Resultatet av en gjord autentisering levereras till e-tjänsten i form av en biljett (identitetsintyg).
  • E-tjänsten begär en viss tillitsnivå (LoA, Level of Assurance) men behöver inte  ha någon kunskap om vilken autentiseringsmetod som används och får dessutom information om användarens behörighet i biljetten, om så önskas.
  • Du som kund kan välja vilka autentiseringsmetoder som ska gälla per e-tjänst.
  • Användarinformationen hämtas från den centrala HSA-katalogen men adminstreras lokalt.


Kundens e-tjänst ansluter till Ineras IdP som Service Provider

Kundens e-tjänst ansluter till Ineras IdP som Service Provider

...

Det finns en variant av det första sättet: Kunden ansluter sin IdP som en Service Provder till Ineras IdP. På så sätt kan man ha en egen IdP, anpassad för specifika lokala behov men ändå ansluta till Ineras lösning via standardiserade gränssnitt. Kunden slipper de nackdelar och kostnader som det medför att utveckla och underhålla IdP-funktionalitet som redan finns i Ineras IdP men måste agera IdP-proxy. Med det menas att gentemot Ineras IdP uppträder den som en Service Provider men mot de anslutna e-tjänsterna agerar den IdP. För detta krävs en utvecklingsinsats. 

Om kunden använder den egna IdP:n för andra e-tjänster så kommer användarna att kunna få SSO, Single Sign-On. Du som användare behöver bara autentisera sig en gång för åtkomst till alla e-tjänster som är anslutna till samma IdP.

Kundens IdP kan visserligen få all behörighetsstyrande information (attribut) om användaren via det identitetsintyg (biljett) som levereras från Ineras IdP men tanken är att den informationen ska hämtas från den lokala katalogtjänsten. Kundens IdP ansvarar för att tillverka ett nytt identitetsintyg, baserat på biljettinformation från Ineras IdP och den lokala katalogtjänsten. 

...