...
Fokus för detta dokument är att beskriva arbetet när man har ett behov av behörighetsgrundande information för ett behörighetsbeslut och hur man säkerställer att denna information uttrycks på ett sätt som främjar interoperabilitet och återanvändbarhet.
...
Uppdragets leverabler
Arbetsgruppen har i uppdrag att skapa en gemensam och hållbar grund för hantering av behörighetsattribut i federativa och sektorsgemensamma sammanhang.
Syftet är att bidra till en enhetlig, interoperabel och långsiktigt förvaltbar modell som kan användas av kommuner, regioner och nationella aktörer.
Uppdraget omfattar att:
- Föreslå förvaltningsstrukturFörvaltningsstruktur
Definiera hur behörighetsattribut och attributprofiler kan förvaltas över tid, inklusive roller, ansvar, styrande principer och beslutsprocesser. Förvaltningsmodellen ska tydliggöra ägarskap, förändringshantering och samordning mellan berörda aktörer. - Beskriv attributlistor och hur de kan användasAttributlistor
Hur går man tillväga när man tar fram en attributlista som ska användas inom en domän, ett samverkanskontext eller för en specifik tillämpning. - Anvisa hur nya behörighetsattribut definierasBehörighetsattribut
Ta fram en process för hur nya behörighetattribut namnges och beskrivs - Exemplifiera och validera
Identifiera och definiera ett första urval av behörighetsattribut inom några utvalda domäner. Dessa ska fungera som konkreta exempel och kunna användas för att pröva struktur, semantik och tillämpning. Verifiera även attributlistor genom att skapa sådana för specifika tillämpningar som Nationell Läkemedelslistan och elektronisk underskrift.
...
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Principer
...
i framtagandet
- Respektera gjorda investeringar i dagens attributanvändning
- De behörighetsattribut som används inom olika sektorer idag kommer inte sluta användas bara för att en statlig myndighet hittar på en bättre variant. Förbättringar kommer ske över tid.
- När det förankrats att användning av ett behörighetsattribut ska fasas ut ska det i attributets dokumentation kunna markeras vilket annat synonymt attribut som rekommenderas.
- De komponenter som tillför behörighetsattribut bör ha vetskap om synonymer för att kunna svara på attributbegäran
- Favorisera brett förankrade attributsdefinitioner framför att skapa nya
- Behörighetsattribut ska i första hand utgå från etablerade och registrerade standarder (exempelvis IANA, OID eller motsvarande internationella register).
Nya attribut ska endast definieras när befintligt attribut saknas.
Rekommendera selektiv användning
Attributsdefinitionskatalogen beskriver möjliga behörighetsattribut. Vid varje enskilt användningstillfälle ska endast de behörighetsattribut som är relevanta för ändamålet användas.
...
- Utfärdande organisation
- Hemorganisation/anställning
- Företrädd organisation i aktuellt uppdrag
- Roll och mandat i den specifika situationen
| Info | ||
|---|---|---|
| ||
Ett viktigt attribut som kan hänföra sig till den organisatoriska dimensionen är orgAffiliation. En person kan ibland agera inom ramen för sin organisatoriska tillhörighet, ibland handlar det om uppdrag.
Notera att man som princip ska minimera information som man delger om en användare, så alternativ 2 bör användas sparsamt. |
| Info | ||
|---|---|---|
| ||
Om en e-tjänst vill nyttja en e-legitimation utan att använda kataloguppslag är det nödvändigt att från e-tjänstens perspektiv kunna peka ut attribut som hänför sig till e-legitimationen. I det fallet kan det vara så att intygsutfördaren inte har tillgång till katalogen eller att det helt enkelt är en onödig omväg. I utgivning av en e-legitimation kan det vara tvunget att säkerställa att identiten härrör från e-legitimationen, inte från katalogen, attributkällan. |
Leverabler
Förvaltningsstruktur
För att säkerställa långsiktig hållbarhet, interoperabilitet och tydligt ansvar behöver attributsdefinitioner och attributprofiler förvaltas i en definierad struktur med tydliga roller och mandat.
- en specifik situation
Ytterligare ett krav är att det i vissa situationer kan vara viktigt att kunna uttrycka från vilken källa ett attribut härrör sig. Till exempel vid utgivning av en mobil e-legitimation utifrån en legitimering med en fysisk e-legitimation kan det vara tvunget att säkerställa att identiteten härrör från den fysiska e-legitimationen och inte inte från en annan attributkällan.
Leverabler
Förvaltningsstruktur
För att säkerställa långsiktig hållbarhet, interoperabilitet och tydligt ansvar behöver attributsdefinitioner och attributlistor förvaltas i en definierad struktur med tydliga roller och mandat.
| Info |
|---|
Följande roller och ansvar BÖR etableras:
|
| 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
|
Attributlistor och hur de kan användas
Inom ett verksamhetsområde så behöver parterna komma överens om vilka behörighetsattribut som som ska användas för att tjänsteproducenter att utvärdera anropande parts juridiska behörighet att utföra förfaranden inom tjänsten. Olika domäner styrs ofta av delvis olika lagstiftning och kan därför kräva domänspecifika behörighetsattribut för att kunna genomföra behörighetskontroller.
...
| Info | ||
|---|---|---|
| ||
För att stödja livscykelhantering av attributlistor utan att störa verksamheters behov av robust digital samverkan, bör man tillämpa följande rekommendationer:
Notera att det för specifika situationer där förutsättningar finns för att driva igenom brytande revideringar utan negativ verksamhetspåverkan för samverkande parter, kan det vara att föredra. |
TODOs
- 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
När man har behov av ett attribut som man vill inkludera i en attributlista bör man på ett strukturerat sätt söka om det finns ett redan definierat attribut som fyller behovet innan man definierar ett nytt attribut.
...
Val av attribut
När man har behov av ett attribut som man vill inkludera i en attributlista bör man på ett strukturerat sätt söka om det finns ett redan definierat attribut som fyller behovet innan man definierar ett nytt attribut.
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Hur används attributlistor
När man slutit en överenskommelse kring en attributlista som ska användas behöver samverkande parter implementera stöd för den. Legitimeringstjänster behöver kunna informationsförsörja attribut i attributlistan och e-tjänster behöver implementera dem för att styra behörigheter i e-tjänsten. Man kan utöver en överenskommelse om vilka attribut som ska användas också definiera scopes för attributbeställningar för att underlätta beställning. E-tjänster kan beställa behörighetsattribut explicit via claims eller i bulk via scope.
Exempel: En E-tjänst begär legitimering av en användare och instruerar legitimeringstjänsten om vilka scopes och claims som krävs eller önskas.
| Code Block | ||
|---|---|---|
| ||
GET https://op.example.se/authorize?
response_type=code
&client_id=rp-client-123
&redirect_uri=https%3A%2F%2Frp.example.se%2Fcallback
&scope=openid%20profile%20email
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj
&claims=%7B
%22id_token%22%3A%7B
%22acr%22%3A%7B%22essential%22%3Atrue%7D
%7D%2C
%22userinfo%22%3A%7B
%22given_name%22%3A%7B%22essential%22%3Atrue%7D%2C
%22family_name%22%3A%7B%22essential%22%3Atrue%7D%2C
%22birthdate%22%3A%7B%22essential%22%3Afalse%7D
%7D
%7D |
I exemplet begärs scopen openid, profile och email. Utöver dessa grupperingar begär man explicit attributen id_token och given_name, family_name och birthdate från userinfo. Betydelsen av essential-märkningen för respektive attributbegäran är om det attributet är obligatoriskt ("essential": true) eller valfritt att bifoga ("essential": false).
Legitimeringstjänsten (även 'OP' i OIDC, eller 'IdP' i SAML) tillför behörighetsattributen, med värden inhämtade från e-legitimationen eller attributkällor av olika slag.
| Info | ||
|---|---|---|
| ||
Legitimeringstjänster BÖR hantera synonymer enligt attributdefinitioner, dvs att om en förlitande part begär ett attribut med någon av dess synonyma identifierare bör detta kunna hanteras utan att generera fel. Det är hjälpsamt för att kunna hantera livscykelhantering av behörighetsattribut. |
| Info | ||
|---|---|---|
| ||
Ett viktigt attribut som kan hänföra sig till den organisatoriska dimensionen är orgAffiliation och andra uppdragsrelaterade behörighetsattribut.
Notera att man som princip ska minimera information som man delger om en användare, så alternativ 2 bör användas sparsamt. |
Hur nya behörighetsattribut definieras
...
Behörighetsattribut
Ett behörighetsattribut inom Samordnad identitet och behörighet definieras behöver i sin definition inkludera följande metainformation:
...
| Info | ||
|---|---|---|
| ||
|
...
| draw.io Board Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Attribut / 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. |
...
...
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?
...