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

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.

Principer för uppdragets leverabler

1. Respektera gjorda investeringar i dagens attributanvändning
   1. 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.
   2. Attributsdefinitioner behöver kunna markeras som "deprecated" (en avrådan från användning) och kopplas till rekommenderat alternativ
   3. De komponenter som tar behörighetsbeslut utifrån tillförda attribut bör ha vetskap om alternativa attributsdefinitioner 
      
      
2. Favorisera brett förankrade attributsdefinitioner framför att skapa nya
   1. Attribut ska i första hand utgå från etablerade och registrerade standarder (exempelvis IANA, OID eller motsvarande internationella register).

   2. Nya attribut ska endast definieras när befintliga standarder inte täcker behovet.

   3. 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?
      
      

3. Rekommendera selektiv användning

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

1. 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.
   
   
2. 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

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:

1. Nationell koordinator (förslagsvis ledningsaktören för Samordnad identitet och behörighet, Digg)
   1. Äger och förvaltar den övergripande domänstrukturen och tillser att varje domän har en utsedd domänkoordinator.
   2. Tar in behov av nya och förtydligade attributsdefinitioner från domänkoordinatorer
   3. Förvaltar en nationell katalog för attributsdefinitioner
   4. Förvaltar domänoberoende attribut i den nationella katalogen med attributsdefinitioner
   5. Förvaltar ramverk för kvalificering, kvalitetsgranskning och publicering av attributsdefinitioner.
      
      
2. Domänkoordinator (exempelvis sektorsmyndigheter)
   1. Tar in behov av nya och förtydligade attributsdefinitioner från aktörer inom en sektor
   2. Förvaltar domänspecifika attribut i den nationella katalogen med attributsdefinitioner
   3. 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

Exempel på förvaltningsstruktur - Transportsektorn

1. Ledningsaktören (Digg) utser Transportstyrelsen till domänkoordinator för Transport-domänen.
2. Transportstyrelsen är domänkoordinator
   1. Transportstyrelsen ansvarar även för attributkällor för vissa domänunika attribut - tex fordonsägare i Fordionsregistret.
   2. 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.

Attributdefinitioner

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.

Attributkategorier

Detta avsnitt syftar till att redogöra för attributtyper 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.

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.

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.

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.

Attributmodell

I federativa B2B- och G2G-miljöer används attribut för att:

• identifiera och tekniskt representera individer och systemaktörer,
• 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.

Teknisk aktör

Placeholder för subject som kan vara api, api-klienter, etc.

Modell för attributprofiler

En uppsättning attribut för en utpekad domän, med utpekad förvaltare (tex sektorsmyndighet)

Generiska attribut

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

1. Definiera skillnaden mellan attributdefinitioner, och attributprofiler
2. 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.
3. Beskriv en modell för attributprofiler med personrelaterade attribut, e-leg-relaterade attribut, N x anställningsrelaterade attribut, M x uppdragsrelaterade uppdrag 
4. Beskriv skillnaden mellan en IdP per organisation och en Idp som representerar flera organisationer

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)

Exempel

Tomas Fransson  referenser till nuvarnde och exempel för ny struktur.

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 SAML-profil

OIDC

För OIDC finns motsvarande här

IdP Bas från Inera OIDC-profil