Outils pour utilisateurs

Outils du site

Vous êtes ici : Portail des services RENATER » La Fédération Éducation-Recherche (FER) » Documentation » Tutoriels Shibboleth » Installation d'un SP Shibboleth et Shibbolisation d'application » Cas d'usages avancés d'un SP

Panneau latéral

Sommaire

Table des matières

← Chapitre 7 
 Chapitre 9 →

Cas d'usages avancés d'un SP

Afin d'adapter le contenu de cette page avec le nom de votre serveur, saisissez-le ici :

Nom de votre machine :

1. Mutualisation d'un SP entre applications

1.1 Lien entre application et entité SAML

Le terme d'application correspond généralement à une instance spécifique d'un logiciel particulier. Par exemple, le site web institutionnel d'un organisme correspond généralement à une instance d'un CMS. Parfois, plusieurs logiciels sont regroupés entre eux pour fournir un ensemble cohérent. Par exemple, une instance Universalistes correspond à l'assemblage d'un gestionnaire de liste de diffusion (Sympa), d'un gestionnaire de sondage (Limesurvey), et d'un Wiki (dokuwiki). C'est souvent le terme de service qui est utilisé pour qualifier un tel assemblage. Mais aucun des deux termes n'a de définition formelles.

Dans un univers SAML, un fournisseur d'identité ne parle pas à des applications, ou à des services, mais à des entités SAML, et à chacune de ces entités est associée un ensemble de paramètres techniques précis, comme par exemple une liste d'attributs souhaités, un certificat de signature, des contacts, et surtout un identifiant unique (entityID). Ce sont ces entités qui sont déclarées sur le guichet de la fédération, en leur associant de surcroit des informations organisationnelles, comme par exemple leur établissement de rattachement.

Une question récurrente porte sur la relation entre ces concepts, et le nombre d'entités qu'il faut déclarer par rapport aux applications ou services mis en oeuvre. Il ne s'agit pas d'une question technique, mais organisationnelle : s'il est techniquement tout à fait possible de regrouper des applications distinctes au sein d'une même entité, celle-ci n'aura qu'une seule liste d'attributs souhaités, qu'une seule description, qu'une seule liste de contacts, etc… Il ne sera pas possible d'inscrire ces applications dans des fédérations différentes, de les faire évoluer séparemment, ou de mettre en place des politiques d'authentification différentes, puisqu'elles constituent une entité unique.

Mutualiser des déclarations sur le guichet de la fédération entre applications indépendantes est donc une mauvaise idée : à chaque entité SAML doit correspondre une application unique, ou un groupes d'applications formant un ensemble cohérent. En revanche, il est tout à fait envisageable de mutualiser les instances de SP Shibboleth utilisées pour faire fonctionner ces applications.

1.2 Différenciation du comportement

Si ces applications correspondent à une entité SAML unique, la question de la mutualisation ne se pose pas, puisqu'il y a un seul déploiement du SP Shibboleth, et une configuration unique de shibd, avec des paramètres SAML partagés entre ces applications.

Si en revanche ces applications correspondent à des entités SAML différentes, il faut pouvoir distinguer entre elles, de façon à configurer des comportements différents du SP en fonction du cas. Il y a deux stratégies différentes, en fonction du degré de différence :

  • via des préférences de contenu, pour des différences ponctuelles
  • via des contextes applications, pour des différences plus marquées

Les deux stratégies sont détaillées plus précisément ci-dessous.

1.2.1 Différenciation via des préférences de contenu

Le terme de préférence de contenu correspond à celui de Content Settings dans la documentation officielle. Si deux entités SAML ne se distinguent que par un élément de ce type, il est inutile de complexifier la configuration de shibd, ceci peut se faire depuis le serveur web.

Ceci se fait via des directives ShibRequestSetting, dans la configuration Apache, qui permettent de définir par exemple :

  • l'identifiant de l'entité (entityID)
  • l'URL du WAYF à utiliser
  • etc…

L'exemple suivant correspond ainsi à deux applications différentes, correspondant à deux entités SAML différentes, avec un identifiant et un WAYF différent :

/etc/httpd/conf.d/shib.conf
<Location /app1>
    AuthType shibboleth
    Require shib-session
    ShibRequestSetting entityIDSelf https://hostname/app1
    ShibRequestSetting discoveryURL https://wayf1
</Location>

<Location /app2>
    AuthType shibboleth
    Require shib-session
    ShibRequestSetting entityIDSelf https://hostname/app2
    ShibRequestSetting discoveryURL https://wayf2
</Location>

1.2.2 Différenciation via des contextes applicatifs

Si les différences entre ces entités sont plus importantes, et ne peuvent pas être spécifiées par des préférences de contenu, il faut mettre en place des contextes applicatifs distincts dans la configuration du serveur shibd.

Ceci se fait via des éléments ApplicationOverride, dans le fichier /etc/shibboleth/shibboleth2.xml, qui permettent de surcharger tout ou partie des éléments définis au niveau de l'élément de base ApplicationDefaults, par exemple :

  • des métadonnées différentes
  • des réglages de session différents
  • etc..

L'exemple suivant montre deux contextes applicatifs, correspondant aux deux entités précédentes qui cette fois-ci diffèrent également par les métadonnées utilisées :

/etc/shibboleth/shibboleth2.xml
<ApplicationDefaults entityID="whatever" ...>
 
  <ApplicationOverride id="app1" entityID="https://hostname/app1">
    <Sessions ...>
      <SSO discoveryProtocol="SAMLDS" discoveryURL="https://wayf1">SAML2</SSO>
    </Sessions>
    <MetadataProvider type="XML" url="https://federation1/metadata.xml"/>
  </ApplicationOverride>
 
  <ApplicationOverride id="app2" entityID="https://hostname/app2">
    <Sessions ...>
      <SSO discoveryProtocol="SAMLDS" discoveryURL="https://wayf2">SAML2</SSO>
    </Sessions>
    <MetadataProvider type="XML" url="https://federation2/metadata.xml"/>
  </ApplicationOverride>
</ApplicationDefaults>

Il faut ensuite spécifier le contexte applicatif à utiliser dans la configuration Apache, via une directive ShibRequestSetting applicationId :

/etc/httpd/conf.d/shib.conf
<Location /app1>
    AuthType shibboleth
    Require shib-session
    ShibRequestSetting applicationId app1
</Location>

<Location /app2>
    AuthType shibboleth
    Require shib-session
    ShibRequestSetting applicationId app2
</Location>

La documentation officielle présente :

2. Externalisation du SP

La discussion jusqu'ici concernait des applications locales, c'est-à-dire installées sur la même machine que le SP, mais ceci n'a rien d'obligatoire. En configurant Apache comme mandataire HTTP inverse (reverse-proxy), il devient possible de répartir les deux fonctions sur deux machines distinctes. La machine hébergeant le SP devient alors un reverse-proxy authentifiant pour l'application qu'elle protège.

Néanmoins, cette architecture complique la sécurité à mettre en place. En effet, les attributs ne sont plus transmis à l'application sous forme de variables d'environnement locales à la machine, mais sous forme d'entêtes HTTP, qui sont sous contrôle de l'utilisateur. Il faut donc s'assurer dans ce cas :

De plus, la façon dont les attributs sont perçus par l'application change, en fonction du langage utilisé, ce qui nécessite parfois une adaptation de celle-ci.

Au vu de ces contraintes, l'intérêt de l'externalisation du SP est à relativiser. Deux cas d'usages classiques peuvent néanmoins le justifier :

  • la séparation des fonctions, avec des personnes différentes en charge de l'applicatif d'un coté, du proxy de l'autre
  • la mutualisation d'un SP entre plusieurs applications distinctes

2.1 Shibbolisation d'une application distante

Pour cette partie du TP, vous allez devoir sécuriser grâce à Shibboleth SP une application interne à votre SI.
Il s'agit d'une application qui affiche les attributs renvoyés par Shibboleth (SP de Test), que vous avez déjà utilisée comme SP bilatéral dans le TP IDP. Cette fois-ci, ce sera à vous de la sécuriser avec votre démon Shibboleth SP.
Vous n'avez pas accès à la configuration de cette application, mais elle sait détecter qu'une session Shibboleth a été créée. L'objectif est que cette application ne puisse être accédée que par des utilisateurs valides.

2.1.1 Vérification de l'accès à l'application

L'application est déjà installée et joignable sur l'URL http://formsfede-014.renater.fr/appli-ABC
Comme nous allons devoir la protéger par un proxy, son adresse, du point de vue de l'utilisateur sera https://monposte.fr/appli

2.1.2 Configuration du SP Proxy Shibboleth

Les fichiers suivants sont à modifier :

  • /etc/httpd/conf.d/appli.conf : nouveau fichier de configuration Apache

2.1.3 Configuration de Apache en proxy sans contrôle d'accès

Créer le fichier /etc/httpd/conf.d/appli.conf :

/etc/httpd/conf.d/appli.conf
<Location /appli>
  ProxyPass  http://formsfede-014.renater.fr/appli-ABC
  ProxyPassReverse  http://formsfede-014.renater.fr/appli-ABC
</Location>


Relancer Apache et tester l'accès via l'URL : https://monposte.fr/appli. 

$> sudo systemctl restart httpd

2.1.4 Configuration du contrôle d'accès

Modifier le fichier /etc/httpd/conf.d/appli.conf :

/etc/httpd/conf.d/appli.conf
<Location /appli>
  ProxyPass  http://formsfede-014.renater.fr/appli-ABC
  ProxyPassReverse  http://formsfede-014.renater.fr/appli-ABC
  **AuthType shibboleth**
  **ShibRequestSetting applicationId default**
  **ShibRequestSetting requireSession 1**
  **ShibUseHeaders On** # Permet l'envoi des variable Shib dans les Headers HTTP
  **require shib-session**
</Location>


Relancer Apache et tester l'accès via l'URL : https://monposte.fr/appli. 

$> sudo systemctl restart httpd
Dans le cas où le SP Shibboleth est installé sur un serveur en proxy, une erreur Apache de ce type peut apparaître The number of request header fields exceeds this server's limit. Pour corriger ce problème il existe deux options, soit :

adapter la configuration de SP sur le proxy : Éditer le fichier attribute-map.xml du SP et supprimez toutes les définitions d'attributs (<Attribute>) qui ne seront pas utilisés par les applications protégées par le proxy.

adapter la configuration du serveur Apache sur les hôtes proxifiés : Ajoutez une directive Apache “LimitRequestFields 150” (avec un nombre > 100) pour que le serveur Apache accepte des requêtes avec un grand nombre d'en-têtes HTTP.

Dans le cadre du TP, la limite côté serveur Web de l'application proxifiée a été relevée.

← Chapitre 7 
Accueil 
 Chapitre 9 →