Questionnaire d'intégration

Ce questionnaire nous permet de vous recommander la meilleure approche d’intégration et de vous fournir l’exemple de code adapté à votre stack.

Désormais interactif

Le formulaire ci-dessous calcule votre recommandation en direct, enregistre vos réponses dans votre navigateur et produit un lien de partage (pour nous les transmettre en un clic). Le guide d’intégration s’en sert ensuite pour pré-sélectionner l’onglet de code de votre stack. Vous préférez le format papier ? Les sections détaillées A → G plus bas restent remplissables à la main — et fonctionnent sans JavaScript.

Recommandation express

Version interactive des sections B → E + G : vos réponses sont enregistrées dans votre navigateur et partageables par lien (pratique pour nous les transmettre). Tout reste utilisable sans JavaScript via les sections détaillées plus bas.

Protocole souhaité

OIDC (OpenID Connect) — recommandéSAML2CAS3LTI 1.3 (LTI Advantage) — ma ressource est un outil LTIJe ne sais pas / aidez-moi à choisir

Comment intégrez-vous l’authentification ?

Nouvelle application (page blanche)Application existante (ajout d’un IdP)Middleware / reverse-proxy devant l’appPasserelle / API gatewayAutre

Développez-vous en interne ?

Oui, développement interneNon — éditeur tiers / progiciel / no-code

Votre stack (si développement interne)

Intégrations SSO déjà en place

Aucun SSO à ce jourKeycloak (adaptateur déjà en place)OIDC générique (Auth0, Entra ID, Google, Okta…)SAML2 (ADFS, Shibboleth, simpleSAMLphp…)CAS (apereo CAS, phpCAS…)LTI 1.3 / LTI AdvantageAutre

Attributs souhaités

Identité (nom, prénom)Profil (élève / enseignant…)Établissement (UAI/RNE, nom)Niveau / classe / structureAutre

Votre recommandation

Répondez ci-dessus (au moins le protocole ou votre stack) pour afficher une recommandation. Sans JavaScript, reportez-vous au tableau d’aiguillage plus bas.

Le détail à nous transmettre

Le formulaire ci-dessus couvre l’essentiel pour l’aiguillage. Complétez ensuite les champs ci-dessous — notamment l’identité de la ressource (section A) et les URLs exactes (section F) — puis envoyez-les nous (voir Comment nous l’envoyer).

Section A — Identité de la ressource

Champ	Votre réponse
Nom de l’éditeur	__________________________
Nom de la ressource (telle qu’affichée dans le médiacentre)	__________________________
Contact technique (nom + e‑mail)	__________________________
Environnements souhaités	☐ Préproduction ☐ Production
Réf. GAR / id ressource (si connue)	__________________________

Section B — Protocole souhaité

Si vous n’avez pas de contrainte, choisissez OIDC : c’est le protocole le mieux outillé et le plus simple à intégrer.

• OIDC (OpenID Connect) — recommandé
• SAML2
• CAS3
• LTI 1.3 (LTI Advantage) — ma ressource est (ou doit être) un outil LTI
• Je ne sais pas / aidez‑moi à choisir

De quel côté implémentez‑vous ? Vous êtes le fournisseur de service (SP / Relying Party) ; ProxyNinja est le fournisseur d’identité (IdP / OP). En LTI 1.3, la même asymétrie s’exprime autrement : vous êtes l’outil (Tool), ProxyNinja est la plateforme (Platform) qui vous lance.

• Je peux agir en client OIDC / SP SAML / client CAS standard
• Je peux agir en outil LTI 1.3 (j’expose initiate_login_uri + target_link_uri et je valide le id_token de lancement)
• J’ai besoin d’aide pour ce rôle

Votre identité vient d’un LMS ?

Si vos utilisateurs n’arrivent pas du GAR mais d’un LMS (Brightspace/D2L, Moodle, ENT), c’est une question de source d’identité, pas de protocole : ProxyNinja branche ce LMS comme IDP du realm et votre intégration ne change pas. Signalez‑le en section E et voyez guide → votre LMS comme source d’identité.

Section C — Comment intégrez‑vous l’authentification chez vous ?

• Nouvelle application — je pars d’une page blanche
• Application existante — j’ajoute un fournisseur d’identité supplémentaire
• Middleware / reverse‑proxy devant l’application (ex. oauth2‑proxy, mod_auth_openidc, Vouch)
• Passerelle / API gateway (ex. APISIX, Kong, Traefik ForwardAuth)
• Autre : __________________________

Point d’entrée fonctionnel : disposez‑vous déjà d’une URL qui peut servir de point d’entrée après authentification (où l’utilisateur « atterrit ») ?

• Oui — URL : __________________________
• Non — à concevoir (voir le guide d’intégration)

Section D — Développez‑vous en interne ?

• Oui, développement interne
• Non — éditeur tiers / progiciel / no‑code (précisez) : ____________

Si oui, indiquez votre stack (cela détermine la bibliothèque recommandée) :

Champ	Votre réponse
Langage principal	☐ PHP ☐ Node.js ☐ .NET / C# ☐ Java ☐ Python ☐ Autre : ______
Framework	☐ Laravel ☐ Symfony ☐ Express/Fastify ☐ NestJS ☐ ASP.NET ☐ Spring ☐ Autre : ______
Version du framework	__________________________
Gestion de session actuelle	☐ Cookie de session serveur ☐ JWT/stateless ☐ Autre : ______

Section E — Avez‑vous déjà des intégrations SSO ?

Si vous avez déjà un SSO, nous pouvons souvent réutiliser votre brique existante plutôt que d’en ajouter une.

• Non, aucune intégration SSO à ce jour
• Oui — cochez ce qui s’applique :
  • Keycloak (client/adapter déjà en place)
  • OIDC générique (Auth0, Azure AD / Entra ID, Google, Okta…)
  • SAML2 (ADFS, Shibboleth, simpleSAMLphp…)
  • CAS (apereo CAS, phpCAS…)
  • LTI 1.3 / LTI Advantage — précisez le rôle tenu par votre brique :
    • outil (Tool) — vous êtes lancé par un LMS
    • plateforme (Platform) — vous lancez d’autres outils
  • Autre : __________________________

Une brique LTI outil déjà en place est réutilisable telle quelle : nous déclarons ProxyNinja comme plateforme et vous n’ajoutez aucun client OIDC.

Détail libre (briques existantes, librairies, contraintes) :

______________________________________________________________________
______________________________________________________________________

Section F — URLs à nous communiquer (prod + préprod)

Hôte de production = dédié par éditeur

Côté ProxyNinja, votre issuer de production est sur votre propre hôte (schéma https://<EDITEUR>-auth.proxyninja.fr, parfois .gar.ninja), communiqué à l’onboarding. La préproduction est, elle, l’instance partagée https://preprod-proxy.gar.ninja. Dans le tableau ci‑dessous, indiquez vos URLs (côté ressource) ; nos endpoints, vous les lisez toujours depuis le .well-known (voir le guide → configuration).

Élément	Préproduction	Production
URL de login (point d’entrée)	________________	________________
URL de redirection (callback OIDC / ACS SAML)	________________	________________
URL de logout back‑channel (OIDC ou CAS)	________________	________________

Si vous intégrez en LTI 1.3, ajoutez :

Élément	Préproduction	Production
initiate_login_uri (initiation OIDC tierce)	________________	________________
target_link_uri (URL de lancement)	________________	________________
URL JWKS de votre outil (seulement si services LTI Advantage)	________________	________________

Section G — Attributs souhaités

Quels attributs utilisateur/établissement attendez‑vous ? (Voir la référence des attributs GAR.)

• Identité (nom, prénom)
• Profil (élève / enseignant / …)
• Établissement (UAI/RNE, nom)
• Niveau / classe / structure
• Autre : __________________________

Variabilité selon la source

Tous les attributs ne sont pas garantis : un IDP comme École Directe, Pronote ou une plateforme LTI (LMS) expose souvent moins d’attributs que le GAR complet. Listez ici ce qui est indispensable vs. optionnel pour votre ressource.

En LTI 1.3, ce tableau ne s’applique pas tel quel

Un lancement LTI ne transporte pas les attributs GAR : vous recevez le profil traduit en rôles IMS et une liste blanche de paramètres custom (id_ressource, id_etab, sso_id). Si vous cochez un attribut ci‑dessus et que vous intégrez en LTI, dites‑le explicitement — il faut des mappers dédiés. Voir référence des attributs → LTI 1.3.

---

Votre recommandation (auto‑aiguillage)

Le formulaire en haut de page applique la logique ci‑dessous. Le tableau reste la référence (et le repli sans JavaScript) :

Si vous avez répondu…	Recommandation	Pour aller plus loin
Protocole OIDC + PHP/Laravel	jumbojett/openid-connect-php, ou Laravel Socialite + socialiteproviders/keycloak	Guide → OIDC · PHP/Laravel
Protocole OIDC + Node.js	openid-client (certifié) + Passport	Guide → OIDC · Node
SSO Keycloak déjà en place	Réutiliser votre adaptateur, pointer l’issuer sur ProxyNinja	Guide → Configuration
Protocole SAML2	SP SAML : onelogin/php-saml (PHP) ou @node-saml/passport-saml (Node)	Guide → SAML2
Protocole CAS3	apereo/phpCAS (PHP) ou client CAS Node	Guide → CAS3
Protocole LTI 1.3	Outil LTI 1.3 Advantage : packbackbooks/lti-1p3-tool (PHP) ou ltijs (Node)	Guide → LTI 1.3
SSO LTI outil déjà en place	Réutiliser votre brique LTI ; nous déclarons ProxyNinja comme plateforme	Guide → LTI 1.3
Pas de dev interne (middleware)	oauth2‑proxy / mod_auth_openidc devant la ressource	Guide → Point d’entrée
Je ne sais pas	Nous vous orientons après lecture de vos réponses	écrivez‑nous (ci‑dessous)

Deux règles d’aiguillage propres à LTI

1. LTI n’est pas substituable. Si vous choisissez LTI 1.3, le formulaire ne vous rabat jamais sur OIDC — même si vous déclarez un Keycloak existant. Un lancement LTI n’est pas un flux Authorization Code.
2. Pas de repli middleware. Un reverse‑proxy générique (oauth2‑proxy, mod_auth_openidc, Vouch) ne sait pas recevoir un lancement LTI : l’outil doit traiter lui‑même l’initiation et le id_token. La recommandation « middleware » est donc masquée pour ce protocole.

Logique d’aiguillage — TODO opérateur

Ce tableau alimente désormais le formulaire interactif en haut de page. TODO (en attente de l’opérateur) : valider/affiner les seuils et la politique « OIDC par défaut ». (Le cas LTI est traité ci‑dessus ; reste à confirmer la bibliothèque LTI officiellement recommandée — voir le guide.)

Comment nous l’envoyer

Deux options, au choix :

1. Lien de partage (rapide). Renseignez le formulaire en haut de page, cliquez sur « Copier le lien de partage », et envoyez‑nous ce lien : il encode vos réponses dans l’URL (?proto=…&stack=…).
2. Document détaillé. Copiez les sections A → G, complétez‑les (identité, URLs exactes, attributs indispensables) et joignez‑les.

Adressez le tout au contact qui vous a été communiqué (à l’onboarding). Nous répondons avec votre recommandation détaillée + le code de référence adapté à votre stack.

TODO opérateur

TODO (en attente de l’opérateur) : préciser le canal de réception officiel (adresse e‑mail dédiée, formulaire, ticket) et le délai de réponse cible.