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 login-sida som också tillhandahålls av Keycloak.
3. Keycloak (i egenskap av SAML-SP) initierar SAML AuthnRequest mot SAML-IDP. Detta 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).
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 slutfö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. AS-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) initierar SAML AuthnRequest mot SAML-IDP. Detta 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.
5. Efter autentisering returneras resultat i form av SAML Response till AS-A (SP). Detta sker också via Användare (syns ej i diagram). Keycloak sparar tills vidare Response.
6. 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
7. 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

...