...
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Federationsinfrastruktur
FI-serien (FI010–FI040) beskriver hur federationsinfrastrukturens centrala komponenter tillsammans etablerar den tekniska tilliten i en federation. I dessa användningsfall visas hur en Tillitsankartjänst publicerar och signerar metadata, hur en Anslutningstjänst kan agera mellanled och applicera lokala policies, hur en Uppslags- och verifieringstjänst bygger och validerar hela tillitskedjan, samt hur en Tillitsmärkestjänst utfärdar och verifierar tillitsmärken som styrker efterlevnad av tillitsskapande krav. Tillsammans utgör de grunden för att federationens parter ska kunna lita på varandra och möjliggör att den digitala samverkan i DS-serien kan realiseras på ett säkert och verifierbart sätt.
...
- Ett konkret förslag till struktur för en "initial" OIDF-struktur! Dvs det realiseras i gemensamt sammankopplade sandbox-miljöer
- Verifiera användningsfallen
Användningsfall publicering och verifiering
| Användningsfall | Beskrivning | POC Acceptanskriterier | Ingående komponenter (ansvarig aktör) | Lösningsmönster & Specifikationer | Kommentar |
|---|---|---|---|---|---|
| FI010 – Metadatapublicering Tillitsankartjänst | En Tillitsankartjänst (Trust Anchor) publicerar och signerar metadata (om sig själv och underordnade) | Verksamhetskriterier 1. Anslutningstjänst registrerad som entitet 2. Policy 2a. Tillitsmärke konfigurerat 2b. Strict/loose policy
Teknikkriterier 1. Tillitsankartjänst publicerar Entity Configuration enligt specifikation 2. Tillitsankartjänst publicerar Entity Statement enligt specifikation 3. Tillitsankartjänst Subordinate listing enligt specifikation 4. Policyhantering enligt specifikation
|
| OpenID Federation Specification Kommande: Ena Infrastructure OIDF Profile | Grund för teknisk tillit i federationen. |
| FI020 –Metadatapublicering Anslutningstjänst | Validera att Anslutningstjänst (Intermediate Entity) publicerar och signerar metadata (om sig själv och underordnade) | Verksamhetskriterier 1. Tjänst (Federationmedlem) registrerad som entitet Teknikkriterier 1. Anslutningstjänst publicerar Entity Configuration enligt specifikation
2. Anslutningstjänst publicerar Entity Statement enligt specifikation
3. Anslutningstjänst Subordinate listing enligt specifikation |
| Möjliggör skalbarhet och delegerad tillit. | |
FI030 – Metadatavalidering | Kontrollera att trust chain kan byggas korrekt (top-down), signaturer verifieras och metadata returneras komplett. | Verksamhetskriterier 1. Uppslags- och verifieringstjänst (Resolver) har konfigurerat betrodda Tillitsankartjänster 2. Ett Resolve-anrop kan göras för vald Tillitsankartjänst och valda Tillitsmärken Teknikkriterier Implementerar Resolve-entity enligt
2. Tillämpning av definierad federation-policy vid verifiering
|
| Avlastar digitala tjänster från komplex verifieringslogik. | |
| FI040 – Tillitsmärkeshantering | Säkerställa att tillitsmärken är signerade, giltiga och verifierbara enligt policy. | Verksamhetskriterier 1. Tillitsmärke utfärdat till:
Teknikkriterier 2. Tillitsmärkestjänst implementerad enligt OpenID Federation Specifikationen
|
| Möjliggör automatiserad kontroll av regelefterlevnad. | |
| FI050 - Metadatapublicering | Validera att anslutna komponenter publicerar och signerar sitt metadata | Verksamhetskriterier 1. Komponent (för Federationmedlem) registrerad som entitet Teknikkriterier 2. Komponent publicerar Entity Configuration enligt specifikation
|
|
Testfall publicering och verifiering
Testfall 1 - Uppslag & verifiering av entitet - omfattar FI030 men fungerar enbart om FI010, FI020 och FI050 är gjort
...
| Steg | Beskrivning | Förväntat resultat | Utfall | Status | |||
|---|---|---|---|---|---|---|---|
| 1 | Uppslag av Entitet EHM AS-B | Pilotmärket saknas i uppslags-svaret | |||||
| 2 | Registrera Pilotmärke för EHM AS-B i TMI hos Internetstiftelsen | 3 | Uppslag av Entitet EHM AS-B | Pilotmärket finns i uppslags-svaretför EHM AS-B i TMI hos Internetstiftelsen | |||
| 3 | Uppslag av Entitet EHM AS-B | Pilotmärket finns i uppslags-svaret |
Användningsfall registering
| Användningsfall | Beskrivning | POC Acceptanskriterier | Ingående komponenter (ansvarig aktör) | Lösningsmönster & Specifikationer | Kommentar |
|---|---|---|---|---|---|
| RA10 – Konfiguration av Tillitsankartjänst | En Tillitsankartjänst (Trust Anchor) konfigurerad för att etablera ett federationskontext | Verksamhetskriterier 1. Ans... Teknikkriterier 1. Reg... |
| OpenID Federation Specification Kommande: Ena Infrastructure OIDF Profile | Grund för teknisk tillit i federationen. |
RA20 - Konfiguration av Anslutningstjänst | |||||
RA30 - Konfiguration av Tillitsmärkestjänst | |||||
RA40 - Anslutning till överordnad (Anslutningstjänst/Tillitsankartjänst) | |||||
RA50 - Konfiguration av Uppslags och verifieringstjänst |
Testfall registrering
Digital samverkan
DS-serien (DS001–DS004) demonstrerar den praktiska digitala samverkan över organisationsgränser, där federationsinfrastrukturen används i faktiska åtkomstflöden. Användningsfallen visar hur en användare loggar in i ett system och etablerar en session, hur lokala auktorisationstjänster tillämpar policies och återanvänder inloggningar via SSO, hur åtkomstbegäran kan riktas mot en annan organisation och besvaras med intyg, samt hur metadata för legitimering och auktorisation hanteras och verifieras via federationsinfrastrukturen. Tillsammans visar dessa flöden hur federativ tillit omsätts i säker åtkomst och informationsutbyte mellan organisationer
...
| Kort-namn | Beskrivning |
|---|---|
| authn-authz-patterns | "Mönster för autentisering och auktorisation" Övergripande beskrivning av mönster för autentisering och auktorisation. Konceptuell, ej normativ. |
| inter-domain-calls | "API-anrop över organisationsgränser" Övergripande beskrivning av mönster för anrop över organisationsgränser. Konceptuell, ej normativ. |
| ena-oauth2-authn-bp | "Ena OAuth 2.0 User Authentication Best Practises" Best practises för integration av befintlig inloggningslösning med OAuth 2.0. Konceptuell, ej normativ. |
| ena-oauth2-profile | "Ena OAuth 2.0 Interoperability Profile" Ena Basprofil för användning av OAuth 2.0 i Ena-sammanhang. Grundläggande specifikation för all tillämpning av OAuth där den förekommer. Normativ. |
| ena-oauth2-chaining | "Ena OAuth 2.0 Token Exchange Profile for Chaining Identity and Authorization" Enaprofil för token exchange och auktorisation över organisationsgränser. |
| oidf-spec | "OpenID Federation 1.0 - draft 43" |
| poc-attributspec | "POC attributspecifikation vård/hälsa" En specifikation som beskriver claims för att bära behörighetsgrundande information för användning i POC/Pilot. OBS - Behöver tas fram! |
Användningsfall
| Användningsfall | Beskrivning | POC Acceptanskriterier
| Ingående komponenter (ansvarig aktör) | Lösningsmönster & Specifikationer | Kommentar | |
|---|---|---|---|---|---|---|
| DS010 – Inloggning i system | En användare loggar in i System A via en legitimeringstjänst (SAML IdP). Resultatet är en aktiv inloggningssession i System A | Verksamhetskriterier 1. Användare är inloggad i systemet 2. Inloggning av användare sker enligt / mha Sambi och Sambis tekniska ramverk Teknikkriterier Övrigt 3. Kandidat: De delar i inloggningslösning som använder OAuth följer ena-oauth2-profile. |
| SAML 2.0, Single Sign-On | Grundförutsättning för federativ åtkomst. | |
| DS020 – Lokal auktorisation | Klient interagerar med en lokal auktorisationstjänst för att fastställa användarens behörigheter. SSO återanvänder sessionen mot IdP för andra system. | Verifiera att lokal auktorisation fungerar och att SSO-sessionen kan återanvändas. Verksamhetskriterier 1. AS i Domän A ("AS-A") har en säkerställd uppfattning om användaren 2. MCSS har ett underlag i form av en signerad JWT med rätt innehåll som underlag för åtkomstbegäran mot org B Teknikkriterier 3. MCSS initierar Auth grant w. code enligt ena-oauth2-authn-bp, kap 2.2 eller 2.3. 4. MSCC utför token exchange mot AS-A enligt ena-oauth2-chaining, kap 3.3 5. Claims i JWT för auth grant följer specifikation poc-attributspec, enligt 3.3.4 |
| OIDC/OAuth2 (Access Token, ID Token), SAML SSO ena-oauth2-profileena-oauth2-chaining | Möjliggör lokal policytillämpning och SSO-flöde. | |
| DS030 – Åtkomstbegäran till annan organisation | System A begär åtkomstintyg från Organisation B:s auktorisationstjänst för att få åtkomst till resurs i B:s miljö. | Kontrollera att Organisation B:s auktorisationstjänst kan utfärda och returnera giltigt intyg som System A kan validera. Verksamhetskriterier 1. AS-B kan ta emot och tolka anrop om auth grant Teknikkriterier 2. MCSS utför authorization grant mot AS i domän B ("AS-B") enligt ena-oauth2-chaining, kap 3.4 2a. profil 5.3 (client credentials grant)
3. AS domän B följer chaining xx 3b. oauth-oauth2-profile i relevanta delar 3.4.2 |
| OIDC/OAuth2 Token Exchange, JWT Grants ena-oauth2-chaining poc-attributspec | Möjliggör system-till-system-samverkan över organisationsgränser. | |
| DS040 – Metadatahantering via federationsinfrastruktur | Metadata för IdP, RP och auktorisationstjänster hanteras via OIDF-federationskomponenter. | Säkerställa att metadata kan hämtas, verifieras och cache:as via Resolver, och att trust chain kan valideras till Tillitsankaren. Verksamhetskriterier 1. MCSS har access token att använda Teknikkriterier 2. AS domän A som klient till AS-B följer oauth-oauth2-profile i relevanta delar 2a. profil xx 3. AS-B kan verifiera klient (MCSS) mot metadata genom client_assertion 3a. chaining 3.4.1 3b. basprofil 5.3 (client credentials) 3c. oidf-spec entity type client 5.1.5 4. AS-B kan verifiera AS-A mot metadata genom "user assertion" 4a. chaining 3.4.1
4c. oidf entity type OIDF 5.1.4 5. AS-B kan verifiera att entitet AS-A i metadata även har "Pilotsmärke" 5a. oidf TM 7 6. AS-B kan tolka claims för behörighetsgrundande attribut 6a. "handbok" |
| oidf-spec OpenID Federation 1.0, Entity Statements, Trust Chains, Trust Marks ena-oauth2-profile | ||
| DS050 - API-anrop Cross Domain | Verksamhetskriterier 1. MCSS kan göra lyckat API-anrop mot NLL | ena-oauth2-profile |
Testfall
Testfall 1: Användare loggar in i MCSS och hämtar NLL-data
...
| Steg | Beskrivning | Förväntat resultat / verifiering | Utfall | Status | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| DS010 | ||||||||||||||||||||||||||||
| 1 | Användare loggar in i MCSS |
| Användaren loggar in i MSCC mha test-IDP i Sambi-trial. Loggar bekräftar inloggning. | 1.
| ||||||||||||||||||||||||
| DS020 | ||||||||||||||||||||||||||||
| 1 | Användaren utför något som initiera hämtning av information från NLL |
| Användaren öppnar "NLL-flik" i MSCC | 1.
| ||||||||||||||||||||||||
| 2 | MCSS startar code flow mot AS-A |
| Request mot authorize-endpoint syns i ASA-logg. | 1.
2.
| ||||||||||||||||||||||||
| 3 |
| Ej med i implementation. Code-flow resulterar i underlag for DS030. |
| |||||||||||||||||||||||||
| DS030 | ||||||||||||||||||||||||||||
| 1 | MSCC anropar AS-B |
| Kollat loggar på både appva-sidan och ehm-sidan. | 1.
2.
| ||||||||||||||||||||||||
| 2 | Negativa testfall av AS-B avseende expiry, granttype, client assertion type, client_id etc testas inte här - ehm kvalitetsäkring av AS-B | |||||||||||||||||||||||||||
| DS040 | ||||||||||||||||||||||||||||
| 1 | AS-B verifierar MCSS som klient |
| 1+2. Kollat loggar på både appva-sidan och ehm-sidan. 3. MCSS som entitet borta ur metadata. Cache tömd + kör om batch. AS-B returnerar invalid client. 4. Metadata från batch manipulerad. verifieringsnyckel gjord invalid genom att tillföra skräptecken i nyckel. Felmeddelande invalid client / invalid signature | 1.
2.
3.
4.
| ||||||||||||||||||||||||
| 2 | AS-B verifierar AS-A |
| 1. Kollat logar 2. ASA som entitet borta ur metadata. Cache tömd + kör om batch. AS B returnerar. Felmeddelande invalid grant / no metadata found 3. Metadata manipulerat för AS-B på Appvas sida. verifieringsnyckel gjord invalid. Felmeddelande Invalid grant / invalid signature | 1.
2.
3.
| ||||||||||||||||||||||||
| 3 | AS-B verifierar tillitsmärke |
| 1. Kollat logar 2. Tillitsmärke bortplockat ur ASA-metadata. Invalid grant / Trustmark not found or not trusted. 3. Manipulerar AS-Bs "whitelist" för vilka märken vi valider mot. Ändra identifierare på "pilotmärket". Felmeddelande Felmeddelande Invalid grant / invalid signature | 1.
2.
3.
| ||||||||||||||||||||||||
| 4 | AS-B access token | DS040-6 & 6a & DS040-1 claims finns i accesstoken | 1. | 1.
| ||||||||||||||||||||||||
| DS050 | ||||||||||||||||||||||||||||
| 1 | MCSS för API-anrop mot NLL |
| 1. okulärt | 1.
| ||||||||||||||||||||||||
...