Expandera | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
|
Introduktion
Autentisering med SITHS realiseras genom att använda av någon av de två autentiseringslösningar som finns för SITHS.
...
- 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
...
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:
Kodblock |
---|
siths://?autostarttoken=<autostarttoken> |
- Autostart via appväxling m.h.a. custom-protokollet <siths://> (om autentisering på samma enhet) - SITHS eID på denna enhet
- QR-kod som scannas in med Mobilklienten (om autentisering på annan enhet)
...
- - SITHS eID på annan enhet
- 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.
- 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.
- siths://?autostarttoken=<token>&referer=<retur url>
Format för custom-protokoll - SITHS eID-app för Windows
Kodblock |
---|
siths://?autostarttoken=<autostarttoken> |
Format för custom-protokoll - SITHS eID-app för Mobila enheter
Kodblock |
---|
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.
...