Dokumenthistorik
...
- Anmäl intresse, teckna avtal med Inera för valt anslutningsmönster och därmed tjänst:
Beställ tjänsten för information om hur en beställning av IdP-anslutning går till
- Fakturering påbörjas.
- Fyll i förstudiemall för testanslutning och skicka in för granskning.
- 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).
- Testa anslutningen och funktionen i test.
- Fyll i ny förstudie för produktionsanslutning, bifoga testrapport som visar att integrationen fungerar som tänkt för de tänkta nyttjandescenarierna.
- När förstudien mot produktion är godkänd kan anslutning ske mellan produktionsmiljöerna.
...
- Anslutande IdP måste inom 6 månader kunna anpassa sig till ändringar i nya versioner av API:et hos Autentiseringstjänsten.
- <upprätthålla kontaktvägar via funktionsbrevlåda>Anslutande organisation måste upprätthålla kontaktvägar mot Inera. Funktionsbrevlådor skall anges som kontaktpunkt, och vid ändringar i informationsvägar måste Inera informeras.
Konnektivitet och nätverk
...
- 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.
...
Förutsättningar för direktanslutning av lokal IdP till Autentiseringstjänsten
- Det finns avtal tecknat med Inera.
- HSA-id för tjänsten som önskar ansluta förmedlas för inläsning i Autentiseringstjänsten.
- 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.
- 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.
- 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.
- Den anslutande IdP:n måste hållas uppdaterad i takt med att Autentiseringstjänsten och dess API:er förändras.
- 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.
- 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".
- 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.
...