På sidan:
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:
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:
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:
| Begrepp | Betydelse på denna sida |
|---|---|
| Federationsoperatör | Digg, som driver Federationskontext BAS och tillhandahåller tillitsankartjänsten och uppslags- och verifieringstjänsten. |
| Anslutningsoperatör | En part som ansluter federationsmedlemmar. Tekniskt tillhandahåller den en intermediate och eventuellt en resolver. Under piloten är det Inera och Internetstiftelsen. |
| Federationsmedlem | En organisation som deltar i federationskontexten genom sina protokollentiteter, till exempel EHM. |
| Protokollentitet | En federationsmedlems tekniska entitet, till exempel klient, åtkomstintygstjänst eller resursserver. |
| Aktör | Samlingsbegrepp på denna sida för anslutningsoperatör och federationsmedlem. |
| Tillitsankartjänst | Den tekniska tjänst som utgör tillitsankaret i en miljö. Det är tjänsten som signerar, men beslut om tillit fattas av federationsoperatören. |
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).
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.
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:
Exakta funktioner och krav för respektive tjänst beskrivs i tillämpliga tjänste- och kravbeskrivningar (Här länkar vi till krav?)
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:
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.
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.
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
Vilka kontroller och förmågor som ska verifieras framgår av krav för respektive miljö i kapitel 4.
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.
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.
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.
För att använda Sandbox gäller detta för samtliga aktörer:
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.
Federationsmedlemmen kan använda Sandbox och för att prova och verifiera sin egna implementation.
Verifieringen kan exempelvis omfatta:
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:
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.
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:
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.
För att få börja nyttja QA bör följande finnas:
Federationsmedlemmen ska kunna verifiera sin egen förmåga att uppfylla federationens krav.
Federationsmedlemmen verifiering bör omfatta:
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:
QA ska avslutas med ett tydligt ställningstagande: godkänd för produktion, godkänd med åtgärder eller inte godkänd.
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:
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.
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.
För att få börja nyttja produktion krävs följande:
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.
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:
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:
Det bör därför verifieras att:
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.
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:
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.
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