Attributstyrning OIDC

 Visa revisionshistorik

Version

Datum

Författare

Kommentar

0.1

  

  • Kopierad från tidigare version
0.2

 

  • Kompletterat information om förval av principalen
1.0

 

Godkänt
 Visa innehållsförteckning

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.

Ex: Begära alla attribut via scope
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.


Ex: Begära attribut via claims
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.
Exempel på ett returnerat authorizationScope
"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"
                }
            ]


Ex: Begäran om specifik loa nivå
claims = {
	"id_token" : {
		"acr" : {
			"value" : "http://id.sambi.se/loa/loa3",
			"essential" : true
		}
	}
}


Ex: claims-begäran som kräver att användaren har minst ett authorizationScope med authorizationScopeCode lika med "BIF"
claims = {
	"userinfo" : {
		"authorizationScope" : {
			"value" : "BIF",
			"essential" : true
		}
	},
	"id_token" : {
		"authorizationScope" : {
			"value" : "BIF",
			"essential" : true
		}
	}
}


Ex: claims-begäran som filtrerar bort authorizationScope som inte har authorizationScopeCode "SYS1" eller "SYS2"
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.

Ex: claims-begäran som väljer SITHS eID på samma enhet som autentiseringsmetod
claims = {
	"id_token" : {
		"authenticationMethod" : {
			"value":"SITHS_EID_SAME_DEVICE"
		}
	}
}

Uppdragsval

Användaren kommer endast ställas inför ett uppdragsval ifall det är nödvändigt, det vill säga om båda dessa villkor är uppfyllda:

  1. Uppdragsspecifika attribut är begärda.
  2. Användaren har fler än ett uppdrag.
    • Har användaren endast ett uppdrag så väljs det implicit.

Om användaren inte har några uppdrag så presenteras inte heller något uppdragsval, och om några av de uppdragsspecifika attributen då är markerade som tvingande (essential i claims-parametern) så kommer inloggningen att misslyckas.

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.

Ex: claims-begäran som begär samtliga uppdragsval
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.

Ex: claims-begäran som begär samtliga HSA ID:n
claims = {
	"id_token" : {
		"allEmployeeHsaIds" : {
			"essential" : true
		}
	}
}

Förval av principalen

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:

ClaimAnvänds för
credentialPersonalIdentityNumberValidering av personidentifierare
personalIdentityNumberValidering av personidentifierare
employeeHsaIdFiltrering av tjänste-id
commissionHsaIdFiltrering av medarbetaruppdrag
orgAffiliationFiltrering av medarbetaruppdrag
organizationIdentifierFiltrering av medarbetaruppdrag

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)
 Klicka här för att expandera ...
Inmatning i claimsbegäranResultat
employeeHsaId: 111Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt employeeHsaId 111.
employeeHsaId: 444Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt employeeHsaId 444.
employeeHsaId: 999

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

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

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.

personalIdentityNumber: 19000101-0001

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

 Klicka här för att expandera ...
Inmatning i claimsbegäranResultat

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.

personalIdentityNumber: 19121212-1212

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

 Klicka här för att expandera ...
Inmatning i claimsbegäranResultat

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.

personalIdentityNumber: 19121212-1212

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

 Klicka här för att expandera ...
Inmatning i claimsbegäranResultat
employeeHsaId: 111Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt employeeHsaId 111.
employeeHsaId: 444Ingen användarinteraktion krävs. OIDC tokens erhålles med claims från scopet openid samt employeeHsaId 444.

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

Inloggningen misslyckas. inget medarbetaruppdrag med organizationIdentifier 67890 hittas under employeeHsaId 111.

employeeHsaId: 444

organizationIdentifier: 12345

Inloggningen misslyckas. inget medarbetaruppdrag med organizationIdentifier 12345 hittas under employeeHsaId 444.

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.

personalIdentityNumber: 19121212-1212

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

 Klicka här för att expandera ...
Inmatning i claimsbegäranResultat

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

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

Förval av principalen i praktiken

I exemplet nedan förväntas användaren bli inloggad med personnummer 194211196979, tjänste-id:t TSTNMT2321000156-10NG för organisationen med organisationsnumret 232100-0214.

Ex: claims-begäran som filtrerar ut ett HSA-id och en organisation
claims = {
	"id_token" : {
		"personalIdentityNumber" : {
			"value": "194211196979"
		},
		"orgAffiliation": {
			"value": "TSTNMT2321000156-10NG@232100-0214"
		}
	}
}


Publik Information