|
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).
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.
De tre integrationsmönstren som erbjuds vid autentisering av e-tjänsters användare via Autentiseringstjänsten och SITHS eID-klienterna.
Detta dokument innehåller framförallt information om direktanslutning till Autentiseringstjänsten (fall 3 ovan). Anslutningsguide till IdP beskriver motsvarande för de två första mönstren.
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.
Beställ tjänsten för information om hur en beställning av IdP/Autentiseringstjänst-anslutning går till
Utöver de angivna generella förutsättningarna i Gemensam anslutningsinformation behöver följande förutsättningar vara på plats;
Anslutande lokal IdP SKALL;
Anslutande organisation SKALL;
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.
En lokal IdP kan anslutas direkt till Autentiseringstjänsten via Ineras proprietära API.
Se ex. SAD IdP för information om hur Ineras IdP realiserar autentiseringsflödet med hjälp av Autentiseringstjänsten.
System som har för avsikt att använda sig av iframes för att visa IdP:ns användargränssnitt för slutanvändaren blir inte godkända för att ansluta sig mot IdP:n. Detta med anledning av att vi inte kan lämna några garantier för att IdPn:s funktionalitet bibehålls när iframes används. Detta är ett hårt krav där inga undantag kommer göras. Vidare så avrekommenderar även DIGG emot användningen av iframes, se DIGGs artikel för mer information.
Autentiseringstjänstens API är indelat i tre delar:
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.mobiltsiths.ineratest.org/.
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: https://authservice.test.siths.se/openapi/swagger-ui/index.html?configUrl=/v3/api-docs/swagger-config
URL för anslutning: https://secure-authservice.mobiltsiths.ineratest.org/
Parametern "checkRevocation" anger huruvida Autentiseringstjänsten skall utföra revokeringskontroll på användarcertifikatet och bör sättas till "true". Det är fullt möjligt att utföra revokeringskontrollen i IdP efter autentiseringen är utförd, men det rekommenderas att delegera detta till Autentiseringstjänsten för att eventuella fel i autentiseringen skall upptäckas så tidigt som möjligt i flödet.
Parametern "enhancedAuthentication" måste sättas till "true". Den var initialt menad att kunna ange huruvida autostarttoken krävdes eller inte, men klienterna stödjer inte längre flödet utan autostarttoken. Parametern lär försvinna helt i framtida versioner.
Svarsfälten "qrStartToken" och "qrStartSecret" används till att beräkna animerade QR kod värden.
Pollning mot autentiseringstjänsten ska göras från servern. Det vill säga en användare ska inte kunna påverka hur ofta pollningen mot autentiseringstjänsten sker (annat än att påbörja sin inloggning).
Rekommenderat tidsinterval för pollning är 2 sekunder.
Kopplingen till klienten skapas genom att klienten från IdP får en autostarttoken (som IdP från från Autentiseringstjänsten i svaret ifrån anropet till /auth) som klienten sedan använder i sitt anrop mot Autentiseringstjänsten. Förmedligen av autostarttoken till klienten kan ske på två sätt:
Formatet för custom-protokollet är följande:
siths://?autostarttoken=<autostarttoken> |
Vid inloggning med annan enhet (mobil eller platta) ska en QR kod genereras och exponeras av IdP:n och skannas av med hjälp av Mobilklienten.
QR koden ska innehålla värdet <autostarttoken> eller den RP genererade animerade QR koden.
Statisk QR
Statiska QR koder skall innehålla värdet av <autostarttoken> från auth/sign svaret.
Animerad QR
Svarsfälten "qrStartToken" och "qrStartSecret" används till att beräkna animerade QR kod värden. "qrStartSecret" skall endast vara en secret mellan RP och AT.
Animerade QR koder skall beräknas enlig prefix.qrStartToken.tid.hmacSHA256(qrStartSecret, tid)
Fält | Beskrivning |
---|---|
prefix | Fast värde för närvarande, skall sättas till "auth" |
qrStartToken | UUID som mottages från auth/sign svaret |
tid | Tid i sekunder sedan svaret från auth/sign mottogs |
hmac | Hash som beräknas enligt HMACSHA256(qrStartSecret, tid) Formatteras som en 64 tecken hexadecimal unsigned integer med ledande nollor Java formatering String.format("%064x", new BigInteger(1/*unsigned*/, HMACSHA256(qrStartSecret, tid))); |
Exempelsekvens:
tid=0
auth.db65306e-63ab-48ba-a2c5-fbadab3aa20e.0.bc81b15eb62e07283694433e5b95ae176dfea54096e9601a6bf8e808801779ad
tid=1
auth.db65306e-63ab-48ba-a2c5-fbadab3aa20e.1.71c30896ad541cd0a8794f3cdf9f305085c60a794b860fb8d2b47f14b6bca742
tid=2
auth.db65306e-63ab-48ba-a2c5-fbadab3aa20e.2.fb2d2343e7901f65f9d0aec2fb77bd4bc7dd5103b1b19977a841dfa3659d2037