Page History

...

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

...

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.

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. 

1. Användaren riktar sin browser mot URL för Webbapp. Webbapp konstaterar att användaren inte är inloggad (avsaknad av session-cookie).
2. Webbapp startar OAuth Authentication code flow mot Keycloak (delkomponent i System) som vidarebefodrar (via redirect, alltså via Användare, visas ej i diagram) användaren mot Keycloak authorization-endpointlogin-sida som också tillhandahålls av Keycloak.
3. Keycloak (i egenskap av SAML-SP) initierar SAML AuthnRequest mot SAML-IDP. Detta resulterar i att användare blir vidarebefodrad (redirect) mot SAML-IDP.sker också genom redirect via Användare som är den som egentligen utför AuthnRequest mot IDP (syns ej i diagram). Slutresultatet är att Användare blir presenterad med inloggningssida hos SAML IDP.
4. Användare autentiserar sig (i denna implementation genom username/password snarare än e-legitimation, av praktiska skäl)(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/SP. Detta sker också via Användare (syns ej i diagram). Keycloak sparar tills vidare Response.
6. Keycloak returnerar Authz Code till Webbapp
7. Webbapp använder Code mot Token-endpoint i Keycloak. Keycloak överför eventuell information till access token. 
8. Keycloak returnerar Access token och användaren är inloggad i Webbapp. Webbapp upprättar session-cookie i webbläsareslutför code flow genom att returnera Authz code och Webbapp använder denna mot token-endpoint (syns ej i diagram). Keycloak tillverkar och returnerar Access token till Webbapp och upprättar inloggningsession för användaren.

Steg 2 - Interaktion med lokal auktorisationstjänst och SSO mot IDP

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. 

Detaljerad beskrivning av interaktion med AS-A. 

1. Användare (inloggad) 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 OAuth Authentication code flow mot AS-A (en instans av Keycloak) och anger scope ("refapi") som gäller för kommande (i steg 3) API-anrop. Detta vidarebefodrar (redirect) användaren mot Keycloak authorization-endpointAS-A som tar emot anropet vidarebefodrar (via redirect, alltså via Användare, visas ej i diagram) användaren mot login-sidan som också tillhandahålls av AS-A.
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. sker också genom redirect via Användare som är den som egentligen utför AuthnRequest mot IDP (syns ej i diagram). Slutresultatet är att Användare blir presenterad med inloggningssida hos SAML IDP.
6. Användare autentiserar sig (i denna implementation genom username/password snarare än e-legitimation, av praktiska skäl.
7. Efter Efter autentisering returneras resultat i form av SAML Response till KeycloakAS-A (SP). Detta sker också via Användare (syns ej i diagram). Keycloak sparar tills vidare Response.
8. Keycloak returnerar Authz Code till System
9. 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
10. AS-A slutför code flow genom att returnera Authz code och Webbapp denna mot token-endpoint (syns ej i diagram). AS-A har nu en session avseende Användare. AS-A tillverkar och signerar JWT (user_JWT). Refresh_token tillverkas också vars giltighetstid speglar den tid
11. Keycloak returnerar user_JWT samt refresh_token till System. 

User_JWT har en giltighetstid som är relativt kort (xx minuter). Refresh_token har en giltighetstid som speglar hur länge förnyelse kan göras. Om förnyelse av user_JWT behöver göras medans giltighet för refreshtoken finns:

1. (Eventuellt) Användare utför åtgärd som kräver giltig user_JWT. Detta kan lika gärna vara något som initieras från internt i System. System upptäcker att giltighet user_JWT har passerats.
2. System initierar token fresh mot AS-A
3. AS-A tillverkar ny user_JWT och signerar denna
4. AS-A returnerar user_JWT

Om refresh inte är möjlig (giltighet passerad), återgår man till det initiala flödet med code flow mot AS-A för att ny autentisering av användaren ska kunna ske mot SAML IDP. 

Steg 3 - Begäran av åtkomstintyg från organisation B

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.

Detaljerad beskrivning av flöde.

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. 

...