Versions Compared

Old Version 37

changes.mady.by.user Martin Solberg

Saved on

compared with

New Version Current

changes.mady.by.user Henric Norlander

Saved on

Key

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

Table of Contents

Ena IAM - Pilot

Sammanfattning

Denna Proof of Concept (POC) syftar till att praktiskt testa och demonstrera hur en federativ infrastruktur enligt OpenID Federation-modellen kan realiseras i Ena för digital samverkan mellan organisationer. Fokus ligger på att visa hur en användare i Organisation A genom sitt system kan anropa ett skyddat API i Organisation B, där säkerhets- och tillitsinformation förmedlas via federationsinfrastrukturen (FI-serien) och används i faktiska samverkansflöden (DS-serien).

...

Tillsammans visar dessa användningsfall hela kedjan: från att etablera federativ tillit via FI-serien till att praktiskt realisera digital samverkan mellan två organisationer via DS-serien.

Användningsfall

Översikt OIDF-struktur

draw.io Diagram
borderfalse
diagramNameEna IAM Pilot FedInfra
simpleViewerfalse
width
linksauto
tbstyleinline
lboxtrue
diagramWidth11911220
height711736
revision722

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.

...

  1. Ett konkret förslag till struktur för en "initial" federationsträdOIDF-struktur! Dvs det realisaras realiseras i gemensamt sammankopplade sandbox-miljöer
  2. Verifiera användningsfallen

...

Användningsfall publicering och verifiering

AnvändningsfallBeskrivningPOC
-kriterier
AcceptanskriterierIngående komponenter (ansvarig aktör)Lösningsmönster & SpecifikationerKommentar
FI010 – Metadatapublicering
Tillitsankare
TillitsankartjänstEn Tillitsankartjänst (Trust Anchor) publicerar och signerar
sitt federation metadata statement.Säkerställa att metadata kan publiceras, distribueras och signaturen verifieras av andra parter.
metadata (om sig själv och underordnade)

Verksamhetskriterier

1. Anslutningstjänst registrerad som entitet

2. Policy

  2a. Tillitsmärke konfigurerat

  2b. Strict/loose policy 

      •  regler för entity_typ
      •  regler för algoritmer

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

    •  Behöver detaljeras
  • Tillitsankartjänst (Trust Anchor)
    • Digg
    • Internetstiftelsen

OpenID Federation

1.0, Entity Statements (Entity Configuration, Trust Chain)

Specification

Kommande: Ena Infrastructure OIDF Profile


Grund för teknisk tillit i federationen.
FI020 –Metadatapublicering Anslutningstjänst
En
Validera att Anslutningstjänst (Intermediate Entity)
agerar länk mellan Tillitsankartjänst och underordnade entiteter (OP, RP, API:er). Den kan även applicera lokala policies.
  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

    •  Authority_hint enligt specifikation

2. Anslutningstjänst publicerar Entity Statement enligt specifikation

    •  Om underordnad tjänst

3. Anslutningstjänst Subordinate listing enligt specifikation

Validera att Anslutningstjänst korrekt kan hämta metadata från Tillitsankartjänst, applicera policy och vidareförmedla metadata.

  • Anslutningstjänst (Intermediate Entity)
    • Digg
    • Internetstiftelsen

OpenID Federation

1.0, Policy claims, Authority Hints

Specification

Möjliggör skalbarhet och delegerad tillit.

FI030 – Metadatavalidering

En Uppslags- och verifieringstjänst (Resolver) kan hämta och verifiera metadata för en entitet genom att bygga en trust chain från Tillitsankartjänsten.

Kontrollera att trust chain kan byggas korrekt (top-down
/bottom-up
), 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
1. OpenID Federation Specification

    •  Validerar digitala signaturer och certifikatkedjor enligt specifikationen

2. Tillämpning av definierad federation-policy vid verifiering

    •  Endast verifierad metadata returneras till förlitande parter
  • Uppslags- och verifieringstjänst (Resolver)
     Digg
      • Digg
      • Internetstiftelsen

    OpenID Federation

    1.0, Authority Hints, Trust Chain Resolution

    Specification

    		Avlastar digitala tjänster från komplex verifieringslogik.
    FI040 – Tillitsmärkeshantering
    En Tillitsmärkestjänst (Trust Mark Issuer) utfärdar tillitsmärken som styrker att en entitet uppfyller definierade tillitsskapande krav.
    Säkerställa att tillitsmärken är signerade, giltiga och verifierbara enligt policy.

    Verksamhetskriterier

    1. Tillitsmärke utfärdat till:

      •  Klient
      •  Auktorisationstjänst(er)
      •  API

    Teknikkriterier

    2. Tillitsmärkestjänst implementerad enligt OpenID Federation Specifikationen

      •  

        Publicerar signerade tillitsmärken

      •  

        Följer federation-policy för tillitsmärkets typ, innehåll och giltighet

    • Uppslags- och verifieringstjänst (
    Trust Mark Issuer) 
    • Tillitsoperatör
    OpenID Federation 1.0, Trust Marks (JWT), PolicykravBygger policybaserad tillit inom federationen.
    • Resolver)
      • Digg
      • Internetstiftelsen

    OpenID Federation Specification

    		Möjliggör automatiserad kontroll av regelefterlevnad.
    FI050 - MetadatapubliceringValidera 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

      •  Authority_hint enligt specifikation
      •  Trust_marks enligt specifikation
    • Klient
      • Appva
    • Auktorisationstjänster(er)
      • Digg
      • Internetstiftelsen
    • Resource Server (API)

    OpenID Federation Specification



    Testfall publicering och verifiering

    Testfall 1 - Uppslag & verifiering av entitet - omfattar FI030 men fungerar enbart om FI010, FI020 och FI050 är gjort

    Förutsättningar

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

    Teststeg

    StegBeskrivningFörväntat resultatUtfallStatus
    1Uppslag av Entitet EHM AS-BEntitet kan inte verifieras

    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



    3Uppslag av Entitet EHM AS-BEntitet kan verifieras


    Testfall 2 - Uppslag & verifiering av entitet med tillitsmärke - omfattar FI040

    Förutsättningar

    • 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
    1Uppslag av Entitet EHM AS-BPilotmärket saknas i uppslags-svaret

    2

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




    3Uppslag av Entitet EHM AS-BPilotmärket finns i uppslags-svaret

    Användningsfall registering

    AnvändningsfallBeskrivningPOC AcceptanskriterierIngående komponenter (ansvarig aktör)Lösningsmönster & SpecifikationerKommentar
    RA10 – Konfiguration av TillitsankartjänstEn Tillitsankartjänst (Trust Anchor) konfigurerad för att etablera ett federationskontext

    Verksamhetskriterier

    1. Ans...

    Teknikkriterier

    1. Reg...

      • Tillitsankartjänst (Trust Anchor)
      • Digg

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

    AnvndningsfallAnvändningsfallBeskrivningPOC 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 & SpecifikationerKommentar
    DS010 – Inloggning i systemEn 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

    Kriterier verksamhet

     Användare

    är inloggad i systemetKriterier specifikation

     Kandidat:

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

    Kriterier verksamhet

     

    Verksamhetskriterier

    1. AS

    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 BKriterier specifikation

      MCSS


    Teknikkriterier

    3. MCSS initierar Auth grant w. code enligt ena-oauth2-authn-bp, kap 2.2 eller 2.3.
      3a. basprofil enligt 5.1

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

      4a. basprofil enligt kap x

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

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

    , enligt 3.3.4

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

    Kriterier verksamhet

     AS


    Verksamhetskriterier

    1. AS-B kan ta emot och tolka anrop om auth grant


    Kriterier specifikationTeknikkriterier

     

    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)

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

    3. AS domän

    B följer

    B följer chaining xx

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

    • 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 federationsinfrastrukturMetadata 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-

    B

    A mot metadata genom "user assertion"

      4a. chaining 3.4.1

      4b. profil xx

      4c. oidf entity type OIDF 5.1.4

    5. AS-B kan verifiera att entitet AS-

    B

    A i metadata även har "Pilotsmärke"

      5a. oidf TM 7

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

    attribut 
    •  AS-B kan utfärda accesstoken 

    Kriterier specifikation

    •  AS domän B som klient följer oauth-oauth2-profile i relevanta delar
    •  Resolver följer oauth-oauth2-profile i relevanta delar

    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 kan göra lyckat API-anrop mot

    NLL med accesstoken
    •  NLL kan verifiera accesstoken
    •  NLL kan utvärdera behörighetsroll
    •  MCSS får svar på API-fråga från NLL

    Kriterier specifikation

    •  MSCC som klient följer oauth-oauth2-profile i relevanta delar
    •  NLL som Resursserver/API följer oauth-oauth2-profile i relevanta delar
    ena-oauth2-profile

    NLL 


    		ena-oauth2-profile


    Testfall

    Testfall 1: Användare loggar in i MCSS och hämtar NLL-data

    Förutsättningar

    • 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? 
    2. DS010-2 Kolla MCSS
    		Användaren loggar in i MSCC mha test-IDP i Sambi-trial. Loggar bekräftar inloggning. 

    1.

    Status
    colourGreen
    titleOK

    DS020

    1Användaren utför något som initiera hämtning av information från NLL
    1. Okulärt
    		Användaren öppnar "NLL-flik" i MSCC

    1. 

    Status
    colourGreen
    titleOK

    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
    		Request mot authorize-endpoint syns i ASA-logg. 

    1.

    Status
    colourGreen
    titleOK

    2.

    Status
    colourGreen
    titleOK

    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)
    		Ej med i implementation. Code-flow resulterar i underlag for DS030.

    Status
    titlen/a

    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
    		Kollat loggar på både appva-sidan och ehm-sidan.

    1. 

    Status
    colourGreen
    titleOK

    2.

    Status
    colourGreen
    titleOK

    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
      (Natalie)
    4. DS040-3: fel nyckel i entitet för MCSS
      (EHM)
    5. DS040-3: fel entitetstyp (ej client) för MCSS


    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.

    Status
    colourGreen
    titleOK

    2.

    Status
    colourGreen
    titleOK

    3.

    Status
    colourGreen
    titleOK

    4.

    Status
    colourGreen
    titleOK

    2

    AS-B verifierar AS-A

    1. DS040-4: kollar logger + kolla metadata
    2. DS040-4: ta bort metadata-entitet för AS-A
      (Stefan)
    3. DS040-4: fel nyckel i entitet för AS-A
      (EHM)

    DS040-4: fel entitetstyp (ej authorization_server) för 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.

    Status
    colourGreen
    titleOK

    2.

    Status
    colourGreen
    titleOK

    3.

    Status
    colourGreen
    titleOK

    3

    AS-B verifierar tillitsmärke

    1. DS040-5 kollar logger + kolla metadata
    2. DS040-5 ta bort tillitsmärke
      (Natalie)
    3. DS040-5 byt tillitsmärke (ej längre det "pilotmärke" vi förväntar oss)
      (EHM)

    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 Invalid grant / invalid signature

    1.

    Status
    colourGreen
    titleOK

    2.

    Status
    colourGreen
    titleOK

    3.

    Status
    colourGreen
    titleOK

    4

    AS-B access token

    		DS040-6 & 6a & DS040-1 claims finns i accesstoken1. 

    1.

    Status
    colourGreen
    titleOK

    DS050

    1

    MCSS för API-anrop mot NLL

    1. DS050-1 lyckat anrop med positivt svar
    		1. okulärt 

    1.

    Status
    colourGreen
    titleOK