Des trucs qu'on garde pour mémoire
Travaux/Déboggage avec Inverse
- fichier de métadata
> Pourrais-tu m'en générer un pour que je puisse tester? Voici un exemple ci-joint. Je l'ai construit à partir d'un exemple réel, que tu peux aussi consulter ici : https://informatique.auf.org/mellon/metadata
... mais j'ai dû d'abord finaliser les méta-données en y ajoutant la clé pub
Pour des raisons _de tests_, le fichier xml est dans /usr/sbin/Resources/sogod/Resources/
Bugs rapportés chez Inverse
Des tests concluants ... mais plusieurs remarques
Yes !! Ça y est !! On a un truc qui marchouille !! :-D 1er problème : il manque une fonction exportée dans la librairie Lasso venant de Entr'ouvert. Wolfgang nous avait déjà proposé une série de correctifs pour ça et nous sommes donc repartis sur sa version corrigée de la liblasso3. 2ème problème : il y avait un souci dans l'interprétation des dates SAML par le module PAM. Nous avons « hacké » ça en quelques lignes de code C pour supprimer automatiquement les microsecondes quand elles sont présentes : elles ne sont pas vraiment utiles et elles ne sont pas comprises par la fonction C "strptime". 3ème problème : l'authentification PAM vérifie que le login fournit pour l'auth correspond bien à un attribut SAML, uid par défaut. Nous avons donc dû, pour le moment, ajouter un attribut "uid" dans l'assertion SAML répondue par l'IdP, uniquement dans le cas où c'est le SP SOGo qui demande. Mais je propose une autre approche, cf plus bas. 4ème problème : il y avait un souci dans notre config' PAM pour Dovecot elle-même. Nous l'avons simplifiée en remplaçant l'inclusion des common-* par des actions PAM explicites (permit). Après cela, l'authentification IMAP a fonctionné pleinement et nous sommes bien arrivés dans la boîte de l'utilisateur. Par contre il reste encore quelques problèmes à résoudre : - SOGo, au moment du login, fait une requête d'authentification avec ForceAuthn="true", ce qui nous impose de nous ré-authentifier et nous empêche donc de bénéficier du SSO ; - SOGo, au moment du logout, ferme sa session locale mais ne fait pas passer l'utilisateur par le logout de l'IdP et nous empêche donc de bénéficier du SLO ; - il semble par ailleurs que la session SAML expire ! en effet, au cours de nos tests, nous nous sommes retrouvés régulièrement à devoir nous ré-authentifier sur l'IdP, ce qui est assez désagréable… il faudrait que la durée en soit paramétrable, et idéalement même que ce soit complètement désactivable (avec une durée nulle ?) ; Et sinon, suite à nos tests, je révise mes suggestions de ce matin comme suit : - faire que le nom de l'attribut SAML à utiliser pour retrouver l'utilisateur SOGo soit un paramètre de la configuration SAML dans SOGo (par exemple SOGoSAML2LoginAttribute) ; - faire que SOGo vérifie que le domaine DNS (la partie après le '@') dans cet attribut SAML, s'il existe, corresponde au domaine indiquée pour SOGo (dans SOGoMailDomain) ; - faire que SOGo utilise ensuite le nom d'utilisateur (la partie avant le '@') dans cet attribut SAML pour faire la correspondance avec l'utilisateur SOGo ; - faire enfin que SOGo utilise le champ IMAPLoginFieldName (venant de l'utilisateur SOGo retrouvé) comme login vers le serveur IMAP. Le traitement resterait ainsi consistant avec les possibilité de paramétrage existantes. J.C.
On 05/04/13 16:47, Jean Christophe André wrote: > > - SOGo, au moment du login, fait une requête d'authentification avec ForceAuthn="true", ce qui nous impose de nous ré-authentifier et nous empêche donc de bénéficier du SSO ; C'est corrigé. Les nightly builds de la nuit prochaine auront le correctif. > > - SOGo, au moment du logout, ferme sa session locale mais ne fait pas passer l'utilisateur par le logout de l'IdP et nous empêche donc de bénéficier du SLO ; Ceci va nécessiter des développements supplémentaires. On pourra regarder le tout après la version 2.0.5. Je suggère que tu ouvres un billet sur http://www.sogo.nu/bugs > > - il semble par ailleurs que la session SAML expire ! en effet, au cours de nos tests, nous nous sommes retrouvés régulièrement à devoir nous ré-authentifier sur l'IdP, ce qui est assez désagréable… il faudrait que la durée en soit paramétrable, et idéalement même que ce soit complètement désactivable (avec une durée nulle ?) ; Les sessions SAML sont stockées seulement dans le cache memcached dans SOGo, alors il faudrait augmenter le timeout d'expiration dans la configuration de SOGo. Au plaisir, -- Ludovic Marcotte
Pour mémoire
test N°1 : récupération des métadata : https://sogo-test-saml.ca.auf.org/SOGo/saml2-metadata
Feb 19 16:41:35 sogod [31252]: |SOGo| starting method 'GET' on uri '/SOGo/saml2-metadata' Feb 19 16:41:35 sogod [31252]: [ERROR] [so-action 0x0xb8623808 SOGoSAML2Actions] did not find action class: SOGoSAML2Actions Feb 19 16:41:35 sogod [31252]: [ERROR] [so-action 0x0xb8354ef8 SOGoSAML2Actions] did not find method 'SOGoSAML2Actions' 2013-02-19 16:41:35.370 sogod[31252] <MySQL4Channel[0x0xb83876f0] connection=0x0xb82430b8> SQL: SELECT * FROM auf_users WHERE (c_uid = 'saml2-metadata') OR (mail_pays = 'saml2-metadata') OR (mail = 'saml2-metadata'); 2013-02-19 16:41:35.370 sogod[31252] <MySQL4Channel[0x0xb83876f0] connection=0x0xb82430b8> query has results, entering fetch-mode. 2013-02-19 16:41:35.370 sogod[31252] <MySQL4Channel[0x0xb83876f0] connection=0x0xb82430b8> SQL: SELECT c_uid FROM auf_users WHERE (c_uid = 'saml2-metadata') AND (source = 'LOCAL'); 2013-02-19 16:41:35.371 sogod[31252] <MySQL4Channel[0x0xb83876f0] connection=0x0xb82430b8> query has results, entering fetch-mode. Feb 19 16:41:35 sogod [31252]: [ERROR] [so-action 0x0xb85eb460 SOGoSAML2Actions] did not find action class: SOGoSAML2Actions Feb 19 16:41:35 sogod [31252]: [ERROR] [so-action 0x0xb8354ef8 SOGoSAML2Actions] did not find method 'SOGoSAML2Actions' Feb 19 16:41:35 sogod [31252]: [ERROR] [so-action 0x0xb85a2670 SOGoSAML2Actions] did not find action class: SOGoSAML2Actions Feb 19 16:41:35 sogod [31252]: [ERROR] [so-action 0x0xb8354ef8 SOGoSAML2Actions] did not find method 'SOGoSAML2Actions' Feb 19 16:41:35 sogod [31252]: |SOGo| request took 0.002779 seconds to execute 10.36.1.4 - - [19/Feb/2013:16:41:35 GMT] "GET /SOGo/saml2-metadata HTTP/1.1" 404 43/0 0.004 - - 0
- Échanges avec Inverse
Le mainteneur de CrudeSAML a publié une nouvelle version avec mes correctifs: http://ftp.espci.fr/pub/crudesaml/crudesaml-1.4.tar.gz ******** J'ai terminé l'implémentation du support SAML dans SOGo en vue de se connecter à Dovecot via le module PAM/SASL crudesaml. À l'aide de l'auteur de crudesaml, j'ai dû adapter le code de trois composants (en plus de SOGo): - Dovecot pour accepter des "mots de passe" de plus de 1000 caractères - liblasso pour qu'il exporte la fonction utilisée par crudesaml - crudesaml pour réduire le nombre de warnings et de prototypes mal configurés lors de la compilation. Je joins ces patches à ce message, même si j'ai déja envoyé l'un d'eux à Jean-Christophe. Au niveau de SOGo, la fonctionnalité sera présente dans la version 2.0.3 de SOGo. Et le guide d'installation a été mis à jour concernant les nouvelles directives de configuration. Notez que j'ai utilisé simplesamlphp comme idp. Je vous suggèrerais de tester les nightly builds de demain pour corriger tout éventuel problème le plus vite possible. ********* >> Peux-tu me dire quelle patch ne s'applique pas correctement? > Celui pour Dovecot, qui est super simple (1 seule ligne) avec Dovecot 2.x (Debian testing) mais pour lequel nous n'avons pas trouvé d'équivalent dans le code source de Dovecot 1.x (Debian stable). Avec v1.2, ca devrait fonctionner, car on a dans le code: ./src/login-common/client-common.h:#define LOGIN_MAX_INBUF_SIZE 8192
- make install de crudesaml
root@sogo-test-saml:/usr/local/src/crudesaml-1.4# make install make[1]: entrant dans le répertoire « /usr/local/src/crudesaml-1.4 » make[1]: Rien à faire pour « install-exec-am ». /bin/mkdir -p '/usr/local/share/man/man5' /usr/bin/install -c -m 644 pam_saml.5 cy2_saml.5 '/usr/local/share/man/man5' /bin/mkdir -p '/lib/sasl2' /bin/bash ./libtool --mode=install /usr/bin/install -c libsaml.la '/lib/sasl2' libtool: install: /usr/bin/install -c .libs/libsaml.so.0.2.0 /lib/sasl2/libsaml.so.0.2.0 libtool: install: (cd /lib/sasl2 && { ln -s -f libsaml.so.0.2.0 libsaml.so.0 || { rm -f libsaml.so.0 && ln -s li }) libtool: install: (cd /lib/sasl2 && { ln -s -f libsaml.so.0.2.0 libsaml.so || { rm -f libsaml.so && ln -s libsam libtool: install: /usr/bin/install -c .libs/libsaml.lai /lib/sasl2/libsaml.la libtool: install: /usr/bin/install -c .libs/libsaml.a /lib/sasl2/libsaml.a libtool: install: chmod 644 /lib/sasl2/libsaml.a libtool: install: ranlib /lib/sasl2/libsaml.a libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n /lib/sasl ---------------------------------------------------------------------- Libraries have been installed in: /lib/sasl2 If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- /bin/mkdir -p '/usr/local/lib/security' /bin/bash ./libtool --mode=install /usr/bin/install -c pam_saml.la '/usr/local/lib/security' libtool: install: /usr/bin/install -c .libs/pam_saml.so.0.2.0 /usr/local/lib/security/pam_saml.so.0.2.0 libtool: install: (cd /usr/local/lib/security && { ln -s -f pam_saml.so.0.2.0 pam_saml.so.0 || { rm -f pam_saml. pam_saml.so.0; }; }) libtool: install: (cd /usr/local/lib/security && { ln -s -f pam_saml.so.0.2.0 pam_saml.so || { rm -f pam_saml.so saml.so; }; }) libtool: install: /usr/bin/install -c .libs/pam_saml.lai /usr/local/lib/security/pam_saml.la libtool: install: /usr/bin/install -c .libs/pam_saml.a /usr/local/lib/security/pam_saml.a libtool: install: chmod 644 /usr/local/lib/security/pam_saml.a libtool: install: ranlib /usr/local/lib/security/pam_saml.a libtool: finish: PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/sbin" ldconfig -n /usr/loca ---------------------------------------------------------------------- Libraries have been installed in: /usr/local/lib/security If you ever happen to want to link against installed libraries in a given directory, LIBDIR, you must either use libtool, and specify the full pathname of the library, or use the `-LLIBDIR' flag during linking and do at least one of the following: - add LIBDIR to the `LD_LIBRARY_PATH' environment variable during execution - add LIBDIR to the `LD_RUN_PATH' environment variable during linking - use the `-Wl,-rpath -Wl,LIBDIR' linker flag - have your system administrator add LIBDIR to `/etc/ld.so.conf' See any operating system documentation about shared libraries for more information, such as the ld(1) and ld.so(8) manual pages. ---------------------------------------------------------------------- make[1]: quittant le répertoire « /usr/local/src/crudesaml-1.4 » root@sogo-test-saml:/usr/local/src/crudesaml-1.4#