Dokumenthistorik

Innehåll

...

Övergripande information och val av integrationsmönster

Läs Autentisering via SITHS eID för en bredare beskrivning av tillgängliga integrationsmönster och hjälp med att välja vilket integrationsmönster som är bäst för ert behov.

Det finns tre integrationsmönster för organisationer som vill koppla e-tjänster mot autentisering via Autentiseringstjänsten och SITHS eID-klienterna.

...

1. Anmäl intresse, teckna avtal med Inera
2. Fyll i relevant förstudiemall (anslutning mot IdP eller anslutning mot Autentiseringstjänsten) för testanslutning och skicka in för granskning.
3. 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, beroende på val av integrationsmönster).
4. Testa anslutningen och funktionen i test.
5. Fyll i ny förstudie för produktionsanslutning, bifoga testrapport som visar att integrationen fungerar som tänkt.
6. När förstudien mot produktion är godkäns godkänd kan anslutning ske mellan produktionsmiljöerna.

Se Beställ tjänsten för ytterligare information om hur en beställning av IdP-anslutning går till.

Förutsättningar

• Användarna har SITHS eID på kort (används för inloggning via windowsklienten, samt för att utfärda Mobilt SITHS eID).
• Den anslutande tjänsten har ett SITHS Funktionscertifikat.
• Det finns en organisation och en plan för att distribuera SITHS eID-klienterna till användarna samt hålla dessa uppdaterade.

...

• Lokal IdP implementerar en SAML-SP eller en OIDC-RP som ansluts till Ineras IdP.
• Lokal IdP väljer vid anslutningen vilka autentiseringsmetoder som Inera IdP skall tillhandahålla för användare.
• Inera IdP tillhandahåller attribut som rör autentisering av användaren.
• Övriga användarattribut hämtar lokal IdP från den lokala katalogtjänsten. Lokal IdP ansvarar därmed för eventuellt uppdragsval.
• Lokal IdP beräknar tillitsnivå (LoA) utifrån certifikatsattribut som Ineras IdP tillhandahåller.
  • Se Tillitsnivå (LoA) för information om hur Ineras IdP tolkar tillitsnivåer.

...

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

...

1. Det finns avtal tecknat med Inera.
2. HSA-id för tjänsten som önskar ansluta förmedlas för inläsning i Autentiseringstjänsten.
3. Den anslutande tjänsten är 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.
4. Den anslutande IdP:n måste hållas uppdaterad i takt med att Autentiseringstjänsten och dess API:er förändras.
   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.
5. Den anslutande IdP:n stödjer 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".
6. 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.

...