...
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.
Inera rekommenderar att i första hand att ansluta e-tjänsten till Ineras IdP, vilket är det sätt som Ineras e-tjänster använder sig av.
Anslut e-tjänst till Ineras IdP
I det första fallet så ansluter Detta innebär att ansluta e-tjänsten som en Service Provider till Ineras IdP. Denna komponent har ett antal förmågor:
...
Anslut kundens IdP till Autentiseringstjänsten från Inera
I det andra 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
...
Anslut kundens IdP som IdP-proxy mot Ineras IdP
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 utvecklingsinsatsKunden behöver utveckla den lokala IdP:n så att den stödjer denna förmåga.
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.
...
| Förmåga/Anslutningssätt | E-tjänst till Ineras IdP | Kundens IdP till Autentiseringstjänsten | Kundens IdP som IdP-proxy |
|---|---|---|---|
| Enbart standardiserade API:er | JA | NEJ | JA |
| Hantering av LoA, mm av komponenter i Ineras miljö | JA | NEJ | JA |
| Tolkning av LoA kan vara en annan än Ineras | NEJ | JA | JA |
| Kunden kan välja katalog för användarinformation | NEJ | JA | JA |
| Använda andra e-legitimationer än SITHS eID | NEJ | JA | JA |
| Tillgång till MTLS (äldre autentiseringsmetod) utan integration | JA | NEJ | JA |
| SSO för alla e-tjänster, lokala och Ineras | JA (om alla e-tjänster ansluts till Ineras IdP) | 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) |
Ineras e-tjänster
Ineras e-tjänster använder uteslutande anslutning till Ineras IdP som Service Providers. Initialt kommer enbart den traditionella autentiseringsmetoden MTLS användas av Ineras e-tjänster, gradvis kommer de att även stödja de nya metoderna. Om din organisations användare vill kunna använda den nya tekniken för inloggning så krävs det att organisationen inför detta genom klientinstallation och instruktioner till sina användare hur de kan få tillgång till mobilt SITHS eID.
...