Depuis la mise à jour passant de DiscourseSSO à DiscourseConnect, notre intégration SSO a cessé de fonctionner.
Nous avons probablement une configuration inhabituelle, car plusieurs applications peuvent initier le SSO, et non une seule. Notre logiciel peut être installé en local ou multi-locataire dans le cloud. Chaque instance locataire du logiciel inclut un lien SSO vers notre communauté Discourse. Cela signifie que nous pouvons initier le SSO depuis (par exemple) tenant1.ourcompany.com, software.tenant2.com ou something.else.com — soit près d’un millier d’endroits différents.
Nous n’avons pas de fournisseur d’identité central unique pour tous nos locataires ; chacun peut utiliser sa propre solution d’IDP (Google, O365, AD, Okta, …). Côté serveur, nous avons mis en place des processus et des mesures de protection contre les prises de contrôle de compte.
Malheureusement, notre approche semble avoir cessé de fonctionner avec la dernière mise à jour de Discourse. (Merci à ce commit.) D’un point de vue technique, le flux qui fonctionnait était le suivant :
- Notre backend obtenait, via l’API, un nonce et les détails SSO de Discourse
- Discourse envoyait une redirection 301 avec la charge utile SSO vers nous à une adresse spécifique
- Le serveur ici était configuré pour ignorer la redirection 301 (pour éviter les erreurs de nonce). Au lieu de cela, il analysait l’en-tête
Location, décodait les valeurs en base64, récupérait le nonce, générait la charge utile SSO, la signait avec le secret SSO et redirigeait l’utilisateur vers l’URL de connexion SSO.
Il semble que le nonce ait été modifié pour qu’il soit lié à la session du navigateur (afin de se protéger contre les attaques CSRF). Cela signifie que lorsque nous essayons le flux ci-dessus, le navigateur client ne dispose pas du cookie _forum_session contenant le nonce lorsque nous le renvoyons vers Discourse, et nous obtenons un message « nonce expiré ».
Serait-il possible de rendre cette protection CSRF optionnelle ? Autrement dit, ajouter un nouveau paramètre enable_secure_nonce que nous pourrions définir à false ?
Pour l’instant, la plupart de nos clients sont bloqués hors de notre forum, et nous sommes contraints de leur faire configurer des mots de passe, tout en perdant notre capacité à suivre les notifications du forum dans notre application — ce qui entraînera une baisse de l’engagement. 