[Obm] miniG et lemonLDAP

[Thomas Cataldo]

On Mon, 2009-07-06 at 16:49 +0200, SamSam wrote:
> Le 3 juillet 2009 16:42, Thomas Cataldo <tcataldo at gmail.com> a écrit :
>         Aujourd'hui le "serveur sso" intégré à OBM renvoie le mdp au
>         backend
>         minig qui s'authentifie alors sur cyrus.
>         
>         Evidemment cette solution est peu satisfaisante car dépendance
>         sur mdp
>         en clair, etc. La solution que nous envisageons :
>         
>         Fournir une implémentation alternative du démon saslauthd (le
>         protocole est en fait très basique). Le démon acceptera, par
>         exemple :
>          - le dialogue normal login:realm:password
>          - un dialogue "custom" login:realm:ticketSSO (par exemple un
>         des
>         headers positionné par lemonldap pourrait servir de ticket)
> 
> Ne serait-ce pas plus simple pour la maintenance de faire un module
> PAM et de baser saslauthd sur PAM, plutôt que de prendre en charge la
> réécriture d'un saslauthd ?

Cette solution nous a été suggérée sur les mailings list cyrus. Un
module pam est encore plus complexe à mon avis : 
language C quasi obligé => difficulté pour intérroger des sous système
complexes : valider des tickets sur des webservices + des annuaires,
etc. Recompilations sur toutes les distribs supportées par obm...

saslauthd est très simple en terme de protocole. Le travail ne se
complexifie qu'en fonction du type d'authentifications que nous
souhaitons supporter : LDAP et tickets sso dans un premier temps. De
plus une implémentation est possible dans n'importe quel language de
haut niveau supportant les sockets AF_UNIX (en gros perl pour ne pas
rajouter un language à obm).

> 
> on peut imaginer enchainer un module auth "sso" sufficient avec un
> module auth ldap. Minig s'authentifierai avec un password positionné
> "sso:ticketSSO" en mode SSO, et avec le mot de passe sinon. Le module
> PAM pourrait vérifier le ticket, l'IP associée, etc... sur un frontend
> cyrus partagé webmail/imap, ou bien même ne rien faire sur un frontend
> cyrus dédié au webmail.
> 
> Sam.

Celà fonctionnerait parfaitement, c'est simplement une question de
facilité d'implémentation et d'industrialisation sur chaque distrib.