1. Pour une installation en production nous vous recommandons : 4 Go de RAM, 2 CPU, et CentOS 7.
   
   
2. Un petit script permet d'entrer votre nom de machine et de remplacer toutes les occurrences de mon-poste.fr dans cette page.

$> hostname

Un éditeur de texte avec coloration syntaxique facilite le travail et limite les risques d'erreurs, notamment avec les fichiers de configuration XML utilisés par l'IdP. Parmi les éditeurs de ce type on peut citer Vim (préinstallé sur les serveurs).

Sur le poste de travail, il existe des extensions pour navigateur permettant de visualiser les échanges SAML entre IdP et SP, facilitant les tests. Parmi les extensions de ce type:

• SAML tracer pour Firefox
• SAML tracer pour Chrome

La brique logicielle Shibboleth IdP est une servlet JAVA et utilise un Java Servlet 3.0 Container (Tomcat comme dans cette documentation) comme serveur d'application. On peut donc l'utiliser sur d'autres plate-formes que Linux. Pour l'installer sur d'autres plate-formes, il faudra exécuter les instructions homologues à celles décrites dans ce TP.

Nous procédons à l'installation de Java Development Kit pour les briques IdP, Tomcat et optionnellement SSO-CAS. La documentation officielle du logiciel recommande l'installation d'un JDK (Java Development Kit), même si un JRE (Java Runtime Environment) peut suffire.

Dans les formations précédentes, nous avions choisi le package distribué par Oracle sous forme de paquetage RPM. Cependant la nouvelle license Oracle ne permet l'utilisation du JDK que pour faire des tests ou pour des usages personnels. C'est pourquoi nous allons utilisé OpenJDK qui facilite les mises à jour et qui est également compatible avec la version 3 de l'IdP Shibboleth,

Installation de OpenJDK :

$> sudo yum install java-1.8.0-openjdk

De nombreuses applications Java se réfèrent à la variable d'environnement JAVA_HOME pour identifier la machine virtuelle à utiliser. La manière la plus simple pour configurer globalement cette variable pour tous les utilisateurs du système est de créer un fichier dans le répertoire /etc/profile.d:

/etc/profile.d/java.sh

JAVA_HOME=/usr

Pour installer Apache HTTPD, exécutez la commande :

$> sudo yum install httpd

Documentation : IdP3 Installation, consortium Shibboleth

L'IdP Shibboleth est une application web compatible avec les spécifications Servlet 3.0. À ce titre, il peut être installé dans n'importe quel conteneur d'applications compatible. Mais seuls Jetty et Tomcat sont supportés par les développeurs. Tomcat est l'implémentation historiquement utilisée. Jetty est fortement recommandé pour exécuter l'IdP Shibboleth 3.x et est utilisé en production par les développeurs du logiciel.

• Apache Tomcat 8, consortium Shibboleth

Apache Tomcat est un serveur d'applications Java; c'est lui qui exécutera la brique Shibboleth IdP. Il est disponible sous forme de paquetage dans certaines distributions Linux, comme c'est le cas ici avec CentOS. Le choix entre le paquetage, et la version distribuée par les développeurs (dite version upstream) offre les avantages et inconvénients classiques d'une telle situation.

Le paquetage a l'avantage d'offrir une solution intégrée d'office, limite l'installation des parties inutiles voire dangereuses, et apporte une garantie en matière de correction des failles de sécurité cohérente avec le reste de la distribution, ce qui facilite le maintien en condition de sécurité. En contrepartie, il est souvent moins à jour que la version upstream, et souvent plus éloignée des documentations officielles.

La version upstream a l'avantage d'être plus à jour, et d'être plus proche des documentations officielles. En contrepartie, elle est moins intégrée, comporte souvent des parties inutiles voire dangereuses (des exemples, une interface d'administration graphique), avec une politique de suivi de sécurité spécifique, qui ne garantit pas forcément des changements à minima, ce qui impose un suivi entièrement manuel des failles de sécurité.

La suite du TP se base de façon arbitraire sur l'installation de la version upstream. Suivez les instructions suivantes pour télécharger et vérifier l'intégrité des fichiers:

$> cd
$> wget https://downloads.apache.org/tomcat/tomcat-8/v8.5.60/bin/apache-tomcat-8.5.60.tar.gz
$> wget https://downloads.apache.org/tomcat/tomcat-8/v8.5.60/bin/apache-tomcat-8.5.60.tar.gz.asc
$> wget https://www.apache.org/dist/tomcat/tomcat-8/KEYS
$> gpg --import KEYS
...
$> gpg --verify apache-tomcat-8.5.60.tar.gz.asc

gpg: Signature faite le lun. 07 oct. 2019 15:33:17 CEST avec la clef RSA d'identifiant 2F6059E7
gpg: Bonne signature de « Mark E D Thomas <markt@apache.org> »
gpg: Attention : cette clef n'est pas certifiée avec une signature de confiance.
gpg:             Rien n'indique que la signature appartient à son propriétaire.
Empreinte de clef principale : A9C5 DF4D 22E9 9998 D987  5A51 10C0 1C5A 2F60 59E7

Il faut d'abord décompresser l'archive dans le répertoire /opt:

$> sudo tar xvzf apache-tomcat-8.5.60.tar.gz -C /opt
apache-tomcat-8.5.60/conf/
apache-tomcat-8.5.60/conf/catalina.policy
apache-tomcat-8.5.60/conf/catalina.properties
[...]

Le répertoire ainsi créé étant lié à une version précise, nous allons créer un lien symbolique générique, en prévision de mises à jour futures :

$> sudo ln -s /opt/apache-tomcat-8.5.60 /opt/tomcat

L'IdP Shibboleth requiert l'installation de la librairie Java Tag Library (non fournie avec le serveur Tomcat) nécessaire pour visualiser les pages JSP (Status..) :

$> cd
$> wget https://build.shibboleth.net/nexus/service/local/repositories/thirdparty/content/javax/servlet/jstl/1.2/jstl-1.2.jar
$> sudo cp jstl-1.2.jar /opt/tomcat/lib

Comme évoqué plus haut parmi les inconvénients de l'utilisation de la version upstream, l'intégration avec la distribution est à notre charge.

D'abord, il va falloir créer un utilisateur dédié, nommé tomcat, afin d'exécuter le serveur avec un compte non privilégié:

$> sudo /usr/sbin/useradd tomcat

Ensuite, il faut donner à cet utilisateur des droits suffisant sur les fichiers de l'application:

$> sudo chown -R tomcat:tomcat /opt/apache-tomcat-8.5.60

Enfin, il va falloir intégrer les scripts de lancement de Tomcat au gestionnaire de service du système, à savoir systemd sur une distribution Linux moderne. Les fichiers nécessaires sont fournis dans le dépot git associé à cette formation, qu'il faut cloner localement:

$> cd
$> git clone https://git.renater.fr/anonscm/git/partage-fede/formation.git
$> sudo cp formation/idp/etc/tomcat.service /usr/lib/systemd/system/tomcat.service
$> sudo cp formation/idp/etc/tomcat.sysconfig /etc/sysconfig/tomcat
$> sudo systemctl daemon-reload

Vous pouvez maintenant démarrer le serveur Tomcat et vérifier ensuite sa bonne exécution :

$> sudo systemctl start tomcat
$> systemctl status tomcat
● tomcat.service - Apache Tomcat Web Application Container
   Loaded: loaded (/usr/lib/systemd/system/tomcat.service; disabled; vendor preset: disabled)
   Active: active (running) since lun. 2019-09-09 10:39:51 CEST; 2s ago
  Process: 25864 ExecStart=/opt/tomcat/bin/startup.sh (code=exited, status=0/SUCCESS)
 Main PID: 25874 (java)
    Tasks: 47
   Memory: 91.2M
   CGroup: /system.slice/tomcat.service
           └─25874 /usr/bin/java -Djava.util.logging.config.file=/opt/tomcat/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djdk.tls.ephemeralDHKeySize=2048 -Djava.protocol.handler.pkgs=org.ap...

sept. 09 10:39:51 formsfede-019 systemd[1]: Starting Apache Tomcat Web Application Container...
sept. 09 10:39:51 formsfede-019 startup.sh[25864]: Existing PID file found during start.
sept. 09 10:39:51 formsfede-019 startup.sh[25864]: Removing/clearing stale PID file.
sept. 09 10:39:51 formsfede-019 systemd[1]: Started Apache Tomcat Web Application Container.

Vérifiez que les logs de Tomcat logs/catalina.out sont correctement renseignés lorsque vous démarrez et arrêtez Tomcat.

$> sudo tail -f /opt/tomcat/logs/catalina.out
18-May-2019 15:24:04.366 INFO [main] org.apache.catalina.core.StandardService.startInternal Démarrage du service Catalina
[...]
18-May-2019 15:24:05.234 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in 906 ms

Vous pouvez maintenant accéder à votre serveur Tomcat avec un navigateur sur la page http://mon-poste.fr:8080/

Il est tout à fait possible d'installer uniquement un serveur Tomcat, sans serveur Apache ; dans ce cas le serveur Tomcat fournira les fonctionnalités SSL pour sécuriser le service. Nous allons opter pour l'utilisation d'un proxy Apache en frontal du serveur Tomcat. Cette architecture vous permet de disposer de l'ensemble des fonctionnalités d'un serveur Apache (modules d'authentification, réécriture, contrôle d'accès, etc.).

La transmission des requêtes entre Apache et Tomcat est assurée par le protocole AJP1.3. Apache fournit cette fonctionnalité via les module mod_proxy_ajp, qui dépend lui-même de mod_proxy.

Vérifiez que votre serveur Apache charge bien ce module proxy_ajp_module :

$> httpd -M | grep ajp
proxy_ajp_module (shared)

Nous devons ensuite activer le protocole AJP sur Tomcat - celui-ci étant désactivé par défaut.

Etant donné que nous souhaitons que toutes les requêtes passent par le serveur Apache, et qu'il ne soit pas possible de le contourner, nous allons restreindre Tomcat de façon à ce que celui-ci n'écoute que sur l'interface locale, en modifiant la configuration du connecteur AJP 1.3, dans le fichier /opt/tomcat/conf/server.xml :

/opt/tomcat/conf/server.xml

<!-- A "Connector" represents an endpoint by which requests are received
     and responses are returned. Documentation at :
     Java HTTP Connector: /docs/config/http.html
     Java AJP  Connector: /docs/config/ajp.html
     APR (HTTP/AJP) Connector: /docs/apr.html
     Define a non-SSL/TLS HTTP/1.1 Connector on port 8080
-->
**<!--**
<Connector port="8080" protocol="HTTP/1.1"
        connectionTimeout="20000"
        redirectPort="8443" />
**-->**
[...]
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector protocol="AJP/1.3"
           address="127.0.0.1"
           port="8009"
           redirectPort="8443"
           **secret="federation"** />

Redémarrez le serveur Tomcat :

$> sudo systemctl restart tomcat

Il faut ensuite définir pour Apache le point d'ancrage de l'application proxyfiée, c'est-à-dire lui indiquer quelles requêtes il doit transmettre, et quelles requête il doit traiter lui-même. Nous utilisons ici l'URL conventionnelle /idp, et un fichier de configuration dédié /etc/httpd/conf.d/shibboleth.conf :

/etc/httpd/conf.d/shibboleth.conf

## configuration d'Apache pour l'IdP Shibboleth
ProxyPass /idp ajp://127.0.0.1:8009/idp secret=federation

Pour tester immédiatement l'interfaçage entre Apache et Tomcat, sans attendre l'installation de l'IdP, nous allons également proxyfier une application d'exemple fournie avec Tomcat:

/etc/httpd/conf.d/shibboleth.conf

ProxyPass /examples ajp://127.0.0.1:8009/examples secret=federation

Redémarrez le serveur Apache :

$> sudo systemctl restart httpd

Vous pouvez maintenant tester l'accès au serveur Tomcat via Apache, en accédant aux exemples JSP fournis avec Tomcat : http://mon-poste.fr/examples/ (attention au '/' à la fin de l'URL).

En cas de problème :

• vérifiez que Apache et Tomcat s'exécutent

$> systemctl status tomcat
$> systemctl status httpd

• consultez les logs dans deux fenêtres terminal différentes

$> sudo tail -f /var/log/httpd/error_log
$> sudo tail -f /opt/tomcat/logs/catalina.out

Un certificat X.509 doit être installé sur le serveur hébergeant le service IdP. Ce certificat répond au besoin de sécurisation des échanges de l'utilisateur avec le serveur web et permet une authentification du serveur.

Sur un serveur en production vous pouvez utiliser un certificat TCS (reconnu nativement dans les navigateurs). Durant le TP nous utiliserons un certificat de test préparé pour les besoins de cette formation.

$> openssl req -new -newkey 2048 -nodes -keyout key.pem -out csr.pem
$> openssl x509 -req -sha256 -days 3650 -in csr.pem -signkey key.pem -out cert.pem

Si vous suivez la formation en présentiel, téléchargez le certificat, la clef privée associée et la chaîne de certification :

$> cd
$> wget https://formsfede-014.renater.fr/certificates/mon-poste.fr_privatekey.pem
$> sudo cp mon-poste.fr_privatekey.pem /etc/pki/tls/private/mon-poste.fr.key
$> sudo chmod 600 /etc/pki/tls/private/mon-poste.fr.key
$> wget https://formsfede-014.renater.fr/certificates/mon-poste.fr.crt
$> sudo cp mon-poste.fr.crt /etc/pki/tls/certs/mon-poste.fr.crt
$> sudo chmod 644 /etc/pki/tls/certs/mon-poste.fr.crt

Vérifiez que le module mod_ssl pour Apache est installé :

$> rpm -q mod_ssl

Si le module n'est pas installé, faites :

$> sudo yum install mod_ssl

Configurez Apache pour utiliser ce certificat. Remplacez les directives SSLCertificateXxx existantes dans /etc/httpd/conf.d/ssl.conf par celles indiquées ci-dessous :

...
  **SSLCertificateFile /etc/pki/tls/certs/mon-poste.fr.crt**
...
  **SSLCertificateKeyFile /etc/pki/tls/private/mon-poste.fr.key**

Redémarrer Apache :

$> sudo systemctl restart httpd

Shibboleth utilisant des assertions à courte durée de vie, des divergences d'horloge entre les serveurs IdP et SP ne sont pas tolérables. Les serveurs doivent donc avoir une configuration permettant une synchronisation horaire.

Il existe plusieurs façons d'assurer cette synchronisation, nous utilisons ici un serveur NTP, dont il faut vérifier le fonctionnement:

$> systemctl status ntpd
Unit ntpd.service could not be found.
$> sudo yum install ntp
$> sudo systemctl enable ntpd
$> sudo systemctl start ntpd
$> date
jeu. mai 02 06:12:26 UTC 2019