Et si on intégrait nos applications GWT avec CAS ?

Intégrer de multiples partenaires et applications et donner une vision unifiée et simple à l’utilisateur passe souvent et entre autre par la mise en place d’une brique de SSO.
Dans ce domaine, CAS (Central Authentication Service) fait très certainement partie des référents. Reste que lorsque l’on m’a demandé si l’intégration d’applications GWT avec CAS était réalisable facilement, j’étais bien incapable de répondre…

overview

Overview de CAS

Etape#1 :
L’utilisateur réalise un accès à une ressource de l’application App#1. Un filtre CAS redirige vers la mire de login portée par CAS et l’url d’origine est spécifiée dans les paramètres de l’url de login. Un exemple d’url serait : https://localhost:8443/cas-server-webapp-3.3/login?service=http://localhost:9090/MyInsurance/com.octo.MyInsurance/MyInsurance.html

Etape #2 :
L’utilisateur s’authentifie. En complément, un cookie est associé à l’url CAS : ce cookie contient un ticket permettant d’identifier l’utilisateur et d’assurer qu’il est bien authentifié.
cookie

Etape #3 :
Dans la mesure où l’authentification a réussie, l’utilisateur est redirigé – via le navigateur – vers l’url initialement demandée. L’url initialement demandée est enrichie d’un attribut nommé ticket. Un exemple d’url serait : http://localhost:9090/MyInsurance/com.octo.MyInsurance/MyInsurance.html?ticket=ST-1-xd342ehPMiyVLhQjfxYo-cas

Etape #4 :
Cet appel vers l’url initiale est de nouveau filtré par CAS qui réalise alors un appel serveur à serveur pour valider le ticket passé en paramètre de l’url.
Une fois l’ensemble de ces étapes réalisées, l’utilisateur est authentifié pour App#1

Telles sont les grandes étapes de l’authentification avec CAS…Reste que la mise en œuvre d’un serveur CAS n’est guère plus complexe puisqu’il s’agit d’une application web déployée pour l’occasion sur un Tomcat. Les subtilités arrivent avec SSL : il vous faudra jouer avec les keystore et les truststore.

Intégration avec une application GWT

Les problématiques classiques de sécurité (ie. authentification et habilitation sur la fonction) ne sont pas nativement prise en compte par GWT. Reste qu’une pratique communément admise pour réaliser l’authentification au niveau d’une application GWT reste notre bon vieux mécanisme de « filtre » : autrement dit, s’appuyer sur un Servlet Filter de type Spring Security (ou Acegi pour les plus anciens…) ou JAAS (pour les dinosaures de mon style…)…

Ce qui est génial avec CAS, c’est que l’intégralité de la configuration tient en ces quelques lignes (A noter qu’il existe une intégration avec ACEGI, pas testée ici…)

<filter>
		</filter><filter -name>CAS Filter</filter>
		<filter -class>
			edu.yale.its.tp.cas.client.filter.CASFilter
		</filter>
		<init -param>
			<param -name>
				edu.yale.its.tp.cas.client.filter.loginUrl
			</param>
			<param -value>
				https://localhost:8443/cas-server-webapp-3.3/login
			</param>
		</init>
		<init -param>
			<param -name>
				edu.yale.its.tp.cas.client.filter.validateUrl
			</param>
			<param -value>
				https://localhost:8443/cas-server-webapp-3.3/serviceValidate
			</param>
		</init>
		<init -param>
			<param -name>
				edu.yale.its.tp.cas.client.filter.serverName
			</param>
			<param -value>localhost:9090</param>
		</init>
	

	<filter -mapping>
		</filter><filter -name>CAS Filter</filter>
		<url -pattern>/*</url>

Cette configuration présente dans le fichier web.xml de votre application permet de spécifier
– l’url de login portée par CAS via le paramètre loginUrl
– l’url du service de validation des tickets appelé à l’étape4 via le paramètre validateUrl.
Quant à la servlet CASFilter, elle est disponible au travers d’une librairie cliente fournie par CAS (cas-client-xx.jar) qu’il est nécessaire d’ajouter dans le répertoire WEB-INF/lib de votre webapp.

En somme, et je dois bien avouer que j’en suis le premier surpris, une intégration relativement transparente et simple même si la configuration utilisée nécessite un serveur CAS pendant les phases de développement. Reste à creuser l’intégration Spring Security/CAS qui devrait lever cette limitation en externalisant la configuration (notamment du web.xml)…

7 commentaires sur “Et si on intégrait nos applications GWT avec CAS ?”

  • Bonjour, je travaille en ce moment sur l'intégration de CAS dans un "ecosystème" d'applications web et ce qui me plait le plus en cette solution c'est la facilité à la paramétrer, l'étendre, disposer d'un niveau de sécurité élevé et sa simplicité de mise en place. Son intégration permet de mettre en place une navigation transparente chère à nos utilisateurs à moindre frais et sécurisée. Modifier son comportement de base afin de pouvoir réaliser une authentification depuis un formulaire hébergé sur l'application cliente est possible et résout beaucoup de contraintes par rapport à l'utilisation de la page de login sur le domaine CAS. Cordialement.
  • Bonjour, Autre fonctionnalité intéressante de CAS : le mode proxy. Avec ce mode, on configure une application cliente en tant que "proxy cas" c'est à dire qu'elle devient habilitée à générer des tickets proxy (PT). Ceci est utile si on veut accéder à une application qui n'est pas accessible directement depuis un navigateur. Dans ce cas, on interagit directement avec l'appli proxy qui se charge de faire transiter le PT à l'application distante qui valide ensuite le ticket auprès du serveur CAS. A noter que lorsque l'on utilise le mode proxy, le serveur CAS doit être en mesure d'établir une connexion https vers l'application proxy (callback), il faut donc configurer correctement le keystore côté serveur CAS.
  • Bonjour, Merci pour ce post. Ma question concerne l'affichage du LOGIN CAS après l'authentification. En effet, j'écris une page où je voudrais tout simplement afficher "vous êtes authentifié en tant que : " avec le login CAS de la personne authentifié. Comment faire ? normalement côté serveur, en écrivant ces lignes : HttpServletRequest request = this.getThreadLocalRequest(); HttpSession session = request.getSession(); session.getAttribute("user"); Je devrais pouvoir récupérer le login CAS, Mais quand je transmet au client, ma variable session est null. Une idée ? Merci d'avance.
  • CAS s'appuie sur son propre protocole de réponse. Dans celui -ci on retrouve de base le login utilisé. On peut ensuite étendre le fonctionnement et récupérer d'autres attributs. Certaines lib clientes sont dispo permettant via un simple getter de récupérer le login sinon il suffit juste de parser la réponse. Le protocole CAS est au format xml, le schéma est disponible sur le site du consortium jasig.
  • Pour info, la mini application : http://sourcesup.cru.fr/projects/gwtssocas/ La documentation : http://sourcesup.cru.fr/frs/download.php/2643/ApplicationSSOCASGoogleWebToolkit.pdf
  • @Jérémy le user est sauvegardé dans la session, dans un attribut de nom "edu.yale.its.tp.cas.client.filter.user" donc un simple : session.getAttribute("edu.yale.its.tp.cas.client.filter.user"); devrait faire ton bonheur sinon tu peux aussi regarder cette option : edu.yale.its.tp.cas.client.filter.wrapRequest
  • @Mab Désolé pour la réponse tardive Effectivement on peut récupérer l'attribut en session mais uniquement si on utilise le cas-client de yale. Dans mon cas je ne l'ai pas utilisé et préféré m'appuyer sur le protocole CAS pour récupérer l'info.
    1. Laisser un commentaire

      Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha