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 } } }
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, organisations-id, organisationsnummer eller organisationstillhörighet och skickas in som value i de respektive claims. Dessa 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.
Mer information om hur denna mekanism fungerar finns på denna här: IdP:ns publika användargränssnitt
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.
claims = { "id_token" : { "personalIdentityNumber" : { "value": "194211196979" }, "orgAffiliation": { "value": "TSTNMT2321000156-10NG@232100-0214" } } }