Desde la actualización de DiscourseSSO a DiscourseConnect, nuestra integración SSO ha dejado de funcionar.
Tenemos una configuración que probablemente sea inusual, ya que existen múltiples aplicaciones desde las que se puede iniciar el SSO, en lugar de una sola. Nuestro software puede instalarse en servidores propios o en la nube con múltiples inquilinos. Cada instancia de inquilino del software incluye un enlace SSO hacia nuestra comunidad de Discourse. Esto significa que podemos iniciar el SSO desde (por ejemplo) tenant1.ourcompany.com, desde software.tenant2.com y desde something.else.com —casi mil lugares diferentes.
No tenemos un único proveedor de identidad central para todos nuestros inquilinos; cada uno puede utilizar su propia solución de IDP (Google, O365, AD, Okta, …). En el lado del servidor, tenemos procesos y medidas de mitigación implementadas para proteger contra el secuestro de cuentas.
Desafortunadamente, nuestro enfoque parece haber dejado de funcionar en la última actualización de Discourse. (Gracias a este commit.) Desde una perspectiva técnica, el flujo que funcionaba era el siguiente:
- Nuestro backend obtenía, mediante API, un nonce y los detalles del SSO de Discourse.
- Discourse enviaba una redirección 301 con la carga útil del SSO de vuelta a nosotros en una dirección específica.
- El servidor aquí estaba configurado para ignorar la redirección 301 (para evitar errores de nonce). En su lugar, analizaba la cabecera
Location, decodificaba los valores en base64, obtenía el nonce, generaba la carga útil del SSO, la firmaba con el secreto del SSO y enviaba al usuario de camino a la URL de inicio de sesión SSO.
Parece que el nonce ha sido modificado para que esté vinculado a la sesión del navegador (para proteger contra ataques CSRF). Esto significa que cuando intentamos el flujo anterior, el navegador del cliente carece de la cookie _forum_session con el nonce cuando lo devolvemos a Discourse, y por lo tanto recibimos un mensaje de “nonce expirado”.
¿Sería posible hacer que esta protección CSRF sea opcional? Es decir, tener una nueva configuración para enable_secure_nonce que podamos establecer en false?
En la actualidad, la mayoría de nuestros clientes están bloqueados fuera de nuestro foro, y estamos considerando tener que pedirles a todos que configuren contraseñas, perdiendo nuestra capacidad de rastrear las notificaciones del foro en nuestra aplicación, lo que provocará una disminución en la participación. 