Jämförda versioner

Nyckel

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


Expandera
titleVisa Revisionshistorik


VersionDatumFörfattareKommentar
0.1

 

Kopierat från Anslutningsguide för Autentiseringstjänst version 1.3

0.2

 

Vissa redaktionella ändringar


Introduktion

Autentiseringstjänsten tillhandahåller autentisering för legitimering och underskrift via med hjälp av SITHS eID Windowsklient och SITHS eID Mobilklient (SITHS eID-klienterna) -apparna för användare som har en giltig SITHS e-legitimation från Identifieringstjänst SITHS

. För mer information om dessa se:

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

...

  1. initalt förmedla HSA-id för inläsning i Autentiseringstjänsten
    1. 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.
  2. 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.
    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.
  3. inom 6 månader kunna anpassa sig till nya versioner av API:et hos Autentiseringstjänsten.
    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.
  4. 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". Se även exempel för tjänster som använder sig av inbäddade webbläsare SITHS eID Appväxling - Exempel för inbäddade webbläsare
  5. hantera
    1. QR kod,
    2. tolkning av tillitsnivå (LoA) och
    3. medarbetaruppdragsval
  6. eventuellt hantera
    1. val av autentiseringsmetod och
    2. integration mot lokal katalogtjänst

...

Se Nätverksinställningar för IAM-tjänster för mer detaljerad information.

SITHS eID-

...

apparna

Användare som ska logga in med Autentiseringslösningen out-of-band som är den lösning som hanteras via anslutningen till Autentiseringstjänsten behöver ha en eller flera av SITHS eID-apparna installerade:

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

...

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.mobiltsithstest.ineratestsiths.org/se.

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?configUrl=/v3/api-docs/swagger-config".

Exempel för Testmiljön: 

  • Dokumentation:

...

...

...

...

Hänsynstaganden vid anrop mot /auth

...