DOCUMENTATION CAS A DESTINATION DES …stephane.boireau.free.fr/.../REFO-DT-ENTV2-ServeurCAS-v1.2.pdf · proposée par JASIG, créateur du Protocole CAS : 4 Application CAS : Application

Tout droit réservé ITOP Education ©

DOCUMENTATION CAS A DESTINATION DES SERVICES TIERS

Titre descriptif du document

Référence du document REFO-DT-ENTV2-ServeurCAS-v1.2.docx

Nom du fichier REFO-DT-ENTV2-ServeurCAS-v1.2.docx

Version du document v1.2

Date de dernière mise à jour 21/03/12 Nb pages : 20

Solution(s) cible(s) principale(s) NetMaternelle, NetEcole, NetCollège, NetLycée

Solution(s) cible(s) secondaire(s)

Rédacteur(s) ITOP EDUCATION

Valideur(s)

Destinataires Editeurs d’applications et ressources pédagogiques connectées à l’ENT

Dernières modifications Ajout des références vers le SDET et l’annexe AAS

REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 2 / 20


HISTORIQUE DES VERSIONS

Version Date Changement par rapport à la version

précédente Rédact. par Vérif. par

1.0 28/02/2012 Création du document GJ 1.1 02/03/2012 Ajout des annexes GJ 1.2 21/03/2012 Ajout des références au SDET et à l’annexe

AAS. GJ



SOMMAIRE

1. Préambule _____________________________________________________________ 4

2. Présentation du protocole CAS (Central Authentication Service) __________________ 5

3. Fonctionnement du serveur _______________________________________________ 5

3.1. Fonctionnement sans proxy – 1ére connexion _____________________________________ 6

3.2. Fonctionnement sans proxy – 2ème connexion ____________________________________ 7

3.3. Fonctionnement sans proxy – Définitions ________________________________________ 8 TGC - Ticket Granting Cookie _______________________________________________________ 8 ST – Service Ticket ________________________________________________________________ 8

4. Fonctionnement Client CAS ________________________________________________ 9

4.1. Définition __________________________________________________________________ 9

4.2. Mise en place d’une authentification CAS ________________________________________ 9 4.2.1. Prérequis _________________________________________________________________________ 9 4.2.2. Installation d’un client CAS __________________________________________________________ 9

5. Respect du SDET – Annexe AAS : __________________________________________ 10

6. Annexes ______________________________________________________________ 14 Réponses du serveur CAS _________________________________________________________ 14 Authentification réussie ________________________________________________________ 14 Authentification échouée _______________________________________________________ 14

Client CAS _____________________________________________________________________ 15 ASP.Net _____________________________________________________________________ 15 PHP ________________________________________________________________________ 17 JAVA ________________________________________________________________________ 18



1. PREAMBULE Dans ce document, les éditeurs de service tiers peuvent trouver la description du système d’authentification unique SSO1 utilisé dans l’ENT :

- Description du protocole CAS - Explication de son utilisation pour la connexion aux diverses applications tierces - Scénarios de test

Un SSO est un système qui permet de centraliser l'authentification au sein d'applications connexes. Voici les différents avantages :

- La gestion des informations de connexion est simplifiée étant donné que l’utilisateur n’a pas à prendre connaissance de ces dernières (sauf pour certain connecteur2)

- Gain de temps : Les personnes utilisant plusieurs applications tierces connectées dans l’ENT ne devront pas se ré authentifier.

- Simplifier la conception des applications en déportant la gestion de l'authentification vers un entrepôt central (utilisant un annuaire LDAP ou une base de données par exemple).

1 SSO : Single Sign On – authentification unique

2 Connecteur : Liaison entre l’ENT et une application tierce permettant l’authentification d’un utilisateur



2. PRESENTATION DU PROTOCOLE CAS3 (CENTRAL AUTHENTICATION

SERVICE) CAS est un système d’authentification unique respectant un protocole développé par l’Université de Yale. C'est un mécanisme très solide, qui est implanté dans plusieurs universités et organismes dans le monde. Ce mécanisme est très utilisé dans les différentes applications utilisées dans le domaine de l’éducation.

3. FONCTIONNEMENT DU SERVEUR A l’aide de nombreux schémas, nous allons expliquer le fonctionnement du Serveur CAS. Le protocole CAS connait deux types de fonctionnement :

- Fonctionnement avec proxy - Fonctionnement sans proxy

A ce jour, nous n’utilisons que le fonctionnement sans proxy. Le fonctionnement en mode simple, sans proxy, permet à une application CAS 4de donner accès à d'autres applications clientes sous condition. Ces applications clientes valideront le ticket transmis par l'application Web auprès du serveur CAS.

3 Pour la présentation du serveur CAS et pour un maximum de clarté nous nous inspirons de la documentation

proposée par JASIG, créateur du Protocole CAS : http://www.jasig.org/cas 4 Application CAS : Application possédant un client CAS

http://www.jasig.org/cas



3.1. Fonctionnement sans proxy – 1ére connexion Nous allons décrire la connexion étape par étape en s’appuyant sur le schéma suivant :

1. Un utilisateur se connecte à une application Web CAS. 2. Il est redirigé vers le formulaire de login du serveur CAS.

o Url : http://www.cas.serveur.fr/cas/login 3. Si aucune session d’authentification n’est connue, l’utilisateur doit s’authentifier et valider

son identité auprès de l’Active Directory. a. Si l’authentification échoue, une erreur est envoyée sur le formulaire

d’authentification. b. Si l’authentification réussie, le serveur CAS renvoie un TGC (Ticket Granting Cookie) à

l’utilisateur. o Url : http://appliweb.fr?ticket=ST-1-32154et15

4. L’utilisateur est alors redirigé vers l’application Web avec un ST (Service Ticket). 5. L’application demande la validation du ST auprès du serveur CAS pour vérifier :

o que le ticket existe o que le ticket soit valide o que le couple service/ticket correspond o Url CAS 1.0 et CAS 2.0:

http://www.cas.serveur.fr/cas/validate?service=http://appliweb.fr&ticket=ST-1-32154et157

http://www.cas.serveur.fr/cas/servicevalidate?service=http://appliweb.fr&ticket=ST-1-32154et157

6. Le serveur CAS renverra un ticket CAS pour authentifier l’utilisateur au sein de l’application ou bien l’avertir d’un problème de connexion CAS.

Application tierce Client / Navigateur

Serveur CAS

Active Directory

Connecteur

/cas/servicevalidate ou /cas/validate

/cas/login

Service d’authentification

1

6

4

5

3b

2

3

3a

3a

Service de validation



3.2. Fonctionnement sans proxy – 2ème connexion Ainsi connecté au serveur CAS, l’utilisateur suivra alors le protocole de connexion suivant. Nous allons décrire la connexion étape par étape en s’appuyant sur le schéma suivant :

1. Un utilisateur accède à une application Web CAS. 2. Il est redirigé vers le serveur CAS.

o Url : http://www.cas.serveur.fr/cas/login?service=http://appliweb.fr 3. L’utilisateur est alors redirigé vers l’application Web avec un ST (Service Ticket).

o Pour cela, le serveur CAS lira le TGC transmit lors de l’étape 2 pour envoyer à l’application un nouveau ST en paramètre URL

o Url : http://appliweb.fr?ticket=ST-1-32154et157 4. L’application demande la validation du ST auprès du serveur CAS pour vérifier :

o que le ticket existe o que le ticket soit valide o que le couple service/ticket correspond o Url CAS 1.0 et CAS 2.0:

http://www.cas.serveur.fr/cas/validate?service=http://appliweb.fr&ticket=ST-1-32154et157

http://www.cas.serveur.fr/cas/servicevalidate?service=http://appliweb.fr&ticket=ST-1-32154et157

5. Le serveur CAS renverra un ticket CAS pour authentifier l’utilisateur au sein de l’application

ou bien l’avertir d’un problème de connexion CAS. On peut noter que pour cette deuxième connexion, l’utilisateur n’a pas à ressaisir ses identifiants. Les authentifications sont automatiques et transparentes pour l’utilisateur.

Serveur CAS

Client / Navigateur Application tierce

Connecteur

/cas/servicevalidate ou /cas/validate

/cas/login

Service d’authentification

1

5

3

2

Service de validation

2

3

4



3.3. Fonctionnement sans proxy – Définitions Voici les abréviations utilisées dans les parties 3.1 et 3.2 :

TGC - Ticket Granting Cookie

Ce ticket est un cookie de session transmit par le serveur CAS au navigateur du client lors de la phase de login. Utilisant un canal sécurisé (https), seul le serveur CAS pourra lire et écrire sur le TGC. Ce cookie est valide durant la session de l’utilisateur et permet d’obtenir un ST (Service Ticket) auprès du Serveur CAS.

Le TGC permet d’identifier l’utilisateur sur le serveur CAS.

ST – Service Ticket

Ce ticket va servir à authentifier une personne pour une application donnée5. Il est envoyé par le serveur CAS après validation d’authentification (3.1 étape 3b et 3.2 étape 3). Ce ticket est transmis par paramètre url sous la forme :

o http://appliweb.fr?ticket=ST-1-32154et157 Ce ticket ne peut être utilisé qu’une fois. De plus, des règles de temps peuvent s’appliquer sur un ticket. L’authentification ne se fera qu’après la validation du ST par le serveur CAS. Ces échanges se font directement entre l’application Web et le serveur CAS. Une fois la demande de validation effectuée, une réponse est envoyée à l’application et le ST est invalidé.

Le ST permet d’authentifier un utilisateur sur un service, et pour une seule connexion.

5 Application donnée : cette application est identifié sous le nom de « service » pour le serveur CAS



4. FONCTIONNEMENT CLIENT CAS

4.1. Définition Un client CAS est un module6 permettant de faire interagir l’application avec le serveur CAS.

Sur le site de JASIG (http://www.jasig.org/cas/client-integration) de nombreux client CAS sont proposés (seul les langages de programmation sont différents). La diversité de ces client CAS ainsi que la standardisation des échanges (HTTPS et XML) Client / Serveur facilitent l’intégration de la technologie CAS au sein d’une application.

4.2. Mise en place d’une authentification CAS

4.2.1. Prérequis Pour qu’une authentification CAS soit prévue, il faut prévoir comme travaux :

- Page d’accès à l’application - Vérifier l’existence d’une connexion sur toutes les pages sensibles d’une application

o Si une page (formulaire) doit être protégée par une authentification il faut qu’à la création de la page, que l’éditeur vérifie l’existence de la session de l’utilisateur. Si cette session n’existe pas, il faut alors rediriger automatiquement la personne vers la page d’accès (Client CAS).

4.2.2. Installation d’un client CAS Il faut avant tout configurer le serveur CAS pour paramétrer le service souhaité. De plus, le retour XML de la réponse CAS doit posséder l’attribut « user ». Une fois ce paramétrage effectué, il faut adapter l’authentification de votre application web afin de supporter l’authentification via un serveur CAS (cf. annexe « Client CAS »).

6 Module : partie d’un développement informatique ayant une fonctionnalité particulière.

http://www.jasig.org/cas/client-integration



5. RESPECT DU SDET – ANNEXE AAS : Le Ministère de l’Education Nationale a publié un schéma directeur des espaces numériques de travail (SDET) afin d’encadrer et de formaliser les préconisations organisationnelles, fonctionnelles et techniques d’un espace numérique de travail (ENT). Vous trouverez la publication de la dernière version du SDET sur le site du Ministère de l’Education Nationale7. Afin d’encadrer l’interconnexion entre les ENT et les applications distantes ou services tiers, une annexe a été rédigé spécifiquement dans le SDET. C’est l’annexe AAS :

- Recommandations pour l’Authentification-Autorisation-SSO : AAS8 - « l'identification, l'authentification, la gestion des autorisations et du Single Sign-On

(AAS) » Il est important de souligner que l’annexe AAS décrit le contexte de diffusion des informations pour les authentifications SSO. En effet, l’AAS présente une liste de cinq catégories d’autorisation de diffusion. Pour chaque service, la réponse CAS devra être personnalisée en fonction de la catégorie déterminée par les deux éditeurs (Editeur d’application et ENT) :

- Catégorie 1 : o L’accès au service ne nécessite ni authentification ni contrôle d’accès (accès

libre). Aucune information d’identité sur l’utilisateur ne doit être transmise pour l’accès à un service tiers appartenant à cette catégorie.

o Dans ce cas, il n’y a pas de liaison avec le serveur CAS, l’accès au service tiers se faisant directement sans besoin d’authentification.

- Catégorie 2 : o L’accès au service nécessite une authentification et un contrôle d’accès basés

uniquement sur l’appartenance de l’utilisateur à l’ENT et/ou à un établissement scolaire défini.

o Les données qui PEUVENT être échangées afin d’assurer l’authentification et le contrôle d’accès sont :

L’identifiant de l’ENT de l’utilisateur L’identifiant de l’établissement de l’accédant (UAI / ex-RNE). Le profil de l’accédant (catégorie de personnes), non associé à une

identité. o D’autres attributs non associés à une identité PEUVENT être échangés (ces

attributs sont donnés dans le tableau du paragraphe 9.2.2, cf. annexe AAS). o Dans ce cas, nous envoyons par la réponse CAS personnalisée pour le service :

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

<cas:authenticationSuccess>

<cas:user>37DB5E37-0345-46D5-A0F5-4394B26E9FEA</cas:user>

<cas:Profil>National_3</cas:Profil>

<cas:UAI>0310000Z</cas:UAI>

</cas:authenticationSuccess>

</cas:serviceResponse>

7 SDET : http://eduscol.education.fr/cid56994/preconisations-techniques.html 8 AAS : http://media.eduscol.education.fr/file/services/44/4/SDET-AAS-v3.0_192444.pdf

http://eduscol.education.fr/cid56994/preconisations-techniques.html

http://media.eduscol.education.fr/file/services/44/4/SDET-AAS-v3.0_192444.pdf



- Catégorie 3 : o L’accès au service nécessite une authentification et un contrôle d’accès de

l’accédant avec transmission de données non nominatives mais uniques par utilisateur (identifiant utilisateur non significatif).

o Les données qui PEUVENT être échangées afin d’assurer l’authentification et le contrôle d’accès sont :

Un identifiant unique par utilisateur mais qui ne permette pas d’être associé à l’identité de l’accédant (identifiant interne à l’ENT – uid)

Le profil de l’accédant non associé à une identité L’identifiant de l’établissement à partir duquel le service tiers est appelé

(UAI / ex RNE) o Remarque : toute autre donnée NE DOIT PAS être transmise. o Dans ce cas, nous envoyons par la réponse CAS personnalisée pour le service :








- Catégorie 4 : o L’accès au service s’effectue sur la base d’informations nominatives sur

l’accédant, dont dispose au préalable le service tiers, et d’informations non nominatives transmises par l’ENT lors de la connexion (mapping d’identités réalisé par le service tiers).

o Le processus d’inscription au service applicatif s’effectue « hors ENT ». o Lors de l’inscription préalable, le service tiers PEUT demander à l’utilisateur des

attributs afin de réaliser, par la suite, l’authentification, le contrôle d’accès ou la personnalisation.

o Par ailleurs, à cette occasion, le service tiers DOIT faire mention des conditions générales d’accès au service en cohérence avec les recommandations CNIL relatives au traitement de données à caractère personnel.

o De plus, les données qui PEUVENT être échangées de l’ENT vers le service tiers sont :

L’identifiant de l’ENT de l’utilisateur. Ou bien un identifiant unique par utilisateur mais qui ne permette pas

d’être associé à l’identité de l’accédant. o Remarque : toute autre donnée NE DOIT PAS être transmise. o Dans ce cas, nous envoyons par la réponse CAS personnalisée pour le service :








- Catégorie 5 : o L’accès au service s’effectue sur la base d’informations fournies par l’utilisateur

lors de la première connexion au service tiers via l’ENT (formulaire en ligne…). o Lors des connexions suivantes, l’accédant sera reconnu par le service tiers sur la

base d’informations utilisateur transmises par l’ENT (fonctionnement identique à la catégorie 4 : mapping d’identités).

o Les informations d’identité qui PEUVENT être demandées à l’utilisateur lors de la 1ère connexion DOIVENT être déclarées préalablement dans la convention de service. Ces données POURRONT couvrir l’ensemble des attributs relatifs aux utilisateurs décrits à l’annexe 2 du « Cahier des charges de l’annuaire ENT ».

o Les informations d’identité DOIVENT être demandées au détail et dans la limite du nécessaire par rapport à la finalité du service tiers (authentification, contrôle d’accès, personnalisation, suivi de l’utilisateur).

o Remarque : toutes les informations échangées lors de cette première connexion sont fournies sur la base du volontariat de l’accédant. A cette occasion, les conditions générales d’accès au service devront y être explicitement précisées.

o Les caractéristiques sont identiques à la catégorie 4, à la seule différence et qu’à la première connexion, le service ne demandera pas le couple d’identifiants de connexion, mais proposera de remplir un formulaire avec différentes informations qu’il stockera dans ses bases.

o Dans ce cas, nous envoyons par la réponse CAS personnalisée pour le service :






<cas:Classes>

<cas:Classe>601</cas:Classe>

<cas:Classe>503</cas:Classe>

</cas:Classes>

<cas:Groupes>

<cas:Groupe>Groupe1</cas:Groupe>

<cas:Groupe>Groupe2</cas:Groupe>

</cas:Groupes>



L’AAS autorise toute transmission d’information tant que celles-ci ne sont pas des informations d’authentifications et nominatives.



Voici une liste non exhaustive d’attributs pouvant être transmis : - Elèves

o Code du niveau de formation o Filière o Niveau de formation du diplôme o Code du niveau de formation o Spécialité o Enseignements o Classe o Groupes

- Enseignants

o Disciplines et catégorie de discipline de poste associée o Matières enseignées o Classes affectées o Groupes affectés

- ENTAuxNonEnsServAc / ENTAuxNonEnsCollLoc / ENTAuxNonEnsEtab

o Service de la personne



6. ANNEXES

Réponses du serveur CAS

Authentification réussie






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

Authentification échouée


<cas:authenticationFailure code="INVALID_TICKET">

Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized

</cas:authenticationFailure>


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



Client CAS

ASP.Net

Classe d’authentification CAS using System;

using System.IO;

using System.Linq;

using System.Net;

using System.Web;

using System.Xml;

public partial class clientAuthentificat : System.Web.UI.Page

{

protected void Page_Load(object sender, EventArgs e)

{

try

{

const string CASHOST = "http://cas.serveurcas.fr/cas/";

string service = HttpUtility.UrlEncode(Request.Url.AbsoluteUri);

// Récupération du ticket dans l'URL

string tkt = Request.QueryString["ticket"];

// S'il n'existe pas de ticket, alors on redirige vers /login du serveur CAS

if (tkt == null || tkt.Length == 0)

{

string redir = CASHOST + "login?" + "service=" + service;

Response.Redirect(redir, false);

return;

}

string validateurl = CASHOST + "serviceValidate?" + "service="

+ service.Replace(HttpUtility.UrlEncode("&ticket=" + tkt), "") + "&ticket=" + tkt;

StreamReader Reader = new StreamReader(new WebClient().OpenRead(validateurl));

string resp = Reader.ReadToEnd();

NameTable nt = new NameTable();

XmlNamespaceManager nsmgr = new XmlNamespaceManager(nt);

XmlParserContext context = new XmlParserContext(null, nsmgr, null, XmlSpace.None);

XmlTextReader reader = new XmlTextReader(resp, XmlNodeType.Element, context);

string netid = null;

bool CASError = true;

while (reader.Read())

{

if (reader.IsStartElement())

{

string tag = reader.LocalName;

if (tag.Contains("authenticationFailure"))

{

CASError = true;

}

if (tag.Contains("authenticationSuccess"))

{

CASError = false;

}

if (!CASError)

{

if (tag.Contains("user"))

{

netid = reader.ReadString();

}

}

}

}

if (CASError)

{

Response.Write("L'authentification CAS n'a pas pu fonctionner.") ;

}

else

{

if (netid == null)

{

Response.Write("Validation échoué, utilisateur non trouvé !");

}

else

{

Response.Write("idUser = " + netid), false);

}

}

} catch (Exception ex)

{

Response.Write("Impossible d'utiliser la connexion CAS pour le moment.");

}

}

}



Page ASPX <h2>

Test du client CAS ASP.NET

</h2>

<p>

Etat de la connexion :

<asp:label runat="server" id="Lbl_Etat" />

<br />

Utilisateur :

<asp:label runat="server" id="Lbl_User" />

</p>

<p>

Erreurs :

<asp:label runat="server" id="Lbl_Erreur" />

</p>

Ce code source n’est qu’un exemple, sur « JASIG » de nombreux client CAS ASP.NET sont disponibles. https://wiki.jasig.org/display/CASC/.Net+Cas+Client

https://wiki.jasig.org/display/CASC/.Net+Cas+Client

https://wiki.jasig.org/display/CASC/.Net+Cas+Client



PHP

Structure de l’application Web Pour tester un client CAS en PHP, vous pouvez utiliser le client PHP CAS suivant : phpCAS : https://wiki.jasig.org/display/CASC/phpCAS Il est nécessaire de télécharger la version adaptée à votre version de PHP. https://wiki.jasig.org/display/CASC/phpCAS+installation+guide Vous trouverez des exemples d’utilisation sur la page suivante : https://wiki.jasig.org/display/CASC/phpCAS+examples Exemple d’utilisation du client phpCAS dans une application web : <?php

// Chargement du fichier config.php

require_once './config.php';

// Chargement de la librairie CAS

require_once $phpcas_path . '/CAS.php';

// Permet de log la connexion dans le répertoire approprié

phpCAS::setDebug();

// Créer / instancie lobjet CAS qui va permettre d’interagir avec le serveur CAS

phpCAS::client(CAS_VERSION_2_0, $cas_host, $cas_port, $cas_context);

// La validation du serveur CAS est crucial pour la sécurité protocole CAS !

phpCAS::setNoCasServerValidation();

// Authentification CAS

phpCAS::forceAuthentication();

// L’utilisateur veut se déconnecter

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

phpCAS::logout();

}

?>

<html>

<head>

<title>phpCAS Client basic</title>

</head>

<body>

<h1>Authentification reussie!</h1>

<p>

Le login utilisateur est <b><?php echo phpCAS::getUser(); ?></b>.

</p>

<p>

Version de phpCAS <b><?php echo phpCAS::getVersion(); ?></b>.

</p>

<p>

<a href="?logout=">Deconnexion</a>

</p>

</body>

</html>

Contenu du fichier config.php <?php

$phpcas_path = './CAS';

// Hostname complet du serveur CAS

$cas_host = 'cas.enteduc.fr';

$cas_context = '/cas';

// Port du serveur CAS. Par d馡ut le port pour https est 443

$cas_port = 443;

header('Content-Type: text/html; charset=utf-8');

?>

https://wiki.jasig.org/display/CASC/phpCAS

https://wiki.jasig.org/display/CASC/phpCAS+installation+guide

https://wiki.jasig.org/display/CASC/phpCAS+examples



JAVA

Prérequis Il est obligatoire de référencé dans le package :

- import edu.yale.its.tp.cas.client.ServiceTicketValidator;

Sans cette classe, les échanges entre client et serveur CAS ne pourra pas s’effectué.

Classe d’authentification CAS package com.xxx.util;

import java.sql.Connection;

import javax.servlet.RequestDispatcher;

import javax.servlet.http.HttpServletRequest;

import javax.servlet.http.HttpServletResponse;

import javax.servlet.http.HttpSession;

import javax.sql.DataSource;

import org.apache.commons.lang.StringEscapeUtils;

import org.apache.commons.lang.StringUtils;

import edu.yale.its.tp.cas.client.ServiceTicketValidator;

public class AuthentificationManagerCASInterne extends AuthentificationManager {

public boolean authentifie(HttpServletRequest request, HttpServletResponse response) throws Exception

{

return this.verifieSession(request, response);

}

public boolean verifieSession(HttpServletRequest request, HttpServletResponse response)

{

// Valeur renvoyée

boolean retour = false;

try {

HttpSession session = request.getSession();

session.setAttribute("authentificationInterne", Boolean.FALSE);

session.setAttribute("casInterne", Boolean.TRUE);

// Datasource récupérée de la session

String datasource = (String) session.getAttribute("datasource");

// On récupère l'utilisateur en session

String utilisateur = session.getAttribute("utilisateur");

if (datasource == null)

{

// On s'appuie alors sur le contexte tomcat

String contexte = ((HttpServletRequest) request).getContextPath();

if (contexte.startsWith("/")) {

contexte = contexte.substring(1).toLowerCase();

}

datasource = contexte;

session.setAttribute("datasource", datasource);

}

if (utilisateur == null || request.getParameter("ticket") != null)

{

session.removeAttribute("ticketDemande");

// On retrouve l'URL de la requête

String urlMonService = request.getRequestURL().toString();

if (urlMonService.startsWith("http://www"))

{

urlMonService = "https" + urlMonService.substring(4,

urlMonService.length());

}

else if (urlMonService.startsWith("www"))

{

urlMonService = "https://" + urlMonService;

}

String serveurCASURL = urlMonService.substring(0, urlMonService.indexOf("servlet"));

serveurCASURL += "cas";

String os = System.getProperty("os.name").toLowerCase();

if (os.indexOf("win") >= 0) {

String finURLMonService =

urlMonService.substring(urlMonService.indexOf("servlet"));

urlMonService = response.encodeURL(serveurCASURL + "/toto");

// Le filtre doit rajouter le RNE normalement

urlMonService = urlMonService.substring(0, urlMonService.indexOf("cas"));

urlMonService = urlMonService + finURLMonService;

}

DataSource ds = null;



if (datasource != null) {

ds = (DataSource) this.ctx_.lookup("java:comp/env/jdbc/" + datasource);

}

// On regarde si on est en callback ou pas

String callback = (String) session.getAttribute("callback");

if (callback != null) {

String ticket = request.getParameter("ticket");

String CASValidate = serveurCASURL + "/serviceValidate" ;

ServiceTicketValidator st = new ServiceTicketValidator();

// Si il n’y a pas de ticket, on recherche l'utilisateur dans la session

if (ticket == null)

{

utilisateur = session.getAttribute("utilisateur");

}

else

{

// Cas de la plateforme Windows

if (urlMonService.toLowerCase().indexOf("enteduc") > 0 ||

urlMonService.toLowerCase().indexOf(".itop.local") > 0)

{

CASValidate = "http://localhost/" + datasource +

"/cas/serviceValidate" ;

urlMonService = StringUtils.replace(urlMonService,

"http://", "https://");

urlMonService = StringUtils.replace(urlMonService,

":443", "");

}

st.setCasValidateUrl(CASValidate);

st.setServiceTicket(ticket);

st.setService(urlMonService);

st.validate();

if (!st.isAuthenticationSuccesful())

{

utilisateur = session.getAttribute("utilisateur");

}

else

{

System.out.println(">> authentification CAS KO");

}

}

if (utilisateur != null)

{

session.removeAttribute("callback");

retour = true;

}

else

{

if (ticket != null )

{

System.out.println(">> Ticket : " + ticket);

session.removeAttribute("callback");

if (st.isAuthenticationSuccesful()) {

// Authentification OK dans le CAS : on

retrouve le login

String login = st.getUser();

if (login != null && login != "")

{

session.setAttribute("utilisateur",

utilisateur);

System.out.println("L'utilisateur " +

login + " a pas été

retrouvé !");

retour = true;

}

else

{

System.out.println("L'utilisateur n’a

pas été retrouvé !");

}

}

else

{

System.out.println(">> Erreur CAS : " +

st.getErrorCode() + " - " +

st.getErrorMessage());

}

}

else

{

// Le ticket est null : on le demande

session.setAttribute("ticketdemande", Boolean.TRUE);

String CASLogin = serveurCASURL + "/login";

response.sendRedirect(response.encodeRedirectURL(CASLogin

+ "?service=" + urlMonService));

}

}

}



else

{

// On fait le callback

session.setAttribute("callback", "callback");

String CASLogin = serveurCASURL + "/login";

response.sendRedirect(response.encodeRedirectURL(CASLogin + "?service="

+urlMonService));

}

}

else

{

return true;

}

}

catch (Exception ex)

{

ex.printStackTrace();

}

return retour;

}

public boolean casInterne()

{

return true;

}

}

Ce code source n’est qu’un exemple, sur « JASIG » de nombreux client CAS JAVA 3.0 et 3.1 sont disponibles. https://wiki.jasig.org/display/CASC/CAS+Client+for+Java+3.0 https://wiki.jasig.org/display/CASC/CAS+Client+for+Java+3.1

http://www.jasig.org/cas/client-integration

https://wiki.jasig.org/display/CASC/CAS+Client+for+Java+3.0

https://wiki.jasig.org/display/CASC/CAS+Client+for+Java+3.1

Documents

DOCUMENTATION CAS A DESTINATION DES …stephane.boireau.free.fr/.../REFO-DT-ENTV2-ServeurCAS-v1.2.pdf · proposée par JASIG, créateur du Protocole CAS : 4 Application CAS : Application