Utiliser un frontal HTTP Apache

Les services ORI-OAI nécessitent un serveur d'application JAVA pour fonctionner. Tomcat est proposé comme solution par défaut.
Utiliser un serveur http Apache en frontal de ce ou ces serveurs Tomcat apporte de nombreux avantages :

  • Sécurité avec Le serveur http Apache installé en DMZ et seul autorisé à dialoguer sur un port réseau particulier avec un serveur Tomcat situé dans un VLAN non accessible depuis internet
  • Tolérance aux pannes et répartition de charge en utilisant un module Apache spécifique de répartition logicielle (mod_proxy_balancer)
  • Contrôle d'accès à certaines URL sensibles afin d'en protéger l'accès
  • Etc.

Configuration

Voici un exemple type de configuration d'un site virtuel Apache 2.2 en frontal d'un module ORI-OAI :

<VirtualHost 100.100.200.1:80>
  ServerName ori-oai-indexing.univ.fr
  VirtualDocumentRoot /data/webapps/ori-oai-indexing.univ.fr
  ProxyPass / ajp://ori-oaisrv.univ.fr:9526/ min=0 max=100 smax=50 ttl=10 route=ori-indexing
  # On protege tout ici
  <Location "/">
    order deny,allow
    deny from all
    # Autorise vlan serveurs
    allow from 100.100.300
  </Location>
</VirtualHost>

Ici le serveur répond à l'adresse ori-oai-indexing.univ.fr sur le port 80 et dialogue avec le serveur Tomcat grâce au protocole AJP sur le port 9526 de la machine ori-oaisrv.univ.fr

Ici le serveur apache n'établit aucune connexion avec le serveur Tomcat par défaut mais seulement au fur et à mesure des demandes des utilisateurs (jusqu'à 50). Si la charge augmente avec plus de 50 utilisations simultanées, alors le serveur peut créer jusqu'à 100 connexions pour revenir ensuite au seuil de 50 connexions.

Le paramètre route permet de reconnaître des cookies marqués par le serveur Tomcat afin de pouvoir orienter la requête suivante de l'utilisateur vers le même serveur Tomcat. Ce paramètre n'est pas indispensable ici car l'on n'utilise pas de mécanisme de répartition de charge où il faudrait garantir qu'un utilisateur soit toujours dirigé vers le même serveur d'applications.

Protection des URL sensibles

Dans l'exemple de configuration ci-dessous l'ensemble du site est protégé grâce aux directives order, deny et allow qui s'applique sur le chemin "/". Cette configuration permet de ne rendre accessible le module d'indexation que depuis une plage d'adresses IP où se retrouvent les différents serveurs. Le module n'est pas accessible depuis Internet. En effet, ce module n'a pas vocation à offrir un service direct aux utilisateurs mais est seulement utilisé par les autres modules ORI-OAI.

Il est particulièrement important de protéger certaines adresses afin d'éviter :

  • Les dénis de service
  • L'appel incontrôlé par des utilisateurs malveillants aux différents Web Services des modules ORI-OAI.

Quelles URL faut-il protéger ?

Voici la liste des URL à protéger dans le cadre de la mise en œuvre des modules ORI-OAI :

  • # ori-oai-workflow à /md-editor/ori-md-editor/vocab
  • # ori-oai-vocabulary à "/"
  • # ori-oai-indexing à "/"
  • # ori-oai-harvester à "/harvester/admin"
  • No labels