...
| Modell | HTA | NTA | DTA med TBE | IIMAR |
|---|---|---|---|---|
| Länk | HTA | NTA | DTA | IIMAR |
| Skiss | ||||
| Kort beskrivning | Centraliserad modell med en nationell Trust Anchor som rot. All policy styrs uppifrån och ned via Intermediates. Enkel och enhetlig validering men begränsad flexibilitet. | Lokala Trust Anchors som pekar på en övergripande nationell Trust Anchor. Balans mellan lokal autonomi och nationell styrning, med möjlighet till både lokal och central validering. | Decentraliserad modell med oberoende Trust Anchors. En Trusted Bridging Entity (TBE) distribuerar nycklar utanför OIDF-specen. | Flera oberoende Trust Anchors kan dela Intermediates, vilket möjliggör interoperabilitet utan nyckeldistribution mellan Trust Anchors. |
För- och nackdelar | Beskrivning: En nationell Tillitsankartjänst som är rot. Fördelar:
Nackdelar:
| Beskrivning: En nationeTrust Anchor, men dessa pekar uppåt mot en nationell Trust Anchor. Fördelar:
Nackdelar:
| Beskrivning: Varje federation har en helt fristående Trust Anchor. Nycklar publiceras via en extern Trusted Bridging Entity (TBE). Ingen hierarki. Fördelar:
Nackdelar:
| Beskrivning: Flera oberoende Trust Anchor länkas ihop genom gemensamma shared Intermediates). Fördelar:
Nackdelar:
|
OIDF stöd | Fullt stöd enligt OIDF specifikationen | Ej fullt stöd enligt OIDF specifikationen | Stöds ej enligt specifikationen | Fullt stöd enligt OIDF specifikationen |
OIDF Policyhantering |
|
|
|
|
Arkitekturell jämförelse av OIDF-modeller
Tabellen nedan analyserar hur olika tillitsmodeller enligt OpenID Federation kan stödja de arkitekturella drivkrafter som identifierats för Enas federationsinfrastruktur. Varje modell – från den hierarkiska HTA till den mer distribuerade IIMAR – erbjuder olika balans mellan styrning, flexibilitet, interoperabilitet och kostnadseffektivitet. Syftet är att tydliggöra hur val av modell påverkar förmågan att uppnå nationell samordning samtidigt som lokal autonomi, innovation och långsiktig skalbarhet bevaras.
| Arkitekturell drivkraft | HTA – Hierarchical Trust Anchors | NTA – Nested Trust Anchors | DTA – Disconnected Trust Anchors (med TBE) | IIMAR – Interlinked Intermediates with Multi-Anchor Resolution |
|---|---|---|---|---|
| Ökad kostnadseffektivitet | Enhetlig styrning och enkel validering minskar driftkostnader, men central administration ger hög overhead. | Delad styrning mellan nationell och lokal nivå minskar kostnader inom varje federationskontext, men kräver samordning. | Varje federation bär full kostnad för egen styrning och nyckelhantering, vilket ger låg kostnadseffektivitet. | Delad federationsinfrastruktur och återanvändning av anslutningstjänster ger god kostnadseffektivitet, trots något högre komplexitet. |
| Behov av gränsöverskridande samverkan | Svårt att samverka internationellt utan central auktorisation. | Möjliggör interoperabilitet via gemensam nationell rot. | Ger möjlighet till selektiv interoperabilitet via extern nyckeldistribution (TBE), men risk för fragmentering. | Mycket god – möjliggör interoperabilitet mellan flera kontexter utan gemensam hierarki. |
| Minskad integrationsbörda | Enkel valideringsmodell med en gemensam rot för validering av tillitsinformation. | Gemensam teknisk grund men lokal ansvarsfördelning kräver viss koordination. | Hög integrationsbörda eftersom nyckelhantering och validering sker separat. | Gemensam federationsinfrastruktur med flera federationskontext minskar behov av separata integrationer och möjliggör återanvändning. |
| Främjande av innovation och decentralisering | Centralstyrd modell begränsar lokala initiativ. | Möjliggör lokala anpassningar inom nationella ramar. | Full frihet till innovation, men risk för oenhetlighet. | Stödjer innovation genom flera federationskontext under gemensam styrning och teknisk samordning. |
| Stöd för behovsdriven förändring över tid | Trögrörlig – alla ändringar kräver central uppdatering. | Lokala förändringar möjliga inom respektive federationskontext. | Hög flexibilitet – varje federation kan utvecklas i egen takt. | Mycket flexibel – nya kontexter och kan införas utan att påverka befintliga. |
| Stöd för utveckling i ett heterogent landskap | Begränsad tolerans för variation mellan aktörer. | Hanterar olika mognadsnivåer via lokal autonomi och gemensamma regler. | Fullt oberoende mellan federationer men utan enhetlig styrning. | Mycket god – flera tillitsstrukturer kan samexistera inom en gemensam teknisk och styrd ram. |
...
Analys av olika OpenID Federation tillitsmodeller inom Ena
Precis som de arkitektoniska modellerna för en nationell OpenID Federation beskriver olika sätt att fördela tillit mellan Tillitsankartjänster (Trust Anchors), Anslutningstjänster (Intermediates) och Tillitsmärkestjänster (Trust Mark Issuers), så innebär valet av modell också direkta konsekvenser för Ena och de organisationer som verkar inom infrastrukturen.
Effekterna märks på flera nivåer: hur tillitshanteringen organiseras och vilka tillitsmärken som krävs, hur federationsinfrastrukturen drivs och utvecklas av operatörer, samt hur digital samverkan mellan myndigheter, kommuner, regioner och privata aktörer realiseras i praktiken.
Varje modell innebär olika balans mellan central styrning och lokal autonomi, mellan enkelhet i validering och flexibilitet i policytillämpning. Det påverkar både ledningsaktören, de operatörer som driver Tillitsankartjänster (Trust Anchors), Anslutningstjänster (Intermediates) eller Tillitsmärkestjänster (Trust Mark Issuers), samt de federationsmedlemmar (Federation Members) som ansluter sina digitala tjänster till infrastrukturen.
I följande avsnitt analyseras därför konsekvenserna av de olika modellerna för Ena och dess aktörer – med fokus på tillitshantering, federationsinfrastrukturens funktion och förutsättningarna för digital samverkan.
...
Ena
Governance
...
- Behövs främst för att underlätta tillämpning och förståelse av den centrala policyn – t.ex. stödmaterial, vägledningar och gemensamma processer för anslutning.
- Ena:s roll blir alltså att stötta införande och praktisk användning, snarare än att kompensera för tekniska brister i styrningen
...
- Ena behöver ge vägledning, profileringar och exempel på hur lokala federationer ska komplettera den nationella policyn.
- Även processer för konflikthantering behövs, eftersom OIDF-policy mekanismer inte räcker för att undvika interoperabilitet mellan NTA och LTA
...
- Ena måste etablera governance, gemensamma minimikrav, och koordinering av nyckelpublicering och policy.
- Här blir mjuk styrning den enda möjligheten att skapa interoperabilitet.
...
- Ena måste stötta genom att samordna hur Intermediates ska publicera metadata och tillitsmärken på ett enhetligt sätt över flera TA:er.
- Även vägledning för hur validering ska göras när flera Tillitsankartjänster är möjliga för validering av tillit.
...
Konsekvenser för
Ledningaktör
...
- Säkerställa att aktörer förstår och kan tillämpa policyn i praktiken, genom vägledningar, stöd i onboarding och gemensamma processer.
...
- Ge ramar för hur lokala federationers policy ska komplettera den nationella. Ta fram profileringar, processer och konflikthantering som jämkar nivåerna.
...
- Samordna hur Intermediates ska hantera och publicera policy från flera Tillitsankartjänster.
- Säkerställa gemensam hantering av tillitsmärken och ge riktlinjer för multipla valideringskedjor.
...
Konsekvenser för nationell federationsoperatör
...
- Säkerställa att anslutna Anslutningoperatörer förstår och följer nationell policy, hantera onboarding och incidentprocesser, samt vara stödjande i praktisk drift.
...
- Ta fram nationell policy som omfattar alla behov av nationell interoperabilitet
...
N/A
...
Konsekvenser för
Federationsoperatör
...
N/A
...
- Översätta nationell policy till lokal policy,
- Stödja medlemmar i att följa nationell och lokal policy, och rapportera konflikter uppåt till Ledningsaktören.
...
N/A
...
- Delta och Koordinera mellan olika Federationsoperatörer för att säkerställa konsekvent publicering av nationella Tillitsoperatörer
- Ge vägledning om valideringsskillnader och stödja Anslutningoperatörer i att hantera motstridiga krav.
...
Konsekvenser för
Anslutningsoperatör
...
- Ansluta till flera Tillitsankartjänster
- Hantera eventuell motsägande policyer
...
Konsekvenser för federationsmedlemmar
...
Vid validering behöver entiteter bara förhålla sig till en Tillitsankartjänst
...
Vid validering måste entiteter kunna hantera flera Tillitsankartjänster
Lokal
Nationell
...
Vid validering måste entiteter kunna hantera flera Tillitsankartjänster
Lokal
Nationell
Behovsanalys
En Tillitsankartjänst utgör den yttersta källan till tillit och skapar därmed ett federationskontext – en gemensam teknisk ram där anslutna tjänster kan verifieras och ingå i samma tillitsstruktur. Inom ett sådant federationskontext kan aktörer dessutom använda tillitsmärken för att definiera vilka tillitsskapande krav som är uppfyllda. På så sätt kan man etablera olika samverkanskontexter där informationsutbyte sker på villkor som är anpassade efter behov och kravbild, utan att frångå den gemensamma tekniska grunden.
Detta väcker frågan om hur många Tillitsankartjänster som behövs och varför en modell med flera Tillitsankartjänster skulle kunna vara en fördel i en nationell federationsinfrastruktur.
Möjliga behov bakom etablering av flera federationskontext
Att organisera en nationell federationsinfrastruktur kring flera federationskontext och därmed Tillitsankartjänster (Trust Anchor enligt OIDF specifikationen) skapar flexibilitet och möjlighet till anpassning för de olika behov som finns i samverkan.
...
Olika tillitsmodeller och styrning
All samverkan behöver inte bygga på samma modell för tillit. Vissa sammanhang kräver styrning enligt ISO 27000 med ledningssystem för informationssäkerhet, medan andra skulle kunna bygga på helt andra regelverk eller kravbilder. Genom att tillåta flera Tillitsankartjänster kan man tillämpa olika tillitsmodeller parallellt, men ändå hålla ihop tekniskt via en gemensam federationsinfrastruktur.
...
Olika tekniska protokoll och standarder
All samverkan behöver inte ske med OIDC eller OAuth. Det finns etablerade miljöer som bygger på SAML, eller andra standarder. Om all metadata blandas i en och samma federationskontext riskerar infrastrukturen att bli svårhanterlig. Med flera Tillitsankartjänster kan man istället skapa tydliga avgränsningar där varje Tillitsankartjänst ansvarar för sitt tekniska område och sina policyer.
...
Arkitekturella drivkrafter
Här ska vi beskriva drivkrafterna bakom valet av modell
Nedan hämtat från Kap 1.1.1 Ena IAM - sammanhållen identitet- och behörighetshantering
...
Behovsanalys
En Tillitsankartjänst utgör den yttersta källan till tillit och skapar därmed ett federationskontext – en gemensam teknisk ram där anslutna tjänster kan verifieras och ingå i samma tillitsstruktur. Inom ett sådant federationskontext kan aktörer dessutom använda tillitsmärken för att definiera vilka tillitsskapande krav som är uppfyllda. På så sätt kan man etablera olika samverkanskontexter där informationsutbyte sker på villkor som är anpassade efter behov och kravbild, utan att frångå den gemensamma tekniska grunden.
Detta väcker frågan om hur många Tillitsankartjänster som behövs och varför en modell med flera Tillitsankartjänster skulle kunna vara en fördel i en nationell federationsinfrastruktur.
Möjliga behov bakom etablering av flera federationskontext
Att organisera en nationell federationsinfrastruktur kring flera federationskontext och därmed Tillitsankartjänster (Trust Anchor enligt OIDF specifikationen) skapar flexibilitet och möjlighet till anpassning för de olika behov som finns i samverkan.
Olika tillitsmodeller och styrning
All samverkan behöver inte bygga på samma modell för tillit. Vissa sammanhang kräver styrning enligt ISO 27000 med ledningssystem för informationssäkerhet, medan andra skulle kunna bygga på helt andra regelverk eller kravbilder. Genom att tillåta flera Tillitsankartjänster kan man tillämpa olika tillitsmodeller parallellt, men ändå hålla ihop tekniskt via en gemensam federationsinfrastruktur.Olika tekniska protokoll och standarder
All samverkan behöver inte ske med OIDC eller OAuth. Det finns etablerade miljöer som bygger på SAML, eller andra standarder. Om all metadata blandas i en och samma federationskontext riskerar infrastrukturen att bli svårhanterlig. Med flera Tillitsankartjänster kan man istället skapa tydliga avgränsningar där varje Tillitsankartjänst ansvarar för sitt tekniska område och sina policyer.Avgränsade samverkanskontexter
All samverkan sker inte mellan alla tjänster. I praktiken är det vanligt att grupper av tjänster främst utbyter information med varandra utifrån gemensamma behov och krav. För vissa typer av tjänster, som exempelvis intygstjänster, är det däremot vanligt att de används i flera olika samverkanskontexter eftersom de tillför generella förmågor som många behöver. Andra komponenter, somAPI:er eller klienter, är oftare knutna till ett mer specifikt behov av samverkan. Genom att införa flera Tillitsankartjänster kan man hantera denna variation: intygstjänster kan återanvändas brett, medan mer specialiserade komponenter kan styras inom en snävare kontext.
Arkitekturella drivkrafter
Här ska vi beskriva drivkrafterna bakom valet av modell
Nedan hämtat från Kap 1.1.1 Ena IAM - sammanhållen identitet- och behörighetshantering
- Ökad kostnadseffektivitet
Kostnadseffektivitet genom användning av etablerade standarder samt återanvändning av tidigare gjorda investeringar. Infrastrukturen och dess komponenter bygger i stor utsträckning på väl etablerade standarder, som OAuth2, vilket möjliggör användande av standardprodukter. Infrastrukturen är även anpassad för att kunna knytas till befintliga lösningar för exempelvis autentisering av användare, för att minimera behov av förändring då befintliga it-lösningar ansluta till infrastrukturen. Att kunna minska dagens manuella administration av medarbetare i digitala tjänster hos andra huvudmän och istället på ett tillitsfullt och standardiserat sätt kunna dela behörighetsgrundande information som underlag för åtkomst har stor potential ökad säkerhet och minskade administrativa kostnader. Behov av gränsöverskridande samverkan
Digital samverkan sker alltmer mellan olika sektorer, domäner och aktörer. En gemensam teknisk grund minskar behovet av kostsamma specialanpassningar för dessa situationer samt möjliggör att tillit och interoperabilitet kan skalas över gränser.Minskad integrationsbörda
Genom att etablera en gemensam federationsinfrastruktur kan nya tillämpningar återanvända befintliga mekanismer för autentisering, åtkomsthantering och etablering av tillit – istället för att varje organisation eller samverkansinitiativ behöver utveckla egna lösningar.Främjande av innovation och decentralisering
Genom att tillhandahålla en stabil och bred teknisk plattform kan olika verksamheter – offentliga såväl som privata – bygga egna tjänster och lösningar som samtidigt är fullt kompatibla med federationens ramverk.Stöd för behovsdriven förändring över tid
Arkitekturen möjliggör att olika delar (tillitshantering, teknisk federation, tillämpningar) kan vidareutvecklas i olika takt utan att skapa ömsesidiga beroenden som hämmar förändring.- Stöd för utveckling i ett heterogent landskap
Arkitekturen är utformad för att fungera i en miljö där olika organisationer befinner sig på olika nivåer av mognad, har olika tekniska förutsättningar och arbetar med varierande processer och system. Tjänster och digitala förmågor utvecklas i den takt och omfattning som organisationers resurser och prioriteringar tillåter. Detta främjar både flexibilitet och långsiktig samverkan, utan att de mest avancerade aktörerna behöver bromsa sin utveckling eller de mindre erfarna riskerar att hamna utanför.
Tekniska krav på federationsinfrastrukturen
Enkelhet och kostnadseffektivitet
Infrastrukturens komplexitet ska hanteras centralt så att det blir enkelt för federationsmedlemmar att ansluta.
Det innebär:stöd för smidig registrering av nycklar,
distribuerad anslutning och
möjlighet till delegerad självadministration.
Samordning av tillitsskapande krav
Konsoliderade säkerhetskrav och gemensamma tillitsskapande krav ska förmedlas till alla parter.
Förmågan att hantera och sprida tillitsinformation på ett distribuerat sätt är avgörande,
liksom att kunna tilldela och verifiera tillitsmärken.
Återanvändning av befintliga investeringar
Infrastrukturen ska kunna samverka med redan etablerade lösningar – legitimeringstjänster, attributkällor och befintliga federationer
och stödja efterlevnadskontroller utan att duplicera kostnader eller processer.
Robusthet och säkerhet
Federationsinfrastrukturen måste vara tålig, med redundans,
stöd för alternativa kommunikationsnät (t.ex. SGSI) och
kontinuerliga kontroller av efterlevnad och säkerhet.
Skalbarhet och flexibilitet
Nya aktörer ska kunna anslutas enkelt, och både infrastrukturen och de tekniska komponenterna för IAM måste kunna växa.
Det ska även vara möjligt att etablera nya samverkanskontexter över tid utan att påverka redan anslutna aktörer.
Arkitekturell jämförelse av OIDF-modeller
Tabellen nedan analyserar hur olika tillitsmodeller enligt OpenID Federation kan stödja de arkitekturella drivkrafter som identifierats för Enas federationsinfrastruktur. Varje modell – från den hierarkiska HTA till den mer distribuerade IIMAR – erbjuder olika balans mellan styrning, flexibilitet, interoperabilitet och kostnadseffektivitet. Syftet är att tydliggöra hur val av modell påverkar förmågan att uppnå nationell samordning samtidigt som lokal autonomi, innovation och långsiktig skalbarhet bevaras.
| Arkitekturell drivkraft | HTA – Hierarchical Trust Anchors | NTA – Nested Trust Anchors | DTA – Disconnected Trust Anchors (med TBE) | IIMAR – Interlinked Intermediates with Multi-Anchor Resolution |
|---|---|---|---|---|
| Ökad kostnadseffektivitet | Enhetlig styrning och enkel validering minskar driftkostnader, men central administration ger hög overhead. | Delad styrning mellan nationell och lokal nivå minskar kostnader inom varje federationskontext, men kräver samordning. | Varje federation bär full kostnad för egen styrning och nyckelhantering, vilket ger låg kostnadseffektivitet. | Delad federationsinfrastruktur och återanvändning av anslutningstjänster ger god kostnadseffektivitet, trots något högre komplexitet. |
| Behov av gränsöverskridande samverkan | Svårt att samverka internationellt utan central auktorisation. | Möjliggör interoperabilitet via gemensam nationell rot. | Ger möjlighet till selektiv interoperabilitet via extern nyckeldistribution (TBE), men risk för fragmentering. | Mycket god – möjliggör interoperabilitet mellan flera kontexter utan gemensam hierarki. |
| Minskad integrationsbörda | Enkel valideringsmodell med en gemensam rot för validering av tillitsinformation. | Gemensam teknisk grund men lokal ansvarsfördelning kräver viss koordination. | Hög integrationsbörda eftersom nyckelhantering och validering sker separat. | Gemensam federationsinfrastruktur med flera federationskontext minskar behov av separata integrationer och möjliggör återanvändning. |
| Främjande av innovation och decentralisering | Centralstyrd modell begränsar lokala initiativ. | Möjliggör lokala anpassningar inom nationella ramar. | Full frihet till innovation, men risk för oenhetlighet. | Stödjer innovation genom flera federationskontext under gemensam styrning och teknisk samordning. |
| Stöd för behovsdriven förändring över tid | Trögrörlig – alla ändringar kräver central uppdatering. | Lokala förändringar möjliga inom respektive federationskontext. | Hög flexibilitet – varje federation kan utvecklas i egen takt. | Mycket flexibel – nya kontexter och kan införas utan att påverka befintliga. |
| Stöd för utveckling i ett heterogent landskap | Begränsad tolerans för variation mellan aktörer. | Hanterar olika mognadsnivåer via lokal autonomi och gemensamma regler. | Fullt oberoende mellan federationer men utan enhetlig styrning. | Mycket god – flera tillitsstrukturer kan samexistera inom en gemensam teknisk och styrd ram. |
Tabellen visar att IIMAR-modellen kan ge det bästa samlade stödet för de arkitekturella drivkrafter som definierats för Ena IAM. Modellen kombinerar flexibilitet, decentraliserad utveckling och återanvändning av gemensam teknik, samtidigt som den bevarar nationell samordning och enhetliga principer för tillit och interoperabilitet. Detta gör IIMAR särskilt väl lämpad som grund för en nationell federationsinfrastruktur med flera federationskontexter under gemensam styrning.
Analys av olika OpenID Federation tillitsmodeller inom Ena
Precis som de arkitektoniska modellerna för en nationell OpenID Federation beskriver olika sätt att fördela tillit mellan Tillitsankartjänster (Trust Anchors), Anslutningstjänster (Intermediates) och Tillitsmärkestjänster (Trust Mark Issuers), så innebär valet av modell också direkta konsekvenser för Ena och de organisationer som verkar inom infrastrukturen.
Effekterna märks på flera nivåer: hur tillitshanteringen organiseras och vilka tillitsmärken som krävs, hur federationsinfrastrukturen drivs och utvecklas av operatörer, samt hur digital samverkan mellan myndigheter, kommuner, regioner och privata aktörer realiseras i praktiken.
Varje modell innebär olika balans mellan central styrning och lokal autonomi, mellan enkelhet i validering och flexibilitet i policytillämpning. Det påverkar både ledningsaktören, de operatörer som driver Tillitsankartjänster (Trust Anchors), Anslutningstjänster (Intermediates) eller Tillitsmärkestjänster (Trust Mark Issuers), samt de federationsmedlemmar (Federation Members) som ansluter sina digitala tjänster till infrastrukturen.
I följande avsnitt analyseras därför konsekvenserna av de olika modellerna för Ena och dess aktörer – med fokus på tillitshantering, federationsinfrastrukturens funktion och förutsättningarna för digital samverkan.
| Modell | HTA | NTA | DTA med TBE | IIMAR |
|---|---|---|---|---|
Ena Governance |
|
|
|
|
Konsekvenser för Ledningaktör |
|
| N/A |
|
Konsekvenser för nationell federationsoperatör |
|
| N/A | N/A |
Konsekvenser för Federationsoperatör | N/A |
| N/A |
|
Konsekvenser för Anslutningsoperatör |
| |||
Konsekvenser för federationsmedlemmar |
|
|
|
Tekniska krav på federationsinfrastrukturen
...
Enkelhet och kostnadseffektivitet
Infrastrukturens komplexitet ska hanteras centralt så att det blir enkelt för federationsmedlemmar att ansluta.
Det innebär:
stöd för smidig registrering av nycklar,
distribuerad anslutning och
möjlighet till delegerad självadministration.
...
Samordning av tillitsskapande krav
Konsoliderade säkerhetskrav och gemensamma tillitsskapande krav ska förmedlas till alla parter.
Förmågan att hantera och sprida tillitsinformation på ett distribuerat sätt är avgörande,
liksom att kunna tilldela och verifiera tillitsmärken.
...
Återanvändning av befintliga investeringar
Infrastrukturen ska kunna samverka med redan etablerade lösningar – legitimeringstjänster, attributkällor och befintliga federationer
och stödja efterlevnadskontroller utan att duplicera kostnader eller processer.
...
Robusthet och säkerhet
Federationsinfrastrukturen måste vara tålig, med redundans,
stöd för alternativa kommunikationsnät (t.ex. SGSI) och
kontinuerliga kontroller av efterlevnad och säkerhet.
Skalbarhet och flexibilitet
...
Nya aktörer ska kunna anslutas enkelt, och både infrastrukturen och de tekniska komponenterna för IAM måste kunna växa.
...
Rekommendation för Ena federationsinfrastruktur
...
