Modifications entre les versions 7 et 8
⇤ ← Version 7 à la date du 2013-06-20 21:05:25 →
Taille: 16450
Éditeur: MoussaNombre
Commentaire: mise à jour
← Version 8 à la date du 2013-07-26 20:22:55 → ⇥
Taille: 17031
Éditeur: MoussaNombre
Commentaire: Bugs rapportés chez Inverse
Texte supprimé. Texte ajouté.
Ligne 181: Ligne 181:

== Bugs rapportés chez Inverse ==
 * [[http://www.sogo.nu/bugs/view.php?id=2376|SAML2 : SLO non fonctionnel]]
 * [[http://www.sogo.nu/bugs/view.php?id=2377|SAML2 : SLO déclenché depuis l'IdP non fonctionnel]]
 * [[http://www.sogo.nu/bugs/view.php?id=2378|SAML2 : modèle de méta-données (metadata)]]
 * [[http://www.sogo.nu/bugs/view.php?id=2379|SAML2 : redirection au moment du logout]]
 * [[http://www.sogo.nu/bugs/view.php?id=2380|SAML2 : impossible de voir la page d'accueil]]
 * [[http://www.sogo.nu/bugs/view.php?id=2381|SAML2 : suggestion d'options SOGo]]

Sommaire

  1. Tests d'intégration SOGo et SAML
    1. Serveur de test
    2. installation des paquets requis
    3. Dovecot pour authentification SAML
    4. Configuration de SOGo
    5. Travaux/Déboggage avec Inverse
    6. Des tests concluants ... mais plusieurs remarques
    7. Bugs rapportés chez Inverse
    8. Pour mémoire

Tests d'intégration SOGo et SAML

Serveur de test

  • copie du CT sogo-test.ca.auf.org ==> sogo-test-saml.ca.auf.org

  • installation en local de : dovecot-imapd (1:1.2.15-7) + postfix
  • sogo (nightly) : 2.0.5.20130405-1

installation des paquets requis

  • lasso (on appliquera le patch de Wolfgang)

    • pré-requis :
      • aptitude install zlib1g-dev
      • aptitude install pkg-config

      • configure: error: Package requirements (glib-2.0 >= 2.4.0 gobject-2.0 >= 2.4.0 libxml-2.0 xmlsec1 >= 1.2.6 xmlsec1-openssl >= 1.2.6 openssl) were not met :

        • aptitude install libglib2.0-dev (==> glib-2.0 >= 2.4.0 gobject-2.0)

        • aptitude install libxmlsec1-dev ==> libxml-2.0 xmlsec1 >= 1.2.6 xmlsec1-openssl >= 1.2.6 openssl

    • appliquer le patch de Inverse : patch -p0 lasso-export.diff

    • ./configure ; make ; make install (lire le INSTALL)

  • crudesaml (http://ftp.espci.fr/pub/crudesaml/crudesaml-1.4.tar.gz)

    • pré-requis :
      • aptitude install libsasl2-dev
      • aptitude install libpam0g-dev
      • modif du fichier plugin_common.h 
        • #include <saslplug.h> :
+typedef int (*sasl_callback_ft)(void);

      • ./configure && make && make install

    • les librairies aux bons endroits : 
      • root@sogo-test-saml:/usr/lib/sasl2# cp -a /lib/sasl2/* /usr/lib/sasl2/
root@sogo-test-saml:/usr/lib/sasl2# cp -a /usr/lib/security/pam_saml.so.0.2.0 /lib/security/pam_saml.so
    • vérification 
      • root@sogo-test-saml:/usr/lib/sasl2# saslpluginviewer
Plugin "saml" [loaded],         API version: 4
        SASL mechanism: SAML, best SSF: 0
        security flags: NO_ANONYMOUS
        features: WANT_CLIENT_FIRST|PROXY_AUTHENTICATION

Dovecot pour authentification SAML

  • /etc/pam.d/dovecot 

    • #%PAM-1.0

# SAML : cf man pam_saml
# http://www.ossir.org/paris/supports/2010/2010-02-09/saml.pdf
#auth required pam_saml.so grace=86400 userid=uid idp=/etc/ssl/saml-id.auf.org-metadata.xml trusted_sp=https://sogo-test-saml.ca.auf.org/SOGo/saml2-metadata saml_check_session_timeframe=0 saml_check_assertion_timeframe=0
auth required pam_saml.so grace=600 userid=uid idp=/etc/ssl/saml-id.auf.org-metadata.xml trusted_sp=https://sogo-test-saml.ca.auf.org/SOGo/saml2-metadata
account required                        pam_permit.so
session required                        pam_permit.so
  • patch apporté par JC 
    • 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".
      root@sogo-test-saml:/# git diff usr/local/src/crudesaml-1.4/saml.c
diff --git a/usr/local/src/crudesaml-1.4/saml.c b/usr/local/src/crudesaml-1.4/saml.c
index 415479a..f3121bb 100644
--- a/usr/local/src/crudesaml-1.4/saml.c
+++ b/usr/local/src/crudesaml-1.4/saml.c
@@ -153,9 +153,15 @@ saml_get_date(date)
        struct tm tm;
        const char *format = "%Y-%m-%dT%TZ";
 
-       if (strptime(date, format, &tm) == NULL)
-               return (time_t)-1;
+        char *date2 = strdup(date);
+        if (strchr(date2,'.') != NULL && strchr(date2,'Z') != NULL)
+               strcpy(strchr(date2,'.'), strchr(date2,'Z'));
 
+       if (strptime(date2, format, &tm) == NULL){
+               free(date2);
+               return (time_t)-1;
+       }
+       free(date2);
        return (timegm(&tm));
 }
 
root@sogo-test-saml:/#

Configuration de SOGo

  • modification de la config SOGo : 
    • defaults -u sogo write sogod SOGoAuthenticationType "saml2"
sogod SOGoSAML2IdpCertificateLocation /etc/ssl/certs/GandiStandardSSLCA.pem
sogod SOGoSAML2IdpMetadataLocation /etc/ssl/saml-id.auf.org-metadata.xml
sogod SOGoSAML2IdpPublicKeyLocation /etc/ssl/saml-id.auf.org-cert.pem
sogod SOGoSAML2CertificateLocation /etc/ssl/certs/saml-sogo-test-saml.ca.auf.org-cert.pem
sogod SOGoSAML2LogoutEnabled YES
sogod SOGoSAML2PrivateKeyLocation /etc/ssl/private/saml-sogo-test-saml.ca.auf.org-key.pem
  • restart de SOGo

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/

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

Bugs rapportés chez Inverse

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#

Projet/SOGo/TestsSAML (dernière édition le 2016-02-03 15:49:47 par MoussaNombre)