| Panel | ||||||
|---|---|---|---|---|---|---|
| ||||||
Vi startar ett arbete som sker parallellt och utanför teamets nuvarande kärnuppdrag att jobba mot realisering av MVP ( arbetet sker med resurser utanför teamet - detta är en platshållare). Syftet är att komma igång med att skapa en publicerbar och återanvändbar struktur för attribut inom Samordnad identitet och behörighet, med fokus på att minska “dialekter” och integrationsbörda för e-tjänster. Bakgrunden är de behov som lyfts från samverkande aktörer att komma igång med detta arbete. Arbetet utgår från fyra attributtyper som först ska definieras och avgränsas. Varje typ bedöms kräva egen diskussion och hantering (t.ex. olika källor, tillitskrav, ansvariga parter och livscykel), för att undvika att allt blandas ihop. SKR och Internetstiftelsen tar fram ett första utkast (0.1) med förslag på typindelning, en nationell minsta kärna och exempel på domänprofiler/mappning (t.ex. skola och vård). DIGG har för avsikt att stå för format, struktur och publiceringsyta och vara avsändare för normering, men inte ta fram definitionerna annat än det som är helt nationellt. Status: |
| Table of Contents |
|---|
Inledning
Uppdrag
...
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:1.
- Ta fram en struktur för hur behörighetattribut beskrivs
Utforma en struktur för hur behörighetsattribut ska namnges och beskrivas. - Ta fram behörighetsattribut för exemplifierade domäner
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
...
2. Ta fram en struktur för hur behörighetattribut beskrivs
...
- .
...
...
- Ta fram en förvaltningsstruktur
Definiera hur behörighetsattribut ska 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.
Not: Arbetet ska resultera i en sammanhållen struktur som möjliggör både praktisk tillämpning och långsiktig utveckling. Arbetet ska kunna verifieras. Exempel på verifiering är Nationell Läkemedelslistan och elektronisk underskrift.
Inledning
Användningsfall
Nedan listas ett antal användningsfall som vi använder som utgångspunkt i arbetet med behörighetsattribut. Syftet är att belysa olika organisatoriska och federativa situationer där identitet, hemvist, utfärdare och företrädd organisation kan skilja sig åt.
Exemplen är hämtade från kommunal verksamhet men kan kompletteras med mönster från andra verksamheter.
Direkt anställning och extern e-tjänst
Agneta har en e-tjänstelegitimation som är utfärdad av Lunds kommun, där hon är anställd.
I sin roll som lärare i Lunds kommun vill hon logga in och använda en e-tjänst från Skolverket.
Gemensam IT-organisation som utfärdare
Görans e-tjänstelegitimation är utfärdad av SML-IT, som är gemensam IT-organisation för flera kommuner.
Göran är anställd som bygglovshandläggare i Lysekils kommun och vill logga in i en e-tjänst från Lantmäteriet.
Flera organisatoriska dimensioner (utfärdare, hemvist och uppdrag)
Lars har en e-tjänstelegitimation utfärdad av Höglandets IT-förbund.
Han är anställd på Aneby kommuns miljökontor som livsmedelsinspektör.
För närvarande utför han ett uppdrag åt Jönköpings kommun och har inom ramen för detta genomfört en inspektion. Han ska nu logga in i Livsmedelsverkets e-tjänst.
Denna uppsättning användningsfall hjälper oss att pröva hur behörighetsattribut behöver beskriva:
- Utfärdande organisation
- Hemorganisation/anställning
- Företrädd organisation i aktuellt uppdrag
- Roll och mandat i den specifika situationen
...
| title | Organisatorisk dimension |
|---|
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. Ett sätt att skilja på detta är att e-tjänsten kan specificera specifika attribut som till exempel userOrgAffiliation när det handlar om organisation och orgAffiliation när det handlar om uppdrag.
| 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. |
Avgränsningar
Behörighetsmodell
Exakt hur attributen från e-legitimationen eller katalogen uppstår beskrivs inte här. Tilliten till attributen löser vi i federationen. Se Referenser för exempel på behörighetsmodeller.
Regler för användning av attribut
Principer för uppgiftsminimering och andra rekommendationer finns inte beskrivna i detta dokument.
Förvaltningsstruktur för behörighetsattribut
För att säkerställa långsiktig hållbarhet, interoperabilitet och tydligt ansvar behöver behörighetsattribut förvaltas i en definierad struktur med tydliga roller och mandat.
Förvaltningsmodellen bygger på två styrnivåer:
...
Principer för uppdragets leverabler
- Respektera gjorda investeringar i dagens attributanvändning
- De attribut 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.
- Attributsdefinitioner behöver kunna markeras som "deprecated" (en avrådan från användning) och kopplas till rekommenderat alternativ
- De komponenter som tar behörighetsbeslut utifrån tillförda attribut bör ha vetskap om alternativa attributsdefinitioner
- Favorisera brett förankrade attributsdefinitioner framför att skapa nya
- Attribut 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 befintliga standarder inte täcker behovet.
När man som tjänsteleverantör har behov av att begränsa behörighet på nya sätt och då behöver nya behörighetsattribut i den attributprofil man använder så ska man innan man "hittar på" ett eget attribut, använda redan befintliga attribut från den nationella attributsdefinitionskatalogen, alternativt från IANA.DUPLIKAT?
Rekommendera selektiv användning
Attributsdefinitionskatalogen beskriver möjliga attribut. Vid varje enskilt användningstillfälle ska endast de attribut som är relevanta för ändamålet användas - val av attributprofil och styrning av vilka attribut som fylls i.
Avgränsningar
- Exakt hur attributen från e-legitimationen eller katalogen uppstår beskrivs inte här. Tilliten till attributen löser vi i federationen. Se Referenser för exempel på behörighetsmodeller.
- Principer för uppgiftsminimering och andra rekommendationer finns inte beskrivna i detta dokument.
Användningsfall
Nedan listas ett antal användningsfall som vi använder som utgångspunkt i arbetet med behörighetsattribut. Syftet är att belysa olika organisatoriska och federativa situationer där identitet, hemvist, utfärdare och företrädd organisation kan skilja sig åt.
Exemplen är hämtade från kommunal verksamhet men kan kompletteras med mönster från andra verksamheter.
Direkt anställning och extern e-tjänst
Agneta har en e-tjänstelegitimation som är utfärdad av Lunds kommun, där hon är anställd.
I sin roll som lärare i Lunds kommun vill hon logga in och använda en e-tjänst från Skolverket.
Gemensam IT-organisation som utfärdare
Görans e-tjänstelegitimation är utfärdad av SML-IT, som är gemensam IT-organisation för flera kommuner.
Göran är anställd som bygglovshandläggare i Lysekils kommun och vill logga in i en e-tjänst från Lantmäteriet.
Flera organisatoriska dimensioner (utfärdare, hemvist och uppdrag)
Lars har en e-tjänstelegitimation utfärdad av Höglandets IT-förbund.
Han är anställd på Aneby kommuns miljökontor som livsmedelsinspektör.
För närvarande utför han ett uppdrag åt Jönköpings kommun och har inom ramen för detta genomfört en inspektion. Han ska nu logga in i Livsmedelsverkets e-tjänst.
Denna uppsättning användningsfall hjälper oss att pröva hur behörighetsattribut behöver beskriva:
- 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. Ett sätt att skilja på detta är att e-tjänsten kan specificera specifika attribut som till exempel userOrgAffiliation när det handlar om organisation och orgAffiliation när det handlar om uppdrag. |
| 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. |
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.
Förvaltningsmodellen bygger på två styrnivåer:
- Nationell koordinator (förslagsvis ledningsaktören för Samordnad identitet och behörighet, Digg)
- Äger och förvaltar den övergripande domänstrukturen och tillser att varje domän har en utsedd domänkoordinator.
- Tar in behov av nya och förtydligade attributsdefinitioner från domänkoordinatorer
- Förvaltar en nationell katalog för attributsdefinitioner
- Förvaltar domänoberoende attribut i den nationella katalogen med attributsdefinitioner
- Förvaltar ramverk för kvalificering, kvalitetsgranskning och publicering av attributsdefinitioner.
- Domänkoordinator (exempelvis sektorsmyndigheter)
- Tar in behov av nya och förtydligade attributsdefinitioner från aktörer inom en sektor
- Förvaltar domänspecifika attribut i den nationella katalogen med attributsdefinitioner
- Lyfter behov gällande gemensamma attribut till nationell koordinator
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 | Koordineringsansvarig |
|---|---|
| Health | E-hälsomyndigheten |
| Skola | SIS |
| Transport | Transportstyrelsen |
Exempel på förvaltningsstruktur - Transportsektorn
- Ledningsaktören (Digg) utser Transportstyrelsen till domänkoordinator för Transport-domänen.
- Transportstyrelsen är domänkoordinator
- Transportstyrelsen ansvarar även för attributkällor för vissa domänunika attribut - tex fordonsägare i Fordionsregistret.
- Trafikverket ansvarar för andra centrala attributkällor inom Transport-domänen och koordinerar tillhörande attributsdefinitioner med Transportstyrelsen - tex registreringsinformation om enskild väg
...
- Tar in behov av nya och förtydligade attributsdefinitioner från aktörer inom en sektor
- Förvaltar domänspecifika attribut i den nationella katalogen med attributsdefinitioner
- Lyfter behov gällande gemensamma attribut till nationell koordinator
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 | Koordineringsansvarig |
|---|---|
| Health | E-hälsomyndigheten |
| Skola | SIS |
| Transport | Transportstyrelsen |
Exempel på förvaltningsstruktur - Transportsektorn
- Ledningsaktören (Digg) utser Transportstyrelsen till domänkoordinator för Transport-domänen.
- Transportstyrelsen är domänkoordinator
- Transportstyrelsen ansvarar även för attributkällor för vissa domänunika attribut - tex fordonsägare i Fordionsregistret.
- Trafikverket ansvarar för andra centrala attributkällor inom Transport-domänen och koordinerar tillhörande attributsdefinitioner med Transportstyrelsen - tex registreringsinformation om enskild väg.
Styrande attribut
Styrande principer för behörighetsattribut
1. Standardiserad namngivning och identifiering
Attribut 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 befintliga standarder inte täcker behovet.
2. Selektiv användning
Den gemensamma attributlistan beskriver möjliga attribut.
Vid varje enskilt användningstillfälle ska endast de attribut som är relevanta för ändamålet användas.
Principer för arbetets inriktning
- Respektera gjorda investeringar i dagens attributanvändning
- De attribut 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.
- Attributsdefinitioner behöver kunna markeras som "deprecated" (en avrådan från användning) och kopplas till rekommenderat alternativ
- De komponenter som tar behörighetsbeslut utifrån tillförda attribut bör ha vetskap om alternativa attributsdefinitioner
- Återanvänd brett förankrade attributsdefinitioner framför att skapa nya
- När man som tjänsteleverantör har behov av att uttrycka
- Förvalta förvaltningsstrukturen aktivt
Standardnära och konfigurerbart
De lösningar och modeller vi tar fram ska vara möjliga att implementera genom konfiguration i etablerade standardprodukter.Arbetet ska följa internationella standarder och etablerad federationspraxis så att leverantörer inte behöver utveckla särskilda speciallösningar för den svenska marknaden.
2. Design för det normala
...
- .
Namnsättning (identifiering) av attribut
Detta avsnitt definierar relationen mellan Object Identifier (OID) och HTTP-URI vid identifiering av attribut eller andra semantiska objekt i en interoperabel infrastruktur.
Object Identifier (OID)
En OID som URN (t ex urn:oid:2.5.4.42) är en globalt unik och hierarkiskt strukturerad identifierare bestående av en numerisk sträng enligt ITU-T X.660 / ISO/IEC 9834.
...
”Exakt vilket begrepp pratar vi om, oavsett kontext?”
HTTP-URI
En HTTP-URI är en kontextuell identifierare som används inom en specifik modell, profil eller implementation för att referera till ett objekt som definieras av en OID.
...
”Hur refererar vi till det här begreppet i just den här modellen eller profilen?”
Relationen mellan OID och HTTP-URI
Följande princip gäller: En HTTP-URI refererar till ett objekt vars semantiska identitet definieras av en OID.
...
HTTP-URI är ett kontextuellt alias.
Interoperabilitetskrav
Inom en federation och/eller vid federationsspecifik attributidentifiering BÖR attribut exponeras och refereras med den attributreferens som definieras i en attributprofil som erkänns av federationens medlemmar. Med andra ord, OID BÖR INTE användas som attributnamn i federativ kommunikation.
...
Detta attribut har denna specifika semantik enligt federationens regelverk.
Kategorisering av attribut
Detta avsnitt syftar till att redogöra för attributkategorier i federativa B2B- och G2G-infrastrukturer. Målet är att etablera en modell som skapar semantisk tydlighet och utgör en tillförlitlig grund för beslut.
Person
I federativa B2B- och G2G-miljöer används attribut för att:
...
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.
Grundprinciper
Alla attribut är inte av samma slag. Attribut kan exempelvis:
...
Attribut som påverkar åtkomstbeslut får inte blandas med beskrivande eller "dekorativa" attribut.
Övergripande attributkategorier
Attribut delas in i sex huvudkategorier där varje kategori har distinkt semantik:
- Identitetsattribut
- Representationsattribut
- Relationsattribut
- Mandatattribut
- Rättighetsattribut
- Kommunikationsattribut
- Transaktionella attribut (utanför subjektet)
Identitetsattribut
Attribut som beskriver individens juridiska eller officiella identitet. Det rör sig om egenskaper som tillhör individen oberoende av organisationstillhörighet, roll eller uppdrag. Dessa uppgifter har typiskt sin grund i officiella register och är, relativt sett, långlivade och stabila över tid.
Exempel: personnummer, officiellt namn, födelsedatum.
Representationsattribut
Representationsattribut delas in i lokal personrespresentation respektive federationsrepresentation.
Lokal personrepresentation
Attribut som beskriver hur hemorganisationen representerar individen. Det rör sig om identifierande egenskaper som är kopplade till individen och genom vilka denne är känd, identifierbar eller tekniskt representerad inom den egna organisationen. Dessa attribut är organisatoriskt kontextbundna och kan förändras över tid, exempelvis vid byte av roll, system eller organisatorisk tillhörighet.
Exempel: uuid, användarnamn, tjänstebeteckning.
Federationsrepresentation
Hemorganisationens tekniska identifierare som används i federationen. Dessa attribut är säkerhetskritiska och deras stabilitet regleras av federationen. De är inte personliga egenskaper utan tekniska identifieringsartefakter.
Exempel: subject-id, pairwise-id, eduPersonPrincipalName, healthCareProviderHsaId.
Relationsattribut
Attribut som beskriver strukturell koppling mellan individ och en organisation. Detta är en relation – inte en egenskap hos personen.
Exempel: organisationsnamn, organisatorisk enhet/avdelning, skolenhetskod, affiliation (t ex personal, elev).
Mandatattribut
Attribut som beskriver att individen representerar en organisation i en viss funktion eller ett uppdrag. Dessa attribut kan vara tidsbegränsade, transaktionsbundna och representera en funktionell roll.
...
Exempel: commissionHsaId, sisSchoolCourseTeacher.
Rättighetsattribut
Policybärande attribut som anger vad individen får göra – rätt att använda en resurs eller utföra en handling.
Exempel: eduPersonEntitlement
Kommunikationsattribut
Attribut som beskriver kanaler genom vilka individen kan kontaktas eller nås.
Exempel: e-postadress, telefonnummer, mobilnummer.
Transaktionella attribut
Attribut utanför subjektet som beskriver händelser om autentisering och/eller intygutgivning vid en specifik tidpunkt.
...
Exempel: identifieringens tillitsnivå, transaktionsid, delegeringskedja.
Teknisk aktör
Placeholder 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
...
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?
...
| 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 |
Attributlista
- Definiera skillnaden mellan attributdefinitioner, och attributprofiler
- 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
...
| Table Filter | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Referenser
Vägledning för hantering av behörighetsattribut (SKR)
...
Behörighetsmodell för vård och omsorg (Inera)
Exempel
Tomas Fransson referenser till nuvarnde och exempel för ny struktur.