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 signeringsbegäran specificera vilken tjänsteidentitet som skall användas för signeringen, för att undvika användarinteraktioner i underskriftsflödet.

IdP ser de tillhandahållna uppgifter som tvingande uppgifter som måste uppfyllas för att slutföra signeringen. Vidare så gäller att ifall flera fält specifierats via PrincipalSelection måste samtliga uppfyllas, det räcker alltså inte ifall bara något eller några av PrincipalSelection-värden matchar. Skulle det visa sig att användarens uppgifter inte stämmer överens med det som skickats via PrincipalSelection kommer signeringen markeras som misslyckad.

Under filtreringen försöker IdP:n göra ett val automatiskt baserad på den informationen som tagits emot i den AuthnRequest som skickats in. Om det är möjligt kan alltså exempelvis ett specifikt tjänste-id pekas ut och användaren slipper göra ett aktivt val i IdP:n. Om den angivna informationen inte är tillräckligt precis för att göra ett automatiskt val kommer användaren presenteras med tjänste-id eller medarbetaruppdragsväljaren i IdP:ns GUI. I väljaren presenteras endast alterantiven som på förhand har filtrerats med hjälp av de inskickade värden i PrincipalSelection.

Läs en mer detaljerad beskrivning om förval av principalen här: Attributstyrning SAML

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.

Webbläsaren stöds inte