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

{{toc}}

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 versions 1.2.0 et 1.3.1 de la librairie php-cas sur lesquelles 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'); // pointe sur la version 1.2.0

require_once('CAS-1.3.1/eoleCAS.php'); // pointe sur la version 1.3.1

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

eolephpCAS::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. Contrôle des certificats

Pour une meilleure sécurité, la validation par la CA devrait être activée.

Mais pour éviter trop de changement, on distingue selon la version d'Eole : 

* Eole 2.2, on ne change rien :

<pre>

    if (method_exists("EolephpCAS", "setNoCasServerValidation")){

         EolephpCAS::setNoCasServerValidation();

    }

</pre>

* Eole 2.3 : dans gen_config en mode expert, onglet Applications web, "activer_web_valider_ca" de type oui/non avec valeur par défaut à non

<pre>

    if (__CAS_VALIDER_CA) {  // gen_config : activer_web_valider_ca

        EolephpCAS::setCasServerCACert(__CAS_CA_LOCATION); // gen_config : eolesso_ca_location (onglet Eole-sso)

    } else {

        if (method_exists("EolephpCAS", "setNoCasServerValidation")){

            EolephpCAS::setNoCasServerValidation();

        }

    }

</pre>

L'utilisation de la fonction method_exists permet d'assurer la compatibilité avec les différentes versions 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 

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

<pre>

eolephpCAS::logout(array("url"=>$_SERVER["SCRIPT_URI"]));

</pre>

ou

<pre>

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

</pre>

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 

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ée, le serveur sso demande à chaque application de supprimer la session associée à l'utilisateur qui s'est déconnecté. 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ée dans le fichier configCAS/cas.inc.php. 

-A noter : cette fonction fournie 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ée (appel à session_name(nomdelasession)). 

Dans ce cas, préférez 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 (pour Eole 2.3)

<pre>

<?php

function cas_auth(){

   require_once('CAS-1.3.1/eoleCAS.php');

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

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

   if (__CAS_VALIDER_CA) {

       eolephpCAS::setCasServerCACert(__CAS_CA_LOCATION);

   } else {

       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-1.3.1/eoleCAS.php');

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

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

   if (__CAS_VALIDER_CA) {

       eolephpCAS::setCasServerCACert(__CAS_CA_LOCATION);

   } else {

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

           eolephpCAS::setNoCasServerValidation();

       }

   }

   eolephpCAS::logout(array("url"=>$_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 n'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, le fonctionnement est identique (au Cas n°1). 

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>

Le filtre "user=uid" est obligatoire.

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>

h2. Des applications externes

h3. Campus

<pre>

/usr/share/sso/app_filters/local_apps.ini

...

[campus]

baseurl=/LaureatsNet

scheme=https

addr=scolarite.net

typeaddr=dns

filter=attributs_campus

...

/usr/share/sso/app_filters/attributs_campus.ini

[utilisateur]

nom=sn

prenom=givenName

login=ENTPersonLogin

categories=ENTPersonProfils

dateNaissance=ENTPersonDateNaissance

codePostal=ENTPersonCodePostal

eleveClasses=ENTEleveClasses

uid=uid

rne=rne

</pre>

L'Url d'accès est : https://scolarite.net/LaureatsNet/IdentificationCasEOLE<codeRNE>

Doc en ligne : http://campuswiki.fr/index.php/Scolarite.net:CAS