Dokumenthistorik

Innehåll

...

• e-tjänsten väljer vilka autentiseringsmetoder som skall vara valbara för användare.
• e-tjänsten anger i sitt metadata (om SAML) eller i autentiseringsanropet (om OIDC) vilka användarattribut som önskas.
• Inera IdP tillhandahåller användarattribut som finns i den nationella HSA-katalogen samt presenterar uppdragsval för användaren.
• Inera IdP tolkar och förmedlar tillitsnivå (LoA) utifrån användarens certifikat.

Förstudie vid anslutning till IdP.

Se Guide till IdP för vidare information om anslutning till Ineras IdP.

Åtkomst till Autentiseringstjänsten för existerande anslutningar e-tjänst → IdP

E-tjänster som redan nu är anslutna till IdP för autentisering via mTLS m.h.a. Net iD Enterprise behöver utföra följande steg för att få åtkomst till autentisering via Autentiseringstjänsten och SITHS eID-klienterna:

1. Se över kraven som ställs gällande distribution och uppdatering av SITHS eID-klienterna.
2. Se över nätverksinställningar.
3. Inkom med en ny uppdaterad förstudie för testmiljö(er) där ni fyller i vilka autentiseringsmetoder ni vill ha aktiva.
4. Efter godkänd förstudie aktiveras autentiseringmetoderna för den anslutna e-tjänsten i IdP.
5. Verifiera funktionen i testmiljöerna
6. Inkom med en ny uppdaterad förstudie för prodmiljön där ni fyller i vilka autentiseringsmetoder ni vill ha aktiva.
   1. Bifoga testrapport från testmiljöerna.
   2. Ange önskat datum och tidpunkt för aktivering.
7. Efter godkänd förstudie så aktiveras autentiseringsmetoderna i IdP för den anslutna e-tjänsten.

Anslutning av lokal IdP till Ineras IdP (proxy-anslutning)

...

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.

...