Sammanfattning

Vid klientregistrering anges vilka attribut (claims) som skall finnas tillgängliga för klienten vid en autentiseringsbegäran.

Vid autentiseringsbegäran anges vilka attribut (claims) som efterfrågas, och huruvida de är tvingande (essential) eller inte.

Tillgängliga claims och scopes

• Claim = attribut
• Scope = en samling av claims

Attributlistan visar vilka claims och scopes som kan levereras av IdP. Notera att varje claim ingår i ett scope.

Klientregistrering

Vid klientregistrering anges vilka claims som är godkända för IdP att släppa ifrån sig till klienten.

Scopet "openid" och de claims som ingår däri är obligatoriska och behöver inte specificeras. Övriga tillåtna attribut kan anges ett och ett som claims eller gruppvis som scopes. Vid registreringen sparas allting som enskilda claims oavsett.

Autentiseringsbegäran

Autentiseringsbegäran måste specificera vilka attribut som skall returneras efter en lyckad autentisering.

Attributbegäran görs via två parametrar i autentiseringsbegäran: scope och/eller claims.

• Begärda claims eller scopes som inte finns definierade i attributlistan ignoreras av IdP.
  
• Det gör ingen skillnad huruvida ett attribut ingår i ett begärt scope eller om det begärs individuellt i claims-parametern, eller i både och. Dock går det i claims-parametern att specificera ytterligare villkor för det begärda attributet (se claims-avsnittet nedan).
• De begärda attributen filtreras och IdP returnerar endast de begärda attribut som är godkända i klientregistreringen enligt ovan.

scope

https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

Det obligatoriska "openid"-scopet i autentiseringsbegäran kan kompletteras med ytterligare scopes.

scope = openid commission authorization_scope personal_identity_number

De claims som ingår i begärda scopes levereras i id-token i autentiseringssvaret.

claims

https://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter

• Begärs ett och ett.
• Anges separat huruvida attributet skall returneras i svarets id-token och/eller levereras från UserInfo-endpointen.
• Kan markeras som essential, d.v.s. tvingande.
  • Motsvarar fältet "isRequired" i SAML
  • Om attributet är flaggat som essential på minst en av userinfo och id_token, och IdP inte kan leverera attributet som begärt så kommer inloggningen att misslyckas.

claims = {
	"userinfo" : {
		"given_name" : null,
		"mobileTelephoneNumber" : {
			"essential" : true
		},
		"healthCareUnitName" : {
			"essential" : true
		},
		"commissionRight" : null
	},
	"id_token" : {
		"healthCareUnitHsaId" : {
			"essential" : true
		},
		"healthCareUnitName" : null
	}
}
 

Filtrering av authorization_scope

• Styrning av vilka authorization_scope som returneras görs genom att skicka med en value-parameter (om det är ett ensamt godkänt värde) eller values-parameter (med en array av godkända värden) under authorizationScope i claims-parametern. Värdet jämförs med underattributet authorizationScopeCode och icke-matchande resultat filtreras bort. Detta kan användas tillsammans med essential-flaggan för att direkt kräva att en användare har en roll inom rätt behörighetsområde för att få utföra en inloggning.

"authorizationScope" : [{
            "authorizationScopePropertyName" : "Tjänstesupport",
            "authorizationScopeName" : "Säkerhetstjänster",
            "authorizationScopeCode" : "BIF",
            "authorizationScopePropertyCode" : "BIF;002",
            "authorizationScopeDescription" : "HSA Domain description",
            "authorizationScopePropertyDescription" : "Tjänstesupport Beskrivning",
            "adminCommissions" : [{
                    "adminCommissionHsaId" : "SE1804231406",
                    "sector" : [{
                            "sectorFlag" : true,
                            "name" : "SE111-JLL",
                            "unitHsaId" : "SE111-JLL"
                        },{
                            "sectorFlag" : false,
                            "name" : "SE111-IVA-NAME",
                            "unitHsaId" : "SE111-IVA"
                        }
                    ],
                    "adminCommissionResponsibleOrganisation" : "232100-0214"
                }
            ]

claims = {
	"id_token" : {
		"acr" : {
			"value" : "http://id.sambi.se/loa/loa3",
			"essential" : true
		}
	}
}

claims = {
	"userinfo" : {
		"authorizationScope" : {
			"value" : "BIF",
			"essential" : true
		}
	},
	"id_token" : {
		"authorizationScope" : {
			"value" : "BIF",
			"essential" : true
		}
	}
}

claims = {
	"userinfo" : {
		"authorizationScope" : {
			"values" : ["SYS1", "SYS2"]
		}
	},
	"id_token" : {
		"authorizationScope" : {
			"values" : ["SYS1", "SYS2"]
		}
	}
}

Autentiseringsmetod

I fallet att ett anslutande system har flera autentiseringsmetoder påslagen går det att förvälja autentiseringsmetoden för en enskild inloggning. Mer specifikt så styrs detta med hjälp av attributet authenticationMethod där det går att ange tre olika värden:

• SITHS_EID_SAME_DEVICE (SITHS eID på denna enhet)
• SITHS_EID_OTHER_DEVICE (SITHS eID på annan enhet)
• MTLS (Net iD Enterprise)

Dock så går det inte att välja en autentiseringsmetod med hjälp av authenticationMethod om inte den autentiseringsmetoden är påslagen för det anslutande systemet. Om ett sådant försök görs misslyckas inloggningen.

IdP kommer endast ta hänsyn till det inskickade värdet för attributet authenticationMethod om er anslutning tillåts begära attributet. Om ni har för avsikt att förvälja autentiseringsmetod med den här mekanismen behöver ni alltså ange att ni begär authenticationMethod som del av er förstudie.

claims = {
	"id_token" : {
		"authenticationMethod" : {
			"value":"SITHS_EID_SAME_DEVICE"
		}
	}
}

Samtliga uppdragsval som claim

Om man vill undvika uppdragsval i de fall som en användare har flera uppdrag och man vill ha all uppdragsinformation så ska man begära attributet allCommissions. Detta kan vara användbart i situationer då SP:n vill ha användarens fullständiga behörighet.

Observera dock att SP:n fortfarande kan begära andra attribut som triggar ett uppdragsval som måste göras i IdP:n. Ett sådant exempel är ifall SP:n begär allCommissions samt commissionPurpose. I det fallet måste uppdragsvalet göras men SP:n kommer ändå få listan på samtliga uppdragsval tillbaka efter lyckad autentisering.

claims = {
	"id_token" : {
		"allCommissions" : {
			"essential" : true
		}
	}
}

 Samtliga HSA ID:n som claim

Om man vill undvika uppdragsval i de fall som en användare har flera HSA ID:n och/eller flera uppdrag och man bara vill ha ett HSA ID:n kan man begära attributet allEmployeeHsaIds. Då returneras en lista av HSA ID:n och SP:n kan då välja ett av dessa, t ex via en användardialog.

claims = {
	"id_token" : {
		"allEmployeeHsaIds" : {
			"essential" : true
		}
	}
}

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.

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

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

Image Removed

Val av medarbetaruppdrag

Användaren ställs inför ett val av medarbetaruppdrag om ett eller flera claims 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 claims som innebär att användaren kan bli presenterad med ett medarbetaruppdragsval finns det såväl claims som är exklusiva till att endast kunna erhållas via medarbetaruppdragsvalet samt att det finns claims 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 claims vilket av valen användaren ställs inför. Om det finns ytterligare claims 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: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.