Équilibrage de charge, Spring Security, ConcurrentSessionFilter

Question

J'ai une configuration d'application Spring 2.5.6/Flex et fonctionne avec Spring Security 2.0.4. Récemment, un équilibreur de charge (A Foundry ServerIron 4g http://www.foundrynet.com/products/a...ems/si-4g.html) a été mis en place et maintenant je reçois des erreurs de domaines croisés. Fondamentalement, l'équilibreur de charge envoie une requête à myloadbalancer.abc.com et myrealserver1.abc.com est renvoyé comme nom de domaine. La sécurité de printemps transmet la demande au serveur réel d'une manière ou d'une autre. Comment puis-je contourner cela?

De même, le ConcurrentSessionFilter ne fonctionne plus. L'application est configurée pour désactiver les connexions simultanées, mais cette fonctionnalité s'est arrêtée après que l'application a été placée derrière l'équilibreur de charge. Je crois que plusieurs serveurs d'applications Oracle sont également regroupés. Je n'ai jamais eu affaire à un clustering ou à des load balancers auparavant et je ne savais pas que le logiciel devait être écrit différemment dans certaines zones.

Cela ressemble à des problèmes distincts, mais j'ai besoin d'aide pour les deux.

Answer 1

Concernant votre deuxième problème:

Si le ConcurrentSessionFilter a cessé de fonctionner (à savoir n'empêche pas de sessions simultanées plus commercialisé), qui pourrait être dû à des conteneurs d'application avec des sessions en cluster collantes.

Dans une telle configuration, chacun des nœuds du cluster fonctionne indépendamment et ne partage pas l'état avec d'autres nœuds. Au lieu de cela, l'équilibreur de charge s'assure que les sessions existantes seront toujours servies par le même nœud.

Maintenant, ConcurrentSessionController de Spring Security fonctionne en mappant les sessions aux entités principales. Le contrôleur lui-même repose sur le HttpSessionEventPublisher envoyant ApplicationEvents au début et à la fin des sessions utilisateur.

Tout ira bien si quelqu'un ayant l'intention d'ouvrir plus d'une session se retrouve sur le même nœud qu'il a déjà ouvert une session. HttpSessionEventPublisher informe le mécanisme de session simultanée de la création de la session et l'authentification échouera car il y a déjà une session associée à cet utilisateur. Cependant, sur un nœud différent, il n'y a pas encore de session pour cet utilisateur, donc ConcurrentSessionController ne se plaint pas et la connexion réussit. Heureusement, la résolution du problème devrait être facile: implémentez votre propre SessionRegistry et utilisez un magasin de données partagé pour tous les nœuds (par exemple, la base de données de l'application).