Intégration des agents ActiveMQ avec LDAP

Important

L'intégration LDAP n'est pas prise en charge pour les agents RabbitMQ.

Vous pouvez accéder à vos agents ActiveMQ en utilisant les protocoles suivants avec TLS activé :

• AMQP

• MQTT

• MQTT via WebSocket

• OpenWire

• STOMP

• STOMP via WebSocket

Amazon MQ offre un choix entre l'authentification ActiveMQ native et l'authentification LDAP et l'autorisation pour gérer les autorisations utilisateur. Pour plus d'informations sur les restrictions liées aux noms d'utilisateur et aux mots de passe ActiveMQ, consultez Users.

Pour autoriser des utilisateurs et des groupes ActiveMQ à utiliser des files d'attente et des rubriques, vous devez modifier la configuration de votre agent. Amazon MQ utilise le plugin Simple Authentication d'ActiveMQ pour limiter la lecture et l'écriture aux destinations. Pour plus d'informations et d'exemples, consultez Toujours configurer un plan d'autorisation et authorizationEntry.

Note

Actuellement, Amazon MQ ne prend pas en charge l'authentification par certificat client.

Intégrer LDAP avec ActiveMQ

Vous pouvez authentifier les utilisateurs Amazon MQ à l'aide des informations d'identification stockées dans votre Active Directory ou un autre serveur LDAP. Vous pouvez également ajouter, supprimer et modifier des utilisateurs Amazon MQ et attribuer des autorisations aux rubriques et aux files d'attente. Les opérations de gestion telles que la création, la mise à jour et la suppression des agents nécessitent toujours des informations d'identification IAM et ne sont pas intégrées à LDAP.

Les clients qui souhaitent simplifier et centraliser leur authentification et leur autorisation d'agent Amazon MQ à l'aide d'un serveur LDAP peuvent utiliser cette fonctionnalité. La conservation de toutes les informations d'identification utilisateur sur le serveur LDAP permet d'économiser du temps et des efforts en fournissant un emplacement central pour stocker et gérer ces informations d'identification.

Amazon MQ fournit la prise en charge LDAP à l'aide du plugin Apache ActiveMQ JAAS. Tout serveur LDAP, tel que Microsoft Active Directory ou OpenLDAP pris en charge par le plugin, est également pris en charge par Amazon MQ. Pour de plus amples informations sur le plugin, veuillez consulter la section Sécurité de la documentation ActiveMQ.

Outre les utilisateurs, vous pouvez spécifier l'accès aux rubriques et aux files d'attente pour un groupe spécifique ou un utilisateur via votre serveur LDAP. Pour ce faire, créez des entrées représentant des rubriques et des files d'attente dans votre serveur LDAP, puis attribuez des autorisations à un utilisateur LDAP spécifique ou à un groupe. Vous pouvez ensuite configurer l'agent pour récupérer les données d'autorisation à partir du serveur LDAP.

Prérequis

Avant d'ajouter la prise en charge LDAP à un agent Amazon MQ nouveau ou existant, vous devez configurer un compte de service. Ce compte de service est requis pour initier une connexion à un serveur LDAP et doit disposer des autorisations appropriées pour établir cette connexion. Ce compte de service configurera l'authentification LDAP pour votre agent. Toutes les connexions client successives seront authentifiées via la même connexion.

Un compte de service est un compte de votre serveur LDAP qui a accès afin d'initier une connexion. Il s'agit d'une exigence LDAP standard et vous ne devez fournir les informations d'identification du compte de service qu'une seule fois. Une fois la connexion configurée, toutes les futures connexions client sont authentifiées via votre serveur LDAP. Les informations d'identification de votre compte de service sont stockées de manière sécurisée sous une forme chiffrée, accessible uniquement à Amazon MQ.

Pour intégrer ActiveMQ, une arborescence d'informations d'annuaire (DIT) spécifique est requise sur le serveur LDAP. Pour un exemple de fichier ldif qui montre clairement cette structure, consultez Import the following LDIF file into the LDAP server (Importer le fichier LDIF suivant dans le serveur LDAP) dans la section Security (Sécurité) de la documentation ActiveMQ.

Mise en route avec LDAP

Pour commencer, accédez à la console Amazon MQ et choisissez LDAP authentication and authorization (Authentification et autorisation LDAP) lorsque vous créez une instance d'agent existante ou nouvelle Amazon MQ.

Fournissez les informations suivantes sur le compte de service :

• Fully qualified domain name (Nom de domaine entièrement qualifié) : Emplacement du serveur LDAP auquel les demandes d'authentification et d'autorisation doivent être émises.

  Note

  Le nom de domaine complet du serveur LDAP que vous fournissez ne doit pas inclure le numéro de protocole ou de port. Amazon MQ va ajouter le nom de domaine complet au protocole ldaps, et ajoutera le numéro de port 636.

  Par exemple, si vous fournissez le domaine complet suivant example.com, Amazon MQ accède à votre serveur LDAP à l'aide de l'URL suivante : ldaps://example.com:636.

  Pour que l'hôte de l'agent puisse communiquer avec le serveur LDAP, le nom de domaine complet doit pouvoir être résolu publiquement. Pour garder le serveur LDAP privé et sécurisé, limitez le trafic entrant dans les règles entrantes du serveur afin d'autoriser uniquement le trafic provenant du VPC de l'agent.

• Service account username (Nom d'utilisateur du compte de service) Nom unique de l'utilisateur qui sera utilisé pour effectuer la liaison initiale au serveur LDAP.

• Service account password (Mot de passe du compte de service) Mot de passe de l'utilisateur effectuant la liaison initiale.

L'image suivante met en évidence où fournir ces détails.

Dans la section LDAP login configuration (Configuration de la connexion LDAP), fournissez les informations requises suivantes :

• User Base (Base d'utilisateurs) Nom unique du nœud de l'arborescence des informations de répertoire (DIT) qui sera recherché pour les utilisateurs.

• User Search Matching (Recherche d'utilisateur) Filtre de recherche LDAP qui sera utilisé pour rechercher des utilisateurs dans userBase. Le nom d'utilisateur du client est remplacé par l'espace réservé {0} dans le filtre de recherche. Pour plus d'informations, consultez Authentification et Autorisation.

• Role Base (Base de rôles) Nom unique du nœud du DIT qui sera recherché pour des rôles. Les rôles peuvent être configurés en tant qu'entrées de groupe LDAP explicites dans votre répertoire. Une entrée de rôle typique peut consister en un attribut pour le nom du rôle, tel que Nom commun, et un autre attribut, tel que member, avec des valeurs représentant les noms distinctifs ou les noms d'utilisateur des utilisateurs appartenant au groupe de rôles. Par exemple, compte tenu de l'unité administrative, group, vous pouvez fournir le nom distinctif suivant : ou=group,dc=example,dc=com.

• Role Search Matching (Recherche de rôle) Filtre de recherche LDAP qui sera utilisé pour rechercher des rôles dans roleBase. Le nom unique de l'utilisateur correspondant à userSearchMatching est remplacé dans l'espace réservé {0} du filtre de recherche. Le nom d'utilisateur du client sera remplacé par l'espace réservé {1}. Par exemple, si les entrées de rôle dans votre répertoire incluent un attribut nommé member, contenant les noms d'utilisateur de tous les utilisateurs de ce rôle, vous pouvez fournir le filtre de recherche suivant : (member:=uid={1}).

L'image suivante met en surbrillance l'endroit où spécifier ces détails.

Dans Optional settings (Paramètres facultatifs), vous pouvez fournir les informations facultatives suivantes :

• User Role Name (Nom du rôle utilisateur) Le nom de l'attribut LDAP dans l'entrée de répertoire de l'utilisateur aux fins de l'adhésion au groupe de l'utilisateur. Dans certains cas, les rôles utilisateur peuvent être identifiés par la valeur d'un attribut dans l'entrée de répertoire de l'utilisateur. L'option userRoleName vous permet de fournir le nom de cet attribut. Par exemple, considérons l'entrée utilisateur suivante :

  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

  Pour fournir le bon userRoleName pour l'exemple ci-dessus, spécifiez l'attribut memberOf. Si l'authentification réussit, le rôle role1 est affecté à l'utilisateur.

• Role Name (Nom du rôle) L'attribut du nom de groupe dans une entrée de rôle dont la valeur constitue le nom de ce rôle. Par exemple, vous pouvez spécifier cn pour le nom commun d'une entrée de groupe. Si l'authentification réussit, l'utilisateur reçoit la valeur de l'attribut cn pour chaque entrée de rôle dont il est membre.

• User Search Subtree (Sous-arborescence de recherche d'utilisateur) Définit l'étendue de la requête de recherche utilisateur LDAP. Si true, la portée est définie pour rechercher la sous-arborescence entière sous le nœud défini par userBase.

• Role Search Subtree (Sous-arborescence de recherche de rôle) Définit l'étendue de la requête de recherche utilisateur LDAP. Si true, la portée est définie pour rechercher la sous-arborescence entière sous le nœud défini par roleBase.

L'image suivante met en surbrillance l'endroit où spécifier ces paramètres facultatifs.

Fonctionnement de l'intégration avec LDAP

Vous pouvez penser à l'intégration dans deux catégories principales : la structure pour l'authentification et la structure pour l'autorisation.

Authentification

Pour l'authentification, les informations d'identification du client doivent être valides. Ces informations d'identification sont validées par rapport aux utilisateurs de la base d'utilisateurs du serveur LDAP.

La base d'utilisateurs fournie à l'agent ActiveMQ doit pointer vers le nœud dans le DIT où les utilisateurs sont stockés sur le serveur LDAP. Par exemple, si vous utilisez AWS Managed Microsoft AD et si vous avez les composants de domaine corp, example et com, et ceux dans lesquels vous avez des unités organisationnelles corp et Users, vous utiliseriez les champs suivants comme base d'utilisateurs :

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

L'agent ActiveMQ recherche à cet emplacement dans le DIT les utilisateurs afin d'authentifier les demandes de connexion client auprès de l'agent.

Parce que le code source ActiveMQ code en dur le nom de l'attribut pour les utilisateurs sur uid, vous devez vous assurer que cet attribut est défini à chaque utilisateur. Pour plus de simplicité, vous pouvez utiliser le nom d'utilisateur de connexion de l'utilisateur. Pour plus d'informations, consultez le code source activemq et Configuration des mappages d'ID dans les utilisateurs et ordinateurs Active Directory pour les versions Windows Server 2016 (et ultérieures).

Pour activer l'accès à la console ActiveMQ pour des utilisateurs spécifiques, assurez-vous qu'ils appartiennent au amazonmq-console-admins.

Autorisation

Pour l'autorisation, les bases de recherche d'autorisations sont spécifiées dans la configuration de l'agent. L'autorisation est effectuée sur une base par destination (ou caractère générique, ensemble de destination) via l'élément cachedLdapAuthorizationMap, qui se trouve dans le fichier de configuration activemq.xml de l'agent. Pour de plus amples informations, consultez Module d'autorisation LDAP mis en cache.

Note

Pour pouvoir utiliser l'élément cachedLDAPAuthorizationMap du fichier de configuraiton activemq.xml de votre agent, vous devez choisir l'option LDAP Authentication and Authorization (Authentification et autorisation LDAP) lors de la création d'une configuration via la AWS Management Console, ou définissez la propriété authenticationStrategy sur LDAP lors de la création d'une nouvelle configuration à l'aide de l'API Amazon MQ.

Vous devez fournir les trois attributs suivants dans l'élément cachedLDAPAuthorizationMap :

• queueSearchBase

• topicSearchBase

• tempSearchBase

Important

Pour éviter que des informations sensibles ne soient directement placées dans le fichier de configuration de l'agent, Amazon MQ bloque l'utilisation des attributs suivants dans cachedLdapAuthorizationMap :

• connectionURL

• connectionUsername

• connectionPassword

Lorsque vous créez un agent, Amazon MQ substitue les valeurs que vous fournissez via la AWS Management Console ou dans la propriété ldapServerMetadata de votre requête d'API, pour les attributs ci-dessus.

L'exemple suivant illustre un exemple d'utilisation 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> 

Ces valeurs identifient les emplacements dans le DIT où les autorisations pour chaque type de destination sont spécifiées. Donc, pour l'exemple ci-dessus avec AWS Managed Microsoft AD, en utilisant les mêmes composants de domaine de corp, example et com, vous devez spécifier une unité d'organisation nommée destination pour contenir tous vos types de destination. Dans cette unité d'organisation, vous en créeriez un pour queues, un pour topics et un pour destinations temp.

Cela signifie que votre base de recherche de file d'attente, qui fournit des informations d'autorisation pour les destinations de type file d'attente, aurait l'emplacement suivant dans votre DIT :

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

De même, les règles d'autorisation pour les rubriques et les destinations temporaires seraient situées au même niveau dans le 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
            

Dans l'unité d'organisation pour chaque type de destination (file d'attente, rubrique, temp), un caractère générique ou un nom de destination spécifique peut être fourni. Par exemple, pour fournir une règle d'autorisation pour toutes les files d'attente commençant par le préfixe DEMO.EVENTS.$., vous pouvez créer l'unité d'organisation suivante :

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

Note

L'unité d'organisation DEMO.EVENTS.$ est dans l'unité d'organisation Queue.

Pour plus d'informations sur les caractères génériques dans ActiveMQ, consultezCaractères génériques

Pour fournir des règles d'autorisation pour des files d'attente spécifiques, telles que DEMO.MYQUEUE, spécifiez quelque chose comme suit :

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

Groupes de sécurité

Dans chaque unité d'organisation qui représente une destination ou un caractère générique, vous devez créer trois groupes de sécurité. Comme pour toutes les autorisations dans ActiveMQ, il s'agit d'autorisations en lecture/écriture/admin. Pour plus d'informations sur ce que chacune de ces autorisations permet à un utilisateur, consultez Sécurité dans la documentation ActiveMQ.

Vous devez nommer ces groupes de sécurité read, write et admin. Dans chacun de ces groupes de sécurité, vous pouvez ajouter des utilisateurs ou des groupes, qui auront ensuite l'autorisation d'effectuer les actions associées. Vous aurez besoin de ces groupes de sécurité pour chaque jeu de destinations génériques ou chaque destination individuelle.

Note

Lorsque vous créez le groupe admin, un conflit survient avec le nom du groupe. Ce conflit se produit parce que les règles antérieures à Windows 2000 héritées ne permettent pas aux groupes de partager le même nom, même si les groupes se trouvent à des emplacements différents du DIT. La valeur de la zone de texte Pre-Windows 2000 (Pré-Windows 2000) n'a aucun impact sur la configuration, mais elle doit être globalement unique. Pour éviter ce conflit, vous pouvez ajouter un suffixe uuid à chaque groupe admin.

L'ajout d'un utilisateur au groupe de sécurité admin pour une destination particulière permettra à l'utilisateur de créer et de supprimer cette rubrique. Les ajouter au groupe de sécurité read leur permettra de lire à partir de la destination, et les ajouter au groupe write leur permettra d'écrire dans la destination.

Outre l'ajout d'utilisateurs individuels aux autorisations de groupe de sécurité, vous pouvez également ajouter des groupes entiers. Cependant, comme ActiveMQ code à nouveau en dur les noms d'attributs pour les groupes, vous devez vous assurer que le groupe que vous souhaitez ajouter possède la classe d'objet groupOfNames, comme illustré dans le code source ActiveMQ.

Pour ce faire, suivez le même processus qu'avec l'uid pour les utilisateurs. Consultez Configuration des mappages d'ID dans les utilisateurs et ordinateurs Active Directory pour les versions Windows Server 2016 (et ultérieures).