Tänk “lager” från mest övergripande (policy) till mest specifikt (tekniska profiler):
Anslutningspolicy (SIB-nivå, organisations-/styrningslager)
Normerar: vem som får ansluta, på vilka villkor, och hur anslutning godkänns.
Innehåller inte: tekniska detaljer per protokoll.
Tekniska anslutningsregler per federationskontext (teknikneutral federationsnivå)
Normerar: vad som gäller, vilka gemensamma tekniska krav som gäller i federationskontexten, men uttryckt teknikneutralt (t.ex. “stark autentisering”, “spårbarhet”, “nyckelhantering”, “metadata-kvalitet”).
Innehåller inte: exakta SAML/OIDC-fält eller profilparametrar.
Registreringspolicy (teknikspecifik processnivå)
Normerar: hur en aktör registrerar en teknisk komponent (IdP, OP, SP, RP, API-gateway, attributkälla etc.), vilken evidens som krävs, test/validering, driftsättning, ändringshantering.
Innehåller: teknikberoende krav och flöden (eftersom registreringen skiljer sig mellan SAML och OIDC).
Tekniskt ramverk (teknikspecifik normnivå: standarder + profiler)
Normerar: exakta standarder, profiler, options, “MUST/SHOULD/MAY”, interoperabilitet, samt referens till testprofiler.
Beroende: både teknik och federationskontext
Nedan är operativa tumregler för att avgöra var ett krav eller en regel hör hemma i din artefakt-arkitektur. De är formulerade som beslutskriterier och gränsdragningar för att minimera överlapp och normkonflikter.
När du formulerar ett krav – avgör först om det normerar:
Rätt att delta → Anslutningspolicy
Egenskaper i federationen → Tekniska anslutningsregler
Process för att få in en komponent → Registreringspolicy
Exakt teknisk implementation → Tekniskt ramverk
Det är alltid objektet för normeringen som styr placeringen.
Kravet gäller organisationen som aktör
Kravet kan uppfyllas utan att du vet vilken teknik som används
Kravet är kopplat till avtal, ansvar eller sanktion
Kravet är av typen “måste ha förmåga att…”
“Aktören ska…”
“Anslutning får ske om…”
“Aktören ansvarar för…”
“Vid bristande efterlevnad kan…”
Krav på algoritmer, claims, attributformat
Testfall
Konfigurationsdetaljer
Metadatafält
Om du kan byta ut “SAML/OIDC” mot “valfri teknik” utan att texten påverkas → då hör det hit.
Kravet beskriver vilken egenskap federationen måste ha
Kravet gäller alla tekniker i federationskontexten
Kravet uttrycks som säkerhets- eller interoperabilitetsnivå
Du kan formulera det utan att nämna ett protokoll
“Autentisering ska uppnå minst nivå X.”
“Kryptografiskt skydd ska säkerställa…”
“Metadata ska vara korrekt och aktuell.”
“Spårbarhet ska möjliggöra…”
“ID Token ska innehålla…”
“Assertion ska signeras med…”
Endpoint-URL-format
Claim-namn
Om du behöver nämna ett specifikt protokollelement → då är du på väg ner i ramverket.
Kravet beskriver hur en komponent tas in i federationen
Det rör ansökningsförfarande, verifiering, test, godkännande
Det är kopplat till förändringshantering
Det är kopplat till evidenskrav
“För registrering ska följande lämnas in…”
“Före produktionssättning ska…”
“Vid ändring av nyckelmaterial ska…”
Generella säkerhetsprinciper
Federationsövergripande krav
Protokollspecifika MUST/SHOULD-detaljer (de hör hemma i ramverket)
Om kravet upphör att vara relevant efter att komponenten är godkänd → då hör det sannolikt hit.
Kravet är testbart på protokollnivå
Du använder MUST/SHOULD/MAY
Du refererar till RFC/OASIS-specifikationer
Det påverkar interoperabilitet direkt
“ID Token MUST be signed using…”
“Assertion SHALL contain…”
“Clients MUST support…”
“Metadata SHALL include…”
Avtalsvillkor
Sanktioner
Organisationskrav
Allmänna säkerhetsprinciper utan teknisk konkretisering
Gäller kravet organisationens rätt eller ansvar att delta?
→ Anslutningspolicy
Gäller det vilken säkerhets-/interoperabilitetsegenskap federationen ska ha?
→ Tekniska anslutningsregler
Gäller det hur en komponent tas in, testas eller ändras?
→ Registreringspolicy
Gäller det exakt hur protokollet ska implementeras?
→ Tekniskt ramverk
Policy säger att
Regler säger vad
Registrering säger hur processen går till
Ramverk säger exakt hur tekniken ska bete sig
Om ett dokument börjar svara på en fråga som hör hemma i ett annat lager → du är på väg att skapa normkonflikt.
Om två dokument verkar säga olika saker:
Tekniskt ramverk konkretiserar – det får inte motsäga högre nivå.
Registreringspolicy får inte skapa nya materiella krav som saknar stöd i regler eller ramverk.
Tekniska anslutningsregler får inte smyga in avtalskrav.
Anslutningspolicy får inte smyga in tekniska implementationer.
| Exempel | Var hör det hemma? | Varför? |
|---|---|---|
| “Aktören ska ha incidenthanteringsförmåga” | Anslutningspolicy | Organisationskrav |
| “Incidenter ska rapporteras inom 24h” | Tekniska anslutningsregler | Federationskrav på samverkan |
| “Byte av signeringscertifikat kräver ny registrering” | Registreringspolicy | Processregel |
| “SAML Assertions MUST be signed with RSA-3072” | Tekniskt ramverk | Protokollkrav |
Detta är ofta den tydligaste distinktionen:
| Dokument | Primär målgrupp |
|---|---|
| Anslutningspolicy | Juridik, ledning, styrning |
| Tekniska anslutningsregler | Säkerhetsarkitekter, federationsansvariga |
| Registreringspolicy | Onboarding-/driftansvariga |
| Tekniskt ramverk | Utvecklare och produktleverantörer |
Om fel målgrupp måste läsa dokumentet för att förstå det – då är något felplacerat.
Detta dokument beskriver hur SIB:s dokumentpaket hänger ihop och var olika typer av krav ska uttryckas. Målet är att undvika dubbelreglering och göra det tydligt vad som styr styrning, krav, process och tekniska detaljer.
Anslutningspolicy – Anslutningsoperatör
Reglerar relationen mellan Federationsoperatör och Anslutningsoperatör: vem som får bli operatör, vilka ansvar som följer, hur uppföljning sker och hur avstängning/återkallelse hanteras.
Anslutningspolicy – Federationsmedlem
Reglerar relationen mellan Anslutningsoperatör och Federationsmedlem: medlemskriterier, åtaganden, efterlevnad, sanktioner och avstängning/återkallelse på medlemsnivå.
Princip: Policys beskriver “vem och varför”, ansvar samt konsekvens vid bristande efterlevnad.
Tekniska anslutningsregler – SIB Federation
Fastställer gemensamma minimikrav som måste vara uppfyllda för att federationen ska fungera säkert och interoperabelt. Innehåller krav som går att kontrollera, och pekar vid behov ut vilket tekniskt ramverk/profil som gäller.
Princip: Här står “vad som ska uppfyllas”, inklusive versionsföljsamhet, miljöer, incident- och nyckelkrav.
Registreringspolicy – OpenID Federation/OIDC (och ev. andra kontexter)
Beskriver hur en teknisk komponent registreras, valideras, driftsätts, uppdateras och avregistreras. Anger vilka artefakter/bevis som krävs och hur kontroller genomförs.
Princip: Här står “hur man gör”, steg för steg.
Tekniskt ramverk – standarder och profiler
Innehåller exakta protokollkrav (profiler, parametrar, endpoints, claims, algoritmer, felhantering) som implementatörer behöver följa.
Princip: Här står “exakt hur det ska implementeras”.
Anslutningspolicy – Anslutningsoperatör
pekar på: Tekniska anslutningsregler, Registreringspolicy
beskriver: ackreditering, ansvar, tillsyn, avstängning/återkallelse av operatör
Anslutningspolicy – Federationsmedlem
pekar på: Tekniska anslutningsregler, Registreringspolicy,
beskriver: medlemskap, åtaganden, sanktioner, avstängning/återkallelse av medlem
Tekniska anslutningsregler – SIB Federation
pekar på: Tekniskt ramverk (profil X/Y),
beskriver: verifierbara minimikrav, miljöer, versionsföljsamhet, säkerhetskrav
Registreringspolicy – OpenID Federation/OIDC
pekar på: Tekniskt ramverk, Tekniska anslutningsregler,
beskriver: registreringsflöden, evidens, validering, publicering, ändring, avregistrering
Tekniskt ramverk – standarder och profiler
refereras av: Tekniska anslutningsregler, Registreringspolicy
beskriver: exakta protokollkrav
Om frågan är ”vem får, vem ansvarar, vad händer om…” lägg i anslutningspolicy.
Om frågan är ”vilka tekniska funktionella krav som måste vara uppfyllda och hur mäter vi det” lägg i tekniska anslutningsregler.
Om frågan är ”hur går det till i onboarding/registrering/ändring” lägg i registreringspolicy.
Om frågan är ”vilka fält/claims/endpoints/algoritmer exakt” lägg i tekniskt ramverk.
Syfte: Reglerar relationen mellan Federationsoperatör och Anslutningsoperatör (ackreditering av operatör).
Innehållsförteckning (förslag):
Syfte, omfattning och definitioner
Roller och ansvar (Federationsoperatör ↔ Anslutningsoperatör)
Tillitsstruktur för operatörsled (konsekvenser vid avstängning/återkallelse)
Kriterier för att få bli Anslutningsoperatör (juridik, säkerhet, kapacitet)
Godkännande och återkommande uppföljning (tillsyn/rapportering)
Krav på operativ förmåga (incident, förändring, kontinuitet, kommunikation)
Delegationer (t.ex. utfärdande av trust marks) – principnivå
Avstängning/återkallelse och konsekvenshantering (migrering, kommunikation)
Bilagor och hänvisningar (till tekniska anslutningsregler/ramverk)
Syfte: Reglerar relationen mellan Anslutningsoperatör och Federationsmedlem (medlemskap och efterlevnad).
Innehållsförteckning (förslag):
Syfte, omfattning och definitioner
Kriterier för medlemskap (juridik, roller, ansvar)
Tillitsstruktur för medlem (konsekvenser vid avstängning/återkallelse)
Medlemsåtaganden (metadataansvar, kontaktvägar, incident, förändring)
Godkännande, uppföljning och sanktioner
Avstängning/återkallelse (medlemsnivå)
Bilagor och hänvisningar
Gräns: Inga tekniska fältlistor—bara åtaganden och efterlevnadsprinciper.
Syfte: Definierar gemensamma, testbara krav som alla parter måste uppfylla för interoperabilitet och säker drift i SIB.
Innehållsförteckning (förslag):
Översikt: mål, tillämpning, miljöer
Gemensamma säkerhetskrav (TLS, nyckelhantering, loggning, tidsstämpling, driftinfo)
Metadata- och identitetskrav (kvalitet, aktualitet, kontaktuppgifter)
Versionsföljsamhet och övergångsregler (tidsfrister, bakåtkompatibilitet)
Krav per roll (Federationsoperatör / Anslutningsoperatör / Federationsmedlem) – utan protokollfält men med tydliga verifieringspunkter
Krav på tillitsstyrning (vilka trust marks/kategorier krävs när, principnivå)
Test, granskning och godkännande (vilka bevis krävs)
Incident- och återkallelsekrav (tekniska effekter och åtgärdstider)
Hänvisningar till tekniskt ramverk och registreringspolicy
Gräns: Här kan det finnas teknikbindning via hänvisning (“för OpenID Federation gäller Ramverk X”), men detaljparametrar ligger i ramverket.
Syfte: Beskriver hur registrering/uppdatering/avregistrering går till för federationens tekniska komponenter och metadata.
Innehållsförteckning (förslag):
Roller i registreringsprocessen (vem gör vad)
Onboardingflöde (steg för steg)
Registreringsobjekt (entitetstyper, relationer, kedjor)
Validering och kontroller (automatiska + manuella)
Miljöer: test/sandbox/produktion och flyttregler
Ändringshantering (metadata, endpoints, nycklar, certifikat)
Avpublicering och återkallelse (inkl. trust mark-status)
Loggning, spårbarhet och beslut
Driftinformation och kommunikation
Mallar: checklistor, evidenskrav, tidsfrister
Gräns: Process + kontroller. Här beskrivs “hur man gör”
Syfte: Exakta standarder/profiler och parametrar som implementatörer behöver följa.
Innehållsförteckning (förslag):
Refererade standarder och profiler
OpenID Federation-profil (exakta claims, endpointkrav, policy application)
OIDC/OAuth-profil (flöden, response types, tokenkrav, signing/encryption)
Algoritmer, nycklar, tidskrav
Felhantering och säkerhetskrav på protokollnivå
Testprofil/konformitet (testfall, assertions)
Versionering och kompatibilitet
Gräns: Endast tekniska detaljer.
Policyn gäller för anslutning till SIB-federationen inklusive:
anslutning av AO till FO,
anslutning av FM (och deras entiteter) via AO,
publicering, uppdatering, avpublicering och revokering av metadata och trust marks.
Policyn reglerar inte bilaterala nyttjandeavtal mellan FM (tjänst-till-tjänst), men kräver att federationens metadata tydligt kan uttrycka avtals-/tillitsförutsättningar via policy/tillitsmarkeringar.2. Policyramverk och harmonisering
Policyn ska bestå av tre sammanhängande delar:
A) Anslutningsvillkor (juridik/avtal),
B) Tekniska anslutningsregler,
C) Operativa rutiner (processer för drift/incident/ändring).
Tekniska anslutningsregler ska vara verifierbara och knutna till anslutningsavtal (motsvarande Sweden Connect-principen att avtal definierar ansvar/avgifter och tekniska regler beskriver hur anslutningen ska fungera).
Policyn ska säkerställa att en Operatör (FO eller AO) som ansluts till SIB:
kan upprätthålla federationens tillit (trust chain) på operatörsnivå,
kan ansluta och hantera FM enligt separata medlemskrav (FM-policy),
kan genomföra drift, incident, ändring och revokering på ett sätt som skyddar federationen och dess deltagare.
Denna anslutningspolicy fastställer villkor och krav för att en organisation ska kunna anslutas som Federationsmedlem i SIB via en Anslutningsoperatör. Policyn ska:
säkerställa att Federationsmedlemmar uppfyller federationsgemensamma krav,
reglera ansvar och skyldigheter mellan Anslutningsoperatör och Federationsmedlem,
beskriva principer för anslutning, uppföljning, avstängning och återkallelse på medlemsnivå.
2.1. Policyn omfattar:
medlemskriterier och åtaganden,
ansvar för metadata, nycklar, incident och förändring,
principer för registrering, publicering och avpublicering,
principer för avstängning/återkallelse på medlemsnivå.
2.2. Policyn omfattar inte:
detaljerade protokollparametrar och fält (Tekniskt ramverk),
detaljerade registreringssteg och valideringsregler (Registreringspolicy),
ackreditering av Anslutningsoperatör (se separat policy).
Federationsmedlem: organisation som ansluter via Anslutningsoperatör och publicerar/driver entiteter/komponenter i federationskontext.
Anslutningsoperatör: organisation som ansluter och hanterar Federationsmedlemmar och deras livscykel.
Federationsoperatör: organisation som styr federationen på övergripande nivå.
5.1. Federationsmedlem ansluts under Anslutningsoperatörens tillitskedja.
Tillitskedja (princip):
Federationsoperatör → Anslutningsoperatör → Federationsmedlem → Federationsmedlemmens entiteter
5.2. Konsekvens:
Avstängning eller återkallelse av Federationsmedlem påverkar normalt endast Federationsmedlemmen och dess entiteter.
För att godkännas som Federationsmedlem ska organisationen:
kunna ingå avtal med Anslutningsoperatör,
ha utsedda kontaktfunktioner för teknik, säkerhet och verksamhet,
kunna uppfylla tillämpliga krav i Tekniska anslutningsregler,
implementera relevanta krav i Tekniskt ramverk för den entitetstyp som ansluts,
genomgå registrering och validering enligt Registreringspolicy.
Federationsmedlemmen ska:
säkerställa att publicerad information och metadata är korrekt, aktuell och spårbar,
skydda kryptonycklar och tillämpa nyckelrotation samt hantera kompromettering,
följa krav på loggning och spårbarhet enligt Tekniska anslutningsregler,
använda rätt miljöer och inte använda produktionsdata i testmiljö,
följa incident- och ändringsrutiner och informera Anslutningsoperatör vid händelser som kan påverka tillit eller interoperabilitet,
medverka i omprövning och uppföljning när detta krävs.
8.1. Federationsmedlemmen ska ha ett undertecknat anslutningsavtal med Anslutningsoperatör innan produktionsanslutning.
8.2. Avtalet ska minst reglera:
ansvarsfördelning, kontaktvägar och rapporteringskrav,
villkor för publicering, uppdatering och avpublicering,
villkor för avstängning/återkallelse och rättelsefrister,
incidenthantering och samverkan,
uppföljning och möjlighet till kontroll.
9.1. Anslutningsoperatören prövar ansökan baserat på:
organisations- och kontaktkontroller,
teknisk validering enligt Registreringspolicy,
uppfyllnad av Tekniska anslutningsregler och Tekniskt ramverk.
9.2. Federationsmedlemmen anses ansluten när:
avtal är tecknat,
registrering/validering är genomförd,
entiteter/komponenter är publicerade enligt Registreringspolicy.
10.1. Anslutningsoperatören får:
genomföra periodisk uppföljning och stickprov,
begära kompletteringar och åtgärdsplan,
kräva omprövning vid incident eller större förändring.
10.2. Federationsmedlemmen ska:
åtgärda avvikelser inom överenskommen tid,
vid behov tillfälligt begränsa funktion eller avpublicera för att minska risk.
11.1. Anslutningsoperatören kan besluta om avstängning eller återkallelse om:
väsentliga krav i policy, avtal eller tekniska anslutningsregler inte uppfylls,
publicerad metadata är felaktig eller inaktuell och inte rättas,
incidenter hanteras bristfälligt eller inte rapporteras,
Federationsmedlemmens tekniska implementation inte längre är interoperabel på ett sätt som påverkar federationen.
11.2. Vid avstängning/återkallelse ska Anslutningsoperatören:
genomföra teknisk avpublicering/ogiltigförklaring enligt Registreringspolicy,
dokumentera beslut och kommunicera till Federationsmedlemmen,
informera Federationsoperatören vid väsentliga händelser enligt överenskommen rutin.
Tekniska anslutningsregler – SIB Federation
Registreringspolicy – OpenID Federation/OIDC
Tekniskt ramverk – standarder och profiler
Eventuella checklistor och evidensmallar (publiceras separat)