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: UTKAST - sida och arbetsyta etableras nu; innehållet är under framtagning och ska återkopplas inom några veckor. Innehållet på denna sida ska betraktas som arbetsutkast som kommer tjäna som underlag för fortsatt diskussion
Uppdrag – Gemensamt arbete med behörighetsattribut
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 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
Utforma en struktur för hur behörighetsattribut ska namnges och beskrivas.
3. Ta fram en förvaltningsstruktur
Definiera hur behörighetsattribut ska förvaltas över tid, inklusive roller, ansvar och beslutsprocesser. Förvaltningsmodellen ska tydliggöra ägarskap, förändringshantering och samordning mellan berörda aktörer.
4. Ta fram styrande principer
Formulera övergripande principer för användning och hantering av behörighetsattribut.
Arbetet ska resultera i en sammanhållen struktur som möjliggör både praktisk tillämpning och långsiktig utveckling.
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.
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
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.
Attribut från e-legitimationen
Om en e-tjänst vill nyttja en e-legitimation utan att användaren finns i en katalog ä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 men e-tjänsten vill använda en legitimeringstjänst.
Avgränsningar
Behörighetsmodell
Exakt hur attributen från e-legitimationen eller katalogen uppstår beskrivs inte här.
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å tre nivåer:
- Ledningsaktör
- Domänkoordinator
- Attribututfärdare
Ledningsaktör (exempelvis Digg)
Ledningsaktören har det övergripande ansvaret för attributstrukturen.
Ansvar:
- Äger och förvaltar den övergripande domänstrukturen
- Beslutar vilka domäner som finns
- Fastställer hur domäner är uppbyggda
- Utser aktör som får rollen Domänkoordinator
- Äger och förvaltar domänoberoende attribut
- Attribut som är gemensamma för samtliga domäner
- Säkerställer enhetlig semantik och namngivning
- Fastställer styrande principer
- Namnstandard
- Beskrivningsmodell
- Versionshantering
- Publiceringskrav
- Tillhandahåller teknisk infrastruktur
- Utrymme för lagring
- Publicering av attributdefinitioner
- Tillgängliggörande av metadata
Ledningsaktören ansvarar för helheten och för att strukturen är sammanhållen över sektorer.
Domänkoordinator (exempelvis sektorsmyndighet)
Domänkoordinatorn ansvarar för en specifik domän på uppdrag av ledningsaktören.
Ansvar:
- Koordinerar och utvecklar attribut inom sin domän
- Säkerställer att domänen använder domänoberoende attribut där sådana finns
- Identifierar behov av domänunika attribut
- Beslutar om införande av domänunika attribut inom ramen för sitt mandat
Säkerställer att domänunika attribut:
- Följer fastställd namnstandard
- Beskrivs enligt ledningsaktörens styrning
- Publiceras enligt fastställd modell
Domänkoordinatorn säkerställer sektorsspecifik relevans utan att bryta helheten.
Attribututfärdare
Attribututfärdaren ansvarar för ett eller flera specifika attribut inom en domän.
Ansvar:
- Säkerställer korrekthet och kvalitet i attributvärden
- Säkerställer att attributet används enligt fastställd definition
- Ansvarar för operativ tilldelning och livscykelhantering
- Samverkar med domänkoordinator vid förändringar
En domän kan ha flera attribututfärdare.
Exempel
Ledningsaktören (Digg) utser Transportstyrelsen till domänkoordinator för Transport-domänen.
Transportstyrelsen är både:
- Domänkoordinator
- Attribututfärdare för vissa domänunika attribut
- Trafikverket är samtidigt attribututfärdare för andra attribut inom Transport-domänen.
Detta innebär att:
- Transportstyrelsen samordnar domänen
- Flera aktörer kan vara ansvariga för enskilda attribut
- Helheten hålls samman genom den gemensamma strukturen
Exempel på domäner
| Domän | Koordineringsansvarig |
|---|---|
| Health | E-hälsomyndigheten |
| Skola | SIS |
| Transport | Transportstyrelsen |
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.
3. Uppgiftsminimering
Vid överföring av attribut ska principen om uppgiftsminimering alltid tillämpas.
Endast den information som är nödvändig för det aktuella syftet får delas.
4. Källoberoende attributmodell
Attribut ska definieras oberoende av var informationen hämtas ifrån.
Ett attributvärde kan komma från exempelvis katalogtjänst (IdP), e-legitimation, uppdragsregister eller annan betrodd källa.
Semantiken ska vara densamma oavsett källa.
5. Autentisering och elektronisk underskrift
Attributen ska täcka in användning för autentisering och elektronisk underskrift.
Principer för arbetets inriktning
1. 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
Vi designar primärt för det vanligaste användningsfallet. Undantag och specialfall ska identifieras och hanteras separat, utan att göra huvudmodellen onödigt komplex.
Arbetet ska sträva efter en 80/20-balans mellan generalitet och praktisk användbarhet.
Inledning
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?