Je souhaite que les clients de plusieurs applications Web associées contiennent leur propre état d'authentification. Cela améliore l'évolutivité, car aucune réplication de session entre les nœuds de cluster n'est nécessaire. Et il rend l'intégration de différentes technologies de serveurs tels que Java Servlets et PHP plus facile.
Mon plan est le suivant:
Tous les serveurs qui souhaitent utiliser la session ne sont que pour connaître le mécanisme de cookie et la clé de déchiffrement. Voir aussi: état de la session dans le niveau client
Cette approche est-elle ok? Serait-il possible de l'intégrer à un servlet de conteneur / serveur d'applications afin qu'il soit transparent pour les applications? Un servlet devrait pouvoir utiliser httpservletRequest # GetRemoteUser () par exemple. Est-ce possible? Ou aurais-je besoin de quelque chose au-dessus du niveau de conteneur comme la sécurité du printemps? Y a-t-il des bibliothèques existantes pour la gestion de la session latérale client?
6 Réponses :
Pas une bonne idée. Stocker des données vitales telles que l'expiration de la session et le nom d'utilisateur entièrement sur le côté client est trop dangereuse IMO, crypté ou non. Même si le concept est techniquement sûr en soi (je ne peux pas répondre à cette profondeur, je ne suis pas un expert en cryptage), une pause peut être facilitée sans compromettre votre serveur, juste en acquérant votre clé de cryptage.
Quelqu'un qui attire la clé de la clé pourrait générer des cookies de session à volonté, Impessonant tout utilisateur pour tout temps de temps , quelque chose que le concept de session classique est conçu pour prévenir.
Il existe de meilleures solutions évolutives pour ce problème. Pourquoi pas, par exemple, mettre en place une instance de vérification centrale de la session que tous les serveurs et services associés peuvent-ils sonder? Regardez autour du Web, je suis sûr à 100% des solutions prêtes à répondre à vos besoins.
Ce n'est pas vraiment la mise en œuvre des sessions. Le cookie lui-même n'a pas besoin de porter des données de la session elle-même, c'est juste une référence à celle-ci.
Qu'est-ce que le cookie est généralement un Si vous n'avez pas de serveur de session de données central pour les autres serveurs d'accès, je suggère d'en obtenir un :). ID de session qui est ensuite lié aux données sur le serveur.
C'est ce qu'il ne veut pas faire parce qu'il veut que la solution soit évolutive. Je pense que cela la seule façon d'aller, cependant.
Je veux avoir un magasin pour l'état d'authentification. Et je ne veux pas stocker cet état sur le côté serveur. J'ai quelque chose comme l'authentification de base HTTP à l'esprit, mais que vous voulez être plus flexible (pour soutenir OpenID par exemple).
Vous pouvez éviter la duplication des données dans un environnement en cluster à l'aide d'un serveur d'état - un serveur bien connu de tous les nœuds des clusters et maintient les données de session pour tous les utilisateurs. Chaque fois qu'un utilisateur effectue une demande, il envoie un cookie avec ID de session sur le serveur d'applications; Celui-ci devrait récupérer la session du serveur d'état. Cela est possible pour le développement ASP.NET, mais je ne suis pas sûr à quel point Java est facile à soutenir cette approche.
Le monde Java Doit avoir des solutions pour cela. C'est la plate-forme Web de haut niveau la plus ancienne et utilisée par d'innombrables applications d'entreprise qui ont rencontré le même problème à un moment donné.
Cela améliore l'évolutivité, car aucune réplication de session entre les nœuds de cluster n'est nécessaire.
Tout d'abord, l'utilisation de la session HTTP ne vous empêche pas vraiment de vous mettre à l'échelle, même lors de l'utilisation de la réplication de l'état HTTP Session (certains mécanismes sont plus intelligents que d'autres d'autrui, par exemple, de Weblogic's La réplication en mémoire n'a pas de gros frais généraux). Deuxièmement, vous en avez vraiment besoin? La plupart des applications (la majorité) n'ont pas besoin de réplication de la session. Troisièmement, je comprends bien: devez-vous utiliser une session HTTP du tout?
(...) Définissez un cookie signé et crypté avec le nom d'utilisateur et le temps d'expiration de la session après l'authentification du client.
ne fais pas cela! Ne stockez pas de nom d'utilisateur et d'autres données sensibles utilisées par le serveur dans un cookie, c'est une très mauvaise idée! Vous avez réellement besoin d'admettre que ce n'est qu'une question de temps avant que quelqu'un déterminer la manière dont votre système fonctionne et le brise (surtout si votre cookie est candidat à crèche attaques). Sor, vraiment, vous devez stocker des données dans la session sur le côté serveur et seul un identifiant dans le cookie, comme les choses fonctionnent réellement. Ceci est beaucoup plus sécurisé.
Cette approche est-elle ok?
non. et vous n'avez pas besoin de cela pour interopérables SING-SICK ON (si c'est ce que vous essayez de construire). Il suffit d'utiliser une solution d'authentification centralisée comme CAS Jasigqui a des bibliothèques pour diverses technologies .
J'ai une question à ce sujet. Si nous stockons SessionID à Cookie et que nous laissons le client envoyer au serveur à chaque fois que l'identité du cent, la personne peut-elle voler cette sessionID et empêcher son utilisateur? Cela me confond depuis si le mauvais gars peut voler des données d'identité sensibles à partir de cookies, alors la sessionID réellement aussi sensible? Ai-je tort? Merci!
Comme le dit Pekka, pas une bonne idée. On peut intercepter votre cookie avec des données de session sensibles. Même avec SSL, en utilisant Fiddler2, on peut Decrypt Le trafic
Une sécurité de la couche de transport n'a pas signé, mais le cryptage des données de cookie lui-même - par exemple avec GNUPG.
Vous avez tort de Fiddler2 décryptant le trafic SSL. Ce n'est pas un trou de la conception SSL / TLS, Fiddler2 agit simplement comme un proxy, mettant lui-même mise à la place d'un serveur Web de confiance, avec un certificat autogogenéré (et non rigoureux!) Pour parler aux demandes d'émission du client et les transmettre à la destination. Destination posant comme client HTTPS. Ceci est très différent de dire que Fiddler2 peut décrypter le trafic SSL. Si ce serait le cas, les criminels auraient vidé nos comptes bancaires hier.
@amn: vrai; Vous n'interceptez que le trafic, obtenu. Strange que sur le lien donné, le titre indique "décrypter le trafic protégé https" ... Ceci est trompeur. Cela devrait être "intercepté". Comme il est dit à la page Fiddler, il permet «de modifier le trafic sécurisé par HTTPS», ce qui maintient le cookie crypté (comme Direction de Damon) n'est toujours pas sécurisé, car on peut changer le cookie cryoté.
Je suis en désaccord avec les affiches indiquant que cette approche n'est pas sécurisée. Les variantes de celui-ci sont utilisées dans un certain nombre de cadres respectés, tels que des rails et des jeux!, Pour les raisons avec précision les raisons que vous décrivez, et il est parfaitement sécurisé lorsqu'il est mis en œuvre correctement.