2012-02-10 4 views
1

Lors de l'utilisation d'un SSO pour l'intégration entre des "applications Web" disparates, l'utilisateur peut basculer entre ces applications. Lorsque l'utilisateur navigue entre ces applications, une session locale est créée sur chacune des applications en plus d'une session créée sur le fournisseur d'identité utilisé pour sso. Par conséquent, le problème est lorsque les applications ont des délais d'attente de session différents, ce qui entraîne une expérience utilisateur défectueuse. Le délai d'attente de session se produit dans une application pendant que l'utilisateur travaille sur une autre application. Lors de la navigation dans l'application que l'utilisateur a déjà visitée, une erreur se produit. Ceci est déroutant pour l'utilisateur, car ils ne sont pas conscients qu'ils travaillent sur des applications différentes. Une façon d'éviter le problème est d'avoir un objet "session globale" auquel chaque application a accès. Pendant que l'utilisateur accède à une ressource protégée, l'application vérifie si la session globale existe et met à jour son horodatage avant de traiter la demande. Les sessions locales n'expireront jamais (ou auront un très long délai d'expiration). Cependant, lorsque l'utilisateur se déconnecte, l'objet de session global est expulsé et la déconnexion se produit sur toutes les applications.Délai de session partagée dans un scénario EAI + sso

Cela semble être un peu la main lourde en raison de:

  • objet global de la session devient le point de défaillance unique
  • La performance de faire un « hors processus » vérification de l'objet de la session mondiale et mettre à jour l'horodatage sur l'accès de tous les demande protégée

toute autre pensée sur la façon de faire ce travail?

Répondre

0
When navigating back into the application the user had 
visited previously, an error occurs. 

Je ne pense pas que ce serait une erreur. L'application redirigera la demande vers le fournisseur SSO et comme l'utilisateur dispose déjà d'une session SSO valide, il s'agira d'une opération SSO réussie et l'application pourra rétablir une nouvelle session/expirée.

+0

Non si des informations de contexte sont stockées dans la session pour répondre à la demande. De la même manière que l'utilisateur appuie sur le bouton Précédent vers une autre plate-forme, mais utilise l'ID de contexte stocké dans la session (plutôt que de le récupérer dans l'URL) pour répondre à la demande. – Kiran