Diffusion des attributs

Principe

Il est nécessaire de s'assurer que les services publiés dans la fédération d'identité reçoivent bien les données nécessaires à leur bon fonctionnement, sauf si la diffusion de certaines  s'oppose à la politique de l'établissement (politique de confidentialité, politique SSI, politique de protection des données à caractères personnel,…).

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 contrôle de la diffusion des attributs utilisateurs au sein de la fédération se fait au niveau de chaque IdP. L'administrateur de celui-ci doit en effet définir, pour chaque SP, l'ensemble des attributs utilisateur qui lui seront transmis à l'issue de la phase d'authentification de l'utilisateur. L'exercice est délicat, puisqu'il faut en effet trouver un équilibre entre le minimum requis pour le fonctionnement du service, et la protection des données à caractères personnels, 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).

Le mécanisme des filtres d'attributs (attribute filters) de l'IdP Shibboleth permet de configurer, au sein du fichier attribute-filter.xml, une ou plusieurs politiques de filtrage des attributs, en fonction d'un certain nombre de critères. Par exemple, ne fournir aucun attribut à un SP, des attributs non nominatifs à un autre et un ensemble d'attributs plus riche à un troisième.

Néanmoins, vu le nombre de SPs présents dans la fédération Education-Recherche, et le fait qu'il s'en ajoute de nouveaux régulièrement, il est aujourd'hui impossible de maintenir manuellement une politique spécifique à 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, 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.

Automatisation

Deux méthodes sont possibles:

  • une méthode moderne, basée sur l'utilisation des méta-données
  • une méthode historique, basée sur l'utilisation de filtres distants

Ces deux méthodes sont fonctionnellement équivalentes. En effet, dans les deux cas, l'information source est constituée de la liste des attributs déclarés par chaque fournisseur de service lors de son enregistrement dans la fédération. Néanmoins, sauf impossibilité technique, il est préférable d'utiliser la méthode moderne, l'autre n'étant conservée que dans un souci de compatibilité.

Utilisation des méta-données

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.

Méta-données

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.

Voici un extrait des méta-données de la fédération, incluant la description XML des attributs attendus par un fournisseur de services :

<AttributeConsumingService index="0">
  <ServiceName xml:lang="fr">CFAU - Cahier de Liaison Electronique</ServiceName>
 
  <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.

Mise en œuvre simple

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és comme demandés par le SP dans les méta-donné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.

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

IDP_ROOT_DIR/conf/attribute-filter.xml
<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>

Mise en œuvre avancée

Il est possible 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. A partir de ces catégories, il est possible de mettre en place des politiques de filtrages distinctes.

Exemple 2: 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>

Exemple 3 : 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>

Utilisation de filtres d'attributs distants

L'opérateur de la Fédération Éducation-Recherche met à disposition un ensemble de fichiers construits automatiquement à partir des informations fournies par les gestionnaires des fournisseurs de service. Dès lors, les administrateurs des fournisseurs d'identités peuvent pointer vers ces fichiers de configuration pour une gestion plus automatiques des filtres.

Les fichiers attribute-filter.xml sont proposés sous plusieurs formes pour laisser une souplesse de gestion aux administrateurs des fournisseurs d'identités :

Lien de téléchargement de tous les filtres

Mise en œuvre

Pour certains de ses fichiers de configuration, l'IdP Shibboleth peut être paramétré pour charger des fichiers de configuration distants. C'est ce mécanisme qui est utilisé ici pour charger dynamiquement les filtres distribués par l'opérateur de la Fédération. Ce paramétrage est réalisé dans le fichier de configuration service.xml.

Les filtres distants sont régulièrement mis à jour par l'IdP, la fréquence de mise à jour étant paramétrable via l'attribut XML configurationResourcePollingFrequency. L'utilisation du type FileBackedHttpResource permet également de conserver une copie locale de ces filtres, qui sera utilisée en cas d'indisponibilité de la resource distante.

Exemple 4 : inclusion de la configuration locale et du filtre diffusant les attributs requis pour toutes les ressources de la Fédération :

<srv:Service id="shibboleth.AttributeFilterEngine"
  configurationResourcePollingFrequency="PT6H"
  configurationResourcePollingRetryAttempts="3"
  xsi:type="attribute-afp:ShibbolethAttributeFilteringEngine">
 
  <srv:ConfigurationResource
    url="https://federation.renater.fr/renater/filtres/renater-attribute-filters-all.xml"
    xsi:type="resource:FileBackedHttpResource" file="/opt/shibboleth-idp/conf/renater-attribute-filters-all.xml"/>
 
  <srv:ConfigurationResource
    file="/opt/shibboleth-idp/conf/attribute-filter.xml"
    xsi:type="resource:FilesystemResource" />
 
</srv:Service>
Il est important de continuer à utiliser le fichier attribute-filter.xml local car il permet la diffusion de l'identifiant de session nameID (transcientID) à tous les SP. La non transmission de cet attribut poserait des problèmes de fonctionnement avec certaines implémentations de SP.

Exemple 5 : inclusion de la configuration locale, du filtre pour les ressources nationales et du filtre pour les communautés nationales (type UNT) :

<srv:Service
  id="shibboleth.AttributeFilterEngine"
  configurationResourcePollingFrequency="PT6H"
  configurationResourcePollingRetryAttempts="3"
  xsi:type="attribute-afp:ShibbolethAttributeFilteringEngine">
 
  <srv:ConfigurationResource
    xsi:type="resource:FileBackedHttpResource"
    url="https://federation.renater.fr/renater/filtres/renater-attribute-filters-national.xml"
    file="/opt/shibboleth-idp/conf/renater-attribute-filters-national.xml"/>
 
   <srv:ConfigurationResource
    xsi:type="resource:FileBackedHttpResource"
    url="https://federation.renater.fr/renater/filtres/renater-attribute-filters-community.xml"
    file="/opt/shibboleth-idp/conf/renater-attribute-filters-community.xml"/>
 
  <srv:ConfigurationResource
    xsi:type="resource:FilesystemResource"
    file="/opt/shibboleth-idp/conf/attribute-filter.xml"/>
 
</srv:Service>
Attention : les filtres d'attributs contiennent des règles faisant référence à des attributs générés. Ces attributs générés sont définis dans votre fichier de configuration attribute-resolver.xml. Un identifiant d'attribut permet de faire la relation entre attribute-filter.xml et attribute-resolver.xml. Dans certains cas cet identifiant n'est pas l'identifiant de l'attribut SupAnn. Exemple : “surname” pour “sn”.

vérifiez la forme de l'élément XML AttributeDefinition/id dans le fichier de configuration attribute-resolver.xml de votre IdP. Les attributs sensibles à ce problème : mail, sn, cn, o, ou.

Mise en place d'exceptions

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 pour un SP identifié. 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.

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

IDP_ROOT_DIR/conf/attribute-filter.xml
<afp:AttributeFilterPolicy id="DenyMailForSp">
 
  <afp:PolicyRequirementRule
    xsi:type="Requester"
    value="https://jenevous.faispasconfiance/"/>
 
  <afp:AttributeRule attributeID="mail">
    <afp:DenyValueRule xsi:type="ANY"/>
  </afp:AttributeRule>
 
</afp:AttributeFilterPolicy>

Validation et débogage

Pour valider la bonne transmission de ces attributs utilisateurs, il est possible d'utiliser la ressource de validation 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.

Plus d'information