Introduktion

Autentisering med SITHS realiseras genom att använda av någon av de två autentiseringslösningar som finns för SITHS.

...

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

...

Kopplingen till klienten skapas genom att klienten från IdP får en autostarttoken (som IdP från från Autentiseringstjänsten i svaret ifrån anropet till /auth) som klienten sedan använder i sitt anrop mot Autentiseringstjänsten. Förmedligen av autostarttoken till klienten kan ske på två sätt:

siths://?autostarttoken=<autostarttoken>

1. Autostart via appväxling m.h.a. custom-protokollet <siths://> (om autentisering på samma enhet) - SITHS eID på denna enhet
2. QR-kod som scannas in med Mobilklienten (om autentisering på annan enhet)

...

1. - SITHS eID på annan enhet
   1. Vid inloggning med annan enhet (mobil eller platta) ska en QR kod genereras och exponeras av IdP:n och skannas av med hjälp av Mobilklienten.
      QR koden ska innehålla värdet <autostarttoken> eller den RP genererade animerade QR koden.

• siths://?autostarttoken=<token>&referer=<retur url>

Format för custom-protokoll - SITHS eID-app för Windows

siths://?autostarttoken=<autostarttoken>

Format för custom-protokoll - SITHS eID-app för Mobila enheter

siths://?autostarttoken=<autostarttoken>&referer=<retur url>

Efter genomförd legitimering kommer appen försöka dirigera användaren tillbaka till den url som levererats i referer enligt url-scheme. Om referer inte skickas kommer appen att bete sig olika beroende på det mobila operativsystemet:

• iOS → Appen visar en skärmbild som informerar användaren om utfallet av legitimeringen/underskriften och en uppmaning om att själv navigera tillbaka till den applikation där hen påbörjade sin legitimering/underskrift
• Android - SITHS eID-appen flyttas till bakgrunden och påkallar att senast använda app ska återta fokus. Som regel är detta den app där användaren påbörjade sin legitimering/underskrift och detta upplever användaren som ett oavbrutet flöde för legitimering/underskrift

Statisk QR

Statiska QR koder skall innehålla värdet av <autostarttoken> från auth/sign svaret.

...