...
I det här fallet kommer användaren få välja bland alla uppdrag som finns kopplade till användarens tjänste-id. Notera i bilden nedan hur HSA-id:t i kolumnen längst ut till höger är detsamma för alla uppdrag.
...
Förval av principalen
IdP :n stödjer filtrering av attributen personalIdentityNumber, employeeHsaId samt organisationIdentifier. Denna funktionalitet är baseras på PrincipalSelection som främst nyttjas för signerings-syften för SAML. För IdP:n har funktionaliteten utökats att även stödja filtrering av dessa attribut för autentisering både för SAML och OIDC.
Med denna filtrering har anslutande system möjlighet att förhandsvälja exempelvis en användares HSA-id om denne har flera HSA-id:n att välja mellan så att valet av tjänste-id hoppas över. Liknande filtrering kan göras genom att ange filtrera ut ett specifikt organisationsnummer om en användare arbetar mot flera olika organisationer. Filtrering av personnummer är endast användbart för signering. Observera att idag stödjs endast dessa tre attribut för att göra filtreringar.
SAML
För att kunna tillämpa denna filtrering med SAML används PrincipalSelection. Se dokumentationen hos DIGG över hur PrincipalSelection fungerar och hur det används. Mer läsvärd information hittas under artikeln för Attributstyrning SAML.
OIDC
När denna filtrering ska användas för OIDC görs det genom att ange de önskade värden i de claims som den anslutande tjänsten begär från IdP:n. Hur detta funkar i praktiken går att se under artikeln för Attributstyrning OIDC.förval av principalen (den inloggade användaren). Förvalet möjliggörs genom att tillåta SAML- och OIDC-anslutningar att skicka in värden som del av deras legitimerings- och signeringsbegäran. Dessa värden används sedan av IdP:n för att kunna göra ett val at tjänste-id och/eller medarbetaruppdraget utan användarinteraktion om möjligt. Alternativt om inte tillräckligt precisa värden skickats in kan IdP:n visa ett urval av valmöjligheter i tjänste-id- eller medarbetaruppdragsväljaren som på förhand har filtrerats med hjälp av de inskickade värdena.
Med denna mekanism har anslutande system möjlighet att på förhand välja vilket personnummer, tjänste-id, medarbetaruppdrag eller organisationsnummer användaren måste slutföra inloggningen med. Om något av de inskickade värden inte kan uppfyllas av användaren (antingen genom att fel kort använts eller uppgifter saknas i HSA) kommer inloggningen eller signeringen att misslyckas.
För respektive protokoll finns det väsentliga skillnader på hur dessa värden skickas in, samt vilka villkor som måste vara uppfyllda för att filtreringen och förvalet ska kunna genomföras. Läs mer om respektive implementation för OIDC och SAML här:
Visningsnamn under legitimerings- och signeringsflödet
...
Namnet som visas kan väljas själv av den anslutande organisationen och anges i förstudien. Gäller det en anslutning med SAML som protokoll ska namnet även finnas i SAML metadatat. Som del av förstudien ska både ett namn på systemet och ett namn på organisationen anges. I praktiken kommer dock endast namnet på organisationen visas för slutanvändaren.
SAML
Vid anslutningsförfarandet hämtas organisationsnamnet som visas under legitimerings- och signeringsflödet från SAML metadatat. IdP:n letar efter ett OrganizationDisplayName under Organization-taggen (se SAML-Profil för konkreta exempel). Namnet som finns angetts under OrganizationDisplayName ska matcha med det som angetts i förstudien under Organisationens visningsnamn. Systemets visningsnamn ska inte vara definierat i SAML metadatat utom ska endast återfinnas i förstudien.
OIDC
Vid anslutningsförfarandet anges organisationens och systemets visningsnamn endast i förstudien. Dessa värden läses sedan in manuellt till IdP:n.
...