As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Integrando corretores ActiveMQ com LDAP

Você pode acessar seus corretores ActiveMQ usando os seguintes protocolos com habilitado: TLS

O Amazon MQ oferece uma escolha entre a autenticação nativa do ActiveMQ e a LDAP autenticação e autorização para gerenciar as permissões do usuário. Para obter informações sobre restrições relacionadas a nomes de usuário e senhas do ActiveMQ, consulte Usuários.

Para autorizar os usuários e grupos do ActiveMQ para trabalhar com filas e tópicos, você deve editar a configuração do agente. O Amazon MQ usa o Plugin de autenticação simples do ActiveMQ para restringir a leitura e a gravação em destinos. Para obter mais informações e exemplos, consulte Sempre configurar um mapa de autorização e authorizationEntry.

Integre LDAP com o ActiveMQ

Você pode autenticar usuários do Amazon MQ por meio das credenciais armazenadas em seu servidor leve de protocolo LDAP de acesso a diretórios (). Você também pode adicionar, excluir e modificar usuários do Amazon MQ e atribuir permissões a tópicos e filas por meio dele. Operações de gerenciamento, como criar, atualizar e excluir corretores, ainda exigem IAM credenciais e não estão integradas com. LDAP

Clientes que desejam simplificar e centralizar a autenticação e autorização do agente Amazon MQ usando LDAP um servidor podem usar esse recurso. Manter todas as credenciais do usuário no LDAP servidor economiza tempo e esforço ao fornecer um local central para armazenar e gerenciar essas credenciais.

O Amazon MQ fornece LDAP suporte usando o plug-in Apache JAAS ActiveMQ. Qualquer LDAP servidor, como o Microsoft Active Directory ou o OpenLDAP, compatível com o plug-in, também é suportado pelo Amazon MQ. Para obter mais informações sobre o plugin, consulte a seção Segurança da documentação do ActiveMQ.

Além dos usuários, você pode especificar o acesso a tópicos e filas para um grupo ou usuário específico por meio do seu LDAP servidor. Você faz isso criando entradas que representam tópicos e filas em seu LDAP servidor e, em seguida, atribuindo permissões a um LDAP usuário ou grupo específico. Em seguida, você pode configurar o agente para recuperar dados de autorização do LDAP servidor.

Pré-requisitos

Antes de adicionar LDAP suporte a um agente Amazon MQ novo ou existente, você deve configurar uma conta de serviço. Essa conta de serviço é necessária para iniciar uma conexão com um LDAP servidor e deve ter as permissões corretas para fazer essa conexão. Essa conta de serviço configurará a LDAP autenticação para seu corretor. Quaisquer conexões sucessivas de cliente serão autenticadas através da mesma conexão.

A conta de serviço é uma conta no seu LDAP servidor, que tem acesso para iniciar uma conexão. É um LDAP requisito padrão e você precisa fornecer as credenciais da conta de serviço apenas uma vez. Depois que a conexão for configurada, todas as conexões do future client serão autenticadas por meio do seu LDAP servidor. Suas credenciais de conta de serviço são armazenadas de forma segura em um formulário criptografado, acessível somente para o Amazon MQ.

Para integrar com o ActiveMQ, é necessária uma Árvore de Informações de Diretório DIT () específica no servidor. LDAP Para obter um exemplo de ldif arquivo que mostre claramente essa estrutura, consulte Importar o seguinte LDIF arquivo para o LDAP servidor na seção Segurança da documentação do ActiveMQ.

Começando com LDAP

Para começar, navegue até o console do Amazon MQ e escolha LDAPautenticação e autorização ao criar um novo Amazon MQ ou editar uma instância de agente existente.

Forneça as seguintes informações sobre a conta de serviço:

A imagem a seguir destaca onde fornecer esses detalhes.

Na seção de configuração de LDAP login, forneça as seguintes informações obrigatórias:

A imagem a seguir destaca onde especificar esses detalhes.

Nas Configurações opcionais, você pode fornecer as seguintes informações opcionais:

A imagem a seguir destaca onde especificar essas configurações opcionais.

Como LDAP a integração funciona

Podemos pensar na integração em duas categorias principais: a estrutura de autenticação e a estrutura de autorização.

Autenticação

Para autenticação, as credenciais do cliente devem ser válidas. Essas credenciais são validadas em relação aos usuários da base de usuários no LDAP servidor.

A base de usuários fornecida ao agente ActiveMQ deve apontar para o nó em que DIT os usuários estão armazenados no servidor. LDAP Por exemplo, se você estiver usando AWS Managed Microsoft AD, e tiver os componentes de domíniocorp, e examplecom, e dentro deles você tiver unidades organizacionais corp eUsers, você usaria o seguinte como sua base de usuários:

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

O agente ActiveMQ pesquisaria neste local no por usuários a fim de autenticar DIT as solicitações de conexão do cliente para o agente.

Como o código-fonte ActiveMQ codifica o nome do atributo para os usuários como uid, você deve se certificar de que cada usuário tem esse atributo definido. Para simplificar, você pode usar o nome de usuário da conexão do usuário. Para obter mais informações, consulte o ActiveMQ Código-fonte e Configurando mapeamentos de ID em Usuários e Computadores do Active Directory para Windows Server 2016 (e versões subsequentes).

Para habilitar o acesso ao console do ActiveMQ para usuários específicos, verifique se eles pertencem ao grupo amazonmq-console-admins.

Autorização

Para autorização, as bases de pesquisa de permissões são especificadas na configuração do agente. A autorização é feita por destino (ou caractere coringa, destino definido) por meio do cachedLdapAuthorizationMap elemento encontrado no activemq.xml Arquivo de configuração. Para obter mais informações, consulte Módulo de LDAP autorização em cache.

Você deve fornecer os três atributos a seguir como parte do Elemento cachedLDAPAuthorizationMap:

O seguinte exemplo demonstra o uso de deslocamentos 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> 

Esses valores identificam os locais em DIT que as permissões para cada tipo de destino são especificadas. Portanto, para o exemplo acima AWS Managed Microsoft AD, usando os mesmos componentes de domínio decorp,, e examplecom, você especificaria uma unidade organizacional nomeada destination para conter todos os seus tipos de destino. Dentro dessa UO, você criaria um para queues, um para topics, e um para tempdestinos.

Isso significaria que sua base de pesquisa de filas, que fornece informações de autorização para destinos do tipo fila, teria a seguinte localização em seu: DIT

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

Da mesma forma, as regras de permissões para tópicos e destinos temporários estariam localizadas no mesmo nível em: 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 da UO para cada tipo de destino (fila, tópico, temporário), um coringa ou um nome de destino específico pode ser fornecido. Por exemplo, para fornecer uma regra de autorização para todas as filas que começam com o prefixoDEMO. EVENTS.$., você pode criar a seguinte OU:

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

Para obter mais informações sobre coringas no ActiveMQ, consulteWildcards (Coringas)

Para fornecer regras de autorização para filas específicas, comoDEMO. MYQUEUE, especifique algo como o seguinte:

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

Grupos de segurança

Dentro de cada UO que representa um destino ou um coringa, você deve criar três grupos de segurança. Tal como acontece com todas as permissões no ActiveMQ, estas são permissões de leitura/escritura/admin. Para obter mais informações sobre o que cada uma dessas permissões permite que um usuário faça, consulte Segurança na documentação do ActiveMQ.

Você deve nomear esses grupos de segurança read, write, e admin. Dentro de cada um desses grupos de segurança, você pode adicionar usuários ou grupos que terão permissão para executar as ações associadas. Você precisará desses grupos de segurança para cada conjunto de destinos coringa ou destino individual.

Adicionar um usuário ao admin grupo de segurança para um destino específico permitirá que o usuário crie e exclua esse tópico. Adicionando-os ao read grupo de segurança permitirá que eles leiam a partir do destino e adicionando-os ao grupo write permitirá que eles escrevam no destino.

Além de adicionar usuários individuais às permissões do grupo de segurança, você também pode adicionar grupos inteiros. No entanto, como o ActiveMQ novamente codifica nomes de atributo para grupos, você deve garantir que o grupo que deseja adicionar tem a classe de objeto groupOfNames, conforme mostrado no código-fonte do ActiveMQ.

Para fazer isso, siga o mesmo processo que acontece com o uid para usuários. Consulte Configurando mapeamentos de ID em Usuários e Computadores do Active Directory para Windows Server 2016 (e versões subsequentes).