Publika användargränssnittet

...

• RP/SP begär endast organizationHsaId. Användaren presenteras med organisationsval.

• RP/SP begär endast commissionHsaId. Användaren presenteras med medarbetaruppdragsval.

• RP/SP begär endast organizationName. Användaren presenteras med organisationsval.

• RP/SP begär organizationName och organizationHsaId. Bägge attribut kan erhållas via organisationsval, därför presenteras användaren med organisationsval.

• RP/SP begär organizationName och commissionHsaId. commissionHsaId är exklusivt för medarbetaruppdragsvalet medans organizationName kan erhållas både via organisations- och medarbetaruppdragsval. Därför presenteras användaren med medarbetaruppdragsval.

• RP/SP begär organizationHsaId och commissionHsaId. organizationHsaId och commissionHsaId skulle leda till två separata val i användargränssnittet vilket inte är tillåtet. Därför är detta en illegal kombination och leder till en misslyckas inloggning.

Förval av principalen

Ankare
principal-selection principal-selection

Som RP/SP finns möjligheten att på förhand ange information om användaren som inloggningen ska slutföras med. IdP stödjer idag förval av personnummer, tjänste-id, medarbetaruppdrags-id, organisationsnummer eller organisationstillhörighet och skickas in som value i de respektive attribut. Dess värden kan användas enskilt men också kombineras med varandra. IdP ser de tillhandahållna uppgifter som tvingande uppgifter som måste uppfyllas för att slutföra inloggningen. Vidare så gäller att ifall flera av dessa principal-fält specifierats måste samtliga uppfyllas, det räcker alltså inte ifall bara något eller några av principal-värden matchar. Skulle det visa sig att användarens uppgifter inte stämmer överens med det som skickats via de attribut kommer inloggningen markeras som misslyckad. Under filtreringen försöker IdP:n göra ett val automatiskt baserad på den informationen som tagits emot i legitimeringsbegäran. 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 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 av tjänste-id, organisation och/eller medarbetaruppdrag 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- organisations- eller medarbetaruppdragsväljaren som på förhand har filtrerats med hjälp av de inskickade attributvärdenvärdena.

Attribut som används i syfte att kunna förvälja principalen ändrar inte beteendet även om claimet har markerats med essential-flaggan. Detta för att förenkla logiken och få ett konsistent beteende för hur förvalet fungerar. Oavsett om "true" eller "false" skickats in under "essential" kommer inloggningen misslyckas om inte IdP hittar matchande uppgifter om identiteten eller medarbetaruppdragen.

Värt att notera är att attribut som används för förvalet av principalen samtidigt också blir del av del attribut som RP/SP:n får som svar i sin biljett. För OIDC finns det alltså en hård koppling mellan förvalet och de attribut som den slutförda inloggningen kommer resultera i vilket är en skillnad mot hur denna mekanism fungerar i SAML. Ett vidare krav för att ett claim ska kunna användas för förvalet av principalen är att RP/SP:n har tillstånd att få ut det aktuella attributet från IdP. Skulle RP/SP:n skicka in ett claim med ett värde men där RP/SP:n inte har tillstånd att få ut det claimet kommer IdP sålla bort och ingen filtrering eller förval kommer ske som tar hänsyn till det specifika claimet.

• Exempel där filtrering/förval kommer genomföras: RP/SP har tillstånd hos IdP att begära employeeHsaId och commissionHsaId. RP/SP skickar in ett claimvärde för både employeeHsaId och commissionHsaId. IdP använder värdet av både employeeHsaId och commissionHsaId som underlag till förvalet av principalen.

• Exempel där filtrering/förval delvis kommer genomföras: RP/SP har tillstånd hos IdP att begära employeeHsaId. RP/SP skickar in ett claimvärde för både employeeHsaId och commissionHsaId. IdP använder värdet av employeeHsaId som underlag till förvalet av principalen.

• Exempel där ingen filtrering/förval kommer genomföras: RP/SP har tillstånd hos IdP att begära employeeHsaId. RP/SP skickar in ett claimvärde för commissionHsaId. IdP använder inget värde som underlag till förvalet av principalen.

Notera även att filtrering på organisation (orgAffiliation, organizationIdentifier) endast kan leda till en lyckad inloggning om användaren i fråga har medarbetaruppdrag konfigurerat på sig. Det är en känd begränsning då uppgifter om organisationstillhörighet endast erhålls via medarbetaruppdrag genom HSA. Som ett exempel så skulle alltså inloggningen misslyckas i fallet då en organisation matas in i förvalet av principalen men användaren saknar medarbetaruppdrag helt och hållet (eller även när inget av medarbetaruppdragen tillhör den inmatade organisationen).

Attribut

De värden som avläses i IdP:n för förval av principalen är:

Exempel på användningsfall

Låt oss anta att användaren har en uppsättning i HSA som grovt förenklat ser ut som strukturen nedan. Vi antar också att användaren använder sitt eget SITHS eID med personnummret som finns speficierat nedan.

För att hålla exemplen enkla används enbart employeeHsaId, commissionHsaId, organizationIdentifier och personalIdentityNumber som de attribut som begärs av RP/SP:n. Exemplen i tabellen är bara ett litet urval av möjliga scenarion och täcker inte alla användningsfall eller kombinationer.

• Person: 19121212-1212

  • Tjänste-id: employeeHsaId 111

    • Medarbetaruppdrag: commissionHsaId aaa, organisationsnummer 12345

    • Medarbetaruppdrag: commissionHsaId bbb, organisationsnummer 12345
      

  • Tjänste-id: employeeHsaId 222

    • Medarbetaruppdrag: commissionHsaId ccc, organisationsnummer 12345

  • Tjänste-id: employeeHsaId 333

    • Medarbetaruppdrag: commissionHsaId ddd, organisationsnummer 67890

  • Tjänste-id: employeeHsaId 444 (saknar medarbetaruppdrag)

Expandera

Inmatning i legitimeringsbegäran

Resultat

credentialPersonalIdentityNumber: 19121212-1212

Ingen användarinteraktion krävs. Biljett erhålles med credentialPersonalIdentityNumber 19121212-1212.

credentialPersonalIdentityNumber: 19000101-0001

Inloggningen misslyckas, personnummer matchar inte identiteten.

employeeHsaId: 111

Ingen filtrering utförs. RP/SP har inte tillstånd att begära employeeHsaId. Tom biljett erhålles.

commissionHsaId: aaa

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:

• Attributstyrning SAML

• Attributstyrning OIDC