Revisionshistorik
Version | Datum | Författare | Kommentar |
---|---|---|---|
0.1 |
| Upprättad | |
0.2 |
| Grim Skarsgård | Utkast |
0.3 |
| Grim Skarsgård | Information om filtrering av authorizationScope |
1.0 |
| Fastställd | |
2.2 |
| Uppdaterad med information kring allCommissions och allEmployeeHsaIds | |
2.2.1 |
| Ehlert, Stefan | Information kring authenticationMethod |
SammanfattningVid 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
Attributlistan visar vilka claims och scopes som kan levereras av IdP. Notera att varje claim ingår i ett scope. KlientregistreringVid 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äranAutentiseringsbegä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.
scopehttps://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims Det obligatoriska "openid"-scopet i autentiseringsbegäran kan kompletteras med ytterligare scopes.
De claims som ingår i begärda scopes levereras i id-token i autentiseringssvaret. claimshttps://openid.net/specs/openid-connect-core-1_0.html#ClaimsParameter
Filtrering av authorization_scope
AutentiseringsmetodI 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:
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.
UppdragsvalAnvä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:
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 claimOm 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.
Samtliga HSA ID:n som claimOm 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.
Filtrering av organisationsnummer, HSA-id, personnummer och orgAffiliationLikt PrincipalSelection för SAML finns motsvarande filtreringsmöjligheter för OIDC. Här ges möjligheten att på förhand göra ett specifikt val över vilket HSA-id, organisationsnummer, personnummer eller orgAffiliation som användaren ska bli inloggad med. Dess värden användas enskilt men också kombineras med varandra. När filtreringen görs försöker IdP:n göra ett val automatiskt baserad på den informationen som tagits emot via de claims som skickats in. 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. I exemplet nedan förväntas användaren bli inloggad med HSA-id:t TSTNMT2321000156-10NG för organisationen med organisationsnumret 232100-0214.
|