Le contrôle de la diffusion des attributs utilisateurs au sein des fédérations se fait au niveau de chaque IdP. L'administrateur de celui-ci doit en effet définir la doctrine de diffusion des attributs utilisateurs aux différents services. L'exercice est délicat, puisqu'il faut en effet trouver un équilibre entre le minimum requis pour le fonctionnement des services, et la protection des données à caractère personnel, imposée par la réglementation (voire à ce sujet nos bonnes pratiques pour le traitement des données à caractère personnel dans la Fédération Éducation-Recherche).

Un service ne recevant pas les attributs obligatoires ou nécessaires à son fonctionnement devient alors inaccessible pour vos utilisateurs. C'est pourquoi la gestion d'un fournisseur d'identité s'accompagne d'une bonne gestion de la diffusion de ces attributs, adaptée aux demandes des services consommateurs d'attributs.

Le mécanisme des filtres d'attributs (attribute filters) de l'IdP Shibboleth permet de configurer une ou plusieurs politiques techniques de filtrage des attributs, en fonction d'un certain nombre de critères. Par exemple, ne fournir aucun attribut à un SP 'A', des attributs non nominatifs à un autre et un ensemble d'attributs plus riche à un troisième. L'ensemble de ces politiques doit permettre de couvrir la doctrine de diffusion des attributs.

Néanmoins, vu le nombre de SPs présents dans la Fédération Éducation-Recherche et dans eduGAIN, et le fait qu'il s'en ajoute de nouveaux régulièrement, il est aujourd'hui impossible de maintenir manuellement l'ensemble des politiques techniques spécifiques à chacun d'entre eux, et il est nécessaire d'automatiser la procédure. C'est d'ailleurs une des obligations du cadre technique de la Fédération Éducation-Recherche, pour l'instant limitée aux seuls services nationaux, mais qu'il est préférable d'appliquer à l'ensemble des différentes catégories.

L'automatisation se base sur l'utilisation des métadonnées, et permet la configuration la plus efficace.

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. Ces informations sont directement issues du guichet de la fédération où l'administrateur d'un fournisseur de service renseigne la liste des attributs utilisateurs dont son service a besoin pour fonctionner.

Voici un extrait des métadonnées de la fédération, incluant la description XML des attributs attendus par un fournisseur de service :

<AttributeConsumingService index="0">
  <ServiceName xml:lang="fr">CFAU - Cahier de Liaison Electronique</ServiceName>
  <!-- Attribut mail obligatoire (isRequired="true")-->
  <RequestedAttribute
    NameFormat="urn:oasis:names:tc:2.0:attrname-format:uri"
    isRequired="true"
    Name="urn:oid:0.9.2342.19200300.100.1.3"
    FriendlyName="mail">
  </RequestedAttribute>
 
  <!-- Attribut eduPersonPrincipalName non obligatoire -->
  <RequestedAttribute
    NameFormat="urn:oasis:names:tc: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étadonné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 service.

Le tableau suivant liste quelques unes des politiques techniques de diffusion posssibles. Nous détaillerons la #1, #2 et #3 dans la suite de cet article.
D'autres politiques sont bien évidemment possibles.

Notre recommandation en tant qu'opérateur de fédération est d'utiliser les politiques techniques suivantes :

• #1 ou #2
• + #3
• + #4 si vous avez des étudiants concernés par la mobilité erasmus
• + #5 si vous utilisez TCS et vous voulez vous authentifier chez Sectigo avec votre IdP

Dans une politique de filtrage, la valeur AttributeInMetadata d'une règle PermitValueRule permet d'autoriser la diffusion d'un attribut uniquement s'il est déclaré comme demandé par le SP dans les métadonnées de la fédération. L'option onlyIfRequired permet de restreindre encore plus ce critère, en exigeant que l'attribut soit indiqué comme obligatoire.

IDP_ROOT_DIR/conf/attribute-filter.xml

<!-- Diffusion d'attributs à tous les SP connus -->
<AttributeFilterPolicy id="releaseToAllSPs">
 
  <!-- ce critère correspond à n'importe quelle entité -->
  <PolicyRequirementRule xsi:type="ANY"/>
 
  <!-- Vérifiez bien le nom des attributs dans votre resolver --> 
 
  <AttributeRule attributeID="displayName">
    <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
 
  <AttributeRule attributeID="mail">
    <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
 
  <AttributeRule attributeID="eduPersonPrincipalName">
    <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
 
  <!-- Ajouter d'autres attributs en-dessous -->
 
</AttributeFilterPolicy>

Par rapport à l'exemple précédent, ce type de politique vous permet d'avoir une liste d'attributs diffusable dans eduGAIN plus restreinte que dans la Fédération Education-Recherche.

<!-- Politique de diffusion pour la Fédération Education-Recherche -->
<AttributeFilterPolicy id="releaseToFERSps">
 
  <!-- Ce critère correspond à toute entité enregistrée dans la fédération d'identifiant
   "https://federation.renater.fr/", c'est-à-dire la Fédération Education/Recherche, soit
    via un groupe d'entités (syntaxe compatible avec une source de type fichier de métadonnées),
    soit via un attribut d'entité (syntaxe compatible avec une source de type MDQ) -->
  <PolicyRequirementRule xsi:type="OR">
    <PolicyRequirementRule xsi:type="InEntityGroup" groupID="https://federation.renater.fr/" />
    <PolicyRequirementRule xsi:type="EntityAttributeExactMatch" attributeName="https://federation.renater.fr/member-of" attributeValue="https://federation.renater.fr/" />
  </PolicyRequirementRule>
 
  <AttributeRule attributeID="displayName">
    <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
 
  <AttributeRule attributeID="mail">
    <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
 
  <AttributeRule attributeID="eduPersonPrincipalName">
    <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
 
  <!-- Ajouter d'autres attributs en-dessous -->
</AttributeFilterPolicy>
 
<!-- Politique de diffusion pour eduGAIN -->
<AttributeFilterPolicy id="releaseToEdugainSps">
 
  <!-- Ce critère correspond à toute entité enregistrée dans la fédération d'identifiant 
  "https://federation.renater.fr/edugain", c'est-à-dire eduGAIN, soit via
  un groupe d'entités (syntaxe compatible avec une source de type fichier de métadonnées),
  soit via un attribut d'entité (syntaxe compatible avec une source de type MDQ) -->
  <PolicyRequirementRule xsi:type="OR">
    <PolicyRequirementRule xsi:type="InEntityGroup" groupID="https://federation.renater.fr/edugain/" />
    <PolicyRequirementRule xsi:type="EntityAttributeExactMatch" attributeName="https://federation.renater.fr/member-of" attributeValue="https://federation.renater.fr/edugain/" />
  </PolicyRequirementRule>
 
  <AttributeRule attributeID="displayName">
    <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
 
  <AttributeRule attributeID="mail">
    <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
 
  <AttributeRule attributeID="eduPersonPrincipalName">
    <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/>
  </AttributeRule>
 
  <!-- Ajouter d'autres attributs en-dessous -->
</AttributeFilterPolicy>
 
  <!-- Ajouter d'autres fédérations selons vos besoins -->

Le cadre de conformité R&S n'impose pas que tous les attributs soient transmis, mais dans la mise en oeuvre d'une politique de filtrage simple et lisible, notre recommandation est des transmettre systématiquement les attributs à tous les SP conformes.
Les attributs concernés sont :

• eduPersonPrincipalName
• eduPersonTargetedID
• mail
• displayName
• givenName
• surName
• eduPersonScopedAffiliation

<!-- Diffusion des attributs du cadre R&S (cf https://services.renater.fr/federation/documentation/engagement-conformite/researchandscholarship) -->
<AttributeFilterPolicy id="releaseResearchAndScholarship">
 
  <!-- ce critère correspond à tout SP conforme à la spécification R&S -->
  <PolicyRequirementRule xsi:type="EntityAttributeExactMatch"
      attributeName="http://macedir.org/entity-category"
      attributeValue="http://refeds.org/category/research-and-scholarship"/>
 
  <!-- diffusion de l'ePPN obligatoire -->
  <AttributeRule attributeID="eduPersonPrincipalName">
    <PermitValueRule xsi:type="ANY"/>
  </AttributeRule>
 
  <!-- diffusion de l'eduPersonTargetedID optionnelle -->
  <AttributeRule attributeID="eduPersonTargetedID">
    <PermitValueRule xsi:type="ANY"/> 
  </AttributeRule>
 
  <!-- diffusion du mail obligatoire -->
  <AttributeRule attributeID="mail">
    <PermitValueRule xsi:type="ANY"/>
  </AttributeRule>
 
  <!-- soit displayName OU (givenName + sn) est obligatoire mais les 3 sont recommandés -->
  <AttributeRule attributeID="displayName">
    <PermitValueRule xsi:type="ANY"/>
  </AttributeRule>
 
  <AttributeRule attributeID="givenName">
    <PermitValueRule xsi:type="ANY"/>
  </AttributeRule>
 
  <AttributeRule attributeID="surName">
    <PermitValueRule xsi:type="ANY"/>
  </AttributeRule>
 
  <!-- diffusion de l'eduPersonScopedAffiliation optionnelle -->
  <AttributeRule attributeID="eduPersonScopedAffiliation">
    <PermitValueRule xsi:type="ANY"/>
  </AttributeRule>
 
</AttributeFilterPolicy>

Quelle que soit la méthode utilisée, il est possible de surcharger la configuration pour un SP spécifique par des règles de diffusion (ou non diffusion) d'attributs. En effet, un attribut n'est transmis 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.

Il se peut qu'un SP ait besoin d'un attribut non défini dans les métadonnées. Quelques exemples :

• Le SP n'exprime pas les attributs requis (possible dans eduGAIN) ;
• L'attribut demandé n'est pas défini sur le guichet de la fédération (attribut trop spécifique - uniquement utilisé dans une fédération locale) ;
• Le SP a besoin d'un identifiant à choisir parmi {eduPersonPrincipalName, eduPersonTargetedID, eduPersonUniqueId}. Le SP peut déclarer ces 3 attributs dans les métadonnées, mais n'en marquer aucun comme obligatoire. Il revient alors à l'administrateur de l'IdP d'ajouter une exception pour transmettre le bon attribut (possible dans eduGAIN).

<!-- Exemple : diffusion de l'ePPN à un service en particulier -->
<AttributeFilterPolicy id="releaseEPPNToSPFooBar">
 
  <PolicyRequirementRule
    xsi:type="Requester"
    value="https://foo.bar.com/sp"/>
 
    <AttributeRule attributeID="eduPersonPrincipalName">
      <PermitValueRule xsi:type="ANY"/>
    </AttributeRule>
 
</AttributeFilterPolicy>

A contrario, il est tout à fait possible de limiter la diffusion d'attributs à un SP trop “gourmand” :

<!-- Exemple : refus de diffusion de l'email à un service en particulier -->
<AttributeFilterPolicy id="DenyMailForSp">
 
  <PolicyRequirementRule
    xsi:type="Requester"
    value="https://jenevous.faispasconfiance/"/>
 
  <AttributeRule attributeID="mail">
    <DenyValueRule xsi:type="ANY"/>
  </AttributeRule>
 
</AttributeFilterPolicy>

Si vous avez besoin de renvoyer les attributs subject-id et pairwise-id décrits dans SAML V2.0 Subject Identifier Attributes, il faut adapter les règles de filtrage de ce 2 attributs, car la demande de présence de ces attributs se fait via un Entity-Category (comme R&S).

Voici comment mettre à jour vos politiques de filtrage :

  <AttributeFilterPolicy id="releasePairwiseID">
    <!-- ce critère correspond à tout SP avec l'attribut urn:oasis:names:tc:SAML:profiles:subject-id:req valant "pairwise-id" ou "any" -->
    <PolicyRequirementRule xsi:type="EntityAttributeRegexMatch" attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req" attributeValueRegex="pairwise-id|any"/>
 
    <!-- Vérifiez bien le nom de l'attribut dans votre resolver -->
    <AttributeRule attributeID="samlPairwiseID">
      <PermitValueRule xsi:type="ANY"/>
    </AttributeRule>
  </AttributeFilterPolicy>
 
  <AttributeFilterPolicy id="releaseSubjectID">
    <!-- ce critère correspond à tout SP avec l'attribut urn:oasis:names:tc:SAML:profiles:subject-id:req valant "subject-id"-->
    <PolicyRequirementRule xsi:type="EntityAttributeRegexMatch" attributeName="urn:oasis:names:tc:SAML:profiles:subject-id:req" attributeValueRegex="subject-id"/>
 
    <!-- Vérifiez bien le nom de l'attribut dans votre resolver -->
    <AttributeRule attributeID="samlSubjectID">
      <PermitValueRule xsi:type="ANY"/>
    </AttributeRule>
  </AttributeFilterPolicy>

Un IdP peut tout à fait être utilisé pour accéder à des services non fédérés. Par exemple, un établissement peut mettre en place un service utilisant SAML pour déléguer l'authentification.

Ce SP va lui aussi requérir un certain nombre d'attributs, que l'IdP doit fournir. Or, les métadonnées du SP n'intègre pas toujours la description des attributs requis. Le plus simple dans ce cas consiste à ajouter une politique spécifique pour ce SP :

<!-- Diffusion des attributs mail, givenName et surName au SP https://foo.univ-xyz.fr/sp -->
<AttributeFilterPolicy id="releaseToLocalSPFoo">
  <PolicyRequirementRule xsi:type="Requester" value="https://foo.univ-xyz.fr/sp"/>
  <AttributeRule attributeID="mail">
    <PermitValueRule xsi:type="ANY"/>
  </AttributeRule>
  <AttributeRule attributeID="givenName">
    <PermitValueRule xsi:type="ANY"/>
  </AttributeRule>
  <AttributeRule attributeID="surName">
    <PermitValueRule xsi:type="ANY"/>
  </AttributeRule>
</AttributeFilterPolicy>

Pour valider la bonne transmission de ces attributs utilisateurs, il est possible d'utiliser le fournisseur de service de test et validation RENATER qui affiche tous les attributs reçus.

Par ailleurs, l'outil en ligne de commande aacli permet de simuler une connexion à n'importe quel fournisseur de service et d'obtenir la réponse de l'IdP à celui-ci. Plus d'informations dans le support de formation.

• La documentation Shibboleth