...

Autentiseringstjänsten tillhandahåller autentisering för legitimering och underskrift via SITHS eID Windowsklient och SITHS eID Mobilklient (SITHS eID-klienterna) för användare som har e-legitimation från Identifieringstjänst SITHS.

Denna guide har som syfte att stötta organisationer som avser att ansluta en lokal IdP till Inera Autentiseringstjänst (mönster 3 nedan).

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.

...

1. Anmäl intresse, teckna avtal med Inera för valt anslutningsmönster och därmed tjänst:

2. Beställ tjänsten för information om hur en beställning av IdP/Autentiseringstjänst-anslutning går till

3. Fakturering påbörjas.
4. Fyll i förstudiemall Autentiseringstjänst / Förstudie vid anslutning till IdP för testanslutning och skicka in för granskning via etjanster.inera.se/DokumentGranskning.
5. När förstudien är godkänd kan anslutning upprättas mellan den lokala tjänstens testmiljö och testmiljö hos Ineras tjänst (IdP eller Autentiseringstjänsten).
6. Testa anslutningen och funktionen i test.
7. Fyll i separat förstudie för produktionsanslutning, bifoga testrapport som visar att integrationen fungerar som tänkt för de tänkta nyttjandescenarierna.
8. När förstudien mot produktion är godkänd kan anslutning ske mellan produktionsmiljöerna.

...

1. initalt förmedla HSA-id och IP-adress 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. IP-adresslåsning (OBS! I produktion tillåts öppning endast för enstaka utpekade IP-adresser, inga IP-spann)
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".
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

...

Konnektivitet och nätverk

Se Nätverksinställningar för IAM-tjänster för mer detaljerad information.

...

Mobilklienterna laddas ner via App Store eller Google Play. Windowsklienten tillgängliggörs i detta confluence-space och organisationer kan välja att distribuera den själva eller att dela länken med sina användare.

Se SITHS eID-app (Autentiseringsklienter) för mer information.

Anslutning av lokal IdP till Autentiseringstjänsten (direktanslutning)

...

Teknisk Information

Flödesbeskrivning

Image Added

1. Anslutande tjänst (RP) startar flödet med AT genom att skicka en förfrågan till "auth" med information om bland annat subject och autentiseringsförfrågans organisationstillhörighet. 
2. AT svarar på förfrågan till "auth" genom att skicka tillbaka en "orderRef" (referens till utfärdad autentiseringsförfrågan) samt en "autoStartToken". RP förmedlar denna autostarttoken till SITHS eID-klienten m.h.a. appväxling eller QR-kod.
3. RP kollar (förslagsvis kontinuerligt m.h.a pollning) mot "collect" hos AT för att se om AT fått autentiseringen legitimerad av subject. Till "collect" skickas tidigare mottagna "orderRef" som är kopplad till en autentiseringsförfrågan.
4. AT svarar på förfrågan till "collect" genom att skicka tillbaka en status och tillhörande data om huruvida kopplad autentiseringsförfrågan blivit legitimerad, om den blivit legitimerad är autentiseringsflödet nu avklarat.
   1. alternativt kan subject välja att avbryta ("cancel") en legitimering och då avslutas autentiseringsflödet och detta meddelas som svar på "collect".

...

Parametern "checkRevocation" anger huruvida Autentiseringstjänsten skall utföra revokeringskontroll på användarcertifikatet och bör sättas till "true". Det är fullt möjligt att endast utföra revokeringskontrollen i IdP efter autentiseringen är utförd, men det rekommenderas att be Autentiseringstjänsten utföra revokeringskontroll för att eventuella fel i autentiseringen skall upptäckas så tidigt som möjligt i flödet. Vi autentisering via Ineras IdP görs revokeringskontroller t.ex. revokeringskontroller både i IdP och AT.

Parametern "enhancedAuthentication" måste sättas till "true". Den var initialt menad att kunna ange huruvida autostarttoken krävdes eller inte, men klienterna stödjer inte längre flödet utan autostarttoken. Parametern lär försvinna helt i framtida versioner.

...

Autentiseringstjänsten tillhandahåller autentisering för legitimering och underskrift via SITHS eID Windowsklient och SITHS eID Mobilklient (SITHS eID-klienterna) för användare som har e-legitimation från Identifieringstjänst SITHS.

Denna guide har som syfte att stötta organisationer som avser att ansluta en lokal IdP till Inera Autentiseringstjänst (mönster 3 nedan).

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.

...

1. Anmäl intresse, teckna avtal med Inera för valt anslutningsmönster och därmed tjänst:

2. Beställ tjänsten för information om hur en beställning av IdP/Autentiseringstjänst-anslutning går till

3. Fakturering påbörjas.
4. Fyll i förstudiemall Autentiseringstjänst / Förstudie vid anslutning till IdP för testanslutning och skicka in för granskning via etjanster.inera.se/DokumentGranskning.
5. När förstudien är godkänd kan anslutning upprättas mellan den lokala tjänstens testmiljö och testmiljö hos Ineras tjänst (IdP eller Autentiseringstjänsten).
6. Testa anslutningen och funktionen i test.
7. Fyll i separat förstudie för produktionsanslutning, bifoga testrapport som visar att integrationen fungerar som tänkt för de tänkta nyttjandescenarierna.
8. När förstudien mot produktion är godkänd kan anslutning ske mellan produktionsmiljöerna.

...

1. initalt förmedla HSA-id och IP-adress 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. IP-adresslåsning (OBS! I produktion tillåts öppning endast för enstaka utpekade IP-adresser, inga IP-spann)
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".
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

...

Konnektivitet och nätverk

Se Nätverksinställningar för IAM-tjänster för mer detaljerad information.

...

Mobilklienterna laddas ner via App Store eller Google Play. Windowsklienten tillgängliggörs i detta confluence-space och organisationer kan välja att distribuera den själva eller att dela länken med sina användare.

Se SITHS eID-app (Autentiseringsklienter) för mer information.

Anslutning av lokal IdP till Autentiseringstjänsten (direktanslutning)

...

Teknisk Information

Flödesbeskrivning

Image Added

1. Anslutande tjänst (RP) startar flödet med AT genom att skicka en förfrågan till "auth" med information om bland annat subject och autentiseringsförfrågans organisationstillhörighet. 
2. AT svarar på förfrågan till "auth" genom att skicka tillbaka en "orderRef" (referens till utfärdad autentiseringsförfrågan) samt en "autoStartToken". RP förmedlar denna autostarttoken till SITHS eID-klienten m.h.a. appväxling eller QR-kod.
3. RP kollar (förslagsvis kontinuerligt m.h.a pollning) mot "collect" hos AT för att se om AT fått autentiseringen legitimerad av subject. Till "collect" skickas tidigare mottagna "orderRef" som är kopplad till en autentiseringsförfrågan.
4. AT svarar på förfrågan till "collect" genom att skicka tillbaka en status och tillhörande data om huruvida kopplad autentiseringsförfrågan blivit legitimerad, om den blivit legitimerad är autentiseringsflödet nu avklarat.
   1. alternativt kan subject välja att avbryta ("cancel") en legitimering och då avslutas autentiseringsflödet och detta meddelas som svar på "collect".

...