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

Nom de votre machine :

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.

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.

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>

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 :

• les différentes paramètres définissables du niveau du contexte par défaut: https://wiki.shibboleth.net/confluence/display/SP3/ApplicationDefaults
• les possibilités de surchage, et les cas pour lesquels cette stratégie n'est pas nécessaire: https://wiki.shibboleth.net/confluence/display/SP3/ApplicationOverride#ApplicationOverride-ValidandInvalidReasonsforOverrides

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.

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

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.

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

Les fichiers suivants sont à modifier :

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

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

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