Page History

...

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 sitt metadata.	Verksamhetskriterier Anslutningstjänst registrerad som entitet Tillitsmärkestjänst registrerad som entitet Policy? Teknikkriterier Tillitsankartjänst publicerar Entity Configuration enligt specifikation Tillitsankartjänst publicerar Entity Statement enligt specifikation Tillitsankartjänst Subordinate listing enligt specifikation Policyhantering enligt specifikation	Tillitsankartjänst (Trust Anchor) Digg Internetstiftelsen	OpenID Federation Specification Entity Statement Subordinate-listings Federation-policy Kommande: Ena Infrastructure OIDF Profile	Grund för teknisk tillit i federationen.
FI020 –Metadatapublicering Anslutningstjänst	Validera att Anslutningstjänst publicerar och signerar sitt metadata	Verksamhetskriterier Tjänst (Federationmedlem) registrerad som entitet Teknikkriterier Anslutningstjänst publicerar Entity Configuration enligt specifikation Authority_hint enligt specifikation Anslutningstjänst publicerar Entity Statement enligt specifikation Om underordnad tjänst Anslutningstjänst Subordinate listing enligt specifikation	Anslutningstjänst (Intermediate Entity) Digg Internetstiftelsen	OpenID Federation Specification Entity Statement Subordinate-listings Federation-policy	Möjliggör skalbarhet och delegerad tillit.
FI030 – Metadatavalidering	Kontrollera att trust chain kan byggas korrekt (top-down/bottom-up), signaturer verifieras och metadata returneras komplett.	Verksamhetskriterier Uppslags- och verifieringstjänst (Resolver) registrerad som entitet Ett Resolve-anrop kan göras för vald Tillitsmärkestjänst och valda Tillitsmärken Teknikkriterier Implementerar Resolve-entity enligt OpenID Federation Specification Validerar digitala signaturer och certifikatkedjor enligt specifikationen Tillämpning av definierad federation-policy vid verifiering Endast verifierad metadata returneras till förlitande parter	Uppslags- och verifieringstjänst (Resolver) DiggDigg Internetstiftelsen	OpenID Federation Specification Resolve-entity	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 Tillitsmärke utfärdat till: Klient Auktorisationstjänst(er) API Teknikkriterier Implementerar Trust Mark Issuer Tillitsmärkestjänst implementerad enligt OpenID Federation SpecificationSpecifikationen Publicerar signerade tillitsmärken via definierad endpoint Följer federation-policy för tillitsmärkets typ, innehåll och giltighet	Uppslags- och verifieringstjänst (Resolver) DiggDigg Internetstiftelsen	OpenID Federation Specification Trust-marks	Möjliggör automatiserad kontroll av regelefterlevnad.

...

Användningsfall

Beskrivning

POC Acceptanskriterier

Batch-lösningen är ett pilotval; i full drift används realtidsupplösning via Resolver.

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.

Legitimeringstjänst (IdP – Org A)
System A (System A– Org A)

SAML 2.0, Single Sign-On

ena-oauth2-profile

ena-oauth2-authn-bp

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.
3a. basprofil enligt xx

4. MSCC utför token exchange mot AS-A enligt ena-oauth2-chaining, kap 3.3

4a. basprofil enligt xx

5. Claims i JWT för auth grant följer specifikation poc-attributspec, enligt ...

~~MSCC som klient följer oauth-oauth2-profile i relevanta delar~~
~~AS domän A följer oauth-oauth2-profile i relevanta delar~~

Auktorisationstjänst (Org A) Legitimeringstjänst (IdP – Org A) System A

OIDC/OAuth2 (Access Token, ID Token), SAML SSO

ena-oauth2-profile

ena-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 xx

~~MSCC som klient följer oauth-oauth2-profile i relevanta delar~~

3. AS domän B följer chaining xx

3b. oauth-oauth2-profile i relevanta delar xx

Auktorisationstjänst (Org B) Resursserver (Org B) System A (Org A)

OIDC/OAuth2 Token Exchange, JWT Grants

ena-oauth2-profile

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 xx

3b. basprofil xx

3c. oidf-spec entity type client xx

4. AS-B kan verifiera AS-A mot metadata genom "user assertion"

4a. chaining xx

4b. profil xx

4c. oidf entity typ as xx

5. AS-B kan verifiera att entitet AS-A i metadata även har "Pilotsmärke"

5a. oidf TM xx

6. AS-B kan tolka claims för behörighetsgrundande attribut

6a. "handbok"

Se tabell ovan

oidf-spec OpenID Federation 1.0, Entity Statements, Trust Chains, Trust Marks

ena-oauth2-profile

DS050 - API-anrop Cross Domain

Verksamhetskriterier

1. MCSS MCSS kan göra lyckat API-anrop mot NLL Teknikkriterier

2. MSCC som klient följer oauth-oauth2-profile i relevanta delar

2a. profil xx

3. NLL som Resursserver/API följer oauth-oauth2-profile i relevanta delar

3a. profil xx

4. NLL kan verifiera accesstoken

4a. chaining xx

4b. profil xx

5. NLL kan utvärdera behörighetsroll

5a. "handbok"

ena-oauth2-profile

Testfall Del DS010 - Använda 1: Användare loggar in i MCSS och hämtar NLL-data. Flöde:

Del DS010

Användare loggar in i MCSS
Del DS020 -
1. Användaren utför något som initiera hämtning av information från NLL
  1. okulärt
2. MCSS startar code flow mot AS-A.
  1. DS020-1 Kan vi verifiera detta?
  2. DS020-3 & 3a: kolla MCSS & AS-A loggar , anrop och tokenrequest/response
3. MCSS intygsväxlar mot AS-A
  1. DS020-4 & 4a kolla MCSS-loggar , kolla & AS-A-loggar och req/resp
  2. DS020-2 & DS020-5 kolla token (user jwt)
Del DS030
1. MSCC anropar AS-B
  1. DS030-2 & 2a och DS030-1 kolla MCSS-loggar och AS-B-loggar req/res.
  2. DS030-3 & 3b kolla AS-B-loggar
Negativa testfall av AS-B avseende expiry, granttype, client assertion type, client_id etc testas inte här - ehm kvalitetsäkring av AS-B
Del DS040
1. AS-B verifierar MCSS som klient
  1. DS040-2: anrop accepterat, kolla loggar AS-B
  2. DS040-3: kolla loggar + kolla metadata
  3. DS040-3: ta bort metadata-entitet för MCSS
  4. DS040-3: fel nyckel i entitet för MCSS
  5. DS040-3: fel entitetstyp (ej client) för MCSS
2. AS-B verifierar AS-A
  1. DS040-4: kollar logger + kolla metadata
  2. DS040-4: ta bort metadata-entitet för AS-A
  3. DS040-4: fel nyckel i entitet för AS-A
  4. DS040-4: fel entitetstyp (ej authorization_server) för AS-A
3. AS-B verifierar tillitsmärke
  1. DS040-5 kollar logger + kolla metadata
  2. DS040-5 ta bort tillitsmärke
  3. DS040-5 byt tillitsmärke (ej längre det "pilotmärke" vi förväntar oss)
4. AS-B access token
  1. DS040-6 & 6a & DS040-1 claims finns i accesstoken
Del DS050
1. MCSS för API-anrop mot NLL
  1. DS050-1 lyckat anrop med positivt svar

Page tree

Versions Compared

Old Version 51

New Version 52

Key