A DESTINATION DES SERVICES TIERS. Editeurs d applications et ressources pédagogiques connectées à l ENT

Transcription

1 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 Dernières modifications Editeurs d applications et ressources pédagogiques connectées à l ENT Ajout des références vers le SDET et l annexe AAS

2 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 /02/2012 Création du document GJ /03/2012 Ajout des annexes GJ /03/2012 Ajout des références au SDET et à l annexe AAS. GJ Vérif. par

3 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 3 / 20 SOMMAIRE 1. Préambule 4 2. Présentation du protocole CAS (Central Authentication Service) 5 3. Fonctionnement du serveur Fonctionnement sans proxy 1ére connexion Fonctionnement sans proxy 2ème connexion Fonctionnement sans proxy Définitions 8 TGC - Ticket Granting Cookie 8 ST Service Ticket 8 4. Fonctionnement Client CAS Définition Mise en place d une authentification CAS Prérequis Installation d un client CAS 9 5. Respect du SDET Annexe AAS : 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

4 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 4 / PREAMBULE Dans ce document, les éditeurs de service tiers peuvent trouver la description du système d authentification unique SSO 1 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 connecteur 2 ) - 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

5 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 5 / PRESENTATION DU PROTOCOLE CAS 3 (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 4 de 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 : 4 Application CAS : Application possédant un client CAS

6 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 6 / Fonctionnement sans proxy 1ére connexion Nous allons décrire la connexion étape par étape en s appuyant sur le schéma suivant : Client / Navigateur Application tierce 1 Connecteur 4 /cas/servicevalidate ou /cas/validate /cas/login Service de validation Service d authentification 3b Serveur CAS 3 3a 3a Active Directory 1. Un utilisateur se connecte à une application Web CAS. 2. Il est redirigé vers le formulaire de login du serveur CAS. o Url : 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 : 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: =ST et 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.

7 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 7 / 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 : Client / Navigateur Application tierce 1 Connecteur 3 /cas/servicevalidate ou /cas/validate /cas/login Service de validation Service d authentification 2 Serveur CAS 3 1. Un utilisateur accède à une application Web CAS. 2. Il est redirigé vers le serveur CAS. o Url : 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 : 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: =ST et 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.

8 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 8 / 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ée 5. 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 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

9 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 9 / FONCTIONNEMENT CLIENT CAS 4.1. Définition Un client CAS est un module 6 permettant de faire interagir l application avec le serveur CAS. Sur le site de JASIG ( 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 Mise en place d une authentification CAS 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) 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.

10 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 10 / 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 Nationale 7. 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 : AAS 8 - «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 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. 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=' <cas:authenticationsuccess> <cas:user>37db5e d5-a0f5-4394b26e9fea</cas:user> <cas:profil>national_3</cas:profil> <cas:uai> z</cas:uai> </cas:authenticationsuccess> </cas:serviceresponse> 7 SDET : 8 AAS :

11 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 11 / 20 - 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 : <cas:serviceresponse xmlns:cas=' <cas:authenticationsuccess> <cas:user>37db5e d5-a0f5-4394b26e9fea</cas:user> <cas:profil>national_3</cas:profil> <cas:uai> z</cas:uai> </cas:authenticationsuccess> </cas:serviceresponse> - 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 : <cas:serviceresponse xmlns:cas=' <cas:authenticationsuccess> <cas:user>37db5e d5-a0f5-4394b26e9fea</cas:user> </cas:authenticationsuccess> </cas:serviceresponse>

12 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 12 / 20 - 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:serviceresponse xmlns:cas=' <cas:authenticationsuccess> <cas:user>37db5e d5-a0f5-4394b26e9fea</cas:user> <cas:profil>national_3</cas:profil> <cas:uai> z</cas:uai> <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> </cas:authenticationsuccess> </cas:serviceresponse> L AAS autorise toute transmission d information tant que celles-ci ne sont pas des informations d authentifications et nominatives.

13 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 13 / 20 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

14 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 14 / ANNEXES Réponses du serveur CAS Authentification réussie <cas:serviceresponse xmlns:cas=' <cas:authenticationsuccess> <cas:user>37db5e d5-a0f5-4394b26e9fea</cas:user> </cas:authenticationsuccess> </cas:serviceresponse> Le tag «cas:authenticationsuccess» indique que l'authentification est réussie. Authentification échouée <cas:serviceresponse xmlns:cas=' <cas:authenticationfailure code="invalid_ticket"> Ticket ST aA5Yuvrxzpv8Tau1cYQ7 not recognized </cas:authenticationfailure> </cas:serviceresponse> Le tag «cas:authenticationfailure» indique que l'authentification a échouée.

15 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 15 / 20 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 = " 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.");

16 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 16 / 20 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.

17 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 17 / 20 PHP Structure de l application Web Pour tester un client CAS en PHP, vous pouvez utiliser le client PHP CAS suivant : phpcas : Il est nécessaire de télécharger la version adaptée à votre version de PHP. Vous trouverez des exemples d utilisation sur la page suivante : 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');

18 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 18 / 20 Prérequis JAVA 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(" urlmonservice = "https" + urlmonservice.substring(4, urlmonservice.length()); else if (urlmonservice.startswith("www")) urlmonservice = " + 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;

19 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 19 / 20 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 = " + datasource + "/cas/servicevalidate" ; urlmonservice = StringUtils.replace(urlMonService, " " 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(); else else 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é!"); System.out.println(">> Erreur CAS : " + st.geterrorcode() + " - " + st.geterrormessage()); // Le ticket est null : on le demande session.setattribute("ticketdemande", Boolean.TRUE); String CASLogin = serveurcasurl + "/login"; response.sendredirect(response.encoderedirecturl(caslogin + "?service=" + urlmonservice));

20 REFO-DT-ENTV2-ServeurCAS-v1.2.docx 21/03/12 Page 20 / 20 else // On fait le callback session.setattribute("callback", "callback"); String CASLogin = serveurcasurl + "/login"; else return true; response.sendredirect(response.encoderedirecturl(caslogin + "?service=" +urlmonservice)); 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.