Tests d'intégration SOGo et SAML

Serveur de test

installation des paquets requis

Dovecot pour authentification SAML

Configuration de SOGo

Travaux/Déboggage avec 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 

Bugs rapportés chez Inverse


Pour mémoire

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