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:

• Användarhandbok - SITHS eID Windowsklient
• Användarhandbok - SITHS eID Mobilklient

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.

1. Anslutning av en eller flera lokal e-tjänster till Ineras IdP
2. Anslutning av lokal IdP till Ineras IdP (proxy-anslutning)
3. Anslutning av lokal IdP till Autentiseringstjänsten (direktanslutning)

...

1. initalt förmedla HSA-id för inläsning i Autentiseringstjänsten
   1. 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.
2. 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.
   1. 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.
   2. 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.
3. inom 6 månader kunna anpassa sig till nya versioner av API:et hos Autentiseringstjänsten.
   1. 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.
4. 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
   
5. hantera
   1. QR kod,
   2. tolkning av tillitsnivå (LoA) och
   3. medarbetaruppdragsval
      
6. eventuellt hantera
   1. val av autentiseringsmetod och
      
   2. integration mot lokal katalogtjänst

...