|
Ce document tente de donner des pistes de recherche en cas de dysfonctionnement lors de l'utilisation du SSO CAS. |
| Dates de modification | ||
|---|---|---|
|
|
|
|
|
|
|
|
la FAQ CAS sur le site de yale.
Un document esup-portail sur l'utilisation des certificats X509 en Java : java_x509.html
Un document esup-portail sur l'utilisation des certificats avec CAS : cas_x509.html
Nous sommes dans un environnement ou il est nécessaire que des applications doivent communiquer directement, et se faire confiance.
Pour celà, https est utilisé pour des communications directes entre une application cliente (qui peut être elle-même une servlet) et une application accessible en https.
Pour bien comprendre les besoins, il faut distinguer les deux types d'usage des certificats liés aux communications https directes entre une appli cliente java et un serveur https, l'appli cliente étant dans notre cas une servlet de même que l'appli serveur.
L'application serveur https doit être accessible en ... https.
C'est donc le serveur W3 qui doit être paramétré pour supporter le https. C'est dans la configuration du serveur W3 qu'on doit indiquer où trouver la clé privée du serveur, le certificat (qui contient la clé publique correspondante), et les certificats éventuels des Autorités de Certification faisant partie de la chaine de certification de délivrance du certificat du serveur, dans le cas d'un certificat non auto-signé).
Deux cas sont traité ici :
Le serveur est un serveur apache, frontal du serveur application
Tomcat traite directement les requêtes https
On utilise habituellement mod_ssl. Voir la documentation à ce sujet. D'une manière très succinte :
SSLCertificateFile précise le nom du fichier qui contient la clé privée
SSLCertificateChainFile précise le nom d'un fichier en format PEM qui contient le certificat du serveur, et des éventuelles Autorités de Certification.
Il faut préparer un keystore (magasin de certificat) qui doit contenir à la fois la clé privée du serveur https, et le certificat du serveur et éventuellement celui des AC de la chaine de certification.
Voir le document officiel tomcat.
Il faut que l'application cliente génère des connexions https vers le serveur. Il est donc nécessaire de lui faire connaitre les serveurs auxquels elle peut faire confiance. Il faut donc lui communiquer le certificat (pas la clé privée, bien sur) du serveur https, ou de l'une des AC de la chaine de certification éventuelle.
Avec java, ceci se fait également avec un keystore, qui peut être paramétré de plusieurs façons :
Soit ajouter le certificat dans le keystore par défaut de la JVM
Soit préciser au lancement de la JVM (donc dans notre cas, de tomcat) de ne pas utiliser le keystore global de la JVM, mais celui qu'on aura préparé.
Soit l'application java est programmée pour savoir lire un keystore particulier. Ce n'est pas le cas du serveur CAS ni d'uPortal.
Voir les packages d'installation disponibles à : http://esup-casgeneric.sourceforge.net/
Voir également les documents esup-portail préalablement citées : java_x509.html et cas_x509.html.
Le client CAS est en fait une application web, qui utilise le serveur CAS pour authentifier un utilisateur.
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 ?
Dans l'exemple, l'adresse IP du navigateur est 194.214.218.163, celle de l'appli web cliente 194.214.218.39.
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)
194.214.218.163 "GET /index.jsp?service=http://ent.univ.fr/Login HTTP/1.1"
194.214.218.163 "GET /Login?ticket=ST-37-sIMC5FhJx15GRwZtJ1Q7 HTTP/1.1"
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.
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.
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.
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.
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.
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)
194.214.218.163 "GET /login?service=https://webmail.univ.fr/cas/index.php HTTP/1.1"
194.214.218.163 "GET /cas/index.php?ticket=ST-1681-9IpDqJ2ang4SBf8aanzT HTTP/1.1"
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
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
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é.
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.
194.214.218.198 "GET /proxy?targetService=imap://mail.univ.fr&pgt=PGT-1094-s.... HTTP/1.1"
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
l'application tierce (serveur IMAP, dans l'exemple) fait valider son PT directement auprès du 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.
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
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"
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).
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.
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.
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>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>
Nous supposons ici que les certificats serveurs du CRU sont utilisés.
Deux méthodes possibles
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
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.
C'est un programme java autonome, qui permet de faire une requête https vers un serveur web.
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.
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