Distribution EOLE » Outils Eole » SSO » eole-php5-cas

h1. Cassification d'une application sur Scribe 

Scribe est fourni avec un serveur d'authentification SSO compatible CAS. Cette page a pour objectif de guider les utilisateurs (administrateurs) de Scribe à utiliser le mode SSO dans leurs applications web php. Les indications fournies permettent de garantir la compatibilité avec les version 0.5 et 1.0.1 de la librairie php-cas sur laquelle se base le paquet php5-cas.

h2. Cas n°1 : authentification simple 

Ici, seule l'authentification de l'utilisateur est nécessaire (l'application ne requiert aucune autre information). La cassification de l'accès à une page reste très simple (fonctionnement du Cas classique). On utilisera la configuration centralisée située dans /usr/share/php/configCAS/cas.inc.php. 

h3. Initialisation du client 

<pre>

<?php

require_once('CAS/eoleCAS.php');

require_once('configCAS/cas.inc.php');

phpCAS::client(__CAS_VERSION, __CAS_SERVER, __CAS_PORT, __CAS_URL, false);

</pre>

Les variables __CAS... sont configurées dans le fichier 'cas.inc.php'. La variable à false signifie qu'une session php a déjà été démarrée avant l'appel au client.

Si __CAS_URL n'existe pas dans la conf on peut l'ajouter dans cas.inc.php de l'appli et l'initialiser à "" cf webcalendar ou ajaxplorer

h3. Désactivation du contrôle de certificats

En attendant une méthode stable de gestion des certificats, nous utiliserons la méthode setNoCasServerValidation : 

<pre>

if (method_exists(eolephpCAS, 'setNoCasServerValidation')){

        eolephpCAS::setNoCasServerValidation();

}

</pre>

L'utilisation de la fonction method_exists permet d'assurer la compatibilité avec les différentes version du client phpCas (paquet php5-cas) 

h3. Authentification 

<pre>

eolephpCAS::forceAuthentication();

</pre>

La redirection vers le serveur CAS est effectuée si nécessaire, par la suite le code est exécuté dans un contexte authentifié.

h3. Déconnexion 

<pre>

if (isset($_REQUEST['logout'])) {

    if (method_exists(eolephpCAS, 'logoutWithUrl')){

        eolephpCAS::logoutWithUrl($_SERVER["SCRIPT_URI"]);

    }else{

        eolephpCAS::logout($_SERVER["SCRIPT_URI"]);

    }

}

</pre>

La variable de redirection ici : $_SERVER["SCRIPT_URI"]  peut être remplacée par la page de logout prévue au départ dans l'application. 

Nouvelle méthode : https://wiki.jasig.org/display/CASC/phpCAS+logout

eolephpCAS::logout(array("url"=>$url));

ou

eolephpCAS::logout(array("service"=>$service));

Dans le premier cas, on est redirigé après déconnexion vers la page $url.

Dans le deuxième cas, on est redirigé sur la mire d'authentification prête pour se reconnecter sur le service $service.

h3. Déconnexion centralisée 

Le serveur CAS au moment de la déconnexion d'une application, appelle la déconnexion des différentes applications ayant une session SSO ouverte.

<pre>

if (__CAS_LOGOUT){

    if (method_exists(eolephpCAS, 'eolelogoutRequests')){

        eolephpCAS::eolelogoutRequests(false);

    }

}

</pre>

La variable __CAS_LOGOUT est configuré dans le fichier configCAS/cas.inc.php. 

A noter : cette fonction fournit par le client CAS d'origine a un fonctionnement très limité, elle ne fonctionne pas lorsque le nom de la session est forcé par l'application cassifié (appel à session_name(nomdelasession)). 

Dans ce cas, préféré l'utilisation de la librairie eolePhpCAS. 

h3. Forcer l'url de votre application auprès du serveur CAS

Dans certains cas, par exemple : 

Accès au travers d'un reverseproxy d'une application http par le protocole https et port 80 fermé sur le reverseproxy.

Il peut être utile de forcer l'url de l'application.

<pre>

eolephpCAS::setFixedServiceURL("https://adressedemonapplication");

</pre>

Il est possible de construire l'url depuis les variables php ($_SERVER par exemple).

h3. Récupération du login de l'utilisateur

<pre>

eolephpCAS::getUser();

</pre>

h3. Le tout dans des fonctions

<pre>

<?php

function cas_auth(){

   require_once('CAS/eoleCAS.php');

   require_once('configCAS/cas.inc.php');

   eolephpCAS::client(__CAS_VERSION, __CAS_SERVER, __CAS_PORT, __CAS_URL, false);

   if (method_exists(eolephpCAS, 'setNoCasServerValidation')){

        eolephpCAS::setNoCasServerValidation();

   }

   if (__CAS_LOGOUT){

       if (method_exists(eolephpCAS, 'eolelogoutRequests')){

          eolephpCAS::logoutRequests(false);

       }

   }

   eolephpCAS::forceAuthentication();

}

function cas_logout(){

   require_once('CAS/eoleCAS.php');

   require_once('configCAS/cas.inc.php');

   eolephpCAS::client(__CAS_VERSION, __CAS_SERVER, __CAS_PORT, __CAS_URL, false);

   if (method_exists(eolephpCAS, 'setNoCasServerValidation')){

        eolephpCAS::setNoCasServerValidation();

   }

   if (method_exists(eolephpCAS, 'logoutWithUrl')){

        eolephpCAS::logoutWithUrl($_SERVER["SCRIPT_URI"]);

    }else{

        eolephpCAS::logout($_SERVER["SCRIPT_URI"]);

    }

}

?>

</pre>

Du coup dans ma page php: 

<pre>

<?php Ce qui s'exécute ici n'est pas authentifié ?>

<?php 

cas_auth();

?>

<?php Ici on exécute que du code authentifié avec le user : eolephpCAS::getUser(); ?>

</pre>

h2. Cas n°2 : authentification avec récupération de données utilisateurs 

Lors de l'authentification CAS, pour récupérer des données utilisateurs en parallèle,

il faut utiliser le client eolephpCAS au lieu de phpCAS. Le fonctionnement est identique (au Cas n°1). 

h3. Initialisation du client 

Identique au Cas n°1 (remplacer phpCAS par eolephpCAS).

h3. Désactivation du contrôle de certificats

Identique au Cas n°1 (remplacer phpCAS par eolephpCAS).

h3. Authentification

Identique au Cas n°1 (remplacer phpCAS par eolephpCAS).

h3.Déconnexion

Identique au Cas n°1 (remplacer phpCAS par eolephpCAS).

h3. Déconnexion centralisée 

<pre>

if (method_exists(eolephpCAS, 'eoleLogoutRequests'){

    eolephpCAS::eoleLogoutRequests(false)

}

</pre>

Lorsque l'on se déconnecte d'une application, celle-ci supprime généralement sa session et demande sa déconnexion du serveur SSO. Les sessions des autres applications ne sont pas supprimées dans ce processus et (la plupart du temps), l'application conserve les informations de connexion dans sa session et conserve donc la connexion. Lors de l'activation de la fonction de déconnexion centralisé, le serveur sso demande à chaque application de supprimer la session associée à l'utilisateur qui s'est déconnecté. Pour que les applications prennent en compte cet appel, il faut rajouter un appel à la fonction 

<pre>

eolephpCAS::eoleLogoutRequests(false). 

</pre>

h3. Récupération des informations utilisateurs 

<pre>

$user_login = eolephpCAS::getUser();

$user_details = eolephpCAS::getDetails();

</pre>

Les détails utilisateurs sont renvoyés sous forme de Array php.

Les données qu'ils contiennent dépendent du filtre sso configuré pour l'application.

h4. Configuration du filtre SSO

Le serveur SSO est capable de fournir des données utilisateurs aux applications sous la forme de xml. Un filtre par défaut se contente de fournir l'uid de l'utilisateur qui se connecte, mais tout un ensemble de données peut être fournit.

h5. Première étape : configurer l'application dans un fichier monfiltre_apps.ini que l'on place dans /usr/share/sso/app_filters/

On renseigne "url" et "filtre" qui sont l'url et le filtre associés. 

Quand l'url "http://adresse/lechemin" me demande d'authentifier quelqu'un, une fois authentifiée, je lui renvoie les données renseignées dans le filtre 'monfiltre'.

<pre>

[democas]

baseurl=/lechemin

scheme=http

addr=0/0

typeaddr=ip

filter=monfiltre

</pre>

h5. Deuxième étape : configurer le fichier filtre monfiltre.ini 

<pre>

[user]

user=uid                

[infos] 

user_groups=user_groups

typeadmin=typeadmin

rne=rne

</pre>

Autres propriétés que l'on peut récupérer et donc assigner dans monfiltre.ini:

    * cn=cn

    * user_groups=user_groups

    * employeeType=employeeType

    * typeadmin=typeadmin

    * pam=pam

    * user=uid

    * profil=profil

    * classe=Divcod

    * firstname=givenName

    * lastname=sn

    * email=mail

    * ctemail=mail_acad

    * fullname=displayName

    * civil=codecivilite

    * codeRNE=rne

    * nomEtab=nom_etab

    * typeEtab=typeEtab

    * uid=secureid

    * ENTEleveNivFormation=Meflcf

    * ENTPersonProfils=profilcns 

(voir la documentation pour l'accès aux informations ldap)

A cette étape le serveur eole-sso nécessite d'être recharger pour prendre votre nouveau filtre en compte:

<pre>

/etc/init.d/eole-sso restart

</pre>

h5. Troisième étape : récupérer les données dans le script PHP 

*Sous forme de XML*

Dans le script php appeler la méthode getCasXML() de la manièe suivante:

<pre>

eolephpCAS::getCasXML()

</pre>

Ici, les données récupérées pour l'utilisateur courant sont :

<pre>

<?xml version="1.0" encoding="UTF-8"?>

<cas:serviceResponse xmlns:cas="http://www.yale.edu/tp/cas">

    <cas:authenticationSuccess>

        <cas:infos>

            <cas:typeadmin>2</cas:typeadmin>

            <cas:rne>1234567X</cas:rne>

            <cas:user_groups>domainusers</cas:user_groups>

            <cas:user_groups>professeurs</cas:user_groups>

            <cas:user_groups>math</cas:user_groups>

            </cas:infos>

        <cas:user>

            <cas:user>prof5e1</cas:user>

        </cas:user>

      </cas:authenticationSuccess>

</cas:serviceResponse>

</pre>

*Sous forme de tableau PHP*

Dans le script php appeler la méthode getDetails() de la manière suivante:

<pre>

eolephpCAS::getDetails()

</pre>

La méthode retourne un tableau associatif à plusieurs dimensions(tableau de tableaux).

Si on suit l'exemple du filtre monfiltre.ini le tableau renvoyé contient deux tableaux dont les clés correspondent aux étiquettes [user] et [infos] définies dans monfiltre.ini.

La clé du tableau contenu à la clé [user] est le nom donné dans notre exemple monfiltre.ini : "user="

[user][user][0] contient l'uid.

Ici les données renvoyées pour l'utilisateur courant sont :

<pre>

Array ( [infos] => Array ( [typeadmin] => Array ( [0] => 2 ) [rne] => Array ( [0] => 1234567X ) [user_groups] => Array ( [0] => domainusers [1] => professeurs [2] => math ) ) [user] => Array ( [user] => Array ( [0] => prof5e1 ) ) 

</pre>

h4. Récupération des informations utilisateurs construites 

Il est possible de renvoyer des données utilisateurs autre que celle du ldap.

Il est possible de fournir un script python au serveur SSO qui fournit des données plus complexes. 

Exemple l'envoi de données sorties de la configuration du serveur dans un fichier rne.py (utilisé dans l'exemple):

<pre>

	def calc_info(user_infos):

	    """ renvoie le rne de l'étab de l'uitilisateur """

	    from creole.parsedico import parse_dico

	    return [parse_dico().get('numero_etab', 'renvide')]

</pre>