Feeder - Alimentation de l'annuaire

Usage du Feeder OpenENT

SDET : Alimentation de l'annuaire

Le Feeder OpenENT sert à intégrer et synchroniser les données provenant de diverses sources externes (telles que les systèmes de gestion scolaire, les bases de données administratives, etc.) vers la plateforme OpenENT.

Principaux Usages

1. Synchronisation des Données

   • Le feeder permet de synchroniser les données des élèves, enseignants, classes, emplois du temps, etc., depuis les systèmes de gestion de l'école (comme les SIECLE, ProNote, etc.) vers la plateforme OpenENT.
   • Cette synchronisation garantit que les informations sur la plateforme sont à jour et cohérentes avec les données administratives de l'établissement.

2. Intégration Multi-Sources

   • Le feeder peut intégrer des données provenant de plusieurs sources hétérogènes.
   • Il permet d'unifier et de centraliser les données provenant de différents systèmes de gestion pour une meilleure interopérabilité et une vue d'ensemble cohérente sur la plateforme.

3. Automatisation des Mises à Jour

   • Le feeder peut être configuré pour effectuer des mises à jour automatiques à intervalles réguliers, minimisant ainsi l'effort manuel nécessaire pour maintenir les données à jour.
   • Cela assure une continuité du service et une fiabilité des informations disponibles sur l'ENT.

4. Gestion des Événements et Notifications

   • Le feeder peut être configuré pour générer des événements et des notifications basés sur les données reçues. Par exemple, l'ajout d'un nouvel élève ou la modification de l'emploi du temps peuvent déclencher des notifications sur la plateforme.
   • Cette fonctionnalité améliore la réactivité et l'interactivité de l'ENT.

5. Transformation et Nettoyage des Données

   • Avant d'intégrer les données dans la plateforme, le feeder peut effectuer des transformations et du nettoyage des données pour assurer leur qualité et leur cohérence.
   • Par exemple, normalisation des formats de date, validation des champs obligatoires, et correction des erreurs courantes dans les données sources.

Fonctionnement

1. Collecte des Données

   • Le feeder collecte les données depuis les systèmes sources via des API, des fichiers CSV, des bases de données ou d'autres méthodes de connexion.

2. Transformation des Données

   • Une fois les données collectées, le feeder applique des règles de transformation définies pour convertir les données au format requis par OpenENT.

3. Chargement des Données

   • Les données transformées sont ensuite chargées dans la base de données d'OpenENT, où elles sont disponibles pour les utilisateurs finaux et les autres composants de la plateforme.

4. Surveillance et Journalisation

   • Le feeder surveille les processus de synchronisation et de chargement des données, générant des logs et des rapports pour le suivi et le dépannage en cas de problèmes.

Paramètres

Parameter Name	Description	Default Value
openent.feeder.import-files	Répertoire d'import des fichiers pour le feeder	/open-ent/data/aaf

Alimentation événementielle via SCIM / SET (IAM externe)

En complément des sources historiques (AAF, imports CSV / fichiers), le feeder peut être alimenté au fil de l'eau par un IAM externe à l'aide de standards ouverts :

• SCIM 2.0 (RFC 7643 / RFC 7644) — description des ressources d'identité (utilisateurs, groupes, organisations, affectations de rôle) ;
• SET — Security Event Token (RFC 8417) — événements signés (« créé / modifié / supprimé ») encapsulés dans des JWT.

Là où l'AAF alimente par fichiers périodiques, cette source alimente par événements en temps réel.

Principe

IAM externe
   │  SET signés (JWT) portant une charge utile SCIM
   ▼
POST /directory/scim/events        (endpoint d'ingestion, module directory)
   │  1. vérification de signature via le JWKS de l'IAM (RS256/384/512)
   │  2. relai sur le bus interne (adresse "entcore.feeder", action "scim-event")
   ▼
ScimFeeder                         (traduction SCIM → modèle annuaire, réutilise les writers du feeder)
   ▼
Annuaire Neo4j                     (structures, classes, groupes, utilisateurs, rattachements)

L'endpoint POST /directory/scim/events (Content-Type application/secevent+jwt) est public (flux machine-à-machine) mais protégé par la vérification de signature : 202 si l'événement est accepté, 401 si la signature est invalide. En production, le restreindre en plus au niveau du reverse-proxy (liste d'IP / mTLS).

Traduction SCIM → annuaire

Ressource / événement SCIM	Effet dans l'annuaire
Organization (create)	Structure (établissement) — functionalId → UAI
User (create)	Utilisateur « façon feeder » (login + code d'activation + profil)
Group (create)	Classe (si tw.type = "class") ou groupe fonctionnel sinon
RoleAssignment (User→Org, Group→Org, User→Group)	Rattachements (établissement, classe, groupe)
patch (replace / add)	Mise à jour d'attributs (displayName, email, activation…)
activate / deactivate	Compte actif / bloqué
delete	Suppression + nettoyage des rattachements liés

• Les données provisionnées portent la source "SCIM", ce qui les isole des données AAF / CSV / manuelles (jamais de modification ni de suppression d'une autre source).
• Les écritures sont idempotentes (upsert par identifiant) : rejouer un événement ne crée pas de doublon.
• Un utilisateur provisionné est un compte ENT complet (login + code d'activation) : une fois activé, il se connecte comme un compte AAF.

Mise en œuvre

• libs/entcore/feeder — org.entcore.feeder.scim.ScimFeeder : traduction SCIM → annuaire, branché sur le bus entcore.feeder (action scim-event).
• libs/entcore/directory — controllers.ScimController (endpoint) + scim.ScimJwtVerifier (vérification de signature via JWKS, en Java natif).
• Tests : ScimFeederTest (JUnit + Vert.x Unit + Testcontainers Neo4j) — création, idempotence, suppression, activation/désactivation, patch, classes et rattachements.
• Configuration : URL du JWKS de l'IAM via la propriété scim-jwks-url du module directory.

⚠️ L'alimentation (le présent connecteur) et l'authentification (SSO) sont deux sujets distincts. Le SSO se configure séparément (OIDC / SAML / CAS) — voir la section Sécurité. Le mapping exact des profils et la fin de vie des comptes dépendent de l'IAM cible et sont à cadrer avec l'éditeur.