På sidan:

1. Syfte och avgränsning

Syftet med att ha flera miljöer är att stegvis verifiera tekniska, säkerhetsmässiga och operativa förutsättningar för att etablera en tillitsrelationen mellan aktörer inom federationen. 

Det finns tre miljöer:

• Sandbox används för teknisk utveckling och experimentering. Här ligger fokus på att ge aktören möjlighet att prova federationens tekniska gränssnitt och ramverk utan att någon faktisk produktionstillit etableras. 
• QA används för kontrollerad verifiering. Här prövas om aktören uppfyller de tekniska, säkerhetsmässiga och operativa krav som krävs för att kunna etablera en tillitsrelation i produktion.
• Produktion är den skarpa federationsmiljön. Här uttrycker tillitsankaret faktiskt tillit till den anslutna aktören inom ramen för federationens tillitsmodell. Tillträde till produktion förutsätter därför att aktören har verifierats och godkänts enligt fastställda krav. 

Miljöerna har olika syften och ställer därför olika krav på en anslutande aktör. Kraven ökar successivt mellan miljöerna. Miljöerna är separata från varandra vilket innebär att:

• varje aktör har en egen instans per miljö, och
• en instans får bara nyttja federationsoperatörens tillitsankare i samma miljö.

Kraven gäller för både anslutningsoperatörer och dess registrerade infrastrukturtjänster, även kallade aktör/aktörer när dessa inte behöver specificeras. En aktör ansvarar för sin egen anslutning och för att kraven för dess roll i federationen uppfylls. En anslutningsoperatör ansvarar även för att de federationsmedlemmar och dess protokollentiteter som operatören ansluter eller förvaltar hanteras på ett sådant sätt att federationens krav och etablerade tillitsrelation kan upprätthållas. 

Kraven nedan ska ses som minimikrav för piloten dessa krav kan komma att justeras och kompletteras under pilotens gång när vi fått en större erfarenhet av hur den distribuerade modellen fungerar i praktiken.

Avgränsningar:

• Kraven är minimikrav för piloten och kan justeras under piloten i takt med att nya insikter nås.
• Sidan upprepar inte krav som redan finns på annat håll. Det innebär att kraven ska läsas tillsammans med Federationsregelverk BAS och de grundläggande kraven på federationsinfrastrukturtjänster.
• Pilotavsteg samlas i avsnitt X

2. Begrepp

3. Ansvarsförhållande

Detta avsnitt beskriver ansvarsfördelningen mellan federationsoperatören och de aktörer som ansluter till federationen. Syftet är att tydliggöra vilka funktioner federationens tjänster ansvarar för att tillhandahålla, vilket stöd som kan ges vid verifiering samt vilket ansvar som ligger på federationsmedlemmar och anslutningsoperatörer. Ansvarsfördelningen gäller för samtliga miljöer och ska läsas tillsammans med de krav som gäller för respektive miljö (läs Kapitel 4).

3.1 Federationsoperatörens tjänster och ansvar

Federationsoperatören (DIGG) tillhandahåller i detta fall tillitsankartjänsten och resolvertjänsten. Tjänsterna ska stödja federationens funktion enligt det federationsramverk och de profiler som tillämpas. De ska hållas åtskilda mellan Sandbox, QA och produktion, så att en aktör använder den tjänst och det tillitsankare som hör till den aktuella miljön.

3.1.1 Vad tillitsankartjänsten och resolvertjänsten ska tillhandahålla

Tjänsternas grundläggande funktioner ska finnas tillgängliga enligt den tjänstebeskrivning och de krav som gäller för respektive miljö. Det innebär att federationsoperatören ska: 

• tillhandahålla det tillitsankare som gäller för den aktuella miljön, så att aktörer kan etablera och tillitskedjor enligt federationens ramverk
• tillhandahålla resolvertjänstens funktioner för att hitta eller hämta den federationsinformation om entiteter som tjänsten enligt federationens ramverk ska kunna hantera
• tillhandahålla de gränssnitt, endpoints och den konfigurationsinformation som aktörer behöver för att använda tjänsterna
• beskriva vilka funktioner och begränsningar som gäller för tjänsterna i respektive miljö
• säkerställa att konfigurationen för respektive miljö överensstämmer med federationens fastställda krav

Exakta funktioner och krav för respektive tjänst beskrivs i tillämpliga tjänste- och kravbeskrivningar (Här länkar vi till krav?)

3.1.2 Vad federationsöperatören kan hjälpa till att verifiera

Utöver att tillhandahålla tillitsankartjänst och resolvertjänst kan federationsoperatören, inom ramen för sin verifieringsprocess och de funktioner som tjänsterna omfattar, hjälpa en aktör att kontrollera att anslutningen är korrekt konfigurerad och fungerar mot federationens tjänster. Detta kan innefatta:

• att rätt tillitsankare och rätt miljö används
• aktörens federationsentitet, entity identifier och OIFD-metadata är konfigurerade enligt federationens krav och tillämpliga profil
• aktörens tillitskedja kan etableras och valideras mot tillitsankaret
• resolvertjänsten kan hitta eller hämta förväntad federationsinformation för den aktuella entiteten
• de protokollfunktioner som ingår i anslutningen till federationens tjänster fungerar som avsett
• tekniska avvikelser som upptäcks vid kontrollerna kan identifieras och utredas inom ramen för verifiering

Vilka av dessa kontroller som faktiskt genomförs och vilka som krävs för godkännande ska framgå av verifieringskraven under kapitel 4.

Den anslutande aktören ansvarar fortfarande för sin egen implementation, säkerhet, drift och förvaltning. Federationsoperatörens stöd innebär inte heller att operatören har verifierat informationsutbyte mellan parter inom ett federationskontext. 

3.2 Anslutande aktörers ansvar

Varje aktör ansvarar för sin egen anslutning och för att uppfylla de krav som gäller för aktörens roll i federationen.

3.2.1 Federationsmedlem

Federationsmedlemmen ansvarar för att den egna protokollentiteten uppfyller tillämpliga krav och att den egna anslutningen kan användas och förvaltas på ett säkert sätt.

Det innebär bland annat ansvar för att

• hantera registrering och konfiguration av underliggande protokollentiteter
• hantera identifierare, OIDF-metadata, nycklar och relevanta entitetstyper
• hantera förändringar och avveckling av underliggande anslutningar
• säkerställa att de krav som gäller för de underliggande aktörerna hanteras på ett kontrollerat sätt
• upprätthålla kontroll över vilka aktörer och integrationer som är anslutna

Vilka kontroller och förmågor som ska verifieras framgår av krav för respektive miljö i kapitel 4.

3.3 Verifiering av anslutning och informationsutbyte

En differentiering mellan verifiering av aktörs anslutning till federationens tjänster och att verifiera informationsutbyte mellan två parter behöver göras. 

En verifiering mot federationens tjänster kan visa att en aktörs konfiguration, OIDF-metadata och tillitskedja fungerar enligt de krav som verifieras i den aktuella miljön. Detta innebär inte automatiskt att informationsutbyte med en annan aktör fungerar. 

När två aktörer ska utbyta information ansvarar berörda aktörer för att verifiera att deras lösningar fungerar tillsammans för det aktuella användningsfallet. Att en aktör har verifieras mot federationsoperatörens tjänster innebär det inte automatiskt att aktören har verifierats för informationsutbyte med andra aktörer.

3.2.2 Verifiering mellan två aktörer

När två aktörer ska utbyta information behöver berörda aktörer också säkerställa att deras lösningar fungerar tillsammans med det aktuella användningsfallet. Berörda aktörer ansvarar för att verifiera sitt specifika informationsutbyte. En verifiering i QA ersätter därför inte automatiskt tester mellan aktörer inför ett visst informationsutbyte. 

4. Miljöer och definitioner

4.1 Sandbox

Sandbox är en öppen utvecklings- och testmiljö för aktörer som vill prova integration mot federationens tekniska gränssnitt. Tillgång kräver ansökan men inget avtal.

Syftet är att sänka tröskeln för att komma igång och ge möjlighet att experimentera med OpenID Federation-ramverket, OAuth2 samt övriga tekniska komponenter som ingår. Sandbox har därför inga andra onboardingkrav än att aktören kan identifiera sig som organisation samt att man har de tekniska förutsättningar som krävs för att genomföra en integration. 

4.1.1 Gemensamma krav

För att använda Sandbox gäller detta för samtliga aktörer:

• identifiera organisationen som står bakom anslutningen
• minst en ansvarig kontaktperson 
• tillhandahålla eventuella endpoints, OIDF-metadata och testuppgifter som behövs för integrationen. 
• förutsättningar för att använda federationens testmiljö
• använda testdata och testcredentials

Det görs ingen bedömning av produktionsmognad eller faktisk tillit. Den verifiering som görs i Sandbox syftar främst till att ge aktören möjlighet att kontrollera sin implementation och bekanta sig med ramverket.

4.1.2 Federationsmedlem

Federationsmedlemmen kan använda Sandbox och för att prova och verifiera sin egna implementation.

Verifieringen kan exempelvis omfatta:

• hur OIDF-metadata och entitetkonfiguration fungerar
• etablering och validering av tillitskedja
• relevant OAuth2-flöde enligt ENA
• hantering av tokens, claims och scopes
• nycklar och signering
• teknisk felhantering (felanrop)

4.1.3 Anslutningsoperatör

Anslutningsoperatören kan använda sandbox för att prova både sin egen implementation av de tekniska krav som uppfyllas, exempelvis OIDF-metadata, nyckelhantering, OAuth 2.0, OIDC, och de funktioner som krävs för att ansluta och hantera underliggande federationsmedlemmar och dess protokollentiteter. 

Anslutningsoperatören bör därför kunna verifiera:

• hantering av underliggande protokollentiteters OIDF-metadata
• etablering och validering av tillitskedjor för registrerade protokollentiteter 
• federationstekniska flöden mellan anslutningsoperatör och federationsmedlems protokollentiteter
  • OAuth 2.0, OIDF-metadata, nyckelhantering, förändring och uppdatering av klientkonfiguration
• livscykelhantering

Resultatet från Sandbox är i första hand ett tekniskt underlag för aktören själv. Det innebär inte att aktören därmed är godkänd av en federationsoperatör. Sandbox ska inte betraktas som en produktionsmässigt betrodd miljö. Testdata ska användas och inga krav på full operativ beredskap ställs i detta steg på varken miljö eller aktörer. Det som sker i Sandbox ska inte ligga till grund för att aktören automatiskt betraktas som godkänd för QA eller Produktion. En aktör kan använda Sandbox för utveckling och tester utan att senare ansluta till de andra miljöerna. 

4.1.4 Icke-funktionella krav

Det finns inga formella krav på tillgänglighet, incidentberedskap eller SLA för sandbox. Miljön är till för utveckling och testning och kan därför påverkas av planerade eller oplanerade underhållsarbeten utan särskilda krav på tillgängligheten.  

Det är fördelaktigt om aktören kan följande:

• använda säkra kommunikationskanaler, exempelvis HTTPS
• skydda nycklar och credentials som används i testmiljön på ett rimligt sätt
• inte använda produktionsdata eller produktionscredentials
• kunna identifiera en teknisk kontaktperson vid behov

4.2 QA

QA är miljön för kontrollerad verifiering av en aktörs integration inför eventuell anslutning till Produktion. Till skillnad från Sandbox krävs ett aktivt godkännande av federationsoperatören för att få ansluta. Länk till blankett för anslutning: INSERT_LINK_HERE

Syftet är att verifiera att aktören uppfyller de funktionella, säkerhetsmässiga och operativa krav som ställs inför en anslutning till produktion. Tester behöver inte ha genomförts i Sandbox för att få ansluta till QA, även om det är rekommenderat att först ha experimenterat i Sandbox. Det är däremot krav på att aktören uppfyller de krav och genomför de verifieringar som definieras för QA. 

Resultatet av QA används som underlag för beslut om anslutning till produktion.  

QA används för att verifiera att en anslutningsoperatör eller federationsmedlem fungerar tillsammans med federationen på ett sådant sätt att den kan gå vidare mot produktion. QA ska därför användas för att verifiera både teknisk funktionalitet och de säkerhetsmässiga och operativa förutsättningar som krävs för att kunna etablera tillit. 

Kraven är högre i QA än i Sandbox. Här är det krav på att integrationen fungerar på ett förutsägbart och säkert sätt

För att få ansluta till QA bör aktören kunna visa att den har förutsättningar att genomföra en fullständig verifiering. Det behöver inte innebära att aktören tidigare har använt Sandbox. 

4.1.1 Gemensamma krav

För att få börja nyttja QA bör följande finnas:

• organisationen är identifierad
• utpekade kontaktpersoner med relevant expertis
• definierad roll i federationen, exempelvis federationsmedlem eller anslutningsoperatör
  • för en anslutningsoperatör bör det även finnas en tydlig beskrivning av vilka federationsmedlemmar som operatören avser att ansluta. 
• identifierade federation- och OAuth flöden enligt OIDF och ENA
• nödvändiga testnycklar och credentials
• en beskrivning av hur QA-instansen motsvarar den planerade produktionen i version och konfiguration. Eventuella skillnader ska redovisas, eftersom resultatet annars inte gäller för produktion.
• en överenskommen testkonfiguration 
  • anslutningsoperatörer behöver tillhandahålla
    • en separat QA-instans som korrekt etablerar och validerar tillitskedjan till federationsoperatörens tillitsankare i QA 
    • den underordnades "entity identifier"
    • den underordnades publika "federation entity keys"
    • vilka "entity types" den underordnade har
  • anslutningsoperatören ska följa federationsramverkets tillämpningskrav i samband med att federationsmedlemmar och dess protokollentiteter registreras 

4.1.2 Federationsmedlem

Federationsmedlemmen ska kunna verifiera sin egen förmåga att uppfylla federationens krav.

Federationsmedlemmen verifiering bör omfatta:

• användning av relevanta profiler
  • följer och använder de profiler som finns
    • ENA OAuth 2.0
    • OIDF Swedish profile
    • OIDC Sweden Connect profile
• korrekt etablering och validering av tillitskedja
• OIDF-metadata som överensstämmer med federationens krav och policy
• hantering av tokens, claims och scopes
• säker hantering av nycklar
• End-to-end-tester
  • korrekt etablering och validering av tillitskedja
  • att OIDF-metadata överensstämmer med federationens krav och policy
  • att tillåtna OAuth2-flöden fungerar korrekt i enlighet med ENA
  • hantering av tokens, claims och scopes
  • hantering av nycklar och nyckelrotation
  • felhantering
• livscykelhantering
  • möjlighet att avaktivera eller avveckla en anslutning
  • möjlighet att förändra och uppdatera OIDF-metadata på ett kontrollerat sätt
• incidenthantering
• återställningshantering ?

4.1.3 Anslutningsoperatör

För anslutningsoperatörer ska verifiering även omfatta förmågan att hantera underliggande klienter och att hantera federationens krav och tillit vidare på ett kontrollerat och säkert sätt. 

Anslutningsoperatören bör kunna verifiera följande:

• identifiera vilka klienter och aktörer som operatören avser att ansluta
• hantera underliggande klienters entity identifier och tillhandahåll dessa till ansvarig för tillitsankartjänst
• hantera underliggande klienters publika federation entity keys och tillhandahåll dessa till ansvarig för tilltisankartjänst
• hantera vilka entity types underliggande klienter har och tillhandahåll dessa till ansvarig för tillitsankartjänst
• kontrollera och sätta relevanta organisationsuppgifter enligt tillämpningskraven
• verifiera underliggande integrationers konfiguration
• hantera förändringar i OIDF-metadata
• stöd för att kunna hantera förändringar i underliggande integrationer
• säkerställa att federationens krav och tillit hanteras vidare på ett kontrollerat och säkert sätt. 

QA ska avslutas med ett tydligt ställningstagande: godkänd för produktion, godkänd med åtgärder eller inte godkänd. 

4.1.4 Icke-funktionella krav

I QA behöver kraven vara högre eftersom miljön används för att avgöra om en aktör är tillräckligt mogen för produktion. Aktören bör därför kunna fullfölja följande:

• ha tillräcklig säkerhet kring privata nycklar och credentials så att ingen obehörig kan få åtkomst till dessa
• använda säkra kommunikationskanaler, exempelvis HTTPS
• ha en relevant loggning och spårbarhet
• kunna upptäcka och hantera fel i den egna integrationen
• kunna genomföra förändringar i den nuvarande anslutningen utan att tappa kontrollen
• ha en namngiven teknisk kontaktperson och definierad kontaktväg för incidenter

I QA bör tjänsterna vara tillgänglig i sådan omfattning att planerade tester och verifieringar kan genomföras. Planerade underhållsarbeten bör i möjligaste mån kommuniceras i förväg till berörda parter. Oplanerade störningar som kan påverka eller påverkar tester och verifieringar ska kommuniceras till berörda parter så snabbt som möjligt efter identifierat problem. 

5.1 Produktion

Produktion är den skarpa miljön och den enda miljön där tillitsankaret faktiskt uttrycker en tillit till den en ansluten aktör inom ramen för federationen. För att ansluta till Produktion ska aktören ha genomgått den verifiering som krävs i QA och därefter godkänns anslutningen till produktion. Anslutningen till produktion förutsätter även att produktionsspecifika förutsättningar är uppfyllda, exempelvis hantering av OIDF-metadata, nycklar, kontaktvägar och rutiner för incidenthantering. 

Kraven för produktion ska inte primärt användas för att testa om implementationen fungerar, utan för att säkerställa att den aktör som får tillgång till produktionsmiljön är verifierad och att det finns tillräckliga förutsättningar för att förvalta anslutningen över tid. 

5.1.1 Gemensamma krav

För att få börja nyttja produktion krävs följande:

• godkänd QA-verifiering
• verifierade produktionsidentiteter och OIDF-metadata
• produktionsnycklar och credentials
• namngivna tekniska och operativa kontaktvägar
• livscykelhantering
  • hantering av förändringar
  • aktivering och avslutning av anslutning
• rutin för incidenthantering
• övervakning av egen anslutning
• end-to-end-flöde testat och verifierat

Anslutningen till produktion ska uttryckligen vara godkänd av samtliga inom federationen och därmed även federationsoperatören (DIGG i detta fall). 

Inför produktionssättningen verifieras framförallt att den konfiguration som ska användas i produktion överensstämmer med det som verifierats i QA.

5.1.2 Federationsmedlem

Klienten ansvarar för att den egna anslutningen till produktion förvaltas så att den etablerade tilliten kan upprätthållas.

Detta innebär att klienten ska kunna:

• skydda privata nycklar och credentials
• hantera åtkomst till administrativa funktioner 
• upprätthålla loggning och spårbarhet
• övervaka relevanta händelser och sätta upp relevanta lar
• hantera förändringar på ett kontrollerat sätt
• hantera säkerhetsuppdateringar och sårbarheter inom rimlig tid (Vad innebär en rimlig tidsram?)
• hantera incidenter
• upprätthålla tillräcklig tillgänglighet (Utifrån avtal)
• kommunicera relevanta förändringar till berörda parter

5.1.3 Anslutningsoperatör

Anslutningsoperatören ska uppfylla samma krav för sin egen anslutning till produktion och har utöver detta ansvar för underliggande klienter som operatören ansluter eller förvaltar.

Anslutningsoperatören bör därför kunna:

• upprätthålla kontroll över vilka underliggande integrationer som är anslutna
• hantera klienternas OIDF-metadata och federationens tekniska krav
  • OIDF-metadata, nycklar, ENA OAuth2.0-profil  
• hantera aktivering, förändring och avslutning av underliggande klienter
• säkerställa att underliggande klienter fortsätter uppfylla relevanta krav
• hantera incidenter
• kommunicera relevanta förändringar och incidenter till berörda parter
• hantera federationens krav och tillit vidare till underliggande klienter på ett kontrollerat och säkert sätt

Det bör därför verifieras att:

• rätt produktionsidentitet används
• rätt nycklar och endpoints används
• federationens OIDF-metadata och policy följs
• kontaktvägar fungerar
• incidenthantering är förankrad i egna organisationen
• verifieringar av end-to-end-flödet i produktionden t
  • säkerställ att den tekniska integrationen fungerar med produktionskonfigurationen

När väl aktören börjat nyttja produktionsmiljön måste lösningen förvaltas så att aktören kan agera på förändringar inom federationskontexten.

5.1.4 Icke-funktionella krav

I produktion behöver de icke-funktionella kraven stödja en faktisk och långsiktigt förvaltad tillitserlation.

Aktören bör därför:

• skydda privata nycklar och andra credentials enligt grundläggande krav på federationsinfrastrukturtjänster
• ha tydlig åtkomststyrning och kontroll över administrativa funktioner
• ha tillräcklig loggning och spårbarhet för att kunna utreda relevanta händelser
  • detta innefattar även övervakning och larmhantering
    • tröskelvärden
• kunna hantera förändringar på ett kontrollerat sätt
• ha en etablerad kontaktväg för incidenter och tekniska frågor
• kunna hantera säkerhetsuppdateringar och sårbarheter inom rimlig tid
• upprätthålla en tillräcklig tillgänlighet för de federationstjänster som ingår i anslutningen
  • Finns ej något definierat här ännu (SLA)

I produktion förväntas aktören ha en tillräcklig nivå av tillgänglighet för att den etablerade tilliten ska kunna upprätthållas. Planerade underhållsarbeten bör genomföras på ett kontrollerat sätt och kommuniceras till berörda parter i förväg. VId längre eller mer omfattande avbrott bör aktören kunna informera ägaren av tillitsankartjänsten om påverkan och förväntad tidsram för det planerade avbrottet. 

Lägg till stycke relaterat till SLA här. Något i linje med 99,5% tillgänlighet eller liknande... när det finns på plats.

Planerat underhåll bör i första hand genomföras på ett sådant sätt att tillitsrelationen och federationens funktion påverkas så lite som möjligt. Förändringar som kräver verifiering av andra parter inom federationen som exempelvis OIDF-metadata, nycklar, endpoints bör kommuniceras och vid behov verifieras i QA innan förändringen produktionssätts.

Vid oplanerade störningar eller säkerhetsincidenter ska aktören ha möjlighet att snabbt informera berörda parter och vidta åtgärder för att begränsa påverkan och återställa anslutningen.

6. Pilotavsteg

Om det är så att det kommer överens om några pilotavsteg avseende miljöerna så kan vi samla det i ett eget avsnitt för att se ta bort det när piloten är klar