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, styrande principer och beslutsprocesser. Förvaltningsmodellen ska tydliggöra ägarskap, förändringshantering och samordning mellan berörda aktörer.

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.

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

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å 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

 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

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.

En OID:

• SKA vara globalt unik.
• SKA entydigt identifiera ett och samma semantiska objekt.
• FÅR INTE återanvändas för att identifiera ett annat semantiskt objekt.
• BÖR betraktas som den normativa och långsiktigt stabila identifieraren.

OID definierar den semantiska identiteten oberoende av teknisk representation eller kontext.

OID ägs och förvaltas i ett OID-träd. Är stabil över tid och används för:

• Semantisk entydighet
• Standarder
• Långsiktig interoperabilitet

OID svarar på frågan om vad något är:

”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.

En HTTP-URI:

• KAN vara en sträng, URI, kortkod eller annan lokal identifierare.
• SKA entydigt mappa till exakt en OID inom den kontext där den används.
• FÅR INTE användas för att referera till olika OID:er inom samma kontext.
• KAN ändras över tid utan att objektets semantik förändras, förutsatt att mappningen till OID kvarstår.

En HTTP-URI är inte i sig en global semantisk identifierare.

En HTTP-URI förvaltas inom ramen för en specifik specifikation, federation eller implementation.

HTTP-URI svarar på frågan om hur begreppet fungerar här och nu:

”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.

En HTTP-URI utgör en kontextuell identifierare som används inom en viss modell eller implementation. Den pekar på en OID, vilken utgör den globala och långsiktigt stabila identifieraren för objektet. OID:en är i sin tur knuten till den formella semantiska definition som entydigt beskriver objektets betydelse.

Relationen kan beskrivas som en semantisk identifieringskedja:

HTTP-URI → OID → Semantisk definition

Den semantiska definitionen är således knuten till OID, inte till HTTP-URI.

OID definierar objektets identitet.

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.

OID utgör den globala semantiska identifieraren, men saknar i sig den kontextuella precisering som krävs för interoperabilitet inom en federation.

Samma OID kan användas i flera federationer men ges olika kontextuell innebörd beroende på:

• tillitsramverk
• källa till uppgiften
• identitetsprocess
• ansvarig part

Ett exempel

OID 2.5.4.10 identifierar begreppet organizationName på en generell semantisk nivå.

Dock gäller:

• I Sweden Connect den organisation som har anskaffat e-legitimationen för sin medarbetare (är kopplad till utgivningsprocessen).
• I Sambi användarens hemorganisation utifrån kataloguppgifter om medarbetarens tjänstgöring (är kopplad till anställning eller uppdrag).
• I Skolfederation eller SWAMID kan motsvarande attribut ha annan källa och annan tillitsgrund.

Det är således inte OID:en i sig som definierar attributets interoperabla betydelse inom federationen, utan den federationsspecifika HTTP-URI och dess profildefinition.

OID säger:

Detta är attributtypen enligt ett generellt schema.

HTTP-URI i federationen säger:

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:

• identifiera och tekniskt representera individer,
• beskriva organisatorisk tillhörighet,
• förmedla mandat och rättigheter, samt
• dokumentera förutsättningarna för autentisering och intygsutgivning.

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:

• utfärdare av identitetsintyg vid e-legitimering,
• individens organisatoriska hemvist, eller
• uppdragsgivare i en specifik handling/situation.

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:

• Avse individen som sådan,
• Uttrycka en teknisk representation av individen,
• Definiera en relation kopplad till individen
• Ange ett mandat som individen har tilldeltas
• Definiera en rättighet inom vilken individen får agera, eller
• Beskriva en händelse om autentisering och intygsutgvining.

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.

Ö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 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 representerar funktionell roll.

Mandat är inte samma sak som affiliation.

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. 

Beskriver händelsen och är inte en egenskap hos individen, snarare tillhör intygsmetadata.

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

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?

Attributlista

Referenser

Vägledning för hantering av behörighetsattribut (SKR)

Stöd för upphandling av e-underskrifter (SKR)

Behörighetsmodell för vård och omsorg (Inera)