Je vais vous expliquer quelle a été notre démarche et comment elle a évolué en fonction de la connaissance acquise progressivement sur Grouper (et nuxeo en parallèle).

Version grouper utilisée : grouper 1.6.3  disponible depuis le 4 janvier 2011.

Démarche entamée fin mars 2011 - arrêt en juin pour installation nuxeo - redémarrage en juillet - prévision de mise en production : septembre 2011.

Démarche

Nous avions 2 motivations pour tester Grouper :

1. remplacer une portlet du portail qui nous permet depuis plusieurs années de gérer les droits d'accès aux applications dans le portail : portlet ldaproles (voir incubateur esup). Nous n'avions pas réussi à la migrer vers un esup 3.2.1 de test.
2. préparer le passage vers la gestion des documents via nuxeo qui nécessite une gestion des groupes améliorée.

Par contre, nous avions les contraintes suivantes :

1. impossible de fédérer l'établissement actuellement autour de ce projet (voir si le DSI qui arrivera en octobre fera changer cela). Au départ, il n'était même pas question de publier dans la branche ou=groups. Et au fur et à mesure de l'avancée du projet Grouper et de sa meilleure connaissance, il est apparu nécessaire de devoir publier dans cette branche ou=groups (notamment pour nuxeo). Nous en avons eu l'autorisation à condition de ne pas gêner les autres usagers. Donc, ne publier que ses propres groupes dans la branche ou=groups sans perturber ceux déjà existants (et nombreux).
2. la portlet ldaproles met à jour un attribut dans la branche ou=people : attribut "ustlRole". Il faut que le passage vers Grouper permette de remplacer cette fonctionnalité.
3. générer automatiquement à partir de Grouper le fichier "pagsGroupStoreConfig.xml" du portail esup. Le lien direct avec Grouper n'étant pas envisagé dans un premier temps, étant donné le projet de restructuration complète et passage d'une esup 2.5.1 en un esup 3.2.4 prévue initialement en juillet 2011 actuellement reportée en fin d'année 2011.

Choix d'organisation

S'affranchir des groupes esup-portail

J'ai souhaité ne pas devoir me calquer sur l'organisation (ou plutôt la pseudo-organisation...) des groupes de notre portail actuel. Les groupes esup-portail étant finalement davantage utilisés pour la publication des fragments et des canaux/portlets, il semblait plus pertinent de créer une structure indépendante et propre à Grouper.

Une organisation évolutive

Mais surtout, il fallait une organisation orientée usagers c'est-à-dire lisible par eux. Il fallait également qu'elle soit évolutive. Nous savions que nous "partirions au fil de l'eau" c'est-à-dire que ce seront les usages qui feront progresser la gestion des groupes et particulèrement les usages sur nuxeo. Il fallait dont que la structure retenue puisse répondre aux demandes ponctuelles (et souvent urgentes !) de création de nouveaux groupes.

Ne pas déléguer la création et la suppression des groupes

Nous avons choisi de ne pas déléguer la création et la suppression des groupes dans un premier temps et sur aucune branche de la structure Grouper choisie, ceci pour garantir une cohérence de cette structure.

Par contre, le peuplement des groupes devaient être délégué, à l'image de ce que faisait la portlet ldaproles (voir ci-dessus). Il fallait également bien identifier la gestion des groupes. On abandonne le vocable "gestion des rôles" par "gestion des groupes". Cela paraît anodin mais nous nous sommes aperçu que nos usagers avaient beaucoup de difficultés à comprendre cette gestion des rôles...

Trucs et Astuces

Voici quelques éléments à prendre en compte pour s'organiser :

1. il est possible de typer les groupes dans Grouper. A un type, on peut associer un ou plusieurs attributs de type string et une ou plusieurs listes. J'ai pu facilement faire des listes de personnes. Par contre, pour faire des listes d'autre chose, ce doit être possible mais cela m'a semblé difficile à mettre en oeuvre : voir avec SubjectAPI (https://spaces.internet2.edu/display/Grouper/Subject+API).
2. Par contre, impossible de nommer un attribut du même nom même sur des types de groupes différents. Il faut donc bien penser ses types de façon à ne pas avoir à réutiliser un même attribut : il faut factoriser. Notamment, cela est important quand on publie dans la branche ou=groups du ldap. J'ai été amenée par ce fait à découper les types déclarés. Par exemple, j'ai un type "GroupLDAP" qui pointe les groupes à publier dans le ldap branche ou=groups et 2 types "AEC" et "GroupOfURLs" "qui me permettent de publier des groupes avec des objectClass différents dans le ldap. Le type "groupLDAP" porte 3 attributs : cnLDAP, ownerLDAP, PubLDAPGroup.
3. Attention aux noms des attributs que vous ajoutez : ils peuvent entrer en collision avec des propriétés internes à Grouper. Par exemple, j'avais utilisé un nom d'attribut "groupName" pour un type "PortailEsup" mais il s'affichait mal car Grouper utilise pour ses propres besoins ce nom... Je l'ai donc renommé en "esup-groupName". Donc, de façon générale, pensez à utiliser des noms d'attributs spécifiques (autre exemple: j'ai utilisé "ownerLDAP" plutôt que "owner" pour un attribut).
4. Si vous choissisez de publier dans le ldap et selon votre degré d'autonomie dans la publication ldap, vous passerez beaucoup de temps à paramétrer le ldappcng.xml. De là à le comprendre complètement... Mais il s'avère que son paramétrage influera également sur l'organisation de vos groupes. Dans mon cas, j'ai été amenée à modifier les types de groupes initialement envisagés de nombreuses fois, au fur et à mesure de mon implémentation ldappcng.
5. Ne chargez pas tous vos groupes au départ ! Surtout, je vous conseille de bien réfléchir à votre structure et de faire des tests de publications dans le ldap avant de mettre votre structure complète dans Grouper. J'ai été amenée tellement de fois à modifier mes groupes que je suis contente de n'avoir pour l'instant que quelques groupes à surveiller...
6. Pour la publication des groupes dans la branche ou=groups du ldap via ldappcng, il est possible maintenant de ne publier que partiellement (authoritative=false dans ldappcng.xml) donc ne pas écraser les groupes déjà existants. Il est également possible de ne publier que certains groupes de Grouper dans cette branche ou=groups. Pour cela, il existe des filtres à positionner (dans ldappc-resolver.xml) mais ces filtres ne permettent pas de sélectionner sur le type de groupe mais sur la valeur exacte d'un attribut ou sur une branche de la hiérarchie Grouper (cf http://www.internet2.edu/grouper/release/1.5.0/doc/api/edu/internet2/middleware/grouper/shibboleth/filter/BaseGroupQueryFilter.html). Par conséquent, j'ai créé un peu "artificiellement" (car dans le fond, un peu en double par rapport au type lui-même) un attribut au type et lui ai affecté une valeur pour pouvoir sélectionner tous les groupes de ce type. Mais finalement, cela m'a servi quand j'ai cherché à publier dans le ldap 2 types de groupes différents (c'est-à-dire qui n'ont pas les mêmes attributs dans le ldap et notamment pas les mêmes objectClass). En effet, j'ai alors valué différemment cet attribut du type selon les spécificités du groupe dans le ldap. Par exemple, j'ai des groupes de type "AEC" (Avancement des Enseignants Chercheurs) et des groupes de type "GroupOfURLs" (ceux pour nuxeo). Pour publier ces 2 types de groupes dans le ldap dans la branche ou=groups en sachant qu'ils n'y auront pas les mêmes attributs particulièrement pas les mêmes objectClass, j'ai ajouté un type "GroupLDAP" qui dispose entre autres d'un attribut "PubLDAPGroup" que je valorise (par l'interface ou par groupershell) à la chaîne de caractère "AEC" quand il s'agit d'un groupe de type "AEC" et à "GOF" pour les groupes de type "GroupOfURLs".

Brigitte WALLAERT-TAQUET