...
| Info |
|---|
Följande roller och ansvar BÖR etableras:
Notera att vissa attribut alltid föds från en nationellt gemensam källa (tex Skatteverkets Navet, Socialstyrelsens HOSP-register). Attributdefinitionerna för dessa attribut hanteras också via en domänkoordinator, även om parten ansvarig för källan har mycket att säga till om. |
Exempel på domäner
| Domän | Domänkoordinator |
|---|---|
| Hälso- och sjukvård (Health) | E-hälsomyndigheten |
| Skola och utbildning (edu) | SIS |
| Forskning och högre utbildningar | SUNET |
| Transport | Transportstyrelsen |
| Expand | ||
|---|---|---|
| ||
Exempel på förvaltningsstruktur - Transportsektorn
|
...
| Expand | ||
|---|---|---|
| ||
HypotesAlla attribut är inte av samma slag. Attribut kan exempelvis:
Dessa är ontologiskt olika. Attribut ska därför kategoriseras efter vad de representerar och efter deras semantiska natur. Attribut som påverkar åtkomstbeslut får inte blandas med beskrivande eller "dekorativa" attribut. AttributmodellI federativa miljöer används attribut för att:
Trots detta behandlas attribut ofta som en enhetlig mängd egenskaper. I praktiken representerar de dock fundamentalt skilda semantiska kategorier. När dessa kategorier inte hålls isär uppstår otydliga behörighetsbeslut, bristande tillitsbedömningar, juridisk osäkerhet och försämrad interoperabilitet, vilket i sin tur försvårar standardisering. Begreppet organisation är ett tydligt exempel på denna problematik. Det används i flera olika betydelser, exempelvis som:
När dessa betydelser sammanblandas uppstår otydlighet i ansvar, mandat och tillit, vilket leder till felaktiga behörighetsbeslut, oklara rättsliga relationer och interoperabilitetsproblem. Teknisk aktörPlaceholder för subject som kan vara api, api-klienter, etc. |
Frågeställningar
Här finns ett antal frågor att besvara innan vi kan detaljera attributramverket.
- Vem har givit ut e-legitimationen?
- Vem är personens huvudsakliga arbetsgivare?
- Vem är personens uppdragsgivare för den rolll personen agerar i just nu?
Ska namnet på attributet spegla källan, till exempel /eid för e-legitimation och /idp för IdP?
I den överenskommelse som finns mellan regionerna och E-hälsomyndigheten när det gäller den SAML-propageringslösning för åtkomst till NLL har man etablerat en namnstandard för attribut som härrör sig från IdP:n. Ett exempel på detta är https://idp.inera.se/attributes/identityProviderForSign Som man kan se så innehåller attributnamnet referens till en organisation. En mera neutral namngivning på detta attribut kunde vara https://federationer.se/attribute/idp/1.0/identityProviderForSign
I vissa användningsfall är det viktigt för e-tjänsten som begär attributen att skilja på om attributen kommer från själva e-legitimationen eller från attributkällan. För Ineras IdP så går det att peka ut certifikatets givenName med attributet urn:credential:givenName. Motsvarande attribut som hämtas från katalogen är http://sambi.se/attributes/1/givenName eller urn:oid:2.5.4.42 (enligt Sweden Connects namnsättning), beroende på vilken IdP man ansluter till. I det senare fallet finns det ingen metod att peka ut attributet som är e-legitimationsspecifikt.
Det spännande attributet orgAffiliation som heter urn:oid:1.2.752.201.3.1 enligt Sweden Connect och som i Ineras fall betyder att källan är katalogen, knutet till uppdraget, att jämföra med https://idp.inera.se/attributes/userOrgAffiliation som är knutet till en personpost i katalogen, oberoende av uppdrag men beroende på vilken organisation som användaren tillhör.
Vi skulle kunna tänka oss följande motsvarande attribut i ramverket
https://id.ena-infrastructure.se/attributes/health/1.0/orgAffiliation
https://id.ena-infrastructure.se/attributes/health/1.0/userOrgAffiliation
OID som attributnamn
Ska vi använda Sweden Connects namn på vissa av attributen vilket i praktiken innebär OID:ar? Ska vi då förutsätta att attributen härrör från e-legitimationen? Det stämmer inte med nuvarande realiseringar som t ex Inera har.
Så här är Sweden Connects namn på ett attribut givenName: urn:oid:2.5.4.42
Övrig semantik i attributnamnet
Vissa attribut kan relatera till en anställds organisationstillhörighet eller uppdrag/roll, hur ska e-tjänsten kunna skilja på detta? I Ineras fall när det gäller den anställdes HSAid beror det på vilka andra attribut som e-tjänsten begär. Observera skillnaden mellan ett HSAid som är knutet till e-legitimationen och HSA-id som finns i katalogen. I den senare kategorin finns ingen namnsättning som skiljer på organisationstillhörighet och uppdragssituation.
När det gäller domänspecifika attribut inom vård och omsorg finns "health" med i attributnamnet https://id.ena-infrastructure.se/attributes/health/healthcareProfessionalLicenseIdentityNumber bland de attribut som används för åtkomst till NLL och är överenskommet med E-hälsomyndigheten och regionerna.
Versionshantering av attribut
Ska attributnamnen ha en namnstandard som medger versionshantering enligt mönster från Sambi?
Exempel från Sambi: http://sambi.se/attributes/1/givenName
Om vi använder det i ramverket: https://federationer.se/attribute/1.0/givenName
Fördelar: om ett attribut får en annan betydelse, till exempel en annan värdemängd, behöver vi inte hitta på ett helt nytt namn utan bara byta som i detta fall 1.0 till 2.0. Den praktiska konsekvensen är att det är ett helt nytt attribut som kan leva parallellt med det gamla. Fråga: har detta någonsin använts i Sambi?
| Info |
|---|
En semantisk eller redaktionell uppdatering i profil → tekniskt breaking change Konsekvens: Versionsnumret i attributnamnet fryser på “1” för alltid. Det beror på att man undviker kostnaden för att byta – vilket gör versionen semantiskt meningslös. Designprinciper som brukar fungera bättre: Attributidentifieraren ska vara stabil Slutsats: inget versionsnummer i attributnamnet, regel för detta arbete. |
Attributlista
- Modellera för hur en attributprofil kan ha multipla attributinstanser, tex beroende på källa (attribut på e-leg, från en katalog), relaterad till ett eller flera uppdrag.
- Beskriv en modell för attributprofiler med personrelaterade attribut, e-leg-relaterade attribut, N x anställningsrelaterade attribut, M x uppdragsrelaterade uppdrag
- Beskriv skillnaden mellan en IdP per organisation och en Idp som representerar flera organisationer
Frågor
- Personalidentity - både pnr och snr eller separata attribut?
- Ska vi lägga in synonymer från andra federationer, t ex Sambi? JA, se lista
- Kan vi lösa de olika synsätten på att peka ut e-legitimationen som källa i namnet genom att göra denna typ av attribut domänspecifika? (https://id.ena-infrastructure.se/attributes/surName jfr med https://id.ena-infrastructure.se/attributes/eid/health/surName). Ska källan i det första fallet vara okänd? Beroende på vilken IdP man använder?
- Attribut som saknas i nuvarande Sambi, t ex Middlename, vad gör vi med dom?
- Enhet som generellt attribut, andra är domänspecifika t ex vårdenhet, skolenhet?
Attributnamn
Namnen är hämtade från OIDC Core, OIDC Sweden och inspirerade av Sambis attributprofil. Domänen health kommer mycket från Ineras IdP då de också är överenskomna med Ehälsomyndigheten. Sweden Connect har gett eIDAS-namnen. Se referenser.
För att avgöra vad ett attribut eller claim ska heta och vilket scope ett claim eventuellt ska tillhöra, behövs en beslutsordning med hänvisning till befintliga standarder. Här har vi valt att illustrera denna beslutsordning i form av beslutsträd.
- Att göra: beslutsträd för SAML-namn
...
För att bestämma vilket namn ett claim ska ha, se nedan för beslutsträd.
...
Exemplifiering och validering
- Modellera för hur en attributprofil kan ha multipla attributinstanser, tex beroende på källa (attribut på e-leg, från en katalog), relaterad till ett eller flera uppdrag.
- Beskriv en modell för attributprofiler med personrelaterade attribut, e-leg-relaterade attribut, N x anställningsrelaterade attribut, M x uppdragsrelaterade uppdrag
- Beskriv skillnaden mellan en IdP per organisation och en Idp som representerar flera organisationer
Frågor
- Personalidentity - både pnr och snr eller separata attribut?
- Ska vi lägga in synonymer från andra federationer, t ex Sambi? JA, se lista
- Kan vi lösa de olika synsätten på att peka ut e-legitimationen som källa i namnet genom att göra denna typ av attribut domänspecifika? (https://id.ena-infrastructure.se/attributes/surName jfr med https://id.ena-infrastructure.se/attributes/eid/health/surName). Ska källan i det första fallet vara okänd? Beroende på vilken IdP man använder?
- Attribut som saknas i nuvarande Sambi, t ex Middlename, vad gör vi med dom?
- Enhet som generellt attribut, andra är domänspecifika t ex vårdenhet, skolenhet?
Val av attribut
Namnen är hämtade från OIDC Core, OIDC Sweden och inspirerade av Sambis attributprofil. Domänen health kommer mycket från Ineras IdP då de också är överenskomna med Ehälsomyndigheten. Sweden Connect har gett eIDAS-namnen. Se referenser.
För att avgöra vad ett attribut eller claim ska heta och vilket scope ett claim eventuellt ska tillhöra, behövs en beslutsordning med hänvisning till befintliga standarder. Här har vi valt att illustrera denna beslutsordning i form av beslutsträd.
- Att göra: beslutsträd för SAML-namn
För att bestämma vilket namn ett claim ska ha, se nedan för beslutsträd.
| draw.io Board Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
För att bestämma vilket scope ett claim eventuellt ska tillhöra, se beslutsträd nedan. Observera att domänansvarig kan bestämma en ökad granularitet, se attributlistan för exempel. Det kan också vara så att ett claim kan sakna scope.
| draw.io Board Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Attributlista
| Info |
|---|
Nedan första utkastet på attributlistan, den ska i detta läge ses främst som ett försök till att bestämma formatet då det är önskvärt att hålla ihop beskrivningen men ändå kunna filtrera på olika sätt. |
| Table Filter | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
...
För att bestämma vilket scope ett claim eventuellt ska tillhöra, se beslutsträd nedan. Observera att domänansvarig kan bestämma en ökad granularitet, se attributlistan för exempel. Det kan också vara så att ett claim kan sakna scope.
...
Attribut
| Info |
|---|
Nedan första utkastet på attributlistan, den ska i detta läge ses främst som ett försök till att bestämma formatet då det är önskvärt att hålla ihop beskrivningen men ändå kunna filtrera på olika sätt. |
| Table Filter | ||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| fixedCols | ||||||||||||||||||||||||||||||||||||||||||||||||||
| totalrow | ,,,,,,,,,,,,,,, | |||||||||||||||||||||||||||||||||||||||||||||||||
| hidelabels | false | |||||||||||||||||||||||||||||||||||||||||||||||||
| ddSeparator | ‚‚‚‚‚‚ | |||||||||||||||||||||||||||||||||||||||||||||||||
| sparkName | Sparkline | |||||||||||||||||||||||||||||||||||||||||||||||||
| hidePane | Filtration panel | customNoTableMsgText | limitHeight | |||||||||||||||||||||||||||||||||||||||||||||||
| sparkline | false | |||||||||||||||||||||||||||||||||||||||||||||||||
| default | ,,,,,, | |||||||||||||||||||||||||||||||||||||||||||||||||
| isFirstTimeEnter | true | |||||||||||||||||||||||||||||||||||||||||||||||||
| cell-width | 250,250,250,250,250,250,250 | |||||||||||||||||||||||||||||||||||||||||||||||||
| hideColumns | false | totalRowName | totalColName | |||||||||||||||||||||||||||||||||||||||||||||||
| customNoTableMsg | false | |||||||||||||||||||||||||||||||||||||||||||||||||
| disabled | false | |||||||||||||||||||||||||||||||||||||||||||||||||
| enabledInEditor | false | |||||||||||||||||||||||||||||||||||||||||||||||||
| globalFilter | false | |||||||||||||||||||||||||||||||||||||||||||||||||
| id | 1776699475527_-1836505391 | iconfilter | ||||||||||||||||||||||||||||||||||||||||||||||||
| order | 0,1,2,3,4,5,6 | |||||||||||||||||||||||||||||||||||||||||||||||||
| hideControls | false | |||||||||||||||||||||||||||||||||||||||||||||||||
| inverse | false,false,false,false,false,false,false | numbering | datefilter | |||||||||||||||||||||||||||||||||||||||||||||||
| column | Domän,Kategori,Källa,Sambi synonym,Sweden Connect synonym,Standard,OIDC scope | sort | totalcol | |||||||||||||||||||||||||||||||||||||||||||||||
| disableSave | false | rowsPerPage | ||||||||||||||||||||||||||||||||||||||||||||||||
| separator | Point (.) | |||||||||||||||||||||||||||||||||||||||||||||||||
| labels | Domän‚Kategori‚Källa‚Sambi synonym‚Sweden Connect synonym‚Standard‚OIDC scope | thousandSeparator | ignoreFirstNrows | |||||||||||||||||||||||||||||||||||||||||||||||
| ddOperator | OR,OR,OR,OR,OR,OR,OR | userfilter | ||||||||||||||||||||||||||||||||||||||||||||||||
| datepattern | dd M yy | numberfilter | heightValue | hideFilters | ||||||||||||||||||||||||||||||||||||||||||||||
| updateSelectOptions | false | |||||||||||||||||||||||||||||||||||||||||||||||||
| worklog | 365|5|8|y w d h m|y w d h m | |||||||||||||||||||||||||||||||||||||||||||||||||
| isOR | AND | showNRowsifNotFiltered |
|
Frågeställningar
Här finns ett antal frågor att besvara innan vi kan detaljera attributramverket.
- Vem har givit ut e-legitimationen?
- Vem är personens huvudsakliga arbetsgivare?
- Vem är personens uppdragsgivare för den rolll personen agerar i just nu?
Ska namnet på attributet spegla källan, till exempel /eid för e-legitimation och /idp för IdP?
I den överenskommelse som finns mellan regionerna och E-hälsomyndigheten när det gäller den SAML-propageringslösning för åtkomst till NLL har man etablerat en namnstandard för attribut som härrör sig från IdP:n. Ett exempel på detta är https://idp.inera.se/attributes/identityProviderForSign Som man kan se så innehåller attributnamnet referens till en organisation. En mera neutral namngivning på detta attribut kunde vara https://federationer.se/attribute/idp/1.0/identityProviderForSign
I vissa användningsfall är det viktigt för e-tjänsten som begär attributen att skilja på om attributen kommer från själva e-legitimationen eller från attributkällan. För Ineras IdP så går det att peka ut certifikatets givenName med attributet urn:credential:givenName. Motsvarande attribut som hämtas från katalogen är http://sambi.se/attributes/1/givenName eller urn:oid:2.5.4.42 (enligt Sweden Connects namnsättning), beroende på vilken IdP man ansluter till. I det senare fallet finns det ingen metod att peka ut attributet som är e-legitimationsspecifikt.
Det spännande attributet orgAffiliation som heter urn:oid:1.2.752.
...
201.
...
3.1 enligt Sweden Connect och som i Ineras fall betyder att källan är katalogen, knutet till uppdraget, att jämföra med https://
...
...
...
userOrgAffiliation som är knutet till en personpost i katalogen, oberoende av uppdrag men beroende på vilken organisation som användaren tillhör.
Vi skulle kunna tänka oss följande motsvarande attribut i ramverket
https://id.ena-infrastructure.se/attributes/
...
https://id.ena-infrastructure.se/
...
attributes/health/1.0/userOrgAffiliation
OID som attributnamn
Ska vi använda Sweden Connects namn på vissa av attributen vilket i praktiken innebär OID:ar? Ska vi då förutsätta att attributen härrör från e-legitimationen? Det stämmer inte med nuvarande realiseringar som t ex Inera har.
Så här är Sweden Connects namn på ett attribut givenName: urn:oid:
...
2.
...
5.
...
4.42
Övrig semantik i attributnamnet
Vissa attribut kan relatera till en anställds organisationstillhörighet eller uppdrag/roll, hur ska e-tjänsten kunna skilja på detta? I Ineras fall när det gäller den anställdes HSAid beror det på vilka andra attribut som e-tjänsten begär. Observera skillnaden mellan ett HSAid som är knutet till e-legitimationen och HSA-id som finns i katalogen. I den senare kategorin finns ingen namnsättning som skiljer på organisationstillhörighet och uppdragssituation.
...
När det gäller domänspecifika attribut inom vård och omsorg finns "health" med i attributnamnet
https://id.ena-infrastructure.se/attributes/
...
health/healthcareProfessionalLicenseIdentityNumber bland de attribut som används för åtkomst till NLL och är överenskommet med E-hälsomyndigheten och regionerna.
Versionshantering av attribut
Ska attributnamnen ha en namnstandard som medger versionshantering enligt mönster från Sambi?
Exempel från Sambi: http://sambi.
...
...
Om vi använder det i ramverket:
...
...
...
...
Fördelar: om ett attribut får en annan betydelse, till exempel en annan värdemängd, behöver vi inte hitta på ett helt nytt namn utan bara byta som i detta fall 1.0 till 2.0. Den praktiska konsekvensen är att det är ett helt nytt attribut som kan leva parallellt med det gamla. Fråga: har detta någonsin använts i Sambi?
| Info |
|---|
En semantisk eller redaktionell uppdatering i profil → tekniskt breaking change Konsekvens: Versionsnumret i attributnamnet fryser på “1” för alltid. Det beror på att man undviker kostnaden för att byta – vilket gör versionen semantiskt meningslös. Designprinciper som brukar fungera bättre: Attributidentifieraren ska vara stabil Slutsats: inget versionsnummer i attributnamnet, regel för detta arbete. |
...
Referenser
| Anchor | ||||
|---|---|---|---|---|
|
...
| Anchor | ||||
|---|---|---|---|---|
|
...
Appendix A - exempel från verkligheten
SAML
För SAML finns det exempel på metadata, inloggningsbegäran (request) och svar (assertion). Det kan vara värt att studera dessa exempel för att förstå hur SAML fungerar.
...
IdP Bas från Inera OIDC-profil
Appendix
...
B - utforskande material
...
kring informationsmodell för behörighetsgrundande information
DISCLAIMER: Inom detta arbete ska vi inte modellera hur behörighetsstyrande attribut är strukturerade i attributkällor, men vi tänkte lite kring detta i tidigt skede av arbetet och har sparat vårt arbetsmaterial i detta appendix.
...