Automatiser la diffusion d'attributs avec un IdP Shibboleth

Le mécanisme des attribute filters de l'IdP Shibboleth permet de configurer, pour chaque ressource (SP), l'ensemble des attributs utilisateur qui lui seront transmis à l'issue de la phase d'authentification de l'utilisateur.

Ce mécanisme est essentiel car il permet de paramétrer au plus juste l'exportation des données sur les utilisateurs. On peut ainsi ne fournir aucun attribut à une ressource, des attributs non nominatifs à une autre et un ensemble d'attributs plus riche à une troisième ressource.

La configuration de ces règles de filtrage est réalisée dans le fichier de configuration attribute-filter.xml.

Problématique de la maintenance du fichier attribute-filter.xml

Le problème de contrôle de la diffusion d'attributs utilisateurs se pose aux administrateurs d'IdP. Ils peuvent gérer manuellement leur fichier attribute-filter.xml, mais compte-tenu du nombre de SP disponibles, ce type de gestion n'est pas réaliste. D'un autre côté les obligations vis à vis de la CNIL impose une diffusion proportionnée des données à caractère personnel (lire nos bonnes pratiques pour le traitement des données à caractère personnel dans la Fédération Éducation-Recherche ).

Précédemment RENATER a mis à disposition des administrateurs d'IdP plusieurs fichiers attribute-filter.xml générés automatiquement en fonction des types de SP et de leur public cible, voir cette documentation.

A partir de sa version 2.4.0 (Avril 2013), l'IdP Shibboleth permet de définir des règles génériques de diffusion d'attributs, en fonction des attributs utilisateurs demandés par un fournisseur de service et également en fonction de l'appartenance de ce fournisseur de services à des entity categories (voir le lien en début de page).

Automatiser la diffusion d'attributs utilisateurs

Depuis juillet 2015 RENATER a étendu le format du fichier de méta-données SAML de sa fédération pour y intégrer les informations concernant les attributs attendus par chaque fournisseur de services. Ces informations sont directement issues du guichet de la fédération où l'administrateur d'un fournisseur de services renseigne la liste des attributs utilisateurs dont son service a besoin pour fonctionner.

Ci-dessous un exemple de données saisies sur le guichet de la fédération :

Ci-dessous un extrait des méta-données de la fédération, incluant la description XML des attributs utilisateur attendus par ce même fournisseur de services :

<AttributeConsumingService index="0">
   <ServiceName xml:lang="fr">CFAU - Cahier de Liaison Electronique</ServiceName>
   <ServiceDescription xml:lang="fr">L'application CLE est géré par le CFA Universitaire Alsace
C'est le Cahier de Liaison Électronique des apprentis, utilisé par les gestionnaires du CFAU, les apprentis des différentes 
universités, les enseignants en charge du suivi et les tuteurs en entreprise. Les utilisateurs cibles via la fédération sont les apprentis universitaires de l’Université de Strasbourg, et l’Université de Haute Alsace, ainsi que les enseignants en charge du suivi</ServiceDescription>
   <RequestedAttribute
      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      isRequired="true"
      Name="urn:oid:0.9.2342.19200300.100.1.3"
      FriendlyName="mail">
   </RequestedAttribute>
 
   <RequestedAttribute
      NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
      Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6"
      FriendlyName="eduPersonPrincipalName">
   </RequestedAttribute>
 </AttributeConsumingService>

Ces informations publiées dans les méta-données SAML sont exploitables pour configurer la diffusion automatique de certains attributs par votre IdP Shibboleth, en fonction des attributs demandés par les fournisseurs de services.

Configurer un IdP pour utiliser les attribute-filters.xml de la Fédération

La version 2.4.0 de l'IdP Shibboleth introduit une nouvelle règle PermitValueRule de type AttributeInMetadata utilisable dans votre fichier de configuration attribute-filter.xml. Cette fonctionnalité vous permet, pour un ensemble de SPs, d'autoriser la diffusion au plus juste des attributs utilisateur, uniquement s'ils sont déclarés comme demandés par le SP dans les méta-données de la fédération. L'option onlyIfRequired permet par ailleurs de ne diffuser l'attribut que s'il est indiqué comme obligatoire.

Exemple 1 : diffusion du pool standard d'attributs utilisateur, à l'exclusion des attributs optionnels :

IDP_ROOT_DIR/conf/attribute-filter.xml
<!-- On fournit les attributs requis, contexte Fédération de Test -->
  <afp:AttributeFilterPolicy id="releaseToAllRenaterSps">
 
    <afp:PolicyRequirementRule xsi:type="saml:AttributeRequesterInEntityGroup" groupID="https://federation.renater.fr/test/" />
 
    <afp:AttributeRule attributeID="email">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="eduPersonPrincipalName">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="displayName">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="givenName">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="surName">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="commonName">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="eduPersonAffiliation">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="eduPersonPrimaryAffiliation">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="eduPersonScopedAffiliation">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="eduPersonTargetedID">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="supannEtablissement">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="uid">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="eduPersonEntitlement">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" onlyIfRequired="true"/>
    </afp:AttributeRule>
 
 
  </afp:AttributeFilterPolicy>

Exemple 1 : diffusion de certains attributs utilisateur, uniquement aux applications nationales :

IDP_ROOT_DIR/conf/attribute-filter.xml
  <afp:AttributeFilterPolicy id="releaseToNationalSp">
 
    <afp:PolicyRequirementRule xsi:type="basic:AND">  
    <basic:Rule  xsi:type="saml:AttributeRequesterInEntityGroup" 
    groupID="https://federation.renater.fr/" />
    <basic:Rule  xsi:type="saml:AttributeRequesterEntityAttributeExactMatch"
        attributeName="http://macedir.org/entity-category"
        attributeValue="https://federation.renater.fr/scope/national"/>
    </afp:PolicyRequirementRule>
 
 
    <afp:AttributeRule attributeID="eduPersonPrincipalName">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" 
     onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="displayName">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" 
     onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="commonName">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" 
     onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="email">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" 
     onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="eduPersonAffiliation">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" 
     onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="eduPersonScopedAffiliation">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" 
     onlyIfRequired="true"/>
    </afp:AttributeRule>
 
    <afp:AttributeRule attributeID="eduPersonTargetedID">
     <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" 
     onlyIfRequired="true"/>
    </afp:AttributeRule>
 
 
  </afp:AttributeFilterPolicy>
 

Adapter à un contexte de production : pour un usage en production, vous devrez ajouter une AttributeFilterPolicy de ce type pour les méta-données SAML main-sps-renater-metadata.xml qui ont un identifiant différent (https://federation.renater.fr/ au lieu de https://federation.renater.fr/test/). Nous vous fournissons un exemple de configuration de ce type, plus loin dans la documentation.

Dans le but de garantir le bon fonctionnement des services nationaux, le cadre technique de la Fédération Education-Recherche impose que tous les fournisseur d'identités mettent en oeuvre ce type de filtrage automatique.

Limiter la diffusion des attributs

Vous avez la possibilité de restreindre la diffusion d'attributs utilisateur à un sous-ensemble des SPs membres de la fédération.

Les SPs enregistrés dans la Fédération Éducation-Recherche sont catégorisés en fonction de deux critères : le type de service proposé (enseignement à distance, outils collaboratifs, documentation électronique, accès Wi-Fi, etc.) et le public cible (service national institutionnel, communautés nationales, ressources locales, service commercial). Ces informations sont publiées dans les méta-données SAML sous forme d'Entity Categories. L'IdP Shibboleth vous permet de définir un filtre d'attribut afin de restreindre la diffusion de certains attributs à une catégorie de SPs.

Exemple 2 : diffusion du numéro de téléphone utilisateur uniquement aux applications nationales :

IDP_ROOT_DIR/conf/attribute-filter.xml
    <afp:AttributeFilterPolicy id="releaseTelephoneToNationalSps">
     <afp:PolicyRequirementRule xsi:type="basic:AND">
      <basic:Rule xsi:type="saml:AttributeRequesterInEntityGroup" 
      groupID="https://federation.renater.fr/test/" />
      <basic:Rule xsi:type="saml:AttributeRequesterEntityAttributeExactMatch"
       attributeName="http://macedir.org/entity-category"
       attributeValue="https://federation.renater.fr/scope/national"/>
     </afp:PolicyRequirementRule>
 
      <afp:AttributeRule attributeID="telephoneNumber">
       <afp:PermitValueRule xsi:type="saml:AttributeInMetadata" 
       onlyIfRequired="true"/>
      </afp:AttributeRule>
   </afp:AttributeFilterPolicy>

Au-delà de ces possibilités de configuration pour un ensemble de SPs, vous pouvez bien sûr ajouter des règles de diffusion (ou non diffusion) d'attributs pour un SP identifié.

Exemple 3 : non diffusion de l'attribut mail à un SP :

IDP_ROOT_DIR/conf/attribute-filter.xml
  <AttributeFilterPolicy id="DenyMailForSp">
<PolicyRequirementRule xsi:type="Requester" 
value="https://sharepp.normandie-univ.fr/sp" />
<AttributeRule attributeID="mail">
<DenyValueRule xsi:type="ANY"/>
</AttributeRule>
</AttributeFilterPolicy>

Conditions de diffusion d'un attribut : Une valeur d'attribut n'est transmise par un IdP que si une règle Permit le prévoit et si aucune règle Deny n'empêche sa diffusion. Les règles Deny ont donc préséance sur les règles Permit.