| 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änst SITHS från Inera
I det här fallet så kan kunden ansluta sin egen IdP till Autentiseringstjänsten Autentiseringstjänst SITHS 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
- Integration mot Ineras Autentiseringstjänst SITHS med presentation av användarens val av autentiseringsmetod
- QR-kodhantering för säkrad autentisering
- Tolkning av tillitsnivå (LoA)
- Integration mot katalogtjänsten
- App-växling
- Uppdragsval
Mer information om hur man ansluter till Autentiseringstjänsten Autentiseringstjänst SITHS finns i Anslutningsguide till AutentiseringstjänstenAutentiseringstjänst SITHS, se kapitlet Referenser.
| Info |
|---|
| Observera att Ineras lokala IdP kan ansluta till Autentiseringstjänsten Autentiseringstjänst SITHS från Inera, på så sätt slipper kunden utveckla motsvarande funktionalitet. Se Lokal IdP från Inera bland Referenser. |
.
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ätt | E-tjänst till Ineras IdP | Kundens IdP som IdP-proxy | Kundens IdP till AutentiseringstjänstenAutentiseringstjänst SITHS Kan vara Ineras Lokala IdP | Dubbelriktad TLS (Mutual TLS, mTLS) |
|---|---|---|---|---|
| Enbart standardiserade API:er | JA | JA | NEJ | JA |
| Hantering av LoA, m h a av komponenter i Ineras miljö | JA | JA | NEJ | NEJ |
| Utforma användardialogen för metodval enligt kundens UX-standard | NEJ | NEJ | JA | JA |
| Välja vilka autentiseringsmetoder som gäller per e-tjänst | JA | NEJ | JA | Beroende på hur det är uppsatt |
| Tolkning av LoA kan vara en annan än Ineras | NEJ | JA | JA | JA |
| Kunden kan välja katalog för användarinformation | NEJ | JA | JA | JA |
| Ingå i valfri federation | NEJ | JA | JA | JA |
| Använda andra e-legitimationer än SITHS eID | NEJ | JA (om kundens IdP har stöd för detta) | JA (om kundens IdP har stöd för detta) | NEJ |
| Tillgång till mTLS | JA | JA | NEJ, inte via Autentiseringstjänst SITHS men om den lokala IdP:n har stöd för detta går det att använda mTLS Ineras lokala IdP har stöd för mTLS. | Integrationen görs i verksamhetssystemet |
| SSO för alla e-tjänster, lokala och Ineras | JA (om alla e-tjänster ansluts till Ineras IdP) | NEJ | NEJ | Nej |
| SSO för lokala e-tjänster | JA (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
- Anslutningsguide till AutentiseringstjänstenAutentiseringstjänst SITHS
- Anslutningsguide till IdP
- Autentisering via SITHS eID övergripande presentation
- AutentiseringstjänstenAutentiseringstjänst SITHS
- Filmer
- Fördjupning om SSO
- Gemensam anslutningsinformation
- Hantering av personidentifierare vid autentisering
- IdP från Inera (central)
- Lokal IdP från Inera
- OIDC
- Programvaror och tillbehör för SITHS
- SAML
- SSO
- Tolkning av tillitsnivå
- Utgivning och användning av SITHS e-legitimation