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 :

« Ai‑je une session ? Non → je demande à ProxyNinja (qui a déjà authentifié l’utilisateur) → je récupère les attributs. »

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: Ai-je une session locale ? → NON
  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. Vérification de session (point d’entrée fonctionnel). Votre application se pose une seule question : « ai‑je déjà une session locale pour cet utilisateur ? »

   • Oui → vous servez directement la ressource.
   • Non → vous déclenchez l’authentification auprès de ProxyNinja (/authorize en OIDC, AuthnRequest en SAML, /login en CAS).

   En LTI 1.3, cette étape n’existe pas sous cette forme : c’est la plateforme qui 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 créez la session locale (cookie de session serveur recommandé) et l’utilisateur accède à la ressource.

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 se résume donc à détecter l’absence de session locale, demander l’identité à ProxyNinja, puis lire les attributs.

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.

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