Uso de Azure AD como proveedor de identidad para OpenSearch Dashboards en Amazon OpenSearch Service

Por Luciano Bernardes, Arquitecto de Soluciones Senior para Partners en AWS
Caio Cesar, Especialista en Microsoft en AWS
Rafael Gumiero, Arquitecto de Soluciones Senior para Analytics en AWS
Robert da Costa, Arquitecto de Soluciones Senior en AWS

¿Qué vamos a discutir en este blog?

Abordemos la integración de OpenSearch Dashboards con un proveedor de identidad, utilizando el estándar SAML 2.0, en un entorno de laboratorio. En los entornos corporativos, es común que las empresas ya tengan un proveedor de identidad para centralizar la autenticación y la autorización de sus aplicaciones/proveedores de servicios, con el objetivo de la seguridad y la operatividad.

Amazon OpenSearch Service

Amazon OpenSearch Service facilita la realización de análisis de registros interactivos, el monitoreo de aplicaciones en tiempo real, la búsqueda en sitios web y más. OpenSearch es un conjunto distribuido de investigación y análisis de código abierto derivado de Elasticsearch. Amazon OpenSearch Service ofrece las últimas versiones de OpenSearch, soporte para 19 versiones de Elasticsearch (versiones 1.5 a 7.10) y funciones de vista previa proporcionadas por OpenSearch Dashboards y Kibana (versiones 1.5 a 7.10).

Proveedor de servicios de identidad (IdP) y proveedor de servicios (SP)

Un proveedor de identidad (IdP) es un socio de la federación que evalúa y confirma la identidad de un usuario y puede usar patrones de intercambio de datos, como SAML 2.0. De esta manera, el IdP autentica al usuario y proporciona un token de autenticación al proveedor de servicios. En el caso de este artículo, el IdP en cuestión es Azure AD.

Y el proveedor de servicios (SP) en sí mismo es un socio de la federación, que proporciona los servicios a los usuarios. El SP depende del IdP para probar la identidad del usuario que intenta acceder a sus recursos. En el caso de este artículo, el SP en cuestión es OpenSearch Dashboards.

OpenSearch Dashboards y SAML 2.0

La autenticación SAML para OpenSearch Dashboards le permite utilizar su proveedor de identidad existente para proporcionar inicio de sesión único (SSO) en dominios de Amazon OpenSearch Service que ejecutan OpenSearch o Elasticsearch 6.7 o posterior. Para usar la autenticación SAML, debemos habilitar un control de acceso detallado. No puede habilitar un control de acceso detallado en los dominios existentes, solo en los nuevos. Por extensión, esto significa que solo puede habilitar la autenticación SAML en dominios nuevos o dominios existentes que ya tengan habilitado el control de acceso detallado.

Requisitos

Este blog describe las tareas para configurar la integración de OpenSearch Dashboards con Azure AD, por lo que los siguientes puntos ya se aprovisionaron en nuestro laboratorio:

Dominio de Amazon OpenSearch Service (nota mencionada en OpenSearch Dashboards y SAML 2.0)
Control de acceso detallado (FGAC) habilitado
Directorio de Azure Active Directory

Tareas para realizar la integración

En el dominio de Amazon OpenSearch Service, activamos el estándar SAML 2.0. En el dominio ya creado, fuimos a la pestaña «Configuración de seguridad» y hacemos clic en «Editar»:

En el área «Autenticación SAML para OpenSearch Dashboards/Kibana», marque la opción «Habilitar autenticación SAML» y tome nota de las tres URL indicadas en el área «Configurar proveedor de identidad (IdP)»:

En el lado de Azure AD de nuestro laboratorio, creamos una aplicación empresarial personalizada. Por lo tanto, en la página del IdP hacemos clic en «Aplicaciones empresariales» y luego en «Todas las aplicaciones\ Nueva aplicación»:

En la galería con las aplicaciones disponibles, hacemos clic en «Crear tu propia aplicación»:

En la diapositiva abierta del lado derecho, llenamos la aplicación con un nombre fácilmente identificable, marcamos la opción «Integrar cualquier otra aplicación que no encuentre en la galería (no en la galería)» y haga clic en «Crear»:

Una vez creada la aplicación, era necesario realizar algunos ajustes de permisos para los usuarios y/o grupos y reconocer OpenSearch Dashboards como un proveedor de servicios. Por lo tanto, abrimos la aplicación y fuimos a «Usuarios y grupos\ Agregar usuario/grupo»:

Nota: Para que los grupos se utilicen en esta integración, evalúe las características de Azure AD Premium.

En la siguiente pantalla, seleccionamos usuarios y grupos que deberían tener acceso a la aplicación y, en consecuencia, podrían realizar el inicio de sesión único para OpenSearch Dashboards. A continuación hacemos clic en «Asignar»:

Una vez realizada la asignación de usuarios y/o grupos, pudimos ver la aplicación disponible iniciando sesión con ellos en https://myapplications.microsoft.com:

Volviendo a la configuración de la aplicación en Azure AD, era necesario realizar ajustes en el estándar SAML 2.0, lo que permitía la integración con los paneles de OpenSearch. Entonces, fuimos a «Single Sign-On» y hicimos clic en «SAML»:

En la siguiente pantalla, hacemos clic en «Editar» en la sección «Configuración básica de SAML»:

Con las notas que se tomaron al principio del procedimiento, disponibles en la consola de Amazon OpenSearch Service, rellenamos los campos disponibles en la siguiente pantalla como se muestra a continuación y hacemos clic en «Guardar»:

Campo en Azure AD	Valor de la consola de Amazon OpenSearch Service
Identificador (ID de entidad)	ID de entidad de proveedor de servicios
URL de respuesta (URL de servicio al consumidor de afirmaciones)	URL de SSO iniciada por SP
Inicie sesión en la URL	URL de paneles de OpenSearch o URL de paneles personalizados de OpenSearch

La configuración era similar a la de la imagen de abajo:

Una vez completado este paso, descargamos el archivo XML de metadatos de federación para completar la configuración en el lado de Amazon OpenSearch Service:

En la consola de Amazon OpenSearch Service, volvimos a la sección de edición de los atributos SAML e hicimos «Importar desde archivo XML», apuntando al archivo que se descargó en el paso anterior:

Con la importación de archivos, el campo «ID de entidad de IdP» se completó automáticamente (el formato XML puede variar):

En esta misma pantalla, tenemos dos configuraciones indicadas como «nombre de usuario maestro SAML» y «rol de backend maestro SAML». Completamos estos campos con un usuario y un grupo de Azure AD, lo que otorga a los paneles de OpenSearch acceso maestro a través del inicio de sesión único, siendo efectivamente un administrador de servicios. Una vez configurado, puede usar este usuario/grupo para realizar la administración de objetos en Amazon OpenSearch Service, creando otras funciones u otros usuarios vinculados a Azure AD.

Nota: El «usuario maestro» tiene todos los permisos de administración del dominio de Amazon OpenSearch Service. Es el primer usuario que se crea al crear un dominio de Amazon OpenSearch Service.

Para ello, agregamos el valor de atributo Nombre principal de usuario (UPN) de un usuario y el Nombre de grupo de un grupo (puede ser uno u otro) que tiene permiso en la aplicación empresarial Azure Active Directory de nuestro laboratorio, como se muestra a continuación:

Como prueba, dejamos la Política de acceso de nuestro dominio de Amazon OpenSearch Service como un nivel de dominio publicado para cualquier objeto autenticado.Para ello, agregamos el valor de atributo Nombre principal de usuario (UPN) de un usuario y el Nombre de grupo de un grupo (puede ser uno u otro) que tiene permiso en la aplicación empresarial Azure Active Directory de nuestro laboratorio, como se muestra a continuación:

Nota: La seguridad de Amazon OpenSearch Service tiene tres capas principales:

Red
La primera capa de seguridad es la red, que determina si las solicitudes pueden llegar a un dominio de Amazon OpenSearch Service. Puede optar por aprovisionar su dominio de Amazon OpenSearch Service con acceso público o solo conexiones que se originen en una VPC.

Política de acceso al dominio
La segunda capa de seguridad es la política de acceso al dominio. Una vez que una solicitud llega a un punto final de dominio, la política de acceso basada en recursos permite o deniega el acceso de la solicitud a un URI en particular. La política de acceso acepta o rechaza las solicitudes en el «borde» del dominio antes de que lleguen al servicio de Amazon OpenSearch.

Control de acceso detallado — FGAC
La tercera y última capa de seguridad es el control de acceso refinado, el FGAC. Después de que una política de acceso basada en recursos permite que una solicitud llegue a un punto de enlace de dominio, el FGAC inicia el proceso de autenticación de usuarios. Si FGCA autentica correctamente al usuario, recupera todos los permisos asignados a ese usuario.

Al final de estos pasos, hacemos clic en «Guardar cambios» en la parte inferior de la página:

Con estas configuraciones realizadas, utilizando el usuario o el miembro del grupo, fue posible acceder a los paneles de OpenSearch a través de SSO, con la credencial de Azure AD. Para hacer esto, se puede acceder a través de la aplicación en https://myapplications.microsoft.com, como se indicó anteriormente, o a través de la «URL de paneles de OpenSearch»/«URL de paneles de OpenSearch personalizados» (por ejemplo, https://myopensearch.mydomain.com). En ambos casos, la solicitud de autenticación se dirigió a Azure AD mediante el estándar SAML.

Una vez que iniciamos sesión, estábamos con un usuario autorizado para realizar otras configuraciones pertinentes, como registrar nuevos usuarios y/o grupos de Azure AD con roles en OpenSearch Dashboards, manejando así la autorización de acuerdo con sus necesidades.

Nota: Los Tenants de OpenSearch Dashboards son espacios para guardar patrones de índice, visualizaciones, paneles y otros objetos de OpenSearch Dashboards. De forma predeterminada, todos los usuarios de OpenSearch Dashboards tienen acceso a dos Tenants: Privado y global. El Tenant global se comparte entre todos los usuarios de OpenSearch Dashboards. El Tenant privado es único para cada usuario y no se puede compartir.

Los Tenants son útiles para compartir su trabajo de forma segura con otros usuarios de OpenSearch Dashboards. Puede controlar qué funciones tienen acceso a un Tenant y si esas funciones tienen acceso de lectura o escritura.

Puede usar el Tenant privado para trabajos exploratorios, crear visualizaciones detalladas con su equipo en un Tenant analista y mantener un panel de resumen para el liderazgo corporativo en un Tenant ejecutivo.

¡Listo! Integramos OpenSearch Dashboards con el proveedor de identidades de Azure Active Directory.

Para administrar los objetos, simplemente acceda al menú Security\ Roles:

Creamos un nuevo rol:

Después de la creación, seleccionamos la pestaña «Usuarios asignados», opción «Usuarios del mapa»:

Agregamos el UPN del usuario a los Usuarios (o al grupo en «Funciones de backend»):

Se agregó el inicio de sesión con el nuevo usuario:

En esta publicación de blog, analizamos la integración de OpenSearch Dashboards con Azure AD a través del estándar SAML 2.0, destacando una alternativa para que las empresas realicen un seguimiento de las credenciales de ese servicio a través del proveedor de identidad de su elección.

Referencias

Este artículo fue traducido del Blog de AWS en Portugues.

Sobre los autores

Luciano Bernardes trabaja actualmente como Sr. Partner Solutions Architect (PSA) en AWS, especializándose en cargas de trabajo de Microsoft. Con 15 años de experiencia en el mercado, trabajó principalmente en consultoría técnica especializada en Microsoft, en clientes de varias verticales, con demandas centradas en la infraestructura local y en la nube. Como PSA, trabaja en estrecha colaboración con los socios consultores de LATAM para ayudarlos a potenciar y escalar las tecnologías de Microsoft en la nube de AWS.

Caio Ribeiro César trabaja actualmente como especialista en ventas especializado en tecnología de Microsoft en la nube de AWS. Comenzó su carrera profesional como administrador de sistemas, que continuó durante más de 15 años en áreas como Seguridad de la Información, Identidad en línea y Plataformas de correo electrónico corporativo. Recientemente se convirtió en un fanático de la informática en la nube de AWS y ayuda a los clientes a aprovechar el poder de la tecnología de Microsoft en AWS.

Robert Costa es un Arquitecto Senior de Soluciones que ha trabajado durante más de 20 años en el área de tecnología en empresas del sector financiero, habiendo participado en varios proyectos de modernización. Hoy se dedica a mejorar a los clientes que buscan innovación mediante el uso de servicios en la nube de AWS. También le encanta viajar con familiares y amigos para disfrutar de su tiempo libre junto al mar.

Rafael Gumiero es arquitecto sénior de soluciones analíticas en Amazon Web Services. Un entusiasta de los sistemas distribuidos y de código abierto brinda orientación a los clientes que desarrollan sus soluciones con los servicios de AWS Analytics, lo que les ayuda a optimizar el valor de sus soluciones.

Blog de Amazon Web Services (AWS)