Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
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é :
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 AuthenticationauthorizationEntry
.
Note
Actuellement, Amazon MQ ne prend pas en charge l'authentification par certificat client.
Rubriques
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é
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é)
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 port636
.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.
![Où spécifier les détails du compte de service LDAP.](images/active-mq-ldap-service-account.png)
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.
![Où spécifier les détails de connexion LDAP.](images/active-mq-ldap-login-configuration.png)
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: j.doe@somecompany.com memberOf: role1 userPassword: password
Pour fournir le bon
userRoleName
pour l'exemple ci-dessus, spécifiez l'attributmemberOf
. Si l'authentification réussit, le rôlerole1
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'attributcn
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.
![](images/amazon-mq-active-ldap-optional-settings.png)
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.
![Emplacement pour rechercher des utilisateurs](images/active-mq-ldap-structure.png)
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
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
![Emplacement de base de recherche de file d'attente.](images/active-mq-ldap-queue-structure.png)
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
![Règles d'autorisation pour des files d'attente spécifiques](images/active-mq-ldap-authorization-rules.png)
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é
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.
![Groupes de sécurité](images/active-mq-ldap-security-groups.png)
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
.
![Ceci est mon image.](images/active-mq-ldap-admin-qualifier.png)
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)