Integración de agentes de ActiveMQ con LDAP

importante

La integración de LDAP no es compatible con los agentes de RabbitMQ.

Para acceder a sus agentes de ActiveMQ, puede utilizar los siguientes protocolos con TLS habilitado:

• AMQP

• MQTT

• MQTT a través de WebSocket

• OpenWire

• STOMP

• STOMP a través de WebSocket

Amazon MQ ofrece la posibilidad de elegir entre la autenticación nativa de ActiveMQ y la autenticación y autorización de LDAP para administrar los permisos de usuario. Para obtener información sobre las restricciones relacionadas con nombres de usuario y contraseñas de ActiveMQ, consulte Usuarios.

Para permitir que los usuarios y grupos de ActiveMQ trabajen con colas y temas, debe editar la configuración del agente. Amazon MQ utiliza el complemento de autenticación simple de ActiveMQ para restringir la lectura y la escritura en los destinos. Para obtener más información y ejemplos, consulte Configurar siempre una asignación de autorizaciones y authorizationEntry.

nota

Actualmente, Amazon MQ no admite la autenticación de certificados de cliente.

Integrar LDAP con ActiveMQ

Puede autenticar usuarios de Amazon MQ a través de las credenciales almacenadas en su servidor de protocolo ligero de acceso a directorios (LDAP). También puede agregar, eliminar y modificar usuarios de Amazon MQ, y asignar permisos para temas y colas a través de él. Las operaciones de administración, como la creación, actualización y eliminación de agentes, aún requieren credenciales de IAM y no están integradas con LDAP.

Los clientes que deseen simplificar y centralizar la autenticación y autorización de los agentes de Amazon MQ mediante un servidor LDAP pueden utilizar esta característica. Mantener todas las credenciales de usuario en el servidor LDAP ahorra tiempo y esfuerzo, ya que proporciona una ubicación central donde almacenar y administrar estas credenciales.

Amazon MQ es compatible con LDAP si se utiliza el complemento JAAS de Apache ActiveMQ. Amazon MQ también admite cualquier servidor LDAP, como Microsoft Active Directory u OpenLDAP, que sea compatible con el complemento. Para obtener más información acerca del complemento, consulte la sección Seguridad de la documentación de ActiveMQ.

Además de los usuarios, puede especificar el acceso a temas y colas para un grupo específico o un usuario a través del servidor LDAP. Para ello, cree entradas que representen temas y colas en el servidor LDAP y, a continuación, asigne permisos a un usuario o grupo de LDAP específico. A continuación, puede configurar el agente para que recupere los datos de autorización del servidor LDAP.

Requisitos previos

Antes de agregar compatibilidad con LDAP a un agente de Amazon MQ nuevo o existente, debe configurar una cuenta de servicio. Esta cuenta de servicio es necesaria para iniciar una conexión con un servidor LDAP y debe tener los permisos correctos para realizar esta conexión. Esta cuenta de servicio configurará la autenticación LDAP para su agente. Todas las conexiones de cliente posteriores se autenticarán a través de la misma conexión.

La cuenta de servicio es una cuenta del servidor LDAP que tiene acceso para iniciar una conexión. Es un requisito estándar de LDAP, y debe proporcionar las credenciales de la cuenta de servicio una sola vez. Una vez configurada la conexión, todas las conexiones de cliente futuras se autentican a través del servidor LDAP. Las credenciales de su cuenta de servicio se almacenan de forma segura en un formato cifrado, al que solo puede acceder Amazon MQ.

Para integrarse con ActiveMQ, se requiere un árbol de información de directorios (DIT) específico en el servidor LDAP. Para ver un archivo ldif de ejemplo que muestra claramente esta estructura, consulte Importar el siguiente archivo LDIF en el servidor LDAP en la sección Seguridad de la documentación de ActiveMQ.

Introducción a LDAP

Para empezar, vaya a la consola de Amazon MQ y elija LDAP authentication and authorization (Autenticación y autorización LDAP) cuando cree una nueva instancia de agente de Amazon MQ o edite una existente.

Proporcione la siguiente información acerca de la cuenta de servicio:

• Fully qualified domain name (Nombre de dominio completo): la ubicación del servidor LDAP al que se emitirán las solicitudes de autenticación y autorización.

  nota

  El nombre de dominio completo del servidor LDAP que proporcione no debe incluir el protocolo ni el número de puerto. Amazon MQ antepondrá el protocolo ldaps al nombre de dominio completo y agregará el número de puerto 636.

  Por ejemplo, si proporciona el dominio completo example.com, Amazon MQ accederá a su servidor LDAP mediante la siguiente URL: ldaps://example.com:636.

  Para que el anfitrión del agente pueda comunicarse correctamente con el servidor LDAP, el nombre de dominio completo debe poder resolverse públicamente. Para mantener el servidor LDAP privado y seguro, restrinja el tráfico entrante a través de las reglas de entrada del servidor de tal modo que solo permitan el tráfico originado desde la VPC del agente.

• Service account username (Nombre de usuario de la cuenta de servicio): nombre distintivo del usuario que se utilizará para realizar el enlace inicial al servidor LDAP.

• Service account password (Contraseña de la cuenta de servicio): contraseña del usuario que realiza el enlace inicial.

En la siguiente imagen, se resaltan los campos donde se proporcionan estos detalles.

En la sección LDAP login configuration (Configuración de inicio de sesión de LDAP), proporcione la siguiente información obligatoria:

• User Base (Base de usuarios): nombre distintivo del nodo del árbol de información de directorios (DIT) en el que se van a buscar los usuarios.

• User Search Matching (Criterios de búsqueda de usuarios): filtro de búsqueda LDAP que se utilizará para buscar usuarios dentro de la userBase. El nombre de usuario del cliente se sustituye en el marcador de posición {0} del filtro de búsqueda. Para obtener más información, consulte Autenticación y Autorización.

• Role Base (Base de roles): nombre distintivo del nodo del DIT en el que se van a buscar los roles. Los roles se pueden configurar como entradas explícitas de grupos LDAP en el directorio. Una entrada de rol típica puede consistir en un atributo para el nombre del rol, como nombre común (CN), y otro atributo, como member, con valores que representan los nombres distintivos o los nombres de usuario de los usuarios que pertenecen al grupo de roles. Por ejemplo, dada la unidad organizativa, que es group, puede proporcionar el siguiente nombre distintivo: ou=group,dc=example,dc=com.

• Role Search Matching (Criterios de búsqueda de roles): filtro de búsqueda de LDAP que se utilizará para buscar roles dentro de la roleBase. El nombre distintivo del usuario que coincide con userSearchMatching se sustituye en el marcador de posición {0} del filtro de búsqueda. El nombre de usuario del cliente se sustituirá por el marcador de posición {1}. Por ejemplo, si las entradas de roles del directorio incluyen un atributo con el nombre member, que contiene los nombres de usuario de todos los usuarios de ese rol, puede proporcionar el siguiente filtro de búsqueda: (member:=uid={1}).

En la siguiente imagen, se resaltan los campos donde se especifican estos detalles.

En la sección Optional settings (Configuración opcional), puede proporcionar la siguiente información opcional:

• User Role Name (Nombre del rol del usuario): nombre del atributo de LDAP que se indica en la entrada del directorio del usuario para la pertenencia al grupo del usuario. En algunos casos, los roles de usuario pueden identificarse por el valor de un atributo en la entrada del directorio del usuario. La opción userRoleName permite proporcionar el nombre de este atributo. Por ejemplo, consideremos la siguiente entrada de usuario:

  dn: uid=jdoe,ou=user,dc=example,dc=com
  objectClass: user
  uid: jdoe
  sn: jane
  cn: Jane Doe
  mail: [e-mail]
  memberOf: role1
  userPassword: password

  Para proporcionar el userRoleName correcto para el ejemplo anterior, debería especificar el atributo memberOf. Si la autenticación se realiza correctamente, al usuario se le asigna el rol role1.

• Role Name (Nombre del rol): atributo de nombre de grupo en una entrada de rol cuyo valor es el nombre de ese rol. Por ejemplo, se puede especificar cn como el nombre común de una entrada de grupo. Si la autenticación se realiza correctamente, se asigna al usuario el valor del atributo cn para cada entrada de rol de la que sea miembro.

• User Search Subtree (Subárbol de búsqueda de usuarios): define el ámbito de la consulta de búsqueda de usuario de LDAP. Si es verdadero, el ámbito se configura para que la búsqueda se realice en todo el subárbol bajo el nodo definido por userBase.

• Role Search Subtree (Subárbol de búsqueda de roles): define el ámbito de la consulta de búsqueda de roles de LDAP. Si es verdadero, el ámbito se configura para que la búsqueda se realice en todo el subárbol bajo el nodo definido por roleBase.

En la siguiente imagen, se resalta, los campos donde se especifica esta configuración opcional.

Cómo funciona la integración de LDAP

La integración se puede pensar en dos categorías principales: la estructura para la autenticación y la estructura para la autorización.

Autenticación

Para la autenticación, las credenciales del cliente deben ser válidas. Estas credenciales se validan contra los usuarios de la base de usuarios del servidor LDAP.

La base de usuarios que se le proporciona al agente de ActiveMQ debe apuntar al nodo del DIT donde se almacenan los usuarios en el servidor LDAP. Por ejemplo, si está utilizando AWS Managed Microsoft AD y tiene los componentes de dominio corp, example, y com que contienen las unidades organizativas corp y Users, usaría lo siguiente como base de usuarios:

OU=Users,OU=corp,DC=corp,DC=example,DC=com
                

El agente de ActiveMQ buscaría usuarios en esta ubicación del DIT para autenticar las solicitudes de conexión del cliente con el agente.

Como el código fuente de ActiveMQ codifica el nombre del atributo de los usuarios como uid, debe asegurarse de que cada usuario tenga este atributo configurado. Para simplificar, puede usar el nombre de usuario de la conexión del usuario. Para obtener más información, consulte el código fuente activemq y la configuración de mapeos de ID en usuarios y equipos de Active Directory para Windows Server 2016 (y versiones posteriores).

Para habilitar el acceso de determinado usuarios a la consola de ActiveMQ, asegúrese de que pertenecen al grupo amazonmq-console-admins.

Autorización

Para la autorización, las bases de búsqueda de permisos se especifican en la configuración del agente. La autorización se realiza por destino (o comodín, conjunto de destinos) a través del elemento cachedLdapAuthorizationMap, que se encuentra en el archivo de configuración activemq.xmldel agente. Para obtener más información, consulte el Módulo de autorización LDAP en caché.

nota

Para poder utilizar el elemento cachedLDAPAuthorizationMap del archivo de configuración activemq.xml del agente, debe elegir la opción LDAP Authentication and Authorization (Autenticación y autorización LDAP) cuando cree una configuración a través de la AWS Management Console, o configurar la propiedad authenticationStrategy como LDAP cuando cree una nueva configuración mediante la API de Amazon MQ.

Debe proporcionar los siguientes tres atributos como parte del elemento cachedLDAPAuthorizationMap:

• queueSearchBase

• topicSearchBase

• tempSearchBase

importante

Para evitar que la información confidencial se coloque directamente en el archivo de configuración del agente, Amazon MQ bloquea el uso de los siguientes atributos en cachedLdapAuthorizationMap:

• connectionURL

• connectionUsername

• connectionPassword

Cuando crea un agente, Amazon MQ sustituye los valores que proporciona a través de la AWS Management Console o en la propiedad ldapServerMetadata de su solicitud de API, para los atributos anteriores.

En el siguiente ejemplo, se muestra un ejemplo práctico de cachedLdapAuthorizationMap.

<authorizationPlugin>
    <map>
        <cachedLDAPAuthorizationMap
            queueSearchBase="ou=Queue,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            topicSearchBase="ou=Topic,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            tempSearchBase="ou=Temp,ou=Destination,ou=corp,dc=corp,dc=example,dc=com"
            refreshInterval="300000"
            legacyGroupMapping="false"
        />
    </map>
</authorizationPlugin> 

Estos valores identifican las ubicaciones dentro del DIT donde se especifican los permisos para cada tipo de destino. Por lo tanto, para el ejemplo anterior con AWS Managed Microsoft AD, utilizando los mismos componentes de dominio de corp, example y com, debería especificar una unidad organizativa con el nombre destination para que contenga todos los tipos de destino. Dentro de esa unidad organizativa, debería crear uno para el destino queues, uno para topics y uno para temp.

Esto significaría que su base de búsqueda de colas, que proporciona información de autorización para destinos de tipo cola, tendría la siguiente ubicación en su DIT:

OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
                

Del mismo modo, las reglas de permisos para temas y destinos temporales se ubicarían en el mismo nivel en el DIT:

OU=Topic,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
OU=Temp,OU=Destination,OU=corp,DC=corp,DC=example,DC=com
            

Dentro de la unidad organizativa de cada tipo de destino (cola, tema, destino temporal), se puede proporcionar un comodín o un nombre de destino específico. Por ejemplo, para proporcionar una regla de autorización para todas las colas que comiencen con el prefijo DEMO.EVENTS.$., puede crear la siguiente unidad organizativa:

OU=DEMO.EVENTS.$,OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com

nota

La unidad organizativa DEMO.EVENTS.$ está dentro de la unidad organizativa Queue.

Para obtener más información acerca de comodines en ActiveMQ, consulte Caracteres comodín

Para proporcionar reglas de autorización para colas específicas, como DEMO.MYQUEUE, incluya una especificación similar a la siguiente:

OU=DEMO.MYQUEUE,OU=Queue,OU=Destination,OU=corp,DC=corp,DC=example,DC=com

Grupos de seguridad

Dentro de cada unidad organizativa que representa un destino o un comodín, debe crear tres grupos de seguridad. Como sucede con todos los permisos de ActiveMQ, estos son permisos de lectura/escritura/administrador. Para obtener más información acerca de lo que permite a un usuario cada uno de estos permisos, consulte Seguridad en la documentación de ActiveMQ.

Debe asignar un nombre a estos grupos de seguridad read, write yadmin. Dentro de cada uno de estos grupos de seguridad, puede agregar usuarios o grupos, que tendrán permiso para realizar las acciones asociadas. Necesitará estos grupos de seguridad para cada conjunto de destinos comodín o destino individual.

nota

Cuando cree el grupo administrador, se generará un conflicto con el nombre del grupo. Este conflicto se produce porque las reglas heredadas anteriores a Windows 2000 no permiten que los grupos compartan el mismo nombre, aunque se encuentren en diferentes ubicaciones del DIT. El valor que se muestra en el cuadro de texto Pre-Windows 2000 (Anterior a Windows 2000) no tiene ningún impacto sobre la configuración, pero debe ser único global. Para evitar este conflicto, puede agregar un sufijo uuid a cada grupo admin.

Si agrega un usuario al grupo de seguridad admin para un destino determinado, el usuario podrá crear y eliminar ese tema. Si lo agrega al grupo de seguridad read, podrá leer desde el destino, y si lo agrega al grupo write, podrá escribir allí.

Además de agregar usuarios individuales a los permisos de grupos de seguridad, también puede agregar grupos completos. Sin embargo, como ActiveMQ codifica los nombres de los atributos para los grupos, debe asegurarse de que el grupo que desea agregar tenga la clase de objeto groupOfNames, como se muestra en el código fuente activemq.

Para hacerlo, realice el mismo proceso que empleó con uid para los usuarios. Consulte Configuración de mapeos de ID en Usuarios y equipos de Active Directory para Windows Server 2016 (y versiones posteriores).