← Chapitre 6 
 Chapitre 8 →

Configuration des attributs utilisateurs

1. Configuration de attribute-resolver.xml

Documentation : Attribute Resolver Configuration, consortium Shibboleth

Afin d'adapter le contenu de cette page avec le nom de votre serveur, Mettez le nom du poste ici :

Différence avec la version 2 : d'une manière générale le fichier attribute-resolver.xml de la version 2 est utilisable avec la version 3 de l'IdP Shibboleth. Les fonctionnalités non supportées sont documentées (Deprecated features).

Ce fichier définit la façon dont chaque attribut utilisateur est extrait des référentiels locaux pour ensuite être diffusé par l'IdP Shibboleth. Vous devez définir des sources de données (DataConnector) puis des attributs (AttributeDefinition) qui y font référence.

Nous allons adapter la configuration distribuée par défaut pour interroger un annuaire LDAP de test. Par la suite, vous pouvez personnaliser ce fichier pour interroger l'annuaire LDAP de votre établissement.

Active Directory : si votre référentiel utilisateur est géré avec Active Directory, vous trouverez des exemples de paramérage adapté à AD dans le fichier de configuration ldap.properties.

Le fichier de configuration attribute-resolver-ldap.xml installé par défaut sera notre base de départ ; il prévoit l'extraction des attributs mail, uid et eduPersonPrincipalName d'un annuaire LDAP. Nous allons éditer ce fichier pour changer la définition de l'attribut eduPersonPrincipalName :

/opt/shibboleth-idp/conf/attribute-resolver-ldap.xml
[...]
    <!-- ========================================== -->
    <!--      Attribute Definitions                 -->
    <!-- ========================================== -->
 
    <!--
    The EPPN is the "standard" federated username in higher ed.
    For guidelines on the implementation of this attribute, refer
    to the Shibboleth and eduPerson documentation. Above all, do
    not expose a value for this attribute without considering the
    long term implications.
    -->
 
**    <AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" scope="%{idp.scope}">**
**        <InputDataConnector ref="myLDAP" attributeNames="uid" />**
**        <DisplayName xml:lang="fr">Identifiant EPPN</DisplayName>**
**        <DisplayDescription xml:lang="fr"> Identifiant globalement unique pour une personne. </DisplayDescription>**
**        <AttributeEncoder xsi:type="SAML1ScopedString" name="urn:mace:dir:attribute-def:eduPersonPrincipalName" encodeType="false" />**
**        <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" encodeType="false" />**
**    </AttributeDefinition>**
 
    <!--
    The uid is the closest thing to a "standard" LDAP attribute
    representing a local username, but you should generally *never*
    expose uid to federated services, as it is rarely globally unique.
    -->
    <AttributeDefinition id="uid" xsi:type="Simple" >
        <InputDataConnector ref="myLDAP" attributeNames="uid"/>
        <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:uid" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" encodeType="false" />
    </AttributeDefinition>
 
    <!--
    In the rest of the world, the email address is the standard identifier,
    despite the problems with that practice. Consider making the EPPN value
    the same as your official email addresses whenever possible.
    -->
    <AttributeDefinition id="mail" xsi:type="Simple" >
        <InputDataConnector ref="myLDAP" attributeNames="mail"/>
        <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
    </AttributeDefinition>
 
    <!-- ========================================== -->
    <!--      Data Connectors                       -->
    <!-- ========================================== -->
 
    <!--
    Example LDAP Connector
 
    The connectivity details can be specified in ldap.properties to
    share them with your authentication settings if desired.
    -->
    <DataConnector id="myLDAP" xsi:type="LDAPDirectory"
        ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
        baseDN="%{idp.attribute.resolver.LDAP.baseDN}"
        principal="%{idp.attribute.resolver.LDAP.bindDN}"
        principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
        useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}"
        connectTimeout="%{idp.attribute.resolver.LDAP.connectTimeout}"
**supprimez:     trustFile="%{idp.attribute.resolver.LDAP.trustCertificates}"**
        responseTimeout="%{idp.attribute.resolver.LDAP.responseTimeout}">
        <FilterTemplate>
            <![CDATA[
                %{idp.attribute.resolver.LDAP.searchFilter}
            ]]>
        </FilterTemplate>
            <ConnectionPool
            minPoolSize="%{idp.pool.LDAP.minSize:3}"
            maxPoolSize="%{idp.pool.LDAP.maxSize:10}"
            blockWaitTime="%{idp.pool.LDAP.blockWaitTime:PT3S}"
            validatePeriodically="%{idp.pool.LDAP.validatePeriodically:true}"
            validateTimerPeriod="%{idp.pool.LDAP.validatePeriod:PT5M}"
            expirationTime="%{idp.pool.LDAP.idleTime:PT10M}"
            failFastInitialize="%{idp.pool.LDAP.failFastInitialize:false}" />
    </DataConnector>
</AttributeResolver>

Vous devez modifier la configuration de Shibboleth afin qu'il utilise attribute-resolver-ldap.xml :

/opt/shibboleth-idp/conf/services.xml
    <util:list id ="shibboleth.AttributeResolverResources">
        <value>**%{idp.home}/conf/attribute-resolver-ldap.xml**</value>
    </util:list>

Vous pouvez forcer le rechargement du nouveau fichier attribute-resolver-ldap.xml : 

$> /opt/shibboleth-idp/bin/reload-service.sh -id=shibboleth.AttributeResolverService

Par défaut le fichier ldap.properties est prévu pour réutiliser les paramètrages LDAP utilisés à l'étape authentification pour la phase de résolution d'attributs. Nous n'avons donc aucune modification à apporter dans le cas présent puisque nous utilisons le même serveur LDAP pour l'authentification et la résolution d'attributs utilisateurs :

/opt/shibboleth-idp/conf/ldap.properties
[...]
# LDAP attribute configuration, see attribute-resolver.xml
# Note, this likely won't apply to the use of legacy V2 resolver configurations
idp.attribute.resolver.LDAP.ldapURL             = %{idp.authn.LDAP.ldapURL}
idp.attribute.resolver.LDAP.connectTimeout      = %{idp.authn.LDAP.connectTimeout:PT3S}
idp.attribute.resolver.LDAP.responseTimeout     = %{idp.authn.LDAP.responseTimeout:PT3S}
idp.attribute.resolver.LDAP.baseDN              = %{idp.authn.LDAP.baseDN:undefined}
idp.attribute.resolver.LDAP.bindDN              = %{idp.authn.LDAP.bindDN:undefined}
idp.attribute.resolver.LDAP.bindDNCredential    = %{idp.authn.LDAP.bindDNCredential:undefined}
idp.attribute.resolver.LDAP.useStartTLS         = %{idp.authn.LDAP.useStartTLS:true}
idp.attribute.resolver.LDAP.trustCertificates   = %{idp.authn.LDAP.trustCertificates:undefined}
idp.attribute.resolver.LDAP.searchFilter        = (uid=$resolutionContext.principal)
[...]
Filtre LDAP: Dans l'exemple ci-dessus le filtre LDAP (propriété idp.attribute.resolver.LDAP.searchFilter ci-dessus) fait référence à l'identifiant de l'utilisateur via la variable $resolutionContext.principal dont le contenu sera l'identifiant de connexion de l'utilisateur saisi lors de la phase d'authentification.
Remarque : Chaque attribut fait l'objet de deux règles d'encodage (SAML1String et SAML2String) dans l'exemple ci-dessus. Ce mode de fonctionnement permet de rester compatible avec les SP Shibboleth 1.3 qui s'attendent à recevoir des attributs au format URN, alors que Shibboleth 2.x utilise le format OID, comme recommandé par la norme SAML2.
Remarque : Un fichier attribute-resolver-ldap.xml plus complet est distribué par RENATER. Il est disponible dans les derniers chapitres de ce TP

2. Configuration du fichier attribute-filter.xml

Documentation : Attribute Filter Configuration, consortium Shibboleth

Un fournisseur d'identités Shibboleth est finement configurable pour filtrer les attributs utilisateurs transmis à chaque fournisseur de services. Cette configuration se fait via le fichier de configuration attribute-filter.xml. La configuration par défaut ne prévoit que la diffusion de quelques attributs à un SP fictif. Nous allons l'adapter pour transmettre ces attributs utilisateurs à tous les fournisseurs de services :

/opt/shibboleth-idp/conf/attribute-filter.xml
<?xml version="1.0" encoding="UTF-8"?>
<!--
    This file is an EXAMPLE policy file.  While the policy presented in this
    example file is illustrative of some simple cases, it relies on the names of
    non-existent example services and the example attributes demonstrated in the
    default attribute-resolver.xml file.
 
    This example does contain some usable "general purpose" policies that may be
    useful in conjunction with specific deployment choices, but those policies may
    not be applicable to your specific needs or constraints.
-->
<AttributeFilterPolicyGroup id="ShibbolethFilterPolicy"
        xmlns="urn:mace:shibboleth:2.0:afp"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:mace:shibboleth:2.0:afp http://shibboleth.net/schema/idp/shibboleth-afp.xsd">
 
[[...]]
 
    <!-- Release an additional attribute to an SP. -->
    <AttributeFilterPolicy id="example1">
**        <PolicyRequirementRule xsi:type="ANY" />**
**        <AttributeRule attributeID="uid" permitAny="true" />**
**        <AttributeRule attributeID="mail" permitAny="true" />**
**        <AttributeRule attributeID="eduPersonPrincipalName" permitAny="true" />**
</AttributeFilterPolicy>
 
     <!-- Release eduPersonScopedAffiliation to two specific SPs. -->
    <AttributeFilterPolicy id="example2">
        <PolicyRequirementRule xsi:type="OR">
            <Rule xsi:type="Requester" value="https://sp.example.org" />
            <Rule xsi:type="Requester" value="https://another.example.org/shibboleth" />
        </PolicyRequirementRule>
 
        <AttributeRule attributeID="eduPersonScopedAffiliation" permitAny="true" />
    </AttributeFilterPolicy>
</AttributeFilterPolicyGroup>

Vous pouvez forcer le rechargement du nouveau fichier attribute-filter.xml : 

$> /opt/shibboleth-idp/bin/reload-service.sh -id shibboleth.AttributeFilterService
Différence avec la version 2 : le fichier attribute-filter.xml devait inclure une règle pour la diffusion du nameID (transientId). Dans la version 3, un service dédié gère la génération des NameID. Vous pouvez cependant activer le fonctionnement antérieur, voir cette documentation.
Configuration automatique : nous illustrons ici le paramétrage “manuel” du fichier attribute-filter.xml. Par la suite nous montrerons comment la diffusion des attributs utilisateurs peut être déterminée dynamiquement, en fonction des besoins des SP en attributs lors de leur inscription auprès de RENATER.

3. Vérification de la configuration des attributs

Documentation : https://wiki.shibboleth.net/confluence/display/IDP30/aacli

Shibboleth inclut l'utilitaire aacli.sh en ligne de commande qui permet de tester quels attributs sont transmis, étant donné un fournisseur de services et un identifiant d'utilisateur.

Vous pouvez tester votre configuration dès maintenant : 

$> /opt/shibboleth-idp/bin/aacli.sh -r https://formsfede-014.renater.fr/sp-ABC -n etudiant1
Différence avec la version 2 : cet utilitaire existait déjà, mais avec un fonctionnement différent. En effet, il exécutait le code de l'IdP dans un processus dédié, ce qui nécessitait d'indiquer où se trouvait la configuration, et d'avoir les droits en lecture sur ces fichiers. Aujourd'hui, cet utilitaire se contente d'émettre une requête HTTP vers le processus existant, comme les autres outils en ligne de commande d'ailleurs, ce qui ne nécessite plus d'accès au système de fichier local. 
  {
  "requester": "https://formsfede-014.renater.fr/sp-ABC",
  "principal": "etudiant1",
  "attributes": [
 
 
    {
      "name": "uid",
      "values": [
                "etudiant1"          ]
    },
 
    {
      "name": "mail",
      "values": [
                "etudiant1@example.org"          ]
    },
 
    {
      "name": "eduPersonPrincipalName",
      "values": [
                "etudiant1@univ-test.fr"          ]
    }
 
  ]
  }

Le résultat de la commande aacli.sh indique les attributs mail, uid et eduPersonPrincipalName.

La valeur droite de l'eppn dépend du domaine renseigné lors de l'installation de votre IdP (etudiant1@votre-domaine.fr).

La configuration permettant l'extraction et la diffusion de ces attributs utilisateur est donc correcte.

4. Test de votre IdP avec un service non fédéré

Cette partie ne concerne que les personnes qui suivent la formation en présentiel, et qui ont configuré la relation bilatérale avec un SP non fédéré, si vous suivez le TP en auto-formation, vous pouvez continuer au point suivant : Enregistrement dans la fédération de test

Comme vous avez pu le constater précédemment, votre connexion fonctionnait, mais aucun attribut n'était renvoyé par votre IDP.

A présent vous pouvez voir que les 3 attributs pour lesquels nous avons autorisé la diffusion sont bien affichés.

Fichiers de configuration édités dans ce chapitre :
  • /opt/shibboleth-idp/conf/attribute-resolver-ldap.xml
  • /opt/shibboleth-idp/conf/services.xml
  • /opt/shibboleth-idp/conf/attribute-filter.xml
← Chapitre 6 
Accueil 
 Chapitre 8 →
  • federation/documentation/guides-installation/idp3.4/chap07.txt
  • Dernière modification : 2020/12/01 14:41
  • de anass.chabli@renater.fr