¿Alguien ha configurado SSO en un sitio de Townnews?
No tengo conocimiento de ningún sitio que utilice Townnews o BLOX CMS con SSO de Discourse. ¿Sabes si es posible agregar código a un sitio que use ese servicio? Si se puede agregar el código de SSO de Discourse al sitio, podría ser posible usarlo como proveedor de SSO para Discourse.
3 Me gusta
Lo siento, soy nuevo, pero me refería a usar townnews como fuente de SSO. ¿Qué código necesitaría agregar al sitio?
Esto significa que TownNews sería el proveedor de SSO para tu sitio de Discourse. Para utilizar la implementación de SSO de Discourse, debes tener la capacidad de agregar código al servicio que actúa como proveedor de SSO. Dicho código debe integrarse en el proceso de inicio de sesión del servicio. Puedes encontrar detalles sobre el código que debe agregarse aquí: Inicio de sesión único oficial para Discourse (sso).
Para un ejemplo de código funcional, consulta cómo nuestro plugin de WordPress implementa el SSO: wp-discourse/lib/sso-provider at main · discourse/wp-discourse · GitHub.
También podría ser posible iniciar sesión de los usuarios en Discourse a través de TownNews con OAuth2. Esto sería posible si TownNews puede funcionar como proveedor de OAuth2. Hay detalles sobre la configuración de inicios de sesión con OAuth2 en Discourse aquí: Soporte básico de OAuth2. Antes de invertir demasiado tiempo en ello, sería bueno confirmar si TownNews puede funcionar como proveedor de OAuth2. Debería ser posible obtener esa información de su documentación.
3 Me gusta
Estoy tratando de resolver un asunto con mi proveedor del sitio, pero pensé en compartir esto contigo para ver si contiene información que puedas utilizar para ayudarme. Agradezco mucho que hayas tomado el tiempo.
Redirección al punto final del proveedor
Cada sitio BLOX-CMS tiene un punto final de autenticación federada disponible en la misma URL reservada:
https://www.example.com/tncms/auth/federated/
El sitio consumidor inicia la autenticación redirigiendo el navegador del usuario a esta URL. El punto final requiere un parámetro return que debe establecerse con la URL del punto final del sitio consumidor.
Un ejemplo de URL:
https://www.example.com/tncms/auth/federated/?return=http://vendor.com/login/
El punto final también acepta parámetros adicionales:
-
source: Este parámetro y su valor se pasarán a la URL de inicio de sesión del sitio si se requiere la autenticación del usuario. Las plantillas pueden reaccionar a este valor para personalizar la interfaz del formulario de inicio de sesión. Por defecto, toma el valor ‘federated’ si no se especifica.
-
reauth: Establece un valor verdadero para forzar la visualización de la página de inicio de sesión, independientemente del estado actual de inicio de sesión del usuario.
Redirección al punto final del consumidor
La URL del punto final del sitio consumidor se proporciona al proveedor mediante el parámetro return cuando el usuario es redirigido inicialmente al punto final del proveedor. Tras una autenticación exitosa en el sitio del proveedor, el usuario será redirigido a esta URL junto con un parámetro code. El valor de code debe intercambiarse por los detalles de la cuenta del usuario en una llamada inmediata al servicio web, como se describe a continuación.
La URL del punto final del consumidor puede contener sus propios parámetros de consulta. El parámetro code se fusionará con ellos sin sobrescribir los demás valores.
Es posible, dependiendo de cómo estén escritas las plantillas del sitio del proveedor, que el usuario llegue al punto final del consumidor sin un valor para code. En este caso, el usuario debe tratarse como si hubiera optado por cancelar el proceso de autenticación.
Una respuesta de ejemplo tras un inicio de sesión exitoso (basada en el ejemplo anterior):
http://vendor.com/login/?code={code}
Donde {code} es un identificador único para usar en el servicio web posterior.
Llamada al servicio web posterior
Cuando el usuario llega al punto final del consumidor con un code válido, el sitio consumidor debe realizar inmediatamente una llamada al servicio web al sitio del proveedor para intercambiarlo por la información de la cuenta del usuario.
El sitio consumidor accederá a la acción get del módulo de usuario, pasando el parámetro code que le fue proporcionado por el proveedor:
https://www.example.com/tncms/webservice/v1/user/get/?code={code}
La respuesta será un objeto de datos de la cuenta del usuario, tal como se describe en la documentación de los servicios web. En caso de un código inválido, se devolverá una respuesta nula.
Un código solo es utilizable una vez. Después de usarse para recuperar una cuenta de usuario, queda inmediatamente invalidado y las futuras solicitudes con él devolverán respuestas nulas.
3 Me gusta
Esto parece prometedor: https://help.bloxcms.com/knowledge-base/applications/settings/users/authentication_provider/article_fa0ce6ec-9824-11e4-b296-23bd78ef308a.html:
La opción Proveedor de autenticación permite que tu sitio funcione como un proveedor de autenticación OpenID. Esto significa que los usuarios de tu sitio pueden usar sus credenciales de tu sitio para iniciar sesión en otros sitios que lo permitan. Otros sitios de BLOX CMS podrían actuar como sitios clientes, permitiendo este intercambio de credenciales de inicio de sesión.
Debería ser posible configurar un sitio de BLOX CMS para que funcione como proveedor de autenticación OpenID para Discourse. De ser así, esto significaría que los usuarios podrían iniciar sesión en tu foro de Discourse a través de tu sitio de TownNews. Para configurarlo, necesitarás instalar Discourse OpenID Connect (OIDC) en tu sitio de Discourse. La configuración podría requerir algunos intentos y errores. Avísanos si te atascas y trataremos de ayudarte.
3 Me gusta