Introduktion

IdP:n har stöd för anslutning till Underskriftstjänst [P4] som följer SwedenConnects SAML-profil för underskrift [S11]. Detta innebär att kunder kan ansluta mot integrerande Underskriftstjänst och utnyttja IdP:n för autentisering mot denna.
Underskrifter kan endast ske via autentiseringsmetoderna som nyttjar SITHS eID via Autentiseringstjänsten [P3].

Relevanta skillnader mot inloggningsflödet

Flödet för underskrift är i stort identiskt med flödet för Autentisering med SITHS eID. Följande listar relevanta skillnader:

Enbart SAML stöds vid underskrift.
Underskriftsfunktionaliteten förlitar sig på Autentiseringstjänsten och SITHS eID-klienterna, och fungerar alltså inte med mTLS-autentisering.
Metadata för underskriftsintegration publiceras separat och innehåller en delmängd av attributen som IdP:n kan producera.
Underskrift följer standarden för Sweden Connect [S10] istället för Sambi [S7] .
Det publiceras flera endpoints för underskrifts SAML-anrop, en för varje autentiseringsmetod. Detta för att kunna välja autentiseringsmetod redan vid anropet då det inte är önskvärt att användaren får val vid just underskrift.
Vid anropet till IdP skickas en personidentifierare med som måste matcha identiteten som sedan autentiseras. Denna identifierare skickas i enskilda fall vidare till Autentiseringstjänsten (se här) och efter autentisering valideras den i IdP.
Vid anropet skickas ett meddelande om vad som ska undertecknas med, detta MÅSTE visas upp för användaren. Meddelandet skickas vidare till Autentiseringstjänsten för vidare förmedling till autentiseringsklienterna.

Anvisning om vilken individ som skall utföra underskriften, via PrincipalSelection

Vid anrop till IdP kan filtrering av data skickas med i enlighet med SwedenConnects SAML-profil för underskrift [S11]. Detta sker i fältet <PrincipalSelection> i Autentiseringsbegäran.
Dessa attribut används för att redan i autentiseringsbegäran specificera vilken tjänsteidentitet som skall användas för autentiseringen, för att undvika användarinteraktioner i underskriftsflödet.

De attribut som avläses i IdP:n för PrincipalSelection är:

Attribut	Används för
http://sambi.se/attributes/1/personalIdentityNumber	Personidentifierare
http://sambi.se/attributes/1/employeeHsaId	Personidentifierare
urn:orgAffiliation	Filtrering av Medarbetaruppdrag
http://sambi.se/attributes/1/organizationIdentifier	Filtrering av Medarbetaruppdrag

Övriga attribut kommer att ignoreras.

Attributet SAML Subject kan användas för att förmedla Personidentifierare med samma påföljder som om PrincipalSelection används.

Endas ETT sätt ska användas för att förmedla Personidentifierare.
Endast ETT sätt ska användas för att förmedla OrganisationsIdentifierare.

Underskrift med flera kort

IdP stödjer signering med flera kort, exempelvis för att kvittera tillhandahållande av ett nytt SITHS-kort till en användare via SITHS eID Portal. För att hantera det här specialfallet görs ytterligare steg som skiljer sig från det normala signeringsflödet:

IdP skickar den tillhandahållna personidentifieraren som ska utföra signaturen till Autentiseringstjänsten.
IdP skickar en extra flagga vid autostarten av autentiseringsklienten för Windows för att signalera att samtliga kortens certifikat ska skickas till Autentiseringstjänsten. Det kompletta anropet för autostarten ser då ut som följer: siths://?autostarttoken=<uuid>&multicard=true. I normalfallet skickas endast certifikaten från kortet som sitter i den primära kortläsaren till Autentiseringstjänsten.
Autentiseringstjänsten tar senare emot samtliga istoppade kortens certifikat. Autentiseringstjänsten väljer då med hjälp av personidentifieraren som tillhandahållits av IdP:n ut vilket av korten och därmed vilket certifikat som signaturen ska slutföras med. I sitt svar till autentiseringsklienten för Windows skickar Autentiseringstjänsten med informationen om vilket certifikat som valts ut.

Möjligheten till att få nyttja underskrift flera kort konfigureras per SAML-anslutning och görs via IdP:ns administrationsgränssnitt.

Funktioner som inte stöds

Saml2 Scoping stöds inte.

<saml2p:Scoping>
	<saml2p:RequesterID>http://www.origsp.com/sp</saml2:RequesterID>
</saml2p:Scoping>

SignMessage

Attributet SignMessage kommer visas för användaren. Ingen formatering av meddelandet stöds, enbart plain text.

authenticationMessage

Ska endast användas vid kritiska inloggningsmoment. Exempelvis när en användare eller ID-administratör gör en förnyad autentisering i samband med utfärdande av SITHS eID i SITHS eID Portal.

Attributet authenticationMessage kommer att visas för användaren i SITHS eID-appen. Ingen formatering av meddelandet stöd, enbart plain text.

Till skillnad från en signeringsbegäran kan authenticationMessage skickas in även när protokollet OIDC används. I dessa fall förmedlas meddelandet med claimet authenticationMessage.

När protokollet SAML används förmedlas meddelandet på samma sätt som vid en signeringsbegäran. Det vill säga med ett SignMessage extension.

Version	Datum	Utförare	Kommentar
0.1	Feb 23, 2023	@Former user (Deleted)	Kopierat från IdP 2.4
0.2	Oct 30, 2023	@Former user (Deleted)	Brutit ut information kring LoA Administration till egen dokumentstruktur
1.0	Nov 17, 2023	@Former user (Deleted)	Efter dokumentationsmötet 16/11 godkänns detta dokument

2.5 SAD - IdP