Inledning
Förutsättning: Federationsmedelm är ansluten enligt Anslutningspolicy för federationsmedlemmar (arbetsmaterial)
Den här registreringspolicyn beskriver hur en teknisk komponent tas in i federationen för Samordnad identitet och behörighet (”federationen”) och hur komponentens metadata och tillitsinformation hanteras under hela livscykeln från registrering, validering, publicering, uppdatering till avregistrering.
Policyn är styrande för anslutningsoperatörens registreringsarbete och används som stöd för federationsmedlemmars administrativa och tekniska kontaktpersoner.
Policyn beskriver processen och den tekniska hanteringen på artefaktnivå, dvs. vilka federationsobjekt som skapas och uppdateras
Detaljerade protokoll och interoperabilitetskrav (t.ex. exakta fältkrav, säkerhetsparametrar, endpoints) återfinns i separata tekniska profiler och tekniska anslutningsregler. Denna policy hänvisar till dessa dokument när de finns fastställda.
Omfattning och tillämpning
Här beskrivet vi koppling till avtal, villkor och meta dataregistrering, Definierar när policyn gäller så som vid nyregistrering, uppdatering och avregistrering
Roller och ansvar
Här beskriver vi roller som träffas av policyn samt relationerna mellan roller ex Anslutningsoperatör, Federationsmedlem
Koppling/referens bör finnas till anslutnignspolicy/avtal här?
Federationsoperatör
kanske ska beskrivas?
Anslutningsoperatör
Anslutningsoperatör är den organisation/funktion som:
tar emot och handlägger ansökningar från federationsmedlemmar,
genomför registreringskontroller och beslutsunderlag,
godkänner och avregistrerar federationsmedlemmar och deras komponenter, och
driver den tekniska funktionen för anslutning/registrering (t.ex. “anslutningstjänst”) och tillhörande register.
I federationsmodellen kan anslutningsoperatören ha delegerat ansvar från överordnad federationsfunktion och förväntas kunna godkänna/avregistrera komponenter och deras metadata?
Federationsmedlem
Federationsmedlem är en organisation som ansluter en eller flera tekniska komponenter till federationen och nyttjar federationens tillitsinformation för samverkan. Federationsmedlemmar förutsätts ingå avtal med anslutningsoperatör för att kunna placera komponenter i federationen.
Teknisk komponent
Med teknisk komponent avses i denna policy en federationsentitet som federationsmedlem ansluter och som ska kunna upptäckas och valideras genom federationens metadata/tillitsinformation. Exempel på komponenttyper:
- legitimeringstjänst/OP,
- förlitande part/RP,
- auktorisationstjänst/AS,
- resurs/API (RS) och API-klient,
- attribut-/informationskälla??,
- övriga om jag missat nån federationsprotokollentiteter enligt tekniska profil(er).
Trust Mark Issuer kanske ska heta nåt annart så som egenskapsintygutföärdare
Trust Mark Issuer är en federationsentitet som utfärdar Trust Marks, dvs signerade intyg om xyz
Federationsmiljöer
Beskriver krav kopplade till olika miljöer såsom test, QA och produktion. Reglerar hur komponenter får flyttas mellan miljöer och vilka krav som gäller per miljö.
Registreringsbara tekniska komponenter
Specificerar vilka typer av komponenter som får registreras, exempelvis IdP, SP, attributtjänster osv.
Process för registrering och verifiering av metadata
Villkor för organisatorisk koppling, behörigföreträdare mm koppling/referat till anslutningspolicy
Här regleras organisatorisk koppling, behörig företrädare och publicerbarhet på någon nivå, samt att detaljerade tekniska krav/test det senare kanske ligger under tekniska anslutnings regler?
Koppling finns troligen till Anslutningspolicy (behörighet/anslutningsvillkor), Tekniska anslutningsregler (detaljer).
Förutsättningar för att registrering får initieras
Här anges att registrering endast får initieras av behörig företrädare (utsedd administrativ/teknisk kontakt) och att organisationen omfattas av anslutningsvillkoren.
Koppling: Anslutningspolicy (medlemskap, roller, behörig företrädare).
Villkor för organisatorisk koppling
Här beskrivs hur komponenten ska kopplas till rätt organisation (t.ex. orgnr/orgnamn) och hur operatören verifierar kopplingen beskriv hur och kolla koppling till Anslutningspolicy för federationsmedlemmar (arbetsmaterial)
Inlämning av metadata för registrering
Här beskrivs antingen vilka metadata som minst ska lämnas in kanske på typnivå (identifierare, orginfo, nycklar, endpoints, kontakt) eller så ska vi lista alla fält?
Grundläggande verifiering inför publicering
Här beskrivs vilken verifiering som alltid görs innan publicering,
Beslut, publicering och återkoppling
Här beskrivs beslutspunkten (godkänn/avvisa/kräv komplettering), hur publicering sker i federationen samt hur medlemmen får återkoppling. Här borde det finns en del klurigheter så som vad som händer vid avslag och vad som ses som myndighetsutövning osv?
Hantering av avvikelser, spärrar och avregistrering
Här beskrivs vad som händer om organisatorisk koppling inte kan styrkas eller om metadata bedöms inte vara publicerbar.
Metadataregler
Beskriver övergripande regler för hur teknisk metadata för en federerad komponent ska vara utformad, vad den ska innehålla och hur den valideras. Syftet ät att metadata kan publiceras och användas för automatiserad tillitsetablering och interoperabilitet i federationen. Metadatareglerna gäller för federationsmedlemmars tekniska komponenter som registreras i federationen oavsett roll (t.ex. utfärdare/auktorisationsserver, förlitande part/klient, eller andra federationstjänster).
Teknisk metadata - organisationnr, orgnamn, entity_id, nycklar mm
Reglerar struktur, innehåll och validering av metadata. Anger obligatoriska element såsom organisationsinformation, endpoints, certifikat osv.
Metadata ska knytas till en teknisk komponent via en entydig identifierare dessutom ska metadata bära tillräcklig organisationsinformation för att koppla komponenten till ansvarig federationsmedlem det skulle kunna vara ex:
- organisationsnummer,
- organisationsnamn,
- relevanta kontaktuppgifter (administrativ och teknisk kontakt),
- eventuell koppling till avtal/anslutningsrelation
- mm
- ELLER så är det en hänvisning till den svenska iodf profileneller nåt annat?
Identifierare och organisationsuppgifter ska vara stabila över tid. Ändring av dessa uppgifter sker enligt nån process nånstans som inte beskrivits ännu.
Egenskapsintyg
Ett egenskapsintyg är ett digitalt, signerat intyg som uttrycker vissa egenskaper hos en aktör eller dess tekniska komponenter på ett standardiserat och maskinläsbart sätt, så att det kan verifieras och användas automatiserat.
Det används för att styrka förutsättningar eller statusar som är relevanta för samverkan, till exempel att ett visst avtal är tecknat? eller andra organisatoriska/tekniska villkor är uppfyllda?
Det ska inte användas för att uttrycka juridisk behörighet eller beslutsmandat? (sånt hör hemma i särskilda behörighetsintyg/behörighetshandlingar).
Tekniska krav på komponenter
Anger krav på protokollstöd, säkerhetskonfiguration, signering och kryptering. Reglerar användning av specificerade profiler och tekniska standarder.
Attribut- och identitetsregler
Definierar vilka attributuppsättningar som får levereras och under vilka förutsättningar. Reglerar särskilda fall såsom organisationsidentiteter och samordningsnummer.
Test och verifiering
Beskriver processen för teknisk granskning och verifiering innan produktionssättning. Anger krav på testfall, interoperabilitet och säkerhetskontroller.
Förändringshantering - kanske ska slå ihop med Kap 13.
Reglerar hur ändringar i metadata, certifikat, endpoints eller funktionalitet ska hanteras. Anger krav på notifiering och eventuell "omgranskning".
Löpande uppföljning och kontroller
Fastställer mekanismer för kontinuerlig validering av metadata och teknisk efterlevnad i syfte att möjliggör revision, stickprov(er) och incidentbaserad kontroll(er).
Avregistrering och återkallelse
Reglerar hur komponenter avregistreras frivilligt eller genom beslut. Anger hur metadata tas bort och hur tillit återkallas vid allvarliga avvikelser.
Versionshantering och uppdatering
Beskriver hur nya versioner av tekniska krav införs och tidsramar för anpassning. Fastställer hur policyn själv uppdateras och träder i kraft.
--------------------------------Tankar och noteringar--------------------------------
Krav
anslutningsoperatör ska endast utfärda Subordinate Statement efter genomförd verifiering enligt avsnittet “Verifiering och granskning”.
anslutningsoperatör ska dokumentera vilka kontroller som utförts och vilket beslutsdatum som gäller för utfärdandet.
anslutningsoperatör ska inkludera policy-identifierare så att andra parter kan förstå vilket regelverk som gällde vid intag
Federationsmedlem
Federationsmedlem är en organisation som ansluter en eller flera tekniska komponenter till federationen och nyttjar federationens tillitsinformation för samverkan. Federationsmedlemmar förutsätts ingå avtal med anslutningsoperatör för att kunna placera komponenter i federationen.
Krav
Federationsmedlem ska utse både administrativ och teknisk kontaktperson med mandat att initiera och godkänna registreringsärenden för organisationens komponenter.
Federationsmedlem ska säkerställa att inlämnad metadata/tillitsinformation är korrekt, aktuell och att ändringar hanteras enligt denna policy. Återstår att beskriva
Teknisk komponent
Med teknisk komponent avses i denna policy en federationsentitet som federationsmedlem ansluter och som ska kunna upptäckas och valideras genom federationens metadata/tillitsinformation. Exempel på komponenttyper (ej uttömmande):
legitimeringstjänst/OP,
förlitande part/RP,
auktorisationstjänst/AS,
resurs/API (RS) och API-klient,
attribut-/informationskälla??,
andra federationsprotokollentiteter enligt gällande tekniska profiler.
Förutsättningar för ansökan
För att en ansökan ska handläggas ska följande förutsättningar vara uppfyllda:
Krav
Federationsmedlem ska ha ett giltigt anslutningsavtal med anslutningsoperatör innan komponentregistrering påbörjas.
Federationsmedlem ska kunna styrka att ansökande person har mandat att företräda organisationen i registreringsärendet här blir det nån koppling till anslutingspolicy
Komponentens avsedda produktionsmiljö ska vara definierad (t.ex. prod/test/utbildning) och kunna särskiljas i registreringsunderlaget.
Teknisk metadata/tillitsinfo som krävs för registrering
För registrering ska följande lämnas in:
Komponentens Entity Identifier (ID) samt angiven komponenttyp/roller?: vilka roller stöds i federationen?.
Länk/åtkomstväg till komponentens Entity Configuration (som komponenten själv publicerar?).
Komponentens federationsnyckelmaterial (publika nycklar via Entity Configuration eller annat?).
Uppgifter om driftmiljö: test/produktion,
Uppgifter om relevanta endpoints/åtkomstpunkter enligt tekniska profiler
Uppgift om vilka överordnade federationsentiteter som ska kunna utfärda Subordinate Statement
Om Trust Marks används: vilka Trust Mark-typer som krävs och hur de ska tillhandahållas
Komponentnamn och intern komponent‑ID hos federationsmedlem.
Referens till godkända testresultat och datum.
Referens till ansökningsärende-ID, och ansvarig beslutsfattare hos federationsmedlem.
Krav
För registrering ska federationsmedlem tillhandahålla åtkomst till komponentens Entity Configuration så att anslutningsoperatören kan validera den före godkännande.
För registrering ska federationsmedlem ange vilka planerade produktionsendpoints som gäller, samt från vilken dag/tid de ska anses aktiva (aktiveringstidpunkt).
Kontaktvägar för incident/förvaltning
För registrering ska följande lämnas in:
Incidentkontakt (24/7 eller definierad beredskap): e‑post, telefon, eskaleringsnivåer.
Förvaltningskontakt: kanal för planerade ändringar (t.ex. ärendeportal), och kanal för akuta ändringar.
Beskrivning av hur anslutningsoperatören ska nå federationsmedlem vid kritiska avvikelser (t.ex. nyckelkompromettering, felpublicerad metadata).
Anslutningsoperatören ska koppla varje registrering till ett unikt ärende-ID och spara vilken policy-URI och vilken beslutsversion som tillämpades.
Federationsmedlem ska vid senare ändringar kunna hänvisa till senaste godkända baseline (versionsinfo) och uppge vad som ändrats.
Krav
Federationsmedlem ska kunna initiera akut ändringsärende (t.ex. nyckelkompromettering) via någon form av ingång och ange åtgärdsplan.
Anslutningsoperatören ska ha dokumenterad rutin för hur incidentkontakt används för att kunna avregistrera/stoppa komponent vid behov
Draft av dokumentsdisposition
Registreringspolicy (RP) – Rubriknivå med scope
- 1. Inledning
Beskriver syftet med registreringspolicyn och dess roll i federationsstyrningen. Klargör att policyn reglerar hur tekniska komponenter får registreras och publiceras i federationen. - 2. Omfattning och tillämpning
Anger vilka aktörer och komponenter som omfattas av policyn. Definierar när policyn gäller – vid nyregistrering, uppdatering och avregistrering. - 3. Roller och ansvar
Fastställer ansvarsfördelningen mellan federationsoperatör, anslutningsoperatörer och federationsmedlemmar. Klargör vem som ansvarar för korrekt metadata, teknisk konfiguration och löpande efterlevnad. - Avtal?
- Koppling till anslutnignspolicy/avtal?
- 4. Federationsmiljöer
Beskriver krav kopplade till olika miljöer såsom test, QA och produktion. Reglerar hur komponenter får flyttas mellan miljöer och vilka krav som gäller per miljö. - 5. Registreringsbara tekniska komponenter
Specificerar vilka typer av komponenter som får registreras, exempelvis IdP, SP, attributtjänster och underskriftstjänster. Klargör att varje instans är en separat registreringsenhet. - 6. Process för verifiering och registrering av metadata
- Villkor för organisatorisk koppling, behörigföreträdare
- Metadataregler
- Teknisk metadata - organisationnr, orgnamn, entity_id, nycklar mm
Reglerar struktur, innehåll och validering av metadata. Anger obligatoriska element såsom organisationsinformation, endpoints, certifikat och UI-information. - Egenskapsintyg
7. Tillitsidentifierare och entitetskategorier
Fastställer hur tillitsnivåer och entitetskategorier ska deklareras i metadata. Reglerar kopplingen mellan godkänd tillitsnivå och tillåtna identifierare.
- 8. Tekniska krav på komponenter
Anger krav på protokollstöd, säkerhetskonfiguration, signering och kryptering. Reglerar användning av specificerade profiler och tekniska standarder. 9. Attribut- och identitetsreglerDefinierar vilka attributuppsättningar som får levereras och under vilka förutsättningar. Reglerar särskilda fall såsom organisationsidentiteter och samordningsnummer.- 10. Test och verifiering
Beskriver processen för teknisk granskning och verifiering innan produktionssättning. Anger krav på testfall, interoperabilitet och säkerhetskontroller. - 11. Förändringshantering
Reglerar hur ändringar i metadata, certifikat, endpoints eller funktionalitet ska hanteras. Anger krav på notifiering och eventuell omgranskning. - 12. Löpande uppföljning och kontroller
Fastställer mekanismer för kontinuerlig validering av metadata och teknisk efterlevnad. Möjliggör revision, stickprov och incidentbaserad kontroll. - 13. Avregistrering och återkallelse
Reglerar hur komponenter avregistreras frivilligt eller genom beslut. Anger hur metadata tas bort och hur tillit återkallas vid allvarliga avvikelser. - 14. Versionshantering och uppdatering
Beskriver hur nya versioner av tekniska krav införs och tidsramar för anpassning. Fastställer hur policyn själv uppdateras och träder i kraft.