Jämförda versioner

Gammal version 68

changes.mady.by.user Former user

Sparat den

jämfört med

Ny version 69

changes.mady.by.user Former user

Sparat den

Nyckel

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

Dokumenthistorik

...

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

Övergripande information och val av integrationsmönster

...

Integrationsmönster

Läs Att ansluta e-tjänster för en övergripande beskrivning av tillgängliga integrationsmönster och hjälp med att välja integrationsmönster.

...

  1. Anslutning av en eller flera lokal e-tjänster till Ineras IdP
  2. Anslutning av lokal IdP till Ineras IdP (proxy-anslutning)
  3. Anslutning av lokal IdP till Autentiseringstjänsten (direktanslutning)

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 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.Detta dokument innehåller framförallt information om direktanslutning till Autentiseringstjänsten (fall 3 ovan).


Ö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. 1-2: Se

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

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

  3. Fakturering påbörjas.
  4. 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.
  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 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.

Förutsättningar

...

  • 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 funktionscertifikat.
  • Det finns en regional/lokal supportorganisation och en utrullingsplan för att distribuera SITHS eID-klienterna till användarna 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.
  • 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.

...

Utöver de angivna generella förutsättningarna i Gemensam anslutningsinformation skall anslutande parts IdP och ansvarig organisation;

  • Anslutande IdP måste inom 6 månader kunna anpassa sig till ändringar i API:et hos Autentiseringstjänsten.
  • <upprätthålla kontaktvägar via funktionsbrevlåda>

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 nedan för länkar till specifik information kring respektive applikation.

Windowsklienten

Användarhandbok - SITHS eID Windowsklient.

SAD - SITHS eID Windowsklient

/wiki/spaces/ST/pages/3475212849

Mobilklienten

Användarhandbok - SITHS eID Mobilklient

SAD - SITHS eID Mobilklient

/wiki/spaces/ST/pages/3475212861

Nerladdningslänkar

Anslutning via Inera IdP

Se Att ansluta e-tjänster och Anslutningsguide till IdP för information om hur anslutningar till Ineras IdP går tillSe SITHS eID app (Autentiseringsklienter) för mer information.


Anslutning av lokal IdP till Autentiseringstjänsten (direktanslutning)

...

  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.

...

  1. Anslutande tjänst (RP) startar flödet med AT genom att skicka en förfrågan till "auth" med information om bland annat subject och autentiseringsförfrågans organisationstillhörighet. 
  2. AT svarar på förfrågan till "auth" genom att skicka tillbaka en "orderRef" (referens till utfärdad autentiseringsförfrågan) samt en "autoStartToken". RP förmedlar denna autostarttoken till SITHS eID-klienten m.h.a. appväxling eller QR-kod.
  3. RP kollar (förslagsvis kontinuerligt m.h.a pollning) mot "collect" hos AT för att se om AT fått autentiseringen legitimerad av subject. Till "collect" skickas tidigare mottagna "orderRef" som är kopplad till en autentiseringsförfrågan.
  4. AT svarar på förfrågan till "collect" genom att skicka tillbaka en status och tillhörande data om huruvida kopplad autentiseringsförfrågan blivit legitimerad, om den blivit legitimerad är autentiseringsflödet nu avklarat.
    1. alternativt kan subject välja att avbryta ("cancel") en legitimering och då avslutas autentiseringsflödet och detta meddelas som svar på "collect".

Se ex. SAD IdP för information om hur Ineras IdP realiserar autentiseringsflödet med hjälp av Autentiseringstjänsten.

Autentiseringstjänstens API

...

  1. Relying Party API: API för att RP ska kunna starta och konsumera autentiserings- och signerings-förfrågningar. (../rp)
  2. Client API: API API för att en klient ska kunna resolvera autentiseringsresolvera autentiserings- och signerings-förfrågningar. (../auth)
  3. Registration Authority: API för att registrera och aktivera certifikat. (../ra)

Anslutande IdP:er kommunicerar via Relying Party API. 

Anrop där förmedling av certifikat krävs ska ske mot adresser som är prefixade med "secure". T.ex. för test: https://secure-authservice.idpmobiltsiths.ineratest.org/.

Swaggerdokumentation
Ankare
swaggerdokumentation
swaggerdokumentation

Autentiseringstjänstens API-dokumentation tillgängliggörs via swagger på Autentiseringstjänsten med följande sökväg: "/openapi/swagger-ui/index.html?url=/v3/api-docs/rp#".

Exempel för Testmiljön: 

Dokumentation: https://authservice.idpmobiltsiths.ineratest.org/openapi/swagger-ui/index.html?url=/v3/api-docs/rp#

URL för anslutning: https://secure-authservice.idpmobiltsiths.ineratest.org/

Hänsynstaganden vid anrop mot /auth

...