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, reglering av federationsinfrastrukturen
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.
Användning av federationsinfrastrukturen (Federationsoperatörer)
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 |
OIDF Arkitektur
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
- Ö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.
Varför flera federationskontext aka 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.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, som API: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.
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"
Mer information
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
| 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. | Varje federation har en egen Trust Anchor som pekar på den nationella Trust Anchorn. Balans mellan lokal autonomi och nationell styrning, med möjlighet till både lokal och central validering. | Decentraliserad modell där varje federation driver en oberoende Trust Anchor. En Trusted Bridging Entity (TBE) distribuerar nycklar utanför OIDF-specen. Ger hög autonomi men kräver separat governance och samordning. | Flera oberoende Trust Anchors kan dela Intermediates, vilket möjliggör interoperabilitet utan nyckeldistribution mellan Trust Anchors. Mycket flexibel men med ökad komplexitet och risk för fragmenterad policy. |
Inom Ena | Beskrivning: En nationell Tillitsankartjänst som är rot. Befintliga federationer är Anslutningstjänster.
Cons:
| Beskrivning: Varje federation har en egen Trust Anchor, men dessa pekar uppåt mot en nationell Trust Anchor.
Cons:
| Beskrivning: Varje federation har en helt fristående Trust Anchor. Nycklar publiceras via en extern Trusted Bridging Entity (TBE). Ingen hierarki.
Cons:
| Beskrivning: Flera oberoende Trust Anchor länkas ihop genom gemensamma shared Intermediates).
Cons:
|
OIDF Policyhantering |
|
|
|
|
OIDF arktitektur 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 |
|
|
| |
Konsekvenser för nationell federationsoperatör |
| N/A | ||
Konsekvenser för Federationsoperatör |
|
| ||
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!!!
| HTA | NTA | DTA m. TBE | IIMAR | |
|---|---|---|---|---|
| Plus | Plus: Enkelt, fint och tydligt.
| 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.
|
|
|
Minus |
|
|
|
|
Ena NTA
OIDF Trust Anchor Policy
Nationell Policy
Lokal Policy
Ena Governance
Utkast!
Påbörjat utkast på hur NTA-strukturen skulle kunna se ut i Ena
Ena IIMAR
Utkast!
Påbörjat utkast på hur IIMAR-strukturen skulle kunna se ut i Ena
