Documentation
Pages enfant
  • Recherche de dysfonctionnements CAS

Vous regardez une version antérieure (v. /wiki/spaces/DOC/pages/7209096/Recherche+de+dysfonctionnements+CAS) de cette page.

afficher les différences afficher l'historique de la page

« Afficher la version précédente Vous regardez la version actuelle de cette page. (v. 9) afficher la version suivante »

Ce document tente de donner des pistes de recherche en cas de dysfonctionnement lors de l'utilisation du SSO CAS.

Liens utiles

Fonctionnement d'un client CAS

Le client CAS est en fait une application web, qui utilise le serveur CAS pour authentifier un utilisateur.

Contraintes

  • Le navigateur W3 doit être capable de gérer les redirections http.
  • L'application web client CAS doit pouvoir accéder directement en http (s) auprès du serveur CAS pour faire valider le Service Ticket (ST). Est-ce possible ?

Cinématique, et logs associés

Dans l'exemple, l'adresse IP du navigateur est 194.214.218.163, celle de l'appli web cliente 194.214.218.39.

Le navigateur accède pour la première fois à une application web.

Celle-ci le redirige (redirection http) vers le serveur CAS pour authentification.

regarder les logs d'accès du serveur CAS lors de la phase de login / récupération de Service Ticket (ST) pour vous assurer des paramètres de redirections passés (paramètre service)

Logs serveur CAS 

194.214.218.163 "GET /index.jsp?service=http://ent.univ.fr/Login HTTP/1.1" 

L'application web cliente récupère le Service Ticket (ST).

Logs appli web cliente : 

194.214.218.163 "GET /Login?ticket=ST-37-sIMC5FhJx15GRwZtJ1Q7 HTTP/1.1"

Validation du ticket

L'appli web cliente génère une requête http ou https pour faire valider le ticket, vers l'URI LegacyValidate (protocole CAS V1) ou ServiceValidate (protocole CAS V2). Le login sera retourné par le serveur CAS et réponse de cette requête.

Logs serveur CAS 

194.214.218.39 GET /serviceValidate?service=http://ent.univ.fr/Login&ticket=ST-37-sIMC5FhJx15GRwZtJ1Q7 HTTP/1.1

S'assurer que le ticket est bien le bon, et que le service passé en paramètre correspond au service passé lors de la demande du ticket.

Validation du certificat

Si l'application web cliente CAS accède au serveur CAS en https pour faire valider son ST : il faut qu'elle soit capable de valider le certificat transmis par le serveur https.

Elle fait donc référence à un 'magasin de certificats', qui doit contenir au moins le certificat du server CAS, ou d'une autorité de certification ayant délivré le certificat.

Causes de non fonctionnement

1) l'application cliente CAS ne peut pas accéder en http(s) au serveur CAS : firewall, ACLs routeur, ...

2) l'application cliente fait valider le ST en https, alors que le certificat du serveur CAS n'est pas validé. Dans le cas d'une servlet hébergée par tomcat, un message est affiché dans le fichier catalina.out, du genre :

certificate no trusted

3) le nom de service passé pour valider le ST est différent de celui passé pour l'obtenir.

Fonctionnement d'un proxy CAS

Contraintes


  • D'abord, celles d'un client CAS, mais avec accès au serveur CAS en https nécessairement
  • Ensuite, l'application proxy CAS doit être elle même accessible en https du serveur CAS, au minimum sur l'URL de callback, qui doit être paramétrable.

    Cinématique, et logs associés

Vérifier le fonctionnement client CAS simple

Vérifier que l'application fonctionne au moins en client CAS simple. Voir la rubrique dédiée à celà.

Important

La demande de ST doit se faire en https et sur l'URI serviceValidate; elle comporte un paramètre supplémentaire, pgtUrl, qui indique que l'application web veut être proxy ; ce paramètre indique l'URLde callback.

Voici les logs des serveur CAS et Appli web proxy lors du login (identique au précédent), puis de la demande de validation du ticket ; ici, 194.214.218.163 est l'adresse IP du navigateur W3, 194.214.218.40 le serveur CAS, 194.214.218.198 l'appli web proxy CAS (ici, webmail imp), 194.214.218.110 le service tiers (ici, serveur IMAP)


Serveur CAS, demande de ST

194.214.218.163 "GET /login?service=[https://webmail.univ.fr/cas/index.php] HTTP/1.1"

Appli web proxy, recup du ticket

194.214.218.163 "GET /cas/index.php?ticket=ST-1681-9IpDqJ2ang4SBf8aanzT HTTP/1.1"

Serveur CAS, validation du ST et demande du PGT (Proxy Granting Ticket)

194.214.218.198 "GET /serviceValidate?service=https://webmail.univ.fr/cas/index.php&ticket=ST-1681-9Ip...&pgtUrl=https://webmail.univ-nancy2.fr/cas/casProxy.php

URL de callback

Avant de délivrer la réponse du GET précédent, le serveur CAS tente un connexion directe en https vers l'URL de callback de l'application web proxy, en passant 2 paramètres : PGTIOU et PGT

Appli web proxy

194.214.218.40">https://webmail.univ.fr/cas/index.php&ticket=ST-1681-9Ip...&pgtUrl=https://webmail.univ-nancy2.fr/cas/casProxy.php

URL de callback

Avant de délivrer la réponse du GET précédent, le serveur CAS tente un connexion directe en https vers l'URL de callback de l'application web proxy, en passant 2 paramètres : PGTIOU et PGT

Appli web proxy

194.214.218.40 "GET /cas/casProxy.php?pgtIou=PGTIOU-547-mnkcs...&pgtId=PGT-1094-sxP1d4vj... HTTP/1.1"

Le serveur CAS répond seulement maintenant au GET serviceValidate, en passant l'identité de la personne, et le PGTIOU ; le proxy CAS peut maintenant associer le PGT reçu à l'utilisateur authentifié.

Requête de PT

L'application proxy dispose maintenant d'un PGT pour l'utilisateur (ici; PGT-1094-...). Elle va pouvoir requérir auprès du serveur CAS des Proxy-Ticket (PT) pour des applications tierces.

Cette demande de PT se fait nécessairement en https, en passant en paramètres le PGT et le 'service' associé, vers l'URI proxy.

Serveur CAS

194.214.218.198 "GET /proxy?targetService=imap://mail.univ.fr&pgt=PGT-1094-s.... HTTP/1.1"

Transmission du PT

le proxy CAS transmet le PT à l'application tierce ; si cette application logue ses accès, il est possible de 'tracer' cet envoi. Dans notre exemple, c'est le serveur imap Casifié, nous n'avons pas de logs

Validation du PT

l'application tierce (serveur IMAP, dans l'exemple) fait valider son PT directement auprès du serveur CAS.

Serveur CAS

194.214.218.110 "GET /proxyValidate?ticket=PT-1682-GMxYazU89ZuGIkpYOhyd&service=imap://mail.univ.fr HTTP/1.0"

On constate que les étapes 4 et 5 sont similaires à une authentification CAS simple, le proxy CAS remplacant le navigateur pour obtenir des PT.

Causes de non fonctionnement en mode proxy

Dans un premier temps, il faut déja s'assurer que l'application web cliente CAS fonctionnement correctement en mode non proxy.

Il faut que l'application proxy puisse accéder en https au serveur CAS, que le serveur CAS puisse accéder en https vers le proxy.

Il faut également que le service tiers accède en http(s) au serveur CAS (avec mod_cas et pam_cas, c'est nécessairement https).

Pour toutes ces connexions https, il faut que le client puisse valider le certificat du serveur, ou une autorité de certification ayant validé le certificat.

Dans le cas de mod_cas et pam_cas, il ne faut passer que le certificat de l'autorité racine.

La cause de loin la plus courante de dysfonctionnement se situe dans les connexions https, lorsque les clients n'ont pas les certificats pour valider la connexion https.

autres causes possibles :

  • le nom de service passé pour valider le PT est différent de celui passé pour l'obtenir.
  • URL de callback en http au lieu de https. Dans ce cas, le message suivant est écrit dans le fichier de log du serveur CAS :
    PGT callback failed: java.io.IOException: only 'https' URLs are valid for this method

Cas et uPortal

Comment savoir si mon installation uPortal est bien proxy CAS ?

Il est possible d'être correctement authentifié via CAS dans uPortal, sans que uPortal se comporte en proxy CAS.

Pour s'assurer qu'uPortal est bien proxy CAS, un canal de test est distribué avec esup-portail : CASTest.

Par défaut, ce canal n'est utilisable que par les administrateurs uPortal.

Pour l'utiliser, 2 solutions :

  • Soit mettre le compte d'essai dans le groupe des administrateurs uportal
  • Soit autoriser son utilisation à une population plus large
  • Se loguer en admin, afin d'autoriser l'allocation du canal à d'autres populations
  • Se loguer avec un compte d'essai authentifié CAS
  • S'allouer le canal "Test CAS en mode proxy"
  • Cliquer sur le bouton "Demander un PT". La réponse doit être "Le fonctionnement Proxy CAS est correct"

Certificats X509

Comme indiqué précédemment, la principale cause de dysfonctionnements se situe dans les connexions https, lorsque le client n'arrive pas à valider le certificat du serveur https.

Une première recherche, est de tenter une connexion https vers le serveur, depuis un navigateur. si la connexion fonctionnement, cliquer sur le cadenas de sécurité, et controler votre certificat ; profitez-en pour vérifier la chaine de certification éventuelle.

L'idéal est de disposer d'une IGC (PKI en anglais) qui puisse valider les certificats des différents serveurs https.

Ainsi, il est juste nécessaire de valider le certificat racine de l'IGC pour vos différents serveurs, y compris le serveur CAS (pam_cas et mod_cas exceptés).

Quelques pistes de recherche de problèmes

Les causes les plus fréquentes de dysfonctionnement sont :

  • requêtes https filtrées par un firewall ou un routeur
  • certificats https non valides, ou chaine de certification non transmise par le serveur W3.
    Dans les exemples qui suivent, ent.univ.fr est un proxy cas, auth.univ.fr est le serveur CAS.

S'assurer qu'un firewall ou un routeur ne filtre pas les requêtes

A l'aide de wget, on va s'assurer que les connexions https directes sont autorisées (adapter les ports TCP en fonction de votre configuration.

Coté ent

wget -O /tmp/cas.log "https://auth.univ.fr:443/proxyValidate?ticket=PT-1-xxx&service=[https://foo.fr]"

Le fichier /tmp/cas.log devrait contenir :

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationFailure code='INVALID_TICKET'>
ticket 'PT-1-xxx' not recognized
</cas:authenticationFailure>
</cas:serviceResponse>

Coté serveur CAS

Même technique, en choisissant une URL valide. ex :

wget \-O /tmp/ent.log "https://ent.univ.fr:443/HealthCheck.html"

et /tmp/ent.log doit contenir :

<html>
<body>
Health Check ent2
</body>
</html>

Controler les certificats

Nous supposons ici que les certificats serveurs du CRU sont utilisés.

Deux méthodes possibles.

Depuis un navigateur W3

La procédure peut différer légèrement d'un navigateur à l'autre.

S'assurer que seul le certificat de l'AC racine du CRU est présente dans le magasin de certificats : pas le certificat ac-serveur ni de certificat du serveur lui-même.

Lancer https://auth.univ.fr

Aucun warning ne devrait être généré par le navigateur.

Cliquer sur le cadenas en bas à droite du navigateur.

Voir le détail du certificat. En particulier, le certificat doit être vu comme valide, et la chaîne de certification doit être affichée :

ac-racine -> ac-serveur -> auth.univ.fr

Faire la même chose avec https://ent.univ.fr

Avec openssl

Faire :

openssl s_client -host auth.univ.fr -port 443

Devrait sortir qq chose comme cela :

CONNECTED(00000003)
depth=2 /C=FR/O=CRU/CN=ac-racine/emailAddress=ca-admin@cru.fr
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=FR/O=0541508W/CN=auth.univ-nancy2.fr/emailAddress=reseau@univ-nancy2.fr
i:/C=FR/O=CRU/CN=ac-serveur/emailAddress=ca-admin@cru.fr
1 s:/C=FR/O=CRU/CN=ac-serveur/emailAddress=ca-admin@cru.fr
i:/C=FR/O=CRU/CN=ac-racine/emailAddress=ca-admin@cru.fr
2 s:/C=FR/O=CRU/CN=ac-racine/emailAddress=ca-admin@cru.fr
i:/C=FR/O=CRU/CN=ac-racine/emailAddress=ca-admin@cru.fr
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEWzCCA0OgAwIBAgICAjgwDQYJKoZIhvcNAQEEBQAwUDELMAkGA1UEBhMCRlIx
....
-----END CERTIFICATE-----
subject=/C=FR/O=0541508W/CN=auth.univ-nancy2.fr/emailAddress=reseau@univ-nancy2.fr
issuer=/C=FR/O=CRU/CN=ac-serveur/emailAddress=ca-admin@cru.fr
---
No client certificate CA names sent
---
SSL handshake has read 3662 bytes and written 340 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
SSL-Session:
.... Verify return code: 19 (self signed certificate in certificate chain)
---

Il Faut s'assurer que la chaine de certification est bien transmise.

Utilitaire testHTTPS

Le programme Java testHTTPS est autonome, il permet de faire une requête https vers un serveur web.

Télécharger : testHTTPS.tar.gz

Voici le script de lancement fourni dans le tar.gz :

export JAVA_HOME=/usr/java/jdk1.5
HOST=auth.univ-nancy2.fr
PORT=443
#HTTP_VER=HTTP/1.1
#ENCODING=ISO-8859-1
#
#### ATTENTION #####
# Le parametre host est obligatoire.
# le defaut est 443 pour le port, "HTTP/1.0" pour le protocole, "ISO-8859-1" pour l'encoding
# l'ordre des parametres est important. Par exemple, si on veut specifier HTTP_VER (HTTP/1.0, par exemple),
# il faut decommenter les parametres PORT et HTTP_VER
#
#$JAVA_HOME/bin/java testHTTPS $HOST $PORT $HTTP_VER $ENCODING
$JAVA_HOME/bin/java -Djavax.net.ssl.trustStore=/Cert/ac-racine-cru.keystore testHTTPS $HOST $PORT $HTTP_VER $ENCODING
#$JAVA_HOME/bin/java -Djavax.net.ssl.trustStore=/Cert/esup-portail.keystore testHTTPS $HOST $PORT $HTTP_VER $ENCODING

Cet utilitaire permet de s'assurer que que keystore passé dans le paramètre javax.net.ssl.trustStore permet à la JVM de valider le certificat (ou la chaine de certification) proposée par le serveur https.

Si le paramètre javax.net.ssl.trustStore n'est pas précisé, c'est le keystore de la JVM (jre/lib/security/cacerts) qui est utilisé pour la validation du certificat.

Conclusion

En cas d'incident :

  • Consulter les logs des serveurs W3
  • Consulter le catalina.out des tomcats support de CAS ou des applications. Si un problème de certificat se présente, un erreur sera remontée dans cette log
  • Consulter les éventuels logs applicatifs
  • Aucune étiquette