Gautier,

Le CR de notre dernière journée. Pour le bilan du temps passé et ce
qu'il est envisageable pour la suite, je reviens vers vous rapidement.

A bientôt,

Mikaël


Présents
========

Matin
-----

Gautier Auburtin Campus Condorcet
Johann Holland Campus Condorcet
Benjamin Dauvergne Entr'ouvert
Paul Marillonet Entr'ouvert
Mikaël Ates Entr'ouvert

Après-midi
----------

Présents du matin +

Alain Frehel Université Sorbonne Nouvelle
Arlette Dorignac EPHE
Aymar Anli Université Paris 1
Dominique Bascle Université Paris 13
Guillaume Harry CNRS
Marie-Anne Marquet EHESS
Olivier Porte CNRS
Raphaël Laurent INED


Notes
=====

CC : Campus Condorcet
EO : Entr'ouvert


Établissements et unités de recherche rejoignant le site du CC
--------------------------------------------------------------

La liste définitive des établissements et des unités de recherche
rejoignant le site du CC a été établie.

CC établit la liste dans un fichier tableur des établissement avec leur
UAI et des unités de recherche avec leur RNSR et l'UAI de leur
établissement de rattachement.


Processus invité
----------------

Tous les référents sont déclarés dans le LDAP de CC.

Lorsqu'un référent valide une invitation, son DN dans le LDAP est
renseigné sur l'entrée de l'invité dans un attribut parrainDN.

=> La validation de l'invitation est pour l'instant gérée dans w.c.s
TODO : construire un DN à partir de l'UID de l'agent backoffice ?
Le référent doit-il forcément se trouver dans le méta-annuaire ? OUI
ParrainDN est une entrée de l'annuaire !
Pour l'instant on peut commencer par une valeur calculée dans w.c.s. qui
ne correspond pas à un DN dans le méta-annuaire. Quelles possibilités en terme
de modification du modèle utilisateur w.c.s et de récupération d'un attribut
utilisateur dans les variables de templates d'emails ? Le modèle utilisateur
est bien modifiable

=> Ok, la modification du modèle utilisateur est assez directe.
Maintenant : comment procéder proprement à l'ajout dans l'entrée du méta-
annuaire.
Plusieurs choses à vérifier :
- le DN peut-il/doit-il se retrouver dans le formulaire une fois la validation
par l'agent backoffice effectuée ? OUI, il s'agit du DN hôte/référent
- Contrôle d'erreur implicite de la part de l'annuaire si jamais le DN ne
renvoie pas à une entrée existante ? OUI
- Sinon, imposer un contrôle d'erreur dans le connecteur passerelle ? NON, pas
un contrôle mais plutôt une gestion a posteriori dans le cas où le DN fourni
n'est pas valide
- parrainDN est-il par défaut dans la norme supann2009 ou bien va-t-il falloir
modifier le schéma de l'annuaire ? supannParrainDN

Le processus de validation de l'invitation sera complété du dispatch des
demandes vers les référents des établissements selon l'établissement
choisi sur le formulaire invité. Il sera possible pour un référent de
réaffecter la demande au référent Campus Condorcet (référent par
défaut).

=> Ok, donc il faut bien des entrées référents déjà présentes dans le méta-
annuaire. Possibilité d'ajouter une entrée référent pour chacun des
établissement.
Reaffectation de la demande : ajout d'un état conditionnel dans le workflow:
avec action 'déléguer la demande à l'un des référents du Campus Condorcet'
 -> Le campus doit être lui aussi renseigné en tant qu'établissement membre
 -> Utiliser un attributs eduOrg ou supannOrg pour la déclaration de la liste
 des référents dans chacun des annuaires ? Ou bien faut-il étendre le schéma ?
 Non pas d'extension, le méta-annuaire doit supporter complètement le schéma
 supann2009 -> supannParrainDN


Si l'invité renseigne une unité de recherche et s'il existe un référent
pour celle-ci, la demande lui est assignée.

=> OK il ne s'agit pas de l'assignation de la demande d'invitation, mais de
de la demande d'inscription
 -> Qui exactement est renseigné dans le champ parrainDN ? Le référant, i.e. la
 personne mentionnée dans la partie hôte du formulaire
Sinon, si l'invité renseigne un établissement et s'il existe un référent
pour celui-ci, la demande lui est assignée.
Sinon, la demande est assignée au référent Campus Condorcet.
 -> Pb: pas de possibilité d'assigner directement une demande de formulaire à
 un agent backoffice
 Une demande est assignée à un rôle, dans lequel certains utilisateurs sont
 inscrits. En revance, on peut 'envoyer un email à valeur calculée', contenant
 l'adresse de l'entrée ldap correspondant à l'EPPN fournie par l'utilisateur
 MAIS cela implique que : soit l'accès en écriture aux formulaires envoyés est
 public, soit les référents possèdent un compte d'agent dans w.c.s
 => Seule solution viable dans le 2e cas : provisioning de la base agent w.c.s
  Mais les formulaires sont associés à des rôles : tous les utilisateurs
  appartenant à un rôle peuvent voir l'ensemble des demandes d'inscription
  On fait quand même comme ça pour l'instant ? Voir plus tard la pbatique du
  découpage des rôles w.c.s
  Un rôle semble assigné à un formulaire, et non pas à certains réponses au
  formulaire
  L'idéal serait d'avoir une fonctionnalité de granularité des droits de
  gestion d'une réponse au formulaire en particulier par valeur d'un des champs
  du formulaire.
  Au total, lors de l'arrivée sur un état "Edition de l'entrée par l'agent
  backoffice w.c.s", non seulement l'agent doit être associé au rôle autorisé à
  gérer le formulaire, mais son adresse email doit aussi être renseignée dans
  l'un des champ du formulaire pour qu'il puisse prendre connaissance de
  l'existence de l'entrée du formulaire.
  La demande de Gautier paraît justifiée à cet égard -> Proposer un patch ?
Peut-être une manière de contourner le problème en proposant un workflow dédié
à la gestion des référents
Faire un formulaire 'backoffice' : l'ajout d'une entrée sur le formulaire
d'inscription créé une entrée dans un second formulaire, qui va contenir les
emails des différentes personnes concernées par la demande d'inscription
(référant, responsables de l'établissement invitant, responsables de l'unité de
recherche invitante, responsable du campus condorcet)
Le workflow va permettre l'envoi d'un email contenant le code de suivi pour
l'entrée du formulaire d'inscription
Lorsque la demande est validée, un second email est envoyé pour avertir toutes
les personnes qui étaient en mesure de valider l'inscription
MAJ : Il faut maintenant choisir un attribut falcultatif censé représenter le
DN des référents d'une unité de recherche ou d'un établissement
Pour ce faire : lecture du schéma LDAP supann_2009, attributs de supannEntite
Blocker : pas d'attributs prevu à cet effet apparemment. Etendre le schema ?
Spec supann 2009 : "non prise en compte des besoins trop spécifiques ; chaque
établissement ayant la liberté d'enrichir son schéma d'annuaire pour répondre à
ses besoins propres;"
Quid des attributs composites pour la définition des référents ?
Revoir les objectClasses pour chacune des entités de l'annuaire (page 16 du
pdf)
"supannCodeEntite de l'attribut composite supannRoleEntite pointe vers l'entite
où s'exerce le rôle"
supannRoleGenerique rôle(s) générique(s) de la personne dans l'établissement
-> A creuser
=> Un admin d'un groupe associé aux membres de l'érablissement ? :
supannGroupeAdminDN administrateurs autorisés à modifier le contenu de l'entrée
supannRefId lien avec d'autre(s) élément(s) du SI
Pb de redondance des données, l'appartenance à un établissement est définie
dans chacune des entrées des comptes utilisateurs
supannGroupeAdminDNA : DN des personnes ou des groupes habilités à
ajouter et supprimer des membres au groupe

=> regarder du côté de de organizationalUnit, l'autre objectClass des entites
(établissements et unités de recherche)

OK : pas de redondance si utilisation de supannRole ou supannRoleGenerique
R10 RESPONSABLE DE MISSION
dans les établissements et dans les unités de recherches
Pour le campus, utilisation de la même valeur d'attribut pour désigner les
référents ?
Donc finalement imposer un filtre sur supannRoleGenerique
{SUPANN}R10
Ce rôle s'exerce bien dans une structure aux dires de la spéc supann
TODO LDAP search filters
TODO modification de l'annuaire de test, ajout des référents pour chacun des
établissements
Est-il possible définir l'établissement d'origine par un DN ?
Cela faciliterait le code logique de recherche des référents
NON : supannEtablissement est une simple chaîne de caractère

Donc, pour un établissement ou une unité de recherche, le référent est l'entrée
utilisateur dont:
- l'attribut supannEtablissement vaut le RDN de l'établissement invitant
- l'attribut supannRoleGenerique vaut "{SUPANN}R10"

Maintenant que la création de la liste des emails est prise en charge :
se charger de l'envoi de emails de notification d'une demande d'inscription
Paramétrage du second workflow
Email à valeurs calculées
Problèmes, comment envoyer à w.c.s une liste d'emails à longueur variable ?
Cette fois-ci il n'est plus possible de créer une entrée de formulaire pour
chaque adresse destinataire, puisque qu'il convient d'envoyer un second mail
de notification de la validation de l'inscription
TODO: ce second email est-il vraiment nécessaire ?
Pourquoi ne pas directement créer une entrée pour email référent ?
OK, faisons comme ça dans un premier temps

Peut-être possibilité de garder tout ça dans un seul formulaire ?
A l'entrée serait alors associée la liste des personnes aptes à valider la
demande d'inscription
TODO : gestion de l'envoi d'emails multiples
Un séparateur dans w.c.s est " ; "
Vérification de l'appartenance à un établissement
certains attributs LDAP sont encodées en base 64
supannEtablissement:: Q29sbMOoZ2UgasOpc3VpdGUgYW1pw6lub2lz
Cela modifie-t-il les filtres de recherche ?

TODO: correction des nomenclatures utilisées pour supannEtablissement ?
Plus important, l'appartennance a un établissement membre pour une entrée
utilisateur ne se fait-elle pas entre
supannPeople::supannEtablissement et supannEntite::ou
mais entre
supannPeople::supannEtablissement et supannEntite::supannEtablissement
?
Oui, utilisation de la nomenclature UAI -> Ok, correction dans le code
La valeur dans les ChoiceField reste la même, c'est la seule garantissant
l'unicité de la structure en question, cependant il faut retrouver le code
supannEtablissement suivant la nomenclature UAI.
BLOCKER : unité de recherche ?
Tout ce qui a été effectué jusque là fonctionne pour les établissement, mais il
semblerait que le référencement de l'appartenance à une unité de recherche soit
effectué differemment.

Si établissement :
supannEtablissement
Sinon c'est une structure :
supannCodeEntite

Mais supannCodeEntite fonctionne aussi pour l'établissement
Donc pour un établissement, on a une redondance d'information dans le
référencement entre ou=people et ou=structure:
supannEntiteAffectation côté people référence supannCodeEntite côté structure
(comme pour les unités de recherche),
mais on a aussi supannEtablissement côté people qui référence
supannEtablissement côté structure
Double vérification dans le code du SP ?


Afin de référencer la structure invitante, l'invité est créé dans
l'annuaire avec pour valeur de l'attribut supannEtablissement
l'établissement invitant. Il est ajouté à la liste des valeurs de
l'attribut supannEntiteAffectation son établissement d'origine. Il est
ajouté à la liste des valeurs de l'attribut eduPersonAffiliation la
valeur 'affiliate'.

=> Ok, donc mauvaise utilisation de l'attribut supannEtablissement jusque là.
A changer dans le code passerelle

Pour le cas de l'INED, l'invité peut être déjà être dans le LDAP de
l'INED. Dans ce cas, il peut utiliser le processus invité ou le
processus d'inscription (décrit par la suite).

=> Ok. Nécessité d'implémenter une vérification de la présence de l'invité dans
l'établissement d'origine du référent ? Pas nécessaire, il suffit d'avoir
recours au SSO implémenté dans la v1 du POC

--> Note : Il était évoqué un problème de doublon mais il ne semble pas
qu'il y ai de problème ici. Une seule entrée dans le LDAP d'origine,
donc un eppn, les 2 processus vérifient l'existence de l'eppn.

=> Ok donc il y a bien vérificartion.

La case à cocher Liste Rouge est nommé "Masquer mes coordonnées dans
l'annuaire du Campus." et est cochée par défaut.

=> Ok

Ajout d'un champs commentaire en texte libre dans la partie Invité du
formulaire.

=> Ok

La partie du formulaire dédié à l'invitant est intitulée "Qui vous
invite ?"

=> Ok

La partie du formulaire dédié à l'invitant est réorganisée ainsi :
* Établissement
* Unité de recherche
* Un champs de saisie libre vient remplacer Nom et Prénom ; un texte
d'aide indique à l'invité qu'il doit renseigner qui l'invite et dans
quel contexte.

=> Ok

Tous ces champs sont facultatifs. Si aucun établissement ou unité de
recherche n'est renseigné, la demande est adressée au référent CC.

=> Ok

L'invité et le référent pourront échanger via des commentaires sur la
demande durant son instruction.

=> Ok

L'inscription dans la fédération RENATER de test est à venir.

=> Mail de Benj à ce propos. Je vais regarder ce que django_mellon supporte

Quelques ajustements de style sont à venir.

L'objectif est une nouvelle démonstration de 4 juillet lors de la
réunion de bureau faite sur la vm hébergée par CC.

=> Ok, je vais regarder comment packager correctement mon appli
Tout est déjà déployé sans virtualenv
En revanche le code de w.c.s. a été modifié pour supporter les appels non
signés à l'API
TODO : appels signés

Le processus de gestion des invités apparaît suffisamment convaincant
pour qu'il soit décliné dans un mode où l'invitant peut générer des
invitations et pour qu'il soit étudier la piste d'un processus
permettant de gérer l'inscription des personnes venant sur site.


Processus invité avec génération d'invitations
----------------------------------------------

Le formulaire d'invitation est accessible par un invitant après
authentification.

=> Ok DONE

Le formulaire d'invitation contient un champs pour saisir un email ou
une liste d'email.

=> Ok, un peu rustique pour l'instant mais DONE

Suite à la soumission du formulaire, un courriel d'invitation est envoyé
à chaque adresse. Le courriel contient une URL qui pointe vers le page
d'invitation où l'usager peut faire un SSO sur la fédération ou accéder
au formulaire en saisie libre. La section Invitant du formulaire est
pré-remplie.

=> Pour l'instant, rien n'assure que le SSO est engendré avec l'adresse à
laquelle a été envoyée l'invitation
Est-ce problématique ? Si oui, y a-t-il possibilité de préremplir la mire de
login de l'IDP ?

Processus d'inscription
-----------------------

Des campagnes d'information inviteront les personnes venant sur site à
venir compléter en ligne le formulaire d'inscription.

Il s'agit du formulaire invité sans la partie du formulaire destiné à
l'invitant.

=> Ok, même formulaire

Le référent est celui associé à l'établissement ou l'unité de recherche
renseigné dans le formulaire pour l'inscrit (l'invité).

=> Ok


Mise à jour des données du LDAP
-------------------------------

Un SP à haute fréquentation peut être utilisé pour mettre à jour les
données du LDAP à chaque nouvelle connexion.

=> A voir avec Mik
