...
Fokus för detta dokument är att beskriva arbetet när man har ett behov av behörighetsgrundande information för ett behörighetsbeslut och hur man säkerställer att denna information uttrycks på ett sätt som främjar interoperabilitet och återanvändbarhet.
...
Uppdragets leverabler
Arbetsgruppen har i uppdrag att skapa en gemensam och hållbar grund för hantering av behörighetsattribut i federativa och sektorsgemensamma sammanhang.
...
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Principer
...
i framtagandet
- Respektera gjorda investeringar i dagens attributanvändning
- 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.
- 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.
- De komponenter som tillför behörighetsattribut bör ha vetskap om synonymer för att kunna svara på attributbegäran
- Favorisera brett förankrade attributsdefinitioner framför att skapa nya
- Behörighetsattribut 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 befintligt attribut saknas.
Rekommendera selektiv användning
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.
...
- Utfärdande organisation
- Hemorganisation/anställning
- Företrädd organisation i aktuellt uppdrag
- Roll och mandat i den specifika situationenen specifik situation
Ytterligare ett krav är att det i vissa situationer kan vara viktigt att kunna uttrycka från vilken källa ett attribut härrör sig. Till exempel vid utgivning av en mobil e-legitimation utifrån en legitimering med en fysisk e-legitimation kan det vara tvunget att säkerställa att identiteten härrör från den fysiska e-legitimationen och inte inte från en annan attributkällan.
...
För att säkerställa långsiktig hållbarhet, interoperabilitet och tydligt ansvar behöver attributsdefinitioner och attributprofiler attributlistor förvaltas i en definierad struktur med tydliga roller och mandat.
...
| Info | ||
|---|---|---|
| ||
Ett viktigt attribut som kan hänföra sig till den organisatoriska dimensionen är orgAffiliation och andra uppdragsrelaterade behörighetsattribut.
Notera att man som princip ska minimera information som man delger om en användare, så alternativ 2 bör användas sparsamt. |
| Info | |||||
|---|---|---|---|---|---|
| |||||
OM en förlitande part explicit vill ha behörighetsattributet med värdet från e-legitimationen kan man specificera detta i claims-begäran genom att kräva LoA3
|
Hur nya behörighetsattribut definieras
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.
- Betydelse: betydelse / tolkning av det värde som ges i detta attribut?
- Status: En indikering om attributet är aktivt, under utfasning, eller utfasat.
- Synonymer: en eller flera attributidentifierare som kan användas synonymt med detta attribut
Identifierare (attributnamn)
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.
...
Om man använder textuella namn eller URI:er brukar identifieraren även benämnas "attributnamn".
| Expand | ||
|---|---|---|
| ||
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:
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:
OID svarar på frågan om vad något är:
HTTP-URIEn 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:
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:
Relationen mellan OID och HTTP-URIFö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:
Den semantiska definitionen är således knuten till OID, inte till HTTP-URI. OID definierar objektets identitet. HTTP-URI är ett kontextuellt alias. InteroperabilitetsanalysOID 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å:
Ett exempel OID 2.5.4.10 identifierar begreppet organizationName på en generell semantisk nivå. Dock gäller:
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:
HTTP-URI i federationen säger:
|
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 attributkategorier har skilda egenskaper avseende stabilitet, tillitsnivå och förekomst av ansvarig utfärdare, vilket i sin tur påverkar hur de bör användas som underlag för åtkomstbeslut.
...
| Expand | ||
|---|---|---|
| ||
HypotesAlla attribut är inte av samma slag. Attribut kan exempelvis:
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. AttributmodellI federativa miljöer används attribut för att:
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:
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örPlaceholder för subject som kan vara api, api-klienter, etc. |
Exemplifiering och validering
- 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
...
- Personalidentity - både pnr och snr eller separata attribut?
- Ska vi lägga in synonymer från andra federationer, t ex Sambi? JA, se lista
- Kan vi lösa de olika synsätten på att peka ut e-legitimationen som källa i namnet genom att göra denna typ av attribut domänspecifika? (https://id.ena-infrastructure.se/attributes/surName jfr med https://id.ena-infrastructure.se/attributes/eid/health/surName). Ska källan i det första fallet vara okänd? Beroende på vilken IdP man använder?
- Attribut som saknas i nuvarande Sambi, t ex Middlename, vad gör vi med dom?
- Enhet som generellt attribut, andra är domänspecifika t ex vårdenhet, skolenhet?
Val av attribut
Namnen är hämtade från OIDC Core, OIDC Sweden och inspirerade av Sambis attributprofil. Domänen health kommer mycket från Ineras IdP då de också är överenskomna med Ehälsomyndigheten. Sweden Connect har gett eIDAS-namnen. Se referenser.
...
| draw.io Board Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Attribut / attributlista
| Info |
|---|
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. |
...