Connecteurs d'accès

Une intégration applicative, plusieurs parcours d’accès

ProxyNinja relie les environnements de vos clients à votre ressource. Un élève peut arriver depuis son ENT, un enseignant depuis PRONOTE, un lecteur depuis le portail de sa bibliothèque. Votre application reçoit ensuite une identité et les attributs prévus dans votre configuration.

Pour l’éditeur, le travail consiste à définir un contrat d’identité, un contrat de données et une règle d’accès. Brancher un nouveau connecteur ne garantit ni les mêmes attributs, ni le rapprochement des comptes existants, ni l’ouverture automatique d’un abonnement.

Cette page est un guide de préparation et de recette. Les capacités décrites doivent être confirmées pour votre instance, votre établissement pilote et votre protocole de sortie. Elle ne constitue pas une annonce d’activation de tous les connecteurs chez tous les clients.

Le parcours commun

1. L’utilisateur ouvre votre ressource depuis son environnement habituel ou depuis un lien institutionnel.
2. ProxyNinja sollicite la bonne source d’identité. Une session existante peut rendre cette étape transparente ; une session expirée peut demander une nouvelle authentification.
3. Les données utiles sont transmises à votre application selon le contrat configuré : OIDC, SAML, CAS ou lancement LTI.
4. Votre application retrouve le compte, contrôle l’accès et ouvre le bon contenu. Les favoris, travaux et progressions doivent rester attachés à la bonne personne.

Qui fait quoi ?

Acteur	Responsabilité dans le projet
Éditeur de la ressource	Définir les données indispensables, les droits, la clé de compte, les URL de retour et le comportement en cas de refus ; intégrer et tester le côté applicatif.
Équipe ProxyNinja	Configurer le connecteur et le routage, adapter les attributs, exposer le protocole convenu, vérifier les échanges et accompagner la recette.
Établissement / bibliothèque / administrateur LMS	Activer la ressource dans son environnement, autoriser la transmission des données nécessaires, fournir les accès pilotes et vérifier les populations concernées.
Partenaire ou réseau d’accès	Fournir le raccordement, les paramètres et les procédures qui lui sont propres. Certaines ouvertures nécessitent sa validation.

Comparer les connecteurs

Connecteur	Point de départ habituel	Décision principale côté éditeur
GAR	Médiacentre ENT ou ÉduGAR	Articuler abonnement, affectation et identité GAR de la ressource.
PRONOTE	Lien de ressource dans PRONOTE	Valider l’établissement et le profil ; traiter séparément les fonctions pédagogiques et leurs API.
École Directe	Ressource activée dans École Directe	Adapter les données ENT disponibles ; ne pas exiger le jeu d’attributs GAR.
e-sidoc	Portail documentaire du CDI	Identifier le lecteur dans le bon établissement, même sans adresse électronique réelle.
OpenAthens	Portail de bibliothèque, site éditeur ou lien WAYFless	Stabiliser le compte et relier institution, affiliations et contrat d’accès.
LTI 1.3	Lien de cours dans un LMS, ou lancement de votre outil depuis ProxyNinja	Choisir le sens d’intégration et le contexte pédagogique à transmettre.
ENT / SAML / OIDC / CAS	Portail d’un établissement ou d’un réseau	Définir un contrat d’attributs propre au partenaire.
EZproxy / accès par IP	Réseau ou proxy d’une bibliothèque	Distinguer accès institutionnel partagé et compte personnel.

GAR · préparer l’accès et l’affectation

Ce que vit l’utilisateur. L’élève ou l’enseignant clique sur une ressource disponible dans son médiacentre. La connexion à la ressource s’appuie sur son environnement scolaire ; votre application ouvre le contenu ou explique le refus d’accès.

À organiser avant l’ouverture. Avec les interlocuteurs GAR concernés, cadrer le raccordement de la ressource, son abonnement et son affectation aux publics visés. L’affectation est une étape opérationnelle à part entière : une intégration SSO fonctionnelle ne remplace pas la mise à disposition de la ressource. Voir la documentation officielle sur l’affectation.

Ce que cela change dans votre application. Définir la clé de compte à partir de l’identité garantie pour votre intégration. Les attributs comme IDO, UAI, PRO, les noms, classes ou groupes sont à inventorier selon le profil et les données autorisées pour la ressource. Préciser lesquels sont indispensables, lesquels sont facultatifs et leur format. Ne pas prendre une adresse électronique comme identifiant de référence.

Recette attendue. Tester élève et enseignant, ressource affectée et non accessible, reconnexion, retour sur le même compte et déconnexion. Vérifier aussi le comportement après une évolution d’affectation. Si le suivi pédagogique est important, convenir du traitement des changements de classe ou d’établissement.

Point d’attention. Une source PRONOTE ou École Directe raccordée directement à ProxyNinja n’est pas, de ce seul fait, un parcours GAR. Le protocole de sortie commun ne rend pas les données d’origine identiques.

PRONOTE · distinguer accès à la ressource et échanges pédagogiques

Ce que vit l’utilisateur. Depuis PRONOTE, l’utilisateur ouvre le lien de votre ressource. ProxyNinja valide l’authentification du parcours configuré, puis votre application reçoit l’identité et les données convenues.

À organiser avant l’ouverture. Confirmer les modalités de raccordement partenaire, l’activation dans les établissements pilotes et l’URL exacte de lancement. Les connecteurs partenaires PRONOTE sont des intégrations activables dans les conditions prévues par INDEX ÉDUCATION ; leur présence ne découle pas du seul paramétrage de ProxyNinja.

Ce que cela change dans votre application. Valider l’identifiant, le rattachement établissement, le profil et les autres attributs sur un échange réel. Le nom et la disponibilité des données peuvent différer du GAR. Prévoir des comptes élèves et enseignants distincts pour la recette.

Si vous échangez devoirs ou résultats. L’accès SSO et les appels aux API pédagogiques sont deux chantiers distincts. Certains échanges PRONOTE comportent un objet structuré apiSupport : le contrat doit préciser sa transmission, son format et les opérations autorisées. Les habilitations et jetons d’API doivent rester côté serveur ; leur réception ne prouve pas qu’un retour de note ou de travail a été implémenté.

Recette attendue. Lancement depuis le véritable établissement, profil correct, continuité du compte, ticket expiré et déconnexion. Tester chaque opération pédagogique séparément si elle fait partie du périmètre vendu.

École Directe · accepter un contrat de données différent

Ce que vit l’utilisateur. L’utilisateur accède à la ressource depuis École Directe, selon l’activation et les droits configurés pour son établissement. Le catalogue Mes Applis d’Aplim décrit cet environnement de ressources connectées.

À organiser avant l’ouverture. Valider avec les interlocuteurs concernés la mise à disposition de l’application, les établissements et les profils couverts. Fournir les URL de lancement et de retour et organiser une recette depuis les comptes réels de test.

Ce que cela change dans votre application. Les attributs CAS de type ENT* peuvent être adaptés aux noms attendus par votre ressource. Cette adaptation ne crée pas une donnée absente : le fait de recevoir un champ de profil ou d’établissement ne garantit pas les groupes, les matières, les structures ou un identifiant GAR IDO.

Identité et droits. Utiliser l’identifiant convenu pour cette source et son périmètre établissement. Définir la correspondance des profils vers les rôles de votre application, sans attribuer un rôle enseignant par défaut si le profil manque.

Recette attendue. Plusieurs profils et, si votre offre le nécessite, plusieurs établissements ; absence d’une donnée facultative ; connexion répétée sans doublon ; refus compréhensible quand le contrat d’accès ne couvre pas l’utilisateur.

e-sidoc · ouvrir la ressource depuis le CDI

Ce que vit l’utilisateur. Depuis le portail documentaire e-sidoc de son établissement, le lecteur ouvre une ressource mise à sa disposition. Le portail e-sidoc de Réseau Canopé est le point de départ documentaire ; la ressource conserve sa propre session applicative.

À organiser avant l’ouverture. Valider la connexion de votre ressource à e-sidoc, sa publication dans le portail, l’établissement de rattachement et le parcours d’authentification retenu. Associer le documentaliste ou l’administrateur du portail à la recette.

Ce que cela change dans votre application. Ne pas imposer d’email réel pour accéder au contenu. Selon la configuration, ProxyNinja peut produire une adresse technique afin de satisfaire une contrainte de profil. Cette adresse n’est pas une boîte de messagerie utilisateur : elle ne doit déclencher ni vérification par email ni récupération de mot de passe par email. Le lecteur s’authentifie par son parcours institutionnel.

Recette attendue. Lancement depuis le portail, bon rattachement établissement, création ou récupération du compte sans formulaire de correction d’email, accès aux contenus souscrits et absence de dépendance à des classes ou groupes non transmis.

OpenAthens · institution, identité stable et accès aux contenus

Ce que vit l’utilisateur. Depuis le site de l’éditeur, il choisit son institution puis s’y authentifie. Depuis un lien WAYFless, l’institution est déjà indiquée : l’étape de sélection peut être évitée. Un lien profond peut viser directement un contenu, si toute la chaîne conserve et traite cette destination. Voir le parcours WAYFless officiel.

À organiser avant l’ouverture. Configurer l’application OpenAthens, le parcours Keystone/OIDC ou SAML retenu, ses retours autorisés et les données réellement transmises par les institutions pilotes. La préproduction et la production doivent chacune être enregistrées et testées avec leurs propres URL. Le nom de la ressource affichée ne suffit pas à déterminer l’environnement ciblé.

Identité stable. Les identifiants ciblés tels que eduPersonTargetedID et Pairwise-ID servent à reconnaître un lecteur pour un fournisseur de service. Leur disponibilité doit être vérifiée auprès de l’institution ; voir les recommandations OpenAthens. ProxyNinja dispose d’un mécanisme de sujet stable pour son connecteur OIDC OpenAthens. Son exposition à votre application doit être configurée explicitement. Changer le sub d’une intégration existante est une migration de comptes à préparer.

Un sub reçu seul en amont ne doit servir de repli qu’après confirmation de sa persistance dans le parcours concerné. Une connexion réussie ne suffit pas à démontrer cette persistance.

Attributs et abonnement. Convenir des scopes institutionnels, affiliations et identifiants nécessaires. Les noms, prénoms et emails peuvent être absents. derivedEduPersonScope et eduPersonScopedAffiliation peuvent aider à appliquer une règle d’accès convenue ; une liste de scopes annoncés par un fournisseur, telle que scopesDeclaredByIdP, n’est pas à elle seule une preuve des droits de l’utilisateur. Distinguer ces données des scopes OIDC demandés comme openid, profile ou email.

Autorisation de l’organisation. Selon votre intégration, ProxyNinja peut vérifier, avant d’ouvrir l’accès, que l’organisation OpenAthens de l’utilisateur est autorisée pour votre ressource, à partir de ses scopes. Un refus à cette étape signale une absence d’abonnement, pas une erreur de connexion.

Retour à la page exacte et partage. Un lien WAYFless peut porter une destination : la landing ProxyNinja la transmet à votre ressource (voir Accès granulaire). Pour qu’un utilisateur partage une page avec un collègue de son institution, ProxyNinja peut vous fournir un gabarit de lien WAYFless : voir Liens partageables.

Recette attendue. Au moins une institution autorisée et une non autorisée, plusieurs connexions du même lecteur, absence d’email, variantes d’identifiants disponibles, lien WAYFless et lien profond jusqu’au contenu final. Le refus doit distinguer un problème de connexion d’une absence d’abonnement.

LTI 1.3 · choisir le sens du raccordement

LTI transporte un lancement pédagogique et son contexte. Il faut préciser lequel des deux parcours fait partie de votre projet.

Vos utilisateurs viennent d’un LMS

Le LMS — par exemple Moodle ou Brightspace — lance une ressource via ProxyNinja. ProxyNinja reçoit le lancement comme outil LTI, puis votre application peut continuer à utiliser le protocole de sortie convenu, par exemple OIDC.

L’administrateur LMS enregistre l’outil et fournit les paramètres d’intégration : émetteur, identifiant client, déploiement, clés et points d’entrée. L’éditeur définit comment le contexte de cours et les rôles se traduisent dans sa ressource. Le LMS décide des informations d’identité qu’il transmet ; l’email peut manquer.

Votre ressource est elle-même un outil LTI

ProxyNinja agit comme plateforme LTI après l’authentification de l’utilisateur par une autre source. Votre outil reçoit un lancement signé avec les claims LTI configurés. Les attributs GAR habituels ne sont pas tous recopiés automatiquement dans ce lancement.

Dans les deux cas. Valider la combinaison émetteur, client et déploiement ; distinguer la personne, son rôle dans un cours et le lien de ressource. Un enseignant dans un cours n’est pas nécessairement administrateur de votre application. La spécification LTI 1.3 définit notamment les paramètres de déploiement et les claims de lancement.

Fonctions à contractualiser séparément. Sélection de contenus (Deep Linking), récupération des membres et rôles (NRPS) et échange de notes (AGS) demandent chacun une configuration, des droits et une recette. Un lancement LTI réussi ne valide pas ces services, ni la synchronisation complète des classes.

Recette attendue. Apprenant et enseignant, deux cours, deux liens vers des contenus distincts, maintien du compte entre les lancements et comportement dans le navigateur utilisé par l’établissement. Tester en plus chaque service pédagogique effectivement retenu.

Autres raccordements à prévoir

ENT et fédérations SAML, OIDC ou CAS

Pour un ENT ou un fournisseur d’identité générique, le protocole décrit l’échange technique, pas la liste des données disponibles. Il faut obtenir les paramètres de confiance, une identité de référence, les profils, le rattachement établissement et les règles de diffusion des attributs. Tester un cas réel avant d’en déduire la couverture de tous les établissements d’un réseau.

EZproxy et reconnaissance par IP

Dans le connecteur ProxyNinja de reconnaissance par IP, l’adresse réseau est rapprochée d’une bibliothèque ou d’un établissement. L’identité obtenue peut être partagée au niveau institutionnel. Elle ne permet pas à elle seule d’isoler les favoris, les résultats ou l’historique de chaque lecteur.

Pour proposer des fonctions personnelles, prévoir un mécanisme d’identification individuelle séparé. La recette porte sur les plages IP déclarées, les accès à distance, les changements de réseau et le refus depuis une adresse non reconnue. Ce mode d’accès est distinct d’un parcours fédéré qui fournit un identifiant utilisateur.

La configuration côté bibliothèque (lien d’entrée, stanza, suffixe d’hôte, retour direct ou proxifié) est décrite dans Accès par EZproxy. Pour qu’un lecteur partage une page avec un collègue de la même bibliothèque, voir Liens partageables.

Les trois réglages à distinguer pour les attributs

Réglage	Ce qu’il permet	Ce qu’il ne garantit pas
Mapper d’entrée	Extraire ou adapter un attribut fourni par le connecteur.	Que la source le transmette pour tous les utilisateurs.
Profil utilisateur / affichage administratif	Définir sa visibilité et ses permissions dans l’administration, lorsqu’il est conservé.	Sa présence dans un jeton envoyé à la ressource.
Mapper de sortie	Transmettre un claim ou attribut à un client donné, avec le nom et le type convenus.	L’existence d’un droit commercial ou d’une donnée absente en entrée.

Le contrat doit préciser où lire chaque donnée : ID token, access token, UserInfo, assertion SAML, réponse CAS ou lancement LTI. Un tableau reste un tableau même lorsqu’il ne contient qu’une seule valeur. Décider aussi comment traiter une donnée retirée par la source : ne pas conserver indéfiniment un ancien rôle comme s’il était encore valide.

L’affichage administratif et la conservation des données dépendent du mode du realm. Dans un fonctionnement transitoire, les données de session ne constituent pas un annuaire utilisateur persistant. Demander quels attributs sont conservés, lesquels vivent seulement pendant la session et comment leur suppression est traitée. Un réglage observé sur un client n’est pas une règle universelle de ProxyNinja.

Le processus d’ouverture d’un nouveau connecteur

1. Cadrer le parcours. Source d’identité, populations, établissements, protocole applicatif, point d’entrée et destination finale. Identifier les fonctions pédagogiques éventuellement attendues.
2. Convenir du contrat de compte et de données. Identifiant de référence, périmètre d’unicité, attributs obligatoires ou facultatifs, types, rôles et droits. Définir la stratégie pour les comptes déjà présents.
3. Préparer le raccordement partenaire. Paramètres de confiance, autorisations, abonnement et activation de la ressource dans l’environnement de départ. Nommer un responsable de chaque côté.
4. Configurer et tester en préproduction. Utiliser les URL réellement enregistrées et des comptes pilotes représentatifs. Contrôler ce que reçoit la ressource, pas seulement ce qui apparaît dans l’administration.
5. Valider le résultat métier. Le bon utilisateur retrouve son compte, son contenu et ses droits. Les utilisateurs non couverts sont refusés proprement.
6. Ouvrir la production. Vérifier les paramètres propres à cet environnement, refaire les cas critiques, prévoir un retour arrière et surveiller les premiers accès.

La fiche à fournir à ProxyNinja

• Connecteur(s) souhaité(s), établissement(s) pilote(s), contact technique et responsable de l’activation partenaire.
• URL de votre application, environnement de recette, URL de retour et exemple de contenu à ouvrir directement.
• Protocole supporté et stratégie actuelle d’identification des comptes.
• Attributs indispensables, rôle attendu, modèle d’abonnement et comportement sans droit d’accès.
• Comptes de test par profil, utilisateurs déjà présents à préserver et éventuelles fonctions de cours, devoirs ou notes.

La grille de validation avant ouverture

Situation à tester	Résultat attendu
Première connexion autorisée	Accès au bon contenu sans champ de profil impossible à compléter.
Reconnexion du même utilisateur	Même compte et même historique ; pas de doublon.
Utilisateur d’une autre institution	Bon rattachement ; aucune ouverture par confusion d’établissement.
Utilisateur authentifié mais non couvert	Refus métier clair, sans contenu réservé accessible.
Email, groupe ou affiliation absent	Dégradation prévue ; pas de privilège accordé par défaut.
Plusieurs rôles ou valeurs	Valeurs correctement interprétées, sans perte au changement de format.
Compte existant via un autre connecteur	Rapprochement explicite si prévu ; aucune fusion sur le seul nom ou email.
Lien profond et session expirée	Authentification puis retour au contenu demandé, sans redirection libre vers un domaine tiers.
Déconnexion et poste partagé	Le prochain utilisateur ne récupère pas la session précédente ; portée de la déconnexion documentée.
Retrait d’un droit ou changement de profil	Prise en compte selon la durée de session et le rafraîchissement convenus.

Pour le support, transmettre l’heure avec fuseau, l’environnement, le connecteur, le profil de test et le message affiché. Ne pas copier dans un ticket un jeton, un secret ou l’URL complète de retour contenant un code de connexion.

Périmètre et références

Mise à jour du 2 octobre 2026. Les parcours décrits s’appuient sur la documentation et les extensions ProxyNinja à cette date, complétées par les références officielles liées dans chaque section. La disponibilité exacte des attributs et des services reste à constater sur le raccordement concerné.

Pour les détails techniques, consulter le guide d’intégration, le parcours de bout en bout, l’accès granulaire, les liens partageables et la référence des attributs. Les tableaux historiques de configuration sont des observations datées, pas une garantie uniforme pour tous les connecteurs.