Expandera | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
|
Introduktion
Autentiseringstjänsten tillhandahåller autentisering för legitimering och underskrift med hjälp av SITHS eID-apparna för användare som har en giltig SITHS e-legitimation från Identifieringstjänst SITHS
|
Introduktion
Autentisering med SITHS realiseras genom att använda av någon av de två autentiseringslösningar som finns för SITHS.
- Inloggning med hjälp av separat säkerhetskanal (out-of-band)
- Inloggning med Dubbelriktad TLS/Mutual TLS (mTLS)
Denna guide har som syfte att stötta organisationer som avser att ansluta en lokal IdP till Inera Autentiseringstjänst enligt integrationsmönster 3 nedan för att uppnå autentisering med autentiseringslösningen out-of-band tillsammans med SITHS eID-apparna. För mer information om dessa se:
Denna guide har som syfte att stötta organisationer som avser att ansluta en lokal IdP till Inera Autentiseringstjänst (mönster 3 nedan).För mer information om autentiseringslösningar för SITHS, se: Autentiseringslösningar för SITHS
Integrationsmönster
Läs Att ansluta e-tjänster för en övergripande beskrivning av tillgängliga integrationsmönster och hjälp med att välja integrationsmönster.
De tre integrationsmönstren som erbjuds vid autentisering av e-tjänsters användare via Autentiseringstjänsten Autentiseringstjänsten och SITHS eID-klienternaapparna.
- Anslutning av en eller flera lokal e-tjänster till Ineras IdP
- Anslutning av lokal IdP till Ineras IdP (proxy-anslutning)
- Anslutning av lokal IdP till Autentiseringstjänsten (direktanslutning)
...
- initalt förmedla HSA-id för inläsning i Autentiseringstjänsten
- Relying party API:et skyddas av bl a mTLS. För att kunna anropa detta API behöver IdP:n presentera sig med ett SITHS funktionscertifikat (utgivet av SITHS e-id Function CA v1) vars subject matchar tjänstens HSA-id som läses in i Autentiseringstjänsten vid anslutningstillfället.
- vara en central IdP för den anslutande organisationen. Varje kund tillåts ha en ansluten IdP, med eventuellt undantag för de största regionerna.
- Denna begränsning ämnar dels till att möjliggöra följsamhet mot referensarkitekturen, som specificerar att autentisering skall centraliseras till en specialiserad tjänst.
- Att hålla nere antalet anslutna tjänster är också avgörande för att kunna säkerställa att anslutna system håller sina anslutningar uppdaterade i takt med att Autentiseringstjänsten förändras.
- inom 6 månader kunna anpassa sig till nya versioner av API:et hos Autentiseringstjänsten.
- När nya versioner av API:erna släpps så kommer de gamla API-versionerna att ligga aktiva parallellt med de nya under en övergångsperiod på 6 månader under vilken den anslutande IdP:n måste anpassas för att använda den nya versionen av API:erna.
- stödja appväxling. IdP:n behöver kunna anropa det externa protokollet "siths://" för att kunna autostarta SITHS eID-klienterna vid inloggning "på samma enhet". Se även exempel för tjänster som använder sig av inbäddade webbläsare SITHS eID Appväxling - Exempel för inbäddade webbläsare
- hantera
- QR kod,
- tolkning av tillitsnivå (LoA) och
- medarbetaruppdragsval
- eventuellt hantera
- val av autentiseringsmetod och
- integration mot lokal katalogtjänst
- val av autentiseringsmetod och
...