Användarval

Användaren kommer endast ställas inför ett val ifall det är nödvändigt. Det finns en rad scenarion och villkor som behöver uppfyllas som var för sig kan leda till att användaren ställs inför ett val. Användaren kan ställas inför följande val i IdP:ns gränssnitt:

• Val av tjänste-id
• Val av organisation
• Val av medarbetaruppdrag

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 som RP 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:n endast begär användarens personnummer och namn som ska hämtas direkt från certifikatet. Om RP:n begär ett claim 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 som begärts från användarens certifikat. Samma sak gäller om RP:n begär ett claim 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 från certifikats och tjänste-id-nivån. Den högsta nivån är valet av medarbetaruppdrag varigenom även claims 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:

1. Uppgifter från certifiktatet (personidentifierare, förnamn, efternamn, m.m.)
2. Uppgifter kring anställningen (employeeHsaId, epostadress, telefonnummer, m.m.)
3. Uppgifter kring organisationstillhörighet (organizationHsaId, organisationsnummer, organisationens namn, m.m.)
4. Uppgifter kring medarbetaruppdrag (commissionHsaId, commissionPurpose, healthCareProviderHsaId, m.m.)

Automatiska val av IdP:n

Om möjligt kommer IdP:n undvika att presentera användaren med något val. I dessa fall har användaren så pass få uppgifter att välja mellan eller att andra förutsättningar finns på plats som gör att ett val endast hade varit ett onödigt steg. I det fallet hade det endast funnits ett enda val användaren skulle kunna göra. Nedan listas ett par exempel och scenarion då ett automatiskt val skulle ske men det finns givetvis många fler tänkbara scenarion:

• Användaren har endast ett HSA-ID tillhörande en organisation med två medarbetaruppdrag konfigurerat på sig. RP: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: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 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:n inte har specifierat något föredraget employeeHsaId via Förval av principalen. Senare begär RP 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 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:n inte har specifierat något föredraget employeeHsaId via Förval av principalen. Senare begär RP 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.

Val av tjänste-id

Användaren ställs inför ett val av tjänste-id om ett eller flera claims 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.)

Om endast attribut på anställningsnivå begärs från IdP:n kan användaren slippa göra ett användarval om något av följande villkor uppfylls:

• Användaren har endast ett tjänste-id kopplat till sig.
• RP: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: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 på samma nivå ha uppfyllts som i sin tur kan uppfylla den nya inloggningsbegäran.

Bilden nedan visar ett exempel på hur ett val av tjänste-id kan se ut för en användare.

Image Removed

Val av organisation

Användaren ställs inför ett val av organisation om ett eller flera claims begärts av IdP:n som kan erhållas via personens organisationstillhörighet. Uppgifterna kring organisationstillhörigheten 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 organisation att välja mellan. Dessutom kan en användare med ett tjänste-id tillhöra flera organisationer (se exempelbild nedan) och behöva göra ett val bland dessa.

Bland de claims som innebär att användaren kan bli presenterad med ett organisationsval finns det såväl claims som är exklusiva till att endast kunna erhållas via organisationsvalet samt att det finns claims som även kan erhållas via medarbetaruppdragsval. Om ett claim begärts som kan erhållas via både organisations- och medarbetaruppdragsval så avgör resterande claims vilket av valen användaren ställs inför. Ifall inga andra claims begärts på medarbetaruppdragsnivå så räcker det alltså med organisationsvalet. Om det dock skulle finnas ytterligare claims i legitimeringsbegäran som endast kan erhållas via medarbetaruppdragsval så ställs användaren istället inför ett medarbetaruppdragsval.

...

Publika användargränssnittet

Publika användargränssnittet består av ett flertal vyer som användare kan behöva navigera sig igenom. Den här sidan fokuserar endast på de vyerna för val av autentiserigsmetod och val av tjänste-id/organisation/medarbetaruppdrag. Vilka vyer användaren får se beror på en mängd olika faktorer, allt ifrån hur RP/SP-anslutningen är uppsatt för ett system, vilka attribut som begärs av IdP:n och hur enskilda användare är konfigurerade i bland annat HSA. Det är endast i vyerna för val av autentiseringsmetod och val av tjänste-id/organisation/medarbetaruppdrag där det anslutande systemet eller användarens konfiguration har effekt på vad som visas för användaren och om ett val överhuvudtaget behöver göras.

Autentiseringsmetod

Anslutna tjänster kan välja vilka inloggningsmetoder som skall vara aktiva och därmed valbara för användarna vid autentisering. Om endast en metod är aktiv för given e-tjänst så ställs användaren inte inför något val av autentiseringsmetod. De tillgängliga metoderna är följande:

• SITHS eID på annan enhet

• SITHS eID på denna enhet

• SITHS-kort på denna enhet

Om e-tjänstens anslutning sker via OIDC kan autentiseringsmetoden förväljas åt användaren. Denna mekanism fungerar endast när den förvalda autentiseringsmetoden är aktiverad för e-tjänsten. För slutanvändaren blir det endast en skillnad i användarflödet om e-tjänsten har mer än en autentiseringsmetod konfigurerad för sig, då IdP:n annars hade valt den enskilda autentiseringsmetoden automatiskt. Läs mer om denna mekanism här: Val av autentiseringsmetod

Det finns i dagsläget ingen mekanism att förvälja en autentiseringsmetod åt en användare om SAML används.

Om inget förval har gjorts presenteras användaren med en vy där alla för den e-tjänstens aktiverade autentiseringsmetoder listas. Här förväntas användaren välja en av de valbara metoderna varpå sedan det specifika flödet för den valda autentiseringsmetoden påbörjas. Se exempelbild nedan där samtliga tre autentiseringsmetoder är aktiverade för en e-tjänst:

...

Användarval

Användaren kommer endast ställas inför ett val ifall det är nödvändigt. Det finns en rad scenarion och villkor som behöver uppfyllas som var för sig kan leda till att användaren ställs inför ett val. Användaren kan ställas inför följande val i IdP:ns gränssnitt:

• Val av tjänste-id

• Val av organisation

• Val av medarbetaruppdrag

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 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 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 attribut som begärts från användarens certifikat. Samma sak gäller om RP/SP:n begär ett 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 attribut från certifikats och tjänste-id-nivån. Den högsta nivån är valet av medarbetaruppdrag varigenom även 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:

1. Uppgifter från certifiktatet (personidentifierare, förnamn, efternamn, m.m.)

2. Uppgifter kring anställningen (employeeHsaId, epostadress, telefonnummer, m.m.)

3. Uppgifter kring organisationstillhörighet (organizationHsaId, organisationsnummer, organisationens namn, m.m.)

4. Uppgifter kring medarbetaruppdrag (commissionHsaId, commissionPurpose, healthCareProviderHsaId, m.m.)

Om uppdragsvalet presenteras för användaren så varierar de listade alternativen beroende på hur de enskilda användarna är konfigurerade i HSA samt vilken autentiseringsmetod som valts. Autentiseringsmetodsvalet påverkar uppdragsvalet genom att:

• Inloggning med SITHS eID på denna/annan enhet föredrar personnummer-certifikat om ett sådant finns

  • En användares personnummer kan ha uppdrag kopplade till sig i HSA som inte också är kopplade på användarens HSA-id. Detta kan i sin tur resultera i att användaren får fler uppdragsval att välja mellan på för denna autentiseringsmetod.

• Inloggning med SITHS-kort på denna enhet alltid föredrar HSA-id-certifikat

Automatiska val av IdP:n

Om möjligt kommer IdP:n undvika att presentera användaren med något val. I dessa fall har användaren så pass få uppgifter att välja mellan eller att andra förutsättningar finns på plats som gör att ett val endast hade varit ett onödigt steg. I det fallet hade det endast funnits ett enda val användaren skulle kunna göra. Nedan listas ett par exempel och scenarion då ett automatiskt val skulle ske men det finns givetvis många fler tänkbara scenarion:

• 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.

Val av tjänste-id

Användaren ställs inför ett val av tjänste-id om ett eller flera 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.)

Om endast attribut på anställningsnivå begärs från IdP:n kan användaren slippa göra ett användarval om något av följande villkor uppfylls:

• Användaren har endast

  en anställning och en organisationstillhörighet

  ett tjänste-id kopplat till sig.

• 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å

  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.

Bilden nedan visar ett exempel på hur ett val av organisation tjänste-id kan se ut för en användare.Image Removed

...

Val av

...

organisation

Användaren ställs inför ett val av medarbetaruppdrag organisation om ett eller flera claims attribut begärts av IdP:n som endast kan erhållas via personens medarbetaruppdragorganisationstillhörighet. Uppgifterna kring medarbetaruppdragen organisationstillhörigheten 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 ett konfigurerat medarbetaruppdrag en konfigurerad organisation att välja mellan. Dessutom kan en användare med ett tjänste-id ha tillhöra flera medarbetaruppdrag organisationer (se exempelbild nedan) .Bland de claims och behöva göra ett val bland dessa.

Bland de attribut som innebär att användaren kan bli presenterad med ett medarbetaruppdragsval organisationsval finns det såväl claims attribut som är exklusiva till att endast kunna erhållas via medarbetaruppdragsvalet organisationsvalet samt att det finns claims attribut som även kan erhållas via organisationsvalmedarbetaruppdragsval. Om ett claim begärts som kan erhållas via både organisations- och medarbetaruppdragsval så avgör resterande claims attribut vilket av valen användaren ställs inför. Ifall inga andra attribut begärts på medarbetaruppdragsnivå så räcker det alltså med organisationsvalet. Om det finns dock skulle finnas ytterligare claims attribut i legitimeringsbegäran som endast kan erhållas via medarbetaruppdragsval så ställs användaren per automatik istället inför ett medarbetaruppdragsval.

Medarbetaruppdragsvalet kan i vissa lägen även visa enskilda tjänste-idn utan tillhörande medarbetaruppdrag. I de fallen har RP: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.

Om attribut på medarbetaruppdragsnivå begärs från IdP:n kan användaren slippa göra ett användarval om något av följande villkor uppfylls:

• Användaren har endast en anställning och ett medarbetaruppdrag.
• RP: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: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: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.

Bilden nedan visar ett exempel på hur ett val av medarbetaruppdrag kan se ut för en användare.

Image Removed

Illegala kombinationer

Det finns vissa claims som är exklusiva för sin nivå (empelvis organisations- eller medarbetaruppdragsnivå). Claims som begärs på anställningsnivå är kompatibla med både organisations- och medarbetaruppdragsvalet vilket gör att dessa claims inte är relevanta för det här stycklet.

I de fallen att minst ett claim begärts som är exklusivt för organisationsnivån och samtidigt minst ett claim begärts som är exklusivt för medarbetaruppdragsvalet så anses det som en illegal kombination av IdP:n. Användaren kan alltid bara presenteras för ett val under ett legitimeringsflöde. I de fallen att en illegal kombination begärts misslyckas inloggningen per automatik. Nedan följer ett par exempel på legala och illegala kombinationer med fokus på claims som härstammar från både organisations- och medarbetaruppdragsnivån. Vi förutsätter i exemplen att ett användarval behöver göras och inte genom någon mekanism eller villkor kan skippas.

De claims som listas i tabellen är endast ett urplock av alla tillgängliga claims. De claims är dock passande för de scenarion som listas nedan.

...

Exempel på scenarion:

• RP begär endast organizationHsaId. Användaren presenteras med organisationsval.
• RP begär endast commissionHsaId. Användaren presenteras med medarbetaruppdragsval.
• RP begär endast organizationName. Användaren presenteras med organisationsval.
• RP begär organizationName och organizationHsaId. Bägge claims kan erhållas via organisationsval, därför presenteras användaren med organisationsval.
• RP 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 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.

...

Som RP 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.

Under filtreringen försöker IdP:n göra ett val automatiskt baserad på den informationen som tagits emot i claimsbegä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 som på förhand har filtrerats med hjälp av de inskickade claimsvärden.

Claims 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 claims som används för förvalet av principalen samtidigt också blir del av del claims som RP: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:n har tillstånd att få ut det aktuella attributet från IdP. Skulle RP:n skicka in ett claim med ett värde men där RP: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 har tillstånd hos IdP att begära employeeHsaId och commissionHsaId. RP 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 har tillstånd hos IdP att begära employeeHsaId. RP 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 har tillstånd hos IdP att begära employeeHsaId. RP 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).

Claims

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 claims som begärs av RP: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)

...

Inloggningen misslyckas, inget giltigt tjänste-id hittas.

...

employeeHsaId: 111

organisationIdentifier: 12345

...

Partiell filtrering utförs med hjälp av endast employeeHsaId. RP har inte tillstånd att begära organizationIdentifier. Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt employeeHsaId 111.

...

Ingen filtrering utförs, RP har inte tillstånd att begära personalIdentityNumber. OIDC tokens erhålles med claims från scopet openid.

...

commissionHsaId: ccc

...

Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt commissionHsaId ccc.

...

commissionHsaId: zzz

...

Inloggningen misslyckas, inget medarbetaruppdrag hittas.

...

employeeHsaId: 111

...

Ingen filtrering utförs. RP har inte tillstånd att begära employeeHsaId. OIDC tokens erhålles med claims från scopet openid.

...

employeeHsaId: 444

...

Ingen filtrering utförs. RP har inte tillstånd att begära employeeHsaId. OIDC tokens erhålles med claims från scopet openid.

...

employeeHsaId: 999

...

Ingen filtrering utförs. RP har inte tillstånd att begära employeeHsaId. OIDC tokens erhålles med claims från scopet openid.

...

commissionHsaId: aaa

organizationIdentifier: 12345

...

Partiell filtrering utförs med hjälp av endast commissionHsaId. RP har inte tillstånd att begära organizationIdentifier. Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt commissionHsaId aaa.

...

employeeHsaId: 222

organizationIdentifier: 12345

...

Ingen filtrering utförs, RP har inte tillstånd att begära varken employeeHsaId eller organizationIdentifier. OIDC tokens erhålles med claims från scopet openid.

...

Ingen filtrering utförs, RP har inte tillstånd att begära personalIdentityNumber. OIDC tokens erhålles med claims från scopet openid.

...

organizationIdentifier: 67890

...

Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt organizationIdentifier 67890.

...

organizationIdentifier: 12345

...

Användarinteraktion krävs. Användaren får välja bland medarbetaruppdragen aaa, bbb och ccc som har organizationIdentifier 12345. OIDC tokens erhålles med claims från scopet openid samt organizationIdentifier 12345.

...

employeeHsaId: 111

...

Ingen filtrering utförs. RP har inte tillstånd att begära employeeHsaId. OIDC tokens erhålles med claims från scopet openid.

...

employeeHsaId: 444

...

Ingen filtrering utförs. RP har inte tillstånd att begära employeeHsaId. OIDC tokens erhålles med claims från scopet openid.

...

employeeHsaId: 999

...

Ingen filtrering utförs. RP har inte tillstånd att begära employeeHsaId. OIDC tokens erhålles med claims från scopet openid.

...

commissionHsaId: aaa

organizationIdentifier: 12345

...

Partiell filtrering utförs med hjälp av endast organizationIdentifier. RP har inte tillstånd att begära commissionHsaId. Användarinteraktion krävs. Användaren får välja bland medarbetaruppdragen aaa, bbb och ccc som har organizationIdentifier 12345. OIDC tokens erhålles med claims från scopet openid samt organizationIdentifier 12345.

...

employeeHsaId: 222

commissionHsaId: ccc

...

Ingen filtrering utförs, RP har inte tillstånd att begära varken employeeHsaId eller commissionHsaId. OIDC tokens erhålles med claims från scopet openid.

...

Ingen filtrering utförs, RP har inte tillstånd att begära personalIdentityNumber. OIDC tokens erhålles med claims från scopet openid.

...

employeeHsaId: 999

...

Inloggningen misslyckas, inget giltigt tjänste-id hittas.

...

organizationIdentifier: 12345

...

Användarinteraktion krävs. Användaren får välja bland medarbetaruppdragen aaa, bbb och ccc som har organizationIdentifier 12345. OIDC tokens erhålles med claims från scopet openid samt organizationIdentifier 12345.

...

employeeHsaId: 111

organizationIdentifier: 12345

...

Användarinteraktion krävs. Användaren får välja bland medarbetaruppdragen aaa och bbb som har organizationIdentifier 12345. OIDC tokens erhålles med claims från scopet openid samt emloyeeHsaId 111 och organizationIdentifier 12345.

...

employeeHsaId: 111

organizationIdentifier: 67890

...

employeeHsaId: 444

organizationIdentifier: 12345

...

employeeHsaId: 111

commissionHsaId: aaa

...

Partiell filtrering utförs med hjälp av endast employeeHsaId. RP har inte tillstånd att begära commissionHsaId. Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt employeeHsaId 111.

...

employeeHsaId: 444

commissionHsaId: aaa

...

Partiell filtrering utförs med hjälp av endast employeeHsaId. RP har inte tillstånd att begära commissionHsaId. Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt employeeHsaId 444.

...

commissionHsaId: ccc

...

Ingen filtrering utförs. RP har inte tillstånd att begära commissionHsaId. OIDC tokens erhålles med claims från scopet openid.

...

commissionHsaId: aaa

organizationIdentifier: 12345

...

Partiell filtrering utförs med hjälp av endast organizationIdentifier. RP har inte tillstånd att begära commissionHsaId. Användarinteraktion krävs. Användaren får välja bland medarbetaruppdragen aaa, bbb och ccc som har organizationIdentifier 12345. OIDC tokens erhålles med claims från scopet openid samt organizationIdentifier 12345.

...

Ingen filtrering utförs, RP har inte tillstånd att begära personalIdentityNumber. OIDC tokens erhålles med claims från scopet openid.

...

credentialPersonalIdentityNumber: 19121212-1212

...

Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt credentialPersonalIdentityNumber 19121212-1212.

...

credentialPersonalIdentityNumber: 19000101-0001

...

Inloggningen misslyckas, personnummer matchar inte identiteten.

...

employeeHsaId: 111

...

Ingen filtrering utförs. RP har inte tillstånd att begära employeeHsaId. OIDC tokens erhålles med claims från scopet openid.

...

commissionHsaId: aaa

...

Om endast attribut på anställnings- och organisationsnivå begärs från IdP:n kan användaren slippa göra ett användarval om något av följande villkor uppfylls:

• 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 attribut på samma nivå ha uppfyllts som i sin tur kan uppfylla den nya inloggningsbegäran.

Bilden nedan visar ett exempel på hur ett val av organisation kan se ut för en användare.

...

Val av medarbetaruppdrag

Användaren ställs inför ett val av medarbetaruppdrag om ett eller flera attribut begärts av IdP:n som endast kan erhållas via personens medarbetaruppdrag. Uppgifterna kring medarbetaruppdragen 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 ett konfigurerat medarbetaruppdrag att välja mellan. Dessutom kan ett tjänste-id ha flera medarbetaruppdrag (se exempelbild nedan).

Bland de attribut som innebär att användaren kan bli presenterad med ett medarbetaruppdragsval finns det såväl attribut som är exklusiva till att endast kunna erhållas via medarbetaruppdragsvalet samt att det finns attribut som även kan erhållas via organisationsval. Om ett claim begärts som kan erhållas via både organisations- och medarbetaruppdragsval så avgör resterande attribut vilket av valen användaren ställs inför. Om det finns ytterligare attribut i legitimeringsbegäran som endast kan erhållas via medarbetaruppdragsval så ställs användaren per automatik inför ett medarbetaruppdragsval.

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 attribut på både anställnings- och medarbetaruppdragsnivån men där de attribut 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.

Om attribut på medarbetaruppdragsnivå begärs från IdP:n kan användaren slippa göra ett användarval om något av följande villkor uppfylls:

• 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 attribut på samma nivå ha uppfyllts som i sin tur kan uppfylla den nya inloggningsbegäran.

Bilden nedan visar ett exempel på hur ett val av medarbetaruppdrag kan se ut för en användare.

...

Illegala kombinationer

Det finns vissa attribut som är exklusiva för sin nivå (empelvis organisations- eller medarbetaruppdragsnivå). Attribut som begärs på anställningsnivå är kompatibla med både organisations- och medarbetaruppdragsvalet vilket gör att dessa attribut inte är relevanta för det här stycklet.

I de fallen att minst ett claim begärts som är exklusivt för organisationsnivån och samtidigt minst ett claim begärts som är exklusivt för medarbetaruppdragsvalet så anses det som en illegal kombination av IdP:n. Användaren kan alltid bara presenteras för ett val under ett legitimeringsflöde. I de fallen att en illegal kombination begärts misslyckas inloggningen per automatik. Nedan följer ett par exempel på legala och illegala kombinationer med fokus på attribut som härstammar från både organisations- och medarbetaruppdragsnivån. Vi förutsätter i exemplen att ett användarval behöver göras och inte genom någon mekanism eller villkor kan skippas.

De attribut som listas i tabellen är endast ett urplock av alla tillgängliga attribut. De attribut är dock passande för de scenarion som listas nedan.

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 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

IdP stödjer 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 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 värdena.

Med denna mekanism har anslutande system möjlighet att på förhand välja vilket personnummer, tjänste-id, organisations-id, organisationsnummer eller medarbetaruppdrag 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:

• Attributstyrning SAML

• Attributstyrning OIDC