Jämförda versioner

Nyckel

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

Innehållsförteckning

Inledning

Denna sida beskriver översiktligt olika varianter på hur din organisations e-tjänster kan nyttja  autentiseringsmetoderna som baseras på SITHS eID. Längst ner på sidan hittar du en sammanställning av för- och nackdelar med respektive variant samt vilka som just nu finns tillgängliga för dig som kund.

...

Bland referenserna finns också en länk till en artikel om hantering av personidentitet vid autentisering för den som vill veta mer om hur det går till i Ineras lösning.

Anslut e-tjänst till Ineras IdP

Detta innebär att ansluta e-tjänsten som en Service Provider till Ineras IdP. Denna komponent har ett antal förmågor:

...

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

Anslut kundens IdP som IdP-proxy mot Ineras IdP

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. Kunden behöver utveckla den lokala IdP:n så att den stödjer denna förmåga.

...

Kundens IdP ansluter till Ineras IdP som Service Provider och uppträder som IdP mot de anslutna e-tjänsterna, dsv som IdP-proxy.


Anslut kundens IdP till Autentiseringstjänsten från Inera

I det här fallet så kan kunden ansluta sin egen IdP till Autentiseringstjänsten från Inera via det proprietära protokoll som Inera har utvecklat. Kundens e-tjänster måste då ansluta till kundens egna IdP för att via denna väg få tillgång till de autentiseringsmetoder som finns för SITHS eID. Kunden måste själv utveckla motsvarande funktionalitet i sin IdP som återfinns i Ineras IdP. T ex

...

Kundens IdP ansluter till Autentiseringstjänsten

Dubbelriktad TLS (Mutual TLS, mTLS)

mTLS är  en autentiseringsteknik där tilliten mellan klient och server bygger på ömsesidig utmaning av varandras certifikat. För att det ska fungera fullt ut, behöver e-legitimationen stödja tekniken, vilket SITHS eID gör.

...

En annan viktig principiell skillnad är att mTLS är en in-band teknik, där informationskanal och säkerhetskanal alltid är densamma. Mobilt SITHS eID är en out-of-band teknik där kanalerna kan vara separata.

För- och nackdelar med de olika anslutningssätten

Varje anslutningssätt har sina möjligheter och begränsningar. Här är en sammanställning.

...

Förmåga/AnslutningssättE-tjänst till Ineras IdPKundens IdP som IdP-proxyKundens IdP till Autentiseringstjänsten Dubbelriktad TLS (Mutual TLS, mTLS)
Enbart standardiserade API:erJAJANEJJA
Hantering av LoA, m h a av komponenter i Ineras miljöJAJANEJNEJ
Utforma användardialogen för metodval enligt kundens UX-standardNEJNEJJAJA
Välja vilka autentiseringsmetoder som gäller per e-tjänstJANEJJABeroende på hur det är uppsatt
Tolkning av LoA kan vara en annan än InerasNEJJAJAJA
Kunden kan välja katalog för användarinformationNEJJAJAJA
Ingå i valfri federationNEJJAJAJA
Använda andra e-legitimationer än SITHS eIDNEJJA (om kundens IdP har stöd för detta)JA (om kundens IdP har stöd för detta)NEJ
Tillgång till mTLS JAJANEJIntegrationen görs i verksamhetssystemet
SSO för alla e-tjänster, lokala och InerasJA (om alla e-tjänster ansluts till Ineras IdP)NEJNEJNej
SSO för lokala e-tjänsterJA (om alla e-tjänster ansluts till Ineras IdP)JA (om alla e-tjänster ansluts till den lokala IdP:n)JA (om alla e-tjänster ansluts till den lokala IdP:n)Beroende på hur det är uppsatt


Referenser

...