Version imprimable
Je constate que chacun fait la pub à son framework ;).
eclairez nous, au moins, à quel besoin répond ce framework.? chacun a son avantage et son inconvenient mais comme tout, pour un besoin particulier une ou plusieurs réponse. on ne choisit pas un framework parceque on n'a pas réussi à mettre en ouvre un autre. on ne modifie pas l'architecture pour utiliser un framework..c'est au framework de s'adapter à l'architecure ..
pour resituer mon message, initialement l'auteur du file de discussion faisait référence à jguard.
un des auteurs par la suite, (sniper 37) posait la question des dépendances des frameworks de sécurité, notamment de la dépendance d'acegi par rapport à spring (la question était peut-on utiliser acegi sans spring, et la réponse était non):
concernant jguard, celui-ci peut être utilisé avec spring, mais il tourne très bien sans.
donc, il n'y a pas besoin d'utiliser de nombreux jars inutiles dans de nombreux cas (mais bien utile quand on utilise beaucoup de fonctionnalités de Spring).
pour la configuration, jguard (mais là c'est complètement subjectif), me semble plus simple.
concernant le fonctionnement, acegi me semble bien fait, et propose de nombreuses fonctionnalités.
ce qui me gène, et a motivé jguard (qui a commencé à peu près en même temps), c'est qu'acegi a réinventé la roue:
en clair, il existe tout un ensemble de classes, notamment JAAS, présent dans java, ignoré par acegi:
acegi a réinventé toutes ces classes , alors que jGuard les utilise.
apparemment, leur première justification était la trop grande complexité de JAAS(...). par la suite, ils ont fait des adapteurs, dont un vers JAAS pour rectifier le tir, mais tout repose sur du spécifique acegi.
à l'opposé, jguard utilise directement JAAS et les autres classes de sécurité de java, et cache l'éventuelle complexité de JAAS à l'utilisateur final de la librairie.
de plus, quand on veut utiliser une permission, jGuard supporte n'importe quelle sous-classe de java.security.Permission (et en propose déjà des toutes faites pour certains cas, en plus de celles de java directement utilisables).
les personnes qui utilisent ces permissions ne dépendent pas de jGuard mais de java.
au contraire, acegi a réinventé le concept de permission, et on doit étendre des classes d'acegi (dépendance directe à acegi), et utiliser spring pour utiliser ses propres permissions.
aionsi, un utilisateur ne voulant pas utiliser spring, ou ayant choisi un autre framework d'ioc(juice de google, ou picocontainer par exemple), aura pour contrainte de quand même embarquer spring et d'être fortement lié à acegi.
pour résumer, acegi fourni un plus grande nombre de fonctionnalités externe pour l'instant, mais au niveau du fonctionnement interne, selon moi, est moins souple (cf les permissions contextuelles de jguard, ou l'héritage des rôles par exemple).
voilà quelques éléments de réponse.
plus de détails peuvent être apportés, mais pour conclure, acegi est quand même une très bonne librairie, et ce n'est donc pas un mauvais choix, si on a à l'esprit et que l'on assume, ce qui est cité plus haut.
cordialement,
Charles.
www.jguard.net
Pourriez vous nous indiquer si jguard est capable de gérér à la fois une authentification en LDAP et les autorisations en base de données .
D'avance merci
(Jai cru comprendre que acegi le permettait)
bonjour,
la réponse est en partie oui.
actuellement, la partie LDAP ne fait que ramener les informations de l'utilisateur, mais pas encore ses rôles.
une petite modification du JNDILoginModule permettrait de faire cela.
pour l'instant, la correlation avec une base de données est nécessaire coté user sans cette petite modif.
par contre, les autorisations sont bien décorrélées de cela, et peuvent tout à fait être faites en base de données.
charles.