...

Principen är att användaren enbart ska behöva göra det minsta möjliga valet för att uppfylla kraven som ställts på inloggningen. För att uppnå det kommer IdP:n presentera användaren med det enklaste valet baserat på de claims attribut som RP/SP begärt från IdP:n. IdP:n föredrar rent praktiskt att presentera användaren med val av tjänste-id före valet av organisation. Och vidare så föredras tjänste-id eller organisationsvalet före medarbetaruppdragsvalet.

Valen kan också beskrivas som en hierarki. Det enklaste valet som kan göras är att inget val behöver göras alls. Ett sådant fall kan innebära att RP/SP:n endast begär användarens personnummer och namn som ska hämtas direkt från certifikatet. Om RP/SP:n begär ett claim attribut på anställningsnivå, exempelvis employeeHsaId så ställs användaren istället inför ett val av tjänste-id men kommer på samma gång kunna uppfylla ytterligare claims attribut som begärts från användarens certifikat. Samma sak gäller om RP/SP:n begär ett claim attribut för organistationstillhörighet, exempelvis organisationsnumret. Då ställs användaren istället inför ett val av organisation men valet kommer fortfarande kunna uppfylla ytterligare claims attribut från certifikats och tjänste-id-nivån. Den högsta nivån är valet av medarbetaruppdrag varigenom även claims attribut från certifikats-, tjänste-id och organisations-nivån kan erhållas. Hierarkin kan beskrivas på följande vis där alltså varje efterföljande nivå samtidigt kan uppfylla samtliga tidigare nivåer:

...

• Användaren har endast ett HSA-ID tillhörande en organisation med två medarbetaruppdrag konfigurerat på sig. RP/SP:n begär endast employeeHsaId från IdP:n. Då de två medarbetaruppdragen inte har någon betydelse för den här legitimeringen väljer IdP:n automatiskt HSA-ID:t och skapar användarens biljett.
• Användaren har endast ett HSA-ID tillhörande en organisation med två medarbetaruppdrag konfigurerat på sig. RP/SP:n begär employeeHsaId och organizationHsaId från IdP:n. Då de två medarbetaruppdragen inte har någon betydelse för den här legitimeringen väljer IdP:n automatiskt HSA-ID:t med den tillhörande organisationen och skapar användarens biljett.
• Användaren har två HSA-ID:n med ett medarbetaruppdrag konfigurerat per HSA-ID. RP/SP 1 begär i en första legitimering endast employeeHsaId från IdP:n. Vid första legitimeringen behöver användaren göra ett val då det finns två HSA-ID:n och RP/SP:n inte har specifierat något föredraget employeeHsaId via Förval av principalen. Senare begär RP/SP 2 i en andra legitimering employeeHsaId och commissionHsaId från IdP:n. I detta fall känner IdP igen att det finns en befintlig legitimering och kan därmed använda det tidigare valda employeeHsaId som grund för den andra legitimeringen. IdP ser att HSA-ID:t endast hade ett medarbetaruppdrag och väljer därför automatiskt medarbetaruppdraget från det HSA-ID:t som användaren valde vid första legitimeringen och skapar användarens nya biljett.
• Användaren har två HSA-ID:n utan några medarbetaruppdrag. RP/SP 1 begär i en första legitimering endast employeeHsaId. Vid första legitimeringen behöver användaren göra ett val då det finns två HSA-ID:n och RP/SP:n inte har specifierat något föredraget employeeHsaId via Förval av principalen. Senare begär RP/SP 2 i en andra legitimering employeeHsaId och organizationHsaId från IdP:n. I detta fall känner IdP igen att det finns en befintlig legitimering och kan därmed använda det tidigare valda employeeHsaId som grund för den andra legitimeringen. IdP:n hämtar information om organisationstillhörigheten för användarens HSA-ID och kan på så sätt direkt skapa nya biljetten.

...

Användaren ställs inför ett val av tjänste-id om ett eller flera claims attribut begärts av IdP:n som kan erhållas via en persons anställning. Uppgifterna kring anställningen hämtas från HSA och det är bland dessa uppgifter användaren senare behöver göra sitt val. Ett val måste göras i de fallen då det finns mer än en konfigurerad anställning (m.a.o. flera tjänste-id:n) för en och samma person. Även om det finns uppgifter som är identiska mellan de olika posterna (ex. för- och efternamn, personnummer, m.m.) så finns det uppgifter som skiljer sig (ex. employeeHsaId, telefonnummer, m.m.)

...

• Användaren har endast ett tjänste-id kopplat till sig.
• RP/SP:n har i inloggningsbegäran specifierat ett employeeHsaId med vilket inloggningen måste slutföras med, läs mer om denna mekanism här: Förval av principalen.
• RP/SP:n begär attribut på anställningsnivå men användaren har en redan giltig SSO-session hos IdP:n. Vid tidigare legitimeringar måste claims attribut på samma nivå ha uppfyllts som i sin tur kan uppfylla den nya inloggningsbegäran.

...

• Användaren har endast en anställning och en organisationstillhörighet.
• RP/SP:n har i inloggningsbegäran specifierat ett employeeHsaId, organizationHsaId eller orgAffiliation med vilket inloggningen måste slutföras med, läs mer om denna mekanism här: Förval av principalen.
• RP/SP:n begär attribut på anställnings- eller organisationsnivå men användaren har en redan giltig SSO-session hos IdP:n. Vid tidigare legitimeringar måste claims på samma nivå ha uppfyllts som i sin tur kan uppfylla den nya inloggningsbegäran.

...

Medarbetaruppdragsvalet kan i vissa lägen även visa enskilda tjänste-idn utan tillhörande medarbetaruppdrag. I de fallen har RP/SP:n begärt claims på både anställnings- och medarbetaruppdragsnivån men där de claims som tillhör medarbetaruppdragsnivån inte är satt som obligatoriska. I de fallen ska alltså valet av ett enskilt tjänste-id fortfarande leda till en giltig legitimering.

...

• Användaren har endast en anställning och ett medarbetaruppdrag.
• RP/SP:n har i inloggningsbegäran specifierat ett commissionHsaId med vilket inloggningen måste slutföras med, läs mer om denna mekanism här: Förval av principalen.
• RP/SP:n har i inloggningsbegäran specifierat ett employeeHsaId med vilket inloggningen måste slutföras med och det employeeHsaId:t i sin tur endast har ett medarbetaruppdrag. Läs mer om denna mekanism här: Förval av principalen.
• RP/SP:n begär attribut på anställnings-, organisations- eller medarbetaruppdragsnivå men användaren har en redan giltig SSO-session hos IdP:n. Vid tidigare legitimeringar måste claims på samma nivå ha uppfyllts som i sin tur kan uppfylla den nya inloggningsbegäran.

...

Exempel på scenarion:

• 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 claims 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 claims. 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 claims kommer inloggningen markeras som misslyckad.

...

Värt att notera är att claims som används för förvalet av principalen samtidigt också blir del av del claims som RP/SP:n får som svar i sina OIDC tokens. För OIDC finns det alltså en hård koppling mellan förvalet och de claims som den slutförda inloggningen kommer resultera i. 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.

...

...

För att hålla exemplen enkla används enbart employeeHsaId, commissionHsaId, organizationIdentifier och personalIdentityNumber som de claims 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.

...

...

...

...

...

...