Guide d interfaçage SSO Connexion des ressources aux plates-formes de type Corrélyce. Sommaire. Titre du document

(1)

CRDP

ACADÉMIED’AIX-MARSEILLE 31, bd d’Athènes 13232 Marseille cedex 1 T 04 91 14 13 12 F 04 91 14 13 00 www.crdp.aix-marseille.fr Établissement public

administratif régi par les articles D314-70 et suivants du Code de l’éducation

Affaire suivie par G. Puimatto, Directeur adjoint

[email protected]

Guide d’interfaçage SSO

Connexion des ressources aux plates-formes de type Corrélyce

Sommaire

Contenu de ce document ... 2

1. Présentation générale de CAS ... 3

1.1. Intérêt ...3

1.2. Fonctionnement de base ...3

1.3. Fonctionnement en mode proxy-CAS ...4

1.4. Notions de TGC et ST ...5

1.5. Fonctionnement en mode Proxy-CAS ...5

2. Implémentation côté éditeur ... 6

2.1. Création d'une page d'accès à la ressource ...6

2.2. Informations mises à disposition à l’issue d’une connexion réussie ...7

2.3. Liaison avec l’url d’accès ...7

2.4. Tests ...7

2.5. Exemples de flux XML CAS ...8

3. Exemples de code utilisables pour la réalisation de la page d’accès ... 8

3.1. Principe fonctionnel ...8

3.2. Les exemples de code proposés ci-après ...9

3.3. Licence.txt ...9

3.4. Ressource.php ... 10

3.5. Single_cas_secure.php ... 11

3.6. Multiple_cas_secure.php ... 12

3.7. Lib.php ... 13

3.8. Corree.php... 14

3.9. Login.php ... 17

3.10. Logout.php... 18

Titre du document Guide d’interfaçage SSO – Courdecol13 Nom du document CycDiff_GuideSSO_C13_230812.pdf

Date 23 Aout 2012 Version 2 /Courdecol13

Auteur(s) CRDP de l’académie d’Aix-Marseille - Alexandre Mathieu, Nicolas Michel, Gérard Puimatto

Observations « Guide d’interfaçage SSO -

Connexion des ressources aux plates-formes de type Corrélyce » réalisé par le CRDP de l'académie d'Aix-Marseille est mis à disposition selon les termes de la licence Creative Commons Attribution - Pas d'Utilisation Commerciale - Partage dans les Mêmes Conditions 3.0 France.

(2)

CRDP de l’Académie d’Aix-Marseille page 2 Aout 2012

CONTENU DE CE DOCUMENT

Ce document est destiné aux correspondants techniques des éditeurs de ressources en ligne souhaitant intégrer leurs ressources dans l’une des plateformes dérivées de Corrélyce (Corrélyce, Courdecol13, Coréprim, etc.).

Il décrit techniquement les protocoles d’interfaçage des ressources en accès SSO, notamment les modes CAS utilisés.

En annexe, des exemples de codes sont fournis pour éclairer les explications et fournir une base de travail aux programmeurs de ces interfaces.

Dans les pages qui suivent, Courdecol13 désigne l’application qui assure le fonctionnement de la plate-forme.

Le cœur de ces plateformes, décrit ci-dessous, est fondé sur une organisation de type « socle ENT », appuyé sur le système SSO (Single Sign On, authentification unique). Au-delà de la facilité de ne pas avoir à ressaisir l’identification pour chaque service accédé, le SSO permet aussi d’ouvrir des canaux d’accès aux ressources d’éditeurs tiers sans avoir à communiquer d’informations nominatives.

Le recours au SSO sans transmission d’identifiants nominatifs est le principe de base adopté pour la connexion aux ressources via les ENT, notamment décrit par le SDET et les avis de la CNIL.

Figure 1 - Organisation générale

Les ressources peuvent être gratuites ou payantes, soumises à contrôle d’accès ou pas. Le dispositif évoqué ici vise à décrire les accès aux ressources à accès contrôlé, qu’elles soient gratuites ou payantes.

La propagation de l’authentification vers les ressources utilise le protocole CAS.

(3)

Corrélyce et Corrélyce-diffusion sont des marques déposées par la Région PACA Courdecol13 est une marque déposée par le Conseil Général des Bouches du Rhône

Corédu et Coréprim sont des marques déposées par le CRDP de l’académie d’Aix-Marseille page 3 1. PRESENTATION GENERALE DE CAS

CAS est un système d'authentification unique développé par l'Université de Yale¹. C'est un mécanisme très fiable, qui est implanté dans de nombreuses universités et organismes dans le monde. CAS est une application Web écrite en Java et distribuée comme un logiciel libre.

1.1. Intérêt

CAS évite de s'authentifier à chaque fois qu'on accède à une application en mettant en place un système de ticket. C’est un système de SSO : on s'authentifie sur un site web, et on est alors authentifié sur tous les sites web qui utilisent le même serveur CAS.

1.2. Fonctionnement de base

Dans son fonctionnement de base, une application CASifiée² s'en remet à CAS pour son authentification. Lors de l'accès d'un utilisateur à une page protégée, le serveur CAS est interrogé. Si l’utilisateur est identifié sur le serveur CAS, c’est cette identification qui est soumise au service demandé ; si l’utilisateur n’est pas authentifié sur le serveur CAS, la fenêtre d’authentification est affichée.

L’existence d’une authentification sur le serveur CAS est conservée sur le navigateur du client sous la forme d’un cookie. De même, tous les échanges entre l’application demandée et le serveur CAS sont réalisés au moyen de redirections via le navigateur (http 302).

Figure 2 - Synoptique simplifié des échanges (utilisateur non authentifié sur le CAS)

1 Central Authentication Service : http://www.ja-sig.org/products/cas/index.html.

2 Une application CASsifiée est une application qui se connecte à un serveur CAS pour son identification.

Navigateur web

(utilisateur)

Serveur CAS

Application cassifiée

1 - demande initiale 2 - demande authentification

3 - authentification

4 – auth OK : TGC + ST

4 – transmission ST

5 – validation ST TGC

(4)

Figure 3 - Synoptique simplifié des échanges (2ème connexion utilisateur déjà authentifié sur le CAS)

Dans les Applications Coré, une version de CAS plus élaborée a été choisie, qui simplifie l’interface côté page de l’éditeur. Il s’agit du « Proxy CAS »

1.3. Fonctionnement en mode proxy-CAS

En mode Proxy CAS, une application mandataire assure la gestion des accès.

Figure 4 - Mode Proxy CAS, première connexion

Navigateur web

(utilisateur)

Serveur CAS

Application cassifiée

1 - demande initiale 2 - demande authentification 3 – TGC OK : transmission ST

4 – validation ST TGC

(5)

Corédu et Coréprim sont des marques déposées par le CRDP de l’académie d’Aix-Marseille page 5 Figure 5 - Mode Proxy CAS, session CAS déjà ouverte

1.4. Notions de TGC et ST

1.4.1. Ticket-Granting Cookie (TGC)

Le TGC, présent dans les schémas précédents, est un cookie de session qui est transmis par le serveur CAS au navigateur du client lors de la phase de login. Ce cookie ne peut être lu / écrit que par le serveur CAS, sur canal sécurisé (https). Il est présent durant toute la session de l'utilisateur et permet d'obtenir des Service Ticket auprès du serveur CAS.

Si le navigateur web n'accepte pas les cookies, l'utilisateur devra se ré-authentifier à chaque appel au serveur CAS.

1.4.2. Service Ticket (ST)

Ce ticket va servir à authentifier une personne pour une application web donnée. Il est envoyé par le serveur CAS après que l'utilisateur s'est authentifié et est transporté dans l'URL.

Ce ticket ne peut être utilisé qu'une seule fois. Il y a ensuite dialogue direct entre l'application web et le CAS via un GET http (sous la forme d’une redirection http 302 sur le navigateur), avec le ST en paramètre. En réponse, le serveur CAS retourne l'identifiant de la personne, et donc l'authentifie. Il invalide également le ticket (libération des ressources associées).

En fait, ce ticket concerne une personne, pour un service ; il n’est utilisable qu’une seule fois.

1.5. Fonctionnement en mode Proxy-CAS

Le fonctionnement en mode proxy permet à une application proxy-CAS de donner accès à d'autres applications clientes sous condition. Ces applications clientes valideront le ticket transmis par l'application proxy auprès du serveur CAS.

• c'est l'application proxy qui est chargée de faire tous les tests nécessaires pour autoriser ou non l'accès à l'application cliente demandée (i.e. générer ou non le PT nécessaire)

• l'application cliente ne peut être accédée par l'utilisateur qu'en passant par l'application proxy

1.5.1. Proxy-Granting-Ticket (PGT)

Il est envoyé par le serveur CAS à une application web « proxy-CAS » disposant d'un ST valide. Ce ticket confère au proxy CAS la possibilité de demander au serveur CAS de générer un Proxy Ticket (PT) pour une application tierce et une personne donnée.

5 – transmission PT

Navigateur web (utilisateur)

Serveur CAS

Connecteur mandataire

cassifié

1 - demande initiale 2 - demande authentification 3 – auth OK : TGC + ST

Application cible

4 – demande PT

6 – validation PT TGC

PGT

(6)

1.5.2. Proxy-Ticket (PT)

Il est généré par le serveur CAS à la demande d'un proxy CAS. Il permet d'authentifier l'utilisateur pour un service distant, avec lequel le client web n'a pas d'accès direct. Le service distant l'utilisera comme le ST, mais sur une URL différente.

CAS dispose alors de deux services distincts pour la validation de ses tickets : serviceValidate (pour les ST) et proxyValidate (pour les PT). Le PT est lié au service distant et n'est pas réutilisable.

Selon les implémentations de CAS, le PT peut aussi être désigné par les initiales ST.

2. IMPLEMENTATION COTE EDITEUR

L'utilisation de CAS pour gérer les accès à une application en ligne est basée sur des standards de l'Internet (http, https et xml) et ne requiert pas de langage de programmation particulier.

Pour pouvoir prendre en compte les demandes d'accès, deux opérations sont nécessaires :

• mettre en place une page d'accès à la ressource ;

• Indiquer l'adresse de cette page dans les données de description de la ressource dans le catalogue.

2.1. Création d'une page d'accès à la ressource

La page d'accès à la ressource doit être une page « dynamique » (dans un langage tel que Java, PHP, ASP, etc.).

Le programme inclus dans cette page doit vérifier les droits de l’appelant, en s’appuyant sur les services CAS, puis, si les conditions sont réunies, ouvrir l’accès.

Pour vérifier les droits de l'appelant, il est nécessaire de réaliser les actions suivantes :

1. vérifier qu'un paramètre nommé « ticket » est bien passé en paramètre, sinon afficher un message d'erreur ;

2. appeler la page de validation par le proxy CAS avec 2 paramètres : - « ticket » : le paramètre ticket passé en paramètre URL ;

- « service » : l'URL de la page courante. Attention, l'URL de cette page doit être celle inscrite dans la notice du catalogue. En effet, le ticket PT généré par CAS prend en compte cette URL et la validation du PT vérifie la correspondance de l'URL passée lors de la génération du PT avec l'URL de la page courante.

3. analyser la réponse XML du serveur CAS :

- erreur d'authentification : afficher une erreur à l'utilisateur ;

- authentification réussie : extraire les informations d'identifiant numérique d'utilisateur, sa classe, son rôle, le SIREN et le RNE de son établissement et donner accès à la ressource.

Les exemples de code donnés plus loin permettent d’illustrer ces traitements.

Notes :

Les librairies clientes CAS disponibles dans de nombreux langages de programmation3 cachent ces échanges clients-serveurs. Il suffit généralement de leur fournir l'adresse du serveur CAS et d'indiquer que la page est un client proxy CAS. Leur utilisation ne permet toutefois pas toujours de se connecter à Corréé, compte tenu de l’utilisation d’un format de ticket non standard.

Un éditeur / diffuseur qui propose plusieurs ressources à Courdecol13 n'est pas obligé de mettre en place une page d'accès par ressource mais peut proposer un point d'entrée unique avec un paramètre URL différent, ou une redirection d’URL, par ressource (paramètre « idressource » par exemple qui contient un identifiant unique de ressource dans le système de l'éditeur).

3 Voir la page http://www.ja-sig.org/wiki/display/CASC/Clients .

(7)

Corédu et Coréprim sont des marques déposées par le CRDP de l’académie d’Aix-Marseille page 7 2.2. Informations mises à disposition à l’issue d’une connexion réussie

Les tags XML à extraire de la validation réussie du « jeton » renvoyé par Courdecol13 sont :

cas:user identifiant numérique unique d'un utilisateur

cas:siren Siren de l'établissement (ou de l'entreprise pour un éditeur)

cas:rne RNE de l'établissement (ou de l'entreprise pour un éditeur) (optionnel) cas:profile « EDITEUR », « ELEVE », « PROFESSEUR » ou « AUTRE »

cas :class classe de l'élève ou classes de l'enseignant (optionnel)

On notera que le flux XML retourné par le serveur proxy-CAS ne contient en aucun cas d’identification nominative de l’usager. Les informations fournies permettent de garantir que chaque utilisateur dispose d’un identifiant numérique stable, ce qui permet si nécessaire de conserver ses informations de session ou de suivi d’une session à l’autre. Les données complémentaires d’établissement, profil et classe permettent un suivi statistique et un profilage des accès.

Dans la grande majorité des cas, les informations nominatives ne sont pas strictement utiles au fonctionnement des applications. Ce mode de fonctionnement permet d’éviter pour le contributeur les contraintes techniques, réglementaires et légales de gestion d’un annuaire.

Dans le cas où les informations nominatives sont jugées indispensables au fonctionnement, le contributeur doit assurer l’alimentation de son propre annuaire par d’autres voies, et appuyer son fonctionnement sur une déclaration CNIL autonome et le respect des droits des usagers en la matière. La continuité entre l’authentification plate-forme et l’application est alors assurée par la tenue d’une table d’équivalence entre l’identifiant cas:user transmis et l’usager déclaré dans l’annuaire de l’application. Cette table peut être générée en demandant à l’usager de saisir lors de sa première connexion via Courdecol13 son identifiant propre à l’application (uniquement pseudo, ni nom, ni prénom). Il convient toutefois d’éviter au maximum cette configuration.

2.3. Liaison avec l’url d’accès

Lors de la validation d’un titre, le contributeur est invité à renseigner l’adresse URL de la page d’accès cassifiée à la ressource. Cette URL est liée à la plate-forme utilisée, car elle contient l’adresse du serveur d’authentification à interroger.

• Pour les versions permettant l’import de notices LOMFR réalisées avec LOMFRPAD, cette URL doit être saisie dans la section « 4.3 localisation » de la notice documentaire LomFR correspondante.

• Pour les versions fondées sur le moissonnage de Coredu, l’URL est saisie par l’éditeur dans le formulaire de validation de la ressource, après saisie des informations commerciales.

Attention, l'URL de la page d’accès Cassifiée doit être celle inscrite dans cette entrée de la description LOMFR.

En effet, le ticket PT généré par CAS prend en compte cette URL et la validation du PT vérifie l'adéquation de l'url passée lors de la génération du PT et l'URL courante.

Cette information est visible uniquement par l'éditeur de la ressource ou par l'administrateur et n'apparaît pas lors de consultations publiques du catalogue.

2.4. Tests

Les tests d'accès à la ressource peuvent être effectués directement par les contributeurs dans leur interface de gestion des titres :

• menu « gestion des titres », sélectionner le titre à tester

• cliquer sur le contenu de la colonne « Accès » du titre choisi

• cliquer sur le lien « tester » dans la nouvelle page

• l'utilisateur est alors redirigé vers l'url d'accès indiquée dans la notice LOMFR avec un ticket valide en paramètre

(8)

2.5. Exemples de flux XML CAS

2.5.1. Authentification réussie En cas d’authentification réussie, le flux suivant est retourné.

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

<cas:authenticationSuccess>

<cas:user>Uam00010</cas:user><cas:rne>0131313Z</cas:rne><cas:siren>602060147</cas:siren>

<cas:profile>EDITEUR</cas:profile><cas:proxies>

<cas:proxy>https://www.correlyce.fr/correlyce/casProxy/receptor</cas:proxy>

</cas:proxies></cas:authenticationSuccess></cas:serviceResponse>

Le tag « cas:authenticationSuccess » indique que l'authentification est réussie.

(exemple tiré de Corrélyce. Pour une autre plate-forme, l’URL du serveur CAS sera différente)

2.5.2. Authentification échouée En cas d’échec d’authentification, le flux suivant est retourné

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

<cas:authenticationFailure code='INVALID_TICKET'>

le ticket 'ST-63-PJraQneKSfeXgrI4pvn20sXlFKQHcLWuMrU-20' est inconnu

</cas:authenticationFailure></cas:serviceResponse>

Le tag « cas:authenticationFailure » indique que l'authentification a échouée

3. EXEMPLES DE CODE UTILISABLES POUR LA REALISATION DE LA PAGE D’ACCES

Les codes qui suivent sont mis à disposition pour faciliter la connexion des ressources. Ils s’appuient sur le langage php, utilisé à titre d’exemple.

3.1. Principe fonctionnel

En mode standard d’accès à une ressource protégée en php, un module login.php est chargé d’établir la session.

Figure 6 - Accès protégé standard en php

Quand la ressource est connectée à Courdecol13, l’accès se fait via une page d’accès spécifiquement mise en place pour la connexion de la ressource à la plate-forme, qui met en œuvre le SSO de Courdecol13.

1. l'utilisateur accède à une ressource depuis Courdecol13 (ressource-test.php dans l’exemple suivant);

2. il est redirigé, après vérification, sur la page d'accès (ressource.php dans l’exemple suivant) avec un PT dans l'URL ;

3. la fonction secure() vérifie l'authentification sur le serveur CAS : - en cas d'échec, un formulaire d'authentification est présenté,

- en cas de succès la session PHP est complétée par les données issues du jeton CAS ;

Ressource-test.php Exemple d’application php en

accès protégé à rendre accessible via CORREE Login.php Logout.php Navgateur

client

(9)

Corédu et Coréprim sont des marques déposées par le CRDP de l’académie d’Aix-Marseille page 9 4. la ressource est affichée, on peut aussi faire une nouvelle redirection vers la ressource.

Figure 7 - L'accès est géré par la page d'accès ressource.php

3.2. Les exemples de code proposés ci-après A noter !

Le fonctionnement décrit nécessite que PHP soit installé sur votre serveur avec les modules openssl, domxml et la directive allow_url_fopen=On. Le module Curl est recommandé.

3.3. Licence.txt

Le fichier licence.txt est l’expression de la licence du code des fichiers fournis

//=====================================================================

//= licence

//=====================================================================

// Le programme dont le code suit a été créé à titre d'exemple par le

// Centre Régional de Documentation Pédagogique de l'académie d'Aix Marseille // à l'attention des éditeurs proposant des ressources pour les plateformes // de mise à disposition de ressources en ligne de type Corrélyce, projet // de la région Provence Alpe Côte d'Azur.

// Il est à adapter par l'éditeur et ne saurait être utilisé tel que.

//

// Auteur : CRDP Aix-Marseille - Alexandre Mathieu // Version : 2012_05_14

// Licence : Cecill V2 (http://www.cecill.info/licences.fr.html), compatible GNU GPL V3 // Selon les termes de ces licences, chacun est libre d'adapter

// et de diffuser ce programme sans demande préalable, // et sans garantie de de la part de l'Auteur.

//

Ressource-test.php Exemple d’application php en

accès protégé à rendre accessible via CORREE Login.php Logout.php

ressource.php CORREE

single_cas_secure.php

Corree.php lib.php

Navgateur client

Site éditeur

(10)

3.4. Ressource.php

Ressource.php est appelé « Page d’accès » dans les différentes documentations et constitue le point d’entrée de votre site pour une application externe. L’adresse complète de ce connecteur est celle qui est attendue pour renseigner le champ 4.3 (system/localisation) de la notice documentaire, ou la zone localisation du formulaire de validation de la ressource (selon la version utilisée).

Ressource.php représente la page d’accès que vous devez installer sur votre site pour en protéger les accès.

<?php

@session_start();

// contacte un seul serveur CAS par ex. correlyce OU courdecol13 require_once( 'single_cas_secure.php' );

// contacte plusieurs serveurs CAS par ex. correlyce ET courdecol13.

//require_once( 'multiple_cas_secure.php' );

// protection de la ressource

@secure();

?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<head>

<title>ressource protégée 1</title>

</head>

<body>

<h1>ressource 1</h1>

<p>bonjour <?php echo $_SESSION['userid'] ?> (<?php echo @$_SESSION['rne'] ?>)

<?php if (isset($_SESSION['corree'])) { ?>

depuis <?php echo $_SESSION['corree'] ?>

<?php } ?>

</p>

<a href="logout.php">se déconnecter</a>

</div>

</body>

</html>

(11)

Corédu et Coréprim sont des marques déposées par le CRDP de l’académie d’Aix-Marseille page 11 3.5. Single_cas_secure.php

Single_cas_secure.php est un module logiciel contenant la fonction secure(), appelée par ressource.php lorsque l’on connecte une ressource à une seule plate-forme Courdecol13. Ce code peut être recopié sur votre serveur et adapté en fonction des besoins.

Cet exemple est codé pour Corrélyce. Pour une autre plate-forme, les URL CAS doivent être modifiées en conséquence (URL du CAS de la plate-forme au lieu de http://cas.correlyce.fr/cas).

<?php

require_once('lib.php');

require_once('corree.php');

// L'URL du serveur CAS

define('CAS_BASE_URL', 'http://cas.correlyce.fr/cas');

// L'URL du service tel que déclaré dans la notice.

// ici on utilise l'URL courante, ce qui évite d'avoir à intervenir sur le code si la notice est modifiée...

define('SERVICE_URL', get_page_url());

$corree = new Corree(CAS_BASE_URL, SERVICE_URL);

/**

* Vérifie que l'accés à l'URL est bien authentifié.

* Si l'URL contient un jeton CAS (ticket) il est vérifié.

* Sinon affiche le formulaire d'authentification.

*/

function secure() { global $corree;

if (!isset($_SESSION['userid'])) { if (isset( $_GET['ticket'])) {

$token = $corree->authenticate($_GET['ticket']);

if ($token !== FALSE) {

$_SESSION['userid'] = $token['user'];

// il est aussi possible d'injecter les autres éléments de $token dans la session

$_SESSION['userrne'] = $token['rne'];

return TRUE;

} }

header('HTTP/1.1 401 Unauthorized');

require('login.php');

exit(0);

} }

?>

(12)

3.6. Multiple_cas_secure.php

Multiple_cas_secure.php est un module logiciel contenant la fonction secure() appelée par ressource.php lorsque l’on connecte une ressource à plusieurs plates-formes de type Corrélyce. Il permet de valider les accès via le serveur CAS de chacune des plates-formes dont les adresses sont enregistrées. Ce code peut être recopié sur votre serveur et adapté en fonction des besoins.

Cet exemple est codé pour Corrélyce, Courdecol13 et Coréprim. Pour ajouter une autre plate-forme, il est nécessaire d’ajouter l’URL du CAS dans le « array » $cas.

<?php

require_once('corree.php');

// tableau contenant les connecteurs vers les serveurs CAS autorisés à authentifier des ressources.

$cas = array(

'correlyce' => new Corree('https://cas.correlyce.fr/cas', get_page_url()), 'courdecol13' => new Corree('https://www.courdecol13.org/cas', get_page_url()), 'coreprim' => new Corree('https://cas.coreprim.fr/', get_page_url())

);

/**

* Vérifie que l'accès à l'URL est bien authentifié.

* Si l'URL contient un jeton CAS (ticket) il est vérifié sur les serveurs CAS déclarés dans

$cas.

* UN SEUL des ces serveur peut valider le jeton.

* Sinon affiche le formulaire d'authentification.

*/

function secure() { global $cas;

if (!isset($_SESSION['userid'])) { if (isset( $_GET['ticket'])) {

foreach($cas as $label => $corree) {

$token = $corree->authenticate($_GET['ticket']);

if ($token !== FALSE) {

$_SESSION['userid'] = $token['user'];

$_SESSION['corree'] = $label; // permet d'identifier par la suite le serveur CAS qui a authentifié le jeton.

// il est aussi possible d'injecter les autres éléments de $token dans la session

$_SESSION['userrne'] = $token['rne'];

return TRUE;

} } }

header('HTTP/1.1 401 Unauthorized');

require('login.php');

exit(0);

} }

?>

(13)

Corédu et Coréprim sont des marques déposées par le CRDP de l’académie d’Aix-Marseille page 13 3.7. Lib.php

Lib.php est un module qui propose une fonction qui retourne l’URL courante sous forme de chaîne. Cette URL peut être différente de celle déduite du script PHP, par exemple en cas de réécriture (utilisation de mod_rewrite). Attention, cela ne fonctionne qu’avec Apache.

<?php /**

* @return string L'URL courante

* qui peut être différente de celle déduite à partir du nom du script PHP

* par exemple en cas de réécriture (ie. utilisation de mod_rewrite).

* Attention : cela ne fonctionne qu'avec Apache...

*/

function get_page_url() {

$page_url = (@$_SERVER['HTTPS'] == 'on') ? 'https://' : 'http://';

$page_url .= $_SERVER['SERVER_NAME'];

if ((@$_SERVER['HTTPS'] !== 'on' && $_SERVER['SERVER_PORT'] !== '80')

|| (@$_SERVER['HTTPS'] === 'on' && $_SERVER['SERVER_PORT'] !== '443')) {

$page_url .= ':'.$_SERVER["SERVER_PORT"];

}

$page_url .= reset(explode("?", $_SERVER['REQUEST_URI']));

return $page_url;

}

?>

(14)

3.8. Corree.php

Corree.php est un module logiciel maintenu par le CRDP et régulièrement actualisé en fonction des évolutions techniques. Il est requis par single_cas_secure.php ou multiple_cas_secure.php (instruction

« require_once(‘corree.php’) » en début de code) qui formate les appels CAS et interprète les retours.

Il doit être recopié sur votre serveur pour être utilisé par la page d’accès.

<?php /**

* @copyright CRDP de l'académie d'Aix-Marseille

* @author Alexandre Mathieu

* @version 0.12

*/

define('CAS_NS', 'http://www.yale.edu/tp/cas');

class Corree {

private $cas_url;

private $service_url;

/**

* Type d'erreur utilisé lors d'un échec d'authentification.

* @var int E_USER_NOTICE, E_USER_WARNING, E_USER_ERROR

* ou FALSE pour ne pas générer d'erreur.

*/

public $error_type = E_USER_WARNING;

/**

* Type d'erreur utilisé lors d'une authentification réussie.

* @var int E_USER_NOTICE, E_USER_WARNING, E_USER_ERROR

* ou FALSE pour ne pas générer d'erreur.

*/

public $success_type = E_USER_NOTICE;

/**

* Délai d'attente pour la réponse du serveur CAS.

* @var int Durée en secondes.

*/

public $timeout = 5;

/**

* Vérification du certificat SSL du serveur CAS.

* @var boolean

*/

public $verify_peer = TRUE;

/**

* @param string $cas_url URL de serveur CAS.

* @param string $service_url URL du service tel que renseigné dans la notice.

*/

function __construct($cas_url, $service_url) {

$this->cas_url = $cas_url;

$this->service_url = $service_url;

}

/**

* Valide le 'proxy ticket' auprès du serveur CAS.

*

* @param string $ticket Le 'proxy ticket' passé en paramètre dans la requête.

*

* @return string[] Renvoi un tableau contenant les détails du jeton CAS reçu

* en cas d'authentification réussie, FALSE sinon (échec ou erreur...)

* @example pour un jeton CAS :

(15)

Corédu et Coréprim sont des marques déposées par le CRDP de l’académie d’Aix-Marseille page 15

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

* <cas:authenticationSuccess>

* <cas:user>endjs</cas:user>

* <cas:profile>eleve</cas:profile>

* <cas:rne>0123467X</cas:rne>

* <cas:proxies>

* <cas:proxy>https://foo.bar.com/pgtCallback</cas:proxy>

* </cas:proxies>

* </cas:authenticationSuccess>

* </cas:serviceResponse>

* le tableau renvoyé sera :

* Array( 'user' => 'endjs', 'profile' => 'eleve', 'rne' => '0123467X' )

*/

public function authenticate($ticket) {

$xmlcontent = $this->get_token($ticket);

if ($xmlcontent === FALSE) { return FALSE;

}

$dom = new DomDocument();

if (!($dom->loadXML($xmlcontent))) {

if ($this->error_type) { trigger_error('invalid response.', $this->error_type); } return FALSE;

}

$rootElt = $dom->documentElement;

if ($rootElt->localName != 'serviceResponse' || $rootElt->namespaceURI != CAS_NS) { if ($this->error_type) {

trigger_error('invalid response', $this->error_type);

}

return FALSE;

}

$successElts = $rootElt->getElementsByTagnameNS(CAS_NS, 'authenticationSuccess');

if ($successElts->length == 0) {

$errorElts = $rootElt->getElementsByTagnameNS(CAS_NS, 'authenticationFailure');

if ($this->error_type) {

trigger_error('authentication failed, ' . $errorElts->item(0)->nodeValue, $this-

>error_type);

}

return FALSE;

}

$success = $successElts->item(0);

$retval = array();

$is_proxy = FALSE;

foreach( $success->childNodes as $node ) {

if ($node->nodeType === XML_ELEMENT_NODE && $node->namespaceURI === CAS_NS) {

if ($node->localName === 'proxies') {

$is_proxy = TRUE;

} else {

$retval[$node->localName] = $node->nodeValue;

} }

(16)

}

if (!$is_proxy) {

trigger_error('not a proxy ticket', $this->error_type);

}

return FALSE;

}

if ($this->success_type) {

trigger_error( 'successful authentication', $this->success_type );

}

return $retval;

}

private function get_token($ticket) {

global $is_curl_installed;

$url = $this->cas_url . '/proxyValidate' . '?'

. http_build_query(array('ticket' => $ticket, 'service' => $this->service_url));

if ($is_curl_installed) {

$ch = curl_init($url);

curl_setopt($ch, CURLOPT_RETURNTRANSFER, TRUE);

curl_setopt($ch, CURLOPT_CONNECTTIMEOUT, $this->timeout);

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, $this->verify_peer);

$data = curl_exec($ch);

if ($data === FALSE) {

if ($this->error_type) { trigger_error(curl_error($ch), $this->error_type); } }

curl_close($ch);

return $data;

} else {

file_get_contents($url);

} } }

function _check_curl_installed() { global $is_curl_installed;

if (isset($is_curl_installed)) return;

if (in_array('curl', get_loaded_extensions())) {

$is_curl_installed = TRUE;

} else {

trigger_error( "l'extension cURL n'est pas installée, le certificat SSL du serveur CAS ne sera donc pas vérifié"

, $this->error_type);

}

$is_curl_installed = FALSE;

(17)

Corédu et Coréprim sont des marques déposées par le CRDP de l’académie d’Aix-Marseille page 17 }

}

/**

* vérifie la présence de l'extension cURL.

*/

_check_curl_installed();

?>

3.9. Login.php

Login.php est un module logiciel standard qui gère les sessions de ressource-test.php en l’absence de cassification.

<?php /**

* Formulaire d'authentification

* en cas de succès redirige l'utilisateur vers la ressource

* après assignation de la variable de session 'userid'.

*

* @copyright CRDP de l'académie d'Aix-Marseille

* @author Alexandre Mathieu

*

*/

/**

* vérifie les données d'authentification fournies par le formulaire.

* @return TRUE en cas d'authentification réussie, FALSE sinon (échec ou erreur...)

*/

function authenticate( $login, $password ) { // ici on se contente d'une simple comparaison.

// habituellement on interroge une base de donnée, un annuaire...

return $login === 'corree' && $password === 'corree';

}

@session_start();

if ($_SERVER['REQUEST_METHOD'] === 'POST') {

$userid = $_POST['userid'];

$password = $_POST['password'];

$ressource = $_POST['ressource'];

if (authenticate($userid, $password)) {

$_SESSION['userid'] = $userid;

header('Location: ' . $ressource);

exit(0);

} else {

unset($_SESSION['userid']);

} } else {

$ressource = get_page_url();

}

?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"

"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<head>

(18)

<title>Formulaire d'authentification</title>

</head>

<body>

<h2>Entrez votre identifiant et votre mot de passe.</h2>

<?php if ($_SERVER['REQUEST_METHOD'] === 'POST') { ?>

Les informations transmises n'ont pas permis de vous authentifier.

</div>

<?php } ?>

<label>identifiant :

<input type="text" name='userid' accesskey="i"

value="<?php if (isset($userid)) echo $userid; ?>" />

</label>

<label>mot de passe :

</label>

</form>

</body>

</html>

3.10. Logout.php

Logout.php est un module logiciel standard qui gère les sessions de ressource-test.php en l’absence de cassification.

<?php

@session_start();

echo $_SESSION['userid'];

if (isset($_SESSION['userid'])) { unset($_SESSION['userid']);

}

header('Location: http://www.google.fr');

?>