Discussion :

[lalakers]

slt,

j'utilise le serveur J2ee de chez sun (8.1).
Dans ma partie Web-Tier, j'utilise Form-based comme méthode d'autentification d'user et j'utilise le Realm du serveur "file".
Après ma page jsp de login, où se trouve mon formulaire d'autentification, si l'autentification est correcte, le user est redirigé donc vers une autre page jsp. J'arrive à récupérer le login de l'autentifier grâce request.getUserPrincipal().getName(), est-il possible de récuperer son subject pour afficher son group par exemple ?

merci

[SEMPERE Benjamin]

en fait il ne me semble pas que l api te donne cette info par contre si tu as la liste des roles du user tu peux tester le:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
boolean result = request.isUserInRole("admin");

pour savoir si oui ou non ton user appartient a tel ou tel groupe

[lalakers]

la méthode isUserInRole("RoleX") permet de savoir si le user a le droit sur ce role mais moi j'aimerais récupérer le groupe du user ?

[SEMPERE Benjamin]

Effectivement isUserInRole c'est pour le role et c est ecrit dans le mon de la methode en plus ...

Ceci dit l API de JAAS ne te permet pas de recuperer la liste des roles d un user alors je serais pres a parier qu il en est de meme pour les groupes

[lalakers]

peut-être c'est pour ça que je me pose cette question, qui je pense est sans réponse

[diabolo512]

est-il possible de récuperer son subject?

la réponse est non, si tu utilises la méthode "classique" j2ee.
en fait, l'authentification sous j2ee est mal standardisée, et le peu qui l'est est d'une qualité douteuse....
en fait, dans les spécifications j2ee, il est fait référence à JAAS souvent, mais chaque serveur d'application utilise son mécanisme de realm spécifique (bonjour la portabilité entre serveurs d'applications......).

la réponse est oui si tu utilises un autre mécanisme, comme jGuard (http://jguard.sourceforge.net).
petite précision, je fais partie de l'équipe de développement de jGuard.
jGuard repose sur JAAS, (intégré en standard dans j2se depuis java 1.4), et l'utilise dans ton application j2ee.

pour résumer, il existe un mécanisme standard dans java, et les spécificateurs j2ee ont fait leur propre système bien moins performant.....

donc avec jGuard, tu récupères effectivement un objet Subject représentant ton utilisateur, ayant des attributs de sécurité publics et privés, possédant plusieurs rôles (principals) dont la liste peut être connue très facilement (impossible en j2ee).
les rôles sont bien sûr liés à des permissions, et les associations rôle - permissions peuvent être mise à jour à chaud via ta webapp (une webapp exemple est fournie).
jGuard fournit aussi une librairie de tags afin de protéger aussi des fragments de page.
la version prochaine de jGuard (v0.65) est pour très bientôt, et la version beta est pour ce week-end (v0.65 beta2).
celle-ci permettra une installation et intégration simplifiée.
pour exemple, l'utilisateur n'aura qu'à mettre le war exemple dans son serveur d'applications (tomcat), et c'est tout!
ceux qui connaissaient les étapes de configuration précédentes apprécieront!

en espérant que ma réponse pourra t'aider,

Charles (jGuard team).

[SEMPERE Benjamin]

est-il possible de récuperer son subject?

la réponse est non, si tu utilises la méthode "classique" j2ee.
en fait, l'authentification sous j2ee est mal standardisée, et le peu qui l'est est d'une qualité douteuse....
en fait, dans les spécifications j2ee, il est fait référence à JAAS souvent, mais chaque serveur d'application utilise son mécanisme de realm spécifique (bonjour la portabilité entre serveurs d'applications......).

la réponse est oui si tu utilises un autre mécanisme, comme jGuard (http://jguard.sourceforge.net).
petite précision, je fais partie de l'équipe de développement de jGuard.
jGuard repose sur JAAS, (intégré en standard dans j2se depuis java 1.4), et l'utilise dans ton application j2ee.

pour résumer, il existe un mécanisme standard dans java, et les spécificateurs j2ee ont fait leur propre système bien moins performant.....

donc avec jGuard, tu récupères effectivement un objet Subject représentant ton utilisateur, ayant des attributs de sécurité publics et privés, possédant plusieurs rôles (principals) dont la liste peut être connue très facilement (impossible en j2ee).
les rôles sont bien sûr liés à des permissions, et les associations rôle - permissions peuvent être mise à jour à chaud via ta webapp (une webapp exemple est fournie).
jGuard fournit aussi une librairie de tags afin de protéger aussi des fragments de page.
la version prochaine de jGuard (v0.65) est pour très bientôt, et la version beta est pour ce week-end (v0.65 beta2).
celle-ci permettra une installation et intégration simplifiée.
pour exemple, l'utilisateur n'aura qu'à mettre le war exemple dans son serveur d'applications (tomcat), et c'est tout!
ceux qui connaissaient les étapes de configuration précédentes apprécieront!

en espérant que ma réponse pourra t'aider,

Charles (jGuard team).

Ca c est interessant par contre supposons que j ai une appli dont la securite est geree au niveau des ejb et du webcontainer, est ce couteux (en temps) de changer mon systeme pour qu il repose sur jguard?

[diabolo512]

supposons que j ai une appli dont la securite est geree au niveau des ejb et du webcontainer, est ce couteux (en temps) de changer mon systeme pour qu il repose sur jguard?

jGuard sécurise dans sa version actuelle principalement le container de servlets.
les autres permissions sont déléguées au mécanisme "classique de java".
la version actuelle sécurise des URL.
la version 0.70 (les changements sont en cours dans le cvs), permettra de sécuriser n'importe quelle permission.
cette protection actuelle par les urls, couvre la plupart des besoins des webapps, vu que les clients des appli webs, les appellent souvent par celle-ci
;-)

concernant la sécurisation du container d'EJBs, celle-ci n'a pas été testée.
par contre (bien qu'apparemment il existe des problèmes sur certains serveurs d'application), il est possible de passer l'objet utilisateur (le subject), ainsi que ses attributs de sécurité (credentials) via JNDI.
il me semble que sur le serveur d'application de sun, cela marche.

la sécurisation du container d'EJB n'est pas tout le temps nécessaire, si on utilise des ejb locaux (à privilégier pour les perfs!!), donc sur la même machine.

concernant la mise en place de jGuard, (en n'optant pas pour une configuration paranoiaque => très haute sécurité au niveau de la machine virtuelle mais plus de config), on peut le mettre en oeuvre rapidement avec la beta2 à venir:
on déclare un servlet filter dans le web.xml, et c'est bon!
le reste est à configurer via les écrans web (attention c'est très moche) fournis à inclure dans sa webapp => on peut aussi appeler l'API directement.

hope it helps,

Charles(jGuard team).

[diabolo512]

petite précision:
la version 0.65beta2 de jGuard sort ce we.
de plus, pour tous ceux qui auraient des questions ou besoin d'aide, l'équipe est très réactive sur le forum du projet hebergé sur sourceforge.

charles.

[lalakers]

vivement lundi avec la version beta car j'ai déjà essayer de configurer la version actuelle la 0.64 et je t'avoue que je ne suis pas arriver et la je la trouve fastidieuse mais voyons voir cette beta

[SEMPERE Benjamin]

supposons que j ai une appli dont la securite est geree au niveau des ejb et du webcontainer, est ce couteux (en temps) de changer mon systeme pour qu il repose sur jguard?

jGuard sécurise dans sa version actuelle principalement le container de servlets.
les autres permissions sont déléguées au mécanisme "classique de java".
la version actuelle sécurise des URL.
la version 0.70 (les changements sont en cours dans le cvs), permettra de sécuriser n'importe quelle permission.
cette protection actuelle par les urls, couvre la plupart des besoins des webapps, vu que les clients des appli webs, les appellent souvent par celle-ci
;-)

concernant la sécurisation du container d'EJBs, celle-ci n'a pas été testée.
par contre (bien qu'apparemment il existe des problèmes sur certains serveurs d'application), il est possible de passer l'objet utilisateur (le subject), ainsi que ses attributs de sécurité (credentials) via JNDI.
il me semble que sur le serveur d'application de sun, cela marche.

la sécurisation du container d'EJB n'est pas tout le temps nécessaire, si on utilise des ejb locaux (à privilégier pour les perfs!!), donc sur la même machine.

concernant la mise en place de jGuard, (en n'optant pas pour une configuration paranoiaque => très haute sécurité au niveau de la machine virtuelle mais plus de config), on peut le mettre en oeuvre rapidement avec la beta2 à venir:
on déclare un servlet filter dans le web.xml, et c'est bon!
le reste est à configurer via les écrans web (attention c'est très moche) fournis à inclure dans sa webapp => on peut aussi appeler l'API directement.

hope it helps,

Charles(jGuard team).

Cool je vais tester ca et au pire je poserai un post pour expliquer comment j ai procede pour passer d une securisation "JAAS classique" a une securisation "JAAS via JGuard" en tout cas merci et bon WE

[SEMPERE Benjamin]

Avec Jguard, est il possible de resoudre ma problematique enoncee ici
http://www.developpez.net/forums/viewtopic.php?t=362639

[diabolo512]

la réponse est, si j'ai bien compris ton besoin:
oui
jGuard lorsqu'un utilisateur s'est authentifié, stocke son objet Subject en session:
il est ainsi possible via un listener de détecter la mise en session de l'objet.

au fait, la version de jGuard v0.65 beta 2 est sortie il y a quelques secondes sur sourceforge!

enjoy!


Charles(jGuard team).

[diabolo512]

je te conseille maintenant d'utiliser la version 0.65 finale de jGuard (http://jguard.sourceforge.net), qui est sortie il y a quelques heures.

elle corrige des bugs des versions beta, et ajoute quelques fonctionnalités supplémentaires.

cordialement,

Charles(jGuard team).