...
| 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.
...
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
...
| 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
...