Ce document tente de donner des pistes de recherche en cas de dysfonctionnement lors de l'utilisation du SSO CAS.
Liens utiles
- la FAQ de l'IGC du CRU, en particulier, les documents keystore1 et keystore2
- la FAQ CAS sur le site de yale.
- Utilisation de certificats X509 pour CAS
- Utilisation de certificats X509 en Java
Documents
...
...
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
| Bloc de code |
|---|
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 :
| Bloc de code |
|---|
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
| Bloc de code |
|---|
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
...
...
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 :
| Bloc de code |
|---|
certificate no trusted
|
3) le nom de service passé pour valider le ST est différent de celui passé pour l'obtenir.
...
- D
- 'abord, celles d'un client CAS, mais avec accès au serveur CAS en https nécessairementEnsuite, 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à.
| Avertissement | ||
|---|---|---|
| ||
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
| Bloc de code |
|---|
194.214.218.163 "GET /login?service=[https://webmail.univ.fr/cas/index.php] HTTP/1.1"
|
Appli web proxy, recup du ticket
| Bloc de code |
|---|
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)
| Bloc de code |
|---|
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
| Bloc de code |
|---|
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
| Bloc de code |
|---|
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
| Bloc de code |
|---|
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
| Bloc de code |
|---|
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.
...
...
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"
...
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.
...
...
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
| Bloc de code |
|---|
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 :
| Bloc de code |
|---|
<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 :
| Bloc de code |
|---|
wget \-O /tmp/ent.log "https://ent.univ.fr:443/HealthCheck.html"
|
et /tmp/ent.log doit contenir :
| Bloc de code |
|---|
<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 :
| Bloc de code |
|---|
openssl s_client -host auth.univ.fr -port 443
|
Devrait sortir qq chose comme cela :
| Bloc de code |
|---|
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 :
| Bloc de code |
|---|
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.
...
Conclusion
En cas d'incident :
...