Terminaison de la session STS-PEP

Pour les applications en dehors des réseaux de l'administration fédérale, seul le scénario de terminaison de session par déconnexion est possible, car l'STS-PEP n'a pas la possibilité d'informer les participants de la session SSO sans qu'une déconnexion unique SAML ait été déclenchée par l'utilisateur.

Terminaison de la session des applications par logout avec STS-PEPs
La séquence suivante explique le processus de fin de session pour les applications qui ne sont pas hébergées derrière un STS-PEP mais ailleurs (réseaux fédéral, Cloud). Comme ces applications n'utilisent pas l'STS-PEP comme porte d'entrée pour toutes les connexions entre le navigateur web et l'application, l'STS-PEP ne peut pas être le maître de toutes les sessions. Cependant, en tant que SAML FI du point de vue des applications, il est le seul à connaître tous les fournisseurs de services utilisés dans la session SSO et à pouvoir les informer de la fin d'une session.

La situation de départ est une session existante du navigateur de l'utilisateur avec le STS-PEP. Dans la session SSO, l'application A et l'application B ont été utilisées par l'utilisateur. Les deux applications ont ensuite envoyé chacune une SAML AuthnRequest au STS-PEP et ont reçu une SAML Response de ce dernier.

: Terminaison de la session par logout pour les applications en dehors des réseaux de l'administration fédérale

L'utilisateur envoie une requête HTTP à l'URI de déconnexion de l'application A.
L'application A crée une demande de déconnexion SAML signée à l'attention de l'STS-PEP. Elle intègre la SAML LogoutRequest dans un formulaire HTML auto-transmis et l'envoie comme réponse HTTP au navigateur web.
Le navigateur Web envoie la demande de déconnexion par HTTP POST à l'URL de déconnexion unique du STS-PEP.
L'STS-PEP en tant qu'FI vérifie la signature de la demande de déconnexion SAML et recherche la session SSO correspondante. Il établit une liste de tous les fournisseurs de services à informer de la déconnexion. L'STS-PEP crée une demande de déconnexion SAML signée à l'intention de l'application B.
L'STS-PEP transmet la demande de déconnexion SAML au navigateur Web au moyen d'un formulaire HTML auto-transmis dans la réponse HTTP.
Le navigateur Web envoie la demande de déconnexion par HTTP POST à l'URL SingleLogout Location de l'application B.
L'application B vérifie la SAML LogoutRequest, identifie la session et génère une SAML LogoutResponse signée. La session de l'application B est terminée.
La LogoutResponse est transmise au navigateur web au moyen d'un formulaire HTML auto-transmis dans la réponse HTTP.
Le navigateur Web envoie la LogoutResponse à l'STS-PEP par HTTP POST.
Le STS-PEP vérifie la LogoutResponse. Si d'autres applications ont été utilisées dans la session SSO, elles sont informées de la même manière de la fin de la session. Si l'application B était la dernière application à ne pas avoir déclenché le Single-Logout SAML, l'STS-PEP crée une SAML Logout Response signée à l'attention de l'application A.
La LogoutResponse est intégrée dans un formulaire HTML auto-transmis et envoyée au navigateur de l'utilisateur dans la réponse HTTP.
Le navigateur Web envoie la LogoutResponse à l'application A par HTTP POST.
L'application A vérifie la LogoutResponse et met fin à la session de l'utilisateur.
L'application A envoie au navigateur web de l'utilisateur dans la réponse HTTP la confirmation que le logout a été effectué et que la session SSO a été terminée.

Terminaison de la session par inactivité de la session

Une autre possibilité pour laquelle la session de l'utilisateur est invalidée et terminée sur le STS-PEP est une inactivité prolongée sur la session. La suppression des sessions inactives a lieu d'une part pour des raisons de sécurité et d'autre part pour libérer les ressources système non nécessaires.

La terminisation de la session initiée par STS-PEP en raison d'une inactivité prolongée de la session est décrite dans la procédure suivante. Comme la déconnexion n'a pas été déclenchée par une request de l'utilisateur, aucune information ne peut être affichée à l'utilisateur sur la déconnexion qui a eu lieu. Si l'utilisateur envoie à nouveau une requête à STS-PEP après la fin de la session sur STS-PEP en raison d'une inactivité trop longue, une nouvelle session est lancée avec le navigateur web de l'utilisateur.

: Terminaison de session pour cause d'inactivité de la session

Le navigateur Web envoie une requête HTTP pour l'application A à l'STS-PEP dans la session en cours.
L'STS-PEP envoie la requête HTTP à l'application A dans la session en cours.
L'application A envoie la réponse HTTP à l'STS-PEP.
L'STS-PEP envoie la réponse au navigateur Web.
Le navigateur Web envoie une requête HTTP pour l'application B au STS-PEP dans la session en cours.
L'STS-PEP envoie la requête HTTP à l'application B dans la session en cours.
L'application B envoie la réponse HTTP à l'STS-PEP.
L'STS-PEP envoie la réponse HTTP au navigateur Web.
Après l'expiration de l'intervalle d'inactivité défini sur le STS-PEP (durée pendant laquelle le PEP n'a plus reçu de requêtes sur cette session), le STS-PEP initie de lui-même la déconnexion de l'application A et envoie une requête HTTP sur l'URL de déconnexion de l'application, avec le cookie de session émis par l'application.
L'application A invalide la session de l'utilisateur.
L'application A envoie une réponse HTTP à l'STS-PEP. Cette réponse HTTP n'est pas transmise au navigateur Web, car le navigateur n'a pas émis de requête HTTP.
L'STS-PEP envoie une requête HTTP à l'URL de déconnexion de l'application B avec le cookie de session que l'application B a émis.
L'application B envoie une réponse HTTP à l'STS-PEP. Cette réponse HTTP n'est pas transmise au navigateur Web, car le navigateur n'a pas émis de requête HTTP.
L'STS-PEP invalide la session de l'utilisateur qu'il gère. La fin de la session sur le PEP se produit indépendamment de la réaction des applications à l'appel de l'URL de déconnexion.

Terminaison de la session par l'atteinte de la durée maximale de la session

.
Une autre possibilité pour laquelle la session de l'utilisateur sur le STS-PEP est invalidée et résiliée est que la durée de vie maximale autorisée de la session soit atteinte. Si celle-ci est atteinte, la session est automatiquement invalidée sur STS-PEP et toutes les applications utilisées pendant la session sont notifiées par STS-PEP de l'invalidation de la session. La session est alors invalidée même si une activité est encore en cours sur la session. La durée maximale de la session sur l'STS-PEP est limitée.

La terminaison de la session initiée par STS-PEP lorsque la durée maximale de la session est atteinte se déroule comme décrit ci-dessous. SAML 2.0 Single Logout (SLO) n'est pas pris en charge.

: Terminaison de la session Durée de vie maximale de la session

La situation de départ est une session qui existe déjà depuis longtemps entre le navigateur web de l'utilisateur et le STS-PEP. Pendant la session, les applications A et B sont utilisées.

Le navigateur Web envoie une requête HTTP à STS-PEP pour l'application A.
L'STS-PEP envoie la requête HTTP à l'application A après l'avoir vérifiée.
L'application A traite la requête HTTP et envoie la réponse HTTP à l'STS-PEP.
L'STS-PEP envoie la réponse HTTP au navigateur Web.
Le navigateur Web envoie une requête HTTP à STS-PEP pour l'application B.
L'STS-PEP envoie la requête HTTP à l'application B après l'avoir vérifiée.
L'application B traite la requête HTTP et envoie la réponse à l'STS-PEP.
L'STS-PEP envoie la réponse HTTP au navigateur Web.
La session de l'utilisateur sur l'STS-PEP atteint sa durée de vie maximale.
L'STS-PEP envoie une requête HTTP à l'URL de déconnexion de l'application A avec le cookie de session de l'application A.
.
L'application A invalide la session de l'utilisateur.
L'application A envoie la réponse HTTP au PEP. Cette réponse HTTP n'est pas transmise au navigateur web de l'utilisateur.
Le STS-PEP envoie une requête HTTP à l'URL de déconnexion de l'application B avec le cookie de session de l'application B.
L'application B invalide la session de l'utilisateur.
L'application B envoie la réponse HTTP à l'STS-PEP. Cette réponse n'est pas transmise par STS-PEP au navigateur de l'utilisateur.
L'STS-PEP invalide la session de l'utilisateur.
Le navigateur web de l'utilisateur envoie une nouvelle requête HTTP à STS-PEP avec le cookie de session STS-PEP désormais invalide.
L'STS-PEP examine la requête HTTP et reconnaît qu'un nouveau contexte de sécurité doit être établi.
STS-PEP redirige le navigateur web vers l'URL de connexion d'STS-PEP. Un nouveau cookie de session est alors créé dans le navigateur Web avec la réponse HTTP.
Le navigateur Web envoie la requête HTTP vers l'URL de connexion STS-PEP.

La suite de l'établissement de la session et la transmission des requêtes se font comme décrit ci-dessus.