Outils pour utilisateurs

Outils du site

Vous êtes ici : Portail des services RENATER » La Fédération Éducation-Recherche (FER) » Documentation » Thématiques générales fédération » Utiliser un reverse-proxy SAML en frontal d'un serveur hébergeant une application

Panneau latéral

Fédération

Table des matières

Utiliser un reverse-proxy SAML en frontal d'un serveur hébergeant une application

1. Avantages et inconvénients

Mettre en place un reverse-proxy SAML permet de centraliser la gestion d'un SP Shibboleth (ou toute autre implémentation SAML, en fait) en un point unique du SI, au lieu d'avoir à déployer et maintenir cette brique sur chaque application. Néanmoins, cette architecture amène également deux problèmes:

  • un problème de fiabilité, d'une part: si le proxy devient indisponible, toutes les applications situées derrière deviennent également injoignables. Il est donc fortement recommandé de prévoir plusieurs reverse-proxys configurés en haute-disponibilité. La description d'une telle architecture sort du cadre de cet article, mais de nombreuses ressources sont disponibles à ce sujet sur le web.
  • un problème de sécurité, d'autre part: les informations d'authentification étant transmises sous forme d'entête HTTP entre le reverse-proxy et l'application, il est indispensable d'empêcher tout accès direct à l'application, en court-circuitant le reverse-proxy, sous peine de rendre trivial l'usurpation d'identité

L'intérêt de cette centralisation est donc à mettre en balance avec ces inconvénients. Si c'est juste pour éviter d'avoir a déployer plusieurs fois le même logiciel, mieux vaut investir dans une solution de gestion de parc, par exemple.

2. Principe de fonctionnement

Le cheminement suivi lors de l'accès à l'application placée derrière un reverse-proxy SAML est le suivant :

  1. l'utilisateur saisit dans son navigateur l'URL d'accès à l'application, via le reverse-proxy (par exemple https://rp.example.com/) ;
  2. sa requête est interceptée par le SP Shibboleth sur le reverse-proxy et le processus Shibboleth classique s'enclenche : redirection vers un IdP en cas d'authentification obligatoire, aucune action en cas d'authentification facultative (lazy session)
  3. le proxy transfère alors la requête vers le serveur hébergeant l'application, avec éventuellement les en-têtes HTTP positionnés par le SP Shibboleth s'il y a eu authentification
  4. l'application reçoit la requête et peut consulter un ou plusieurs en-têtes pour autoriser ou non l'accès à l'utilisateur.

3. Démarche de mise en oeuvre

Nous proposons ici une démarche à suivre pour mettre en place un telle architecture. Nous considérons un proxy en frontal d'un seul serveur hébergeant une seule application, mais le principe reste le même s'il y a plusieurs serveurs et/ou plusieurs applications derrière le proxy.
Dans cet exemple, l'URL du service vu par les utilisateurs sera https://application.example.com/. Bien entendu, pour que le traffic passe pas le proxy, il faudra que le domaine application.example.com pointe sur l'IP du proxy.
L'addresse interne de l'application est https://application.interne.fr/.
On utilise le serveur Apache et son module mod_proxy.

L'authentification étant déléguée au proxy, l'application finale ne contrôle l'accès que sur la présence de certains headers HTTP.
Il est donc indispensable de protéger les accès réseau à l'application, sinon un utilisateur malveillant pourrait injecter lui-même des headers et s'octroyer un accès non autorisé à l'application.
Une des méthodes dans ce cas est de n'autoriser le traffic http/https vers l'application finale, uniquement depuis le proxy.

3.1 Configurer ou adapter l'application pour qu'elle accepte la connexion d'un utilisateur sur la base d'un champ en-tête HTTP

L'application recevra l'identifiant de l'utilisateur et ses éventuels attributs via des champs d'en-tête HTTP. Il est possible que l'application soit déjà capable de fonctionner avec en aval des modules d'authentification tels que mod_auth_basic ou mod_ssl ; dans ce cas il sera aisé d'adapter ce comportement pour Shibboleth.

Le mod_proxy d'Apache ne permet pas le transfert du champ d'en-tête HTTP REMOTE_USER. Il faut donc utiliser un autre en-tête.

3.2 Installer et configurer un fournisseur de services Shibboleth sur le reverse proxy

Suivez la documentation d'installation d'un fournisseur de service Shibboleth. Validez l'installation et la configuration dans la fédération de test avec un script affichant les attributs.

Afin que le SP Shibboleth transfère les informations sous forme d'en-têtes HTTP vers l'application, il est nécessaire de positionner la directive suivante dans la configuration Apache : 
  ShibUseHeaders On

<note

3.3 Configurer le reverse proxy

Avec Apache il suffit d'utiliser les directives du module mod_proxy :

application.conf
  <VirtualHost *:443>
  ...
    ServerName application.example.com
  ...
 
    # les requêtes SAML sont gérées par mod_shib directement
    <Location /Shibboleth.sso>
        SetHandler shib
    </Location>
 
    # les requêtes concernant des ressources physiques (logos, messages d'erreur, ...) du SP doivent
    # être servies depuis le système de fichier local
    Alias /Shibboleth /usr/share/shibboleth/www
    <Location /Shibboleth>
        Require all granted
        ProxyPass !
    </Location>
 
    # Tout le reste doit être transféré à l'application
    <Location />
        ShibRequestSetting requireSession On # Ou "Off" si Lazy
        Require shib-session # Ou "shibboleth" si Lazy
        ShibUseHeaders On
        ProxyPasss       http://application.interne.fr/
        ProxyPassReverse http://application.interne.fr/
    </Location>
  ...
  </VirtualHost>