| Table of Contents |
|---|
...
Inledning
OpenID Federation (OIDF) tillhandahåller en arkitektur för hur tillit och interoperabilitet kan etableras mellan 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 relationen mellan tillitsankartjänster, anslutningstjä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
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.
...
| 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 |
| 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 specifikation | Ej fullt stöds enligt OIDF specifikationen | Stöds ej enligt specifikationen | Fullt stöd enligt OIDF specifikation |
OIDF Policyhantering |
|
|
|
|
Analys av olika OpenID Federation tillitsmodeller inom Ena
...
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 |
|
|
|
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.
...
Att organisera en nationell federationsinfrastruktur kring flera federationskonstext federationskontext och därmed Tillitsankartjänster (Trust Anchor enligt OIDF specifikationen) skapar flexibilitet och möjlighet till anpassning för de olika behov som finns i samverkan.
Olika tillitsmodeller och styrning
All samverkan behöver inte bygga på samma tillitsramverkmodell för tillit. Vissa sammanhang kräver styrning enligt ISO 27000 med ledningssystem för informationssäkerhet, medan andra skulle kunna bygga på helt andra regelverk eller kravbilder. Genom att tillåta flera Tillitsankartjänster kan man tillämpa olika tillitsmodeller parallellt, men ändå hålla ihop tekniskt via en gemensam federationsinfrastruktur.Olika tekniska protokoll och standarder
All samverkan behöver inte ske med OIDC eller OAuth. Det finns etablerade miljöer som bygger på SAML, eller andra standarder. Om all metadata blandas i en och samma federationskontext riskerar infrastrukturen att bli svårhanterlig. Med flera Tillitsankartjänster kan man istället skapa tydliga avgränsningar där varje Tillitsankartjänst ansvarar för sitt tekniska område och sina policyer.Avgränsade samverkanskontexter
All samverkan sker inte mellan alla tjänster. I praktiken är det vanligt att grupper av tjänster främst utbyter information med varandra utifrån gemensamma behov och krav. För vissa typer av tjänster, som exempelvis intygstjänster, är det däremot vanligt att de används i flera olika samverkanskontexter eftersom de tillför generella förmågor som många behöver. Andra komponenter, somAPI:er eller klienter, är oftare knutna till ett mer specifikt behov av samverkan. Genom att införa flera Tillitsankartjänster kan man hantera denna variation: intygstjänster kan återanvändas brett, medan mer specialiserade komponenter kan styras inom en snävare kontext.
...
.
...
Arkitekturella drivkrafter
...
Vid etableringen av den nationella federationsinfrastrukturen enligt IIMAR-modellen finns två vägval för hur den gemensamma infrastrukturen initialt kan konfigureras.
...
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.
...
| 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
...
