Référence des attributs GAR

Après authentification, votre ressource reçoit un jeu d’attributs (claims OIDC /userinfo, attributs SAML, ou attributs CAS3 p3/serviceValidate). Leur nom et leur encodage dépendent du protocole, mais leur disponibilité dépend de la source d’identité branchée derrière le GAR — pas du protocole : GAR expose le même jeu complet en OIDC, SAML2 et CAS3.

LTI 1.3 est l’exception : le jeton de lancement ne transporte pas ce jeu d’attributs. Voir Et en LTI 1.3.

Source

Tableau extrait de la configuration vivante en préproduction (realm ouiactive), le 26/06/2026. La config déployée fait foi ; confirmez les types/multiplicités exacts contre le référentiel d’attributs GAR avant la mise en production.

Pourquoi la disponibilité varie

1. Le protocole n’est pas un facteur : GAR expose le même jeu complet d’attributs sur ses trois protocoles — OIDC, SAML2 et CAS3. Choisissez celui que vous maîtrisez ; la couverture d’attributs est identique.
2. La source d’identité : certaines sources branchées derrière le GAR — École Directe, Pronote — exposent beaucoup moins d’attributs et sous des noms différents (schéma ENT* côté CAS).

Votre ressource doit donc traiter chaque attribut comme garanti ou optionnel selon la source d’identité et dégrader proprement en cas d’absence.

Légende : ✅ fourni · ⚠️ partiel / variante · ❌ non fourni · ? à confirmer.

Tableau des attributs

Attribut (code GAR)	Type	Signification	GAR (OIDC · SAML · CAS)	École Directe	e-sidoc
NOM	mono	Nom de famille (→ lastName)	✅	✅	✅
PRE	mono	Prénom (→ firstName)	✅	✅	✅
UAI	mono	Code établissement (RNE/UAI)	✅	✅	✅
PRO	multi	Profil national (élève / enseignant / …)	✅	✅	✅
IDO	mono	Identifiant GAR persistant (pseudonyme stable)	✅	❌	❌
idENT	mono	Identifiant ENT	✅	⚠️ codé en dur (ecoledirecte)	❌
P_MEL	mono	Adresse mél	✅	✅ (via mail)	❌
DIV	multi	Divisions / classes	✅	✅	❌
DIV_APP	multi	Divisions d’appartenance	✅	❌	❌
GRO	multi	Groupes	✅	⚠️ (attribut groupes)	❌
E_MAT / P_MAT	multi	Matières (enseignées / suivies)	✅	❌	❌
E_MS4 E_MS5 P_MS4 P_MS5	multi	MEF / structures (niveau de formation)	✅	⚠️ (eleveMEF → E_MS4 seul)	❌

Préfixes : E_ = attribut enseignant, P_ = attribut élève/personne.

Points d’attention

• Noms sur le fil ≠ codes GAR. En OIDC/SAML les claims portent les codes GAR (UAI, PRO, NOM…). En CAS École Directe, ils arrivent sous les noms ENT (ENTPersonProfils → PRO, ENTEleveClasses → DIV, ENTPersonStructRattachUAI → UAI, ENTEleveNivFormation…) puis sont remappés.
• IDO (identifiant persistant) absent via École Directe. Si votre ressource indexe les utilisateurs sur un identifiant stable, prévoyez une stratégie de repli quand IDO manque (École Directe fabrique un identifiant de la forme ${USER}@${rneCourant}).
• Pronote : aucun IDP Pronote dans le realm ouiactive de préproduction au moment de l’extraction → disponibilité ? à confirmer. Attendez-vous à un jeu réduit proche d’École Directe (source ENT/CAS).

Et en LTI 1.3

Deux situations, à ne pas confondre — elles correspondent aux deux rôles de LTI décrits dans le guide d’intégration.

Votre ressource est lancée en LTI (ProxyNinja = plateforme)

Le id_token de lancement porte les revendications LTI, et rien d’autre : le lancement s’effectue avec scope=openid seul, donc aucun des attributs du tableau ci-dessus n’y figure par défaut. Ce qui vous parvient réellement du GAR :

Donnée GAR	Comment elle arrive en LTI
PRO (profil national)	Traduit en URIs de rôle IMS dans …/claim/roles — vous ne recevez pas la valeur brute
Identifiant de ressource	…/claim/custom → id_ressource
Établissement	…/claim/custom → id_etab (code UAI)
Identifiant SSO	…/claim/custom → sso_id
NOM, PRE, UAI, IDO, DIV, GRO, E_MAT…	Non transmis par défaut — nécessite des mappers dédiés sur votre client

Les paramètres custom transmis sont filtrés par une liste blanche par tenant (attribut de client lti.custom.allowed) : un paramètre absent de cette liste n’est jamais émis, même s’il existe côté GAR.

Rôle par défaut = Learner

Quand le profil GAR est absent ou inconnu du mapping, le rôle émis est Learner. C’est un repli, pas une information : n’accordez jamais de privilège sur l’absence d’un rôle enseignant, et prévoyez une dégradation propre.

Vos utilisateurs viennent d’un LMS (ProxyNinja = outil)

Quand la source d’identité est une plateforme LTI externe (Brightspace/D2L, Moodle, ENT), les attributs sont ceux que ce LMS veut bien émettre — pas ceux du GAR. Attendez-vous à une couverture réduite, comparable à École Directe : identité et rôle, rarement les structures (DIV, GRO, MEF). IDO, en particulier, n’existe pas : l’identifiant persistant est celui du LMS.

TODO opérateur — cartographie LTI ↔ GAR

TODO (en attente de l’opérateur) : produire, comme pour le tableau ci-dessus, un relevé de configuration vivante pour un realm exposant LTI (paramètres custom réellement autorisés, mappers d’attributs additionnels éventuels, et attributs constatés pour un IDP LMS).

Lecture côté code

Lisez les attributs depuis /userinfo (OIDC) ou l’assertion (SAML/CAS) — voir le guide d’intégration. Indiquez les attributs indispensables à votre ressource dans le questionnaire : nous vérifions leur disponibilité pour vos sources cibles.