Page History

...

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

...

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

...

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

...