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
Tout droit réservé ITOP Education ©
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
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 3 / 20
Tout droit réservé ITOP Education ©
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
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 4 / 20
Tout droit réservé ITOP Education ©
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
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 5 / 20
Tout droit réservé ITOP Education ©
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
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 6 / 20
Tout droit réservé ITOP Education ©
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
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 7 / 20
Tout droit réservé ITOP Education ©
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
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 8 / 20
Tout droit réservé ITOP Education ©
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
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 9 / 20
Tout droit réservé ITOP Education ©
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.
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 10 / 20
Tout droit réservé ITOP Education ©
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
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 11 / 20
Tout droit réservé ITOP Education ©
- 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='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>
- 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='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>37DB5E37-0345-46D5-A0F5-4394B26E9FEA</cas:user>
</cas:authenticationSuccess>
</cas:serviceResponse>
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 12 / 20
Tout droit réservé ITOP Education ©
- 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='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: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.
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 13 / 20
Tout droit réservé ITOP Education ©
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
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 14 / 20
Tout droit réservé ITOP Education ©
6. ANNEXES
Réponses du serveur CAS
Authentification réussie
<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>37DB5E37-0345-46D5-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='http://www.yale.edu/tp/cas'>
<cas:authenticationFailure code="INVALID_TICKET">
Ticket ST-1856339-aA5Yuvrxzpv8Tau1cYQ7 not recognized
</cas:authenticationFailure>
</cas:serviceResponse>
Le tag « cas:authenticationFailure » indique que l'authentification a échouée.
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 15 / 20
Tout droit réservé ITOP Education ©
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.");
}
}
}
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 16 / 20
Tout droit réservé ITOP Education ©
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
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 17 / 20
Tout droit réservé ITOP Education ©
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');
?>
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 18 / 20
Tout droit réservé ITOP Education ©
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;
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 19 / 20
Tout droit réservé ITOP Education ©
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));
}
}
}
REFO-DT-ENTV2-ServeurCAS-v1.2.docx – 21/03/12 Page 20 / 20
Tout droit réservé ITOP Education ©
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