Quelles sont les alternatives pour l'authentification Java?

De préférence quelque chose qui s'intègre bien avec un frontal Flex. Oui les gars de Spring Security disent que c'est possible, mais tous les exemples semblent utiliser des bibliothèques de balises jsp héritées les rendant à moitié inutiles comme exemples. Je ne veux pas passer un mois à configurer et à apprendre à utiliser un outil de sécurité. Je voudrais un outil qui prend en charge l'utilisation des annotations (@RolesAllowed etc), MINIMAL XML, et les fonctionnalités "remember-me" (pas de base de cookies). Apache Shiro semble également prendre en charge Flex/Silverlight/Swing, mais j'aimerais savoir s'il existe d'autres alternatives qui ne sont pas spécifiques au conteneur.Quelles sont les alternatives pour l'authentification Java?

Source

2010-05-08 Manius

Quel type de remember-me suggérez-vous lorsque vous dites que vous ne voulez pas que ce soit basé sur des cookies? Au cours d'une session, vous pouvez utiliser des paramètres dans l'URL, mais entre les sessions, je ne saurais pas comment stocker des informations d'identification sans cookies (flash). –

Impossible de SharedObject faire cela? http://livedocs.adobe.com/flash/9.0/ActionScriptLangRefV3/flash/net/SharedObject.html Je ne sais pas ce que la logistique de le faire serait, mais ce serait bien d'abandonner complètement la gestion de la session de conteneurs en utilisant quelque chose qui n'a pas BESOIN d'un conteneur (comme Shiro?) Je veux être capable de déployer sur des conteneurs J2EE sans craindre que ma fonctionnalité de sécurité/session ne se casse à chaque fois, mais je ne veux pas dépenser 1/3 de mon temps de développement en mettant une telle sécurité. N'est-ce pas un objectif valable? – Manius

Il s'avère que Apache Shiro est une solution plus simple et plus facile à apprendre que la sécurité Spring. Et aucune configuration stupide de xml n'est gentille.

Source

2010-12-19 19:37:46 Manius

Je ne vois pas pourquoi Flex devrait authentifier quoi que ce soit, après tout ce qui est le côté client. Qu'est-ce qui empêche quelqu'un de décompiler votre flash/flex?

Pour la plupart des gens Apache Shiro est exagéré et ils viennent de rouler les leurs. Ce qui n'est pas la meilleure idée pour être honnête. J'ai vu beaucoup de systèmes d'authentification horribles au cours des années. Les cookies sont destinés à suivre la session pour le client, pourquoi utiliser autre chose?

Editer: Utiliser la sécurité du ressort pour l'authentification.

Source

2010-05-08 18:01:08 rook

Je pense que vous vous méprenez, je ne veux pas que Flex lui-même authentifie quoi que ce soit (et le hacking swf est exactement la raison pour laquelle je recherche une réelle sécurité côté serveur).Seule l'implication est le fait que les appels distants (RemoteObject) via Blaze ou Granite DS sont utilisés plutôt que la simple soumission de formulaire, ce qui signifie que les exemples de balises jsp ne sont pas de bons exemples. – Manius

Je pense aussi que les docs de Spring Security parlent d'une alternative à la persistance des cookies plus sécurisée (j'oublie comment ça s'appelle mais je crois qu'elle utilise une base de données) et je ne pense pas que les cookies s'intègrent très bien avec une application Flex . Et encore une chose - l'authentification n'est pas si difficile (JAAS) mais l'autorisation semble être plus problématique. – Manius

@Crusader vous êtes un peu confus. Il est impératif que vous transmettiez un identifiant de session au serveur Web afin de conserver l'état de la session. La météo de cet état est conservée par un bean Session ou l'utilisation de la base de données n'est pas pertinente en termes de sécurité. Si cet identifiant de session est divulgué à l'attaquant par xss ou par reniflage, alors ce compte est compromis. C'est pourquoi OWASP A3: l'authentification et la gestion de session cassées nécessitent l'utilisation de HTTPS tout au long de la session. – rook

Spring Security est de loin le meilleur outil disponible.

BlazeDS n'est pas une magie. C'est finalement juste un appel au serveur via HTTP. L'application Blaze est juste un fichier de guerre, et a des URLs traditionnels. Donc, pour protéger les services, vous devez protéger les URL dans vos fichiers de configuration web.xml/spring. Pour l'essentiel, lisez la documentation de Spring Security/JAAS et remplacez les jsps par les URL de vos services blaze. Spring Security prend également en charge les rôles et les autorisations. Il a également une fonctionnalité remember-me, mais qui utilise absolument les cookies. Vous ne pouvez pas avoir de fonctionnalité remember-me sans cookies. En ce qui concerne l'authentification, il est possible de passer le jeton d'authentification en tant que paramètre de requête au lieu d'un cookie. Mais les cookies sont recommandés, et sont beaucoup plus faciles à obtenir.

Enfin, la sécurité est inutile sans utiliser https. Vous devez absolument utiliser https dans votre application si vous vous souciez de la sécurité.

Source

2010-05-08 21:10:45

Je ne comprends pas pourquoi tout le monde dit que Spring Security est si génial (ou que Shiro est "overkill") lorsque Spring Security a une liste massive de dépendances et une courbe d'apprentissage abrupte. Le but de Shiro est d'être le 'plus facile à utiliser', n'a presque AUCUNE dépendance et jar hell, et très peu de configuration. Contrasté avec le fétiche de xml de ressort je ne comprends tout simplement pas comment quelqu'un pourrait dire que Shiro est exagéré. Si quelque chose Spring Security a probablement plus de fonctionnalités, mais est aussi beaucoup plus gonflé. On dirait que ces deux sont les seules alternatives là-bas ... – Manius

Quelles sont les alternatives pour l'authentification Java?

Répondre

Questions connexes