Estoy tratando de obtener una comprensión más clara de nuestras opciones para un proyecto de reestructuración en el que estoy trabajando. He estado buscando en los foros para obtener más información y, aunque encontré una consulta similar, el escenario del autor original es algo diferente al nuestro, por lo que estoy creando este nuevo tema.
Actualmente tenemos un sitio de WordPress en domain.com configurado como cliente SSO para la instancia de Discourse en community.domain.com, pero el sitio de WP se está reorganizando como una red multisitio, por ejemplo, sub1.newdomain.com, sub2.newdomain.com, etc., y una instancia separada de Discourse para cada sitio, por ejemplo, forum.sub1.newdomain.com (o idealmente sub1.newdomain.com/forum, si podemos resolver la configuración de subcarpeta).
Queremos que nuestros usuarios tengan una única identidad en todas las comunidades y sabemos cómo sincronizar los usuarios que se registran en un subsitio de WP en toda la red. Entiendo que una instancia de Discourse puede actuar como servidor SSO para otra, pero no he podido encontrar confirmación de cómo se configura esto ni si funciona para múltiples clientes de Discourse.
Así que, pasando a mis preguntas:
En el escenario descrito, ¿es posible configurar una instancia de Discourse en, por ejemplo, auth.newdomain.com para que actúe tanto como servidor SSO para la red de WPMS como para todas las instancias de Discourse vinculadas a los subsitios?
Si la respuesta a la pregunta anterior es afirmativa, ¿sería factible configurar esa instancia “servidor” para que solo proporcione funcionalidades relacionadas con la autenticación? Es decir, que no tendría otro propósito más que ser la “fuente de verdad” de autenticación para toda la red, independientemente del sitio contra el que el usuario desee autenticarse. ¿O sería más apropiado depender de una solución de autenticación externa en este punto?
Hola, esto apareció para mí ya que enlazaste a mi tema original. Dejaré que @simon comparta sus pensamientos, pero una opción que puede o no funcionar para ti (y sería mucho más sencilla) es configurar una única instancia de Discourse y utilizar grupos para separar los foros. Puedes enviar información del grupo en la carga útil de SSO.
Sin embargo, tener múltiples foros con uno solo que proporcione SSO debería ser bastante sencillo (aunque no lo he probado antes). Creo que los pasos serían:
Agregar el plugin WP Discourse y configurarlo como cliente SSO (en las opciones de red).
Configurar el foro de Discourse que deseas que funcione como proveedor de SSO (agregar claves secretas en WP y Discourse, etc.).
A partir de ahí, al agregar foros posteriores, estos se configurarían como clientes SSO (y como WP Discourse está configurado a nivel de red, no tendrías que tocar ninguna configuración al agregar nuevos sitios).
¡Muchas gracias por compartir tus sugerencias, @jakeols. Sé que los grupos son la alternativa más comúnmente sugerida, pero no se ajustan a nuestro caso de uso particular.
Espero que @simon pueda ofrecer algunas ideas sobre lo que es y lo que no es posible aquí.
Puedes usar Discourse como proveedor de SSO en una red multisitio. Solo se habilita si configuras un único sitio de Discourse como proveedor de SSO para todos los sitios de la red. La razón de esto es que, en una red multisitio, todos los usuarios se almacenan en una sola tabla de base de datos. Si se permite que múltiples sitios de Discourse funcionen como proveedores de SSO para varios sitios de una red, no hay una manera sencilla de garantizar que los IDs de usuario de Discourse guardados en WordPress sean únicos.
Cuando el plugin WP Discourse se instala en una red multisitio, se agrega una pestaña de Discourse al menú de Administración de la Red. Para configurar Discourse como proveedor de SSO para todos los sitios de la red, ve a la página de Administración de la Red y selecciona Discourse en el menú. Selecciona la opción ‘Habilitar configuración multisitio’ y luego completa la Configuración de Conexión. Luego, baja en la página hasta la sección Configuración de SSO. Selecciona la opción ‘Habilitar cliente SSO’. Ingresa tu Clave Secreta de SSO y guarda la página de configuración.
Algo a tener en cuenta es que habilitar la funcionalidad de Cliente SSO en una red multisitio podría dar acceso a cualquier usuario de tu foro de Discourse a cualquier sitio de tu red.
Básicamente, si estás intentando lograr algo diferente a esto usando Discourse como proveedor de SSO para una red multisitio de WordPress, estás por tu cuenta. Sería técnicamente posible permitir que múltiples sitios de Discourse funcionen como proveedores de SSO para sitios individuales en una red de WordPress, pero la configuración requerida sería excesivamente compleja. No creo que esto se agregue alguna vez al plugin de WordPress.
Muchas gracias por tu respuesta. Tu publicación citada es a la que me refería en mi mensaje original. En realidad, no tengo problemas en el lado de WordPress; sabemos cómo conectarnos a nivel de red y luego sincronizar los usuarios en todos los subdominios. Lo que más intento entender es cómo podemos configurar un Discourse para que funcione como servidor SSO de otro. Estaba tratando de aclarar si es posible hacer esto mientras el Discourse de “auth” también actúa como servidor SSO para WordPress al mismo tiempo.
No he podido encontrar documentación sobre la configuración Discourse-Discourse. Si pudieras indicarme dónde encontrar más información o simplemente describir los pasos necesarios, te lo agradecería enormemente.
Entiendo tu punto, pero Discourse no está diseñado para usarse exclusivamente con fines de autenticación. Te sugiero que dediques un tiempo a considerar un servicio de autenticación dedicado al que conectes tus diversas instancias de Discourse y WordPress. Una pequeña inversión en investigación ahora puede rendir frutos más adelante.
Mi principal consejo para ti es que lo que propones es complicado y, sin importar el camino que elijas, necesitas configurar un entorno de staging que refleje tu entorno de producción previsto para experimentar con diferentes configuraciones antes de implementarlo. Este tipo de configuración puede verse afectado por diversas variables y es difícil dar consejos al respecto de manera abstracta.
Sé que la idea de configurar un entorno de staging completamente separado para una red interconectada de servidores puede parecer laboriosa, pero el trabajo involucrado en eso es mucho menor que intentar resolver problemas imprevistos que surjan una vez que hayas lanzado algo como esto.
Sí, reconozco que Discourse no es un servicio de autenticación puro. Estamos considerando tres opciones potenciales:
Usar Discourse como nuestro proveedor de identidad
Usar WordPress como nuestro proveedor de identidad
Usar un proveedor de identidad externo (SaaS o autoalojado)
Cada una de estas opciones tiene implicaciones diferentes en cuanto a costos, complejidad y experiencia de usuario que estamos tratando de evaluar, de ahí mis preguntas aquí.
No, tienes toda la razón, sí es complejo y no se nos ocurriría desplegar esto sin probarlo primero en un entorno de staging. ¡Muchas gracias por la explicación, muy apreciada!
