Configurer un SP Shibboleth pour rendre accessible des attributs de méta-données à une application

Depuis la version 2.5 du Shibboleth Service Provider il est possible de rendre accessible à une application fédérée des attributs de meta-données. Cette nouvelle fonction est documentée dans le wiki Shibboleth sur la page décrivant l'AttributeExtractor.

Configuration pour Shibboleth SP 2.5 ou plus récent

Le fichier de meta données de la fédération contient du code XML pour chaque Identity Provider (IdP) comme cet exemple :

<EntityDescriptor entityID="https://idp.exemple.fr/idp/shibboleth">
  <IDPSSODescriptor protocolSupportEnumeration="...">
      [... SAML2 Metadata ...]
  </IDPSSODescriptor>
  <Organization>
      <OrganizationName xml:lang="en">Université XY</OrganizationName>
      <OrganizationDisplayName xml:lang="en">Université XY</OrganizationDisplayName>
      <OrganizationURL xml:lang="en">http://www.exemple.fr</OrganizationURL>
  </Organization>
  <ContactPerson contactType="technical">
    <SurName>Système Information</SurName>
    <EmailAddress>systeme-information@exemple.fr</EmailAddress>
  </ContactPerson>
</EntityDescriptor>

Quelquefois il serait utile pour un Service Provider (SP) d'avoir ces informations dans un attribut pour le montrer aux utilisateurs. Par exemple dans le cas d'une erreur, le SP pourrait donner l'adresse émail du contact technique et le nom de son organisation aux utilisateurs.

Pour réaliser cela, il faut adapter la configuration du Shibboleth SP:

  1. Ouvrez avec en éditeur de texte le fichier shibboleth2.xml qui se trouve normalement dans le répertoire /etc/shibboleth (Linux/Unix/MacOS X) ou C:/opt/shibboleth-sp/etc/shibboleth (Windows)
  2. Dans l'élément <ApplicationDefaults> et chaque élément <ApplicationOverride> ajoutez un attribut XML “metadataAttributePrefix”. Après la modification l'élément sera:
    <ApplicationDefaults metadataAttributePrefix="Shib-Metadata-" [...] >

    Ce préfixe est utilisé pour construire le nom d'attribut dans l'environment de serveur web. Naturellement il est aussi possible de choisir un autre nom pour le préfixe.

  3. Cherchez tous les éléments du type:
    <AttributeExtractor type="XML" [...] path="attribute-map.xml"/>

    Normalement il y en a seulement un. Adaptez cet élément comme dans cet exemple :

    <AttributeExtractor type="Chaining">
      <AttributeExtractor type="XML" [...] path="attribute-map.xml"/>
      <AttributeExtractor type="Metadata"
        OrganizationName="OrganizationName"
        OrganizationDisplayName="OrganizationDisplayName"
        OrganizationURL="OrganizationURL">
          <ContactPerson 
            id="TechnicalContact" 
            contactType="technical" 
            formatter="&lt;a href='$EmailAddress'&gt;$GivenName $SurName&lt;/a&gt;" />
      </AttributeExtractor>  
    </AttributeExtractor>
  4. Enregistrez le fichier shibboleth2.xml
  5. Exécutez (en tant que root/administrateur) la commande suivante pour s'assurer que la configuration est encore valide:
    shibd -t

    ou pour Windows:

    C:\opt\shibboleth-sp\sbin\shibd.exe -check
  6. Finalement, redémarrer le Service Provider SP. Par exemple sur Linux avec la commande:
    /etc/init.d/shibd restart

Après avoir adapté la configuration comme décrit plus haut, une application web peut lire et utiliser les attributs suivants dans l'environnement du serveur web:

  • Shib-Metadata-OrganizationName
  • Shib-Metadata-OrganizationDisplayName
  • Shib-Metadata-TechnicalContact
  • Shib-Metadata-OrganizationURL

Après l'authentification, on peut accéder le Shibboleth Session Handler (/Shibboleth.sso/Session) pour examiner les nouveaux attributs:

Si un IdP a plusieurs contacts techniques, l'attribut va contenir plusieurs valeurs séparées par un ';'. Donc l'application devra découper ces valeurs avant affichage.

Dans le cas où le SP Shibboleth est installé sur un serveur en proxy, une erreur Apache de ce type apparait 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.

Avec la même adaptation de la configuration, il est aussi possible d'utiliser d'autres informations extraites des metadonnées décrivant un IdP. Vous trouverez plus de détails sur la page wiki de Shibboleth AttributeExtractor.