...
...
...
Expandera | ||
---|---|---|
| ||
|
...
|
...
|
...
Innehållsförteckning | ||
---|---|---|
|
Introduktion
Autentiseringstjänsten tillhandahåller autentisering för legitimering och underskrift via SITHS eID Windowsklient och SITHS eID Mobilklient (SITHS eID-klienterna) för användare som har e-legitimation från Identifieringstjänst SITHS.
Denna guide har som syfte att stötta organisationer som avser att ansluta en lokal IdP till Inera Autentiseringstjänst (mönster 3 nedan).
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.
...
- 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/Autentiseringstjänst-anslutning går till
- Fakturering påbörjas.
- Fyll i förstudiemall Autentiseringstjänst / Förstudie vid anslutning till IdP för testanslutning och skicka in för granskning via etjanster.inera.se/DokumentGranskning.
- 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 separat 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.
...
- initalt förmedla HSA-id och IP-adress för inläsning i Autentiseringstjänsten
- Relying party API:et skyddas av bl a mTLS. För att kunna anropa detta API behöver IdP:n presentera sig med ett SITHS funktionscertifikat (utgivet av SITHS e-id Function CA v1) vars subject matchar tjänstens HSA-id som läses in i Autentiseringstjänsten vid anslutningstillfället.
- IP-adresslåsning (OBS! I produktion tillåts öppning endast för enstaka utpekade IP-adresser, inga IP-spann)
- vara en central IdP för den anslutande organisationen. Varje kund tillåts ha en ansluten IdP, med eventuellt undantag för 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.
- inom 6 månader kunna anpassa sig till nya versioner av API:et hos Autentiseringstjänsten.
- 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.
- stödja 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".
- hantera
- QR kod,
- tolkning av tillitsnivå (LoA) och
- medarbetaruppdragsval
- eventuellt hantera
- val av autentiseringsmetod och
- integration mot lokal katalogtjänst
- val av autentiseringsmetod och
...
Konnektivitet och nätverk
Se Nätverksinställningar för IAM-tjänster för mer detaljerad information.
...
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 SITHS eID-app (Autentiseringsklienter) för mer information.
Anslutning av lokal IdP till Autentiseringstjänsten (direktanslutning)
...
Infoga utdrag | ||||
---|---|---|---|---|
|
Hänsynstaganden vid anrop mot /auth
...