...
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 |
---|
border | truefalse |
---|
| |
---|
diagramName | poc-apoc1 |
---|
simpleViewer | false |
---|
width | |
---|
links | auto |
---|
tbstyle | topinline |
---|
lbox | true |
---|
diagramWidth | 561 |
---|
height | 161 |
---|
revision | 1 |
---|
|
...
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 |
---|
border | truefalse |
---|
| |
---|
diagramName | poc-a steg 1poc2 |
---|
simpleViewer | false |
---|
width | |
---|
links | auto |
---|
tbstyle | topinline |
---|
lbox | true |
---|
diagramWidth | 561 |
---|
height | 201 |
---|
revision | 1 |
---|
|
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 |
---|
border | truefalse |
---|
| |
---|
diagramName | poc-2poc3 |
---|
simpleViewer | false |
---|
width | |
---|
links | auto |
---|
tbstyle | topinline |
---|
lbox | true |
---|
diagramWidth | 323 |
---|
height | 181 |
---|
revision | 1 |
---|
|
...
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 |
---|
border | truefalse |
---|
| |
---|
diagramName | poc-a steg 2poc4 |
---|
simpleViewer | false |
---|
width | |
---|
links | auto |
---|
tbstyle | topinline |
---|
lbox | true |
---|
diagramWidth | 561 |
---|
height | 201 |
---|
revision | 1 |
---|
|
Detaljerad beskrivning av interaktion med AS-A.
draw.io Diagram |
---|
border | truefalse |
---|
| |
---|
diagramName | poc-3poc5 |
---|
simpleViewer | false |
---|
width | |
---|
links | auto |
---|
tbstyle | topinline |
---|
lbox | true |
---|
diagramWidth | 242241 |
---|
height | 182181 |
---|
revision | 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.
- 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.
- 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.
- (Eventuellt) Om behov av autentisering av användare behövs så presenteras inmatning av kreditiv för användare.
- Efter autentisering returneras resultat i form av SAML Response till Keycloak. Keycloak sparar tills vidare Response.
- Keycloak returnerar Authz Code till System
- 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.
- 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 |
---|
border | truefalse |
---|
| |
---|
diagramName | poc-a steg 3poc6 |
---|
simpleViewer | false |
---|
width | |
---|
links | auto |
---|
tbstyle | topinline |
---|
lbox | true |
---|
diagramWidth | 561 |
---|
height | 201 |
---|
revision | 1 |
---|
|
Detaljerad beskrivning av flöde.
draw.io Diagram |
---|
border | truefalse |
---|
| |
---|
diagramName | poc-4poc8 |
---|
simpleViewer | false |
---|
width | |
---|
links | auto |
---|
tbstyle | topinline |
---|
lbox | true |
---|
diagramWidth | 362361 |
---|
height | 4241 |
---|
revision | 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".
- AS-B tar emot förfrågan och verifierar
- client-JWT - att identitet (iss) går att slå upp som entitet i metadata
- client-JWT - att signatur går kan verifieras genom nyckelmaterial på entitet i metadata
- client-JWT - att entitet (iss) har tillitsmärke för "EFI-pilot-tjänsteleverantor" knuten till sig
- client-JWT - att klient finns med i whitelist för klienter
- user-JWT - att identitet (iss) går att slå upp som entitet i metadata
- user-JWT - att signatur kan verifieras genom nyckelmaterial på entitet i metadata
- user-JWT - att entitet (iss) har tillitsmärke för "EFI-pilot-identitet" och "EFI-pilot-behorighet" knuten till sig
- 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 |
---|
border | truefalse |
---|
| |
---|
diagramName | poc-a steg 4poc9 |
---|
simpleViewer | false |
---|
width | |
---|
links | auto |
---|
tbstyle | topinline |
---|
lbox | true |
---|
diagramWidth | 561 |
---|
height | 201 |
---|
revision | 1 |
---|
|
...