Projet pam_cas
Pages enfant
  • 02 - Interfaçage Cyrus-imap avec CAS

Comparaison des versions

Ancienne version 2

changes.mady.by.user Pascal Aubry

Sauvegardée le

comparé à

Nouvelle version Actuel

changes.mady.by.user Pascal Rigaux

Sauvegardée le

Légende

  • Ces lignes ont été ajoutées. Ce mot a été ajouté.
  • Ces lignes ont été supprimées. Ce mot a été supprimé.
  • La mise en forme a été modifiée.

Sommaire

Problématique

Le portail doit pouvoir proposer un canal permettant d'apporter des informations sur la messagerie de l'utilisateur (nombre de mails non lus, ...).
Il est probable que ce canal doive lancer un webmail externe (IMP ?) lorsque l'utilisateur désire utiliser sa messagerie d'une manière plus intensive.

...

Ce document propose des solutions pour interfacer simplement CAS avec le serveur cyrus-imap, et les optimisations nécessaires.

Interfacer cyrus-imap avec CAS

Cyrus-imap s'appuie sur cyrus-sasl pour la partie authentification.
Cyrus-sasl est une librairie qui permet d'utiliser différents mécanismes d'authentification.
Parmi ceux-ci, il peut utiliser un 'démon' unix sachant parler différents protocoles ou méthodes, dont LDAP, pam, .... C'est salsauthd.

...

Les étapes sont les suivantes :

Coté pam

Il faut activer le pam_cas pour le service imap.

Voir : Documentation 01 - Installation et paramétrage de pam_cas.

Coté cyrus

  • Compiler cyrus-sasl avec l'option --with-saslauthd.
  • Dans le fichier /etc/imapd.conf, mettre sasl_pwcheck_method: saslauthd
  • Pour que saslauthd utilise pam, il faut le lancer avecl'option -a pam
  • pour optimiser le fonctionnement, saslauthd peut gérer un cache. C'est très utilise pour l'utilisation avec pam, engénéral.
    Pour activer le cache, il faut ajouter l'option -c
    D'autres options de gestion du cache (taille, ttl, ...) sont disponibles. Faire man saslauthd pour plus d'information.

...

En plus, un cache peut être activé, ce qui présente un grand intérêt. Le PT, qui est en principe un jeton non rejouable, peut le devenir pour cyrus-imap. Il devient en quelque sorte un identifiant de session spécifique, ce qui évite de recourir à tout le mécanisme d'acquisition puis de validation d'un PT à chaque requête.

Tests IMAP CAS-ifié

Un programme php utilisant phpCAS vous est fourni afin de tester la CAS-ification d'un serveur IMAP : casimap.php.

...

Cet utilitaire vous permet donc de tester un IMAP CAS-ifié, et son comportement vis à vis du cache de mot de passe. Il fonctionne en mode proxy CAS.

Personnalisation du script

 

Bloc de code

$cas_hostname="auth.univ.fr";         // c'est l'url du serveur CAS
   $cas_port=443;                        // le port d'accès https au serveur CA
   $cas_uri='';                          // l'uri de base du serveur CAS
   $imap_server="mail.univ.fr";          // le serveur imap à tester
   $imap_port=143;                       // le port imap
   $imap_box="INBOX";                    // le préfixe des boites IMAP
   $imap_service="imap://$imap_server";  // le service passé pour la récupération du PT. Doit être identique
                                         // au service paramétré dans pam-cas

Le 'service' passé au serveur CAS sera ici implicitement imap://mail.univ.fr. Si cela ne convient pas , écraser la variable $imap_service avec l'URL de service désiré.

Installation du script

Il faut bien sûr en préalable l'installation de phpCAS, avec ses pré-requis.

...

On suppose que le script est accessible à l'URL http(s)://test/univ.fr/casimap.php

Paramétrage pam_cas

Le fichier pam_cas sera paramétré comme indiqué dans la doc pam_cas.

  • paramètre de service (option -s) : doit contenir l'URL du service indiqué ci-dessus. Dans notre exemple :
    -simap://mail.univ.fr
  • paramètres de proxy (option -p) : doit contenir l'url du (ou des) proxies CAS qui vont utiliser le service imap CAS-ifié. A priori, il y aura au moins le socle ENT, et le webmail. Pour le test, il faut rajouter notre script. Donc, pour suivre l'exemple :
    -phttps://test.univ-nancy2.fr/casimap.php

Essais

Ce script est composé de 2 parties : une dédié au mécanisme CAS, une autre à un login imap 'classique'.

Partie 'CAS'

Différentes options sont possibles :

  • Obtenir un PGT : génère une redirection vers le serveur CAS afin d'obtenir un (nouveau) ST et PGT. C'est la première opération à faire pour tester le mécanisme CAS.
    Le PGT obtenu s'affiche à l'issue de cette opération.
    Il est possible de redemander successivement d'autres PGT.
  • Obtenir un PT : Ce bouton n'est visible que si l'on dispose au préalable d'un PGT.
    Le PT obtenu s'affiche à l'issue de cette opération.
    Il est possible de redemander successivement d'autres PT.
  • Ouvrir une connexion IMAP avec le PT Courant : test de la connexion IMAP avec le PT courant.
    Le résultat de la connexion IMAP s'affiche en tête du document W3 retourné.
    Il est possible de tester le cache IMAP en cliquant de nouvelles fois sur ce bouton sans réclamer de nouveaux PT.
  • Logout applicatif sans CAS. Permet de supprimer la session applicative, sans se déloguer de CAS.
  • Logout applicatif et CAS. Même chose que précédemment, avec un logout CAS.

Partie imap 'classique'

Cette seconde partie permet d'une part, de s'assurer que le script fonctionne correctement en imap 'classique', donc avec le login et mot de passe utilisateur, et d'autre part, d'apréhender l'écrasement du PT par le mot de passe utilisateur dans le cache IMAP.

Le résultat de la connexion IMAP s'affiche comme précédemment.

En cas de problème

  • De récupération de PGT ou de PT : voir les logs d'accès et d'erreur du serveur CAS et du serveur apache supportant le script de test.
  • De connexion imap : voir les logs d'accès et d'erreur du serveur CAS, et le fichier messages de la machine UNIX supportant le serveur IMAP CAS-ifié. Le code erreur des messages pam_cas donnent des indications sur le dysfonctionnement.

Si un PT est obtenu, mais que la connexion imap de fonctionne pas, redemander un nouveau PT.
En dessous du bouton "Ouvrir une connexion imap avec le PT courant", s'affiche une url du genre :

Bloc de code

https://auth.univ.fr:443/proxyValidate?ticket=PT-168270-aG...&service=imap://mail.univ.fr

Tenter de valider 'à la main' ce PT :
Depuis un serveur ayant un acces https vers le serveur CAS (le serveur imap est un bon candidat), lancer :

Bloc de code

wget --ca-certificate=/Cert/ac-racine.pem -O /tmp/cas.log "https://auth.univ.fr:443/proxyValidate?ticket=PT-168270-aG...&service=imap://mail.univ.fr"

...

Vous devez obtenir quelque chose comme celà dans le fichier /tmp/cas.log :

Bloc de code

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
  <cas:authenticationSuccess>
    <cas:user>vmathieu</cas:user>
    <cas:proxies>
      <cas:proxy>https://infocri.univ-nancy2.fr/~vmathieu/CAS/casimap.php</cas:proxy>
    </cas:proxies>
  </cas:authenticationSuccess>
</cas:serviceResponse>

Rem : il est possible de remplacer l'option --ca-certificate=/Cert/ac-racine.pem par --no-check-certificate lors du wget ; dans ce cas, un warning sera affiché.

Difficultés coté client imap

Après cette mise en oeuvre, on dispose d'un service imap sachant parler CAS (en plus des autres méthodes), avec une possibilité de cache du PT.

...

Ca semble relativement aisé au niveau du portail. Il est probable que ce ne soit pas aussi simple au niveau IMP à la fois pour cet aspect, et pour le promouvoir en proxy CAS.

...

Optimisation poussée

La mise en oeuvre précédente s'est faite sans aucune modification de code à tous niveaux.

On pourrait envisager une optimisation spécifique à notre projet, en Un patch modifiant le fonctionnement du cache de saslauthd.

Actuellement, il associe un 'mot de passe' (éventuellement donc, un PT) à un utilisateur.
On pourrait envisager qu'il associe 3 mots de passe à une personne :

  • le mot de passe habituel (dans notre cas, le mot de passe LDAP)
  • le PT venant du portail
  • le PT venant du webmail

Ca peut s'implémenter avec cyrus-imap, sans modification du source :

il est possible d'avoir 3 'instances' IMAP en attente sur 3 ports différents, et avec 3 caches différents (3 instances de saslauthd).

du démon saslauthd est proposé,  permettant d'associer plusieurs 'mots de passe' à un utilisateur.

Avertissement

Plutôt que de patcher saslauthd, il est maintenant plus simple d'utiliser la fonctionnalité "cacheDirectory" de la dernière version de esup-pam-cas.

 Donc, une instance sur les ports POP et IMAP traditionnels, pour les clients de messagerie standards, une instance dédié au webmail et une instance dédiée au portail.

Annexe : cinématique

Les schémas joints montrent la cinématique de l'authentification imap, dans différents cas.

Il suppose que le portail et le webmail ont déja acquis auprès du serveur CAS un PGT (Proxy Granting Ticket) pour l'utilisateur.

Première connexion imap depuis portail


 

  1. L'utilisateur provoque un évênement qui demande au 'canal' dédié à la messagerie d'accéder au serveur imap.
  2. Le portail dispose d'un PGT pour l'utilisateur. Il demande donc au serveur CAS un PT pour le service imap (appelons-le PT-A1).
  3. Il tente une connexion imap. Pour la phase de login imap, il va transmettre le login de l'utilisateur et le PT-A1.
  4. cyrus-imap fait appel au démon saslauthd pour authentifier ; il passe donc le login et le PT-A1.
  5. saslauthd n'a pas encore l'utilisateur dans son cache. Il passe donc ces 2 informations à l'interface pam. Celle-ci utilise pam_cas, et génère une requête https vers le serveur CAS avec ce PT. Le serveur CAS valide le PT, pam valide donc l'authentification pour saslauthd.
  6. saslauthd met en cache l'information user + password (ici, PT-A1).
  7. saslauthd valide l'authentification à cyrus-imap.
    La phase de login s'est donc bien déroulée.

Nouvelles connexions imap depuis le portail


 

  1. rafraichissement du 'canal imap'
  2. login imap avec le login, et le même PT qu'auparavant (PT-A1)
  3. cyrus-imap fait appel à saslauthd pour authentifier
  4. saslauthd consulte son cache. il trouve une entrée pour l'utilisateur. Le mot de passe (PT-A1) est valide. Il n'a pas besoin de faire appel à pam-cas
  5. L'authentification imap est effectuée

On voit bien que la procédure est beaucoup plus légère que précédemment.

Connexion IMAP depuis le webmail

On suppose maintenant que l'utilisateur vient de lancer le webmail IMP (depuis le portail, ou directement). IMP doit donc générer une connexion IMAP.
 
Le fonctionnement est identique au premier cas, sauf que saslauthd trouve une entrée pour l'utilisateur dans le cache ave PT-A1 comme mot de passe, alors que le mot de passe qui est proposé est un nouveau PT (appelé PT-B1).
saslauthd fait donc à nouveau appel à pam, qui valide. saslauthd met à jour son cache avec PT-B1, et authentifie la personne.

Nouvelles connexions imap depuis le webmail

identique à nouvelles connexions imap depuis le portail (second schéma)

Nouvelle connexion imap depuis le portail

On suppose que le portail doit à nouveau requêter IMAP.
Le 'canal' imap ne sait pas que le cache du serveur imap a changé. Le login IMAP va donc échouer :

...