Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • EHM AS-B finns inte i metadata eller ta ned servern
  • Registrera Resolver med Tillitsankartjänst "Sweden Trust",
  • Registrera Anslutningstjänst Internetstiftelsen hos Tillitsankartjänst ST

Teststeg

StegBeskrivningFörväntat resultatUtfallStatus
1Resolva Entitet EHM AS-BEntitet kan inte resolvas

2Registrera Entitet EHM AS-B för till Anslutningstjänst hos Internetstiftelsen (AT-IIS)AT-IIS ger ut Subordinate Statement om EHM AS-B



TA-ST ger ut Subordinate Statement om AT-ISS



3Resolva Entitet EHM AS-BEntitet kan inte resolvas


Testfall - Resolva tillitsmärke - omfattar FI040

...

  • Pilotmärket är definierat i TMI hos IIS
  • EHM AS-B finns i metadata men har inte tillitsmärket "Pilotmärke"

Teststeg

StegBeskrivningFörväntat resultatUtfallStatus
1Resolva Entitet EHM AS-BPilotmärket saknas i entity statement

2

Registrera Pilotmärke för EHM AS-B i TMI hos Internetstiftelsen




3Resolva Entitet EHM AS-BPilotmärket finns i entity statement


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

...

  • EHM AS-B, Appva MCSS, Appva AS-A finns registrerade i metadatat
  • Appva AS-A har Pilotmärket i TMI hos IIS

Teststeg

StegBeskrivningFörväntat resultat / verifieringUtfallStatus
DS010

1Användare loggar in i MCSS
  1. DS010-1 Okulärbesiktning av inloggningsflöde. Titta i MSCC-loggar? Titta i IDP-logg?
  2. DS010-2 Kolla MCSS eller IDP-logg


DS020

1Användaren utför något som initiera hämtning av information från NLL
  1. Okulärt


2MCSS startar code flow mot AS-A
  1. DS020-1 Kan vi verifiera detta? 
  2. DS020-3 & 3a: kolla MCSS & AS-A loggar request/response


3MCSS intygsväxlar mot AS-A
  1. DS020-4 & 4a kolla MCSS-loggar & AS-A-loggar req/resp
  2. DS020-2 & DS020-5 kolla token (user jwt)


DS030

1MSCC 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


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

DS040-6 & 6a & DS040-1 claims finns i accesstoken

DS050

1

MCSS för API-anrop mot NLL

  1. DS050-1 lyckat anrop med positivt svar