Problème
Actuellement, si un utilisateur saisit son adresse mail dans la mire ProConnect, et que le domaine est associé à RENATER, alors l'utilisateur est dirigé vers oidc2fer qui le redirige immédiatement vers le WAYF RENATER (https://discovery.renater.fr) pour le choix de son établissement.
Or il devrait souvent être possible de déduire l'établissement de rattachement de l'utilisateur d'après le domaine de son adresse mail. Dans ce cas de figure, on ne devrait pas envoyer l'utilisateur sur le WAYF RENATER mais plutôt directement sur l'IdP de son établissement.
Questions ouvertes
- Où stocker l'association domaine <->
entityID ?
- Si elle est stockée côté
oidc2fer, cela nécessite une base de données persistente qui n'existe pas actuellement ;
- Si elle est stockée côté ProConnect, il reste à décider si l'information serait exposée par une API appelée au besoin par
oidc2fer, ou passée automatiquement à oidc2fer par ProConnect par exemple en enrichissant le login_hint (qui actuellement contient l'adresse mail saisie, mais ici on aurait plutôt besoin d'un entityID).
Problème
Actuellement, si un utilisateur saisit son adresse mail dans la mire ProConnect, et que le domaine est associé à RENATER, alors l'utilisateur est dirigé vers
oidc2ferqui le redirige immédiatement vers le WAYF RENATER (https://discovery.renater.fr) pour le choix de son établissement.Or il devrait souvent être possible de déduire l'établissement de rattachement de l'utilisateur d'après le domaine de son adresse mail. Dans ce cas de figure, on ne devrait pas envoyer l'utilisateur sur le WAYF RENATER mais plutôt directement sur l'IdP de son établissement.
Questions ouvertes
entityID?oidc2fer, cela nécessite une base de données persistente qui n'existe pas actuellement ;oidc2fer, ou passée automatiquement àoidc2ferpar ProConnect par exemple en enrichissant lelogin_hint(qui actuellement contient l'adresse mail saisie, mais ici on aurait plutôt besoin d'unentityID).