375 lines
15 KiB
Plaintext
375 lines
15 KiB
Plaintext
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
|