1 (10:13:50) progfou: ATELIER : Authentification unifiée
2 (10:14:17) progfou: donc ici nous allons parler de la partie authentification que vous avez pu apercevoir sur le portail
3 (10:14:28) progfou: et d'un peu plus autour de ce sujet ;-)
4 (10:15:01) arnaud.amelina@auf.org: ----------------------------DebutATELIER : Authentification unifiée -----------------------------------
5 (10:15:07) progfou: nous allons suivre le plan indiqué sur http://wiki.auf.org/wikiteki/Projet/SemaineTech/2012/Ateliers/AuthentificationUnifiée
6 (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
7 (10:16:42) progfou: ça concerne nos collègues à l'AuF mais pas seulement
8 (10:17:26) progfou: ça concerne également nos abonnés des CNF, ainsi que les autres usagers de nos services, surtout web
9 (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 (10:19:04) thierry.tsitoara [thierry.tsitoara@auf.org/Bureau] a rejoint le salon.
11 (10:19:16) photo-valentin.kouadio [photo-valentin.kouadio@auf.org/f26a87cc] a rejoint le salon.
12 (10:19:18) progfou: mais il reste encore tous les autres sites et applications web demandant une authentification
13 (10:19:38) progfou: qui ont chacun leurs BdD d'identifiants et mots de passe
14 (10:20:10) progfou: par ailleurs, non seulement tout cela n'est pas unifié
15 (10:20:15) louis-beethoven.montrose [louis-beethoven.montrose@auf.org/15841688021346163607623832] a rejoint le salon.
16 (10:20:24) progfou: mais on ne peut pas non plus changer son mot de passe globalement, par une seule opération
17 (10:20:44) progfou: et plusieurs de ces BdD de mots de passe sont répliquées
18 (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
19 (10:21:38) frumence.boroto [frumence.boroto@auf.org/BureanCNFKin] a rejoint le salon.
20 (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)
21 (10:22:48) progfou: donc, si on dresse un bilan actuellement : ça marche, mais c'est grandement améliorable !
22 (10:23:18) progfou: l'ARI a donc décidé d'en faire une des priorité de 2012
23 (10:23:43) progfou: via le projet "Authentification unique et distribuée"
24 (10:24:12) progfou: ce projet est géré dans Redmine à cette adresse : https://redmine.auf.org/projects/auth
25 (10:24:38) progfou: les objectifs principaux :
26 (10:24:51) progfou: unifier tout cela, en simplifiant sans sacrifier la sécurité mais au contraire en l'augmentant
27 (10:24:55) frumence.boroto [frumence.boroto@auf.org/BureanCNFKin] a rejoint le salon.
28 (10:25:02) progfou: le web en priorité, tous les autres services par la suite (ou en parallèle quand c'est possible)
29 (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
30 (10:25:16) nguyen.le.duc.huy a quitté le salon
31 (10:26:12) progfou: ce projet a pu profiter du stage d'un de nos collègues : Chanesakhone Chitsaya, RTL au Laos
32 (10:26:31) progfou: ce qui lui a permis de se concentrer la moitié de son temps de travail dessus
33 (10:27:15) photo-valentin.kouadio [photo-valentin.kouadio@auf.org/f26a87cc] a rejoint le salon.
34 (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
35 (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
36 (10:28:53) progfou: en ce qui concerne SAML, c'est un protocole d'échange d'assertions de sécurité
37 (10:29:02) progfou: (...)
38 (10:29:13) progfou: ça vous parle pas ?
39 (10:29:29) progfou: moi non plus, ça me disait rien du tout au début ! :)
40 (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, ...)
41 (10:31:30) photo-valentin.kouadio a quitté le salon
42 (10:32:08) frumence.boroto a quitté le salon
43 (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)
44 (10:33:14) stefano.amekoudi a quitté le salon
45 (10:33:20) progfou: un autre avantage intéressant : il nous apporte les techniques de SSO (single sign-on) et SLO (single log-out)
46 (10:33:25) frumence.boroto [frumence.boroto@auf.org/BureanCNFKin] a rejoint le salon.
47 (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
48 (10:34:08) nguyen.le.duc.huy [nguyen.le.duc.huy@auf.org/26494767491346164444317172] a rejoint le salon.
49 (10:34:24) progfou: et que quand il se déconnectera, cela le déconnectera globalement de tous les services auxquels il aura accedé
50 (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é
51 (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 ;-)
52 (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
53 (10:36:55) progfou: la première fois l'utilisateur devra s'authentifier, avec un identifiant et un mot de passe
54 (10:37:10) progfou: cela lui ouvrira une session sur le service d'identité lui-même
55 (10:37:42) progfou: qui sera conservée dans son navigateur jusqu'à ce qu'il le ferme ou choisisse de se déconnecter
56 (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
57 (10:38:42) progfou: c'est cela qui permet le SSO
58 (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)
59 (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é
60 (10:40:36) progfou: donc il n'y a concrètement qu'un seul mot de passe pour tous les sites web
61 (10:41:08) progfou: et quand on le change, ça s'applique "globalement" (puisqu'il n'y en a qu'un)
62 (10:41:44) progfou: cela veut aussi dire que la gestion des informations d'authentification (les comptes) ne se fait qu'à un seul endroit
63 (10:42:17) progfou: par ailleurs SAML est un protocole pensé pour être évolutif
64 (10:42:39) progfou: il permet d'associer des informations supplémentaires sur les utilisateurs identifiés
65 (10:43:07) progfou: comme par exemple l'appartenance à un ou plusieurs groupes, les droits accordés, ou toute autre information farfelue
66 (10:43:49) louis-beethoven.montrose a quitté le salon
67 (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
68 (10:44:13) progfou: elle est utilisée en particulier dans les universités pour normaliser le type d'informations échangées
69 (10:44:28) progfou: (nous ne l'utiliserons pas dans un premier temps, peut-être plus tard)
70 (10:44:58) progfou: la norme SAML permet aussi d'informer de la réussite ou de l'échec de l'authentification
71 (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
72 (10:45:56) progfou: assez parlé ! une démo ! :)
73 (10:46:09) moussa.nombre: QUESTION (doan.manh.ha)
74 quel est le numéro de contact quand le service est indisponible
75 (10:46:15) progfou: (ensuite les questions, et après je continuerai avec nos projets AuF)
76 (10:46:20) moussa.nombre: ah
77 (10:46:48) progfou: d'abord on regarde à quoi ça ressemble
78 (10:47:03) louis-beethoven.montrose [louis-beethoven.montrose@auf.org/36917549101346165216143836] a rejoint le salon.
79 (10:47:08) progfou: concrètement on ne va quasiment jamais sur le site d'identité lui-même
80 (10:47:15) progfou: on va sur un site qui demande de s'authentifier
81 (10:47:33) progfou: donc allez par exemple sur http://test.informatique.auf.org/
82 (10:48:00) progfou: si vous y êtes déjà passés tout à l'heure, il ne va pas vous demander de vous authentifier
83 (10:48:19) progfou: allez donc ensuite sur https://intranet.auf.org/-/intranet.auf/
84 (10:48:41) progfou: là aussi, vous apercevrez un rapide passage via id.auf.org, mais aucune demande d'authentification (principe de SSO)
85 (10:48:59) progfou: allez ensuite sur https://redminebeta.auf.org/
86 (10:49:16) progfou: ne saisissez rien comme Identifiant et Mot de passe
87 (10:49:26) progfou: cliquez sur le lien id.AUF (SSO) en bas
88 (10:49:51) progfou: cela demandera à RedmineBeta d'utiliser le service id.auf.org pour vous authentifier
89 (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é
90 (10:51:24) progfou: maintenant cliquez sur le lien Déconnexion dans RedmineBeta
91 (10:51:39) progfou: il va vous faire passer par id.auf.org pour lancer un SLO
92 (10:51:55) progfou: c'est à dire une déconnexion générale de tous les services
93 (10:52:12) progfou: et cela fermera ensuite votre session sur id.auf.org => fermeture du SSO
94 (10:52:22) progfou: puis retour au site demandeur
95 (10:52:45) progfou: là vous pouvez par exemple re-tenter les connexions mais dans un ordre différent
96 (10:53:01) progfou: questions ?
97 (10:53:04) moussa.nombre: oui
98 (10:53:19) moussa.nombre: 3 QUESTIONS
99 1- (doan.manh.ha)
100 quel est le numéro de contact quand le service est indisponible
101 (10:53:32) progfou: (autre que "pourquoi tu tapes si lentement ?" => je suis sur un clavier québecois... grmph... :-p )
102 (10:53:41) moussa.nombre: je suppose qu'il veut parler de id.auf.org
103 (10:54:26) progfou: je dirais que c'est le même que pour tout autre service indisponible
104 (10:54:37) progfou: => son Tech local en premier
105 (10:55:08) progfou: ensuite, si la question est "qui gère ce service ?", c'est moi et Moussa (dans cet ordre)
106 (10:55:36) doan.manh.ha: ok toi et Moussa
107 (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)
108 (10:56:14) moussa.nombre: QUESTION
109 2- (davin.baragiotta)
110 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?
111 (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
112 (10:57:55) progfou: ensuite, il y a plusieurs choses qui font que la sécurité est bonne au départ
113 (10:58:10) progfou: déjà, ce service est isolé dans un serveur virtuel
114 (10:58:16) progfou: il sera seul dans ce serveur
115 (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)
116 (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)
117 (11:00:58) progfou: question sécurité en terme de disponibilité, il y aura de la redondance
118 (11:01:24) progfou: déjà j'ai prévu de faire ce service en double à Montréal et à Paris
119 (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)
120 (11:02:11) progfou: ça répond à la question 6
121 (11:02:12) progfou: ?
122 (11:03:48) moussa.nombre: (emmanuel.tagne-tagne)
123 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.
124 (11:04:01) moussa.nombre: dans la même logique
125
126 (11:04:07) moussa.nombre: REMARQUE
127
128 (alexandre.domont)
129 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.
130 (11:04:20) moussa.nombre: (jean-baptiste.millogo)
131 si un usager oublie de fermer son navigateur dans un cyber public ?
132 (11:04:32) progfou: ok
133 (11:04:41) progfou: donc
134 (11:04:42) progfou: oui
135 (11:04:56) progfou: le SSO apporte un risque supplémentaire
136 (11:05:19) progfou: pour des personnes qui n'en comprendrait pas les conséquences
137 (11:05:38) progfou: il nous faut donc, bien évidement, informer nos utilisateurs
138 (11:06:17) progfou: il faut bien comprendre que la simplicité est l'ennemi de la sécurité
139 (11:06:28) progfou: plus on simplifie, plus on prend des risques
140 (11:06:55) progfou: mais en même temps, simplifier les accès permet aussi d'en simplifier l'explication
141 (11:07:04) progfou: et une explication simple est plus facilement comprise
142 (11:07:22) progfou: donc finalement on va y gagner, en terme de maîtrise de la sécurité par les utilisateurs
143 (11:07:34) progfou: maintenant pour les cas cités
144 (11:07:43) progfou: le fait de ne pas se déconnecter
145 (11:07:51) progfou: ça arrivera peut-être
146 (11:08:04) progfou: normalement pas souvent car les utilisateurs auront conscience des risques
147 (11:08:09) progfou: mais ça peut arriver
148 (11:08:11) progfou: donc
149 (11:08:35) progfou: actuellement Authentic 2, le logiciel utilisé pour id.auf.org, ne permet pas de gérer cette situation
150 (11:08:53) progfou: mais j'ai prévu de faire faire (ou faire moi-même) une petite amélioration
151 (11:09:18) progfou: pour permettre la gestion par l'utilisateur de toutes ses sessions ouvertes
152 (11:09:42) progfou: de la même façon qu'on peut terminer ses sessions distantes dans Google
153 (11:09:59) progfou: on pourra le faire sur id.auf.org aussi, mais pas tout de suite
154 (11:10:14) moussa.nombre: demande de précision :
155 (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
156
157 (11:10:27) moussa.nombre:
158 (david.violette) Les mots de passe auront-ils une durée de vie ?
159 (11:10:52) progfou: pour l'oubli il y a 2 choses
160 (11:10:55) louis-beethoven.montrose a quitté le salon
161 (11:11:11) progfou: déjà, la session ne vit que tant que le navigateur est ouvert
162 (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
163 (11:12:24) progfou: ensuite, oui, il y a une durée de vie des sessions sur id.auf.org
164 (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)
165 (11:13:07) moussa.nombre: (alexandre.domont) demandais :
166 ça incite à rester connecté ou à enregistrer son login/passe dans le navigateur...il faudra pouvoir "gérer" par connexion..c'est pas possible ?
167 (11:13:07) progfou: car l'idée est de permettre du SSO pendant toute la journée de travail
168 (11:13:22) progfou: alors
169 (11:13:25) louis-beethoven.montrose [louis-beethoven.montrose@auf.org/39883450371346166796505535] a rejoint le salon.
170 (11:13:32) progfou: cette remarque de Alexandre est très intéressante
171 (11:14:00) progfou: pour la question de l'enregistrement du mot de passe, c'est exactement le contraire
172 (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
173 progfou: de la même façon qu'on peut terminer ses sessions distantes dans Google"
174
175 et en concluant : "ça répond à ma question, c'est top ça"
176
177 (11:14:14) michel.lecoz [michel.lecoz@auf.org/17054311441346140947741453] a rejoint le salon.
178 (11:14:34) progfou: les gens enregistrent leur mot de passe pour éviter de le retaper tout le temps
179 (11:14:45) moussa.nombre: JC
180 (11:14:54) progfou: hors ici, ce qu'apporte le SSO, c'est qu'ils ne le taperont qu'une seule fois
181 (11:14:55) moussa.nombre: je complète pour que tu réponde globalement :
182 (11:14:58) progfou: ok
183 (11:14:59) moussa.nombre:
184 (doan.manh.ha)
185 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
186 (11:15:14) moussa.nombre: voila
187 (11:15:20) progfou: ok
188 (11:15:44) progfou: personnellement je ne sais pas le faire, mais apparemment c'est faisable
189 (11:15:53) progfou: (d'empêcher l'enregistrement du mot de passe)
190 (11:16:01) progfou: car je l'ai vu sur des sites de banques
191 (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
192 (11:17:05) progfou: à étudier donc, merci pour l'idée
193 (11:17:23) progfou: autre question ?
194 (11:17:35) moussa.nombre: non, tu peux continuer
195 (11:17:46) progfou: ok
196 (11:18:07) progfou: donc maintenant, quel est notre plan de bataille ?
197 (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
198 (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
199 (11:20:47) progfou: techniquement, on utilise le logiciel Authentic 2 (cf URL sur le wiki) avec un LDAP derrière
200 (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
201 (11:21:55) progfou: il utilise actuellement les données d'authentification venant de auth.auf (= mot de passe Intranet/Jabber/TSE/...)
202 (11:22:26) progfou: il y a plusieurs avantages à utiliser un LDAP
203 (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
204 (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)
205 (11:23:52) nacer.saidou-adamou@auf.org [nacer.saidou-adamou@auf.org/Bureau] a rejoint le salon.
206 (11:23:58) photo-valentin.kouadio@auf.org [photo-valentin.kouadio@auf.org/f26a87cc] a rejoint le salon.
207 (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
208 (11:24:33) progfou: et parfois avec un chiffrement faible (un hachage MD5)
209 (11:24:39) progfou: avec LDAP ce ne sera plus possible
210 (11:24:56) progfou: seule une intrusion dans le LDAP lui-même permettrait une lecture des mots de passe
211 (11:25:20) progfou: l'autre avantage : LDAP est très largement supporté comme technique d'authentification
212 (11:25:29) progfou: que ce soit en direct dans les applications
213 (11:25:43) progfou: ou via un module PAM-LDAP => c'est ce que nous déploierons
214 (11:26:10) progfou: donc
215 (11:26:37) progfou: l'idée est de commencer par se concentrer sur l'authentification _web_ des personnels AuF
216 (11:27:03) progfou: uniquement le web et uniquement les personnels AuF
217 (11:27:29) progfou: et, en première étape, de façon centralisée, sur id.auf.org
218 (11:28:11) progfou: la gestion du mot de passe se fera alors sur id.auf.org et non plus sur auth.auf
219 (11:29:05) progfou: on aura donc au départ une désynchronisation entre "la nouvelle authentification sécurisée" et "l'ancienne authentification"
220 (11:29:20) progfou: mais on s'assurera que cela ne dure pas trop longtemps, quelques mois tout au plus
221 (11:29:42) progfou: les mots de passe devront alors respecter une "politique des mots de passe"
222 (11:29:58) progfou: qui donne des critères de qualités pour un bon mot de passe
223 (11:30:21) progfou: cette politique sera imposée : un mot de passe insuffisamment bon ne sera pas accepté
224 (11:30:40) progfou: (la politique est visible sur id.auf.org, en suivant le lien tout en bas)
225 (11:31:07) progfou: tous les nouveaux sites web utiliseront la nouvelle authentification
226 (11:31:27) progfou: les sites externes seront migrés progressivement
227 (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)
228 (11:32:58) progfou: donc, la première étape est la mise en place d'une authentification web centralisée pour les personnels AuF
229 (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
230 (11:34:11) progfou: nous vous donnerons pour cela une documentation de déploiement bien sûr
231 (11:34:38) progfou: et il y aura une nouvelle version de auf-django-users (déjà testée à Vientiane, Laos) qui supportera LDAP
232 (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à
233 (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
234 (11:36:19) progfou: là aussi nous vous donnerons une documentation pour le déploiement de PAM-LDAP avec des exemples
235 (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)
236 (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
237 (11:38:33) progfou: bien sûr le SSO ne fonctionnera que pour les services web
238 (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)
239 (11:39:33) abrosine2 a quitté le salon
240 (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
241 (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
242 (11:40:54) progfou: qui sera alors synchronisé _vers_ le central
243 (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
244 (11:42:05) progfou: pour cela il faudra déployer un service d'identité comme celui sur id.auf.org dans toutes les implantations
245 (11:42:15) progfou: qui se basera sur le LDAP local à l'implantation
246 (11:42:31) progfou: et permettra alors l'authentification de n'importe quel usager local : employé AuF ou abonné
247 (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
248 (11:43:19) progfou: par exemple
249 (11:43:50) progfou: un usager du CNF de Dakar veut accéder au site de gestion des bourses de l'AuF
250 (11:44:00) progfou: il va sur le site de gestion des bourses
251 (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
252 (11:44:57) progfou: là il choisit le CNF de Dakar puisque c'est là qu'il s'est inscrit
253 (11:45:20) chanesakhone.chitsaya a quitté le salon
254 (11:45:21) progfou: cela le renvoie vers id.sn.auf.org, qui sera le service d'identité du CNF de Dakar
255 (11:45:27) chanesakhone.chitsaya [chanesakhone.chitsaya@auf.org/Home] a rejoint le salon.
256 (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
257 (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
258 (11:46:53) progfou: à un moment il se déconnecte
259 (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
260 (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
261 (11:48:55) progfou: voilà, j'ai fini de vous présenter le plan de bataille pour ce projet
262 (11:49:01) progfou: questions ?
263 (11:49:05) moussa.nombre: oui
264 (11:49:25) moussa.nombre: je commence par les remarques
265 (11:49:29) moussa.nombre: REMARQUE
266 (11:49:38) moussa.nombre:
267 (victor.bruneau)
268 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
269 (11:49:44) moussa.nombre: QUESTION liée à la remarque de Victor :
270 (11:49:59) moussa.nombre:
271 (doan.manh.ha)
272 si on change maintenant on doit changer sur auth et dans adu local en meme temps ? => 2 fois ?
273 (11:50:44) photo-valentin.kouadio@auf.org a quitté le salon (Replaced by new connection)
274 (11:50:49) photo-valentin.kouadio [photo-valentin.kouadio@auf.org/f26a87cc] a rejoint le salon.
275 (11:51:38) moussa.nombre: à toi JC
276 (11:52:09) progfou: alors
277 (11:52:17) moussa.nombre: tiens ...
278
279 REPONSE de Khone
280 ce n'est pas changé mais améliorer seulement le mdp des utilisateurs sous LDAP
281 donc; on peut dire que c'est "AJOUTER LDAP " en plus
282 (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
283 (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
284 (11:54:19) progfou: le login indiqué dans la gestion des alias ne sert à rien d'autre pour le moment
285 (11:54:38) progfou: le plus important étant évidement dans a-d-u
286 (11:54:53) progfou: ainsi que le fait de relier tous les services sur une base unique
287 (11:55:09) progfou: ce qui n'est pas fait partout non plus
288 (11:55:25) progfou: le déploiement du LDAP et de PAM-LDAP sera l'occasion d'uniformiser tout cela
289 (11:55:51) progfou: suite ?
290 (11:56:00) progfou: ah
291 (11:56:08) progfou: juste pour rebondir sur la remarque de Khone
292 (11:56:17) progfou: oui, la bascule ne sera pas brutale
293 (11:56:25) progfou: le LDAP viendra d'abord en plus
294 (11:56:38) progfou: en parallèle à l'auth MySQL
295 (11:56:52) progfou: donc vous pourrez basculer les services vers LDAP un par un
296 (11:57:12) progfou: sans panique, sans stress (mais rapidement tout de même pour respecter les délais qu'on vous indiquera)
297 (11:57:34) progfou: une fois tout basculé vers LDAP, on coupera la partie "mot de passe de a-d-u dans MySQL"
298 (11:57:42) progfou: suite ?
299 (11:57:46) moussa.nombre: REMARQUE
300 (11:57:52) moussa.nombre:
301 (david.violette)
302 le mot de passe peut-être en clair dans le navigateur, mais si on bloc l'enregistrement tout va bien
303 (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)
304 (11:58:49) progfou: suite ?
305 (11:58:57) moussa.nombre: COMPLEMENT
306 (Khone)
307 déjà testée à Vientiane, Laos ==> pas seulement testé mais on a déjà utilisé il y a 2-3 mois
308 (11:59:06) moussa.nombre: ensuite QUESTIONS
309 (11:59:12) moussa.nombre:
310 1- (alexandre.domont)
311 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
312 (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 :)
313 (12:00:05) truong.tung.lam a quitté le salon
314 (12:00:07) progfou: a-d-u version 0.6.1 n'est que l'adaptation de a-d-u pour Squeeze
315 (12:00:27) progfou: j'attendais que plusieurs personnes la valide pour passer à l'étape suivante
316 (12:00:40) progfou: mais je pense que je ne vais plus attendre... on gèrera la casse
317 (12:01:03) moussa.nombre:
318 2- (nacer.saidou-adamou)
319 et SAML pour la synchro? c'est envisageable?
320 ... je parle de la synchro entre base ldap locale et distante
321 (12:01:16) progfou: (merci encore à Willy, le seul jusqu'ici à avoir confirmé que ça passait bien chez lui)
322 (12:01:44) progfou: synchro via SAML : bonne question, j'avoue ne pas avoir étudié cette possibilité
323 (12:02:07) progfou: mais je ne suis pas sûr que le rapport efficacité/complexité soit intéressant ici
324 (12:02:29) progfou: on a déjà des techniques de synchros simples et efficaces qu'on peut réutiliser
325 (12:03:11) tran.dinh.minh.tri [tran.dinh.minh.tri@auf.org/Nomade] a rejoint le salon.
326 (12:03:11) progfou: suite ?
327 (12:03:11) tran.dinh.minh.tri a quitté le salon
328 (12:03:20) moussa.nombre: non, plus rien :)
329 (12:03:38) progfou: ok
330 (12:03:57) progfou: donc on fini bien après une durée de 2h, cool :)