Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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?

...

Motsvarar alltså den "yttre styrningen" – den nationella ramen.

...

Policy för ett federationskontext (Federationsoperatörernas ansvar)

Denna policy gäller inom ett specifikt federationskontext.

...

PerspektivStyrning av federationsinfrastrukturenOIDF-policy (Federationsområdesansvarig)
NivåNationell, övergripandeFederationskontext, operativ
AnsvarigLedningsaktörFederationsoperatör
SyfteGemensam styrning och samordningSäkerställa efterlevnad av gemensamma regler inom ett Federationskontext
FokusRamar, standarder, roller, tillsynImplementering, validering, metadata och tillitsmärken
Typ av kravStrategiska och juridiskaTekniska 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 tillitsdomäner. 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.

AspektAnslutning till federationsinfrastrukturenAnslutning till federationskontext
SyfteTekniskt tillträde till infrastrukturenTillit och policy för en viss samverkan
Hanteras avAnslutningsoperatörTillitsankartjänst (och tillitsmärkestjänster) via Anslutningsoperatör
ResultatKomponentens metadata blir verifierbar och sökbarKomponentens tillhörighet till ett visst federationskontext fastställs
Typ av tillitTeknisk 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.

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

  2. Delade operatörer och gemensamma verktyg
    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.

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

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

OIDF

...

Arkitekturer

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.

...

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


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

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

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

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

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

...

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

...

ModellHTANTADTA med TBEIIMAR
LänkHTANTADTAIIMAR
Skiss

Kort beskrivningCentraliserad 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.
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 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 kan 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.

...


HTANTADTA m. TBEIIMAR
Plus

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.

  • Fortfarande förhållandevis enkel modell men med ökad flexibilitet jämfört med HTA.
    • 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.
  •  I vissa användningsfall kan tilliten lösas i den lokala federationen utan inblandning på central nivå:
    • Underlättar incidenthanteringen
    • Ökar robustheten
  •  Ökad robusthet då enskilt federativt kontext kan fungera autonomt.
  •  Löser problemet med samverkan mellan aktörer i olika verksamhetsområde. [Exempel: Migrationsverket, AF, FK, SKV, CSN, Transportstyrelsen, A-kassorna och Pensionsmyndigheten kan använda de gemensamma nationella tillitsmärkena för GIF och ha interoperabilitet över flera verksamhetsområden].
  • Jämnare fördelning av arbetsbördan för att underhålla federationen, fler organisationer kan bidra.
    • Digg torde få minst administration i denna modell.
  •  Om vi väljer att kapsla in befintliga federationer som sub-tillitsankare i NTA får vi en tydligare modell för hur vi kan ta tillvara på tidigare investeringar i federationer.
    • [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

OIDF Trust Anchor Policy 

Nationell Policy

Lokal Policy

...

Ena NTA



Info
titleUtkast!

Påbörjat utkast på hur NTA-strukturen skulle kunna se ut i Ena

...

draw.io Diagram
borderfalse
diagramNameEna-HTA2
simpleViewerfalse
width
linksauto
tbstyleinline
lboxtrue
diagramWidth681
height631
revision6
draw.io Diagram
borderfalse
diagramNameEna-NTA-IdentAukt
simpleViewerfalse
width
linksauto
tbstyleinline
lboxtrue
diagramWidth641
height391
revision1

Ena IIMAR

Info
titleUtkast!

Påbörjat utkast på hur IIMAR-strukturen skulle kunna se ut i Ena

...