Mapeo de claims de JWT a un Usuario de Discourse mediante plugin de login

He estado intentando encontrar un plugin SSO que me permita aprovechar las afirmaciones (claims) que provienen de mi IdP para mis usuarios de Discourse.

En el plugin OIDC, estás prácticamente limitado al endpoint userinfo. Eso no está mal, pero estaba intentando usar otra información de nuestro almacén de identidad y el resultado de userinfo no se puede ajustar. Había intentado forzar el plugin OIDC a usar id_token_info para fabricar el usuario, pero no tuve éxito.

Volví al plugin oauth, pero a simple vista parece tener la misma restricción básica, que es que depende de la información del usuario de un endpoint específico. Estoy trabajando para ver si puedo encontrar uno que devuelva el contenido de las afirmaciones JWT, pero ese no es realmente un caso de uso normal, así que no espero mucho.

Originalmente pensé que las “callback userinfo paths” en el oauth basic podrían usarse para mapear las afirmaciones al Usuario, pero siempre parezco obtener valores nulos en la respuesta y falló la inserción. Puedo decodificar el token del IdP y ver las afirmaciones correctas y, en este caso, en la raíz del JSON como iss, exp, etc., pero no puedo conectarlas al lado de ActiveRecord.

Estoy mirando jwt, pero no parece tener el mapeo de afirmaciones a usuario en absoluto. Básicamente, si obtienes un 200, estás bien, lo cual tampoco es lo que estaba buscando.

También encontré omniauth-jwt, que parece estar más cerca de mi objetivo, aunque no parece ser un plugin ni estar activamente mantenido. Algo que tal vez podría arreglar, pero es una tarea más grande de lo que esperaba.

¿Alguien puede indicarme una dirección para un plugin mantenido actualmente para mapear afirmaciones JWT a un Usuario o dónde podría estar cometiendo un error con uno de los plugins existentes?

No tengo ni idea, pero lo que haría sería ir a GitHub - discourse/all-the-plugins y buscar OmniAuth. Eso te dará un montón de plugins que usan Eso te da GitHub - discourse/discourse-jwt: Discourse Auth support for JSON Web Tokens (JWT), que podría ser lo que buscas.

Sí, ya pasé por ese.\n\nA menos que esté extra despistado hoy, solo cubre la autenticación con atributos fijos. No hay forma de hacer un mapeo de reclamaciones que pudiera encontrar. Si tuviera que bifurcar algo, probablemente empezaría por ahí, pero quería asegurarme de que no me estaba perdiendo algo obvio por ahí.

1 me gusta

Y solo para añadir un poco más de contexto para quienes encuentren este tema.

El OAuth básico parece solo admitir la obtención de atributos de un punto final de datos de usuario definido y no admite el mapeo de reclamaciones JWT. Por lo tanto, es similar al complemento OIDC, pero en lugar de la ubicación de la información del usuario proporcionada por el documento de descubrimiento, puede apuntar a cualquier punto final JSON y luego mapear por ruta. Al agregar la configuración para incluir la autenticación en la cabecera, puede acceder a lugares como https://graph.microsoft.com/v1.0/me, que utilizamos para OAuth basado en Entra.

Ahora, Entra ID ofrece cierta extensibilidad para objetos principales, pero no es tan fácil como agregar una reclamación opcional y sería un cambio global por lo que veo. Por lo tanto, no estoy seguro de que sea una opción real para nosotros. Dando un paso atrás aún más en el camino de la madurez y simplemente usando el complemento JWT parece ser el único camino, pero requeriría algo de trabajo en PR para agregar soporte de mapeo de reclamaciones. Básicamente, de la misma manera que el oauth2-basic existente permite personalizar el mapeo del campo de Discourse a un atributo JSON, necesitaría permitir una mayor personalización del campo a las reclamaciones JWT.

Ahora, ese es un camino para nosotros, pero me encontré con un problema diferente que creo que detiene todo en seco.

Después de que oauth2-basic funcionó, solicita un nuevo usuario y ve que ya existe un usuario que utiliza el correo electrónico del uso del complemento OIDC existente. A pesar de que comparten el mismo atributo de correo electrónico, creo que no puede moverse entre proveedores para el mismo usuario de Discourse. Hacer que todos comiencen de cero no es una opción real y, si bien probablemente podría hackear una migración de un registro de proveedor oauth de un proveedor oidc, siento que solo estoy pidiendo problemas. Por lo tanto, incluso si JWT tuviera el soporte de mapeo de reclamaciones, todos los usuarios existentes están anclados al proveedor OIDC sin algunas artimañas de base de datos o la creación de un manejador de “usuario existente” para permitir el cambio de cuenta asociada, parece que está atascado.

Eso es extraño. Debería coincidir con la dirección de correo electrónico y conectarse a la misma cuenta, al parecer. Los inicios de sesión de OAuth funcionan de esa manera.

Había esperado que se vincularan permitiendo \u003e1 registro_asociado_de_usuario por usuario de Discourse (por provider_id) o una indicación de “vinculación” para permitir cambiar de un proveedor a uno nuevo. Sin embargo, en mis pruebas no fue así y solo se indica que el correo electrónico está en uso y se solicita crear un nuevo Usuario.

Si me quedara en el mismo plugin, estoy seguro de que sería perfecto, pero en este caso son provider_ids únicos, cada uno con sus propios metadatos.

1 me gusta