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

border	false

diagramName	Ena IAM Pilot FedInfra
simpleViewer	false
width
links	auto
tbstyle	inline
lbox	true
diagramWidth	11911220
height	716736
revision	822

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" federationsträdOIDF-struktur! Dvs det realisaras 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

sitt metadata.

metadata (om sig själv och underordnade)

Verksamhetskriterier

Anslutningstjänst

1. Anslutningstjänst registrerad som entitet

Tillitsmärkestjänst registrerad som entitet

Policy?

Teknikkriterier

2. Policy

2a. Tillitsmärke konfigurerat

2b. Strict/loose policy

- - regler för entity_typ
  - regler för algoritmer

Teknikkriterier

1. Tillitsankartjänst

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

sitt

metadata (om sig själv och underordnade)

Verksamhetskriterier

Tjänst

1. Tjänst (Federationmedlem) registrerad som entitet

Teknikkriterier

Anslutningstjänst

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

Anslutningstjänst (Intermediate Entity)
- Digg
- Internetstiftelsen

OpenID Federation Specification

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

1. Uppslags- och verifieringstjänst (Resolver)

registrerad som entitet

har konfigurerat betrodda Tillitsankartjänster

2. Ett Resolve-anrop kan göras för vald

Tillitsmärkestjänst

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

1. Tillitsmärke utfärdat till:

- Klient
- Auktorisationstjänst(er)
- API

Teknikkriterier

Implementerar Trust Mark Issuer

2. Tillitsmärkestjänst implementerad enligt OpenID Federation

Specification

Specifikationen

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

Digg

- Digg
- Internetstiftelsen

OpenID Federation Specification

Trust-marks

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

- 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

Steg	Beskrivning	Förväntat resultat
1	Uppslag av Entitet EHM AS-B	Entitet kan inte verifieras
2	Registrera 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
3	Uppslag av Entitet EHM AS-B	Entitet 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

Steg	Beskrivning	Förväntat resultat
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-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...	Tillitsankartjänst (Trust Anchor) Digg	OpenID Federation Specification Entity Statement Subordinate-listings Federation-policy 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

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

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

~~4a. basprofil enligt~~ xx~~kap x~~

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

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

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 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 xx5.3 (client credentials grant)

~~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 xx3.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 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 xx3.4.1

3b. basprofil xx5.3 (client credentials)

3c. oidf-spec entity type client xx5.1.5

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

4a. chaining xx3.4.1

~~4b. profil xx~~

4c. oidf entity typ as xxtype OIDF 5.1.4

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

5a. oidf TM xx7

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

...

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

Steg	Beskrivning	Förväntat resultat / verifiering	Utfall	Status
DS010
1	Användare loggar in i MCSS

okulärt

DS010-1 Okulärbesiktning av inloggningsflöde. Titta i MSCC-loggar?

...

DS010-2 Kolla MCSS

Användaren loggar in i MSCC mha test-IDP i Sambi-trial. Loggar bekräftar inloggning.

1.

Status

colour	Green
title	OK

DS020

1

...

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

...

Okulärt

Användaren öppnar "NLL-flik" i MSCC

1.

Status

colour	Green
title	OK

2

MCSS startar code flow mot AS-A

...

DS020-1 Kan vi verifiera detta?
DS020-3 & 3a: kolla MCSS & AS-A loggar request/response

Request mot authorize-endpoint syns i ASA-logg.

1.

Status

colour	Green
title	OK

2.

Status

colour	Green
title	OK

3

...

~~MCSS intygsväxlar mot AS-A~~

~~DS020-4 & 4a kolla MCSS-loggar~~

...

~~& AS-A-loggar~~

...

~~req/resp~~
~~DS020-2 & DS020-5 kolla token (user jwt)~~

...

Ej med i implementation. Code-flow resulterar i underlag for DS030.

Status

title	n/a

DS030

1

MSCC anropar AS-B

DS030-2 & 2a och DS030-1 kolla MCSS-loggar och AS-B-loggar req/res.
DS030-3 & 3b kolla AS-B-loggar

Kollat loggar på både appva-sidan och ehm-sidan.

1.

Status

colour	Green
title	OK

2.

Status

colour	Green
title	OK

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

DS040-2: anrop accepterat, kolla loggar AS-B
DS040-3: kolla loggar + kolla metadata
DS040-3: ta bort metadata-entitet för MCSS
(Natalie)
DS040-3: fel nyckel i entitet för MCSS
(EHM)
~~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

colour	Green
title	OK

2.

Status

colour	Green
title	OK

3.

Status

colour	Green
title	OK

4.

Status

colour	Green
title	OK

2

AS-B verifierar AS-A

DS040-4: kollar logger + kolla metadata
DS040-4: ta bort metadata-entitet för AS-A
(Stefan)
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

colour	Green
title	OK

2.

Status

colour	Green
title	OK

3.

Status

colour	Green
title	OK

3

AS-B verifierar tillitsmärke

DS040-5 kollar logger + kolla metadata
DS040-5 ta bort tillitsmärke
(Natalie)
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

colour	Green
title	OK

2.

Status

colour	Green
title	OK

3.

Status

colour	Green
title	OK

4

AS-B access token

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

1.

Status

colour	Green
title	OK

DS050

1

MCSS för API-anrop mot NLL

DS050-1 lyckat anrop med positivt svar

1. okulärt

1.

Status

colour	Green
title	OK

...

Page tree

Versions Compared

Old Version 51

New Version Current

Key

Ena IAM - Pilot

Sammanfattning

Användningsfall

Översikt OIDF-struktur

Federationsinfrastruktur

Användningsfall publicering och verifiering

Testfall publicering och verifiering

Användningsfall registering

Testfall registrering

Digital samverkan

Användningsfall

Testfall

Page tree

Page History

Versions Compared

Old Version 51

New Version Current

Key

Ena IAM - Pilot

Sammanfattning

Användningsfall

Översikt OIDF-struktur

Federationsinfrastruktur

Användningsfall publicering och verifiering

Testfall publicering och verifiering

Användningsfall registering

Testfall registrering

Digital samverkan

Användningsfall

Testfall