Om sidan

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

Inledning

För att kunna etablera samverkan via en digital tjänst krävs att den tjänsteproducerande parten kan fatt ett automatiserat behörighetskontroll. Underlag för sådan kontroll ges i regel i form av utfästelser om identitets- och behörighetsgrundande information.. Användarens identitet kontrolleras i regel genom e-legitimering och för systemaktörer används ofta certifikat som påstår att innehavaren av certifikatet har en viss identitet. Utfästelserna (eller påståendena) om identiteter och behörighetsgrundande information för anropande system och eventuell bakomliggande fysisk användare taggas som olika attribut, paketeras enligt en attributprofil, och förses med en digital stämpel av den part som står som garant för påståendets riktighet.

Fokus för detta dokument är att beskriva hur arbetet med att definiera attribut och attributprofiler bör drivas framgent för att främja interoperabilitet och för att underlätta för samhällets digitalisering avseende behörighetskontroller.

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:

Behörighetsattribut
Ta fram en struktur för hur behörighetattribut namnges och beskrivs
Attributprofiler
Fö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.
Ta fram behörighetsattribut och attributprofiler 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.

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

Respektera gjorda investeringar i dagens attributanvändning
1. 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.
2. 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.
3. De komponenter som tar behörighetsbeslut utifrån tillförda behörighetsattribut bör ha vetskap om alternativa attributsdefinitioner
Favorisera brett förankrade attributsdefinitioner framför att skapa nya
1. Behörighetsattribut 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.
Rekommendera selektiv användning
1. 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.

Avgränsningar

Exakt hur behörighetsattribut uppstår i e-legitimationer eller attributkällor beskrivs inte här. Tilliten till attributen löser vi i federationen. Se Referenser för exempel på behörighetsmodeller.
Tekniska mekanismer för informationsförsörjning av, och hantering av, behörighetsattribut beskrivs inte av detta dokument.

Exemplifierande 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

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

Behörighetsattribut

Ett behörighetsattribut inom Samordnad identitet och behörighet definieras behöver i sin definition inkludera följande metainformation:

Identifierare: en eller flera attributidentifierare enligt #3.1 nedan.
Kategori: en attributkategori enligt #3.2 nedan.
Status: En indikering om attributet är aktivt, under utfasning, eller utfasat.
Synonymt med: en eller flera attributidentifierare som kan användas synonymt med detta attribut
...mer

draw

Identifierare

Som identifierare av attribut eller andra semantiska objekt i en interoperabel infrastruktur används i regel formaten Object Identifier (OID), HTTP-URI, eller ett textuellt namn utan format.

Regler och rekommendationer

Attribut BÖR primärt identifieras med HTTP-URI
Attribut BÖR INTE primärt identifieras med oformaterat textuellt namn eller OID i federativ kommunikation
Attribut KAN identifieras med oformaterat textuellt namn eller OID
Om man i en och samma behörighetskontroll behöver särskilja mellan instanser av "samma" behörighetsattribut, informationsförsörjda från olika attributkällor, REKOMMENDERAS att man skapar olika behörighetsattribut, men olika identifierare.
Attribut BÖR exponeras och refereras med den identifierare som definieras i en attributprofil som erkänns av federationens medlemmar.

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.

Interoperabilitetsanalys

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

För att möjliggöra interoperabilitet och tillförlitliga åtkomstbeslut i federativa infrastrukturer behöver attribut klassificeras. Klassificeringen tydliggör vad ett attribut representerar, i vilken kontext det är giltigt samt hur det bör tolkas och användas. Detta minskar risken för feltolkningar, särskilt vid informationsutbyte mellan organisationer eller över landsgränser, och skapar en stabil grund för både tekniska implementationer och policybeslut.

Som grund för klassificeringen görs en åtskillnad mellan attribut som beskriver subjektets identitet, hur det representeras tekniskt och organisatoriskt, samt vilka relationer, mandat och rättigheter som gäller i en viss kontext. Vidare särskiljs attribut som möjliggör kommunikation med individer från sådana som beskriver själva transaktionen, exempelvis uppgifter om autentisering eller intygsutgivning. Ur ett IAM-perspektiv är denna uppdelning central, då olika attributtyper har skilda egenskaper avseende stabilitet, tillitsnivå och ansvarig utfärdare, vilket i sin tur påverkar hur de bör användas som underlag för åtkomstbeslut.

Regler och rekommendationer

Attribut BÖR typas enligt följande:

Kategori	Beskrivning	Typisk källa	Exempel på attribut
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.	E-legitimation	personnummer, officiellt namn, födelsedatum.
Representation - lokal	Attribut som beskriver hur arbets- eller uppdragsgivare 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.	Katalog	uuid, användarnamn, tjänstebeteckning
Representation - federativ	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.	Katalog	subject-id, orgAffiliation, pairwise-id, eduPersonPrincipalName, healthCareProviderHsaId.
Relationsattribut	Attribut som beskriver strukturell koppling mellan individ och en organisation. Detta är en relation – inte en egenskap hos personen.	Katalog	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.	Katalog	careunitHsaId, 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.	Katalog	eduPersonEntitlement
Kommunikationsattribut	Attribut som beskriver kanaler genom vilka individen kan kontaktas eller nås. Rekommenderas inte att användas för beslut om åtkomst.	Katalog	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, utan tillhör snarare ett intygs metadata.	Intygsutfärdare	identifieringens tillitsnivå, transaktionsid, delegeringskedja

Hypotes

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.

Attributmodell

I federativa 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.

Attributprofiler

En attributprofil är uppsättning behörighetsattribut som som möjliggör för 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.

Regler och rekommendationer

För att stödja livscykelhantering av attributprofiler utan att störa verksamheters behov av robust digital samverkan, bör man tillämpa följande rekommendationer:

Det SKA för varje domän etableras minst en attributprofil för SAML och en attributprofil för OIDC.
Attributprofiler BÖR revideras med bakåtkompabilitet, dvs man bör i stort sett aldrig ersätta attribut eller genomföra andra icke bakåtkompatibla förändringar.
Kompabilitetsbrytande revideringar av attributprofiler BÖR genomföras genom en övergångsperiod av bakåtkompatibla förändringar och parallellt stöd för äldre och nyare behörighetsattribut i tjänsteproducenters behörighetskontroll.

Notera att det för specifika situationer där förutsättningar finns för att driva igenom brytande revideringar av attributprofiler utan negativ verksamhetspåverkan för samverkande parter, kan det vara att föredra.

Exemplifiering för hälsosektorn

Inom hälsosektorn används en attributprofil, i vilken man kan uttrycka att en användare kan ha ett antal olika systemspecifika rolltilldelningar (SystemRole), vårdspecifika uppdrag (Commission), samt så kallade administrativa uppdrag (AdminCommission) inom ett visst organisatoriskt omfång (AuthorizationScope).

Notera att Ineras IdP låter användaren välja vilken av uppdragen som ska representeras som "aktivt" och då få sina claims kopierade till rotnivån i intyget. Alla uppdrag kan även bifogas (allCommissions) och då kan eTjänsten låta användaren välja vilket uppdrag som ska användas för åtkomstbeslut, loggning, m.m. i e-tjänsten.

{
"commissionPurpose": "Administration",
"at_hash": "qEj37dgo2bQEyePuzqDyNQ",
"pharmacyIdentifier": "731.1337.1337:Apotek",
"sub": "1a400571-a2d0-4b28-b9da-11400ba496e1",
"healthCareUnitName": "Admin",
"credentialCertificatePolicies": [
"2.23.140.1.2.3",
"1.2.752.74.8.506"
],
"amr": [
"urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient"
],
"iss": "https://idp.dev.inera.test:8443/oidc",
"credentialGivenName": "Olof",
"healthcareProviderId": "2321000214",
"commissionHsaId": "SE111-UPPDRAG-JLL-TEKSYSADMIN",
"acr": "http://id.sambi.se/loa/loa3",
"systemRole": [
{
"systemId": "BIF",
"role": "Loggadministratör"
},
{
"systemId": "BIF",
"role": "Administrator"
},
{
"systemId": "PU",
"role": "Administratör"
}
],
"organizationIdentifier": "2321000214",
"credentialSurname": "Olsson",
"auth_time": 1610616929,
"healthCareProviderName": "SE111-JLL",
"exp": 1610618196,
"healthCareProviderHsaId": "SE111-JLL",
"iat": 1610617896,
"commissionRight": [
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "dia"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "fun"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "lkf"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "lkm"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "lko"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "pad"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "pat"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "und"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "upp"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "vbe"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "vko"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "voo"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "vot"
},
{
"activity": "Läsa",
"scope": "VG",
"informationClass": "vpo"
}
],
"organizationName": "SE111-JLL",
"healthCareUnitHsaId": "SE111-ADMIN",
"authorizationScope": [
{
"authorizationScopePropertyName": "Tjänstesupport",
"authorizationScopeName": "Hitta och jämför vård",
"authorizationScopeCode": "HJV",
"authorizationScopePropertyCode": "HJV;003",
"authorizationScopeDescription": "Hitta och jämför vård är den del på 1177.se som presenterar kontaktinformation till landets vårdmottagningar, deras vårdutbud och vårdkvalitet.Varje enskild mottagning har ett eget ”kontaktkort” där kontaktuppgifter, e-tjänster och övrigt utbud presenteras.",
"authorizationScopePropertyDescription": "Tjänstesupport Beskrivning",
"adminCommissions": [
{
"adminCommissionHsaId": "TNT4477663322-1021",
"sector": [
{
"sectorFlag": true,
"feignedUnit": null,
"name": "CGI Östersund",
"unitHsaId": "TNT4477663322-101Q"
}
],
"adminCommissionResponsibleOrganisation": "447766-3323",
"feignedAdminCommission": null
}
]
},
{
"authorizationScopePropertyName": "Redaktör kontaktkort",
"authorizationScopeName": "Hitta och jämför vård",
"authorizationScopeCode": "HJV",
"authorizationScopePropertyCode": "HJV;001",
"authorizationScopeDescription": "Hitta och jämför vård är den del på 1177.se som presenterar kontaktinformation till landets vårdmottagningar, deras vårdutbud och vårdkvalitet.Varje enskild mottagning har ett eget ”kontaktkort” där kontaktuppgifter, e-tjänster och övrigt utbud presenteras.",
"authorizationScopePropertyDescription": "Redaktör kontaktkort får administrera information på kontaktkorten förutom kontaktkorten.",
"adminCommissions": [
{
"adminCommissionHsaId": "TNT4477663322-1021",
"sector": [
{
"sectorFlag": true,
"feignedUnit": null,
"name": "CGI Östersund",
"unitHsaId": "TNT4477663322-101Q"
}
],
"adminCommissionResponsibleOrganisation": "447766-3323",
"feignedAdminCommission": null
}
]
}
],
"x509SubjectName": "EMAILADDRESS=olof.olsson@inera.test, SERIALNUMBER=TNT4477663322-1046, GIVENNAME=Olof, SURNAME=Olsson, CN=Olof Olsson, O=Inera AB, L=SITHS, C=SE",
"given_name": "Olof",
"x509IssuerName": "CN=TEST SITHS e-id Person HSA-id 3 CA v1,O=Inera AB,C=SE",
"aud": "https://sp.dev.inera.test:8881",
"commissionName": "Teknisk Systemadministratör JLL",
"credentialPersonalIdentityNumber": "TNT4477663322-1046",
"credentialCertificate": "MIIGLDCCBBSgAwIBAgIPAXFdbr7VwpjRZAID8OW5MA0GCSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhJbmVyYSBBQjEqMCgGA1UEAwwhVEVTVCBTSVRIUyBlLWlkIFBlcnNvbiBJRCAzIENBIHYxMB4XDTIwMDQwOTA1MzQzMFoXDTI1MDMzMDIyNTk1OVowgYExCzAJBgNVBAYTAlNFMQ4wDAYDVQQHDAVTSVRIUzERMA8GA1UECgwISW5lcmEgQUIxFjAUBgNVBAMMDVN2ZW4gRXJpY3Nzb24xETAPBgNVBAQMCEVyaWNzc29uMQ0wCwYDVQQqDARTdmVuMRUwEwYDVQQFEwwxOTQyMTExOTY5NzkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD74bO125QuwwNfYwFa+FphbBoyw3i1Rw7g6d/xCckEiuMBDVMlyit6y2AbU6NLPoB+RhZir4ZL2bTO+Hc06YXS/3ShQZ6gz4QkYpZLAEnvJSnKmXafJCU/UP2ELu64wpl+TBpzIwdEfvSYKVOoklwo4QMs/VxywMXb3tJUl0N6zqZ9IQid7s2SvNb66Z65KRCFlObqIoSPulds+oDxuCwrrJcd/QvKddrRXXvg1H4ZMTtssTGF58ACqO74qc2F5+MpmJ3unjnz6khaWBJj8rHZcdzWKpRe/iEUhSlMw/biW1uJWEWZP8YLxSn/bRLYmI4GQUDU/6+N+oPuoMeQ+3tAgMBAAGjggHTMIIBzzAfBgNVHSMEGDAWgBToKeVtVR3Xg9I2+z+WTQEBj4ec1DAdBgNVHQ4EFgQUN9CzE5NcPeOpM/7I1yGVfUIeaAowDgYDVR0PAQH/BAQDAgWgMIGJBgNVHSAEgYEwfzA9BgZngQwBAgMwMzAxBggrBgEFBQcCARYlaHR0cHM6Ly93d3cuaW5lcmEuc2Uvc2l0aHMvcmVwb3NpdG9yeTA+BgcqhXBKCIN2MDMwMQYIKwYBBQUHAgEWJWh0dHBzOi8vd3d3LmluZXJhLnNlL3NpdGhzL3JlcG9zaXRvcnkwRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2NybDFwcC5zaXRocy5zZS90ZXN0c2l0aHNlaWRwZXJzb25pZDNjYXYxLmNybDATBgNVHSUEDDAKBggrBgEFBQcDAjB0BggrBgEFBQcBAQRoMGYwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwMXBwLnNpdGhzLnNlMD8GCCsGAQUFBzAChjNodHRwOi8vYWlhcHAuc2l0aHMuc2UvdGVzdHNpdGhzZWlkcGVyc29uaWQzY2F2MS5jZXIwHwYGKoVwIgIBBBUTEzk3NTIyNjk4NzU3MDAxMDExODkwDQYJKoZIhvcNAQELBQADggIBAG6X/KblSrVX+JLLcEu/667sVybfc78QbPeIPO9a2/kIh4ZMOBgo+ep9imXWwkkFiBDXE6fp2ZhM+wBm00WytyPHyVUJnCx1a1QCx6DinAWZZYU+b/XBjKSbJ95a6zPkZioexIy10kWiT7qeKQooWRkLpTv/AuJMTcTAOUT36NzobovBW0ccqvbjeMVB2kX+eh0ntOk8OGPxBVYeCfLkQrn9OENRXCxEGSdxtlU1jkZC+lmCP5CtslJnykFI97N804kL9gJmUwXZnYqi28YJoYdJu8LtyV5Rq1JoRrhuYMrXpgloXXilxD8ZhP+K0mciPhjnHrBbrgcsITfyc1Cm0wpGqnBQ17DEsQLjLWeLpc6JSzoKqxwYaLb9ALJK9yLWZh6YcmuXM6qhtJZ98IMa7PstPJaabG09do05VBzfHxbAGMPWqdTBfK0vEqZvGFJuZS0e+xk9SSrpK/hpTzucQS+tr8C5fcjmXJ6ubkG7SWg9lAIWACKiGDCUADILq+dp10xHQSqFsfLJpyOGHF4pwvGj7czEe1XJj/1cPONCpDlSQUiOc0naQjQhlkjDGeoGfwqT+0OCWugGcZLmGpRv8ltKV8UEieuy3eLEdwLnfZeY3Tvg5BDD4QRZMcnrMFEiJcxW1zeXHmBMgPpGdHJxWmPqOsUWVslVtEl3e2iF8YES",
"employeeHsaId": "TNT4477663322-1046",
"name": "Olof Olsson",
"credentialDisplayName": "Olof Olsson",
"credentialOrganizationName": "Inera AB",
"family_name": "Olsson",
"authenticationMethod": "SITHS_EID_SAME_DEVICE",
"allEmployeeHsaIds": [
"TSTNMT2321000156-10NG",
"TSTNMT2321000156-10NX"
],
"allCommissions": "[{\"employeeHsaId\":\"TSTNMT2321000156-10NG\",\"commissionName\":\"Teknisk Systemadministratör JLL\",\"commissionHsaId\":\"SE111-UPPDRAG-JLL-TEKSYSADMIN\",\"commissionPurpose\":\"Administration\",\"healthCareUnitHsaId\":\"SE111-ADMIN\",\"healthCareUnitName\":\"Admin\",\"healthCareProviderHsaId\":\"SE111-JLL\",\"healthCareProviderName\":\"SE111-JLL\",\"healthCareProviderOrgNo\":\"2321000214\",\"commissionRights\":[{\"activity\":\"Läsa\",\"informationClass\":\"dia\",\"scope\":\"VG\"},{\"activity\":\"Läsa\",\"informationClass\":\"fun\",\"scope\":\"VG\"}]},{\"employeeHsaId\":\"TSTNMT2321000156-10NX\",\"commissionName\":\"Teknisk Systemadministratör SLL\",\"commissionHsaId\":\"SE222-UPPDRAG-SLL-TEKSYSADMIN\",\"commissionPurpose\":\"Administration\",\"healthCareUnitHsaId\":\"SE222-ADMIN\",\"healthCareUnitName\":\"Admin\",\"healthCareProviderHsaId\":\"SE222-SLL\",\"healthCareProviderName\":\"SE222-SLL\",\"healthCareProviderOrgNo\":\"2321000214\",\"commissionRights\":[{\"activity\":\"Läsa\",\"informationClass\":\"dia\",\"scope\":\"VG\"},{\"activity\":\"Läsa\",\"informationClass\":\"fun\",\"scope\":\"VG\"}]}]",
"allCommissionOrgAffiliations": [
"TSTNMT2321000156-10NG@123456-7890",
"TSTNMT2321000156-10NX@654321-0987"
],
"userOrganizationHsaId": "SE2321000156-0001",
"sithsEidChallenge": "b90fc25314de41ffaf88c03677e2caac"
}

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öljande roller och ansvar BÖR etableras:

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

Domän	Domänkoordinator
Health	E-hälsomyndigheten
Skola	SIS
Forskning och högre utbildningar	SUNET
Transport	Transportstyrelsen

Exempel på förvaltningsstruktur - Transportsektorn

Ledningsaktören (Digg) utser Transportstyrelsen till domänkoordinator för Transport-domänen.
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.

Exemplifierade domäner

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?

En semantisk eller redaktionell uppdatering i profil → tekniskt breaking change
Och det är ofta oproportionerligt dyrt.

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
Versionering ska ske i profilen, inte i attributet
Om något förändras – använd kompatibilitetsprincipen
Om du kan uppdatera profilen utan att bryta existerande implementationer → behåll attributets URI.
Om det bryter → skapa nytt attribut och deprecera det gamla.

Slutsats: inget versionsnummer i attributnamnet

Attributlista

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

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.

Oops, it seems that you need to place a table or a macro generating a table within the Table Filter macro.

Beskrivning	Namn (SAML)	Namn (OIDC)	Referens	FriendlyName	Alternativt namn (SAML)	Exempelvärden	Källa	Kategori	Domän	Multivärde J/N
Visningsnamn	https://id.ena-infrastructure.se/attributes/displayName	name	urn:oid:2.16.840.1.113730.3.1.241
Personnummer	https://id.ena-infrastructure.se/attributes/personalIdentityNumber	https://id.oidc.se/claim/ personalIdentityNumber	urn:oid:1.2.752.29.4.13	personalIdentityNumber			Katalog	Identitetsattribut
Personnummer	https://id.ena-infrastructure.se/attributes/eid/health/personalIdentityNumber	https://id.ena-infrastructure.se/attributes/eid/health/personalIdentityNumber	urn:oid:1.2.752.29.4.13	personalIdentityNumber			Elegitimation	Identitetsattribut
Samordningsnummer	https://id.ena-infrastructure.se/attributes/coordinationNumber	https://id.oidc.se/claim/ coordinationNumber	urn:oid:1.2.752.29.4.13	coordinationNumber			Katalog	Identitetsattribut	general
Samordningsnummer	https://id.ena-infrastructure.se/attributes/eid/health/coordinationNumber	https://id.ena-infrastructure.se/attributes/eid/health/coordinationNumber	urn:oid:1.2.752.29.4.13	coordinationNumber			Elegitimation	Identitetsattribut	health
HSA-id för anställd	https://id.ena-infrastructure.se/attributes/health/employeeHsaId	https://id.ena-infrastructure.se/attributes/health/employeeHsaId	urn:oid:1.2.752.29.6.2.1	employeeHsaId	urn:oid:1.2.752.29.6.2.1		Katalog	Identitetsattribut	health	N
HSA-id för anställd	https://id.ena-infrastructure.se/attributes/eid/health/employeeHsaId	https://id.ena-infrastructure.se/attributes/eid/health/employeeHsaId	urn:oid:1.2.752.29.6.2.1	employeeHsaId	urn:oid:1.2.752.29.6.2.1		Elegitimation	Identitetsattribut	health	N
Anställds organisationstillhörighet, id	https://id.ena-infrastructure.se/attributes/OrganizationIdentifier	https://id.oidc.se/claim/orgNumber	urn:oid:2.5.4.97	orgNumber		8024050190	Katalog	Relationsattribut	general	N
Anställds organisationstillhörighet, namn	https://id.ena-infrastructure.se/attributes/OrganizationName	https://id.oidc.se/claim/ orgName						Relationsattribut	general
Anställds organisationstillhörighet knutet till uppdraget eller aktuell organisation, id	https://id.ena-infrastructure.se/attributes/health/OrganizationIdentifier	https://id.ena-infrastructure.se/attributes/health/OrganizationIdentifier	urn:oid:2.5.4.97	organizationIdentifier			Katalog	Relationsattribut	health
Anställds organisationstillhörighet knutet till uppdraget eller aktuell organisation, namn	https://id.ena-infrastructure.se/attributes/health/OrganizationName	https://id.ena-infrastructure.se/attributes/health/OrganizationName						Relationsattribut	health
OrgAffiliation, knutet till uppdraget eller aktuell organisation	https://id.ena-infrastructure.se/attributes/OrgAffiliation	https://id.oidc.se/claim/ orgAffiliation
E-post	https://id.ena-infrastructure.se/attributes/mail	https://id.ena-infrastructure.se/attributes/mail	urn:oid:0.9.2342.19200300.100.1.3	mail		mans.johansson@storhamrakommun.se anna-maria.de-la-cruz@specialistmyndigheten.se karl-olof.ornstedt@nordicfuturegymnasium.se		Kommunikationsattribut	general

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)

Vägledning elektronisk underskrift (SKR)

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

Page tree

Attributramverk för Samordnad identitet och behörighet (SIB) – typindelning, kärna och domänprofiler

Inledning

Uppdrag

Principer för uppdragets leverabler

Avgränsningar

Exemplifierande användningsfall

Behörighetsattribut

Identifierare

Object Identifier (OID)

HTTP-URI

Relationen mellan OID och HTTP-URI

Interoperabilitetsanalys

Attributkategorier

Hypotes

Attributmodell

Teknisk aktör

Attributprofiler

Exemplifiering för hälsosektorn

Förvaltningsstruktur

Exempel på domäner

Exempel på förvaltningsstruktur - Transportsektorn

Exemplifierade domäner

Generiska attribut

Frågeställningar

Ska namnet på attributet spegla källan, till exempel /eid för e-legitimation och /idp för IdP?

OID som attributnamn

Övrig semantik i attributnamnet

Versionshantering av attribut

Attributlista

Referenser

Exempel

SAML

OIDC