≪ View Page

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Prochaine révision		Révision précédente
informatique:securite:cas [2014/12/30 11:42] – créée bn8informatique:securite:cas [2018/02/07 15:06] (Version actuelle) – [Services autorisés à utilisé l'authentification CAS] bn8
Ligne 116: Ligne 116:
     * **ldap.manager.password :** Le mot de passe associé     * **ldap.manager.password :** Le mot de passe associé
  
 +<note important>Un service CAS est normalement **toujours** derrière une **connexion sécurisé (HTTPS)**. Si jamais, pour une raison que vous appartient, vous décider d'installer un service CAS derrière une connexion **non-sécurisé (HTTP)** il faudra modifier la configuration du générateur de cookie pour qu'il n'oblige pas les connexions sécurisées. Pour cela, copier le fichier //build/cas/WEB-INF/spring-configuration/ticketGrantingTicketCookieGenerator.xml// dans le dossier //custom/webpages/WEB-INF/spring-configuration// (à créé au préalable) et modifier le paramètre **p:cookieSecure** dans ce fichier comme suit : <code>[...]
 +        <bean id="ticketGrantingTicketCookieGenerator" class="org.jasig.cas.web.support.CookieRetrievingCookieGenerator"
 +                p:cookieSecure="false"
 +                p:cookieMaxAge="-1"
 +                p:cookieName="CASTGC"
 +[...]
 +</code></note>
  
 ==== Déploiement ==== ==== Déploiement ====
Ligne 130: Ligne 137:
   * Redémarrer //Tomcat7// : <code>sudo /etc/init.d/tomcat7 restart</code>   * Redémarrer //Tomcat7// : <code>sudo /etc/init.d/tomcat7 restart</code>
  
-<note important>Il semble que les dépôts //Maven// utiliser pour le //build// du serveur CAS est changé, rendant impossible les nouveaux déploiements. Cela ne pose cependant pas de problème au ancien déploiement qui dispose d'un cache local des dépendances. Une solution simple (mais crade) de contourner se problème est de récupérer le cache d'un serveur CAS préalablement déployé : il s'agit du dossier //current/build/maven-repository//.</note> +<note important>Il semble que les dépôts //Maven// utiliser pour le //build// du serveur CAS est changé, rendant impossible les nouveaux déploiements. Cela ne pose cependant pas de problème au ancien déploiement qui dispose d'un cache local des dépendances. Une solution simple (mais crade) de contourner se problème est de récupérer le cache d'un serveur CAS préalablement déployé : il s'agit du dossier //current/build/maven-repository//. Vous pouvez aussi télécharger {{:informatique:cas-server-maven-cache-repository-content.tar.bz2|l'archive suivante}} qui contient le dossier //maven-repository//.</note>
 ==== Re-déploiement ==== ==== Re-déploiement ====
  
Ligne 154: Ligne 160:
 <note>Seul les services HTTP/HTTPS ont cepandant accès aux attributs CAS.</note> <note>Seul les services HTTP/HTTPS ont cepandant accès aux attributs CAS.</note>
  
-Il est possible d'ajouter des nouveaux services autorisés lorsque le service est démarré en utilisant l'interface [[https://login.enercoop.org/cas/services/manage.html]]. Il faudra pour cela se connecté avec un utilisateur reconnu comme //ADMIN// du service (cf. paramètre //security.useradmin//).+Il est possible d'ajouter des nouveaux services autorisés lorsque le service est démarré en utilisant l'interface [[https://login.example.fr/cas/services/manage.html]]. Il faudra pour cela se connecté avec un utilisateur reconnu comme //ADMIN// du service (cf. paramètre //security.useradmin//).
  
 <note important>**Attention :** Les ajouts fait par ce biais ne sont pas conservé lors du redémarrage du service.</note> <note important>**Attention :** Les ajouts fait par ce biais ne sont pas conservé lors du redémarrage du service.</note>
 +
 +===== Problème de la déconnexion générale (Single-Sign-Out) =====
 +
 +Pour bien comprendre le problème, mieux vaut l'expliquer complètement :
 +  * lorsqu'un utilisateur s'authentifie auprès de serveur CAS, le serveur défini un cookie de session (stocké dans le navigateur du client) qui permet de faire en sorte qu'il soit reconnu à son prochain passage
 +  * lorsqu'une application authentifie un utilisateur via le serveur CAS, elle initie également une session pour l'utilisateur et défini son propre cookie pour cette session
 +  * lorsque l'authentification SSO est gérée par Apache, le module SSO d'Apache gère également sa propre session (et son propre cookie) en plus de celle géré par l'application.
 +
 +Dans le cas d'un accès à une application (authentifié par Apache) via une application de type portail (gérant sa propre connexion SSO), l'utilisateur dispose donc normalement d'au moins quatre sessions :
 +  * une au niveau du serveur CAS
 +  * une au niveau de l'application portail
 +  * une au niveau de l'Apache donnant accès à l'application tierce
 +  * une au niveau de l'application tierce
 +
 +Pour déconnecter l'utilisateur proprement, il faut :
 +  * soit que l'utilisateur ferme son navigateur : tous les cookies de session seront alors invalidés/supprimés par le navigateur
 +  * soit que chaque application clos sa propre session ce qui revient le plus souvent au final à supprimer son cookie de session
 +
 +Dans le cas d'une authentification géré par Apache via le module mod_auth_cas, la déconnexion n'est pas gérée correctement. En outre, il est possible pour l'application authentifiée par Apache gère la suppression du cookie du module //mod_auth_cas// d'Apache en plus du sein au moment de la déconnexion.
 +
 +Un autre critère est à prendre en compte par ailleurs : lors de la déconnexion d'un utilisateur au niveau d'une application, celle-ci clos sa session avant de rediriger l'utilisateur vers la déconnexion du niveau du portail SSO. Cependant, si l'utilisateur était connecté auprès d'une autre application, la déconnexion auprès de celle-ci n'est pas gérée si l'application ne supporte pas le mécanisme de Single-Sign-Out (ce qui est le cas de la plupart des applications utilisant le protocole CAS). Pour ce problème, il existe cependant une solution :
 +  * les boutons de déconnexion des applications doivent renvoyer l'utilisateur vers une page web intermédiaire avant la déconnexion SSO.
 +  * sur cette page intermédiaire, on fait appel à l'ensemble des pages de déconnexions des applications utilisant le SSO (via des balises iframes ou des pseudos balises images) avant de rediriger l'utilisateur vers la déconnexion au niveau du portail SSO en lui-même.
 +
 +<note>Il est à noter cependant que cette solution n'est pas idéale car si l'utilisateur ferme l'onglet de son navigateur durant le temps de chargement de la page intermédiaire de déconnexion, il ne sera pas bien déconnecté.</note>