Outils pour utilisateurs

Outils du site


braveo:docinstall:cas:proxying:presentation

CAS proxying c'est quoi ? comment ça marche ?

Problématique, nécessité du proxying

Lorsque que nous avons mis en place notre CAS le problème de l'identification sur des interfaces web tel que roundcube, SOGo (webmail) ou encore jappix c'est vite posé. Car en effets ces interfaces utilisent les identifiants des utilisateurs pour se connecter sur d'autres serveurs : serveur imap pour roundcube et SOGo et serveur jabber (XMPP) pour jappix.

Or lorsqu'on identifie un utilisateur par le CAS on le fait via un ticket et à aucun moment le mot de passe de l'utilisateur n'est accessible par le service qui l'identifie (roundcube par exemple).

Il a donc fallu trouver une solution le CAS proxying, on remplace tout simplement le mot de passe par un ticket fournis par le CAS, puis transmis par le proxy ou CAS proxy client (roundcube) au service tiers ou Proxy Service (serveur imap). Il est donc nécessaire de relier le service tiers (serveur imap) au CAS pour qu'il puisse vérifier ce ticket.

Le déroulement du processus

Je vous conseil de suivre les étapes en vous aidant de ce schéma.

Dans notre exemple nous identifions l'utilisateur 'benvii' sur la webmail (mail.mdl29.net) à l'aide du CAS (cas.mdl29.net).

Voici les différentes étapes :

étape 1 : identification classique, obtention du Service Ticket (ST)

Le service redirige l'utilisateur vers le CAS :

Location: https://cas.mdl29.net/login?service=https://mail.mdl29.net

 Schéma L'utilisateur est déjà connecté au CAS ou se connecte, il est alors redirigé vers le service ici la webmail avec un Service-Ticket (ST) :

Location: https://mail.mdl29.net/?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS

 Schéma


étape 2 : Vérification du Service Ticket et demande pour devenir proxy

Contrairement à la démarche classique on ne se contente pas de vérifier d'identité de l'utilisateur, en plus de cela on demande un PGT Proxy Granting Ticket. Pourquoi avoir besoin de ce ticket ?

Tout simplement car ce ticket sera utilisé (plusieurs fois s'il le faut) pour demander des Proxy Ticket (PT) pour d'autres services comme notre serveur imap par exemple. En d'autres termes, ce ticket donne le privilège a l'interface roundcube de demander des PT pour d'autres services et de les distribuer à ces services. Les Proxy Ticket sont des ST à la différence qu'ils ne proviennent pas directement du CAS mais passent par un proxy, tout comme les ST ils ne sont utilisables qu'une fois.

On utilise donc le ST de l'étape 1 pour obtenir ce PGT et donc ce droit de demander des ST pour d'autres services :

GET https://cas.mdl29.net/serviceValidate?ticket=ST-956-Lyg0BdLkgdrBO9W17bXS&service=https://mail.mdl29.net&pgtUrl=https://mail.mdl29.net/

Résultat :

  <cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
      <cas:authenticationSuccess>
        <cas:user>benvii</cas:user>
    <cas:proxyGrantingTicket>PGTIOU-85-8PFx8qipjkWYDbuBbNJ1roVu4yeb9WJIRdngg7fzl523Eti2td</cas:proxyGrantingTicket>
      </cas:authenticationSuccess>
  </cas:serviceResponse>

 Schéma

Vous remarquerez qu'on a obtenu un PGTIOU et non un PGT ! En effet le CAS ne se laisse pas faire comme ça =) . Aller avec un petit dialogue ça passera mieux :

- Webmail : Salut je suis https://mail.mdl29.net/ je voudrais un PGT
- CAS : Ok mais je vais d'abord vérifier que vous êtes bien https://mail.mdl29.net/ pour cela je vais vous donner un PGTIOU, puis je vais envoyer moi-même une requête chez https://mail.mdl29.net/ contenant ce PGTIOU et le PGT que vous demandez. Si vous êtes bien https://mail.mdl29.net/ vous pourrez alors retrouver le PGT à l'aide du PGTIOU.
- Webmail : Ok merci, je prends le PGTIOU et j'attends votre requête ..

 Schéma


étape 3 : Récupération du PGT

Le CAS à donc envoyé une requête contenant le PGT et le PGTIOU on peut la retrouver dans les logs par exemple :

mail.mdl29.net - - [10/Dec/2003:09:28:15 +0000] "GET /?pgtIou=PGTIOU-85-8PFx8qipjkWYDbuBbNJ1roVu4yeb9WJIRdngg7fzl523Eti2td&pgtId=PGT-330-CSdUc5fCBz3g8KDDiSgO5osXfLMj9sRDAI0xDLg7jPn8gZaDqS HTTP/1.1" 200 13079

Voilà il n'y a plus qu'a le récupérer, bien-sûr des scripts/librairies tel que phpCas ou autre ne se base pas sur les logs, lorsque la requête est envoyée ils stockent le PGTIOU et le PGT dans une base de donnée ou autre …


étape 4 : Demande d'un PT pour le serveur imap

Toujours dans l'optique de connecter notre utilisateur à son compte imap via roundcube, nous avons récupéré l'identifiant à l'étape 2, nous allons maintenant récupérer le mot de passe qui est en réalité un Proxy Ticket.

On effectue donc une demande pour le service imap://mail.mdl29.net, avec le PGT :

https://cas.mdl29.net/proxy?targetService=imap://mail.mdl29.net&pgt=PGT-330-CSdUc5fCBz3g8KDDiSgO5osXfLMj9sRDAI0xDLg7jPn8gZaDqS

 Shéma La réponse :

  <cas:serviceResponse>
    <cas:proxySuccess>
        <cas:proxyTicket>PT-957-ZuucXqTZ1YcJw81T3dxf</cas:proxyTicket>
    </cas:proxySuccess>
  </cas:serviceResponse>

 Schéma

Voilà on as notre PT plus qu'a le mettre à la place du mot de passe et c'est bon.

 Schéma


étape 5 : Procédure de vérification du PT

Cette étape explique juste comment le serveur imap/XMPP va vérifier le PT :

https://cas.mdl29.net/proxyValidate?service=imap://mail.mdl29.net&ticket=PT-957-ZuucXqTZ1YcJw81T3dxf

 Schéma Réponse :

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
      <cas:authenticationSuccess>
          <cas:user>endjs</cas:user>
          <cas:proxies>
              <cas:proxy></cas:proxy>
          </cas:proxies>
      </cas:authenticationSuccess>
</cas:serviceResponse>

Schéma

Cette action sera effectué par pam que nous verrons plus tard.




Prêts a poursuivre ? Allons relier notre serveur imap au CAS : CASsification via PAM


Rédigé par Benjamin Bernard
Source : Proxy CAS Walkthrough - Central Authentication Service - Jasig Wiki

braveo/docinstall/cas/proxying/presentation.txt · Dernière modification : 2024/04/16 22:34 de 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki