1

Nuxeo a-t-il connaissance de pb de performance lors d'accès LDAP et si oui a-t-il des pistes d'amélioration ?

On constate, sur certaines opérations, un grand nombre d'accès LDAP. Ex : Accès à tous les utilisateurs 1 par 1 et pas sur toute la branche. Nous sommes vigilants à la bonne utilisation d'index sur les attributs LDAP mais sommes peut-être passé à côté de certaines bonnes pratiques. Pour voir une configuration type utilisée pendant les tests cf. 7) configuration shib + LDAP fonctionnelle

2

Mise à jour du moteur JUEL

Rapidement pendant les tests nous avons été confronté au limitation de moteur d'évaluation des règles SHIB. Il nous fallait notamment pouvoir utiliser des expressions régulières pour tester les attributs SHIB multivalués dont le contenu est du style "valeur1;valeur2;valeur3". La modification est décrite ici : Tests UNR RUNN - Vincent bonamy (Paragraphe "JUEL...")
Nous avons aussi rencontré des difficultés avec la vérification des expressions, notamment avec la nouvelle version de JUEL, et l'avons supprimer en première approche.
Il conviendrait :

• De livrer nuxeo avec cette version de JUEL
• De réactiver la vérification des expressions

3

Non visualisation des "groupes composites"

Si on définit dans nuxeo un groupe "grpnx" contenant le groupe LDAP "grpldap" et que "grpldap" contient l'utilisateur "user" alors on ne voit pas, dans l'IHM nuxeo de gestion des utilisateurs, le groupe "grpnx" comme groupe d'appartenance de "user".
Pourtant une ACL avec "grpnx" positionnée sur une ressource semble bien prise en compte pour "user".

4

"groupes composites" constitués de groupes Shib non fonctionnels

Si on définit dans nuxeo un groupe "grpnx" contenant le groupe SHIB "grpshib" et que "grpshib" contient contient une règle matchant l'utilisateur "user" alors on ne sait pas autoriser "user" sur une ressource en positionnant une ACL sur "grpnx". Il faut obligatoirement positionner le groupe "grpshib".

5

Ajout d'un utilisateur SHIB, non encore authentifié, lors de la saisie des ACL

Au point 2.3.3.2 du CdC il est demandé de pouvoir ajouter un utilisateur Shib. La livraison le permet partiellement en :

• Permettant de retrouver l'identité d'un user SHIB qui s'est déjà authentifié
• Permettant, mais seulement à un administrateur, d'ajouter un user local avec un "username" bien construit qui permettra un appariement à la première connexion de cette utilisateur
  Mais il n'est pas possible à une personne ayant le droit "gérer" sur une ressource d'ajouter un utilisateur SHIB qui ne s'est pas encore authentifier une fois. Nous avons conscience de la difficulté technique potentielle à pouvoir répondre à cette demande. Elle correspond néanmoins à un besoin fonctionnel important. De plus, si le plus sûr en terme d'identifiant pour les utilisateurs SHIB semble être l'eppn, ce dernier n'est pas facilement manipulable par les utilisateurs finaux. Il serait donc particulièrement intéressant de pouvoir travailler sur un autre attribut comme l'email pour "référencer" cet utilisateur. Ceci en tenant compte du fait que l'email comme d'autres attributs SHIB peuvent être multivalués.