= Authentification unifiée : archive de la conversation =

{{{
davin.baragiotta: je crois qu'on a eu une pointe à 35 participants
}}}

{{{#!highlight irc
(10:13:50) progfou: ATELIER : Authentification unifiée
(10:14:17) progfou: donc ici nous allons parler de la partie authentification que vous avez pu apercevoir sur le portail
(10:14:28) progfou: et d'un peu plus autour de ce sujet ;-)
(10:15:01) arnaud.amelina@auf.org: ----------------------------DebutATELIER : Authentification unifiée -----------------------------------
(10:15:07) progfou: nous allons suivre le plan indiqué sur http://wiki.auf.org/wikiteki/Projet/SemaineTech/2012/Ateliers/AuthentificationUnifiée
(10:16:17) progfou: on part d'un problème constaté maintes fois, depuis longtemps, et que les utilisateurs n'hésitent pas à nous rappeler : la multitude de comptes, identifiants et mots de passe
(10:16:42) progfou: ça concerne nos collègues à l'AuF mais pas seulement
(10:17:26) progfou: ça concerne également nos abonnés des CNF, ainsi que les autres usagers de nos services, surtout web
(10:18:42) progfou: on a quand même déjà un peu travaillé à simplifier les choses en ayant 2 grands systèmes d'authentification : auth.auf, pour tous les sites internes, et auf-django-users, surtout pour toutes les authentifications locales à une implantation
(10:19:04) thierry.tsitoara [thierry.tsitoara@auf.org/Bureau] a rejoint le salon.
(10:19:16) photo-valentin.kouadio [photo-valentin.kouadio@auf.org/f26a87cc] a rejoint le salon.
(10:19:18) progfou: mais il reste encore tous les autres sites et applications web demandant une authentification
(10:19:38) progfou: qui ont chacun leurs BdD d'identifiants et mots de passe
(10:20:10) progfou: par ailleurs, non seulement tout cela n'est pas unifié
(10:20:15) louis-beethoven.montrose [louis-beethoven.montrose@auf.org/15841688021346163607623832] a rejoint le salon.
(10:20:24) progfou: mais on ne peut pas non plus changer son mot de passe globalement, par une seule opération
(10:20:44) progfou: et plusieurs de ces BdD de mots de passe sont répliquées
(10:21:28) progfou: sans parler du fait que le chiffrement du mot de passe est parfois faible, par exemple du simple MD5, technique de hachage qui est déjà reconnue comme compromise
(10:21:38) frumence.boroto [frumence.boroto@auf.org/BureanCNFKin] a rejoint le salon.
(10:22:25) progfou: et je ne vais pas non plus m'attarder sur le fait que ces BdD de mots de passe sont accessible par toute personne se connectant dans un de nos réseau bureautique (du fait de NSS)
(10:22:48) progfou: donc, si on dresse un bilan actuellement : ça marche, mais c'est grandement améliorable !
(10:23:18) progfou: l'ARI a donc décidé d'en faire une des priorité de 2012
(10:23:43) progfou: via le projet "Authentification unique et distribuée"
(10:24:12) progfou: ce projet est géré dans Redmine à cette adresse : https://redmine.auf.org/projects/auth
(10:24:38) progfou: les objectifs principaux :
(10:24:51) progfou: unifier tout cela, en simplifiant sans sacrifier la sécurité mais au contraire en l'augmentant 
(10:24:55) frumence.boroto [frumence.boroto@auf.org/BureanCNFKin] a rejoint le salon.
(10:25:02) progfou: le web en priorité, tous les autres services par la suite (ou en parallèle quand c'est possible) 
(10:25:12) progfou: les personnels AuF d'abord mais pas seulement : les abonnés ensuite, les bénéficiaires et tout autre utilisateur de nos services, comme les demandeurs de bourses par exemple
(10:25:16) nguyen.le.duc.huy a quitté le salon
(10:26:12) progfou: ce projet a pu profiter du stage d'un de nos collègues : Chanesakhone Chitsaya, RTL au Laos
(10:26:31) progfou: ce qui lui a permis de se concentrer la moitié de son temps de travail dessus
(10:27:15) photo-valentin.kouadio [photo-valentin.kouadio@auf.org/f26a87cc] a rejoint le salon.
(10:27:29) progfou: après étude de plusieurs techniques disponibles, nous avons déterminé que la technique la plus approprié pour arriver à nos objectifs était SAML, couplée à l'utilisation de LDAP
(10:28:22) progfou: on n'a jamais trop apprécié LDAP à l'AuF, mais il faut bien reconnaître que c'est l'outil qui recoupe le plus de techniques d'authentifications actuellement
(10:28:53) progfou: en ce qui concerne SAML, c'est un protocole d'échange d'assertions de sécurité
(10:29:02) progfou: (...)
(10:29:13) progfou: ça vous parle pas ?
(10:29:29) progfou: moi non plus, ça me disait rien du tout au début ! :)
(10:31:03) progfou: disons que ce sont des gros mots pour dire plus simplement que différents services vont s'échanger des informations de sécurité sur un utilisateur, comme son authentification (la ou les méthodes autorisées), son identité ou autre renseignements supplémentaires (groupes, droits, ...)
(10:31:30) photo-valentin.kouadio a quitté le salon
(10:32:08) frumence.boroto a quitté le salon
(10:32:37) progfou: un gros avantage de SAML : c'est un protocole ouvert (cf wikipedia), normalisé et déjà reconnu et mis en place par bon nombre d'universités de par le monde (dont la France et le Canada)
(10:33:14) stefano.amekoudi a quitté le salon
(10:33:20) progfou: un autre avantage intéressant : il nous apporte les techniques de SSO (single sign-on) et SLO (single log-out)
(10:33:25) frumence.boroto [frumence.boroto@auf.org/BureanCNFKin] a rejoint le salon.
(10:33:56) progfou: c'est à dire qu'un utilisateur n'aura besoin de s'authentifier qu'une seule fois pour être ensuite identifié dans tous ses accès à tous nos services
(10:34:08) nguyen.le.duc.huy [nguyen.le.duc.huy@auf.org/26494767491346164444317172] a rejoint le salon.
(10:34:24) progfou: et que quand il se déconnectera, cela le déconnectera globalement de tous les services auxquels il aura accedé
(10:35:17) progfou: l'idée pour réussir cela, c'est de concentrer l'authentification en un seul point : un service d'identité
(10:35:52) progfou: dans une architecture SAML, on va installer un serveur d'identité à un endroit, comme par exemple id.auf.org, au hasard ;-)
(10:36:26) progfou: puis tous les services web feront passer les utilisateurs par ce service d'identité avant de leur autoriser l'accès
(10:36:55) progfou: la première fois l'utilisateur devra s'authentifier, avec un identifiant et un mot de passe
(10:37:10) progfou: cela lui ouvrira une session sur le service d'identité lui-même
(10:37:42) progfou: qui sera conservée dans son navigateur jusqu'à ce qu'il le ferme ou choisisse de se déconnecter
(10:38:34) progfou: les fois suivantes, quand un site web le fera passer par le service d'identité, ce dernier verra la session déjà ouverte et ne lui demandera pas de s'authentifier mais le renverra directement vers le site web demandeur
(10:38:42) progfou: c'est cela qui permet le SSO
(10:39:34) progfou: du fait que tout cela se fasse via des redirections web classiques (des codes 302), ça fonctionne avec n'importe quel navigateur web, même les plus basiques (nos chers w3m, lynx ou links par exemple)
(10:40:19) progfou: autre avantage de cette technique : le mot de passe ne se trouve qu'à un seul endroit, dans le serveur d'identité
(10:40:36) progfou: donc il n'y a concrètement qu'un seul mot de passe pour tous les sites web
(10:41:08) progfou: et quand on le change, ça s'applique "globalement" (puisqu'il n'y en a qu'un)
(10:41:44) progfou: cela veut aussi dire que la gestion des informations d'authentification (les comptes) ne se fait qu'à un seul endroit
(10:42:17) progfou: par ailleurs SAML est un protocole pensé pour être évolutif
(10:42:39) progfou: il permet d'associer des informations supplémentaires sur les utilisateurs identifiés
(10:43:07) progfou: comme par exemple l'appartenance à un ou plusieurs groupes, les droits accordés, ou toute autre information farfelue
(10:43:49) louis-beethoven.montrose a quitté le salon
(10:43:50) progfou: il existe une autre norme associée qui permet d'échanger des informations sur l'utilisateur qui s'appelle ID-WSF
(10:44:13) progfou: elle est utilisée en particulier dans les universités pour normaliser le type d'informations échangées
(10:44:28) progfou: (nous ne l'utiliserons pas dans un premier temps, peut-être plus tard)
(10:44:58) progfou: la norme SAML permet aussi d'informer de la réussite ou de l'échec de l'authentification
(10:45:39) progfou: libre au service web demandeur ensuite de faire ses choix par rapport au résultats, comme par exemple d'autoriser quand même un accès web anonyme si l'authentification échoue
(10:45:56) progfou: assez parlé ! une démo ! :)
(10:46:09) moussa.nombre: QUESTION (doan.manh.ha)
quel est le numéro de contact quand le service est indisponible
(10:46:15) progfou: (ensuite les questions, et après je continuerai avec nos projets AuF)
(10:46:20) moussa.nombre: ah
(10:46:48) progfou: d'abord on regarde à quoi ça ressemble
(10:47:03) louis-beethoven.montrose [louis-beethoven.montrose@auf.org/36917549101346165216143836] a rejoint le salon.
(10:47:08) progfou: concrètement on ne va quasiment jamais sur le site d'identité lui-même
(10:47:15) progfou: on va sur un site qui demande de s'authentifier
(10:47:33) progfou: donc allez par exemple sur http://test.informatique.auf.org/
(10:48:00) progfou: si vous y êtes déjà passés tout à l'heure, il ne va pas vous demander de vous authentifier
(10:48:19) progfou: allez donc ensuite sur https://intranet.auf.org/-/intranet.auf/
(10:48:41) progfou: là aussi, vous apercevrez un rapide passage via id.auf.org, mais aucune demande d'authentification (principe de SSO)
(10:48:59) progfou: allez ensuite sur https://redminebeta.auf.org/
(10:49:16) progfou: ne saisissez rien comme Identifiant et Mot de passe
(10:49:26) progfou: cliquez sur le lien id.AUF (SSO) en bas
(10:49:51) progfou: cela demandera à RedmineBeta d'utiliser le service id.auf.org pour vous authentifier
(10:50:34) progfou: encore une fois, comme c'est déjà fait, id.auf.org va vous laisser passer sans demander d'authentification et vous renverra vers RedmineBeta mais cette fois-ci identifié
(10:51:24) progfou: maintenant cliquez sur le lien Déconnexion dans RedmineBeta
(10:51:39) progfou: il va vous faire passer par id.auf.org pour lancer un SLO
(10:51:55) progfou: c'est à dire une déconnexion générale de tous les services
(10:52:12) progfou: et cela fermera ensuite votre session sur id.auf.org => fermeture du SSO
(10:52:22) progfou: puis retour au site demandeur
(10:52:45) progfou: là vous pouvez par exemple re-tenter les connexions mais dans un ordre différent
(10:53:01) progfou: questions ?
(10:53:04) moussa.nombre: oui
(10:53:19) moussa.nombre: 3 QUESTIONS
1- (doan.manh.ha)
quel est le numéro de contact quand le service est indisponible
(10:53:32) progfou: (autre que "pourquoi tu tapes si lentement ?" => je suis sur un clavier québecois... grmph... :-p )
(10:53:41) moussa.nombre: je suppose qu'il veut parler de id.auf.org
(10:54:26) progfou: je dirais que c'est le même que pour tout autre service indisponible
(10:54:37) progfou: => son Tech local en premier
(10:55:08) progfou: ensuite, si la question est "qui gère ce service ?", c'est moi et Moussa (dans cet ordre)
(10:55:36) doan.manh.ha: ok toi et Moussa 
(10:55:53) progfou: l'indisponibilité sera très improbable (c'est du Django, donc robuste) et on va assurer de la redondance (on en reparle après)
(10:56:14) moussa.nombre: QUESTION
2- (davin.baragiotta)
dans la mesure où id.auf.org est un système critique (centralisation de l'accès), y a-t-il des mesures de sécurité particulières qui ont été prises?
(10:57:12) progfou: pour le moment, la seule mesure de sécurité qui a été prise est d'avoir respecté les bonnes pratiques habituelles en cas de mise en place de service web public
(10:57:55) progfou: ensuite, il y a plusieurs choses qui font que la sécurité est bonne au départ
(10:58:10) progfou: déjà, ce service est isolé dans un serveur virtuel
(10:58:16) progfou: il sera seul dans ce serveur
(10:58:44) progfou: ensuite, il ne contient pas lui-même les mots de passe, qui sont déportés dans un LDAP (j'en reparle après)
(11:00:09) progfou: par ailleurs, ce service est actuellement utilisé dans plusieurs universités de par le Monde, donc j'ai assez confiance dans la qualité du code (dont j'ai aussi rencontré quelques auteurs, qui ont un bon niveau)
(11:00:58) progfou: question sécurité en terme de disponibilité, il y aura de la redondance
(11:01:24) progfou: déjà j'ai prévu de faire ce service en double à Montréal et à Paris
(11:01:59) progfou: et ensuite, quand on passera en mode distribué (sur toutes les implantations), il y aura alors 3 moyens d'accès (1 principal, 2 de secours)
(11:02:11) progfou: ça répond à la question 6
(11:02:12) progfou: ?
(11:03:48) moussa.nombre: (emmanuel.tagne-tagne)
Est-ce que le fait de reconnecter l'usager sans authentification (les prochaines fois) n'est pas un risque? sachant que ca donne accès à tout et qu'on ne saura jamais où, et sur quel ordinateur l'usager pourra ouvrir la session hors du bureau. 
(11:04:01) moussa.nombre: dans la même logique

(11:04:07) moussa.nombre: REMARQUE

(alexandre.domont)
ouais le point critique se reporte d'avantage sur le poste client maintenant....un navigateur web = accès a une grande partie des ressources...il faut une bonne gestion des révocations ou changement de mot de passe.
(11:04:20) moussa.nombre: (jean-baptiste.millogo)
si un usager oublie de fermer son navigateur dans un cyber public ?
(11:04:32) progfou: ok
(11:04:41) progfou: donc
(11:04:42) progfou: oui
(11:04:56) progfou: le SSO apporte un risque supplémentaire
(11:05:19) progfou: pour des personnes qui n'en comprendrait pas les conséquences
(11:05:38) progfou: il nous faut donc, bien évidement, informer nos utilisateurs
(11:06:17) progfou: il faut bien comprendre que la simplicité est l'ennemi de la sécurité
(11:06:28) progfou: plus on simplifie, plus on prend des risques
(11:06:55) progfou: mais en même temps, simplifier les accès permet aussi d'en simplifier l'explication
(11:07:04) progfou: et une explication simple est plus facilement comprise
(11:07:22) progfou: donc finalement on va y gagner, en terme de maîtrise de la sécurité par les utilisateurs
(11:07:34) progfou: maintenant pour les cas cités
(11:07:43) progfou: le fait de ne pas se déconnecter
(11:07:51) progfou: ça arrivera peut-être
(11:08:04) progfou: normalement pas souvent car les utilisateurs auront conscience des risques
(11:08:09) progfou: mais ça peut arriver
(11:08:11) progfou: donc
(11:08:35) progfou: actuellement Authentic 2, le logiciel utilisé pour id.auf.org, ne permet pas de gérer cette situation
(11:08:53) progfou: mais j'ai prévu de faire faire (ou faire moi-même) une petite amélioration
(11:09:18) progfou: pour permettre la gestion par l'utilisateur de toutes ses sessions ouvertes
(11:09:42) progfou: de la même façon qu'on peut terminer ses sessions distantes dans Google
(11:09:59) progfou: on pourra le faire sur id.auf.org aussi, mais pas tout de suite
(11:10:14) moussa.nombre: demande de précision :
(11:10:21) moussa.nombre: (jean-baptiste.millogo) en cas d'oublie deconnection par l'usager est  le système prévoit une désactivation de session et au bout de combien de temps ? même si le navigateur est ouvert 

(11:10:27) moussa.nombre: 
(david.violette) Les mots de passe auront-ils une durée de vie ? 
(11:10:52) progfou: pour l'oubli il y a 2 choses
(11:10:55) louis-beethoven.montrose a quitté le salon
(11:11:11) progfou: déjà, la session ne vit que tant que le navigateur est ouvert
(11:12:07) progfou: donc, du moment qu'on ferme le navigateur, même si ça ne ferme pas proprement les sessions de tous les services auxquels on a accédé, au moins ça ferme l'accès
(11:12:24) progfou: ensuite, oui, il y a une durée de vie des sessions sur id.auf.org
(11:12:54) progfou: je ne m'en souviens plus de mémoire, mais c'est de l'ordre de 10h il me semble (je pourrai vérifier)
(11:13:07) moussa.nombre: (alexandre.domont)  demandais :
ça incite à rester connecté ou à enregistrer son login/passe dans le navigateur...il faudra pouvoir "gérer" par connexion..c'est pas possible ?
(11:13:07) progfou: car l'idée est de permettre du SSO pendant toute la journée de travail
(11:13:22) progfou: alors
(11:13:25) louis-beethoven.montrose [louis-beethoven.montrose@auf.org/39883450371346166796505535] a rejoint le salon.
(11:13:32) progfou: cette remarque de Alexandre est très intéressante
(11:14:00) progfou: pour la question de l'enregistrement du mot de passe, c'est exactement le contraire
(11:14:05) moussa.nombre: et il répond en te citant "progfou: pour permettre la gestion par l'utilisateur de toutes ses sessions ouvertes
progfou: de la même façon qu'on peut terminer ses sessions distantes dans Google"

et en concluant : "ça répond à ma question, c'est top ça"

(11:14:14) michel.lecoz [michel.lecoz@auf.org/17054311441346140947741453] a rejoint le salon.
(11:14:34) progfou: les gens enregistrent leur mot de passe pour éviter de le retaper tout le temps
(11:14:45) moussa.nombre: JC
(11:14:54) progfou: hors ici, ce qu'apporte le SSO, c'est qu'ils ne le taperont qu'une seule fois
(11:14:55) moussa.nombre: je complète pour que tu réponde globalement :
(11:14:58) progfou: ok
(11:14:59) moussa.nombre: 
(doan.manh.ha) 
FF demande si je veux qu'il garde le mot de passe alors on peut empecher par defaut pour tous les navigateurs ? ça diminue le risque pour les users qui repondent Oui tout le temps quand ils sont dans un cyber cafe 
(11:15:14) moussa.nombre: voila
(11:15:20) progfou: ok
(11:15:44) progfou: personnellement je ne sais pas le faire, mais apparemment c'est faisable
(11:15:53) progfou: (d'empêcher l'enregistrement du mot de passe)
(11:16:01) progfou: car je l'ai vu sur des sites de banques
(11:16:52) progfou: ça doit se faire avec du JavaScript j'imagine, en utilisant un champ INPUT qui ne soit pas de type "password" mais masque quand même la saisie avec des astérisques
(11:17:05) progfou: à étudier donc, merci pour l'idée
(11:17:23) progfou: autre question ?
(11:17:35) moussa.nombre: non, tu peux continuer
(11:17:46) progfou: ok
(11:18:07) progfou: donc maintenant, quel est notre plan de bataille ?
(11:18:41) progfou: ici on a déjà mis en place id.auf.org, mais c'était plutôt de l'expérimentation, pour pouvoir maîtriser la technologie
(11:20:06) progfou: pourtant on a tout de suite vu l'intérêt d'avoir un site central (facilité et rapidité de mise en place) et on va donc démarrer avec cela
(11:20:47) progfou: techniquement, on utilise le logiciel Authentic 2 (cf URL sur le wiki) avec un LDAP derrière
(11:21:24) progfou: pour le moment c'est le LDAP qui existait déjà à Montréal, et qui sert déjà pour l'authentification de quelques services comme Redmine ou Jabber
(11:21:55) progfou: il utilise actuellement les données d'authentification venant de auth.auf (= mot de passe Intranet/Jabber/TSE/...)
(11:22:26) progfou: il y a plusieurs avantages à utiliser un LDAP
(11:22:56) progfou: déjà le fait qu'on puisse faire une authentification sans avoir besoin d'aller chercher le mot de passe dans la BdD
(11:23:44) progfou: sur le plan sécurité c'est une réelle amélioration par rapport à notre gestion actuelle où tous nos services peuvent aller lire tous les mots de passe dans la BdD (pour les vérifier)
(11:23:52) nacer.saidou-adamou@auf.org [nacer.saidou-adamou@auf.org/Bureau] a rejoint le salon.
(11:23:58) photo-valentin.kouadio@auf.org [photo-valentin.kouadio@auf.org/f26a87cc] a rejoint le salon.
(11:24:16) progfou: actuellement si quelqu'un arrive à abuser un de nos services, il a accès à toute la liste des mots de passe chiffrés
(11:24:33) progfou: et parfois avec un chiffrement faible (un hachage MD5)
(11:24:39) progfou: avec LDAP ce ne sera plus possible
(11:24:56) progfou: seule une intrusion dans le LDAP lui-même permettrait une lecture des mots de passe
(11:25:20) progfou: l'autre avantage : LDAP est très largement supporté comme technique d'authentification
(11:25:29) progfou: que ce soit en direct dans les applications
(11:25:43) progfou: ou via un module PAM-LDAP => c'est ce que nous déploierons
(11:26:10) progfou: donc
(11:26:37) progfou: l'idée est de commencer par se concentrer sur l'authentification _web_ des personnels AuF
(11:27:03) progfou: uniquement le web et uniquement les personnels AuF
(11:27:29) progfou: et, en première étape, de façon centralisée, sur id.auf.org
(11:28:11) progfou: la gestion du mot de passe se fera alors sur id.auf.org et non plus sur auth.auf
(11:29:05) progfou: on aura donc au départ une désynchronisation entre "la nouvelle authentification sécurisée" et "l'ancienne authentification"
(11:29:20) progfou: mais on s'assurera que cela ne dure pas trop longtemps, quelques mois tout au plus
(11:29:42) progfou: les mots de passe devront alors respecter une "politique des mots de passe"
(11:29:58) progfou: qui donne des critères de qualités pour un bon mot de passe
(11:30:21) progfou: cette politique sera imposée : un mot de passe insuffisamment bon ne sera pas accepté
(11:30:40) progfou: (la politique est visible sur id.auf.org, en suivant le lien tout en bas)
(11:31:07) progfou: tous les nouveaux sites web utiliseront la nouvelle authentification
(11:31:27) progfou: les sites externes seront migrés progressivement
(11:32:19) progfou: les anciens sites internes (typiquement sur l'intranet) seront toujours accessible avec l'ancien mot de passe (celui venant de auth.auf) le temps de déterminer si on les branche sur la nouvelle authentification ou si on les abandonne (suivant les cas)
(11:32:58) progfou: donc, la première étape est la mise en place d'une authentification web centralisée pour les personnels AuF
(11:33:50) progfou: la seconde étape sera de déployer un LDAP dans toutes les implantations et de normaliser les identifiants et mots de passe utilisateurs
(11:34:11) progfou: nous vous donnerons pour cela une documentation de déploiement bien sûr
(11:34:38) progfou: et il y aura une nouvelle version de auf-django-users (déjà testée à Vientiane, Laos) qui supportera LDAP
(11:35:20) progfou: la gestion des utilisateurs se fera toujours via une BdD MySQL, toujours via NSS, sauf pour le mot de passe qui lui sera sauvé dans le LDAP et uniquement là
(11:35:58) progfou: l'authentification se fera donc via une couche PAM-LDAP, autant pour les services de courriels que pour le poste client ou tout autre service local qui utilisait MySQL directement
(11:36:19) progfou: là aussi nous vous donnerons une documentation pour le déploiement de PAM-LDAP avec des exemples
(11:37:46) progfou: afin que les mots de passe _des personnels AuF_ puissent être les même entre le local (LDAP de a-d-u) et le central (LDAP de id.auf.org), nous mettrons en place une technique de synchronisation entre local et central (soit via LDAP, soit via script Python/SSL)
(11:38:18) progfou: cette seconde étape consistera donc en une unification de l'authentification des personnels AUF, non plus seulement web mais tous services confondus
(11:38:33) progfou: bien sûr le SSO ne fonctionnera que pour les services web
(11:39:01) progfou: (il y a des recherches en cours pour relier le SSO à l'authentification sur un poste client, mais ce n'est pas mûr)
(11:39:33) abrosine2 a quitté le salon
(11:40:09) progfou: enfin, en 3ème et dernière étape, dans le cadre de ce projet, nous rendrons aux implantations leur autonomie de gestion en mettant en place une structure d'authentification distribuée
(11:40:41) progfou: c'est à dire que ce qui fera référence pour l'authentification d'un utilisateur ne sera plus le LDAP central mais le LDAP local
(11:40:54) progfou: qui sera alors synchronisé _vers_ le central
(11:41:35) progfou: à partir de cette étape là, nous aurons aussi la possibilité d'intégrer tous les usagers locaux dans notre processus d'authentification
(11:42:05) progfou: pour cela il faudra déployer un service d'identité comme celui sur id.auf.org dans toutes les implantations
(11:42:15) progfou: qui se basera sur le LDAP local à l'implantation
(11:42:31) progfou: et permettra alors l'authentification de n'importe quel usager local : employé AuF ou abonné
(11:43:15) progfou: l'authentification étant distribuée, cela voudra aussi dire qu'une personne voulant s'authentifier devra d'abord indiquer quelle est l'autorité qui la connaît
(11:43:19) progfou: par exemple
(11:43:50) progfou: un usager du CNF de Dakar veut accéder au site de gestion des bourses de l'AuF
(11:44:00) progfou: il va sur le site de gestion des bourses
(11:44:35) progfou: si c'est la première fois, le site lui propose une liste des autorités d'authentification = la liste des implantations de l'AuF
(11:44:57) progfou: là il choisit le CNF de Dakar puisque c'est là qu'il s'est inscrit
(11:45:20) chanesakhone.chitsaya a quitté le salon
(11:45:21) progfou: cela le renvoie vers id.sn.auf.org, qui sera le service d'identité du CNF de Dakar
(11:45:27) chanesakhone.chitsaya [chanesakhone.chitsaya@auf.org/Home] a rejoint le salon.
(11:45:57) progfou: là bas il s'authentifie et est ensuite renvoyé, identifié, vers le site d'origine : le site de gestion des bourses de l'AuF
(11:46:43) progfou: à partir de là c'est du SSO et il a accès à tous les sites que lui autoriseront son profil d'abonné, sans avoir besoin de se ré-authentifier
(11:46:53) progfou: à un moment il se déconnecte
(11:47:44) progfou: quand il revient sur un site de l'AuF, depuis le même navigateur, ce dernier aura retenu (cookie) le choix précédent d'autorité d'authentification et le renverra directement sur id.sn.auf.org
(11:48:29) progfou: bien sûr il y aura un lien, sur tous les sites de service d'identité, pour changer ce choix par défaut
(11:48:55) progfou: voilà, j'ai fini de vous présenter le plan de bataille pour ce projet
(11:49:01) progfou: questions ?
(11:49:05) moussa.nombre: oui
(11:49:25) moussa.nombre: je commence par les remarques
(11:49:29) moussa.nombre: REMARQUE
(11:49:38) moussa.nombre: 
(victor.bruneau)
la normalisation des  identifiants en prenom.nom pour la messagerie et le poste client peut commencer dès maintenant pour les implantations qui ne l'ont pas encore faite. Cela leur fera gagner du temps
(11:49:44) moussa.nombre: QUESTION liée à la remarque de Victor :
(11:49:59) moussa.nombre: 
(doan.manh.ha)
si on change maintenant on doit changer sur auth et dans adu local en meme temps ? => 2 fois ?
(11:50:44) photo-valentin.kouadio@auf.org a quitté le salon (Replaced by new connection)
(11:50:49) photo-valentin.kouadio [photo-valentin.kouadio@auf.org/f26a87cc] a rejoint le salon.
(11:51:38) moussa.nombre: à toi JC
(11:52:09) progfou: alors
(11:52:17) moussa.nombre: tiens ...

REPONSE de Khone
ce n'est pas changé mais améliorer seulement le mdp des utilisateurs sous LDAP
donc;  on peut dire que c'est "AJOUTER LDAP " en plus
(11:53:08) progfou: effectivement le changement de la forme du login doit être indiqué sur auth.auf, pour ceux qui l'utilisent dans leur SOGo
(11:53:50) progfou: mais normalement on avait déjà convenu de passer à cette nouvelle forme dans le cadre du déploiement de SOGo, donc une partie du travail est déjà bien entamée
(11:54:19) progfou: le login indiqué dans la gestion des alias ne sert à rien d'autre pour le moment
(11:54:38) progfou: le plus important étant évidement dans a-d-u
(11:54:53) progfou: ainsi que le fait de relier tous les services sur une base unique
(11:55:09) progfou: ce qui n'est pas fait partout non plus
(11:55:25) progfou: le déploiement du LDAP et de PAM-LDAP sera l'occasion d'uniformiser tout cela
(11:55:51) progfou: suite ?
(11:56:00) progfou: ah
(11:56:08) progfou: juste pour rebondir sur la remarque de Khone
(11:56:17) progfou: oui, la bascule ne sera pas brutale
(11:56:25) progfou: le LDAP viendra d'abord en plus
(11:56:38) progfou: en parallèle à l'auth MySQL
(11:56:52) progfou: donc vous pourrez basculer les services vers LDAP un par un
(11:57:12) progfou: sans panique, sans stress (mais rapidement tout de même pour respecter les délais qu'on vous indiquera)
(11:57:34) progfou: une fois tout basculé vers LDAP, on coupera la partie "mot de passe de a-d-u dans MySQL"
(11:57:42) progfou: suite ?
(11:57:46) moussa.nombre: REMARQUE
(11:57:52) moussa.nombre: 
(david.violette)
le mot de passe peut-être en clair dans le navigateur, mais si on bloc l'enregistrement tout va bien
(11:58:27) progfou: le mot de passe n'est normalement pas en clair quand on prend soin d'utiliser un mot de passe principale (mais je pense qu'on ne l'a pas encore expliqué aux gens)
(11:58:49) progfou: suite ?
(11:58:57) moussa.nombre: COMPLEMENT
(Khone)
déjà testée à Vientiane, Laos ==> pas seulement testé mais on a déjà utilisé il y a 2-3 mois
(11:59:06) moussa.nombre: ensuite QUESTIONS
(11:59:12) moussa.nombre: 
1- (alexandre.domont)
c'est la version 0.6 (note du modérateur : le nouveau a-d-u avec ldap)? http://apt.auf.org/pool/auf/a/auf-django-users/auf-django-users_0.6.1_all.deb
(11:59:32) progfou: effectivement, la solution a-d-u + LDAP + PAM-LDAP est déjà en production à Vientiane (Laos), merci Khone pour ce rappel :)
(12:00:05) truong.tung.lam a quitté le salon
(12:00:07) progfou: a-d-u version 0.6.1 n'est que l'adaptation de a-d-u pour Squeeze
(12:00:27) progfou: j'attendais que plusieurs personnes la valide pour passer à l'étape suivante
(12:00:40) progfou: mais je pense que je ne vais plus attendre... on gèrera la casse
(12:01:03) moussa.nombre: 
2- (nacer.saidou-adamou)
 et SAML pour la synchro? c'est envisageable?
... je parle de la synchro entre base ldap locale et distante
(12:01:16) progfou: (merci encore à Willy, le seul jusqu'ici à avoir confirmé que ça passait bien chez lui)
(12:01:44) progfou: synchro via SAML : bonne question, j'avoue ne pas avoir étudié cette possibilité
(12:02:07) progfou: mais je ne suis pas sûr que le rapport efficacité/complexité soit intéressant ici
(12:02:29) progfou: on a déjà des techniques de synchros simples et efficaces qu'on peut réutiliser
(12:03:11) tran.dinh.minh.tri [tran.dinh.minh.tri@auf.org/Nomade] a rejoint le salon.
(12:03:11) progfou: suite ?
(12:03:11) tran.dinh.minh.tri a quitté le salon
(12:03:20) moussa.nombre: non, plus rien :)
(12:03:38) progfou: ok
(12:03:57) progfou: donc on fini bien après une durée de 2h, cool :)
}}}