Le front office et le back office communiquent via SSL en utilisant des certificats x509.
L'authentification est dite « mutuelle ». Le front office et le back office doivent chacun avoir un certificat propre qu'ils s'échangent lors de chaque connexion l'un à l'autre.
Afin d'effectuer cette authentification mutuelle deux notions sont importantes sur chaque serveur : le keystore et le truststore.
Si le certificat reçu est issu d'une autorité de certification, des mécanismes automatiques sont déclanchés pour valider le certificat.
Si le certificat reçu est auto-signé ou bien si le serveur dans l'incapacité d'utiliser les mécanismes automatiques de validation, le serveur va regarder dans une liste de certificats de confiance s'il y trouve ce certificat. Cette liste de certificats de confiance est un truststore.
Au sein d'un keystore ou d'un truststore, chaque certificat (et clés associées dans le cadre des keystore) est identifié par un alias.
Donc, au minimum dans le cadre d'une authentification via certificats auto-signés :
Dans tous les web services mis en place, les front offices sont des clients (ils initient la connexion) et le back office serveur. Le certificat d'un serveur doit respecter une règle :
le CN (Common Name, correspondant à la question nom et prénom lors de la génération par keytool) doit correspondre au nom de la machine.
Exécutez la commande suivante :
keytool -genkey -alias serverkey -keystore keystoreserver.jks |
Répondez aux questions posées en respectant la règle énoncée ci-dessus.
Ensuite, auto-signez le keystore créé avec la commande suivante :
keytool -selfcert -alias serverkey -keystore keystoreserver.jks |
Le certificat est un élément de paramétrage d'applications dans l'administration du back
office. Pour extraire le certificat, exécutez la commande suivante (à adapter suivant le
certificat à extraire) :
keytool -export -alias clientkey -keystore keystoreclient.jks certifclient.crt -file keystore front office |
Les keystore front office contiennent les certificats qui serviront à authentifier les applications appelantes au sein des back office. Chaque certificat front office doit respecter la règle suivante :
le CN (Common Name, correspondant à la question nom et prénom lors de la génération par keytool) doit correspondre au nom de l'application qui sera paramétrée dans le back office.
Exécutez la commande suivante :
keytool -genkey -alias clientkey -keystore keystoreclient.jks |
Répondez aux questions posées en respectant la règle énoncée ci-dessus.
Ensuite, auto-signez le keystore créé avec la commande suivante :
keytool -selfcert -alias clientkey -keystore keystoreclient.jks |
Ce keystore doit ensuite être ajouté à l'éventuel keystore existant dans l'environnement, par exemple au esup-portail.keystore.
Un truststore contient tous les certificats de confiance d'une machine. Si la machine cible contient déjà un truststore, la manipulation consiste à ajouter un nouveau certificat au truststore existant. Le truststore client existe déjà à priori et contient le certificat du serveur CAS. Il ne faut surtout pas le supprimer.
Les manipulations suivantes sont à effectuer de manière à ce que :
Exécutez la commande suivante (à adapter suivant le certificat à extraire) :
keytool -export -alias serverkey -keystore keystoreserver.jks -file ./certifserveur.crt |
Exécutez la commande suivante (à adapter suivant le truststore et le certificat à importer)
Il faut ajouter le certificat du serveur au truststore du client :
keytool -import -keystore truststoreclient.jks -alias certifserver -file certifserveur.crt |
Il faut ajouter le certificat du client au truststore du serveur :
keytool -import -keystore truststoreserver.jks -alias certifclient -file certifclient.crt |
Mise en place du port d'écoute
Le back office est déployé en tant que servlet. La mise en place de la liaison sécurisée avec authentification du client se fait au niveau du paramétrage du connecteur du serveur tomcat utilisé pour les web services.
Lors d'un déploiement en mode quick start, le paramétrage des keystore et truststore back office s'effectue via les propriétés suivantes du fichier build.properties :
Le fichier server.xml utilisé par le serveur tomcat lancé est celui situé dans le dossier
utils/tomcat. Le connecteur est paramétré comme suit :
<Connector port="${tomcat.port}" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" enableLookups="false" redirectPort="8444" acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" scheme="https" secure="true" clientAuth="true" sslProtocol="TLS" keystoreFile="${tomcat.keystore}" keystorePass="${tomcat.keypass}" truststoreFile="${tomcat.truststore}" truststorePass="${tomcat.truststorePass}" /> |
Afin de faciliter la mise en place lors d'un déploiement servlet du front office, la mise en place des keystore et truststores (qui sont uniques pour un environnement) a été mise en place au sein même de l'application.
Les propriétés suivantes du fichier config.properties sont à décommenter et à renseigner :
Ensuite, décommentez le bean initSslParameters du fichier properties/client/client.xml
Keystore et truststore sont unique pour un environnement. Dans le cadre d'un déploiement portlet, le portail possède des éléments de certification, notamment pour la mise en place de l'authentification par serveur CAS. La mise en place des certificats du service doit donc venir compléter l'existant. Les clés et certificats doivent être importés dans les keystore et truststore existants et être paramétrés pour être pris en compte dès le lancement du portail.
Une solution consiste à modifier le fichier env.cmd du portail de la sorte :
SET TRUST_CERT=[chemin du truststore] SET KEY_CERT=[chemin du keytore] SET PWD_KEYSTORE=[mot de passe du keystore] |
Puis modifier le fichier start-esup pour y intégrer la commande suivante :
SET CATALINA_OPTS="-Djavax.net.ssl.keyStore=%KEY_CERT%" "- Djavax.net.ssl.keyStorePassword=%PWD_KEYSTORE%" "- Djavax.net.ssl.trustStore=%TRUST_CERT%" |
La sécurisation des connexions est un point sensible de l'environnement.
Il est possible de suivre les événements SSL de l'application en paramétrant le variable d'environnement suivante avant lancement du serveur Tomcat :
CATALINA_OPTS = "-Djavax.net.debug=ssl" |
Abréviations |
Définitions |
SMS |
Short Message Service |
API SMS-U |
Back office chargé de mutualiser la gestion de l'envoi de SMS au broker pour plusieurs universités. |
Broker de SMS |
Système tiers responsable de l'envoi des SMS vers les opérateurs respectifs des destinataires des SMS. OLM est un broker. |
OLM |
Orange on Line Multimédia |
Etablissement |
C'est une université. Elle a son propre portail. Elle a sa propre base d'utilisateurs. Elle peut mutualiser son annuaire avec d'autres établissements. |
SUPANN 2008 |
Version du schéma LDAP partagé par toutes les applications basées sur le modèle esup. |
uPortal |
Portail Web standardisé par le groupement ESUP. Il s'agit du front office du système |
Utilisateur |
Personne authentifiée dans le portail uPortal et qui accède à l'IHM de service d'envoi de SMS. |
IHM |
Interface Homme Machine |
UNPIdf |
Université Numérique Paris Ile-de-France |
API |
Application Programming Interface |
Framework esup-commons |
Framework de développement basé sur Spring, JSF et Hibernate proposé comme standard de développement d'applications dans le cadre du projet ESUP-Portail. |