Versions Compared

Key

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

...

POC implementerar 2.1 enligt inter-domain-calls.md och SSO enligt authn-authz-patterns.md. Tanken är att kunna utöka POC i ett andra steg till att implementera 2.2 (inter-domain-calls) och eventuellt växling av SAML-intyg (authn-authz-patterns). 

draw.io Diagram
bordertruefalse
diagramNamepoc-apoc1
simpleViewerfalse
width
linksauto
tbstyletopinline
lboxtrue
diagramWidth561
height161
revision1

...

Användaren loggar in i System. Detta sker genom en legitimationstjänst (SAML-IDP) och resulterar i att användaren har en inloggningssession i System.

draw.io Diagram
bordertruefalse
diagramNamepoc-a steg 1poc2
simpleViewerfalse
width
linksauto
tbstyletopinline
lboxtrue
diagramWidth561
height201
revision1

System består av två komponenter, dels en Webbapplikation (Quarkus) och dels en Keycloak-instans som agerar SAML-SP mot SAML-IDP. Webbapp använder Oauth authorization code-flow mot Keycloak. 

draw.io Diagram
bordertruefalse
diagramNamepoc-2poc3
simpleViewerfalse
width
linksauto
tbstyletopinline
lboxtrue
diagramWidth323
height181
revision1

...

Någon gång efter inloggning utför användaren något i System som föranleder att API-anrop mot API (i organisation B) behöver utföras. För att göra detta behöver först ett underlag genereras (som kan användas i steg 3 för att begära åtkomstintyg). Detta underlag (signerad JWT) skapas genom att System utför begäran mot lokal auktorisationstjänst (AS-A) som får en uppfattning om användaren genom ett SSO-flöde till SAML-IDP. 

draw.io Diagram
bordertruefalse
diagramNamepoc-a steg 2poc4
simpleViewerfalse
width
linksauto
tbstyletopinline
lboxtrue
diagramWidth561
height201
revision1

Detaljerad beskrivning av interaktion med AS-A. 

draw.io Diagram
bordertruefalse
diagramNamepoc-3poc5
simpleViewerfalse
width
linksauto
tbstyletopinline
lboxtrue
diagramWidth242241
height182181
revision1

  1. Användare utför något i System som föranleder API-anrop till API i organisation B (trycker på en knapp/länk). Detta kan ske direkt efter inloggning eller efter att en viss tid passerat.
  2. System startar code flow mot AS-A (en instans av Keycloak) och anger scope ("refapi") som gäller för kommande API-anrop. Detta vidarebefodrar (redirect) användaren mot Keycloak authorization-endpoint.
  3. Keycloak (i egenskap av SAML-SP / webSSO) initierar SAML AuthnRequest mot SAML-IDP. Detta resulterar i att användare blir vidarebefodrad (redirect) mot SAML-IDP.
  4. (Eventuellt) Om behov av autentisering av användare behövs så presenteras inmatning av kreditiv för användare.
  5. Efter autentisering returneras resultat i form av SAML Response till Keycloak. Keycloak sparar tills vidare Response.
  6. Keycloak returnerar Authz Code till System
  7. System använder Code mot Token-endpoint i Keycloak. Keycloak överför information från Response (AttributeStatement, LOA) och anger andra relevanta claims (sub, aud, iss, scope etc.) till signerad JWT ("user-JWT") och signerar denna med nyckel vars publika del finns i metadata. 
  8. Keycloak returnerar user-JWT till System

...

När underlag finns kan åtkomstbegäran göras mot auktorisationstjänst (AS-B) i organisation B. AS-B använder metadata (som får via Resolver/Batch) för att verifiera underlag och klient som för förfrågan (System). Resultatet är ett åtkomstintyg (access token) som returneras till System.

draw.io Diagram
bordertruefalse
diagramNamepoc-a steg 3poc6
simpleViewerfalse
width
linksauto
tbstyletopinline
lboxtrue
diagramWidth561
height201
revision1

Detaljerad beskrivning av flöde.

draw.io Diagram
bordertruefalse
diagramNamepoc-4poc8
simpleViewerfalse
width
linksauto
tbstyletopinline
lboxtrue
diagramWidth362361
height4241
revision1

  1. System har nu user-JWT från tidigare steg. System tillverkar en "client-JWT" enligt JWT Profile for Client Authentication. Både user-JWT och client-JWT anges i anrop till AS-B enligt RFC7523 samt scope "refapi".
  2. AS-B tar emot förfrågan och verifierar
    1. client-JWT - att identitet (iss) går att slå upp som entitet i metadata
    2. client-JWT - att signatur går kan verifieras genom nyckelmaterial på entitet i metadata
    3. client-JWT - att entitet (iss) har tillitsmärke för "EFI-pilot-tjänsteleverantor" knuten till sig
    4. client-JWT - att klient finns med i whitelist för klienter
    5. user-JWT - att identitet (iss) går att slå upp som entitet i metadata
    6. user-JWT - att signatur kan verifieras genom nyckelmaterial på entitet i metadata
    7. user-JWT - att entitet (iss) har tillitsmärke för "EFI-pilot-identitet" och "EFI-pilot-behorighet" knuten till sig
  3. AS-B tillverkar access token med sig själv som issuer, för över relevant information from user-JWT (samt eventuellt client-JWT) och krypterar denna. AS-B returnerar access token till System

...

System har nu förutsättningar att utföra API-anrop mot API med åtkomstintyg som bärare av säkerhetsinformation. 

draw.io Diagram
bordertruefalse
diagramNamepoc-a steg 4poc9
simpleViewerfalse
width
linksauto
tbstyletopinline
lboxtrue
diagramWidth561
height201
revision1

...