| Table of Contents |
|---|
Enas behov av 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.
Styrning och policyhantering - två nivåer
För att offentlig sektor ska kunna ha rådighet över den federativa infrastrukturen behöver vi gemensamt ta ställning till vilken nivå av ansvar som bör ligga hos myndigheter. Är det rimligt att just federationskontext förvaltas av myndigheter eftersom de kräver stabilitet och legitimitet i offentlig förvaltning?
En möjlig modell är att myndigheter även ansvarar för den första nivån av underordnade anslutningstjänster. Det skulle skapa en gemensam bas där aktörer kan ansluta sig under tydliga ramar, medan andra anslutningstjänster längre ut i hierarkin kan utvecklas av olika aktörer. På så sätt kan offentlig rådighet kombineras med flexibilitet och innovationskraft.
Samtidigt är det viktigt att komma ihåg att den ledningsaktör som ansvarar för infrastrukturen ändå kan styra genom att avgöra vilka federationskontext som accepteras och får ”anslutas " federationsinfrastrukturen. Även om flera aktörer driver olika federationskontext kan rådighet därför upprätthållas genom de överordnade regler och policies som styr helheten.
Frågan vi behöver diskutera är alltså: var bör gränsdragningen gå mellan offentlig styrning och mångfalden av andra aktörer, för att både tillit, robusthet och utvecklingsmöjligheter ska kunna säkerställas över tid?
Styrning av federationsinfrastrukturen (Ledningsaktörens ansvar)
Denna styrning handlar om övergripande reglering av hela infrastrukturen. Ledningsaktören sätter de ramar och krav som alla federationskontext måste följa för att vara en del av den nationella federationsinfrastrukturen.
Syftet är att säkerställa styrning, neutralitet och enhetlighet i hur federationsinfrastrukturen används för att skapa interoperabilitet mellan federationskontext.
Omfattar t.ex.:
Grundläggande säkerhetskrav och tillitsskapande principer
Gemensamma tekniska specifikationer och standardval (t.ex. att OIDF används, och vilka protokoll som kan användas)
Regler för hur federationskontext får etableras och anslutas
Krav på revision, incidentrapportering och förändringshantering
Ramverk för hur tillit, ansvar och avtal ska utformas
Motsvarar alltså den "yttre styrningen" – den nationella ramen.
Policy för ett federationskontext (Federationsoperatörernas ansvar)
Denna policy gäller inom ett specifikt federationskontext.
Syftet är att säkerställa att aktörerna inom just den federationen följer både de gemensamma nationella ramarna och de specifika krav som gäller för den aktuella federationen.
Omfattar t.ex.:
Vilken metadata ska publiceras och valideras
Vilka tillitsmärken som accepteras inom ett federationskontext.
- Eventuella utökningar av nationella regelverk
Motsvarar alltså den "inre styrningen" – den operativa policyn som omsätter de nationella reglerna i praktiken.
| Perspektiv | Styrning av federationsinfrastrukturen | OIDF-policy (Federationsområdesansvarig) |
|---|---|---|
| Nivå | Nationell, övergripande | Federationskontext, operativ |
| Ansvarig | Ledningsaktör | Federationsoperatör |
| Syfte | Gemensam styrning och samordning | Säkerställa efterlevnad av gemensamma regler inom ett Federationskontext |
| Fokus | Ramar, standarder, roller, tillsyn | Implementering, validering, metadata och tillitsmärken |
| Typ av krav | Strategiska och juridiska | Tekniska och operativa |
Anslutning till federationsinfrastrukturen och till federationskontext
Ena federationsinfrastruktur är uppbyggd för att skilja mellan hur aktörer ansluter tekniskt till infrastrukturen och på vilka villkor de samverkar inom olika federations- och samverkanskontext. Själva federationsinfrastrukturen utgör den tekniska grunden som gör det möjligt för aktörer att ansluta sina komponenter, publicera metadata och bli verifierbara i ett gemensamt nätverk. Den beskriver vem som vill samverka och på vilket sätt aktörernas komponenter kan hittas, verifieras och användas.
Federationskontexterna utgör grunden där villkoren för samverkan definieras. Varje federationskontext utgår från vilka krav, tillitsnivåer och regelverk som gäller för deltagande aktörer – inte från vilken typ av samverkan som sker. Det gör att flera olika typer av digital samverkan kan ske inom samma tekniska grund, men möjlighet till ytterligare tillitskapande strukturer. Ett federationskontext kan detaljeras ytterligare genom införandet av ett eller flera samverkanskontexter. Samverkanskontexter beskriver mer specifika verksamhetsmässiga eller tematiska ramar för informationsutbyte mellan aktörer, till exempel inom ett visst område eller en särskild tillämpning. På så sätt kan federationsinfrastrukturen stödja både övergripande styrning av till och finmaskig anpassning för olika typer av digital samverkan
När en organisation blir federationsmedlem ansluter den sig till den gemensamma federationsinfrastrukturen via en Anslutningsoperatör.
Detta innebär att organisationens tekniska komponenter (t.ex. legitimeringstjänster, auktorisationstjänster, API:er eller e-tjänster) registreras och publiceras i infrastrukturen på ett standardiserat sätt med signerad metadata och tillhörande tillitsinformation.
Syftet med denna anslutning är att:
ge komponenterna en teknisk identitet inom infrastrukturen,
säkerställa att deras metadata kan hittas, verifieras och användas av andra aktörer,
skapa grundläggande teknisk tillit genom kryptografisk validering mot en tillitsankartjänst.
Anslutningen till infrastrukturen är alltså teknisk och strukturell – den placerar aktören i nätverket och gör den sökbar, men säger ännu inget om vilken typ av samverkan eller vilka tillitskrav som gäller
Ett federationskontext representerar en särskild tillitsdomän kopplad till en Tillitsankartjänst.
Här definieras vilka tillitsmodeller, regelverk och tillitsmärken som gäller för de aktörer som ska samverka inom just det kontextet.
För att en ansluten aktör ska kunna delta i digital samverkan inom ett visst kontext krävs att:
den anslutande operatören är kopplad till det aktuella tillitsankaret,
aktören uppfyller de tillitsskapande krav som gäller för kontextet (t.ex. via tillitsmärken),
tillitskedjan för komponenten kan valideras upp till det tillitsankare som gäller för kontextet.
På så sätt kan samma tekniska anslutning till infrastrukturen användas i flera federationskontexter – men tilliten och regelverken verifieras separat i varje kontext.
Anslutningsoperatören utgör länken mellan den tekniska federationsinfrastrukturen och de olika federationskontexterna.
Operatören:
ansluter och administrerar sina medlemmars komponenter till infrastrukturen,
publicerar deras metadata,
kopplar anslutningen till ett eller flera federationskontexter,
Genom denna roll kan operatören även stödja interoperabilitet mellan olika tillitsankartjänster och kontexter, genom att samordna hur metadata publiceras och hur valideringstjänster används.
| Aspekt | Anslutning till federationsinfrastrukturen | Anslutning till federationskontext |
|---|---|---|
| Syfte | Tekniskt tillträde till infrastrukturen | Tillit och policy för en viss samverkan |
| Hanteras av | Anslutningsoperatör | Tillitsankartjänst (och tillitsmärkestjänster) via Anslutningsoperatör |
| Resultat | Komponentens metadata blir verifierbar och sökbar | Komponentens tillhörighet till ett visst federationskontext fastställs |
| Typ av tillit | Teknisk tillit (signerad metadata) | Organisatorisk och policybaserad tillit |
För att helheten ska fungera krävs att interoperabilitet bevaras både inom den tekniska federationsinfrastrukturen och mellan olika federationskontexter.
Gemensam teknisk grund
Alla tillitsankartjänster och anslutningsoperatörer använder samma tekniska federation – samma metadataformat, signeringsstandarder och mekanismer för tillitskedjor.
Det gör att metadata från olika federationskontexter kan läsas, verifieras och förstås på samma sätt, oavsett vilket tillitsankare som ligger till grund.Anslutningsoperatörer som bryggor
En anslutningsoperatör kan vara kopplad till flera tillitsankartjänster och därmed agera bro mellan kontexter.
Genom att publicera metadata i enlighet med gemensam profilering kan samma komponent (t.ex. en legitimeringstjänst) användas inom flera federationskontexter utan dubbelregistrering.Tillitsmärken som bärande princip för interoperabilitet
Eftersom tillitsmärken beskriver uppfyllda tillitsskapande krav på ett standardiserat sätt kan de erkännas över flera federationskontexter.
En aktör som redan är granskad och tilldelad ett tillitsmärke inom ett kontext behöver därför inte genomgå ny granskning för samma krav i ett annat kontext.Övergripande styrning genom ledningsaktören
Ledningsaktören ansvarar för att regelverket för infrastrukturen anger vilka tekniska specifikationer och gemensamma tillitsramar som måste följas för att en federationskontext ska kunna anslutas.
På så sätt kan olika tillitsankartjänster och federationskontexter samexistera – men alltid inom en gemensam och verifierbar teknisk ram.
Att ansluta till federationsinfrastrukturen ger teknisk synlighet och verifierbarhet, medan anslutning till ett federationskontext ger tillgång till en tillitsdomän med särskilda krav.
Genom den gemensamma tekniska infrastrukturen, standardiserade tillitsmärken och samordnade operatörstjänster bevaras interoperabiliteten mellan kontexter – vilket gör att aktörer kan samverka digitalt över organisations- och sektorsgränser utan att tilliten förloras eller måste byggas om.
Rekommendation för Enas federationsinfrastruktur
...
Modellen utgår från att flera tillitsankartjänster (Trust Anchors) kan samexistera och samverka inom en gemensam nationell styrningsram. Varje tillitsankartjänst ansvarar för ett eget federationskontext, där aktörerna kan välja vilka delar av de nationellt gemensamma tekniska specifikationerna, tillitsskapande krav och styrningsprinciper som ska tillämpas för att möta respektive behov. Interoperabiliteten mellan kontexterna säkerställs genom gemensamma anslutningstjänster, format och tillitsramar.
Alternativa modeller för Enas federationsinfrastruktur
Vid etableringen av den nationella federationsinfrastrukturen finns två vägval för hur den gemensamma infrastrukturen initialt kan konfigureras.
Alternativ 1 – Initialt ett gemensamt federationskontext
I denna modell etableras ett enda nationellt federationskontext som omfattar all digital samverkan – både nationell identitetshantering och behörighetshantering. Alla anslutningstjänster och tillitsmärkestjänster verkar inom samma övergripande tillitsstruktur och följer gemensamma policyer och styrning.
Fördelen med detta alternativ är enkelhet och tydlighet: en enhetlig policy, gemensam förvaltning och sammanhållen tillitsstruktur. Nackdelen är minskad flexibilitet när olika tillitsnivåer, tekniska protokoll eller särskilda krav behöver införas för olika typer av informationsutbyte.
Alternativ 2 – Initialt två federationskontexter: nationell identitet samt organisationsöverskridande identitet och behörighet
I detta alternativ etableras två separata men interoperabla federationskontexter under gemensam nationell styrning.
Det första federationskontextet omfattar svensk e-legitimering och identitetsintyg, med tillitsnivåer och regelverk enligt eIDAS och nationella krav.
Det andra omfattar organisationsöverskridande identitet- och behörighetshantering, med fokus på behörighetsintyg, attribut och tillitsmärken mellan organisationer.
De båda kontexterna delar teknisk infrastruktur, gemensamma format och verifieringsmekanismer men kan tillämpa olika tillitsmodeller och juridiska krav. Denna modell ger större flexibilitet och gör det möjligt att särskilt hantera sektorsövergripande samverkan utan att påverka befintlig e-legitimationsfederation.
Flera federationskontexter under gemensam styrning
Den svenska federationsinfrastrukturen bör därför omfatta minst två federationskontexter:
– Ett federationskontext för svensk e-legitimering med fokus på identitetsintyg, certifiering och säkerhetsnivåer enligt eIDAS och nationella krav.
– Ett federationskontext för behörighetshantering med fokus på förmedling av behörighetsintyg, attribut och tillitsmärken mellan organisationer.
De båda kontexterna utgår från olika tillitsstrukturer men verkar inom samma federationsinfrastruktur, delar gemensamma tjänster såsom anslutnings- och verifieringstjänster och följer samma övergripande regelverk.
Behovet av internationell samverkan är samtidigt centralt. Federationsinfrastrukturen ska kunna samverka med motsvarande lösningar i andra länder och utbyta tillitsinformation på ett standardiserat och verifierbart sätt. Det möjliggör gränsöverskridande användning av både svenska e-legitimationer och behörighetsintyg, samtidigt som nationell styrning och tillitsramverk bevaras.
Etablering av nya federationskontexter vid behov av särskild teknisk samverkan
Nya tillitsankartjänster kan införas när tekniska behov uppstår som inte kan eller bör lösas inom befintligt federationskontext, till exempel olika protokoll, tillitsnivåer, krypteringsmetoder eller integrationsmodeller. Ett exempel är ett federationskontext för behörighetshantering, där tillitsstrukturen och de tekniska mekanismerna skiljer sig från e-legitimering men där interoperabilitet mellan kontexterna fortfarande krävs.
Varje ny tillitsankartjänst fungerar då som en självständig Trust Anchor enligt OIDF-specifikationen men verkar inom Ena:s gemensamma styrningsram och följer gemensamma tillitsskapande principer.
IIMAR som modell för samordnad interoperabilitet
Den nationella federationsinfrastrukturen ska bygga på OIDF-modellen IIMAR (Interlinked Intermediates with Multi-Anchor Resolution). I denna modell kan flera oberoende Trust Anchors (tillitsankartjänster) samexistera utan hierarki, gemensamma Intermediates (anslutningstjänster) kan vara kopplade till flera tillitsankartjänster samtidigt, och aktörer kan verifiera metadata och tillit över flera federationskontexter.
Nationell samordning, tillitsstyrning och interoperabilitet
Ledningsaktören inom Ena ansvarar för att erkänna tillitsankartjänster (federationskontexter) som en del av den nationella infrastrukturen och säkerställa att de följer det gemensamt överenskomna regelverket och de tekniska principerna för federationsinfrastrukturen. Syftet är att alla federationskontexter ska kunna samverka både tekniskt och tillitsmässigt, med bibehållen rådighet för offentlig sektor även när flera tillitsankartjänster etableras.
Gemensamma metadataformat, kryptografiska standarder, tillitsramar och verifieringstjänster används för att undvika fragmentering och möjliggöra sömlös digital samverkan mellan sektorer och federationskontexter. På så sätt upprätthålls interoperabilitet, rättssäkerhet och förtroende i hela den nationella federationsinfrastrukturen.
Jämförelse av OIDF Arkitekturer/OIDF tillitsmodeller
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.
Arkitekturella drivkrafter bakom val av modell
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
...
Varför flera federationskontext (Tillitsankartjänster)
Att organisera en nationell federationsinfrastruktur kring flera federationskonstext 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 tillitsramverk. 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.
...
Inledning
OpenID Federation (OIDF) definierar en modell för hur tillit och interoperabilitet kan etableras mellan ett brett spektrum av olika organisationer på ett distribuerat och standardiserat sätt. OIDF-specifikationen kan dock tillämpas enligt flera olika arkitekturella mönster, med skilda nivåer av centralisering, ansvarsfördelning och flexibilitet.
För Enas federationsinfrastruktur innebär detta att det finns flera möjliga sätt att organisera relationer mellan federationsinfrastrukturtjänster och de aktörer som deltar i digital samverkan. Valet av modell påverkar hur tillit etableras, hur metadata valideras och hur nya federationskontexter kan uppstå över tid.
Syftet med detta fokusområde är att ge en översikt över dessa olika tillitsmodeller, analysera deras för- och nackdelar samt belysa hur de svarar mot de arkitekturella drivkrafter som identifierats för Ena. Genom att tydliggöra alternativen kan vi skapa en strategisk plan för hur OIDF-arkitekturen bör användas initialt – och hur vi successivt kan anpassa oss när nya behov, krav och samverkansformer uppstår.
Analys av olika tillitsmodeller baserade på OpenID Federation
Analysen fokuserar på hur modellerna skiljer sig i fråga om styrning, tillit och teknisk samverkan – och vilka konsekvenser dessa skillnader får för möjligheten att kombinera nationell samordning med lokal autonomi och gradvis utveckling över tid.
Tabellen nedan beskriver och analyserar de fyra huvudsakliga tillitsmodellerna i OpenID Federation ur ett mer tekniskt perspektiv.
Fokus ligger på hur tillit etableras, hur policyer tillämpas och hur interoperabilitet upprätthålls mellan federationskontexter.
Jämförelsen visar hur modellerna skiljer sig i fråga om styrningsnivå, komplexitet i nyckelhantering, valideringslogik och grad av teknisk flexibilitet.
Analysen tydliggör även vilka modeller som fullt ut stöds av OIDF-specifikationen och vilka som kräver kompletterande mekanismer, till exempel extern nyckeldistribution eller utökad governance.
Syftet är att ge en teknisk grund för val av modell inom Enas federationsinfrastruktur och förstå hur olika arkitekturella beslut påverkar robusthet, interoperabilitet och möjlighet till automatiserad verifiering över tid.
| 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 |
|
|
|
|
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
Tillitsmodeller kan utformas och tillämpas på olika sätt beroende på verksamhetens behov och risknivå. Även när samma grundläggande principer för ledning och kontroll används, exempelvis ISO 27000-serien med ledningssystem för informationssäkerhet, kan omfattningen av krav, uppföljning och efterlevnad skilja sig avsevärt. Vissa sammanhang kan kräva detaljerad styrning och kontinuerlig revision, medan andra främst betonar ömsesidigt ansvar och övergripande riktlinjer och avtal. Genom att möjliggöra flera tillitsmodeller kan samverkan anpassas till olika förutsättningar utan att helheten går förlorad.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 Samordnad identitet och behörighet
- Bra användarupplevelse
En absolut förutsättning för att en arkitektur för identitets- och behörighetshantering ska nå de effektmål som eftersträvas, måste användarupplevelsen vid inloggningar beaktas i relation till etablerade standarder för tillgänglighet, användbarhet och kognition. - Ö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
Enkel anslutning
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 |
|
|
|
Rekommendation för Ena federationsinfrastruktur
Utifrån jämförelsen av de olika modellerna (se kapitel 3) ser det ut som attIIMAR-modellen bäst kan stödja de behov som ligger bakom framtagandet av den nationella federationsinfrastrukturen. Modellen möjliggör en koordinerad struktur med flera federationskontexter under gemensam styrning och ger samtidigt flexibilitet för olika typer av samverkan.
Modellen utgår från att flera tillitsankartjänster (Trust Anchors) kan samexistera och samverka inom en gemensam nationell styrningsram. Varje tillitsankartjänst ansvarar för ett eget federationskontext, där aktörerna kan välja vilka delar av de nationellt gemensamma tekniska specifikationerna, tillitsskapande krav och styrningsprinciper som ska tillämpas för att möta respektive behov. Interoperabiliteten mellan kontexterna säkerställs genom gemensamma anslutningstjänster, format och tillitsramar.
Vid etableringen av den nationella federationsinfrastrukturen enligt IIMAR-modellen finns två vägval för hur den gemensamma infrastrukturen initialt kan konfigureras.
Alternativ 1 – Initialt ett gemensamt federationskontext
I denna modell etableras ett enda nationellt federationskontext som omfattar all digital samverkan – både nationell identitetshantering och behörighetshantering. Alla anslutningstjänster och tillitsmärkestjänster verkar inom samma övergripande tillitsstruktur och följer gemensamma policyer och styrning.
Fördelen med detta alternativ är enkelhet och tydlighet: en enhetlig policy, gemensam förvaltning och sammanhållen tillitsstruktur. Nackdelen är minskad flexibilitet när olika tillitsnivåer, tekniska protokoll eller särskilda krav behöver införas för olika typer av informationsutbyte.
Alternativ 2 – Initialt två federationskontexter: svensk e-legitimering samt organisationsöverskridande identitet och behörighet
I detta alternativ etableras två separata men interoperabla federationskontexter under gemensam nationell styrning.
Det första federationskontextet omfattar svensk e-legitimering och identitetsintyg, med tillitsnivåer och regelverk enligt eIDAS och nationella krav.
Det andra omfattar organisationsöverskridande identitet- och behörighetshantering, med fokus på behörighetsintyg, attribut och tillitsmärken mellan organisationer.
De båda kontexterna delar teknisk infrastruktur, gemensamma format och verifieringsmekanismer men kan tillämpa olika tillitsmodeller och juridiska krav. Denna modell ger större flexibilitet och gör det möjligt att särskilt hantera sektorsövergripande samverkan utan att påverka befintlig e-legitimationsfederation.
Rekommendation: Utifrån behovet av flexibilitet, återanvändning av befintliga lösningar och möjligheten att stödja både nationell och sektorsövergripande samverkan föreslås att federationsinfrastrukturen initialt etableras med två federationskontexter under gemensam nationell styrning.
– Ett federationskontext för svensk e-legitimering med fokus på identitetsintyg, certifiering och säkerhetsnivåer enligt eIDAS och nationella krav.
– Ett federationskontext för behörighetshantering med fokus på förmedling av behörighetsintyg, attribut och tillitsmärken mellan organisationer.
De båda kontexterna utgår från delvis olika tillitsstrukturer men verkar inom samma federationsinfrastruktur, delar gemensamma tjänster såsom anslutnings- och verifieringstjänster och följer samma övergripande regelverk.
Behovet av internationell samverkan är samtidigt centralt. Federationsinfrastrukturen ska kunna samverka med motsvarande lösningar i andra länder och utbyta tillitsinformation på ett standardiserat och verifierbart sätt. Det möjliggör gränsöverskridande användning av både svenska e-legitimationer och behörighetsintyg, samtidigt som nationell styrning och tillitsramverk bevaras.
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Anslutning till, styrning av och samverkan med hjälp av federationsinfrastrukturen
Ena federationsinfrastruktur är uppbyggd för att skilja mellan hur aktörer ansluter tekniskt till infrastrukturen och på vilka villkor de samverkar inom olika federations- och samverkanskontext. Själva federationsinfrastrukturen utgör den tekniska grunden som gör det möjligt för aktörer att ansluta sina komponenter, publicera metadata och bli verifierbara i ett gemensamt nätverk. Den beskriver vem som vill samverka och på vilket sätt aktörernas komponenter kan hittas, verifieras och användas.
Ledningsaktören inom Ena ansvarar för att erkänna tillitsankartjänster (federationskontexter) som en del av den nationella infrastrukturen och säkerställa att de följer det gemensamt överenskomna regelverket och de tekniska principerna för federationsinfrastrukturen. Syftet är att alla federationskontexter ska kunna samverka både tekniskt och tillitsmässigt, med bibehållen rådighet för offentlig sektor även när flera tillitsankartjänster etableras. Gemensamma metadataformat, kryptografiska standarder, tillitsramar och verifieringstjänster används för att undvika fragmentering och möjliggöra sömlös digital samverkan mellan sektorer och federationskontexter. På så sätt upprätthålls interoperabilitet, rättssäkerhet och förtroende i hela den nationella federationsinfrastrukturen.
Federationskontext utgör grunden där de tekniska villkoren för samverkan inom federationsinfrastrukturen definieras. Varje federationskontext utgår från vilka tekniska krav, tillitsnivåer och regelverk som gäller för deltagande aktörer – inte från vilken typ av verksamhetsmässig samverkan som sker. Det gör att flera olika typer av digital samverkan kan ske inom samma tekniska grund, men möjlighet till ytterligare tillitsskapande strukturer. Ett federationskontext kan detaljeras ytterligare genom införandet av ett eller flera samverkanskontexter. Samverkanskontexter beskriver mer specifika verksamhetsmässiga ramar för informationsutbyte mellan aktörer, till exempel inom ett visst område eller en särskild tillämpning. På så sätt kan federationsinfrastrukturen stödja både övergripande styrning av till och finmaskig anpassning för olika typer av digital samverkan
När en organisation blir federationsmedlem ansluter den sig till den gemensamma federationsinfrastrukturen via en Anslutningsoperatör.
Detta innebär att organisationens tekniska komponenter (t.ex. legitimeringstjänster, auktorisationstjänster, API:er eller e-tjänster) registreras och publiceras i infrastrukturen på ett standardiserat sätt med signerad metadata och tillhörande tillitsinformation.
Syftet med denna anslutning är att:
ge komponenterna en teknisk identitet inom infrastrukturen,
säkerställa att deras metadata kan hittas, verifieras och användas av andra aktörer, inom ett federationskontext och
skapa grundläggande teknisk tillit till komponenten så att den kan anslutas till ett federationskontext.
Anslutningen till infrastrukturen är alltså teknisk och strukturell – den placerar aktören i nätverket men säger ännu inget om vilken typ av samverkan eller vilka tillitskrav som gäller.
Ett federationskontext avgränsas av en specifik tillitsankartjänst. Tillitsankartjänsten definierar de tekniska villkoren för hur tillit etableras, till exempel vilka tillitsmärken som kan användas.
För att en ansluten aktör ska kunna delta i digital samverkan inom ett visst kontext krävs att:
den operatör aktören är ansluten till är kopplad till federationskontextens Tillitsankartjänst,
aktören uppfyller de tillitsskapande krav som gäller för kontexten (t.ex. via tillitsmärken),
tillitskedjan för komponenten kan valideras upp till den Tillitsankartjänsten som gäller för kontextet.
På så sätt kan samma tekniska anslutning till infrastrukturen användas i flera federationskontexter – men tilliten och teknisk följsamhet verifieras utifrån ett specifikt kontext.
Anslutningsoperatören utgör länken mellan den tekniska federationsinfrastrukturen och de olika federationskontexten.
Operatören:
ansluter sina medlemmars komponenter till infrastrukturen,
validerar komponenternas metadata när det skapas eller uppdateras,
ansluter ansluter sin egen anslutningstjänst till ett eller flera federationskontexter
för att möjliggöra sina kunder att etablera samverkan med aktörer inom olika federationskontexter
| Aspekt | Anslutning till federationsinfrastrukturen | Anslutning till federationskontext | Anslutning till samverkanskontext |
|---|---|---|---|
| Syfte | Tekniskt tillträde till infrastrukturen | Tekniska villkor och policy för en viss samverkan | policy för en viss samverkan |
| Hanteras av | Anslutningsoperatör | Federationsoperatör via Anslutningsoperatör & Tillitsoperatörer | Tillitsoperatörer |
| Resultat | Komponentens metadata blir verifierad | Komponentens metadata görs verifierbar inom ett federationskontext | Komponentens tilldelas tillitsmärken |
| Typ av tillit | Teknisk tillit (signerad metadata) | Teknisk tillit (signerad metadata) | Teknisk tillit (signerad metadata) |
För att helheten ska fungera krävs att interoperabilitet bevaras både inom den tekniska federationsinfrastrukturen och mellan olika federationskontexter.
Gemensam teknisk grund
Alla Federationsoperatörer och Anslutningsoperatörer använder samma tekniska federationsinfrastruktur – samma metadataformat, signeringsstandarder och mekanismer för tillitskedjor.
Det gör att metadata från olika federationskontexter kan läsas, verifieras och förstås på samma sätt, oavsett vilket tillitsankare som ligger till grund.Anslutningsoperatörer som bryggor
En anslutningsoperatör kan vara kopplad till flera tillitsankartjänster och därmed agera bro mellan kontexter.
Genom att publicera metadata i enlighet med gemensam profilering kan samma komponent (t.ex. en legitimeringstjänst) användas inom flera federationskontexter utan dubbelregistrering.Tillitsmärken som bärande princip för interoperabilitet
Eftersom tillitsmärken beskriver uppfyllda tillitsskapande krav på ett standardiserat sätt kan de erkännas inom och över flera federationskontexter.
En aktör som redan är granskad och tilldelad ett tillitsmärke inom ett kontext behöver därför inte genomgå ny granskning för samma krav i ett annat kontext.Övergripande styrning genom ledningsaktören
Ledningsaktören ansvarar för att regelverket för infrastrukturen anger vilka tekniska specifikationer och gemensamma tillitsramar som måste följas för att en federationskontext ska kunna anslutas.
På så sätt kan olika tillitsankartjänster och federationskontexter samexistera – men alltid inom ett gemensamt tekniskt ramverk.
Att ansluta till federationsinfrastrukturen ger verifierad teknisk metadata, medan anslutning till ett federationskontext gör metadata verifierbar enligt kontextets krav.
Genom den gemensamma tekniska infrastrukturen, standardiserade tillitsmärken och samordnade operatörstjänster bevaras interoperabiliteten mellan kontexter – vilket gör att aktörer kan samverka digitalt över organisations- och sektorsgränser utan att tilliten förloras eller måste byggas om.
Styrning och policyhantering - tre nivåer
För att offentlig sektor ska kunna ha rådighet över den federativa infrastrukturen behöver vi gemensamt ta ställning till vilken nivå av ansvar som bör ligga hos myndigheter. Är det rimligt att just federationskontext förvaltas av myndigheter eftersom de kräver stabilitet och legitimitet i offentlig förvaltning?
En möjlig modell är att myndigheter även ansvarar för den första nivån av underordnade anslutningstjänster. Det skulle skapa en gemensam bas där aktörer kan ansluta sig under tydliga ramar, medan andra anslutningstjänster längre ut i hierarkin kan utvecklas av olika aktörer. På så sätt kan offentlig rådighet kombineras med flexibilitet och innovationskraft.
Samtidigt är det viktigt att komma ihåg att den ledningsaktör som ansvarar för infrastrukturen ändå kan styra genom att avgöra vilka federationskontext som accepteras och får anslutas till federationsinfrastrukturen. Även om flera aktörer driver olika federationskontext kan rådighet därför upprätthållas genom de överordnade regler och policies som styr helheten.
Frågan vi behöver diskutera är alltså: var bör gränsdragningen gå mellan offentlig styrning och mångfalden av andra aktörer, för att både tillit, robusthet och utvecklingsmöjligheter ska kunna säkerställas över tid?
Styrning och ledning av federationsinfrastrukturen
Denna styrning handlar om övergripande reglering av hela infrastrukturen. Ledningsaktören sätter de ramar och krav som alla federationskontext måste följa för att vara en del av den nationella federationsinfrastrukturen.
Syftet är att säkerställa styrning, neutralitet och enhetlighet i hur federationsinfrastrukturen används för att skapa interoperabilitet mellan federationskontext.
Omfattar t.ex.:
Grundläggande säkerhetskrav och tillitsskapande principer
Gemensamma tekniska specifikationer och val av protokoll (t.ex. att OIDF används, och vilka protokoll som kan användas, OIDC, OAuth, SAML)
Regler för hur federationskontext får etableras och anslutas
Krav på incidentrapportering och förändringshantering
Övergripande ramverk för hur tillit kan etableras, ansvarsfördelning regleras, samt hur avtal bör utformas
Styrning och ledning av federationskontext
Syftet är att säkerställa att aktörerna inom kontextet följer både de gemensamma nationella ramarna och de specifika krav som gäller för det aktuella federationskontextet.
Varje federationskontext behöver regleras av en policy som innehåller följande:
- Vilken metadata ska publiceras och valideras
- Vilka protokoll (tex, OIDC, OAuth, SAML)
Vilka tillitsmärken som accepteras inom kontextet.
- Eventuella utökningar av nationella regelverk
Det är federationskontextens federationsoperatör som ansvarar för att ta fram policyn, men den behöver förhålla sig till de ramar som stipuleras av federationsinfrastrukturens ledningsaktör.
Samverkanskontext
Ett samverkanskontext beskriver hur aktörer samordnar sin digitala samverkan inom ett visst verksamhetsområde eller för ett särskilt ändamål. Till skillnad från ett federationskontext, som definierar den tillitsmässiga och tekniska ramen, fokuserar samverkanskontextet på hur tillämpningen av gemensamma regler och tillitsprinciper sker i praktiken mellan de aktörer som deltar.
Syftet är att möjliggöra enhetlig och effektiv samverkan mellan parter som delar ett gemensamt behov av informationsutbyte, utan att skapa nya styrningsnivåer eller separata tekniska lösningar. Samverkanskontextet fungerar ovanpå den tekniska federationsinfrastrukturen och inom ramen för ett eller flera federationskontexter.
Inom ett samverkanskontext kan aktörer:
tillämpa gemensamma tolkningar av tillitsskapande krav, säkerhetsnivåer och tillitsmärken,
beskriva vilka typer av informationsutbyte, intyg och attribut som används,
specificera eventuella kompletterande regler eller processer som behövs för samverkan inom det aktuella området.
Ett samverkanskontext etableras vanligen av en samordnande part, exempelvis en sektorsmyndighet eller annan samverkansoperatör. Det kan omfatta flera federationskontexter och därmed tillåta samverkan mellan aktörer som verkar under olika federationskontext.
| Perspektiv | Styrning av federationsinfrastrukturen | Policyhantering av Federationskontext | Överenskommelser inom samverkanskontext |
|---|---|---|---|
| Nivå | Nationell, övergripande | Federationskontext, operativ användning av infrastrukturen | operativt informationsutbyte |
| Ansvarig | Ledningsaktör | Federationsoperatör | Federationsmedlemmar |
| Fokus | Ramar, standarder, roller, tillsyn | Teknisk interoperablitet, validering, metadata och tillitsmärken | Semantisk interoperabilitet |
| Syfte | Gemensam styrning och samordning | Säkerställa efterlevnad av gemensamma regler inom ett Federationskontext | tillämpa gemensamma tolkningar av tillitsskapande krav, säkerhetsnivåer och tillitsmärken, |
| Typ av krav | Strategiska och juridiska | Tekniska och operativa | Verksamhetsmässiga |
Slutsatser (tas bort!?)
2.3.1Etablering av nya federationskontexter vid behov av särskild teknisk samverkan
Nya tillitsankartjänster kan införas när tekniska behov uppstår som inte kan eller bör lösas inom befintligt federationskontext, till exempel olika protokoll, tillitsnivåer, krypteringsmetoder eller integrationsmodeller. Ett exempel är ett federationskontext för behörighetshantering, där tillitsstrukturen och de tekniska mekanismerna skiljer sig från e-legitimering men där interoperabilitet mellan kontexterna fortfarande krävs.
Varje ny tillitsankartjänst fungerar då som en självständig Trust Anchor enligt OIDF-specifikationen men verkar inom Ena:s gemensamma styrningsram och följer gemensamma tillitsskapande principer.
Dokumentet beskriver fyra arkitektoniska modeller för hur en nationell OpenID Federation kan byggas upp och hur tillit fördelas mellan Trust Anchors, Intermediates och deltagande aktörer. Varje modell har olika styrkor och svagheter när det gäller centralisering, autonomi, interoperabilitet och enkelhet i validering.
Beskrivning och utvärdering "OIDF Trust models"
| Info | ||
|---|---|---|
| ||
Mer information, inklusive detaljerade exempel och jämförelser, finns i projektets GitHub-repo: https://github.com/s-hal/oidf-architecture/blob/main/oidf-trust-models.md |
...
...
...
...
...
Inom Ena
...
Beskrivning: En nationell Tillitsankartjänst som är rot. Befintliga federationer är Anslutningstjänster.
Pros:
Centraliserad styrning → enhetlig policy och tydlig ansvarsfördelning.
Tillitskedjor blir enkla, deterministiska och alltid förankrade i samma Tillitsankartjänst → enkel validering.
Cons:
All onboarding och tillitsmärkeshantering måste gå via den nationella Tillitsankartjänsten → ökad administration.
Begränsad flexibilitet för federationer (Fed A, Fed B) att göra egna anpassningar.
Risk för flaskhalsar och tung styrning
...
Beskrivning: Varje federation har en egen Trust Anchor, men dessa pekar uppåt mot en nationell Trust Anchor.
Pros:
Varje federation har egen kontroll över sin Tillitsankartjänst och sina nycklar.
Möjliggör anpassning till lokala/regionala krav samtidigt som nationella regler följs.
Stödjer integration av självständiga federationer.
Cross-federation validering blir enklare (alla slutar i samma nationella TA).
Cons:
Vid validering måste entiteter kunna hantera flera Tillitsankartjänster
Lokal
Nationell
Risk för olika valideringsresultat beroende på om man startar i lokal eller nationell Tillitsankartjänst.
Kräver tydlig samordning så att policys inte krockar
...
Beskrivning: Varje federation har en helt fristående Trust Anchor. Nycklar publiceras via en extern Trusted Bridging Entity (TBE). Ingen hierarki.
Pros:
Full autonomi för varje federation.
Möjlighet till selektiv interoperabilitet utan gemensam rot.
Flexibel, olika federationer kan utvecklas självständigt.
Cons:
TBE ligger utanför OpenID Federation-specifikationen → kräver separat styrning och standardisering.
Risk för fragmentering om inte stark governance upprättas.
Ingen automatisk tillitskedja → validerare måste hantera flera nyckeluppsättningar parallellt.
Större administrativ börda vid onboarding och nyckelhantering
...
Beskrivning: Flera oberoende Trust Anchor länkas ihop genom gemensamma shared Intermediates).
Pros:
Möjliggör interoperabilitet för underordnade utan att Trust Anchors behöver underordna sig varandra.
Flexibel anslutning – samma Anslutningstjänst kan knytas till flera Tillitsankartjänster.
Stödjer gradvis integration mellan federationer.
Entiteter kan delta i flera federationer via samma Intermediate.
Cons:
Komplexitet ökar när fler Trust Anchors ansluts.
Intermediates måste hantera flera överordnade.
- Risk för policyfragmentering mellan Trust Anchors
- Entiteter och Uppslags-/verifieringstjänster måste kunna hantera flera Trust Anchors, vilket ökar krav på implementation,
...
OIDF stöd
...
Fullt stöd enligt OIDF specifikation
...
Ej fullt stöds enligt OIDF specifikationen
...
Stöds ej enligt specifikationen
...
Fullt stöd enligt OIDF specifikation
...
OIDF Policyhantering
...
All policy definieras i den nationella Trust Anchor och slår igenom top-down.
Policys blir enhetliga och entydiga, vilket gör validering enkelt och konsekvent.
Begränsad möjlighet för underordnade federationer att lägga till egna krav – det riskerar att krocka med den centrala styrningen
...
Policy definieras både i den nationella Trust Anchor och i lokala federationers Tillitsankartjänster.
Om validering görs mot en lokal TA → lokala regler gäller. Om validering görs via den nationella TA → både nationella och lokala regler slår igenom.
Risk för inkonsekvent policy tillämpning beroende på vilken väg en verifiering går.
...
Ingen gemensam policykedja i federationens metadata.
Varje Tillitsankartjänst definierar sin egen policy helt självständigt.
För att möjliggöra interoperabilitet måste TBE (Trusted Bridging Entity) eller motsvarande governance-funktion definiera gemensamma minimikrav för att få vara med.
All faktisk policytillämpning blir lokalt scope:ad till respektive TA.
...
Varje Trust Anchor behåller sin egen policy och publicerar den separat.
Indermediates som är delade måste hantera och förena policyer från flera olika Trust Anchors.
Vid validering måste en Trust Anchor väljas → policyn som tillämpas beror på vilken Trust Anchor som är slutpunkt.
Risk för divergens: samma Intermediate kan ge olika valideringsresultat beroende på vilken kedja som följs.
OIDF arktitekturer 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.
...
Konsekvenser för
Federationsoperatör
...
- Ö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.
...
- 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
...
Konsekvenser för federationsmedlemmar
Sammanställning plus och minus (Inera)
Följande lista ÄR ETT FÖRSTA UTKAST PÅ EN SAMMANSTÄLLNING av plus och minus för de olika modellerna. Den är baserad på tolkningar OCH BRISTANDE FÖRSTÅELSE av de olika modellerna. Dessutom finns det stor risk att slutsatserna i listan påverkas av vägval inom respektive modell. Dock tror vi att informationen om modellerna behöver kokas ner till slutsatser på denna nivå och att det är enklare med denna typ av plus/minus lista än pros/cons i tabellen ovan.
ATT-GÖRA 1: ensa de olika slutsatserna om respektive modell så att överlappande slutsatser rensas bort.
ATT-GÖRA 2: balansera upp plus och minus. Just nu är det nästan bara plus på NTA…
ATT-GÖRA 3: kvalitetsgranska slutsatserna!!!
...
Plus: Enkelt, fint och tydligt.
- Enklast att genomföra tekniskt, både att bygga upp och att nyttja då valideringen är enklare än alternativen.
- Att spåra eventuella incidenter blir också enklare i denna modell.
- Enklare att förklara.
- Att lista alla tillitsmärkesutdelare på ett ställe gör det enklare att hitta dem.
- Det kommer att bli lättare att hålla ihop policies.
Lokala tillitsmärken stöds, dvs federad hantering, medan samverkan mellan federativa kontext endast kan basera sig på nationellt godkända märken.
Digg kan lägga ut federationstillitsankare på sektorsmyndigheter utan att det försvårar interoperabilitet över sektorsgränser.
Lyckas vi skapa bra gemensamma tillitsmärken bör inte behovet av specifika tillitsmärken i respektive sub-tillitsankare bli lika stort.
...
- Den stora fördelen med denna modell är en högre graden av flexibilitet.
- Kan snabbare och enklare möta områdets eventuella specifika behov.
...
- Underlättar incidenthanteringen
- Ökar robustheten
...
- [Skolfederation, Sambi och andra befintliga federationer kan vid behov bli en federation i nya infrastrukturen utan större förändringar. Internt behöver man inte förändra så mycket och EFI gör att anslutna parter får identitets och behörighetshantering med andra verksamhetsområden. Inera skulle (om vi kommer fram till att det är en bra ide) kunna skapa ett tillitsankare för Inera och tillitsmärke för HSA-bas samt HSA-extra (andra gruppen är de som uppfyller fem bör-kraven i HSA Tillitsramverk 5.0 som krävs av EHM). Får enklare övergång till framtida gemensamma tillitsmärken. EHM skulle initialt kunna acceptera både tillitsmärke Sambi och HSA-extra men kan på sikt gå över till ett (eller flera) gemensamma tillitsmärken.]
...
- Stor flexibilitet
- Ökad robusthet då enskilt federativt kontext kan fungera autonomt.
...
- Förmodligen mest flexibel(?) - men eftersom vi inte fullt ut klarar bedöma vad modellen innebär så vet vi inte.
...
Minus
...
- Brist på flexibilitet kan leda till att infrastrukturen inte svarar upp mot behoven efter en tid.
- Centralstyrningen ger mindre utrymme för egna varianter, vilket kommer att uppfattas som negativt.
- Mer arbete för ledningsaktören.
- Problematiskt att centralisera hantering av samverkanskontext. Risk för att mindre samverkanskontexter får hanteras utan tillitsmärken. Kan bli ohållbart.
- Om man vill representera avtal eller medlemskap i ett specifikt samverkanskontext behöver ansvarig samordnare för varje samverkanskontext använda en trust mark issuer som är registrerad/godkänd av tillitsankare
...
- Mer komplex validering än HTA.
- Risk för fragmentering om nationella och lokala policies inte koordineras.
- Valideringsutfall kan skilja sig mellan lokal och nationell TA
- Högre krav på samordning för att undvika konflikter.
...
- Minimal harmonisering mellan federativa kontext – interfederation.
- Riskerar cementera fast fragmentering och motverka harmonisering. Skulle i så fall inte öka samhällets framtida digitaliseringstakt.
- Så stor risk att alternativet kan utgå.
...
- Upplevs som krånglig. Torde bli svår att förklara.
- Kanske mindre risk för fragmentering än DTA men tror fortfarande att skillnader mellan olika kontext riskerar cementeras fast, och att målet om harmonisering missas.
Ena-exempel - OIDF arkitekturer
Ena IIMAR
| Info | ||
|---|---|---|
| ||
Påbörjat utkast på hur IIMAR-strukturen skulle kunna se ut i Ena |
draw.io Diagram
