Dans le cadre de la digitalisation du programme Erasmus, il est prévu d'intégrer progressivement les services de mobilité (OLA, application mobile Erasmus+, etc.) dans la fédération eduGAIN afin de permettre : (a) aux étudiants de s'authentifier avec le compte de leur établissement d'origine ; (b) aux services de recevoir les informations nécessaires sur les étudiants en mobilité (ESI, infos de contact, établissement de rattachement, etc.).
Comme illustré par le schéma ci-dessous, les services Erasmus sont aujourd'hui rendu disponibles dans eduGAIN via un composant de type Proxy
, point d'accès unique qui permet une mise en relation facilitée avec les fournisseurs d'identités (IdPs) des établissements enregistrés dans cette même fédération.
Ce composant présente également l'avantage pour les services d'éviter de s'enregistrer individuellement dans eduGAIN (seul le proxy y est enregistré en tant que service) et de pouvoir gérer plusieurs protocoles de fédération (i.e. un service de mobilité basé sur OpenIDConnect pourra ainsi utiliser eduGAIN basée sur SAML pour l'authentification des utilisateurs).
Ce document décrit comment configurer un fournisseur d'identités (appelé plus succinctement IdP dans la suite de ce document) pour accéder aux services Erasmus via la fédération eduGAIN.
Il est destiné à l'administrateur technique d'un IdP dont l'établissement participe au programme de mobilité Erasmus.
Un IdP utilisant eduGAIN doit pouvoir transmettre le jeu d'attributs suivant :
Attribut | Description succincte |
---|---|
Au moins 1 des identifiants suivants : - Persistent NameID - eduPersonTargetedID - eduPersonUniqueId - SAML Subject-ID - SAML Pairwise-ID | Identifiant utilisateur unique, opaque et persistant. Exemple de valeur pour l'attribut eduPersonTargetedID : https://idp.univ-exemple.fr!https://service.univ-exemple.fr!jx1SM1we3Bn8Yg0XQ= |
eduPersonPrincipalName | Identifiant utilisateur globalement unique. Exemple de valeur : jdupont@univ-exemple.fr |
Au moins 1 des infos suivantes : - commonName (cn) - displayName - sn + givenName | Nom et prénom d'une personne. Exemple de valeur pour l'attribut cn: Dupont Jean |
Adresse de courrier électronique institutionnelle. Exemple de valeur : jean.dupont@univ-exemple.fr |
|
eduPersonAffiliation | Statut de la personne vis-à-vis de l'établissement (peut être multi-valuée). Exemple de valeur : student ou student;member |
eduPersonScopedAffiliation | <eduPersonAffiliation>@<domaine DNS établissement> (peut être multi-valuée). Exemple de valeur: student@univ-exemple.fr ou student@univ-exemple.fr;member@univ-exemple.fr |
schacHomeOrganization | Nom de domaine DNS de l'établissement . Exemple de valeur : univ-exemple.fr |
schacHomeOrganizationtype | Type d'établissement (voir les valeurs possibles ici) . Exemple de valeur : urn:schac:homeOrganizationType:eu:higherEducationalInstitution |
Il s'agit ici d'appliquer les modifications de configuration suivantes sur votre IdP:
Dans le fichier metadata-providers.xml
, ajouter à la configuration existante la directive permettant de charger le fichier de métadonnées eduGAIN main-sps-edugain-metadata.xml
, comme illustré dans l'exemple ci-dessous :
Fichier /opt/shibboleth-idp/conf/metadata-providers.xml (cliquez pour déplier)
Fichier /opt/shibboleth-idp/conf/metadata-providers.xml (cliquez pour déplier)
<!-- Chargement des métadonnées de la Fédération Education-Recherche --> <MetadataProvider id="RenaterProdMetadata" xsi:type="FileBackedHTTPMetadataProvider" backingFile="%{idp.home}/metadata/main-sps-renater-metadata.xml" metadataURL="https://metadata.federation.renater.fr/renater/main/main-sps-renater-metadata.xml"> <MetadataFilter xsi:type="SignatureValidation" requireSignedMetadata="true" certificateFile="%{idp.home}/credentials/renater-metadata-signing-cert-2016.pem"> </MetadataFilter> <MetadataFilter xsi:type="EntityRoleWhiteList"> <RetainedRole>md:SPSSODescriptor</RetainedRole> </MetadataFilter> </MetadataProvider> <!-- Chargement des métadonnées eduGAIN --> <MetadataProvider id="RenaterEdugainMetadata" xsi:type="FileBackedHTTPMetadataProvider" backingFile="%{idp.home}/metadata/main-sps-edugain-metadata.xml" metadataURL="https://metadata.federation.renater.fr/edugain/main/main-sps-edugain-metadata.xml"> <MetadataFilter xsi:type="SignatureValidation" requireSignedMetadata="true" certificateFile="%{idp.home}/credentials/renater-metadata-signing-cert-2016.pem"> </MetadataFilter> <MetadataFilter xsi:type="EntityRoleWhiteList"> <RetainedRole>md:SPSSODescriptor</RetainedRole> </MetadataFilter> </MetadataProvider>
#1. Adaptation du fichier attribute-resolver:
Le fichier attribute-resolver.xml
définit tous les attributs diffusables par votre IdP et pour chacun la source de données associée.
Pour eduGAIN, vous devez enrichir ce fichier pour prendre en compte les attributs schacHomeOrganization
et schacHomeOrganizationType
non prévus par défaut. Dans la plupart des cas les valeurs de ces deux attributs seront constantes pour tous vos utilisateurs ; vous pouvez donc les définir au moyen d'un DataConnector
de type Static
comme illustré dans l'exemple ci-dessous :
Fichier /opt/shibboleth-idp/conf/attribute-resolver.xml (cliquez pour déplier)
Fichier /opt/shibboleth-idp/conf/attribute-resolver.xml (cliquez pour déplier)
<!-- ========================================== --> <!-- Attribute Definitions --> <!-- ========================================== --> <!-- Définition attribut schacHomeOrganization --> <AttributeDefinition id="schacHomeOrganization" xsi:type="Simple"> <InputDataConnector ref="staticAttributes" attributeNames="schacHomeOrganization"/> <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:schacHomeOrganization" encodeType="false" /> <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.25178.1.2.9" friendlyName="schacHomeOrganization" encodeType="false" /> </AttributeDefinition> <!-- Définition attribut schacHomeOrganizationType --> <AttributeDefinition id="schacHomeOrganizationType" xsi:type="Simple"> <InputDataConnector ref="staticAttributes" attributeNames="schacHomeOrganizationType"/> <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:schacHomeOrganizationType" encodeType="false" /> <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.25178.1.2.10" friendlyName="schacHomeOrganizationType" encodeType="false" /> </AttributeDefinition> <!-- ========================================== --> <!-- Data Connectors --> <!-- ========================================== --> <!-- Connecteur de données statique --> <DataConnector id="staticAttributes" xsi:type="Static"> <Attribute id="schacHomeOrganization"> <Value>univ-exemple.fr</Value> </Attribute> <Attribute id="schacHomeOrganizationType"> <Value>urn:schac:homeOrganizationType:int:university</Value> </Attribute> </DataConnector>
#2.Adaptation du fichier attribute-filter:
Pour que votre IdP soit capable de transmettre le jeu d'attributs recommandé, éditez le fichier attribute-filter.xml
et ajoutez une nouvelle politique de filtrage AttributeFilterPolicy
en vous basant sur l'un des deux fichiers exemple ci-dessous (selon que vous souhaitiez transmettre ce jeu d'attributs à l'ensemble des services enregistrés dans eduGAIN ou à un service en particulier).
Exemple 1 : diffusion du jeu d'attributs recommandé à l'ensemble des services enregistrés dans eduGAIN
Fichier /opt/shibboleth-idp/conf/attribute-filter.xml (cliquez pour déplier)
Fichier /opt/shibboleth-idp/conf/attribute-filter.xml (cliquez pour déplier)
<!-- Transmission du jeu d'attributs recommandé à l'ensemble des services enregistrés dans eduGAIN --> <AttributeFilterPolicy id="releaseToAnyEduGainSPs"> <!-- Ce critère correspond à toute entité enregistrée dans la fédération d'identifiant "https://federation.renater.fr/edugain", c'est-à-dire eduGAIN --> <PolicyRequirementRule xsi:type="InEntityGroup" groupID="https://federation.renater.fr/edugain/" /> <AttributeRule attributeID="eduPersonTargetedID"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="eduPersonPrincipalName"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="displayName"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="commonName"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="mail"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="eduPersonAffiliation"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="eduPersonScopedAffiliation"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="schacHomeOrganization"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="schacHomeOrganizationType"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> </AttributeFilterPolicy>
Exemple 2 : diffusion du jeu d'attributs recommandé à un service donné enregistré dans eduGAIN
Fichier /opt/shibboleth-idp/conf/attribute-filter.xml (cliquez pour déplier)
Fichier /opt/shibboleth-idp/conf/attribute-filter.xml (cliquez pour déplier)
<!-- Transmission du jeu d'attributs recommandé au service "https://sp.example.org" --> <AttributeFilterPolicy id="releaseToSelectedEduGainSp"> <PolicyRequirementRule xsi:type="Requester" value="https://sp.example.org" /> <AttributeRule attributeID="eduPersonTargetedID"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="eduPersonPrincipalName"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="displayName"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="commonName"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="mail"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="eduPersonAffiliation"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="eduPersonScopedAffiliation"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="schacHomeOrganization"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> <AttributeRule attributeID="schacHomeOrganizationType"> <PermitValueRule xsi:type="AttributeInMetadata" onlyIfRequired="true"/> </AttributeRule> </AttributeFilterPolicy>
#3.Test de votre configuration :
Pour valider votre nouvelle configuration et vérifier que votre IdP transmet bien le jeu d'attributs requis au SP correspondant au proxy erasmus (identifié par l'entityID https://proxy.prod.erasmus.eduteams.org/metadata/backend.xml
), vous pouvez utiliser l'outil en ligne de commande aacli
.
Cet outil 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 sur l'utilisation de l'outil ici.
Une fois la configuration technique de votre IdP effectuée, vous devez l'enregistrer dans la fédération eduGAIN via le guichet de la fédération. Le mode opératoire pour effectuer cet enregistrement depuis le guichet est décrit plus en détail sur cette page.
Une fois l'enregistrement de votre IdP pris en compte dans les métadonnées de la fédération eduGAIN, vous pouvez valider son fonctionnement en vous connectant à un des services de validation disponibles dans eduGAIN.
Plusieurs fédérations partenaires proposent ainsi un service de validation dans eduGAIN. Vous pouvez par exemple accéder au service de validation offert par SWITCH - l'opérateur de fédération suisse - qui vous indiquera si votre IdP renvoie bien l'ensemble des attributs requis au bon format.
Les attributs requis par les services Erasmus et qui doivent être transmis par votre IdP incluent :
Les attributs renvoyés par l'IdP doivent utiliser le NameFormat urn:oasis:names:tc:SAML:2.0:attrname-format:uri
, comme illustré dans le tableau ci-dessous :
SAML Attribute Name | SAML Attribute Friendly Name |
---|---|
urn:oid:1.3.6.1.4.1.5923.1.1.1.10 | eduPersonTargetedID |
urn:oid:1.3.6.1.4.1.5923.1.1.1.13 | eduPersonUniqueId |
urn:oasis:names:tc:SAML:attribute:subject-id | subject-id |
urn:oasis:names:tc:SAML:attribute:pairwise-id | pairwise-id |
urn:oid:1.3.6.1.4.1.5923.1.1.1.6 | eduPersonPrincipalName |
urn:oid:2.5.4.3 | cn |
urn:oid:2.16.840.1.113730.3.1.241 | displayName |
urn:oid:2.5.4.4 | surname |
urn:oid:2.5.4.42 | givenName |
urn:oid:0.9.2342.19200300.100.1.3 | |
urn:oid:1.3.6.1.4.1.5923.1.1.1.9 | eduPersonScopedAffiliation |
urn:oid:1.3.6.1.4.1.25178.1.2.9 | schacHomeOrganization |
urn:oid:1.3.6.1.4.1.25178.1.2.14 | schacPersonalUniqueCode |
L'ESI est transporté via l'attribut schacPersonalUniqueCode et, dans le cas des établissements français, construit à partir de l'INE (Identifiant National Étudiant), selon la forme suivante :
urn:schac:personalUniqueCode:int:esi:fr:[INE]
Un exemple de valeur d'ESI pour un étudiant enregistré dans un établissement français sous l'INE 1234567890G serait ainsi :
L'ESI est construit à partir de l'INE, matérialisé dans la norme supAnn par l'attribut supannCodeINE. Au niveau du SI de l'établissement, cet attribut supannCodeINE
devrait logiquement être présent pour tout étudiant enregistré dans le SI Scolarité de l'établissement.
Afin que votre IdP puisse générer un ESI, 2 stratégies sont possibles en fonction de l'attribut source provisionné dans le référentiel utilisateurs couplé à l'IdP :
schacPersonalUniqueCode
est stocké dans sa forme complète dans le référentiel utilisateurs de l'IdP (ex: urn:schac:personalUniqueCode:int:esi:fr:1234567890G
). Dans ce cas, l'IdP prendra cet attribut source tel quel, sans transformation avant transmission ;supannCodeINE
est stocké dans le référentiel utilisateurs de l'IdP. Dans ce cas, la partie gauche de l'ESI relative à l'espace de nommage (urn:schac:personalUniqueCode:int:esi:fr
) est définie statiquement au niveau de l'IdP. L'IdP sélectionnera alors l'attribut source supannCodeINE
dans le référentiel utilisateurs et construira dynamiquement - par concaténation - l'ESI à renvoyer au bon format.
Stratégie 1: l'ESI (attribut schacPersonalUniqueCode
) est stocké dans sa forme complète dans le référentiel utilisateurs de l'IdP
Dans le fichier attribute-resolver.xml
, ajoutez une définition de l'attribut schacPersonalUniqueCode
de type Simple
, comme illustré dans l'exemple ci-dessous :
Fichier /opt/shibboleth-idp/conf/attribute-resolver.xml (cliquez pour déplier)
Fichier /opt/shibboleth-idp/conf/attribute-resolver.xml (cliquez pour déplier)
<AttributeDefinition id="schacPersonalUniqueCode" xsi:type="Simple"> <InputDataConnector ref="myLDAP" attributeNames="schacPersonalUniqueCode" /> <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:schacPersonalUniqueCode" encodeType="false"/> <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.25178.1.2.14" friendlyName="schacPersonalUniqueCode" encodeType="false"/> </AttributeDefinition>
Stratégie 2: seul l'attribut supannCodeINE
est stocké dans le référentiel utilisateurs de l'IdP
Dans le fichier attribute-resolver.xml
, ajoutez une définition de l'attribut schacPersonalUniqueCode
de type Template
, utilisant l'attribut supannCodeINE
présent dans le référentiel utilisateurs de l'IdP, comme illustré dans l'exemple ci-dessous :
Fichier /opt/shibboleth-idp/conf/attribute-resolver.xml (cliquez pour déplier)
Fichier /opt/shibboleth-idp/conf/attribute-resolver.xml (cliquez pour déplier)
<!-- Définition de l'ESI (attribut schacPersonalUniqueCode) --> <AttributeDefinition id="schacPersonalUniqueCode" xsi:type="Template"> <InputDataConnector ref="myLDAP" attributeNames="supannCodeINE" /> <DisplayName xml:lang="fr">Identifiant Etudiant Européen (ESI)</DisplayName> <DisplayName xml:lang="en">European Student Identifier (ESI)</DisplayName> <Template>urn:schac:personalUniqueCode:int:esi:fr:${supannCodeINE}</Template> <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:schacPersonalUniqueCode" encodeType="false"/> <AttributeEncoder xsi:type="SAML2String" name="urn:oid:1.3.6.1.4.1.25178.1.2.14" friendlyName="schacPersonalUniqueCode" encodeType="false" /> </AttributeDefinition>
Dans le fichier attribute-filter.xml
, il s'agit ici de définir une nouvelle politique de filtrage afin que votre IdP :
schacPersonalUniqueCode
correspondant à l'ESI ;étudiant
uniquement ; https://proxy.prod.erasmus.eduteams.org/metadata/backend.xml
). https://test-sp.federation.renater.fr
)En tenant compte de ces conditions, la politique de filtrage pour transmission de l'ESI devrait ressembler à l'exemple ci-dessous :
Fichier /opt/shibboleth-idp/conf/attribute-filter.xml (cliquez pour déplier)
Fichier /opt/shibboleth-idp/conf/attribute-filter.xml (cliquez pour déplier)
<!-- Diffusion de l'ESI au proxy d'authentification Erasmus et au service de test RENATER --> <AttributeFilterPolicy id="ReleaseESI"> <PolicyRequirementRule xsi:type="AND"> <Rule xsi:type="OR"> <!-- Tout SP présentant un tag ESI dans ses métadonnées (c'est le cas du proxy d'authentification Erasmus) --> <Rule xsi:type="EntityAttributeExactMatch" attributeName="http://macedir.org/entity-category" attributeValue="https://myacademicid.org/entity-categories/esi" /> <!-- ou ce SP en particulier (service de test RENATER) --> <Rule xsi:type="Requester" value="https://test-sp.federation.renater.fr" /> </Rule> <!-- Diffusion uniquement pour la population étudiante --> <Rule xsi:type="Value" attributeID="eduPersonAffiliation" value="student" /> </PolicyRequirementRule> <!-- L'attribut schacPersonalUniqueCode contenant la valeur d'ESI est renvoyé --> <AttributeRule attributeID="schacPersonalUniqueCode"> <PermitValueRule xsi:type="ValueRegex" regex="^urn:schac:personalUniqueCode:int:esi:.*$" /> </AttributeRule> </AttributeFilterPolicy>
Pour vérifier que votre IdP est bien capable de fournir l'ESI, vous pouvez commencer par utiliser l'outil en ligne de commande aacli
comme précédemment et simuler une connexion au SP de test RENATER (si déclaré précédemment dans l'attribute filter) et/ou au proxy d'authentification Erasmus.
aacli
ici.
Outre la ligne de commande, vous pouvez également accéder au service de test en ligne RENATER (en cliquant sur “Connexion avec la Fédération Education-Recherche” dans le bandeau supérieur bleu) et vous assurer que l'ESI (via l'attribut schacPersonalUniqueCode
) est bien présent dans la liste des attributs retournés par votre IdP.
A ce stade, la configuration de votre IdP est normalement finalisée.
Vous pouvez alors tester que l'accès aux services Erasmus via votre IdP est bien fonctionnel en vous connectant au service de validation suivant : https://myacademicid.devtest.eduteams.org
Le service étant destiné à être accédé par vos étudiants, nous vous recommandons de sélectionner l'accès “Test Attribute Release for Students” puis de vous connecter à l'aide d'un compte de test étudiant.
Saisissez/sélectionner ensuite votre établissement et connectez-vous à l'aide du compte de test étudiant pour voir la page de résultat.
Si tout est OK, tout devrait être au vert.