Dokumenthistorik

Innehåll

...

Detta dokument innehåller framförallt information om direktanslutning till Autentiseringstjänsten (fall 3 ovan). Anslutningsguide till IdP beskriver motsvarande för de två första mönstren.

Övergripande information

Oavsett val av integrationsmönster så finns det hänsynstaganden som behöver hanteras av alla organisationer som avser att använda sig av Autentiseringstjänsten för legitimering och signering, dessa hänsynstaganden följer nedan.

...

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.
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 ny 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.

...

Utöver de angivna generella förutsättningarna i Gemensam anslutningsinformation skall anslutande parts IdP och ansvarig organisation behöver följande förutsättningar vara på plats;

Anslutande

...

Konnektivitet och nätverk

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

SITHS eID-klienterna

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)

En lokal IdP kan anslutas direkt till Autentiseringstjänsten via Ineras proprietära API.

• Lokal IdP ansvarar för eventuellt val av inloggningsmetod
• Lokal IdP förmedlar autostarttoken till SITHS eID-klienterna
  • Se SITHS eID Appväxling - Exempel för inbäddade webbläsare ifall er IdP använder sig av en inbäddad webbläsare.
• Lokal IdP ansvarar för att tolka och förmedla tillitsnivå, utifrån information från användarcertifikatet som levereras från Autentiseringstjänsten.
  • Se Tillitsnivå (LoA) för information om hur Ineras IdP tolkar tillitsnivåer.

Förutsättningar för direktanslutning av lokal IdP till Autentiseringstjänsten

...

lokal IdP SKALL;

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 exempelvis 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. Den anslutande IdP:n måste hållas uppdaterad i takt med att Autentiseringstjänsten och dess API:er förändrasinom 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. Den anslutande IdP:n stödjer 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".Relying party API:et skyddas av mTLS. För att kunna anropa detta API behöver IdP:n presentera sig med ett SITHS funktionscertifikat (SITHS e-id Function CA v1) vars subject matchar tjänstens HSA-id som läses in i Autentiseringstjänsten vid anslutningstillfället.
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

Anslutande organisation SKALL;

1. upprätthålla kontaktvägar mot Inera:
   1. Minst en funktionsbrevlåda anges som kontaktpunkt i produktionsmiljö.
   2. Testanslutningar

Konnektivitet och nätverk

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

SITHS eID-klienterna

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)

En lokal IdP kan anslutas direkt till Autentiseringstjänsten via Ineras proprietära API.

• Lokal IdP ansvarar för eventuellt val av inloggningsmetod
• Lokal IdP förmedlar autostarttoken till SITHS eID-klienterna
  • Se SITHS eID Appväxling - Exempel för inbäddade webbläsare ifall er IdP använder sig av en inbäddad webbläsare.
• Lokal IdP ansvarar för att tolka och förmedla tillitsnivå, utifrån information från användarcertifikatet som levereras från Autentiseringstjänsten.
  • Se Tillitsnivå (LoA) för information om hur Ineras IdP tolkar tillitsnivåer.

Image Added

Teknisk Information

Flödesbeskrivning

...