Grafana: Inicio de sesión automático mediante URL de token

sería bastante inseguro ya que cualquiera puede ver el token, puede crear una instantánea de los datos visibles e incrustarla, sería más seguro

Sí, pero al usar instantáneas, no tiene permiso para editarlo, o ¿hay alguna forma de editar el panel a través de instantáneas?

Esto es muy importante para la interoperabilidad con SaaS.
Tenemos nuestra propia autenticación y paneles de control, queremos brindar la capacidad de pasar un usuario de nuestro panel a Grafana, de manera similar a cómo Heroku interopera con New Relic y otros servicios sin contraseñas.

Proporcionar un método de autenticación de URL + token es parte del curso.
Si alguien luego va e incrusta eso en un sitio web público, entonces ninguna cantidad de seguridad salvará a esa persona de sí misma. Eso es culpa de ellos.
Proporcionar suficientes advertencias en la documentación / UI debería estar bien para esto.

Sin esta funcionalidad, los usuarios deben encontrar una segunda pantalla de inicio de sesión, donde se confundirán en cuanto a qué nombre de usuario / contraseña ingresar.

Este es un gran bloqueador para nosotros.

Suena como una buena característica para tener en Grafana. Me gustaría ayudar con las relaciones públicas, ya que hay muchas otras cosas que son realmente de alta prioridad en este momento.

Buena explicación @adamlwgriffiths me pasa lo mismo.

Ahora mismo solucionamos este problema con un pequeño truco, agregando un javascript que inicia sesión automáticamente en grafana, pero es una solución temporal

+10 por esto !!
Para que esto sea seguro, debe haber un hash del nombre de usuario + contraseña + fecha, contenido en el token. Esto podría usarse para caducar el token después de x número de horas para mejorar la seguridad.

Si tengo algo de tiempo, consideraré seriamente trabajar en esto.

Si está almacenando la fecha de creación del token para que pueda caducarlo, también está almacenando el hash y la cuenta asociada, por lo que no creo que el hash deba generarse a partir de ningún dato en particular. Solo tiene que ser un espacio de búsqueda lo suficientemente grande para que no sea factible adivinar.

@adamlwgriffiths , esto también debería admitir algunos roles básicos ... como visor, editor, etc., similar a lo que se hace con las claves de API.

Creo que, a largo plazo, el token de usuario / org / api debe consolidarse, en lugar de agregar un nuevo método.
Si los tokens de la API se expandieran para permitir el uso desde la interfaz HTML, esto no sería un problema.
Los tokens de API ya tienen roles y se pueden revocar, por lo que solo deben poder usarse para la vista web en lugar de API pura.

Los tokens de la API de la OMI deberían funcionar igual que los usuarios normales. Hay una segregación arbitraria que no está documentada y creo que es contraintuitivo. Creo que lo mejor sería habilitar todas las comprobaciones de inicio de sesión para comprobar también las claves API.

¿Se ha implementado esta función? Estaba intentando que un usuario fuera redirigido automáticamente al panel de grafana desde mi sitio.

@comcomservices Como seguimiento del token en sí, definitivamente podría cifrar la información dentro del token con la identificación de usuario y el tiempo de vencimiento del token. De esa manera, puede leer el token en sí y obtener la información sin requerir que los tokens se almacenen en la base de datos y ejecutar 'barrer y borrar' sobre tokens antiguos.

No me atrevo a recomendar tal cosa, creo firmemente que la criptografía es difícil, y sin una comprensión completa de lo que está haciendo, no es una buena idea intentar hacerlo.

El otro problema con los tokens cifrados es que son bastante grandes y, cuanto más información, más grande se vuelven.
Donde, como una cadena aleatoria se puede hacer con cualquier longitud, siempre que el espacio sea lo suficientemente grande como para hacer inviable la fuerza bruta.

@adamlwgriffiths en lo que respecta a la criptografía, tengo antecedentes formales y lo disfruto, pero para este caso estoy totalmente de acuerdo en que un token sería lo mejor. por demasiado tiempo ... aunque lo entenderé y este es el primero en mi lista

¡Espero con ansias esta función! Con respecto al comentario de raven-js de Sentry ; hará una URL pública y luego la restringirá por origen (ver más abajo). ¿Mitigaría esto el problema de seguridad?

@ Germanaz0, ¿su JS de inicio de sesión automático está disponible públicamente? Estoy buscando implementar algo similar contra la rama maestra y parece que el backend redirige a la pantalla de inicio de sesión antes de ingresar a la página del tablero. Todavía no estoy muy familiarizado con la estructura del proyecto, por lo que es posible que no esté conectando la sección correcta en el código JS.

@rca sí, pero mi solución es súper simple https://gist.github.com/Germanaz0/d41b5f60dd8097405b6b

Recibe un parámetro de entrada como? T = base64 de un json con {user: _USERNAME_, pass: _PASS_, redirect_to: _URL_TO_REDIRECT}

Deberá incluir ese script en la página de inicio de sesión.

@ Germanaz0 , gracias por compartir! Después de enviar mi comentario comencé a echar un vistazo y, como señaló, descubrí que necesitaba actualizar la página de inicio de sesión. Tomé un enfoque ligeramente diferente y actualicé el controlador de inicio de sesión en lugar de hacer un script independiente; mi cambio está aquí: https://github.com/zymbit/grafana/tree/auto-login-by-cookie-redirect

¿Es esto digno de una solicitud de extracción? Estaría feliz de hacer las modificaciones necesarias para que esto se convierta en un estado fusionable.

¿Algún avance en esto?
@rca ¿

+1 para un PR de @rca

@ Germanaz0 , ¿en qué archivo está incluyendo su archivo .js?

@rca , ¿tiene alguna instrucción sobre cómo usar su mod de controlador de inicio de sesión? Soy nuevo en grafana y estoy tratando de que esto funcione para un quiosco desatendido.

Por cierto, si alguien más necesita una forma de lograr esto para los kioscos, etc., consulte el authproxy de

@scottfuhrman Nada escrito formalmente, sin embargo, aquí está mi caso de uso e implementación:

No buscaba el modo kiosco, sino una forma de insertar un panel como iframe en una página externa. Los gráficos están incrustados bastante limpios, por ejemplo:

En la página que busca para insertar el panel, necesita el siguiente marcado:

<div id='grafana-dashboard' class="col-lg-12"></div>


<script type="text/javascript">
    GrafanaEmbed = {
        grafanaUrl: 'https://your.grafana.example.com',
        dashboard: 'dashboad-name',
        queryParams: {
            dashnav: 0,
            // this is a base64-encoded string of username:password
            // for example on a *NIX machine (and Mac OS X):
            // $ echo "kiosk1:supersecret" | base64
            // a2lvc2sxOnN1cGVyc2VjcmV0Cg==
            auth: 'a2lvc2sxOnN1cGVyc2VjcmV0Cg==',
            theme: 'light'
        }
    };

    (function() {
        var d = document.createElement('script'); d.type = 'text/javascript'; d.async = true;
        d.src = GrafanaEmbed.grafanaUrl + '/public/app/features/dashboard/embed.js';
        (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(d);
    })();
</script>

Espero que esto ayude.

+1

No tengo los recursos de personal para esto, pero estaría feliz de financiar colectivamente el esfuerzo para esto.

Pensé que tenía esto resuelto hasta que intenté usar una lista de reproducción. El uso de authproxy funciona para un panel determinado, pero una vez que probé una lista de reproducción con varios paneles, encontré el mismo problema. No entiendo el punto de tener un modo de kiosco cuando es imposible implementar una aplicación de kiosco real a menos que deshabilitemos completamente la seguridad de visualización.

@torkelo He contratado a @ over64 para trabajar en esto por mí.

¿Cómo recomienda que se implemente? Básicamente, lo que necesito es tener un token en la cadena de URL que omita / resuelva la autenticación. ¿Cuál es el mejor enfoque para esto?

no estoy seguro, tendría que investigar cómo se debe implementar de forma segura dicha función

Entendido. Estamos listos una vez que haya ideado un plan :)

Si tiene una idea de cómo hacerlo, hágamelo saber y puedo evaluarla.

Bien. @ over64 echará un vistazo y sugerirá algo.

@torkelo ¿Puedes mirar las relaciones públicas de @ over64 en # 7431 para ver si eso tiene sentido?

¿Alguna solución fácil? Estoy tratando de implementar la solución @ Germanaz0 pero no me funciona :(

Esto es imprescindible, de lo contrario, uno está bloqueado al incrustar una instantánea dentro del iframe. La URL de la instantánea incrustada debe admitir la clave / token de inicio de sesión.

Hola a todos,

Los comentarios más recientes en este hilo son con respecto a:

• seguridad
• incrustación dentro de un iframe

Con respecto a la seguridad, considere mi anterior comentario anterior: https://github.com/grafana/grafana/issues/3752#issuecomment -200874453

Y sobre la incrustación en un iframe: https://github.com/grafana/grafana/issues/3752#issuecomment -267062843

Esta rama (aunque bastante antigua) contiene código prestado de Discourse que ajusta muy bien un iframe y se autentica mediante un token como se describe en el comentario anterior.

@torkelo Por favor, avíseme si consideraría una solicitud de extracción que incorpore los elementos anteriores.

@rca, ¿qué es ese embed.js en su código anterior?

@zoell es un js tomado del proyecto Discourse para dimensionar bien un iframe en la página según el contenido incrustado con el marco.

@rca oh gracias. No pude encontrar ese archivo en la rama que mencionaste. ¿Está disponible en otro lugar?

@zoell , bifurcaré ese repositorio e

@rca gracias que sería genial.

@rca Lo siento, todavía no puedo encontrar el archivo en la rama que mencionaste antes.

@TinaRen @zoell Dejé caer la pelota sobre esto, disculpas.

Sin embargo, después de echar un vistazo ahora, ¡parece que el archivo ha estado allí todo el tiempo! 😬

Haré cualquier trabajo adicional sobre esto en:

https://github.com/rca/grafana

Y el archivo está en:

https://github.com/rca/grafana/blob/embedding/public/app/features/dashboard/embed.js

Si este archivo no se está construyendo y no termina en el directorio public_gen/ , hágamelo saber.

¡Gracias!

¿Es posible al menos limitar grafana a los accesos de localhost? (para limitar el uso compartido de paneles al mismo sitio del servidor)

Me encantaría ver a alguien que lo intente con una implementación adecuada que pueda ir en sentido ascendente. La solución que propusimos (# 7431), nunca fue aceptada :(

Estoy feliz de que alguien de nuestro lado dedique algún tiempo a esto, pero necesitaríamos orientación sobre lo que sería aceptable en la fase inicial.

Logrado hacer esto con éxito en el uso de Grafana auth.proxy y de Nginx ngx_http_secure_link_module

Los enlaces que utilizo tienen el formato http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Una vez que el usuario hace clic en él, se establece la cookie de sesión y el usuario puede navegar por Grafana como si hubiera iniciado sesión normalmente.

Ventajas:

• El enlace caduca después de un tiempo + seguridad
• El enlace genera hash con ID de usuario, marca de tiempo y contraseña + seguridad
• No es necesario escribir contraseña + conveniencia

Mi conf nginx es así

server {
    listen 3001 default_server;
#   listen [::]:3001 default_server;

    server_name _;

        location / {
        set $user "";
        set $state "";

        if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

        secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

No dude en contactarme si necesita ayuda con esto

Muy interesante, @Nayar. Sin embargo, mi preocupación con esta solución es que requiere una gran cantidad de personalizaciones. Preferiría algo que esté integrado en Grafana de forma nativa.

Usé un Grafana común. Solo tuve que recompilar un nginx de stock con el módulo habilitado y eso es todo.

Nayar, ¿podría decirme si la solución que implementó puede funcionar con todas las versiones de grafana? Soy nuevo en Grafana. En mi organización ya han instalado

Sacando algunas ideas (y problemas) de cómo resolver esto.

Solución más rápida:

1) agregue un tipo especial (bandera) en una clave de API para que pueda usarse en la URL para iniciar sesión.

Ventajas: solo los administradores de la organización pueden agregar claves API.

2) hacer posible que los usuarios creen claves de API y claves de URL (variante de clave de API).

Los problemas con esto serán configuraciones de oauth donde si un usuario puede crear una clave de API o una clave de URL, podrá usarla después de que se le haya eliminado el acceso de Grafana (desde el sistema de oauth). Como la clave api o la clave URL no requerirá un inicio de sesión Oauth. Esto será un gran problema para las claves de API de usuario cuando finalmente las hagamos. Una solución de mitigación podría ser permitir que solo los administradores de la organización o los administradores del servidor Grafana creen claves de API de usuario.

Pensamientos @DanCech ? ¿Continuar con el uso de una clave de API con una marca AllowUrlLogin?

No creo que usar la infraestructura de claves de API sea el camino correcto, ya que dificulta agregar más funciones más adelante (por ejemplo, limitar la URL a un conjunto particular de paneles, lo que permite a los no administradores crear enlaces de inicio de sesión ) y es probable que resulte confuso para los usuarios. Ciertamente podríamos usar los mismos conceptos y tener una estructura de backend similar, pero nos da más opciones si lo separamos, y creo que será más claro para los usuarios.

En cuanto a la pregunta de inicio de sesión de Oauth, creo que tenemos que averiguar cuál debería ser el alcance aquí. El mismo problema existe para los usuarios de oauth si también tiene las contraseñas habilitadas, ya que pueden establecer una contraseña local y podrían iniciar sesión de esa manera después de que se deshabilite la cuenta de oauth. La única solución real a ese problema es almacenar ese enlace en la cuenta de usuario y siempre enviar un usuario oauth a través del ciclo de redireccionamiento de oauth antes de aceptar su inicio de sesión.

También creo que necesitamos encontrar un nombre razonable para esta funcionalidad. La "URL de inicio de sesión" puede ser demasiado amplia y no deja espacio para su uso en el futuro como una forma de, por ejemplo, compartir un enlace en vivo limitado a un panel en particular.

A @mattttt le encantaría conocer tu opinión

ya que dificulta agregar más funcionalidades más adelante (por ejemplo, limitar la URL a un conjunto particular de paneles de control, lo que permite a los no administradores crear enlaces de inicio de sesión)

Dudo en vincular esta función de inicio de sesión a permisos o restringirla a paneles de control específicos (que no sea vincularla a un rol o usuario de la organización). Porque convertiría esto en una función para compartir y establecería expectativas de seguridad que no se cumplen (ya que puede consultar todos los datos de una fuente de datos utilizada por una organización).

La única solución real a ese problema es almacenar ese enlace en la cuenta de usuario y siempre enviar un usuario oauth a través del ciclo de redireccionamiento de oauth antes de aceptar su inicio de sesión.

No estoy seguro de cómo eso resuelve "revocar" la URL de inicio de sesión / token de API de usuario. Si nunca intentan iniciar sesión con oauth después de que se eliminó su acceso, Grafana nunca lo sabría.

@hemsush Según esta publicación de blog, debería funcionar a partir de Grafana 2.0 en adelante: https://grafana.com/blog/2015/12/07/grafana-authproxy-have-it-your-way/

Dudo en vincular esta función de inicio de sesión a permisos o restringirla a paneles de control específicos (que no sea vincularla a un rol o usuario de la organización). Porque convertiría esto en una función para compartir y establecería expectativas de seguridad que no se cumplen (ya que puede consultar todos los datos de una fuente de datos utilizada por una organización).

Ese es un problema que debe resolverse, por lo que mi sugerencia sería que este sistema se diseñe con ese caso de uso en mente para el futuro.

No estoy seguro de cómo eso resuelve "revocar" la URL de inicio de sesión / token de API de usuario. Si nunca intentan iniciar sesión con oauth después de que se eliminó su acceso, Grafana nunca lo sabría.

Mi opinión es que la vista que obtiene el cliente cuando usa uno de estos enlaces debe ser similar a la del usuario "anónimo", donde no se registran mágicamente como un usuario en particular, sino que obtienen una cuenta de espectador limitada, lo que divorciaría totalmente esta función. de cuentas de usuario individuales. Eso evitaría el problema de los permisos de la cuenta de usuario individual, reduciría el nivel de riesgo ya que un enlace no se podría utilizar para realizar ningún cambio y permitiría la gestión centralizada de todos los enlaces de acceso activos por parte de los administradores de la organización.

Propuesta de solución

1) Introduzca el nuevo concepto "Token de URL del visor", que puede agregar / eliminar de la página de claves API (podemos crear una nueva página para esto más adelante). Almacene en la nueva tabla url_token y funcionarán desde una perspectiva de seguridad muy similar a las claves de la API. Es decir, se generarán y validarán de la misma manera que las claves de API. Sin embargo, se puede usar para iniciar sesión mediante el uso en la URL con "& url-auth-token =".
2) Opción para restringir el token para que solo funcione con la API de renderizado PNG (será más seguro ya que los usuarios con token de URL no podrán emitir ninguna consulta, solo verán paneles / paneles existentes)
3) En el futuro, tendremos que encontrar una manera de vincular el token a los grupos de usuarios y los permisos del tablero, pero aún no estoy seguro de cómo funcionará. Creo que podría ser bueno crear un usuario ficticio para esto que se pueda usar para otorgar permisos a los usuarios del "Token de URL" para paneles de control y fuentes de datos específicos. Odiaría tener que tener comprobaciones / uniones explícitas para los tokens de URL en las comprobaciones de permisos.

4) Deje en claro que cualquier persona con un token de URL tendrá acceso a todas las fuentes de datos de la organización (y técnicamente puede emitir cualquier consulta) (a menos que se use la opción de restricción de procesamiento de API).

pensamientos @bergquist @DanCech

Opción para restringir el token para que solo funcione con la API de renderizado PNG (será más seguro ya que los usuarios con token de URL no podrán emitir ninguna consulta, solo verán tableros / paneles existentes)

No creo que el renderizado PNG sea una buena solución. Parpadeará y no se verá tan bien como el Grafana real.

Me gusta la idea de conectar el token a un usuario. La forma más fácil de conectar ese token / inicio de sesión a grupos de usuarios y permisos de carpeta de panel. Pero creo que iniciar sesión con el token (inicio de sesión de TV / modo de visualización / modo de TV) debería obligar al usuario a estar en el rol Viewer .

Deje en claro que cualquier persona con un token de URL tendrá acceso a todas las fuentes de datos de la organización (y técnicamente puede emitir cualquier consulta) (a menos que se use la opción de restricción de procesamiento de API).

Agregar información y advertencias al crear nuevos tokens puede ayudar.

El problema de vincular un token a un usuario "normal" es que causa todo tipo de problemas cuando el usuario es modificado o eliminado. Si los tokens de URL pueden ser miembros de un grupo de la misma manera que los usuarios, entonces habría una gran flexibilidad en la configuración de URL individuales con acceso a paneles de control particulares, etc.

No estoy seguro de que agregue mucha complejidad a las verificaciones de permisos, estaría usando una tabla diferente para los miembros del grupo dependiendo de si el espectador es un usuario regular o un token de URL, pero las verificaciones de acceso en todo el sistema no deberían necesidad de cambio.

En lo que respecta a hacer cumplir el acceso a las fuentes de datos, no hay diferencia aquí que con los usuarios habituales. La solución final para ese problema es mover los complementos de la fuente de datos al backend y hacer que el frontend envíe las solicitudes de la fuente de datos especificando el tablero, el panel, el rango de tiempo y los valores de var de la plantilla y haciendo que las consultas reales se construyan en el backend después de validar que el usuario tiene acceso y que los valores de var de la plantilla son legítimos.

El problema de vincular un token a un usuario "normal" es que causa todo tipo de problemas cuando el usuario es modificado o eliminado.

El problema de que cualquiera que conozca un token (incluso si la cuenta está cerrada) puede ver los paneles de control es cierto para ambas soluciones. Se puede revocar el acceso eliminando el usuario o el token.

No estoy seguro de que agregue mucha complejidad a las verificaciones de permisos, estaría usando una tabla diferente para los miembros del grupo dependiendo de si el espectador es un usuario regular o un token de URL, pero las verificaciones de acceso en todo el sistema no deberían necesidad de cambio.

Las comprobaciones deben tener el mismo aspecto independientemente de la autenticación. Entonces eso no será un gran problema. La interfaz de usuario para agregar tokens / usuarios a grupos, paneles de control, etc. puede ser complicada y solo ayudará a un número muy pequeño de usuarios.

En lo que respecta a hacer cumplir el acceso a las fuentes de datos, no hay diferencia aquí que con los usuarios habituales. La solución final para ese problema es mover los complementos de la fuente de datos al backend y hacer que el frontend envíe las solicitudes de la fuente de datos especificando el tablero, el panel, el rango de tiempo y los valores de var de la plantilla y haciendo que las consultas reales se construyan en el backend después de validar que el usuario tiene acceso y que los valores de var de la plantilla son legítimos.

Aquí es donde creo que deberíamos empezar a trabajar para proporcionar una buena experiencia para compartir paneles de forma segura. Sin esto, toda solución se siente como un mal intercambio. Creo que debería mantenerse al mínimo hasta que se resuelva el acceso a la fuente de datos.

También encontré este problema con el panel de inserción en el modo username+passwd+ldap auth ...
¿Alguna actualización sobre esto?

Estoy muy interesado en la opción de token de visor. Si puedo ayudar de alguna manera, estaría encantado de ayudar.

¡Hola chicos!
Estoy tratando de crear un enlace autenticado para un tablero, tengo un backend en java y un front-end en JSF, quiero poner un usuario en la pantalla que, al hacer clic, redirigirá al usuario directamente a su tablero, yo No entiendo bien el concepto, alguien. ¿Tiene un ejemplo de cómo puedo hacer esto?

Hola,

Solo una idea, tratando de ayudar. ¿Por qué no agregar una nueva API de usuario, usando la autenticación básica como esta?
? curl https://admin:admin<strong i="7">@localhost</strong>:3000/api/user/cookie
y obtén un resultado JSON como
{"user_name":"admin","cookie_name":"grafana_,session":"a0b1c2d3e4","remember":"da27ef425e9e0d"}

Se protegería a través de https, y podría usar esta información para falsificar cookies y autorizar a los usuarios a ver sus hermosos gráficos.

Miro con atención su código y creo que (con mucho respeto ) no sería demasiado difícil.
En lugar de enviar:
user.Rands+user.Password, setting.CookieRememberName, user.Login, days, setting.AppSubUrl+"/"

a la función SetSuperSecureCookie, puede crear una nueva función, inspirada en SetSuperSecureCookie, algo como esto:

func (ctx *Context) NewFunc(secret, name, value string, others ...interface{}) {
   key := pbkdf2.Key([]byte(secret), []byte(secret), 1000, 16, sha256.New)
   text, err := com.AESGCMEncrypt(key, []byte(value))
   return hex.EncodeToString(text)
}

La respuesta podría ser elaborada y enviar como en una de sus funciones como:

func getUserUserProfile(userId int64) Response {
    query := m.GetUserProfileQuery{UserId: userId}

    if err := bus.Dispatch(&query); err != nil {
        return ApiError(500, "Failed to get user", err)
    }

    cook:= array
    result := {
        user_name: user.name,
                cookie_name:   cookie.name,
        session: s.session,
                remember: cokie.remember

    }

    return Json(200, &result)
}

Sé que no eres un mago y que codificar no es jugar a Lego, pero esta es una función muy importante para mí. Intentaría ayudar.

Durante GrafanaCon, @DanCech mencionó la idea de crear listas de reproducción públicas con una clave GUID. Similar a cómo funcionan las instantáneas en la actualidad. Compartir / almacenar dicha clave podría considerarse tan seguro como un token de API, pero limitado a ver listas de reproducción. La lista de reproducción podría asociarse con el creador / actualizador para validar los permisos de visualización del panel.

La URL podría verse como https://play.grafana.com/playlists/public/<hash>

Una cosa que me gusta de esta solución es que restringe la funcionalidad a solo ver listas de reproducción (panel de control) que creo que es el caso de uso más grande para tokens como este.

Pero aún necesitaríamos iniciar sesión con el usuario de alguna manera, ya que las acl / anotaciones del panel, etc. requerirán autenticación del lado del servidor.

Supongo que podemos pensar más en este tipo de solución. Principalmente quería hacer una explosión de ideas sobre nuestra conversación de GrafanaCon :)

Gracias @bergquist , definitivamente es bueno escribir estas cosas mientras aún están frescas.

La siguiente evolución de ese pensamiento fue agregar el concepto de una "pantalla" para desacoplar aún más las cosas, de modo que el usuario pudiera crear una "pantalla" que luego tuviera una URL secreta con hash a la que se conectaría. Esto serviría para el mismo propósito pero permitiría la administración de las pantallas desde dentro de Grafana, para que el usuario pudiera controlar qué lista de reproducción se muestra, etc.

El objetivo final aquí sería admitir un mecanismo para que un usuario cree fácilmente una tarjeta sd o una imagen usb que pueda usarse para iniciar una raspberry pi dedicada y mostrar la lista de reproducción deseada de forma segura desde Grafana sin tener que pasar por los aros de autenticación.

El objetivo final aquí sería admitir un mecanismo para que un usuario cree fácilmente una tarjeta sd o una imagen usb que pueda usarse para iniciar una raspberry pi dedicada y mostrar la lista de reproducción deseada de forma segura desde Grafana sin tener que pasar por los aros de autenticación.

@DanCech Este es exactamente el caso de uso que estoy buscando.

La siguiente evolución de ese pensamiento fue agregar el concepto de una "pantalla" para desacoplar aún más las cosas, de modo que el usuario pudiera crear una "pantalla" que luego tuviera una URL secreta con hash a la que se conectaría.

@DanCech ¡ Esto suena perfecto!

Hola a todos,

Esto parece estar un poco lejos del problema original abierto por Germanaz0

Debería ser bueno tener un inicio de sesión automático que pase un token de usuario a través de la URL, esta podría ser una solución parcial para incrustar iframes en los sitios.

y explicado por adamlwgriffiths

Tenemos nuestra propia autenticación y paneles de control, queremos brindar la capacidad de pasar un usuario de nuestro panel a Grafana, de manera similar a cómo Heroku interopera con New Relic y otros servicios sin contraseñas. Proporcionar un método de autenticación de URL + token es parte del curso.

Germanaz0 desarrolla un script js

Ahora mismo solucionamos este problema con un pequeño truco, agregando un javascript que inicia sesión automáticamente en grafana, pero es una solución temporal

Entiendo que necesitan un inicio de sesión automático para usar grafana chart en su propio sitio. Esto es lo que también necesito sin usar la lista de reproducción ... ¿Sería posible?

Si solo desea registrar automáticamente a un usuario, su mejor opción es usar http://docs.grafana.org/tutorials/authproxy/

@DanCech, el problema es que permitiría a todos los usuarios iniciar sesión automáticamente. Queremos una forma de iniciar sesión automáticamente solo los usuarios que tienen una URL específica.

@gzzo que depende del diseño del proxy

También estoy buscando esta función en Grafana.
Creo que Microsoft Power BI incrustado es la buena solución. Vea los enlaces a continuación.
https://github.com/Microsoft/PowerBI-JavaScript/wiki/Embedding-Basics
https://microsoft.github.io/PowerBI-JavaScript/demo/v2-demo/index.html

Creo que la solución PowerBi anterior se basa en OAuth2.
El lado del servidor de Grafana admitirá OAuth2 y habilitará CORS.

@Nayar Soy nuevo en Grafana. ¿Qué quieres decir con acciones de Grafana y acciones de Nginx que comentaste el 14 de septiembre de 2017? ¿Tienen algún enlace ambos?

Esperando ansiosamente el lanzamiento de 5.4, supongo.

Logrado hacer esto con éxito en el uso de Grafana auth.proxy y de Nginx ngx_http_secure_link_module

Los enlaces que utilizo tienen el formato http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Una vez que el usuario hace clic en él, se establece la cookie de sesión y el usuario puede navegar por Grafana como si hubiera iniciado sesión normalmente.

Ventajas:

• El enlace caduca después de un tiempo + seguridad
• El enlace genera hash con ID de usuario, marca de tiempo y contraseña + seguridad
• No es necesario escribir contraseña + conveniencia

Mi conf nginx es así

server {
  listen 3001 default_server;
#     listen [::]:3001 default_server;

  server_name _;

        location / {
      set $user "";
      set $state "";

      if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

      secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

No dude en contactarme si necesita ayuda con esto

Hola Nayar
Estoy intentando hacer la integración grafana con SaaS.
El requisito es que después de que el usuario inicie sesión en mi aplicación web y luego haga clic en el enlace 'grafana' en mi página, se redirigirá al panel de grafana sin ingresar el nombre de usuario y la contraseña.

Tu comentario parece cumplir con mi requisito. Pero todavía no tengo claro el proceso de autenticación.
Cuando proxy_pass a grafana, cómo verificar que el usuario esté autenticado por mi propia aplicación.

Mi aplicación web es a través de X-XSRF-TOKEN para verificar la autoridad del usuario.

Soy nuevo en la configuración del servidor. Se agradece su ayuda.

@torkelo / @bergquist Solo un así es como solucionamos esto en Screenly . ¡Está en vivo y funciona muy bien! ¡Gracias por el trabajo duro chicos!

@torkelo / @bergquist Solo un así es como solucionamos esto en Screenly . ¡Está en vivo y funciona muy bien! ¡Gracias por el trabajo duro chicos!

@vpetersson No estoy usando screenly, pero tengo curiosidad por saber cómo pudo implementar esto. Entiendo la generación de un token de API. ¿Todavía tienes un iframe en la URL? ¿Cómo agregaste el token de autenticación en los encabezados de la solicitud?

@GimpMaster Solo usamos el encabezado auth, por lo que no se necesitan iframes. Desde que escribimos el reproductor / navegador, pudimos inyectar el encabezado de autenticación en la carga de la página.

Acabo de hacer que mi modo Kiosco funcione usando el enfoque de Screenly que @GimpMaster vinculó. Utilicé el ModHeader de la extensión de Chrome donde agregué el encabezado de Autorización con la clave de API del portador. Pero como las extensiones necesitan algo de tiempo para cargar los 10 segundos de suspensión, la configuración de un quiosco en raspberry pi hizo el truco. Esta solución también funcionaría para iframes, pero debe configurarse en cada cliente en ese momento.

@Nayar He adaptado con éxito su configuración ngnix sugerida para usar el acceso _unsecure_. Es decir, solo toma el nombre de usuario de la cadena de consulta y lo coloca en X-WEBAUTH-USER. Esto luego obtiene la identificación de sesión de un grafana y nos vamos. ¡Gracias!

No puedo hacer que funcione el método md5. No tengo claro qué es exactamente lo que necesito para hacer una huella digital md5. ¿Podría darme más detalles? ¿Hay algún truco para hacer el md5?

¿Es posible implementar alguna solución para iniciar sesión mediante token / cookie / header / ... en grafana 6. *?

No puedo hacerlo con un panel de enlace simple en un PHP en blanco

index.php

<html>
<body>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js" type="text/javascript"></script>
<script language="javaScript">
$( document ).ready(function() {
$.ajax({
        type: "GET",
        //url: "http://page.test;/grafana/",
        url: "http://page.test;/grafana/d/o24Tt1Cik/dashboard-test?orgId=1",
        contentType: "application/json",
        xhrFields: {
            withCredentials: false
        },
        beforeSend: function(request) {
                     request.setRequestHeader("X-WEBAUTH-USER", "admin");
                },
        headers: {
            // Set any custom headers here.
        "X-WEBAUTH-USER" : "admin"
        },
        success: function(data){
                var iframeDoc = $("#monitoringframe").get(0).contentDocument;
                iframeDoc.open();
                iframeDoc.write(data);
                iframeDoc.close();
//$("#monitoringframe").attr('srcdoc',data)
        },
        error : function(err) {
            console.log('Error!', err)
        }
    });
});

</script>
<iframe name="monitoringframe" id="monitoringframe" src="about:blank" sandbox="allow-forms allow-popups allow-same-origin allow-scripts" width=100% height=600 border="0" frameborder="0" />
</body>
</html>

nginx

 server {
  listen 80;
  server_name page.test;
  root /var/www/page;
  index index.html index.htm index.php;

        location ~ \.php$ {
        fastcgi_pass   127.0.0.1:9000;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
        location /grafana/ {

                proxy_pass http://localhost:3000/;

       }

}

grafana.ini

[auth.proxy]
# Defaults to false, but set to true to enable this feature
enabled = true
# HTTP Header name that will contain the username or email
header_name = X-WEBAUTH-USER
# HTTP Header property, defaults to `username` but can also be `email`
header_property = username
# Set to `true` to enable auto sign up of users who do not exist in Grafana DB. Defaults to `true`.
auto_sign_up = true
# If combined with Grafana LDAP integration define sync interval
ldap_sync_ttl = 60
# Limit where auth proxy requests come from by configuring a list of IP addresses.
# This can be used to prevent users spoofing the X-WEBAUTH-USER header.
# Example `whitelist = 192.168.1.1, 192.168.1.0/24, 2001::23, 2001::0/120`
whitelist = 127.0.0.1, ::1/120
# Optionally define more headers to sync other user attributes
# Example `headers = Name:X-WEBAUTH-NAME Email:X-WEBAUTH-EMAIL`
headers =

[auth.basic]
;enabled = true

Probé cambiar mi configuración de nginx a esto y establecer "? User = myUser" en la URL, pero solo obtengo una respuesta no autorizada

location /grafana/ {

                error_log /var/www/grafana/error.log;
                access_log /var/www/grafana/access.log;

                set $user "";

                if ($args ~ "^user=(.+)") {
                    set $user $1;
                }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://localhost:3000/;

       }

@ mr0bles Todo lo relacionado con el proxy de autenticación se explica en la documentación . No he visto una solución antes en la que llame al proxy con "X-WEBAUTH-USER ; por lo general, se autentica en su proxy, que a su vez completa y proporciona el X-WEBAUTH-USER a grafana.

@marefr gracias por la respuesta.
Leí la documentación y mi API funciona, pero necesito autenticación de usuario dinámica (no el mismo permiso para todos los usuarios de la página)

Esta solución de @Nayar incluye X-WEBAUTH-USER en el encabezado sin codificarlo, pero no puedo hacer que funcione

Creo que algo se rompió en 6.0 o 6.1.
Actualicé una instalación completamente funcional usando auth proxy en Apache2 a 6.1 ayer (desde 5.3) y obtengo exactamente las mismas pantallas que

Tenga en cuenta que Grafana parece entender el encabezado del proxy: inicialmente registra al usuario, pero las solicitudes posteriores obtienen una respuesta 401.

@Bitblade no hemos recibido ningún otro informe similar al suyo. Abra un nuevo informe de error, ya que este problema está relacionado con una solicitud de función.

Logrado hacer esto con éxito en el uso de Grafana auth.proxy y de Nginx ngx_http_secure_link_module

Los enlaces que utilizo tienen el formato http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800

Una vez que el usuario hace clic en él, se establece la cookie de sesión y el usuario puede navegar por Grafana como si hubiera iniciado sesión normalmente.

Ventajas:

• El enlace caduca después de un tiempo + seguridad
• El enlace genera hash con ID de usuario, marca de tiempo y contraseña + seguridad
• No es necesario escribir contraseña + conveniencia

Mi conf nginx es así

server {
  listen 3001 default_server;
#     listen [::]:3001 default_server;

  server_name _;

        location / {
      set $user "";
      set $state "";

      if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

      secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

No dude en contactarme si necesita ayuda con esto

Esta solución no me funciona. Porque creo que cada solicitud debe contener un encabezado X-WEBAUTH-USER válido. No funciona si llena el encabezado en la primera solicitud, obtiene cookies y las acompaña.

Terminé con la siguiente solución:

server {
  listen 80 default_server;
  listen [::]:80 default_server;

  client_max_body_size 10m;
  root /foo/public;

  location /grafana/ {
    auth_request /gauth;
    auth_request_set $user $upstream_http_user;

    proxy_set_header X-WEBAUTH-USER $user;
    proxy_pass http://localhost:4000/;
  }

  location / {
    try_files $uri @app;
  }

  location <strong i="23">@app</strong> {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect  off;
  }
}

Entonces, la solución usa el módulo auth_request nginx. Mi aplicación es responsable del control de acceso (solicitud / gauth) y devuelve el nombre de usuario en el encabezado de respuesta User .

Hola, mientras tanto, puedes usar mi solución que se describe aquí: https://github.com/guysoft/FullPageOS/issues/175

Aquí está mi solución con PHP y la autenticación OAuth genérica de Grafana: https://github.com/nbayramberdiyev/grafana-generic-oauth

Espero que esto te ayudará.

solo quería comentar cómo resolví esto usando http basic auth https://github.com/grafana/grafana/issues/13706#issuecomment -540958284

Debería ser bueno tener un inicio de sesión automático que pase un token de usuario a través de la URL, esta podría ser una solución parcial para incrustar iframes en los sitios.

@rca ¿puedes dar un ejemplo con tu código? Copio tu código y embed.js, pero no funcionó.

Si está utilizando oauth, hay una manera de realizar un grafana incrustado sin un doble inicio de sesión

1. Configure grafana con un único proveedor de oauth y sin otros mecanismos de inicio de sesión
2. Establecer GF_AUTH_OAUTH_AUTO_LOGIN en verdadero
3. Aloje grafana en una subruta y use un proxy inverso para que grafana se sirva en el mismo host que su aplicación principal
4. Conecta tu aplicación principal y grafana al mismo proveedor de oauth (para el proveedor de oauth serán la misma "aplicación")
5. Insertar grafana
6. Cuando se carga el iframe, grafana intentará iniciar sesión automáticamente con oauth (lo que debería tener éxito ya que está en el mismo dominio que su aplicación principal, compartiendo así la misma cookie de autenticación)

EDITAR: Es posible que deba configurar security.cookie_samesite=none en grafana para que esto funcione correctamente en algunos navegadores (esto se debe a que en el iframe, se está produciendo una redirección al proveedor de oauth (dominio diferente) y luego una redirección a su grafana. Actualmente, firefox no permitirá que una cookie del mismo sitio configurada en lax persista de esta manera. https://bugzilla.mozilla.org/show_bug.cgi?id=1454027 lo que significa que grafana pierde su oauth_state cookie si cookie_samesite no está configurado en none )

@seanlaff Probé su solución con AWS Cognito pero devuelve un encabezado que no permite ponerlo en un iframe (X-Frame-Options: deny), ¿algún consejo sobre esto?

Logrado hacer esto con éxito en el uso de Grafana auth.proxy y de Nginx ngx_http_secure_link_module
Los enlaces que utilizo tienen el formato http://grafana/?user=nayar&md5=2tutcea9nfdsfdsfdsw&expires=1505386800
Una vez que el usuario hace clic en él, se establece la cookie de sesión y el usuario puede navegar por Grafana como si hubiera iniciado sesión normalmente.
Ventajas:

• El enlace caduca después de un tiempo + seguridad
• El enlace genera hash con ID de usuario, marca de tiempo y contraseña + seguridad
• No es necesario escribir contraseña + conveniencia

Mi conf nginx es así

server {
    listen 3001 default_server;
#   listen [::]:3001 default_server;

    server_name _;

        location / {
        set $user "";
        set $state "";

        if ($args ~ "^user=(.+)&md5") {
                    set $user $1;
                    set $state "${state}U";
                }

        secure_link $arg_md5,$arg_expires;
                secure_link_md5 "$secure_link_expires$uri$user grafanarocks";

                if ($secure_link = "") { 
                    set $state "${state}S1";
                }

                if ($secure_link = "0") { 
                    set $state "${state}S2";
                }

                add_header X-uristate "$state";

                if ($state = "US1") { return 403; }
                if ($state = "US2") { return 410; }

                add_header X-uri "$user";

                proxy_set_header X-WEBAUTH-USER $user;

                proxy_pass http://127.0.0.1:3000;
            }
    }

No dude en contactarme si necesita ayuda con esto

Esta solución no me funciona. Porque creo que cada solicitud debe contener un encabezado X-WEBAUTH-USER válido. No funciona si llena el encabezado en la primera solicitud, obtiene cookies y las acompaña.

Terminé con la siguiente solución:

server {
  listen 80 default_server;
  listen [::]:80 default_server;

  client_max_body_size 10m;
  root /foo/public;

  location /grafana/ {
    auth_request /gauth;
    auth_request_set $user $upstream_http_user;

    proxy_set_header X-WEBAUTH-USER $user;
    proxy_pass http://localhost:4000/;
  }

  location / {
    try_files $uri @app;
  }

  location <strong i="24">@app</strong> {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-SSL-Client-Cert $ssl_client_cert;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_redirect  off;
  }
}

Entonces, la solución usa el módulo auth_request nginx. Mi aplicación es responsable del control de acceso (solicitud / gauth) y devuelve el nombre de usuario en el encabezado de respuesta User .

¿Cómo se usa con iframe?
soy nuevo en Grafana y NGINX
así que comparte los detalles máximos ahora para modificar

¿Cómo se usa con iframe?

@pgsekaran esta solución no es para iframe, sino para obtener la interfaz de usuario de grafana sin un inicio de sesión explícito de grafana para los usuarios de su aplicación. La aplicación en este caso es un proxy que sabe cómo iniciar sesión en grafana.

Hola,
Gracias por la pronta respuesta. ¿Tiene algún enlace con referencia para agregar Grafana con otra aplicación usando iframe.i agrego Grafana a mi aplicación pero no puedo configurar la administración de uso?
SaludosGuna
El martes 23 de junio de 2020 a las 09:54:57 p.m. GMT + 5: 30, Konstantin Kolotyuk [email protected] escribió:

¿Cómo se usa con iframe?

@pgsekaran esta solución no es para iframe, sino para obtener la interfaz de usuario de grafana sin un inicio de sesión explícito de grafana para los usuarios de su aplicación. La aplicación en este caso es un proxy que sabe cómo iniciar sesión en grafana.

-
Estás recibiendo esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub o cancele la suscripción.

¿Aún no está implementado? En serio, esta es una característica buena para tener.

@pgsekaran tengo una solución para iframe, que no es muy segura porque utiliza un inicio de sesión basado en el nombre de usuario y se basa en que los nombres de usuario no son fáciles de adivinar. Básicamente, el nombre de usuario es el token.
He escrito sobre esto aquí, no con gran detalle, pero eouhg para comenzar
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

@pgsekaran tengo una solución para iframe, que no es muy segura porque utiliza un inicio de sesión basado en el nombre de usuario y se basa en que los nombres de usuario no son fáciles de adivinar. Básicamente, el nombre de usuario es el token.
He escrito sobre esto aquí, no con gran detalle, pero eouhg para comenzar
https://blog.yadamiel.com/tutorials/embed-and-authenticate-grafana-in-a-iframe

Hola,

Necesito configurar con NGINX e iframe con inicio de sesión automático

El problema exacto se explicó en https://github.com/grafana/grafana/issues/16319#issuecomment -483272921: La identificación de sesión no se devuelve con la primera respuesta que contiene la página "esqueleto". Las solicitudes posteriores no contienen el token de inicio de sesión automático, por lo que fallan.

Usamos cromo en modo quiosco para mostrar los paneles de Grafana en varios lugares. Como la misma instancia de Grafana también está disponible para los usuarios, usamos auth.generic_oauth ( auth.basic hasta 5.x) para iniciar sesión en humanos y auth.proxy para iniciar sesión en las máquinas en modo quiosco:

/usr/bin/chromium --app="https://server.localdomain/grafana/d/000000004/002-the-big-picture?orgId=1&refresh=5m&autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE"

Como han señalado otros, esto simplemente no funciona. Lo que funcionaría es llamar primero a la url http://prometheus.localdomain/grafana/login?autologin=lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE (que ahora establece la cookie grafana_session ) y luego redirigir al panel real. Pero ... modo kiosco 🤷 e iframes 🤦‍♂️

Nuestra solución de trabajo final es combinar el parámetro de consulta autologin con una cookie personalizada. Sí, no puede cerrar sesión a través de la GUI ya que la cookie personalizada no se elimina, pero como este mecanismo solo se usa en las máquinas en modo quiosco, no fue necesario.

Así que aquí está la configuración de nginx para Grafana Server:

# this maps tokens to grafana users
map $arg_autologin $autologin {
    lHOrdypkhxzNYb2lRaIjbNPlOCZw9gWE "display-1";
    default "";
}

server {
    listen 80;

    server_name server.localdomain;

    # add_header cannot be used in an "if"-context
    # so we set it to an empty string here as 
    # `add_header Set-Cookie "";` just removes the complete
    # header from the response
    set $setCookieHeader "";

    # when the autologin query param is not set, use
    # the value from the cookie named `grafana_autologin`
    if ($arg_autologin = "") {
        set $arg_autologin $cookie_grafana_autologin;
    }

    # when either the autologin query param or the `grafana_autologin`
    # cookie was set, place the autologin token and the cookie path
    # in the variable. `path=/` is needed to allow deeplinking
    if ($arg_autologin != "") {
        set $setCookieHeader "grafana_autologin=$arg_autologin;path=/";
    }

    location /grafana/ {
        rewrite  ^/grafana/(.*)  /$1 break;

        # now send the Set-Cookie header when an autologin token was provided
        add_header Set-Cookie $setCookieHeader;

        # look up the autologin token in the map above and set the grafana user
        proxy_set_header X-WEBAUTH-USER $autologin;
        proxy_pass http://localhost:3000;
    }
}