Parcours de bout en bout

Cette page décrit le parcours complet d’un utilisateur, depuis le clic sur votre ressource dans le médiacentre de l’ENT jusqu’à l’affichage de votre application authentifiée, en passant par la création de session par ProxyNinja et la récupération des attributs.

Le principe central côté éditeur tient en une phrase :

« À chaque arrivée sur l’entrée SSO, je redemande l’identité à ProxyNinja, je récupère les attributs à jour et je renouvelle ma session locale. »

Les acteurs

Acteur	Rôle
Utilisateur	Élève ou enseignant, déjà authentifié dans son ENT.
Médiacentre (ENT)	Catalogue de ressources de l’ENT ; publie votre landing.
GAR	Le fournisseur d’identité de l’Éducation nationale (et IDP assimilés : ENT, École Directe, Pronote, plateformes LTI 1.3).
ProxyNinja	Le fournisseur d’identité managé (OP OIDC / IdP SAML / serveur CAS / plateforme LTI 1.3) qui vous fait face.
Ressource	Votre application (le Service Provider / Relying Party, ou l’outil LTI).

Diagramme de séquence

Les flèches pleines représentent des actions/redirections du navigateur ; les flèches en pointillé représentent les échanges de fédération d’identité.

sequenceDiagram
  actor U as Utilisateur (élève / enseignant)
  participant MC as Médiacentre (ENT)
  participant GAR as GAR (IdP)
  participant PN as ProxyNinja (OP managé)
  participant R as Ressource (votre application)

  Note over U,MC: L'utilisateur est déjà authentifié dans son ENT
  U->>MC: Clic sur la landing de la ressource
  MC->>R: Redirection vers le point d'entrée (URL de login)

  rect rgb(235, 243, 255)
  Note over R: Point d'entrée fonctionnel
  R->>R: Nouvelle transaction, même avec une session locale
  R-->>PN: Demande d'authentification (OIDC /authorize · SAML AuthnRequest · CAS /login)
  end

  rect rgb(235, 255, 243)
  Note over PN,GAR: ProxyNinja établit / réutilise l'identité GAR
  PN-->>GAR: Authentification pour la ressource (si nécessaire)
  GAR-->>PN: Jeton / assertion d'authentification
  Note over PN: Session ProxyNinja créée
  end

  PN-->>R: Redirection avec code / ticket (déjà authentifié — aucune re-saisie)

  rect rgb(255, 248, 235)
  Note over R,PN: Récupération des jetons et des attributs
  R->>PN: Échange code → jetons (/token)
  R->>PN: Récupération des attributs (/userinfo · claims · validation ticket)
  PN-->>R: id_token + access_token + attributs
  end

  R->>R: Création de la session locale
  R-->>U: Accès à la ressource (authentifié)

Étape par étape

1. Publication de la landing. Votre ressource est publiée dans le médiacentre de l’ENT. La vignette pointe vers votre point d’entrée (l’URL de login que vous nous communiquez — voir le questionnaire, section F).

2. Clic de l’utilisateur. L’utilisateur, déjà authentifié dans son ENT, clique sur votre ressource. Le navigateur est redirigé vers votre point d’entrée.

3. Nouvelle demande d’identité (point d’entrée d’authentification). À chaque arrivée sur cette entrée, votre application déclenche une nouvelle authentification auprès de ProxyNinja, même si elle possède déjà une session locale. Ne servez pas la ressource à partir d’attributs en cache à cette étape : ils peuvent avoir changé, notamment avec Pronote. Les pages de contenu ordinaires peuvent, elles, continuer à utiliser la session locale.

   En LTI 1.3, la plateforme vous lance ; voir la variante ci-dessous.

4. ProxyNinja crée la session. ProxyNinja délègue (ou réutilise) l’identité GAR pour la ressource, reçoit le jeton/assertion d’authentification et crée la session ProxyNinja. Comme l’utilisateur vient du médiacentre, cette étape est en général transparente (pas de nouvelle saisie d’identifiants).

5. Retour à votre point d’entrée. ProxyNinja redirige le navigateur vers votre redirect_uri (OIDC) / Assertion Consumer Service (SAML) / service (CAS) avec un code ou un ticket.

6. Récupération des jetons et des attributs. Votre application échange le code contre des jetons (/token) puis récupère les attributs via /userinfo (OIDC), l’assertion (SAML) ou la validation du ticket (CAS). Voir la référence des attributs GAR.

7. Session locale + accès. Vous actualisez les attributs et les droits, puis créez ou renouvelez la session locale avant de servir le contenu autorisé.

Le point clé

La session ProxyNinja existe déjà au moment où votre point d’entrée demande l’authentification : l’utilisateur a été authentifié en amont via le GAR. Votre travail consiste à redemander l’identité à chaque entrée SSO, puis à actualiser les attributs et renouveler la session locale. Une nouvelle transaction ne signifie pas nécessairement une nouvelle saisie d’identifiants.

Variante LTI 1.3

Si votre ressource est un outil LTI, l’ordre s’inverse : ProxyNinja tient le rôle de plateforme et pousse l’utilisateur vers vous. Vous n’interrogez plus « ai-je une session ? » — vous recevez un lancement et vous le validez.

sequenceDiagram
  actor U as Utilisateur (élève / enseignant)
  participant MC as Médiacentre (ENT)
  participant PN as ProxyNinja (plateforme LTI)
  participant GAR as GAR (IdP)
  participant T as Votre outil LTI

  U->>MC: Clic sur la landing de la ressource
  MC->>PN: Landing de lancement LTI

  rect rgb(235, 255, 243)
  Note over PN,GAR: ProxyNinja établit / réutilise l'identité GAR
  PN-->>GAR: Authentification (si nécessaire)
  GAR-->>PN: Assertion → session ProxyNinja
  Note over PN: profil GAR traduit en rôles IMS
  end

  rect rgb(235, 243, 255)
  Note over PN,T: Lancement LTI 1.3 (initiation OIDC tierce)
  PN->>T: POST initiate_login_uri (iss · login_hint · target_link_uri · lti_message_hint)
  T->>PN: /protocol/openid-connect/auth (response_type=id_token · response_mode=form_post · state · nonce)
  PN->>T: POST target_link_uri → id_token signé (roles · context · resource_link · custom)
  end

  rect rgb(255, 248, 235)
  Note over T: Validation obligatoire
  T->>T: Signature (JWKS plateforme) · iss/aud/exp · nonce · deployment_id
  end

  T->>T: Création de la session locale
  T-->>U: Accès à la ressource (authentifié)

Différences à retenir par rapport au parcours standard :

• Aucun échange de code ni appel /token : le lancement est un POST qui porte directement le id_token.
• Les attributs voyagent dans le jeton, pas via /userinfo : rôles IMS, contexte, lien de ressource et paramètres custom.
• La validation vous incombe entièrement — signature, nonce à usage unique, deployment_id. Voir le guide → LTI 1.3.

Accéder directement à un contenu

Le paramètre target d’une landing permet de transmettre à la ressource la page demandée. La ressource le conserve pendant sa propre authentification, crée sa session locale, vérifie les droits, puis ouvre le contenu. Voir Accès granulaire avec target pour l’instrumentation et la recette. Cette fonctionnalité est en préparation, non publiée en production.

Et pour la déconnexion ?

La fermeture de session est propagée par ProxyNinja vers votre ressource via le back‑channel logout (OIDC) ou le Single Logout (SAML/CAS). Votre application doit invalider la session locale en quelques secondes — n’attendez jamais l’expiration naturelle d’un jeton. Voir le guide d’intégration → déconnexion.

La suite

• Vous voulez mettre en œuvre ce parcours ? → Guide d’intégration
• Vous voulez savoir quels attributs vous recevrez ? → Référence des attributs GAR