We apologize for untranslated text, you can use the Google Translation button to get an automatic translation of the web page in the language of your choice.

L'administrateur d'espace n'a plus le droit de mettre des membres dans ses groupes

René Bernard · on 7/15/13 at 11:57 AM

Depuis la migration en 7.1.2, nous constatons que les administrateurs d'espace ne peuvent plus peupler leurs groupes si ceux-ci ont un groupe parent qui n'appartient pas à l'espace et sur lequel ils n'ont pas de droit .

Travailler avec une acl est une solution que nous n'avons pas retenue car trop permissive.

Il semblerait que la jsp admin/doMemberList vérifie les droits sur les groupes parents avant de proposer le menu Ajouter Membre.

Cette vérification semble débrayable puisque la méthode Member.checkMemberGroupModification(loggedMember, group, null, true) possède un paramètre qui mis à false permet de ne pas propager la vérification aux groupes parents.

Le fait de placer ce paramètre à false permettrait de résoudre notre problème et de revenir à un fonctionnement antérieur.

Pouvez-vous nous confirmer que cette manipulation ne provoquera pas d'effet de bord et nous dire pourquoi il n'existe pas une propriété permettant d'obtenir ce comportement ?

Merci

4 pts
Olivier Jaquemet · on 7/15/13 at 12:11 PM

Bonjour René,

Il s'agissait d'un bug, identifié sous la référence JCMS-3035
il a été corrigé dans JCMS 7.1.3 diffusée sur ce site vendredi dernier, avec les jumbo patch adéquat pour effectuer une migration très rapidement.

Le correctif est plus compliqué que cette simple modification et je vous invite à migrer votre webapp en 7.1.3 en appliquant le jumbo patch.

0 pts
René Bernard · on 7/15/13 at 12:30 PM

Merci Olivier pour votre réponse

Pouvez-vous juste me préciser la stratégie adoptée par le patch ? vérification des groupes parents ou pas ?

Bien cordialement

#1

Biensur, le correctif autorise à nouveau les administrateurs d'espace à ajouter des membres dans des groupes globaux ou dans des groupes d'espace ayant un groupe global comme parent.

D'autre vérifications sur les groupes parents continuent à être assurées, notamment l'interdiction de mettre un utilisateur dans un groupe bénéficiant d'une ACL global.

Olivier Jaquemet · on 7/15/13 at 12:37 PM
0 pts
René Bernard · on 7/15/13 at 1:55 PM

Re,

après étude du bug JCMS-3035,  il me semble que cela ne corrigera pas notre problème. En effet le correctif porte sur les groupes globaux.

Notre problème est de débrayer le mécanisme qui interdit de mettre un membre dans un groupe si ce groupe comporte un groupe parent sur lequel on n'a pas le droit de le faire puisque c'était comme ça dans les versions précédentes.

Cette vérification au demeurant tout à fait légitime nous pose problème puisque nous donnons accès à des espaces collaboratifs à travers des groupes de nos espaces traditionnels.

La méthode Member.checkMemberGroupModification permet de ne pas faire cette vérification à travers son quatrième paramètre apparu avec la version 7.1.2.

Malheureusement, ce paramètre ne semble pas être utilisé à travers une propriété par le MemberListHandler au moment de l'insertion du membre dans le groupe.

Quelle solution pouvons-nous adopter pour débrayer la vérification du droit d'insérer le membre  dans un groupe parent ?

Merci encore

#3

Je suis désolé car je n'ai pas de solution à vous proposer en l'état.

Le comportement actuel est voulu. Je comprends qu'il soit contraignant pour votre cas d'usage mais c'est ce lui que nous avons retenu après validation des scénarios fonctionnels les plus courants, tout en conservant une sécurité maximale, et une maintenabilité du produit acceptable.

Je peux éventuellement saisir une demande d'évolution pour débrayer la contrainte de sécurité via fameux booléen dont vous parlez (et le rendre paramétrable), mais si vous utilisez les ACLs sur d'autres groupes, vous risquez d'autoriser des modifications qui ne devraient pas être acceptées.

Quoi qu'il en soit, vous n'aurez pas de moyen de mettre en oeuvre cette solution de suite.

Olivier Jaquemet · on 7/15/13 at 4:29 PM
#4

Olivier, merci pour vos réponses et votre compassion.

Pour finir, juste trois remarques :

  1. Vous avez bien rendu débrayable le droit pour un administrateur d'espace de mettre un membre dans un groupe global via la propriété member.rights.allow-global-group-wsadmin: true alors pourquoi pas pour les groupes d'espace parents.
  2. Le problème n'est pas tellement qu'une vérification du droit de mettre les membres dans un groupe soit propagée au niveau des groupes parents ce qui en soit est une bonne chose mais que cette vérification soit apparue sans crier gare à la faveur d'une migration somme toute secondaire.
  3. Ne pourrait-on pas imaginer une mécanique de droit sur les groupes permettant de gérer plus finement que les ACL le droit de mettre des membres dans un groupe particulier ?

Bien cordialement

René Bernard · on 7/16/13 at 8:59 AM
#5
  1. ces propriétés que vous avez pu voir sont proposées pour sécuriser l'application encore plus par rapport au choix que nous faisons en standard, elles sont prévues dans le cas ou le choix par défaut ne serait pas jugé suffisamment sûr pour un client.
    Ne plus contrôler les groupes parents autoriserait des actions largement au delà ce qu'on estime raisonnable. Je ne souhaite pas proposer cette option car notre devoir de conseil c'est aussi vous éviter de configurer JCMS d'une façon qui puisse nuire à la sécurité de vos sites.
  2. ce comportement plus restrictif a été introduit en 7.1.2, car c'est selon nous un problème de sécurité que de l'autoriser, c'est donc un correctif. Je mentirais en vous disant que nous avions pensé à tous les cas d'usage et que ça n'a pas posé de problème chez d'autre client, c'est d'ailleurs pour ça que nous avons de nouveau correctif en 7.1.3.
  3. Nous devons conserver une mécanique simple sans quoi cela deviendrait un frein pour la maintenance et l'évolution de JCMS.

Vous l'avez dit vous même dans un précédent message, le controle qui a été introduit dans JCMS est une "vérification au demeurant tout à fait légitime".

Vous souhaitez proposer une action permettant à certains administrateurs de placer des membres dans des groupes spécifiques, en allant contre la politique de sécurité de JCMS. Je vous propose d'utiliser une mécanique existante dans JCMS pour proposer cette action : développer un simple JSP accessible depuis l'espace d'administration via une target

  1. Vous exploiter une mécanique déjà fourni par le produit, donc que vous pouvez mettre en place dès maintenant sur votre webapp.
  2. Cela simplifie votre tâche : le développement à réaliser est plus simple que de devoir s'insérer dans une éventuelle mécanique de contrôle de droit sur les groupes et groupes parents, dont la gestion est extrêmement délicate et sujet à l'erreur
  3. Le produit reste entièrement sûr et maintenable en standard, ce qui pour nous est un gage de simplicité, et pour vous la promesse de meilleure fonctionnalité à l'avenir

L'impact est une légère diminution de la qualité de l'expérience utilisateur car l'action en question ne se fait pas dans les interfaces habituelles de JCMS.

Olivier Jaquemet · on 7/16/13 at 9:59 AM
1 pt