Cómo habilitar la autenticación de SAML en Kibana y Elasticsearch

¿Qué es SAML exactamente y por qué estamos emocionados?

Desmitificando de SAML

SAML, que significa Lenguaje de Marcado para Confirmaciones de Seguridad (Security Assertion Markup Language en Inglés), es una norma basada en XML de OASIS que se encarga del intercambio de datos de autenticación y autorización entre partes. Consta de una serie de perfiles que describen diferentes casos de uso de la norma, pero el que es más utilizado es el perfil de inicio de sesión único de explorador web de SAMLS 2.0, que describe el inicio de sesión único de red entre dominios (seguridad).

Existen tres actores involucrados en un flujo de autenticación SAML. El proveedor de identidad (IdP) SAML es una autoridad SAML que tiene la responsabilidad de autenticar usuarios mediante un repositorio de identidad y recuperar información sobre estos usuarios del mismo repositorio de identidad o de otros. Por lo tanto, transmite esta información a un proveedor de servicios SAML mediante mensajes SAML. Un proveedor de servicios (SP) SAML es generalmente un componente o middleware en una aplicación web. Desencadena la solicitud de autenticación a un proveedor de identidad SAML y, luego de la autenticación correcta del usuario, consume el mensaje SAML que el proveedor de identidad envió para recuperar los detalles sobre el evento de autenticación y los mismos usuarios autenticados. Finalmente, utiliza esta información para crear una sesión en el contexto de la aplicación web en la que se está utilizando.

El último de los tres actores es el explorador que utiliza el usuario para acceder a la aplicación, y por lo tanto, el proveedor de servicios y el proveedor de identidad. Toda comunicación en el perfil SSO de navegador web de SAML 2.0 es comunicación de front-end (o canal frontal) y la maneja el explorador de manera explícita. El proveedor de identidad no necesita poder comunicarse directamente con el proveedor de servicios de ninguna manera.

En el siguiente diagrama se ilustran las interacciones entre estos tres actores principales en un flujo de autenticación SSO de explorador web de SAML 2.0. La siguiente leyenda describe los pasos implicados con mayor detalle y brinda observaciones sobre el proceso.

1. El flujo de autenticación generalmente comienza cuando el usuario hace clic en un botón de inicio de sesión o al acceder a una parte de la aplicación web que está asegurada. Como la aplicación web está configurada para la autenticación con SAML, crea un mensaje SAML conocido como solicitud de autenticación de SAML. Como el nombre lo indica, este mensaje es una solicitud al proveedor de identidad para que autentique al usuario.
2. Un mensaje de solicitud de autenticación está comprimido y codificado en Base64, y el explorador del usuario redirige al proveedor de identidad con ese mensaje con un parámetro HTTP GET.
3. Al recibir la solicitud de autenticación, el proveedor de identidad verifica si viene de un proveedor de servicios de confianza y le indica al usuario que efectúe la autenticación, por lo general mediante un formulario de inicio de sesión.
4. El usuario realiza la autenticación con el proveedor de identidad utilizando sus credenciales existentes y, si la autenticación es exitosa, el proveedor de identidad procede a crear un mensaje de respuesta SAML que contiene una aserción SAML. Básicamente, al construir la aserción SAML, el proveedor de identidad afirma que este usuario se ha autenticado satisfactoriamente y se reconoce que tiene ciertas características que se presentan bajo la forma de atributos SAML y sus valores.
5. El proveedor de identidad, entonces, le da al explorador del usuario la instrucción de hacer una solicitud HTTP POST a la URL en donde el proveedor de servicios espera los mensajes de respuesta SAML, llamada «URL de servicio de consumidor de aserciones», con la respuesta SAML codificada en Base64 y la URL en el cuerpo de la solicitud.
6. Finalmente, el proveedor de servicios recibe la respuesta SAML a la solicitud de autenticación SAML que creó originalmente y luego de verificar su autenticidad e integridad, la “consume” para recuperar el hecho de que se ha autenticado al usuario satisfactoriamente y que se ha reconocido la información sobre la identidad de ese usuario bajo la forma de atributos. Luego, transmite esta información a la aplicación web para que cree una sesión para el usuario.

Quizá tenga ahora un par de preguntas en mente: «¿Cómo verifica el proveedor de identidad que la solicitud de autenticación proviene de un proveedor de servicios de confianza?» o «¿cómo puede verificar el proveedor de servicios la autenticidad y la integridad de las respuestas SAML que recibe del proveedor de identidad?».

Bueno, antes de que se pueda intercambiar algún mensaje entre un proveedor de identidad y un proveedor de servicios, uno tiene que saber la configuración de los detalles y las capacidades del otro. Esta configuración y las capacidades se codifican en un documento XML; tales serán los metadatos SAML de la entidad SAML. El documento de metadatos contiene mucha información, pero las partes más importantes son las siguientes:

• Una ID única de la entidad SAML, llamada EntityID
• Una clave pública que otras entidades SAML pueden usar para encriptar mensajes enviados a esta entidad
• Una clave pública que corresponde a la clave privada que usa esta entidad para firmar digitalmente los mensajes enviados a otras entidades
• URL a las que otras entidades pueden enviarles mensajes SAML y los enlaces (detalles de conexión y protocolos específicos) que admite.
• Información sobre la organización que dirige esta entidad y detalles sobre contactos técnicos y soporte

Una vez que las entidades han intercambiado mutuamente metadatos de manera segura, las firmas digitales XML, el cifrado XML y la criptografía se utilizan para proteger la integridad, la autenticidad y la confidencialidad de los mensajes SAML. Por ejemplo, un proveedor de identidad utiliza la clave privada que corresponde a la clave pública que ha publicado en sus metadatos para firmar digitalmente la respuesta SAML que envía a un proveedor de servicios. Luego, el proveedor de servicios puede usar esa clave pública en los metadatos publicados para verificar la firma y así la autenticidad y la integridad de la respuesta.

¿Por qué usar SAML?

Aparte de ser una de las características más solicitadas, ¿por qué estamos entusiasmados por ofrecerle el soporte de la autenticación SAML? O mejor, ¿por qué es una de las características más solicitadas? Las soluciones de inicio de sesión único ofrecen una variedad de beneficios tanto para las organizaciones como para los usuarios. Desde la perspectiva de las organizaciones, ayuda a reducir los riesgos y asiste en los esfuerzos de cumplimiento, ya que las credenciales y la información del usuario se deben almacenar y mantener en un solo lugar. De este modo, es más fácil para la organización proteger y asegurar estos datos del usuario, además de otorgar solicitudes de portabilidad de datos y solicitudes para eliminar datos en el contexto del Reglamento General de Protección de Datos (GDPR). A su vez, mejora la experiencia del usuario, ya que los usuarios deben ingresar las credenciales y sus datos contacto con menor frecuencia. También ayuda a reducir la fatiga de contraseña: mientras menos contraseñas tenga que recordar el usuario, más son las posibilidades de que utilice contraseñas más largas y más complejas. SAML se ha implementado y probado ampliamente en muchas industrias, y sigue siendo una de las normas más populares para implementar soluciones web de inicio de sesión único.

Bueno, me convencieron. Muéstrenme como funciona con Elastic Stack.

SAML y Elastic Stack

En términos de la nomenclatura de SAML 2.0, Elastic Stack en conjunto es un proveedor de servicios compatible con SAML 2.0, que implementa los perfiles de inicio de sesión único y cierre de sesión único del explorador web. Los dos componentes principales de Elastic Stack que contribuyen a la funcionalidad relacionada con SAML son Kibana y Elasticsearch. Kibana, como el componente orientado al usuario, interactúa con el explorador del usuario y recibe todos los mensajes SAML que el proveedor de identidad envía al proveedor de servicios de Elastic Stack. Elasticsearch implementa la mayor parte de la funcionalidad que necesita un proveedor de servicios SAML. Mantiene toda la configuración relacionada con SAML en forma de dominio de autenticación y además genera todos los mensajes SAML necesarios y los transmite a Kibana para que se retransmitan al explorador del usuario. Por último, consume todas las respuestas SAML que Kibana le retransmite, las verifica, extrae la información de autenticación necesaria y crea los token de autenticación interna en base a eso.

Configurar SAML en 9 líneas de configuración

SAML 2.0 ofrece muchas opciones para los implementadores de la norma, y como tal, nuestra configuración tiene una buena cantidad de opciones que pueden configurarse y botones que pueden ajustarse. Dicho esto, se ha realizado un esfuerzo importante en ofrecer una guía integral sobre cómo configurar Elastic Stack para SAML, y en configurar la mayor cantidad posible de valores predeterminados razonables de modo que la configuración necesaria para habilitar SAML sea mínima.

Suponiendo que su proveedor de identidad está en marcha, solo hay dos requisitos previos: TLS para la capa http y el servicio de token se deben habilitar en Elasticsearch.

Una vez resuelto eso, SAML puede configurarse con las siguientes 9 líneas (de ejemplo) en su archivo elasticsearch.yml.

xpack.security.authc.realms.saml1:
   type: saml
   order: 0
   idp.metadata.path: saml/idp-external.xml
   idp.entity_id: "https://idp.myorg.com/"
   sp.entity_id:  "https://kibana.myorg.com/"
   sp.acs: "https://kibana.myorg.com/api/security/v1/saml"
   sp.logout: "https://kibana.myorg.com/logout"
   attributes.principal: "nameid:persistent"

Esta configuración crea un dominio de autenticación SAML con el nombre saml1 con las siguientes propiedades de configuración:

• idp.metadata.path es la ruta del archivo o la URL de https en donde están disponibles los metadatos de su proveedor de identidad.
• idp.entity_id es la EntityID de SAML de su proveedor de identidad. Esto se puede ver desde la página de configuración del proveedor de identidad o sus metadatos de SAML.
• sp.entity_id es la EntityID de SAML de nuestro proveedor de servicios. Esta puede ser cualquier Identificador de recursos uniforme (URI), pero es una buena práctica configurarla en la URL donde Kibana acepta conexiones.
• sp.acs es la URL de servicio de consumidor de aserciones donde Kibana atiende mensajes SAML entrantes. Este debe ser el extremo /api/security/v1/saml de su servidor.
• sp.logout es el extremo de cierre de sesión único donde el proveedor de servicios atiende mensajes SAML entrantes de respuesta de cierre de sesión y solicitud de cierre de sesión. Este debe ser el extremo /logout de su servidor Kibana.
• attributes.principal define qué atributo SAML se asignará al (nombre de usuario) principal del usuario autenticado en Kibana, en este caso usamos el nameid:persistent específico que asignará la NameID con formato urn:oasis:names:tc:SAML:2.0:nameid-format:persistent desde el asunto de la aserción SAML.

Si su proveedor de identidad puede consumir metadatos SAML, entonces se puede crear fácilmente con la herramienta saml-metadata proporcionada que viene con X-Pack. De lo contrario, las únicas piezas de la configuración que su IdP requeriría son la EntityID del proveedor de servicios y la URL de servicio de consumidor de aserciones.

La configuración de Kibana es aún más fácil, ya que solo se deben configurar dos parámetros:

xpack.security.authProviders: [saml]
server.xsrf.whitelist: [/api/security/v1/saml]

basic se puede agregar a la lista de authProviders si queremos permitir que los usuarios también inicien sesión a través del dominio nativo, lo cual puede resultar práctico para el acceso administrativo y como un mecanismo de autenticación de reserva en caso de que el proveedor de identidad no responda. La falsificación de petición en sitios cruzados se debe deshabilitar para la URL de servicio de consumidor de aserciones, ya que la respuesta SAML llegará como una petición de sitio cruzado legítima. No obstante, Elasticsearch validará el contenido de la solicitud antes de consumirlo.

Eso es todo. Al reiniciar Elasticsearch y Kibana, se habilitará la autenticación SAML y al entrar a Kibana se iniciará el flujo de autenticación que describimos anteriormente. ¿Quién dijo que SAML era difícil?

Pruébelo con la última versión de la Elastic Stack.