Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.

Dokumenthistorik

...

I integrationsmönster 1 och 2 ovan så kommunicerar den lokala e-tjänsten eller IdP:n med Ineras IdP via SAML- eller OIDC-protokollet. Ineras IdP är i sin tur ansluten till Autentiseringstjänsten och tillhandahåller dess autentiseringsmetoder som den lokala tjänsten kan välja att exponera för sina användare, se Guide Anslutningsguide till IdP för detaljer. I integrationsmönster 3 så ansluter den lokala IdP:n direkt till Autentiseringstjänsten via Ineras proprietära API. Alla tre integrationsmönstren beskrivs närmare under respektive rubrik nedan.

...

Kommunikation behövs mellan..eID klientAutentiseringstjänstUtfärdandeportalBrowserIneras IdP
eID klient
jaja

Autentiseringstjänstja


(bock)
Utfärdandeportalja

ja(bock)
Browser

ja
ja
Ineras IdP
(bock)(bock)ja

Se Adresser, brandväggsöppningar & routing för Nätverksinställningar för IAM-tjänster för mer detaljerad information.

...

Se Att ansluta e-tjänster och Guide Anslutningsguide till IdP för information om hur anslutningar till Ineras IdP går till.

...

  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.

...