...
- 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).
- 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 rassemble les attributs communs à tous les groupes ldap de la branche ou=groups.
- Il porte 3 attributs : cnLDAP, ownerLDAP, PubLDAPGroup. En effet, le cn et le owner sont des attributs communs à tous les groupes à publier dans ou=groups, l'attribut PubLDAPGroup (valeurs actuelles : "aec" ou "gof", cf ci-après explications sur ces types) me permet de publier l'un ou l'autre des types de groupes lors de la synchronisation ldappcng (filtre de publication).
- J'ai ensuite déclaré 3 types : type "AEC", type "supannGroupe" et type "GroupOfURLs" "qui me permettent de publier des groupes avec des objectClass différents dans le ldap mais aussi de déclarer des attributs spécifiques à chacun de ces types.
- Par exemple, le type "AEC" supporte un attribut "ustlPresident",
- le type "supannGroupe" supporte 3 attributs : supannGroupeAdminDN, supannGroupeLecteurDN et supannGroupeDateFin.
- Le type GroupOfURLs permet de déclarer des groupes dynamiques dans la branche ou=groups. Je n'ai déclaré qu'un seul attribut pour ce type : memberURL. La valeur de cet attribut est un filtre ldap, par exemple : ldap://nom-serveur.univ-xxx.fr/ou=people,dc=univ-xxx,dc=fr??sub?(ustlDepartement=SUAIO). De ce fait, dans le ldap dans la branche ou=groups, ce groupe est déclaré dynamiquement : aucun membre n'apparaît en visualisation dans l'annuaire mais les applications qui appellent ce groupe peuvent en déduire "à la volée" ses membres. C'est ce que fait Nuxeo par exemple.
- Un autre exemple de "factorisation" possible d'attribut : une partie des groupes pags d'esup-portail et d'infoglue ont une partie commune : l'attribut "ustlRole" à publier dans le ldap, attribut qui permet de rassembler des personnes sur simple déclaration du/des responsables de ce groupe (par exemple, liste des ACMO ou encore liste des chargés de mission recherche). J'ai donc un seul type nommé "PAGSRole" qui permet de déclarer
- la valeur de cet attribut "ustlRole" pour ce groupe (par exemple "ACMO-acteurs" ou "IntranetCMR") , qu'il soit pags-esup-portail, pags-infoglue voire ni l'un ni l'autre (cas d'une application qui vient lire directement dans le ldap, comme la portlet annuaire pour avoir la liste des correspondants antivirus, logiciels ou gestionnaire de parc par exemple).
- Ensuite, j'ai un type "PortailEsup" qui donne le groupName et le groupKey pour esup-portail et un type "Infoglue" qui donne des attributs spécifiques à Infoglue.
- J'ai également un type"PAGS" qui donne la valeur du selectionTest pour esup-portail, à utiliser uniquement pour les groupes pags du portail qui sont déclarés à partir d'une selectionTest et d'attributs "classiques" du ldap (comme objectClass ou eduPersonAffiliation par exemple),
- 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).
- Attention au paramètre Required pour les attributs de Type. Je dois modifier mes déclarations de types pour les rendre tous Not Required car impossible d'enlever le type de groupe quand un des attributs est required et que cet attribut avait déjà été renseigné. Cf bug jira : https://bugs.internet2.edu/jira/browse/GRP-620
- 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.
- 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...
- 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". Mais attention, je ne peux plus publier tous les objets en même temps, je dois utiliser le paramètre entityName pour sélectionner ce que je veux publier : member ou groupAEC ou groupGOF.
...