Impact de l'authentification unique sur l'expiration de la session

Question

Je dois mettre en œuvre l'authentification unique entre un domaine Windows et une application Web J2EE.

Je pensais à l'impact que cela aurait sur le délai de session de l'application web. Nous avons un délai de 2 heures.

Si nous implémentons un SSO sans apparence, je pense que cela pourrait devenir confus pour l'utilisateur.

L'authentification unique fera apparaître que l'application Web est immédiatement disponible. Je suis inquiet qu'ils commencent à remplir des formulaires, puis aller déjeuner (ou quelque chose) et revenir après que leur session a expiré. Cependant, il peut ne pas être immédiatement évident que cela est arrivé, puisque le SSO va juste les signer à nouveau (mais maintenant avec une nouvelle session).

Quelqu'un at-il une expérience avec quelque chose comme ça et comment le gérer? Avons-nous juste besoin d'implémenter une forme de messagerie supplémentaire pour dire à l'utilisateur que sa session précédente a expiré et que son travail a été perdu?

Answer 1

Je pense que vous devez absolument faire apparaître une boîte d'alerte si la session de l'utilisateur est réinitialisée. Demandez-leur de cliquer sur OK dans le message et de les rediriger vers la page d'accueil.

En outre, je pense qu'un délai de 2 heures semble être une mauvaise idée si vous le faites comme je pense que vous êtes. Voulez-vous dire que l'utilisateur a 2 heures à partir de quand se connecter au travail avant que leur session expire? Cela n'aurait-il pas plus de sens d'avoir quelque chose comme un timeout de 10 minutes mais avec la minuterie qui se réinitialise à chaque fois que l'utilisateur envoie une nouvelle requête dans cette session.

Answer 2

Le délai d'expiration n'est pas un temps fixe statique mesuré à partir de la connexion, mais plutôt une mesure dynamique de l'inactivité.

Sur les sites que nous avons équipés de cette fonctionnalité au bout de 10 minutes environ, la page Web revient à la page de connexion (JS utilisée) et l'utilisateur peut recommencer s'il le souhaite.

S'ils sont occupés avec un long processus où ils examinent des résultats ou quelque chose, vérifiez le déplacement de la souris ou une touche de sous-liste comme celle qui indique qu'ils sont encore occupés.

Answer 3

question ancienne, mais au cas où quelqu'un va à travers elle:

Essayez vraiment difficile de stocker pas d'état lors de la session du serveur. Client, bien; persistance du serveur principal (comme une base de données), très bien. Rien entre les deux ne serait perdu. Lorsque l'utilisateur est ré-authentifié de façon transparente, il ne remarque pas le changement. La durée du délai d'attente devient non pertinente.

Cette réponse est en fait plus faisable maintenant, six ans plus tard, car il existe plusieurs frameworks frontaux qui stockent vos données pour vous. Vous pouvez toujours utiliser Spring Security (disons) sur le serveur, car l'authentification est toujours là avec la nouvelle session; il devrait régénérer vos informations de sécurité (SecurityContext, UserDetails, etc.) à la volée. Quelle que soit la demande obtient ou envoie des données devrait alors "juste fonctionner".