Jämförda versioner

Nyckel

  • Dessa rader lades till.
  • Denna rad togs bort.
  • Formateringen ändrades.
Kommentera: Första halvan omjobbad lite

Dokumenthistorik

...

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

Övergripande information och val av integrationsmönster

...

  1. Anmäl intresse, teckna avtal med Inera för valt anslutningsmönsteroch därmed tjänst:
    1. 1-2: Se Beställ tjänsten för information om hur en beställning av IdP-anslutning går till

    2. 3: Se Beställ anslutning SITHS TODO (denna är placeholder)

  2. Fakturering påbörjas.
  3. Fyll i relevant förstudiemall (anslutning mot IdP, 1 och 2 ovan, eller anslutning mot Autentiseringstjänsten) för testanslutning och skicka in för granskning.
  4. 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).
  5. Testa anslutningen och funktionen i test.
  6. Fyll i ny förstudie för produktionsanslutning, bifoga testrapport som visar att integrationen fungerar som tänkt för de tänkta nyttjandescenarierna.
  7. När förstudien mot produktion är 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

Förutsättningar för alla anslutningsmönster

  • Användarna har SITHS eID personcertifikat 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 Funktionscertifikatfunktionscertifikat.
  • Det finns en organisation regional/lokal supportorganisation och en plan utrullingsplan för att distribuera SITHS eID-klienterna till användarna samt hålla dessa och utbilda dem i användningen.
  • Det finns en livscykelprocess för att hålla eID-klienterna uppdaterade.

Nätverk

  • Användarnas SITHS eID-klienter behöver kunna kommunicera med Autentiseringstjänsten och Utfärdandeportalen.
  • För att kunna utfärda/administrera Mobilt SITHS eID så måste användarnas browser kunna komma åt Utfärdandeportalen samt den instans av Ineras IdP som Utfärdandeportalen använder sig av för autentisering.För de integrationer som ansluter till Ineras IdP så måste denna vara åtkomlig från användarnas enheter.
  • Organisationer som sitter på Sjunet och internet samtidigt behöver välja över vilket nät och hur trafiken skall routas

Detta kan sammanfattas på matrisform.

...

Se 

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 mer detaljerad information.

Distribution av SITHS eID-klienterna

...


Mönstren finns på Att ansluta e-tjänster så nedanstående kanske ska kortas/tas bort/komplettera den sidan?

Expandera
titleMönster 1-2

Anslutning av lokal e-tjänst till Ineras IdP

En e-tjänst kan ansluta till Ineras IdP som en SAML SP (Service Provider) eller OIDC RP (Relying Party). Vilka autentiseringsmetoder som är tillgängliga för användarna konfigureras i IdP per e-tjänst, det går således att välja vid anslutningen att endast använda ett urval av de autentiseringsmetoder som Ineras IdP tillhandahåller.

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


Anslutning av lokal e-tjänst till Ineras IdPImage Modified

Å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)

En lokal IdP kan anslutas som en OIDC RP eller SAML SP mot Ineras IdP och agera som en "proxy-IdP". Anslutningen sker (med några undantag) som en vanlig anslutning av en e-tjänst till Ineras IdP.

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



Image Modified


Tillgängliga attribut för en lokal IdP

Förutom attribut som alltid anges i SAML-biljetten eller OIDC-tokens per default (se Attributlista), så är följande attribut tillgängliga för en lokal IdP att begära från Inera IdP:

SAML AttributnamnOIDC Attributnamn
urn:sambi:names:attribute:authnMethod

amr

urn:sambi:names:attribute:x509IssuerName

http://www.w3.org/2000/09/xmldsig#X509IssuerName

x509IssuerName

http://www.w3.org/2000/09/xmldsig#X509SubjectName

x509SubjectName
urn:sambi:names:attribute:levelOfAssuranceacr
urn:credential:givenNamecredentialGivenName
urn:credential:surnamecredentialSurname
urn:credential:personalIdentityNumbercredentialPersonalIdentityNumber
urn:credential:displayNamecredentialDisplayName
urn:credential:organizationNamecredentialOrganizationName
urn:credential:certificatePoliciescredentialCertificatePolicies


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
  • Lokal IdP ansvarar för att tolka och förmedla tillitsnivå, utifrån information från användarcertifikatet som levereras från Autentiseringstjänsten.


Anslutning av lokal IdP till AutentiseringstjänstenImage Modified


Förutsättningar för

...

direktanslutning av lokal IdP till Autentiseringstjänsten

  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.

...